Autonomous PM Front-End

The autonomous PM front-end lets an automation Level 4 run start from a vision doc alone and manufacture an approved work queue — driving /business-case → /capability → /requirement → /groom — so warp-drive discovery has req+approved work to consume, with no human authoring of requirements. It is part of the Level 4 capability (#865) and realizes use case #863.

Reuse before build. The semantic authoring — which business case, which capabilities, which requirements and their acceptance criteria — is the job of the existing PM command skills, invoked by the agent following the orchestration command. The backbone script here is the deterministic scaffolding around that judgement: the same split the swarm lead uses in scripts/swarm/decompose.js. It never re-derives queue membership (that is discover-queue.sh, the single source of the approved queue) and never re-implements the todo format (that is todo-contract.js; see the TODO Format Contract).

Backbone CLI — scripts/warp-drive/pm-frontend.js

Zero-dependency Node (built-ins only). CLI plus a library API used by the tests.

Sub-command	Purpose	Exit codes
check-vision [--root DIR] [--path FILE] [--json]	Verify a usable vision doc exists (the vision-only-start precondition). Fails closed on a missing, thin, or unframed doc so a run never manufactures a queue from an empty vision.	0 usable · 1 not usable
scaffold [--root DIR] [--path FILE] [--json]	Emit the ordered PM plan the agent follows — the /business-case → /capability → /requirement → /groom chain, each step naming the reused skill (never reimplemented) plus a grounded digest of the vision.	0 · 1 no vision
verify-queue [--area SLUG] [--from-json FILE] [--json]	The result gate: assert the produced queue is non-empty, consumable unchanged by warp-drive discovery, and that every requirement meets /groom readiness.	0 consumable · 1 not consumable · 2 tooling error
emit-todo --title T --summary S --instructions "a;b" [--blocks NN] [--priority P] [--dry-run]	Hand a human-only blocker back as a contract-conforming todo (validated by todo-contract.js). Ties to the #878 pre-flight.	0 · 1 non-conforming · 2 usage

The queue gate (verify-queue)

The gate is the deterministic guarantee behind AC-2 and AC-4. It shells out to discover-queue.sh — the single source of the approved queue — so the membership and ordering rule lives in exactly one place, then layers /groom readiness on top. A queue passes only when:

• it is non-empty (a vision that decomposes to nothing is a failure), and
• every item is consumable unchanged by warp-drive discovery (req/bug + approved, guaranteed by discover-queue.sh on both its fetch paths since #1794 — the approved half of the rule used to be enforced only in the gh call's --label, which left the offline path below ungated), and
• every requirement meets /groom readiness: a priority label (p1-critical … p4-low), no blocked or needs-clarification label (no unresolved collisions), and at least one testable acceptance-criterion checkbox. Bugs are exempt from the checkbox rule (a bug's definition of done is a regression test) but must still be prioritised and unblocked.

Offline, --from-json FILE pipes a pre-fetched issue array through the same discover-queue.sh path, so tests exercise the real oracle without gh — and apply the identical gate, approved included. Supplying the rows chooses the fetch, never the filter. Neither call site passes --allow-unapproved: the front-end's whole job is to prove the gate held.

Testing

make test-pm-frontend runs tests/test-pm-frontend.js — unit tests over the exported functions plus CLI-contract tests that drive the gate end-to-end against the real discover-queue.sh via its --from-json offline mode. Deterministic and dependency-free (no gh, no Claude), safe for CI.

See also

• Warp-Drive State Reference — the loop that consumes the manufactured queue.
• TODO Format Contract — the contract emit-todo conforms to.