Project Management System
Continuing spring cleaning 2026 for day two brings us to: project management system.
What is project management system you may ask?
Project Management System (pms) is two things:
- uh, it’s a project management system (le duh)
- but pms is also an experiment in maximizing agent information density, discovery, and self-management surfaces.
There’s also a very big 2,000 line README illustrating all commands and ideas for the project.
or, you could even checkout a somewhat illustrated getting started doc too.
Automated Agent Discovery Diving Surfaces
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Language Files Lines Code Comments Blanks
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
JSON 8 757 757 0 0
Python 529 252769 222291 2449 28029
Shell 41 5704 4915 76 713
SQL 1 1851 1440 206 205
TOML 2 101 89 0 12
─────────────────────────────────────────────────────────────────────────────────
Markdown 39 21245 0 15856 5389
|- BASH 30 3295 2505 389 401
|- Dockerfile 1 12 8 0 4
|- INI 1 16 14 0 2
|- JSON 16 1970 1963 0 7
|- Markdown 1 67 0 55 12
|- Python 15 3808 2997 268 543
|- SQL 1 60 52 4 4
|- TOML 1 16 16 0 0
|- YAML 3 73 73 0 0
(Total) 30562 7628 16572 6362
─────────────────────────────────────────────────────────────────────────────────
Rust 6 19460 18381 95 984
|- Markdown 2 269 0 268 1
(Total) 19729 18381 363 985
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total 626 311473 255501 19666 36306
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━My ongoing theory (which is correct, i will not be taking any questions) is the AI agents are smarter and more capable at people when nagvigating data structures and complex multi-dimensional interfaces.
So we should actually be intentionally designing more, practically, insane interfaces with hundreds or thousands of commands having unified output formats for maximum agent exposure and creativity in building new services and platforms over time.
Here, I made Project Management System as an agent-first task system (kinda like the task list built into claude code or codex) except pms:
- is a native database (sqlite or postgres)
- can be used on a local machine or remotely (postgres)
- can be used by one or more agents collaboratively
- tasks can have owners and agents and personalities and a dozen other metadata fields
- pms is organized around: plans -> projects -> tasks -> goals / objectives / …….. and other things.
- you can set deadlines, percentage completion for tasks updated (agents love estimating percentage completion on tasks and updating them incrementally), task labels, blockers, stages, and dozens of other things.
Another interesting part: since codex and claude have been RL’d on
“how to use task lists” with their internal harness tools, AI agents are
easily adapable to external task list systems too. You just
have to tell them to call out to your own external task list commands
with shell tools instead of using the bult in Task command
structures and the models/agents/harnesses adapt to much any more
expansive and expressive plan/project/task/goal management capabilities
automatically.
The basic interface for pms looks like the paste below at a “terminal pretty print” level, but all data also has opt-in “machine-readable” json output formats for more reliable value partitioning.
Here’s a sample of pms using pms to manage the project devlopment of pms itself:
$ uv run pms plan list
Scope: Instance-wide plan list view. The most recent scoped work is terminal; no other visible active work is currently surfaced.
Active Plans
0 visible
(none)
Draft Plans
3 visible
┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Ref ┃ Name ┃ Status ┃ Format ┃ Project ┃ Goal ┃ Objective ┃ Tasks ┃ Activity ┃ Last Transition ┃
┡━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 88e5c055 │ Objective Lifecycle │ draft │ json │ Objective Lifecycle │ - │ - │ 0 │ 25d ago │ 25d ago │
│ │ Aggregate Hardening │ │ │ Aggregate Parity │ │ │ │ (2026-04-25T13:46Z) │ (2026-04-25T13:46Z) │
│ 5eae65f1 │ PMS Release Readiness │ draft │ json │ PMS Release Readiness and │ - │ - │ 0 │ 28d ago │ 28d ago │
│ │ Documentation Plan │ │ │ Public Documentation │ │ │ │ (2026-04-23T01:40Z) │ (2026-04-23T01:40Z) │
│ d7619225 │ Transactional Correctness │ draft │ yaml │ PMS Transactional │ Make PMS multi-step writes │ - │ 0 │ 28d ago │ 28d ago │
│ │ Audit and Refactor Plan │ │ │ Correctness and Atomicity │ transactionally correct │ │ │ (2026-04-23T01:18Z) │ (2026-04-23T01:18Z) │
│ │ │ │ │ │ and crash-safe │ │ │ │ │
└──────────┴───────────────────────────┴────────┴────────┴───────────────────────────┴────────────────────────────┴───────────┴───────┴───────────────────────────┴────────────────────────────┘
Completed Plans
34 visible
┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Ref ┃ Name ┃ Status ┃ Format ┃ Project ┃ Goal ┃ Objective ┃ Tasks ┃ Activity ┃ Last Transition ┃
┡━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━┩
│ c961e98c │ Public Release Tagging │ completed │ yaml │ Public Release Tagging │ Confirm PMS is │ Revalidate maintained │ 3 │ 25d ago │ 25d ago │
│ │ Validation Plan │ │ │ Validation │ tag-ready for public │ docs and interfaces on │ │ (2026-04-25T16:31Z) │ (2026-04-25T16:31Z) │
│ │ │ │ │ │ release │ the release candidate │ │ │ │
│ │ │ │ │ │ │ commit │ │ │ │
│ 2d3438ee │ Key Result Lifecycle │ completed │ json │ Key Result Lifecycle │ Keep key result │ Prove key result │ 6 │ 25d ago │ 25d ago │
│ │ Aggregate Hardening │ │ │ Aggregate Parity │ lifecycle aggregates │ list/detail surfaces │ │ (2026-04-25T15:17Z) │ (2026-04-25T15:17Z) │
│ │ │ │ │ │ truthful across │ expose canonical │ │ │ │
│ │ │ │ │ │ maintained surfaces │ lifecycle rollups, │ │ │ │
│ │ │ │ │ │ │ timestamps, links, │ │ │ │
│ │ │ │ │ │ │ terminal reasoning, │ │ │ │
│ │ │ │ │ │ │ and continuation hints │ │ │ │
│ bb9af9b1 │ Cross-Surface │ completed │ json │ Cross-Surface │ - │ - │ 1 │ 25d ago │ 25d ago │
│ │ Lifecycle Aggregate │ │ │ Lifecycle Aggregate │ │ │ │ (2026-04-25T04:29Z) │ (2026-04-25T04:29Z) │
│ │ Hardening │ │ │ Parity │ │ │ │ │ │
│ 8cbd51f4 │ Maintained Client │ completed │ json │ Maintained Client │ - │ Close lifecycle list │ 0 │ 26d ago │ 26d ago │
│ │ Lifecycle List Surface │ │ │ Lifecycle List Surface │ │ filter and pagination │ │ (2026-04-24T21:02Z) │ (2026-04-24T21:02Z) │
│ │ Hardening │ │ │ Parity │ │ parity gaps and add │ │ │ │
│ │ │ │ │ │ │ shared live audits │ │ │ │
│ baaab863 │ Dynamic Client │ completed │ json │ Dynamic Maintained │ - │ - │ 0 │ 26d ago │ 26d ago │
│ │ Operator Payload │ │ │ Client Operator │ │ │ │ (2026-04-24T19:47Z) │ (2026-04-24T19:47Z) │
│ │ Parity Hardening │ │ │ Payload Parity │ │ │ │ │ │
│ 33c1fc74 │ Client Operator │ completed │ json │ Maintained Client │ - │ - │ 0 │ 26d ago │ 26d ago │
│ │ Surface Contract │ │ │ Operator Surface │ │ │ │ (2026-04-24T19:47Z) │ (2026-04-24T19:47Z) │
│ │ Hardening │ │ │ Contract Truth │ │ │ │ │ │
│ f5e4b6d4 │ Quickstart Project │ completed* │ json │ Quickstart Project │ - │ - │ 4 │ 26d ago │ 26d ago │
│ │ Plan │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ a4eb0c36 │ API Aggregate Operator │ completed │ json │ API Aggregate Operator │ - │ - │ 0 │ 26d ago │ 26d ago │
│ │ Surface Hardening │ │ │ Surface Parity │ │ │ │ (2026-04-24T18:51Z) │ (2026-04-24T18:51Z) │
│ 6257a8fa │ Cross-Surface │ completed │ json │ Cross-Surface │ Keep lifecycle rollups │ Prove nested graph │ 3 │ 26d ago │ 26d ago │
│ │ Lifecycle Contract │ │ │ Lifecycle Contract │ identical across CLI, │ status, activity, │ │ (2026-04-24T18:01Z) │ (2026-04-24T18:00Z) │
│ │ Hardening │ │ │ Audit │ API, and MCP surfaces │ transition, and │ │ │ │
│ │ │ │ │ │ │ terminal reasoning │ │ │ │
│ │ │ │ │ │ │ stay cross-surface │ │ │ │
│ │ │ │ │ │ │ consistent │ │ │ │
│ 8a9d75bb │ Project Lifecycle │ completed │ json │ Project Lifecycle │ Keep project lifecycle │ Reconcile raw project │ 3 │ 26d ago │ 26d ago │
│ │ Bubble-Up Hardening │ │ │ Bubble-Up Truth │ truth aligned with │ status with effective │ │ (2026-04-24T16:28Z) │ (2026-04-24T16:28Z) │
│ │ │ │ │ │ nested graph execution │ task goal and plan │ │ │ │
│ │ │ │ │ │ │ terminality │ │ │ │
│ 8d707151 │ CLI Output Contract │ completed │ json │ CLI Output Contract │ Stabilize CLI text and │ Eliminate CLI output │ 11 │ 26d ago │ 26d ago │
│ │ Hardening │ │ │ Determinism Audit │ machine output │ nondeterminism across │ │ (2026-04-24T15:05Z) │ (2026-04-24T15:05Z) │
│ │ │ │ │ │ contracts across │ operator and machine │ │ │ │
│ │ │ │ │ │ interactive and │ surfaces │ │ │ │
│ │ │ │ │ │ non-interactive │ │ │ │ │
│ │ │ │ │ │ surfaces │ │ │ │ │
│ e67ad6d9 │ Graph Transition │ completed │ json │ Graph Transition │ Normalize │ - │ 4 │ 26d ago │ 26d ago │
│ │ Surface Truth │ │ │ Surface Truth Audit │ operator-visible graph │ │ │ (2026-04-24T12:46Z) │ (2026-04-24T12:46Z) │
│ │ Hardening │ │ │ │ transition │ │ │ │ │
│ │ │ │ │ │ representation │ │ │ │ │
│ 1eb7873a │ Residual Graph │ completed │ json │ Graph Representation │ Close residual graph │ Audit residual │ 4 │ 26d ago │ 26d ago │
│ │ Representation │ │ │ Audit Backlog │ representation gaps │ mutation sources that │ │ (2026-04-24T02:47Z) │ (2026-04-24T02:47Z) │
│ │ Bubble-Up Sweep │ │ │ │ across all maintained │ should bubble into │ │ │ │
│ │ │ │ │ │ summary systems │ summary surfaces │ │ │ │
│ a8168547 │ Graph Lifecycle Status │ completed │ json │ Graph Lifecycle │ Keep graph lifecycle │ Prevent stale or │ 5 │ 27d ago │ 27d ago │
│ │ Truth Hardening │ │ │ Representation Audit │ status truthful across │ contradictory active │ │ (2026-04-24T01:51Z) │ (2026-04-24T01:51Z) │
│ │ │ │ │ │ summary surfaces │ and completed state │ │ │ │
│ │ │ │ │ │ │ across nested graph │ │ │ │
│ │ │ │ │ │ │ views │ │ │ │
│ f7237ee6 │ Graph Summary Surface │ completed │ json │ Graph Summary Surface │ Bubble nested graph │ Prove every operator │ 5 │ 27d ago │ 27d ago │
│ │ Truth Hardening │ │ │ Truth Audit │ activity into summary │ surface derives │ │ (2026-04-24T00:46Z) │ (2026-04-24T00:46Z) │
│ │ │ │ │ │ surfaces │ recency from nested │ │ │ │
│ │ │ │ │ │ │ graph mutations │ │ │ │
│ 2a4436f3 │ Completed Visible Plan │ completed │ json │ Completed Visible Plan │ - │ - │ 0 │ 27d ago │ 27d ago │
│ │ │ │ │ Project │ │ │ │ (2026-04-23T18:59Z) │ (2026-04-23T18:59Z) │
│ e8006664 │ PMS Goal-Scoped │ completed │ json │ PMS Goal-Scoped │ - │ - │ 0 │ 39d ago │ 39d ago │
│ │ Execution and Unified │ │ │ Execution and Unified │ │ │ │ (2026-04-11T16:02Z) │ (2026-04-11T16:02Z) │
│ │ Graph Reporting Plan │ │ │ Graph Reporting │ │ │ │ │ │
│ 2ef81301 │ PMS Clean-State │ completed │ json │ PMS Clean-State │ Audit PMS from the │ - │ 1 │ 39d ago │ 39d ago │
│ │ Platform Audit Plan │ │ │ Platform Audit │ cleaned state and │ │ │ (2026-04-11T15:19Z) │ (2026-04-11T15:19Z) │
│ │ │ │ │ │ prioritize the next │ │ │ │ │
│ │ │ │ │ │ branch │ │ │ │ │
│ 33810a91 │ PMS Network Runtime │ completed │ json │ PMS Network Runtime │ Guarantee end-to-end │ - │ 26 │ 39d ago │ 39d ago │
│ │ and Client Interop │ │ │ and Client Interop │ correctness, │ │ │ (2026-04-11T13:29Z) │ (2026-04-11T13:29Z) │
│ │ Delivery Plan │ │ │ Hardening │ ergonomics, and │ │ │ │ │
│ │ │ │ │ │ reliability across PMS │ │ │ │ │
│ │ │ │ │ │ server and client │ │ │ │ │
│ │ │ │ │ │ interfaces │ │ │ │ │
│ e93bb92b │ PMS Consistency and │ completed │ json │ PMS Consistency and │ Close remaining PMS │ - │ 10 │ 39d ago │ 39d ago │
│ │ Operator Usability │ │ │ Operator Usability │ consistency, │ │ │ (2026-04-11T13:29Z) │ (2026-04-11T13:29Z) │
│ │ Closure Delivery Plan │ │ │ Closure │ correctness, and │ │ │ │ │
│ │ │ │ │ │ operator-usability │ │ │ │ │
│ │ │ │ │ │ gaps │ │ │ │ │
│ c813fba2 │ PMS Active Goal │ completed │ yaml │ PMS Active Goal │ Make goal surfaces and │ - │ 0 │ 39d ago │ 39d ago │
│ │ Visibility and Backlog │ │ │ Visibility and Backlog │ active backlog review │ │ │ (2026-04-11T04:16Z) │ (2026-04-11T04:16Z) │
│ │ Rationalization │ │ │ Rationalization │ reflect current │ │ │ │ │
│ │ Delivery Plan │ │ │ │ actionable work │ │ │ │ │
│ │ │ │ │ │ instead of retained │ │ │ │ │
│ │ │ │ │ │ fixture residue │ │ │ │ │
│ 27652e8e │ PMS Graph Workflow │ completed │ yaml │ PMS Graph Workflow │ Make graph workflows │ - │ 27 │ 39d ago │ 39d ago │
│ │ Architecture │ │ │ Architecture │ coherent and navigable │ │ │ (2026-04-11T04:14Z) │ (2026-04-11T04:14Z) │
│ │ Consistency Delivery │ │ │ Consistency │ across planning, │ │ │ │ │
│ │ Plan │ │ │ │ execution, and │ │ │ │ │
│ │ │ │ │ │ ownership surfaces │ │ │ │ │
│ cce44403 │ PMS Actor Identity and │ completed │ yaml │ PMS Graph Workflow │ Make graph workflows │ - │ 21 │ 39d ago │ 39d ago │
│ │ Persona Graph Delivery │ │ │ Architecture │ coherent and navigable │ │ │ (2026-04-11T04:14Z) │ (2026-04-11T04:14Z) │
│ │ Plan │ │ │ Consistency │ across planning, │ │ │ │ │
│ │ │ │ │ │ execution, and │ │ │ │ │
│ │ │ │ │ │ ownership surfaces │ │ │ │ │
│ 7543ffff │ PMS Global Task │ completed │ json │ PMS Global Task │ Make global task list │ - │ 3 │ 41d ago │ 41d ago │
│ │ Visibility and │ │ │ Visibility and │ and task read surfaces │ │ │ (2026-04-09T02:48Z) │ (2026-04-09T02:48Z) │
│ │ Operator Surface Truth │ │ │ Operator Surface Truth │ truthful about visible │ │ │ │ │
│ │ Delivery Plan │ │ │ │ operator work versus │ │ │ │ │
│ │ │ │ │ │ retained audit history │ │ │ │ │
│ 0d167979 │ PMS Global Readback │ completed │ json │ PMS Global Readback │ Make global │ - │ 5 │ 42d ago │ 42d ago │
│ │ Truth and History │ │ │ Truth and History │ dashboards, totals, │ │ │ (2026-04-08T23:40Z) │ (2026-04-08T23:40Z) │
│ │ Integrity Delivery │ │ │ Integrity │ and retained-history │ │ │ │ │
│ │ Plan │ │ │ │ summaries truthful │ │ │ │ │
│ │ │ │ │ │ under large mixed │ │ │ │ │
│ │ │ │ │ │ state │ │ │ │ │
│ 5f939069 │ PMS Unified Data Truth │ completed │ json │ PMS Unified Data Truth │ - │ - │ 20 │ 42d ago │ 42d ago │
│ │ Architecture Delivery │ │ │ Architecture │ │ │ │ (2026-04-08T03:47Z) │ (2026-04-08T03:47Z) │
│ │ Plan │ │ │ │ │ │ │ │ │
│ 060215a3 │ PMS Runtime Truth and │ completed │ json │ PMS Runtime Truth and │ Make PMS state │ - │ 6 │ 45d ago │ 45d ago │
│ │ Scoped Mutation Safety │ │ │ Scoped Mutation Safety │ mutations explicit, │ │ │ (2026-04-06T00:00Z) │ (2026-04-05T23:59Z) │
│ │ Delivery Plan │ │ │ │ workspace-correct, and │ │ │ │ │
│ │ │ │ │ │ truthfully reflected │ │ │ │ │
│ │ │ │ │ │ across direct and │ │ │ │ │
│ │ │ │ │ │ delegated runtime │ │ │ │ │
│ │ │ │ │ │ paths │ │ │ │ │
│ 154d768f │ Runtime Auth Recovery │ completed │ json │ PMS Runtime Truth and │ - │ - │ 2 │ 45d ago │ 45d ago │
│ │ Continuation │ │ │ Scoped Mutation Safety │ │ │ │ (2026-04-06T00:00Z) │ (2026-04-05T23:59Z) │
│ e0e2ae22 │ PMS Autonomous │ completed │ json │ PMS Autonomous │ Drive PMS toward │ - │ 11 │ 45d ago │ 45d ago │
│ │ Reliability and │ │ │ Reliability and │ self-reconciling, │ │ │ (2026-04-05T23:14Z) │ (2026-04-05T23:14Z) │
│ │ Ergonomics Growth │ │ │ Ergonomics Growth │ low-friction, │ │ │ │ │
│ │ Delivery Plan │ │ │ │ production-grade │ │ │ │ │
│ │ │ │ │ │ operator and │ │ │ │ │
│ │ │ │ │ │ automation workflows │ │ │ │ │
│ bd06605f │ Bench Project Plan │ completed │ json │ Bench Project │ - │ - │ 2 │ 45d ago │ 45d ago │
│ │ │ │ │ │ │ │ │ (2026-04-05T18:51Z) │ (2026-04-05T18:51Z) │
│ a757dd6e │ PMS Finality and Scope │ completed │ json │ PMS Finality and Scope │ Make completion and │ - │ 10 │ 45d ago │ 45d ago │
│ │ Clarity Delivery Plan │ │ │ Clarity │ ongoing instance work │ │ │ (2026-04-05T14:20Z) │ (2026-04-05T14:20Z) │
│ │ │ │ │ │ unambiguous in PMS │ │ │ │ │
│ │ │ │ │ │ operator surfaces │ │ │ │ │
│ 2972c735 │ PMS Whole-System │ completed │ json │ PMS Whole-System │ Drive PMS toward │ - │ 43 │ 45d ago │ 45d ago │
│ │ Hardening Delivery │ │ │ Hardening and │ whole-system │ │ │ (2026-04-05T03:39Z) │ (2026-04-05T03:39Z) │
│ │ Plan │ │ │ Completion │ correctness, security, │ │ │ │ │
│ │ │ │ │ │ performance, │ │ │ │ │
│ │ │ │ │ │ usability, and parity │ │ │ │ │
│ │ │ │ │ │ completion │ │ │ │ │
│ a29dcda7 │ Rust Fast Path and │ completed │ json │ Rust Fast Path and │ Reconcile PMS planning │ - │ 26 │ 46d ago │ 46d ago │
│ │ Interface Parity │ │ │ Interface Parity │ state and continue │ │ │ (2026-04-04T21:38Z) │ (2026-04-04T21:38Z) │
│ │ Delivery Plan │ │ │ │ runtime, interface, │ │ │ │ │
│ │ │ │ │ │ and scale hardening │ │ │ │ │
│ c3516211 │ Capability Extension │ completed │ json │ Platform Capability │ Ship the next │ - │ 8 │ 46d ago │ 46d ago │
│ │ and UX Tightening │ │ │ Extension and UX │ operator-grade PMS │ │ │ (2026-04-04T19:50Z) │ (2026-04-04T19:50Z) │
│ │ Delivery Plan │ │ │ Tightening │ capability layer │ │ │ │ │
└──────────┴────────────────────────┴────────────┴────────┴────────────────────────┴────────────────────────┴────────────────────────┴───────┴────────────────────────┴────────────────────────┘
Archived Plans
20 visible
┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Ref ┃ Name ┃ Status ┃ Format ┃ Project ┃ Goal ┃ Objective ┃ Tasks ┃ Activity ┃ Last Transition ┃
┡━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ ef58d35d │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ 78cc7787 │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ 78b2d06c │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ f39db252 │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ a9b8d4ad │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ a622f22b │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ 990bb3b3 │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ 6cee20de │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ 0c118214 │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ ef77c856 │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ fb00d9a1 │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ 1859bf82 │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ e19ca9bf │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ 12b896b0 │ Quickstart Project Plan │ archived │ json │ Quickstart Project │ - │ - │ 3 │ 26d ago │ 26d ago │
│ │ │ │ │ │ │ │ │ (2026-04-24T19:22Z) │ (2026-04-24T19:22Z) │
│ fcd1c44e │ PMS Active Work │ archived │ json │ PMS Active Work │ - │ - │ 0 │ 39d ago │ 39d ago │
│ │ Eligibility and Fixture │ │ │ Eligibility and Fixture │ │ │ │ (2026-04-11T13:29Z) │ (2026-04-11T13:29Z) │
│ │ Visibility Integrity │ │ │ Visibility Integrity │ │ │ │ │ │
│ │ Delivery Plan │ │ │ │ │ │ │ │ │
│ 4abfc994 │ PMS Stale Fixture │ archived │ json │ PMS Stale Fixture │ Suppress stale fixture │ - │ 0 │ 39d ago │ 39d ago │
│ │ Suppression and Start │ │ │ Suppression and Start │ residue from default │ │ │ (2026-04-11T13:29Z) │ (2026-04-11T13:29Z) │
│ │ Focus Truth Delivery Plan │ │ │ Focus Truth │ operator active-work │ │ │ │ │
│ │ │ │ │ │ surfaces │ │ │ │ │
│ 3e58b823 │ PMS No-Actionable Surface │ archived │ json │ PMS No-Actionable Surface │ Make no-active-work │ - │ 0 │ 39d ago │ 39d ago │
│ │ Truth Delivery Plan │ │ │ Truth │ operator surfaces │ │ │ (2026-04-11T13:29Z) │ (2026-04-11T13:29Z) │
│ │ │ │ │ │ truthful and actionable │ │ │ │ │
│ 19f98d4d │ PMS Residual │ archived │ json │ PMS Residual │ Close residual │ - │ 0 │ 39d ago │ 39d ago │
│ │ No-Actionable Task │ │ │ No-Actionable Task │ no-actionable-work │ │ │ (2026-04-11T13:29Z) │ (2026-04-11T13:29Z) │
│ │ Surface Truth Delivery │ │ │ Surface Truth │ guidance gaps on global │ │ │ │ │
│ │ Plan │ │ │ │ task surfaces │ │ │ │ │
│ 5e7bffb8 │ PMS Filter-Preserving │ archived │ json │ PMS Filter-Preserving │ Make task-surface machine │ - │ 0 │ 39d ago │ 39d ago │
│ │ Task Surface Links │ │ │ Task Surface Links │ links preserve active │ │ │ (2026-04-11T13:29Z) │ (2026-04-11T13:29Z) │
│ │ Delivery Plan │ │ │ │ filters │ │ │ │ │
│ 0889e814 │ PMS Filter-Preserving │ archived │ yaml │ PMS Filter-Preserving │ - │ - │ 0 │ 39d ago │ 39d ago │
│ │ Project Surface Links │ │ │ Project Surface Links │ │ │ │ (2026-04-11T13:29Z) │ (2026-04-11T13:29Z) │
│ │ Delivery Plan │ │ │ │ │ │ │ │ │
└──────────┴───────────────────────────┴──────────┴────────┴───────────────────────────┴───────────────────────────┴───────────┴───────┴───────────────────────────┴───────────────────────────┘
* status shown is the derived graph lifecycle, not the stale stored plan row
Projects Without Plans
4 visible
Active Work (1 visible)
┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Ref ┃ Name ┃ Status ┃ Activity ┃ Last Transition ┃
┡━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ fa1ce0de │ Progress Auto Start Project │ active │ 25d ago (2026-04-25T21:09Z) │ 25d ago (2026-04-25T21:09Z) │
└──────────┴─────────────────────────────┴────────┴─────────────────────────────┴─────────────────────────────┘
Project History (1 visible)
┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Ref ┃ Name ┃ Status ┃ Activity ┃ Last Transition ┃
┡━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 34855fb4 │ Planless Project Visibility Audit │ completed │ 27d ago (2026-04-24T00:39Z) │ 27d ago (2026-04-24T00:39Z) │
└──────────┴───────────────────────────────────┴───────────┴─────────────────────────────┴─────────────────────────────┘
Delivery History (1 visible)
┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Ref ┃ Name ┃ Status ┃ Activity ┃ Last Transition ┃
┡━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 3a85e34b │ PMS Deployment And Operator Documentation Truth │ completed │ 27d ago (2026-04-23T03:46Z) │ 27d ago (2026-04-23T03:46Z) │
└──────────┴─────────────────────────────────────────────────┴───────────┴─────────────────────────────┴─────────────────────────────┘
Repro Artifact (1 visible)
┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Ref ┃ Name ┃ Status ┃ Activity ┃ Last Transition ┃
┡━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 48210fff │ Complete Repro Project 2 │ completed │ 46d ago (2026-04-05T00:34Z) │ 46d ago (2026-04-05T00:34Z) │
└──────────┴──────────────────────────┴───────────┴─────────────────────────────┴─────────────────────────────┘
These projects have fresh graph activity but no persisted plan row, so they are invisible as plan entries unless surfaced here.
Suppressed generated planless projects: 6 (use --include-generated to show)
Total: 57
Status groups: active 0 | draft 3 | completed 34 | archived 20
Freshest Visible Activity: Progress Auto Start Project (project without plan) (25d ago (2026-04-25T21:09Z))
Freshest Visible Transition: Progress Auto Start Project (project without plan) (25d ago (2026-04-25T21:09Z))
Suppressed generated plans: 131 (use --include-generated to show)
Recently Completed Plans:
- Public Release Tagging Validation Plan [Public Release Tagging Validation] (updated 25d ago (2026-04-25T16:31Z))
- Key Result Lifecycle Aggregate Hardening [Key Result Lifecycle Aggregate Parity] (updated 25d ago (2026-04-25T15:17Z))
- Cross-Surface Lifecycle Aggregate Hardening [Cross-Surface Lifecycle Aggregate Parity] (updated 25d ago (2026-04-25T04:29Z))
Completed-scope shortcuts: uv run pms plan show c961e98c-b3f8-4840-8e2a-33fe17e38893, uv run pms plan show 2d3438ee-4e6b-4ea3-a5ff-a4c9375be790, uv run pms plan show
bb9af9b1-7885-4a9f-a89d-e108756163ef
Execution Focus: Client operator payload parity fallback task (0%)
Focus Reason: next ready work to start
Next:
- uv run pms task start "Client operator payload parity fallback task" --project "Quickstart Project"
- uv run pms task show "Client operator payload parity fallback task" --project "Quickstart Project"
- uv run pms plan show 88e5c055
- uv run pms plan lineage --plan-id 88e5c055
- uv run pms plan create <name> --project "<name>" --content '{}'
- uv run pms plan show c961e98c-b3f8-4840-8e2a-33fe17e38893One VERY IMPORTANT approach when creating “agent-first” terminal / cli application is: you can see the trailer at the end of the command there. I intentionally designed the system to output POTENTIAL NEXT COMMANDS with pre-populated values and defaults the agent may want to explore next when running commands.
Every command output on pms includes “suggested next” or “related commands you may also like” and even “related entities in graph space” (including all JSON output, it’s just formatted differently) in the screen output or data payload for easy navigation without agents needing to “memorize a system” up front. Progressive disclosure of capability surfaces while ranking “important commands” higher in memory is the only way forward.
Other views include (but are not limited to):
task show
$ uv run pms task show "Audit recent terminal work operator contracts" --project "Graph Representation Audit Backlog"
Audit recent terminal work operator contracts
ID: 75773531-3b61-4ebc-b301-8ab923dc62f7
Project: Graph Representation Audit Backlog (b07c407e-1d44-49a9-a7f8-a91a3807d83e)
Created: 27d ago (2026-04-23T19:37Z)
Updated: 26d ago (2026-04-24T02:17Z)
Last Activity: 26d ago (2026-04-24T02:17Z)
Last Transition: 26d ago (2026-04-24T02:17Z)
Status: done
Priority: medium
Evidence: 0
Graph: 0 blocked-by | 0 dependents | 0 subtasks
Progress: 100%
Last Update: 26d ago (2026-04-24T02:17Z) by codex - Start now surfaces recent terminal project context, canonical recent-completion payloads, and freshest visible project activity/transition
when no active focus remains; targeted CLI coverage, the graph-summary audit, and the full public release gate all passed from this checkpoint.
Description: Ensure recent-completion and recent-transition summaries stay truthful when no active focus remains.
Linked Plans:
- Residual Graph Representation Bubble-Up Sweep (1eb7873a-4e3b-4303-a609-71b9fe0918fe)
Next:
- uv run pms plan list --task-id 75773531-3b61-4ebc-b301-8ab923dc62f7 --format json
- uv run pms project show b07c407e-1d44-49a9-a7f8-a91a3807d83e --format json
- uv run pms task tree --project b07c407e-1d44-49a9-a7f8-a91a3807d83e --root-task-id 75773531-3b61-4ebc-b301-8ab923dc62f7 --format json
- uv run pms task timeline "Audit recent terminal work operator contracts" --project "Graph Representation Audit Backlog"
- uv run pms task progress "Audit recent terminal work operator contracts" --project "Graph Representation Audit Backlog" <percent> <message> --by <user>
- uv run pms task evidence list "Audit recent terminal work operator contracts" --project "Graph Representation Audit Backlog"dashboard
$ uv run pms dashboard
Dashboard Overview
========================================
Scope: Instance-wide dashboard view. Completed scoped work remains terminal, but unrelated active work still exists elsewhere in this PMS instance.
Purpose: overall live-state control plane for project health, ready work, and next operator actions.
Creates: no new state; this command reads current live system status.
Visible Active Projects: 1
Visible Tasks: 16
Completed: 0 / 16
Instance Totals: 50 projects, 543 tasks, 511 completed, 0 blocked
Suppressed generated projects: 0
Suppressed non-active projects: 2
Runtime Coordination: Direct-file mode is active.
Reason: Writes are going straight to SQLite because PMS_WRITE_MODE is set to `direct`.
Freshest Visible Activity: Progress Auto Start Project (25d ago (2026-04-25T21:09Z))
Freshest Visible Transition: Progress Auto Start Project (25d ago (2026-04-25T21:09Z))
Active Projects:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Project ┃ Health ┃ Tasks ┃ Activity ┃ Transition ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ Progress Auto Start Project │ 50% │ 0/16 │ 25d ago (2026-04-25T21:09Z) │ 25d ago (2026-04-25T21:09Z) │
└─────────────────────────────┴────────┴───────┴─────────────────────────────┴─────────────────────────────┘
Recently Completed Projects:
- Public Release Tagging Validation (activity 25d ago (2026-04-25T16:31Z); transition 25d ago (2026-04-25T16:31Z))
- Key Result Lifecycle Aggregate Parity (activity 25d ago (2026-04-25T15:17Z); transition 25d ago (2026-04-25T15:17Z))
- Objective Lifecycle Aggregate Parity (activity 25d ago (2026-04-25T13:46Z); transition 25d ago (2026-04-25T13:46Z))
Completed-scope shortcuts: uv run pms project show "Public Release Tagging Validation" --format json, uv run pms project show "Key Result Lifecycle Aggregate Parity" --format json, uv run pms
project show "Objective Lifecycle Aggregate Parity" --format json
Goals by Horizon:
┏━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Horizon ┃ Goals ┃ Avg Progress ┃
┡━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ short_term │ 726/776 │ 94.3% │
└────────────┴─────────┴──────────────┘
Focus: Progress Auto Start Task (35%)
Why: active execution in progress
Queues:
- ready (0) Tasks ready to start (no blocking dependencies).
- stale (showing 3 of 16) Tasks with no updates in 14+ days.
- Progress Auto Start Task [Progress Auto Start Project] updated 25d ago (2026-04-25T15:24Z)
- Progress Auto Start Task [Progress Auto Start Project] updated 25d ago (2026-04-25T15:33Z)
- Progress Auto Start Task [Progress Auto Start Project] updated 25d ago (2026-04-25T15:35Z)
- blocked (0) Tasks blocked by dependencies or execution locks.
- overdue (0) Tasks past their due date.
- at_risk (0) Tasks due within the next 7 days.
Next Actions (Ready Tasks): none
In Progress:
- Progress Auto Start Task [Progress Auto Start Project] workflow - progress 35% activity 25d ago (2026-04-25T21:09Z) id 29fb1c10
- Progress Auto Start Task [Progress Auto Start Project] workflow - progress 35% activity 25d ago (2026-04-25T20:49Z) id 871b7739
- Progress Auto Start Task [Progress Auto Start Project] workflow - progress 35% activity 25d ago (2026-04-25T18:23Z) id d917eefc
- Progress Auto Start Task [Progress Auto Start Project] workflow - progress 35% activity 25d ago (2026-04-25T17:53Z) id 9ea6996b
- Progress Auto Start Task [Progress Auto Start Project] workflow - progress 35% activity 25d ago (2026-04-25T17:44Z) id eb9e7fa5
Blocked: none
Next:
- uv run pms config set --write-mode prefer_server --server-url http://127.0.0.1:8765
- uv run pms runtime prefer-server --host 127.0.0.1 --port 8765
- uv run pms start --format json
- uv run pms task progress "Progress Auto Start Task" --project "Progress Auto Start Project" <percent> <message> --by <user>
- uv run pms task show "Progress Auto Start Task" --project "Progress Auto Start Project"
- uv run pms work daily --scope-type project --scope "Progress Auto Start Project" --format json
- uv run pms queue presets --format jsonYou may notice in the above output there is also a “server mode.”
You can run pms as a server which can then use the faster
rust client to connect to the server for near-instant responses instead
of incurring the dreaded “python vm startup latency” on every command.
The practice of “python core, but make python also be a server, then use
rust/zig/c” is a workable pattern I used in hiproc and it
works great for instant response commands while retaining a more usable
backend architecture.
task view in JSON output also showing all linkage between projects/plans/tasks/events/artifacts
{
"id": "733d5f29-6bbc-46ad-8b81-e089cc2c442a",
"created_at": "2026-04-04T20:39:52.164223+00:00",
"updated_at": "2026-04-04T20:58:57.811992+00:00",
"last_event_sequence": 11,
"last_revision_number": 9,
"project_id": "126c521f-bf6b-41dc-ae19-96b2cf00b5f0",
"milestone_id": null,
"parent_id": null,
"title": "Auto-surface newly unblocked dependents in task completion output and planning views",
"description": "When completing the last blocker in a dependency chain, include newly unblocked task refs in task complete output, task list/goal summary/planning views, and regression audits so operators see downstream work immediately.",
"status": "done",
"priority": "medium",
"complexity_points": null,
"actual_hours": null,
"current_progress_percent": 100,
"last_progress_update_at": "2026-04-04T20:58:56.694382+00:00",
"checked_out_at": null,
"checkout_lease_until": null,
"checkout_attempts": 0,
"checkout_version": 0,
"workflow_id": null,
"current_state": null,
"workflow_metadata": {},
"due_date": null,
"tags": [],
"sort_order": 0,
"completed_at": "2026-04-04T20:58:57.811992+00:00",
"assignee": {
"ref": null,
"id": null,
"actor": null,
"links": {
"actor": null,
"tasks": null
}
},
"checkout": {
"agent_session_id": null,
"actor": {
"ref": null,
"id": null,
"actor": null,
"links": {
"actor": null,
"tasks": null
}
},
"checked_out_at": null,
"lease_until": null,
"version": 0,
"expired": false
},
"project_name": "Rust Fast Path and Interface Parity",
"last_activity_at": "2026-04-04T20:58:57.814350+00:00",
"last_transition_at": "2026-04-04T20:58:57.814350+00:00",
"workflow_summary": null,
"available_transitions": [],
"labels": [],
"evidence_count": 0,
"completion_criteria": [],
"completion_ready": false,
"context": {
"project": {
"id": "126c521f-bf6b-41dc-ae19-96b2cf00b5f0",
"name": "Rust Fast Path and Interface Parity",
"links": {
"self": "uv run pms project show 126c521f-bf6b-41dc-ae19-96b2cf00b5f0 --format json",
"summary": "uv run pms project summary 126c521f-bf6b-41dc-ae19-96b2cf00b5f0 --format json",
"tasks": "uv run pms task list --project 126c521f-bf6b-41dc-ae19-96b2cf00b5f0 --format json",
"plans": "uv run pms plan list --project-id 126c521f-bf6b-41dc-ae19-96b2cf00b5f0 --format json"
}
},
"milestone": null,
"parent": null,
"subtasks": [],
"subtask_count": 0,
"dependency_count": 2,
"dependent_count": 0
},
"progress": {
"current_percent": 100,
"last_update": {
"id": "met_2080d55b-8444-4015-928e-d6841ba06d9e",
"created_at": "2026-05-21T02:17:24.898751+00:00",
"updated_at": "2026-05-21T02:17:24.898752+00:00",
"last_event_sequence": 0,
"last_revision_number": 0,
"task_id": "733d5f29-6bbc-46ad-8b81-e089cc2c442a",
"percent_complete": 100,
"status_message": "Completed",
"updated_by": "codex",
"timestamp": "2026-04-04T20:58:57.811992+00:00",
"duration_since_last_update_seconds": null,
"percent_delta": null,
"metadata": {}
},
"last_updated_at": "2026-04-04T20:58:56.694382+00:00"
},
"linked_plan_count": 1,
"linked_plans": [
{
"id": "a29dcda7-dcac-4a12-924f-4b208b81e316",
"name": "Rust Fast Path and Interface Parity Delivery Plan",
"status": "completed",
"project_id": "126c521f-bf6b-41dc-ae19-96b2cf00b5f0",
"goal_id": "b4b9be07-8dc2-43e1-b408-6e2eb222d18e",
"objective_id": null,
"updated_at": "2026-04-04T21:38:07.266778+00:00",
"links": {
"self": "uv run pms plan show a29dcda7-dcac-4a12-924f-4b208b81e316",
"lineage": "uv run pms plan lineage --plan-id a29dcda7-dcac-4a12-924f-4b208b81e316 --format json"
}
}
],
"links": {
"self": "uv run pms task show 733d5f29-6bbc-46ad-8b81-e089cc2c442a",
"project": "uv run pms project show 126c521f-bf6b-41dc-ae19-96b2cf00b5f0 --format json",
"parent": null,
"subtasks": "uv run pms task tree --project 126c521f-bf6b-41dc-ae19-96b2cf00b5f0 --root-task-id 733d5f29-6bbc-46ad-8b81-e089cc2c442a --format json",
"timeline": "uv run pms task timeline 733d5f29-6bbc-46ad-8b81-e089cc2c442a",
"graph": "uv run pms task graph 733d5f29-6bbc-46ad-8b81-e089cc2c442a",
"evidence": "uv run pms task evidence list 733d5f29-6bbc-46ad-8b81-e089cc2c442a",
"progress": "uv run pms task progress 733d5f29-6bbc-46ad-8b81-e089cc2c442a <percent> <message> --by <id>",
"plans": "uv run pms plan list --task-id 733d5f29-6bbc-46ad-8b81-e089cc2c442a --format json",
"actor": null,
"checkout_actor": null
},
"next_steps": [
"uv run pms plan list --task-id 733d5f29-6bbc-46ad-8b81-e089cc2c442a --format json",
"uv run pms project show 126c521f-bf6b-41dc-ae19-96b2cf00b5f0 --format json",
"uv run pms task tree --project 126c521f-bf6b-41dc-ae19-96b2cf00b5f0 --root-task-id 733d5f29-6bbc-46ad-8b81-e089cc2c442a --format json",
"uv run pms task timeline \"Auto-surface newly unblocked dependents in task completion output and planning views\" --project \"Rust Fast Path and Interface Parity\"",
"uv run pms task progress \"Auto-surface newly unblocked dependents in task completion output and planning views\" --project \"Rust Fast Path and Interface Parity\" <percent> <message> --by <user>",
"uv run pms task evidence list \"Auto-surface newly unblocked dependents in task completion output and planning views\" --project \"Rust Fast Path and Interface Parity\""
],
"cli": {
"canonical_prefix": "uv run pms",
"alternate_prefix": null
}
}You can see here every entity inside pms has it own uuid which can be directly mapped into a full graph of relations between all other entities in the project management system. The agents are better at understanding and tracking these than you are.
another random plan view
$ uv run pms plan show 1859bf82-9d71-4f6b-92d3-29b209026a3c --project "Quickstart Project"
Quickstart Project Plan
Status: archived
Format: json
Last Activity: 26d ago (2026-04-24T19:22Z)
Last Transition: 26d ago (2026-04-24T19:22Z)
Description: Quickstart plan
Project: Quickstart Project (d94ab618-6931-4f55-b070-b873b82f5f16)
Tasks (3):
Summary: cancelled 3
- Define scope (cancelled) 71093f38
- Build MVP (cancelled) 5a667baf
- Review and iterate (cancelled) 989f73d2
Execution State: plan is already archived
This plan is terminal. Inspect lineage, linked tasks, project state, or goal state instead of treating the plan as active work.
Content:
{
"summary": "Starter plan generated by quickstart.",
"tasks": [
"Define scope",
"Build MVP",
"Review and iterate"
]
}
Next:
- uv run pms plan lineage --plan "Quickstart Project Plan" --project "Quickstart Project"
- uv run pms task list --project "Quickstart Project"
- uv run pms project show "Quickstart Project" --format jsonConclusion
i dunno, just go do stuff.
also, below, here’s a post-conclusion slop-article from codex about pms too.
free for a limited time only i didn’t even read anything below this line (limited time may not apply in all regions).
PMS: The Work Graph I Wanted For Humans, Agents, And The Messy Middle
I have been building a project management system called PMS.
The name is boring in the way a good shell command is boring. It is short, easy to type, and does not try to sell you a lifestyle. The system itself is much more opinionated: PMS is a local-first project and execution graph for humans, AI agents, scripts, dashboards, HTTP clients, and MCP tools that all need to coordinate around the same work without inventing five competing versions of truth.
This came out of a very real annoyance. Modern software work is scattered across conversation history, terminal state, issue trackers, TODO files, CI logs, pull requests, scratch notes, and whatever an AI assistant happened to remember in the current session. That is fine for a few minutes. It gets brittle the moment you want continuity.
I wanted a system where a person could sit down and ask:
uv run pms startand get a useful answer to “where am I, what is active, what should I inspect, and what can I do next?”
I also wanted an agent to ask the same question:
uv run pms start --format jsonand get a structured control surface with live state, a focus task, links, graph navigation, actor rollups, scenario pointers, and next steps it can actually follow.
That is the center of PMS: the system should help you regain context, continue work, prove what happened, and make the next useful action visible.
The Shape Of The System
PMS models project work as a graph.
There is a structural graph:
organization -> portfolio -> program -> product -> projectThere is a strategy graph:
goal -> objective -> key resultThere is an execution graph:
plan -> task -> subtask
task -> dependency -> dependentThere is an identity graph:
actor -> alias
actor -> membership
actor -> assignment
actor -> checkoutAnd there is a proof/review graph:
task -> evidence
task -> test run
task -> proof bundle
scope -> work snapshot
scope -> review checkpointThe important design choice is that these pieces are connected. A task carries more than a title and status. It can belong to a project, link back to a plan, carry workflow state, block another task, belong to an actor, be checked out by a runtime agent, collect progress updates, attach test evidence, and show up in a daily review.
That sounds big because real work is big. The usability goal is to keep the first touch small anyway.
The First Good Moment:
pms start
The command that best shows the shape of PMS is:
uv run pms startThat command creates no state. It reads the current workspace and gives you a start -> go -> observe map.
It answers questions like:
- is this workspace empty?
- are there active projects?
- is anything ready to start?
- is anything already in progress?
- is there a task that should be the current focus?
- which dashboard, queue, daily review, or scenario should I use next?
- is the local runtime coordinated through a server or writing directly?
For humans, the text view is meant to be a fast orientation surface.
For agents, the JSON view exposes fields such as
live_state, focus_task,
graph_navigation, links,
next_steps, actor_rollups, and
runtime.coordination.
That is a usability pattern repeated all over the project: do not make the user memorize the whole command tree before the system becomes helpful. Give them a good next action, and give machines a stable structure for following it.
Relevant code and docs:
pms/cli/app.pyimplementsstartdocs/IMMEDIATE_START_GO.mddocuments the operator pathdocs/MACHINE_INTERFACE_GUIDE.mddocuments the machine contract
Quickstart That Leaves You Somewhere Useful
An empty project system is awkward. You install it, run a version command, and then stare at a blank database.
PMS has a quickstart path for that:
uv run pms quickstart --defaults --format jsonThat creates a real starter graph:
- organization
- portfolio
- program
- product
- project
- starter tasks
- starter plan
- links back into
start,dashboard,task list, andwork daily
It is intentionally reusable. If you run quickstart again with the same default shape, it reuses the generated starter tasks and plan so your workspace does not fill up with duplicate tutorial junk.
The first-run path is also scriptable:
./scripts/run_demo_smoke.shThat isolated smoke run initializes PMS, creates starter state, starts and progresses a task, completes it, exports a daily summary, and generates a capability inventory.
Design Goals
PMS has grown a lot of features, but the design goals are fairly compact.
1. Preserve Continuity
Agent sessions end. Humans take breaks. Shells close. Terminals scroll away.
PMS treats continuity as a core feature. Progress updates, transitions, evidence, revisions, comments, watches, test runs, and review checkpoints are stored as durable project state.
The goal is that tomorrow’s operator, whether human or agent, can recover the state of the work from PMS without reconstructing it from memory.
2. Prefer Control Surfaces Over Raw CRUD
PMS has plenty of create/list/update commands, but the more interesting surfaces are control surfaces:
startdashboardqueue presetswork dailywork reviewwork graph-reportgoal summarytask show --include-linked
These commands answer operational questions. What changed? What is blocked? What is ready? What needs proof? What should happen next?
3. Make Human And Machine Use Meet In The Same Model
Text/table output is for humans. JSON output is for agents, scripts, and API clients. Both should describe the same underlying graph.
That is why PMS response payloads include fields like:
linksnext_stepsparamspagefocus_taskgraph_navigationpopulation_basisvisible_totalsactor_rollupsruntime_write
A human can scan the table. A tool can follow the continuation fields.
4. Treat Proof As Part Of Execution
PMS separates “I changed the status” from “I can show what happened.”
Tasks can collect evidence:
uv run pms task evidence add "Run smoke tests" \
log \
logs/smoke.txt \
--project "Gateway Launch" \
--description "Latest smoke run output"Test runs can be linked to projects, plans, and tasks. Proof bundles collect task evidence and test run summaries into one inspectable payload. Work snapshots and daily reviews surface evidence deltas so review is part of the normal loop.
This matters a lot for agentic work. An agent saying “done” is cheap. A task with evidence, test runs, lineage, and review state is much easier to trust.
5. Keep Runtime Truth Visible
PMS can run local-first with direct SQLite writes. It can also run through a managed local FastAPI server so multiple shells, clients, or agents coordinate through one warm writer.
The user should never have to guess which path was used. Mutating
JSON outputs include runtime_write, and text output
includes a write-path line.
The related workflow is:
uv run pms runtime prefer-server --host 127.0.0.1 --port 8765
uv run pms runtime status --format jsonFor repeated reads, the repo also includes a Rust client:
./scripts/install_pms_client.sh
export PMS_API_KEY="$(cat .pms-admin-key)"
./.bin/pms-client --server http://127.0.0.1:8765 start --format jsonThe design target is practical: keep single-user local usage simple, but make multi-process coordination explicit when you need it.
Data Structure Goals
The data model is trying to avoid two common traps:
- flattening everything into tasks until the system cannot explain strategy
- hiding important relationships inside arbitrary JSON blobs
PMS still uses JSON where JSON is the right shape: plan content, metadata, automation payloads, artifact lists, tags, and extension-friendly fields.
For authoritative graph relationships, the schema increasingly uses
native tables and foreign keys. Examples visible in
pms/db/schema.sql include:
organization_membersteam_membersplan_tasksplan_test_job_tasksportfolio_goalsportfolio_objectivesprogram_goalsprogram_objectivestask_dependenciestask_evidencetask_progress_updatestask_state_transitionsactor_membershipsactor_aliases
This gives PMS better traversal, better rollups, and fewer mystery arrays. When a relationship is truly part of the work graph, it should have one authoritative source.
The schema also uses constraints for values that really are closed vocabularies: task status, priority, actor kind, project status, goal horizon, plan format, workflow booleans, progress percentage bounds, JSON validity, and other storage-level invariants.
The database also has first-class tables for events, revisions, snapshots, and metrics. Those are easy to overlook, but they are part of the usability story: if the system is going to help agents and humans resume work later, it needs history and activity state that can be queried directly.
At the same time, PMS keeps extension-facing values open where freezing them would make the system less useful. Workflow state names, some evidence types, plugin-facing labels, and other intentionally open surfaces are governed by docs and service logic rather than over-eager database enums.
The governing idea is simple: strict where correctness depends on it, flexible where extension depends on it, explicit either way.
Useful references:
docs/ARCHITECTURE.mddocs/VOCABULARY_GOVERNANCE.mddocs/ID_CONTRACT_ARCHITECTURE.mdpms/db/schema.sqlpms/models/
Architecture In The Repo
The current Python package is organized in layers:
| Path | Role |
|---|---|
pms/models/ |
Domain objects such as projects, tasks, actors, plans, goals, evidence, queues, and workflows |
pms/repositories/ |
Persistence/query layer over SQLite or PostgreSQL |
pms/services/ |
Business logic, graph math, lifecycle reconciliation, proof, snapshots, queues, actors, and validation |
pms/db/ |
Schema, connection handling, backend selection, migrations/bootstrap |
pms/core/ |
Events, metrics, revisions, ID/namespace utilities, registries, state-machine support |
pms/cli/ |
Click/Rich terminal interface and JSON response shaping |
pms/api/ |
FastAPI app, routes, auth, typed request/response models |
pms/tools/ |
MCP tool registry and server factory |
pms/runtime/ |
Managed local server and write-coordination behavior |
pms/client/ |
Python HTTP client helpers |
client-rust/ |
Compiled Rust client for low-latency server-backed reads |
scripts/ |
Scenario runners, audits, generators, release gates, contract smokes |
tests/ |
Unit, API, service, integration, MCP, parity, and scenario coverage |
The service layer is where most of the system behavior lives. For example:
pms/services/task_service.pyhandles task lifecycle, dependencies, progress, duplicate previews, execution locks, and reconciliation of linked plans/goals.pms/services/work_daily_service.pybuilds daily review summaries with snapshots, queues, evidence deltas, test runs, timelines, links, and next steps.pms/services/work_snapshot_service.pybuilds scope-level rollups and review digests.pms/services/proof_bundle_service.pycollects task evidence and test runs into proof bundles.pms/services/actor_service.pyresolves actors, aliases, memberships, workload rollups, and checkout identity.
The interface layer deliberately fans out:
- CLI for direct human/operator use
- HTTP API for services, dashboards, and multi-process integrations
- MCP tools for agent runtimes
- Rust client for fast repeated server reads
- scenario scripts for runnable demonstrations and contract validation
That spread is part of the product. PMS is meant to be operated by different kinds of callers while preserving one underlying work graph.
Interface Surfaces
CLI
The CLI is the main operator surface:
uv run pms start
uv run pms dashboard
uv run pms task ready
uv run pms work daily --scope-type project --scope "Gateway Launch"Most important surfaces also support JSON:
uv run pms dashboard --format json
uv run pms task show <task-id> --include-linked --format json
uv run pms work graph-report --scope-type project --scope-id <project-id> --format jsonHTTP API
The FastAPI server exposes the same system for service and multi-process use:
uv run pms serve
uv run pms auth init --show-keyUseful API entry points include:
GET /api/v1/health
GET /api/v1/discoverability/graph
GET /api/v1/observability/overview
GET /api/v1/dashboard
GET /api/v1/work-snapshots/{scope_type}/{scope_id}
GET /api/v1/tasks/{task_id}
GET /api/v1/plans?task_id={task_id}The root API payload includes discoverability links, scenario hints, and recommended entry points, so clients do not have to begin by hardcoding a private route map.
MCP
PMS ships an MCP server factory in
pms/tools/server.py.
The MCP surface includes project, task, goal, objective, key result, plan, organization, team, portfolio, program, queue, work snapshot, custom field, comment, watcher, automation, evidence gate, test run, checkout, workflow, and proof-bundle tools.
Core tools can be loaded eagerly while extended tools are marked for deferred loading. That matters for agent ergonomics: an agent can start with common project/task actions and discover deeper tools when it needs them.
Dashboard
The dashboard is intentionally an operator console. It focuses on:
- project overview
- observability
- work snapshots
- plan -> task -> test lineage
- smart queues
- retention/storage health
It is read-only and API-backed. The goal is focused review and inspection.
Scenario Scripts
The real-world scenario scripts are the most approachable way to feel the system quickly:
./scripts/run_dropin_start_go_extend_grow.sh
./scripts/run_team_handoff_flow.sh
./scripts/run_incident_response_flow.sh
./scripts/run_user_start_go_observe_flow.sh
./scripts/run_operational_review_flow.sh
./scripts/run_backlog_triage_flow.sh
./scripts/run_portfolio_steering_flow.sh
./scripts/run_agent_execution_loop_flow.sh
./scripts/run_release_readiness_flow.shEach maintained scenario writes artifacts under
PMS_DATA_DIR, emits a machine-readable summary JSON file,
and has a matching contract smoke script.
This is one of my favorite parts of the repo. The examples are executable product stories.
Usability Patterns I Care About
Progressive Depth
You can start with:
uv run pms startThen move to:
uv run pms quickstart --defaults
uv run pms task ready
uv run pms dashboardThen later use:
uv run pms task show <task-id> --include-linked --format json
uv run pms work graph-report --scope-type project --scope-id <project-id> --format jsonThe system gets deeper as your need gets deeper.
Actionable Readbacks
Many surfaces return next_steps. That small field
changes how the system feels. It means PMS can give a caller a runnable
continuation alongside the static record.
For humans, this reduces command lookup. For agents, it reduces brittle prompt logic.
Population Truth
Rollups are easy to misuse. Does this count include archived projects? Hidden fixture state? Project-scoped tasks? Organization-visible tasks? Direct actor assignments only, or inherited persona/team work too?
PMS uses fields such as population_basis,
visible_totals, scope, and params
so readers can understand what a number means.
This is boring in the best possible way. Ambiguous dashboards are dangerous.
Actor-Native Identity
PMS has a first-class Actor model for humans, personas,
teams, service accounts, and runtime agents.
That lets the system distinguish:
- who owns the work
- who is assigned the work
- who is actively executing it
- who inherits it through membership or persona representation
Example:
uv run pms actor create "Release Bot" --kind runtime_agent --handle release-bot --format json
uv run pms actor create "QA Persona" --kind persona --handle qa-persona --format json
uv run pms actor membership add qa-persona release-bot --role representative --format json
uv run pms task list --mine --format jsonThis makes “my work” more useful than a flat assignee string.
Review Is A First-Class Workflow
Daily review has its own workflow:
uv run pms work daily \
--scope-type project \
--scope "Gateway Launch" \
--format jsonThat summary can include snapshot totals, queue summaries, recent test runs, evidence deltas, blockers, next actions, transition timeline, and review history.
You can also mark a review checkpoint:
uv run pms work review \
--scope-type project \
--scope "Gateway Launch" \
--reviewed-by matt \
--note "Weekly review" \
--format jsonNow the next digest can tell you what changed since the last review.
Agent Loops With Audit Artifacts
PMS includes maintained patterns for agent harnesses:
uv run pms start --format json
uv run pms dashboard --format json
uv run pms task ready --format json
uv run pms work daily --scope-type project --scope "<project>" --format json --no-attach
uv run pms goal summary "<goal>" --format jsonThere is also a stop-audit helper:
python3 scripts/agent_hooks/pms_stop_audit.py \
--project "Resume Hosting Site" \
--goal "Launch resume hosting MVP"That writes a deterministic bundle under
PMS_DATA_DIR/hook-audits/ with start,
dashboard, task-ready, scoped task list, daily
review, and goal summary JSON.
That bundle is a practical answer to “what did the agent see when it stopped?”
Practical Examples
Example 1: Run The Fast Demo
./scripts/run_demo_smoke.shUse this when you want the shortest path from checkout to real artifacts.
Example 2: Ask The Workspace What To Do
uv run pms start --format jsonLook for:
live_statefocus_taskgraph_navigationobservability_pathsscenario_pathsnext_steps
Example 3: Create A Manual Project Graph
uv run pms project create "Gateway Launch" \
-d "Release control for the public API launch" \
--format json
uv run pms goal create "Ship Gateway v1" \
--project "Gateway Launch" \
--horizon short_term \
--owner matt \
--format json
uv run pms objective create "Stabilize launch flow" \
--goal "Ship Gateway v1" \
--owner matt \
--format json
uv run pms keyresult create "Launch checklist completion" \
--objective "Stabilize launch flow" \
--current 0 \
--target 100 \
--unit percent \
--owner matt \
--format jsonExample 4: Move Work And Attach Proof
uv run pms task add "Gateway Launch" "Run smoke tests" \
--assigned-to qa-persona \
-p high \
--format json
uv run pms task start "Run smoke tests" --project "Gateway Launch" --by matt
uv run pms task progress "Run smoke tests" --project "Gateway Launch" 50 "Smoke run started" --by matt
uv run pms task evidence add "Run smoke tests" \
log \
logs/smoke.txt \
--project "Gateway Launch" \
--description "Latest smoke run output"Example 5: Inspect The Graph Instead Of A Flat List
uv run pms task show "Run smoke tests" \
--project "Gateway Launch" \
--include-linked \
--format json
uv run pms work graph-report \
--scope-type project \
--scope "Gateway Launch" \
--format jsonThis is the path I want agents to use: follow IDs, links, and graph navigation rather than scraping terminal prose.
Real-World Usage Scenarios
The scenario pack is where PMS becomes more concrete.
Drop In -> Start -> Go -> Extend -> Grow
./scripts/run_dropin_start_go_extend_grow.shThis starts from an isolated workspace, bootstraps a project, executes a task, adds custom fields, comments, watchers, automation, queues, reports, plugin scaffolding, and loop setup.
It is the best “show me the platform shape” scenario.
Incident Response
./scripts/run_incident_response_flow.shThis models triage, mitigation, comms, and postmortem work. It uses actors, custom fields, comments, watchers, automation, queues, daily review, reports, history, and metrics.
It is a good example of PMS as an operations memory system.
Release Readiness
./scripts/run_release_readiness_flow.shThis models launch control: release notes, smoke validation, go/no-go approval, test-server registration, recorded test runs, task progress, custom fields, automation, queues, daily review, project report, and metrics.
It is a good proof-and-review example.
Agent Execution Loop
./scripts/run_agent_execution_loop_flow.shThis creates a project/goal/objective/plan/task set, generates a loop config and prompt from live PMS state, runs a deterministic command adapter, records loop messages, attaches proof artifacts, records a test run, builds a proof bundle, and closes the task path.
It is the clearest “agents can operate inside the same work graph” scenario.
Validation And Release Discipline
The repo has a large audit layer because the public surface is broad.
Useful scripts include:
./scripts/run_audit_checks.sh --list-stages
./scripts/run_audit_checks.sh all-preflight
./scripts/run_public_release_gate.shThe audit stages cover docs, parity, scenario contract smokes, discoverability, runtime guards, surface contracts, lifecycle rollups, Rust client parity, graph report truth, actor workload math, service transaction boundaries, and more.
Generated references are also part of the release story:
docs/CAPABILITIES_REFERENCE.mddocs/API_ENDPOINT_CATALOG.mddocs/API_RESPONSE_CONTRACTS.md
The current generated capability reference is broad by design: it covers namespaces, tools, patterns, events, reference types, knowledge types, and feedback categories. That self-description matters because agents should be able to discover the system rather than relying on a hand-maintained prompt that slowly falls out of date.
That matters because a tool with CLI, API, MCP, dashboard, Python client, and Rust client surfaces can drift unless the repo actively checks those surfaces against each other.
Where To Look In The Repo
Start here:
README.mdGETTING_STARTED.mddocs/DOCUMENTATION_MAP.mddocs/IMMEDIATE_START_GO.mdexamples/real_world/README.md
For architecture and contracts:
docs/ARCHITECTURE.mddocs/MACHINE_INTERFACE_GUIDE.mddocs/END_TO_END_WORKFLOWS.mddocs/WRITE_COORDINATION_ARCHITECTURE.mddocs/ACTOR_IDENTITY_PERSONA_GRAPH_ARCHITECTURE.mddocs/VOCABULARY_GOVERNANCE.mddocs/OUTPUT_CONTRACTS.md
For implementation:
pms/cli/app.pypms/api/app.pypms/api/routes/pms/tools/server.pypms/tools/project_tools.pypms/services/task_service.pypms/services/work_daily_service.pypms/services/work_snapshot_service.pypms/services/proof_bundle_service.pypms/services/actor_service.pypms/runtime/write_coordination.pypms/db/schema.sqlclient-rust/README.md
For runnable examples:
scripts/run_demo_smoke.shscripts/run_dropin_start_go_extend_grow.shscripts/run_incident_response_flow.shscripts/run_release_readiness_flow.shscripts/run_agent_execution_loop_flow.sh
The Part I Am Most Proud Of
The thing I like most about PMS is that it tries to make serious coordination feel recoverable.
You can leave and come back. An agent can stop and another process can inspect what it saw. A task can carry evidence. A review can have a baseline. A graph export can explain how strategy, execution, actors, and proof relate. A command can tell you what to do next.
That is the product bet here: good project infrastructure should reduce the cost of returning to context.
For humans, that means fewer “what was I doing?” moments.
For agents, that means less fake memory and more durable state.
For teams, it means execution, evidence, and review can live in one inspectable system.
PMS is still a builder’s tool. It is broad, a little intense, and deliberately local-first. But it is already useful in the way I wanted: I can point a human, a script, or an agent at the same repo and the same work graph, and they can all ask the system where to go next.