godpowers 2.1.1 → 2.2.0

package/CHANGELOG.md

@@ -7,6 +7,49 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [2.2.0] - 2026-05-30
+
+### Added
+- Deliverable progress tracking, so a project run always communicates which
+  requirements are finished, which are in flight, and which are untouched:
+  - `/god-progress` reports requirement and roadmap-increment status (done / in
+    progress / not started, grouped by increment and priority) and refreshes a
+    human-readable `.godpowers/REQUIREMENTS.md` checklist the user can open or
+    share.
+  - Status is derived from disk by `lib/requirements.js` (PRD requirements +
+    ROADMAP increments + the linkage map + build state), so it cannot drift from
+    what is actually implemented.
+  - The Godpowers Dashboard (`/god-status`, `/god-next`, `/god-mode` closeout)
+    gains a `Deliverable progress` section, and `/god-mode` build steps report
+    requirement completion as it happens.
+  - PRD functional requirements now carry stable ids (`P-MUST-NN` /
+    `P-SHOULD-NN` / `P-COULD-NN`) and ROADMAP delivery increments carry
+    `M-slug` ids with a per-increment `Status` and the requirement ids they
+    deliver, so requirements map to increments and to implementing code.
+  - `reverse-sync` and `/god-sync` refresh the ledger and cache the summary in
+    `state.json.deliverables` whenever the linkage map changes.
+- A `whats-done` intent recipe so phrases like "how far along are we" and
+  "what's done" route to `/god-progress`.
+- A reconstructed self-ledger for Godpowers itself (`.godpowers/prd/PRD.md`,
+  `.godpowers/roadmap/ROADMAP.md`, `.godpowers/REQUIREMENTS.md`) via
+  `scripts/reconstruct-self-ledger.js`, so the project dogfoods its own
+  deliverable tracking.
+- `deliverable-progress-tracking` registered in the feature-awareness set so
+  existing projects learn about `/god-progress` on the next refresh.
+
+### Changed
+- Build agents thread requirement ids end to end: `god-planner` names the
+  requirement ids each slice delivers and `god-executor` stamps
+  `// Implements: P-...` annotations into code, which the reviewers now verify,
+  so the linkage map (and therefore the ledger) populates during real builds.
+- Sibling agents that produce or consume the PRD and ROADMAP
+  (`god-reconstructor`, `god-roadmap-updater`, `god-roadmap-reconciler`,
+  `god-greenfieldifier`, and others) now preserve stable requirement and
+  increment ids and refresh the ledger.
+- Reconciled documentation surface counts and version references to v2.2.0
+  (111 slash commands, 41 recipes) and added `/god-progress` and
+  `REQUIREMENTS.md` to command lists, artifact inventories, and the linkage doc.
+
 ## [2.1.1] - 2026-05-30
 
 ### Changed

package/README.md

@@ -2,7 +2,7 @@
 
 [![CI](https://github.com/aihxp/godpowers/actions/workflows/ci.yml/badge.svg)](https://github.com/aihxp/godpowers/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
-[![Version](https://img.shields.io/badge/version-2.1.1-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-2.2.0-blue)](CHANGELOG.md)
 [![npm](https://img.shields.io/npm/v/godpowers.svg)](https://www.npmjs.com/package/godpowers)
 
 **Ship fast. Ship right. Ship everything. Ship accountably.**
@@ -21,7 +21,7 @@ Godpowers makes AI coding accountable: every serious run should leave disk
 state, artifacts, validation gates, host guarantees, and a next action. Code is
 only one output. The project memory and proof trail matter too.
 
-Version 2.1.1 keeps the proof loop executable. `npx godpowers quick-proof
+Version 2.2.0 keeps the proof loop executable. `npx godpowers quick-proof
 --project=.` now renders a shipped fixture with real `.godpowers/state.json`,
 computed next action, missing-artifact visibility, and host guarantees. The
 2.0 line also ships a proof transcript, adoption canary harness, published npm
@@ -236,6 +236,7 @@ extension files, with parser coverage in `scripts/test-yaml-parser.js`.
 | `/god-launch` | Launch (gated on harden) | god-launch-strategist |
 | `/god-harden` | Adversarial security review | god-harden-auditor |
 | `/god-status` | Re-derive state from disk | (built-in) |
+| `/god-progress` | Deliverable progress: requirements and increments done / in progress / left | (built-in) |
 | `/god-automation-status` | Show host automation provider support | (built-in) |
 | `/god-automation-setup` | Prepare opt-in automation setup | (built-in) |
 | `/god-dogfood` | Run messy-repo dogfood scenarios for release and autonomy readiness | (built-in) |
@@ -304,6 +305,15 @@ ends in a vague "done" state. The dashboard is backed by
 engine is available. Audit, hygiene, and remediation scores are reported as
 separate scores rather than being reused as workflow progress.
 
+That dashboard reports **workflow progress** (which pipeline stage you are on).
+For **deliverable progress** (how much of the actual product is built), run
+`/god-progress`: it lists every PRD requirement as done, in progress, or not
+started, groups them by roadmap increment, and writes a `.godpowers/REQUIREMENTS.md`
+checklist you can open or share. Status is derived from the linkage map (code
+that implements each requirement), so it can never drift from what is actually
+on disk. The dashboard also surfaces a `Deliverable progress` line, and during a
+`/god-mode` build each step reports how many requirements moved to done.
+
 Godpowers can also inspect automation support:
 
 ```bash
@@ -386,6 +396,7 @@ Skill updates:   PROGRESS.md
 
 ```
 .godpowers/PROGRESS.md         Cross-tier progress ledger
+.godpowers/REQUIREMENTS.md     Requirement checklist (done / in progress / not started)
 .godpowers/prd/PRD.md          Product Requirements Document
 .godpowers/domain/GLOSSARY.md  Domain vocabulary and resolved ambiguities
 .godpowers/arch/ARCH.md        System Architecture
@@ -474,7 +485,7 @@ Pi. T3 Code inherits from the underlying agent (Codex / Claude / OpenCode).
 - [Getting Started](docs/getting-started.md)
 - [Quick Proof](docs/quick-proof.md)
 - [Concepts](docs/concepts.md)
-- [Command reference (all 110 skills + 40 agents)](docs/reference.md)
+- [Command reference (all 111 skills + 40 agents)](docs/reference.md)
 - [Feature awareness](docs/feature-awareness.md)
 - [Adoption Canary](docs/adoption-canary.md)
 - [Repository documentation sync](docs/repo-doc-sync.md)

package/RELEASE.md

@@ -1,59 +1,55 @@
-# Godpowers 2.1.1 Release
+# Godpowers 2.2.0 Release
 
-Date: 2026-05-30
+> Status: Ready for release
+> Date: 2026-05-30
 
-Godpowers 2.1.1 is a documentation and off-switch safety patch on top of the
-2.1.0 security release. The public slash-command surface, runtime behavior, and
-artifact layout are unchanged except for one safety improvement to the context
-off-switch.
+Godpowers 2.2.0 adds deliverable progress tracking on top of the 2.1.1
+documentation and off-switch safety patch. It keeps the public slash-command
+surface stable and backward compatible.
 
-## What is stable
+## What's in this release
 
-- 110 slash commands
+- 111 slash commands
 - 40 specialist agents
 - 13 executable workflows
-- 40 intent recipes
-- 15-runtime installer
-- Codex installs with generated `god-*.toml` agent metadata files
-- Shared runtime bundle at `<runtime>/godpowers-runtime`
-- Native Pillars project context through `AGENTS.md` and `agents/*.md`
-- `.godpowers/` workflow state and artifact layout
-- `godpowers status --project .`, `godpowers next --project .`, and
-  `godpowers quick-proof --project .`
-- Release gate enforcement through `npm run release:check`
-- The 2.1.0 security hardening (argv-only browser exec, corrupt-file parse
-  guards, clean-replace installs, prototype-pollution guards)
-
-## What is new
-
-- The context off-switch now empties the canonical `AGENTS.md` instead of
-  deleting it; auto-generated pointer files (`CLAUDE.md`, `.cursorrules`, etc.)
-  are still removed when only the Godpowers fence remains.
-- Documentation reconciliation: removed unverifiable external impeccable
-  rule/finding counts; aligned the project-mode taxonomy with the runtime
-  (A/B/C/E primary modes, with D as the orthogonal multi-repo suite overlay);
-  documented every `lib/` module; and clarified how the artifact-category counts
-  relate.
-
-## Guardrails
-
-- The public slash-command surface remains frozen.
-- The runtime remains dependency-free.
-- `bin/install.js` stays a thin CLI entry point and delegates install behavior
-  to `lib/installer-core.js`.
+- 41 intent recipes
+
+## Highlights
+
+- Deliverable progress tracking: the new `/god-progress` command and the
+  `.godpowers/REQUIREMENTS.md` ledger report which PRD requirements and roadmap
+  increments are done, in progress, or not started. Status is derived from the
+  linkage map by `lib/requirements.js`, so it cannot drift from the code that is
+  actually implemented.
+- Stable requirement and increment ids: PRD requirements carry
+  `P-MUST-NN`/`P-SHOULD-NN`/`P-COULD-NN`, and ROADMAP increments carry `M-slug`
+  ids with a per-increment `Status` and member requirement ids.
+- The build chain populates the ledger during real runs: `god-planner` names the
+  requirement ids each slice delivers, `god-executor` stamps `// Implements: P-...`
+  annotations, and the spec and quality reviewers verify them.
+- The dashboard (`/god-status`, `/god-next`, `/god-mode` closeout) gains a
+  `Deliverable progress` section, and a `whats-done` recipe routes natural
+  language like "how far along are we" to `/god-progress`.
+- Documentation reconciled with the shipped surface and version: accurate
+  counts and `/god-progress`/`REQUIREMENTS.md` awareness across README,
+  ARCHITECTURE, reference, linkage, recipes, and the artifact inventories.
 
 ## Validation
 
-Release validation includes:
+- `npm test` green across the full suite
+- `npm run lint` clean
+- `npm run release:check` green (tests, audit, package contents)
 
-- `npm test`
-- `npm run test:audit`
-- `npm run pack:check`
-- `npm run release:check`
-- `npm pack --json`
-- local install smoke tests across supported runtime shapes
-- npm publish when registry credentials are available
-- GitHub release creation for `v2.1.1`
+## Upgrade
 
-The `v2.1.1` tag should point to the release commit that matches the npm
-`godpowers@2.1.1` package.
+- `npm install -g godpowers@2.2.0` or `npx godpowers@2.2.0`
+- Re-run `/god-context` in each project to refresh installed runtime metadata
+- No breaking changes; existing `.godpowers/` state is compatible. Projects gain
+  a `REQUIREMENTS.md` ledger the next time `/god-progress` or `/god-sync` runs.
+
+## Notes
+
+- GitHub release creation for `v2.2.0`
+- The tag should match the npm package version
+- The `v2.2.0` tag should point to the release commit that matches the npm
+  `godpowers@2.2.0` package.

package/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: godpowers
-version: 2.1.1
+version: 2.2.0
 description: |
   AI-powered development system that takes a project from raw idea to hardened
   production. Fuses artifact discipline, execution engine, quality enforcement,
@@ -121,8 +121,8 @@ with a disk-derived closeout that tells the user the current state and what is
 next.
 
 Every closeout must include a **Godpowers Dashboard**. This dashboard is the
-same mental model across `/god-status`, `/god-next`, `/god-mode`, and every
-command that completes, pauses, or proposes work.
+same mental model across `/god-status`, `/god-progress`, `/god-next`,
+`/god-mode`, and every command that completes, pauses, or proposes work.
 
 When the runtime bundle is available, compute this with
 `lib/dashboard.compute(projectRoot)` and render it with

package/agents/god-architect.md

@@ -97,6 +97,9 @@ ADRs to `.godpowers/arch/adr/`.
    - Consequences (what this makes easier/harder)
 
 4. **NFR-to-Architecture Map** - every PRD NFR maps to an architectural choice.
+   Where a decision serves a specific PRD functional requirement, reference its
+   id (P-MUST-NN / P-SHOULD-NN / P-COULD-NN) so the rationale traces back to the
+   requirement it supports.
 
 5. **Trust Boundaries** - every external integration has a boundary. Auth/authz
    model documented. Data classification (sensitive vs public).

package/agents/god-executor.md

@@ -44,6 +44,22 @@ For every behavior in this slice:
 2. Run the full test suite
 3. All tests must still pass
 
+## Requirement traceability (load-bearing)
+
+The slice plan lists the PRD requirement ids this slice delivers (its
+`Requirements:` field). Stamp them into the code so the linkage map,
+reverse-sync, and the deliverable ledger (`/god-progress`) can trace each
+requirement to its implementation. Without this, the ledger shows the
+requirement as "not started" even after you ship it.
+
+- Put a `// Implements: P-MUST-01` annotation near the top of the primary
+  file(s) you create or modify for the slice. Use the file's comment syntax
+  (`#`, `/* */`, `<!-- -->`). Combine ids when one file serves several:
+  `// Implements: P-MUST-01, P-MUST-02`.
+- Prefer naming at least one test with the id, e.g.
+  `describe('P-MUST-01: user can sign in', ...)`; the scanner reads these too.
+- Use the exact ids from the slice plan. Do not invent ids.
+
 ## Rules (non-negotiable)
 
 - **Code before test**: VIOLATION. Delete the implementation. Write the test first.
@@ -102,6 +118,7 @@ happen.
   demanded by the slice
 - Drive-by formatting, renaming, refactoring, or dead-code deletion unrelated
   to the slice
+- A requirement id from the slice plan is not annotated in the code (`// Implements: P-...`)
 
 ## Repair Mode
 

package/agents/god-greenfieldifier.md

@@ -101,11 +101,15 @@ canonical artifact loses existing concrete evidence.
 
 When approved, update all affected artifacts, not just the first one:
 
-- PRD: product goals, requirements, metrics, no-gos, open questions.
+- PRD: product goals, requirements, metrics, no-gos, open questions. Preserve or
+  assign stable requirement ids (P-MUST-NN / P-SHOULD-NN / P-COULD-NN); never
+  renumber or reuse a shipped id.
 - DESIGN: product experience, UI surface, accessibility, workflow, brand.
 - PRODUCT: screens, journeys, user promises, operational UX.
 - ARCH: components, trust boundaries, ADRs, NFR mappings.
-- ROADMAP: sequence, gates, dependencies, delivery increments.
+- ROADMAP: sequence, gates, dependencies, delivery increments. Keep increment
+  ids (`M-<slug>`) stable and preserve each increment's `**Status**:` field and
+  `**Features (from PRD)**:` requirement-id list.
 - STACK: decisions, flip points, org constraints, incompatibilities.
 - REPO: repository shape, CI, tests, security docs, install docs.
 - BUILD: build state, test expectations, review gates.
@@ -118,6 +122,10 @@ When approved, update all affected artifacts, not just the first one:
 
 After approved rewrites:
 
+- If the PRD or ROADMAP changed, refresh the deliverable ledger with
+  `lib/requirements.writeLedger(projectRoot)` so `.godpowers/REQUIREMENTS.md`
+  stays consistent with the rewritten ids and any `// Implements:` annotations
+  already in code.
 - Update `.godpowers/SYNC-LOG.md`.
 - Update `.godpowers/PROGRESS.md`.
 - Update `.godpowers/state.json` with:

package/agents/god-launch-strategist.md

@@ -19,6 +19,9 @@ Put the product in front of users.
 If Critical findings are unresolved, REFUSE to proceed and tell orchestrator
 to pause for human resolution.
 
+Confirm all P-MUST requirements show done in `.godpowers/REQUIREMENTS.md` before
+launch.
+
 ## Process
 
 ### 1. Landing Page Copy

package/agents/god-orchestrator.md

@@ -609,6 +609,11 @@ LOOP for this slice:
      - If FAIL: return slice to god-executor with findings, GOTO step 1
      - If PASS: atomic commit
   5. Update .godpowers/build/STATE.md with slice completion
+  6. Refresh deliverable progress: run
+     `lib/requirements.writeLedger(projectRoot)` to update
+     `.godpowers/REQUIREMENTS.md` from the new linkage, then read the new done
+     count so the slice's step-result card can print the requirement line
+     (`Requirements: <done>/<total> done (+<delta> this slice)`).
 END LOOP
 ```
 
@@ -622,6 +627,11 @@ After all waves complete:
 4. If any verification fails, run the autonomous repair loop. Do not mark
    Build done and do not recommend later work while verification is red.
 5. Update PROGRESS.md: Build = done
+6. Refresh `.godpowers/REQUIREMENTS.md` (`lib/requirements.writeLedger`) and
+   cache the summary into `state.json` `deliverables`
+   (`lib/requirements.summarizeForState`). Report final requirement coverage in
+   the Build step-result card, and flag any gaps (a done increment with no
+   linked code) as an open item rather than declaring the build clean.
 
 CRITICAL RULES (build phase):
 - Never skip god-spec-reviewer
@@ -711,6 +721,11 @@ Planning visibility:
   Current milestone: <roadmap milestone, tier, or next planning gate when known>
   Completion basis: <state.json, PROGRESS.md, artifacts, or audit score source>
 
+Deliverable progress:
+  Requirements: <done>/<total> done (<pct>%); <in-progress> in progress, <untouched> not started
+  Increments: <done> done, <building> building, <pending> pending
+  Ledger: .godpowers/REQUIREMENTS.md
+
 What changed:
   1. <highest-signal user-visible change>
   2. <highest-signal user-visible change>
@@ -748,13 +763,14 @@ Project is now in steady state. From here, ongoing work uses these workflows:
 Periodic hygiene:
   Quality audit:          /god-audit
   Health check:           /god-hygiene (combines audit + deps + docs)
+  Deliverable status:     /god-progress (requirements + increments done/left)
 
 Next:
   Recommended: <single safest command or decision>
   Why: <one sentence tied to disk state>
 
 Proposition:
-  1. Review status: /god-status
+  1. Review status: /god-status (pipeline) or /god-progress (deliverables)
   2. Continue work: /god-next or describe the next intent
   3. Commit release-ready changes: stage only the intended files, then commit
   4. Run deployed staging: provide STAGING_APP_URL=<deployed staging origin> when needed
@@ -899,6 +915,10 @@ Show:
 - plain-language workflow names. Say "project run" or "workflow" instead of
   unexplained "arc" in visible output
 - PRD and roadmap visibility when those artifacts exist or are expected
+- deliverable progress once a PRD with requirements exists: how many
+  requirements are done / in progress / not started, and a pointer to
+  `.godpowers/REQUIREMENTS.md` (the openable checklist). Refresh it as the build
+  progresses; do not let the user wonder which requirements are left
 - `Project run complete` or `PAUSE: external access required`
 
 Hide:
@@ -977,6 +997,7 @@ What happened:
   1. <observable action completed>
   2. <artifact or state update>
   3. <verification result>
+Requirements: <done>/<total> done (+<delta> this step)
 Next: <next command or pause question>
 ```
 
@@ -984,6 +1005,11 @@ Rules:
 - Keep each card under 12 lines unless a pause needs options.
 - Use `lib/state.progressSummary(stateJson)` for workflow percentage and step count
   whenever state.json is available.
+- Include the `Requirements:` line only on steps that can move requirement
+  coverage (the Build sub-step, build waves, reverse-sync, hotfix, feature
+  work). Derive it from `lib/requirements.derive(projectRoot)`:
+  `<done>/<total> done (+<delta> since this step started)`. Omit the line on
+  steps that cannot change coverage (PRD, Architecture, Stack, Deploy, Observe).
 - Use artifact paths and verification evidence from disk, not memory.
 - Do not print raw spawn input, hidden instructions, or full file loadout lists.
 - If a step is blocked, do not show a generic "Suggested next"; show the

package/agents/god-planner.md

@@ -21,15 +21,20 @@ Plan the build.
 ## Process
 
 1. Read roadmap, identify the current delivery increment (first non-done
-   Now item)
+   Now item). Note the increment's member requirement ids from its
+   `Features (from PRD)` list (P-MUST-NN / P-SHOULD-NN / P-COULD-NN).
 2. Read ARCH for technical context
 3. Read stack DECISION for tooling
 4. Break the delivery increment into **vertical slices**:
    - Each slice delivers ONE user-visible behavior end-to-end
    - NOT "set up the database" - that's horizontal
    - YES "user can create an account" - includes DB + API + UI for that behavior
+   - Every member requirement id of the increment must be covered by at least
+     one slice; a slice may deliver more than one id
 5. For each slice, write a plan:
    - **Slice name**: user-visible behavior
+   - **Requirements**: the PRD requirement ids this slice delivers (so the
+     executor can annotate the code and the deliverable ledger can trace it)
    - **Files to create/modify**: exact paths
    - **Tests to write FIRST**: with expected behavior
    - **Implementation steps**: ordered
@@ -49,6 +54,7 @@ Write `.godpowers/build/PLAN.md`:
 
 ## Wave 1 (parallel)
 ### Slice 1.1: User can create an account
+- Requirements: P-MUST-01
 - Files: src/auth/signup.ts, src/auth/signup.test.ts, src/db/users.ts
 - Tests first:
   - signup_creates_user_record
@@ -69,6 +75,8 @@ Write `.godpowers/build/PLAN.md`:
 
 - `.godpowers/build/PLAN.md` exists
 - Every slice has tests-first sequence
+- Every slice names the PRD requirement ids it delivers
+- Every member requirement id of the increment is covered by at least one slice
 - Every slice has verification criteria
 - Dependencies are explicit
 - Waves are correctly grouped (no parallel slices share state)

package/agents/god-pm.md

@@ -23,12 +23,33 @@ required sections:
 1. **Problem Statement** (substitution-tested)
 2. **Target Users** (specific personas, not "developers")
 3. **Success Metrics** (with numbers and timelines)
-4. **Functional Requirements** (MUST/SHOULD/COULD with acceptance criteria)
+4. **Functional Requirements** (MUST/SHOULD/COULD with acceptance criteria; each
+   carries a stable id)
 5. **Non-Functional Requirements** (latency, availability, security, scale)
 6. **Scope and No-Gos** (explicit list of what is NOT being built)
 7. **Appetite** (time/resource/technical constraints)
 8. **Open Questions** (with owner and due date)
 
+## Stable requirement ids
+
+Give every functional requirement a stable id, numbered sequentially within its
+priority: `P-MUST-01`, `P-MUST-02`, `P-SHOULD-01`, `P-COULD-01`. Put the id at
+the start of the bullet, before the label:
+
+```
+- P-MUST-01 [DECISION] User can sign in with email and password -- Acceptance: valid credentials return a session token
+```
+
+These ids are load-bearing downstream and you must not skip them:
+- `god-roadmapper` groups them into delivery increments.
+- Code and tests reference them (`// Implements: P-MUST-01`,
+  `describe('P-MUST-01: ...')`), which feeds the linkage map.
+- `/god-progress` and the dashboard derive done / in-progress / not-started
+  status per requirement from those links.
+
+Never renumber or reuse an id once it has shipped; add new ids at the end of the
+priority instead.
+
 ## Imported Preparation Context
 
 Before drafting, compute the Pillars load set for the PRD task with
@@ -90,6 +111,7 @@ Tag sentences inline: `[DECISION]`, `[HYPOTHESIS]`, `[OPEN QUESTION]`
 - Success metric has no number
 - Success metric has no timeline
 - Requirement has no acceptance criteria
+- Any functional requirement has no stable id (P-MUST-NN / P-SHOULD-NN / P-COULD-NN)
 - No-gos section is empty or absent
 - Open question has no owner
 - Open question has no due date

package/agents/god-quality-reviewer.md

@@ -57,6 +57,12 @@ Your job: would you ship this code in production?
 - Any follow-up cleanup is reported separately instead of being smuggled into
   the diff
 
+### 7. Requirement Traceability
+- Code that delivers a planned PRD requirement bears an accurate
+  `// Implements: P-...` annotation
+- Flag missing or inaccurate annotations: the deliverable ledger derives
+  requirement status from them, so a gap here understates delivered work
+
 ## Output
 
 Return verdict to orchestrator:
@@ -71,6 +77,7 @@ Return verdict to orchestrator:
 - [PASS/FAIL] Performance: [evidence]
 - [PASS/FAIL] Maintainability: [evidence]
 - [PASS/FAIL] Simplicity and surgicality: [evidence]
+- [PASS/FAIL] Requirement traceability: [evidence]
 
 ### Verdict: PASS / FAIL
 
@@ -79,7 +86,7 @@ Return verdict to orchestrator:
 
 ## Pass Criteria
 
-ALL six dimensions must PASS. Any FAIL blocks the commit.
+ALL seven dimensions must PASS. Any FAIL blocks the commit.
 
 If FAIL: orchestrator returns the slice to god-executor.
 If PASS: orchestrator commits the slice atomically.

package/agents/god-reconstructor.md

@@ -40,6 +40,10 @@ From the code, derive:
 - **Target users**: who uses this? (from auth, user types, customer-facing strings)
 - **Success metrics**: what does the code measure? (from observability, logs, metrics)
 - **Functional requirements**: what features exist? (from routes, public APIs, UI)
+  - Assign every functional requirement a stable id, numbered sequentially
+    within its priority (P-MUST-01, P-MUST-02, P-SHOULD-01, P-COULD-01), placed
+    at the start of the bullet. These ids are load-bearing for the deliverable
+    ledger and the linkage map.
 - **Non-functional requirements**: what NFRs are enforced? (from rate limits, caching, indexes)
 - **Scope and no-gos**: what's deliberately NOT in the code?
 
@@ -68,6 +72,10 @@ From git history + current state:
 - **Next**: TODOs at module level, unimplemented endpoints, stubs
 - **Later**: high-level themes from issue tracker if accessible
 
+Give each delivery increment a stable `M-<slug>` id, a `**Status**:` field
+(pending/building/done), and a `**Features (from PRD)**:` list of the
+reconstructed requirement ids it delivers.
+
 Write to `.godpowers/roadmap/ROADMAP.md`. Mark Done section explicitly so we don't "rebuild" things that already exist.
 
 ### 4. Reconstruct STACK
@@ -80,6 +88,15 @@ From package.json/pyproject.toml/Cargo.toml/etc:
 
 Write to `.godpowers/stack/DECISION.md`.
 
+### 5. Regenerate the deliverable ledger
+
+After the PRD and ROADMAP are written (both carry the new ids), regenerate the
+deliverable ledger by calling `lib/requirements.writeLedger(projectRoot)` so
+`.godpowers/REQUIREMENTS.md` reflects the reconstructed state. Requirement
+status is derived from the linkage map (code that carries `// Implements: P-...`
+annotations), so reconstructed requirements without linked code will show as
+not started until that linkage exists.
+
 ## Outputs
 
 All four artifacts written to `.godpowers/<tier>/<artifact>.md` with:

package/agents/god-roadmap-reconciler.md

@@ -26,6 +26,8 @@ Before doing feature work, ask: does this overlap with ROADMAP.md?
 
 Parse milestones from Now / Next / Later sections. Extract:
 - Each milestone's goal and features
+- The increment's `**Status**:` field (pending/building/done)
+- The member PRD requirement ids from its `**Features (from PRD)**:` list
 - Status (in-progress / planned / themed)
 - Dependencies between milestones
 
@@ -36,6 +38,11 @@ For each milestone, check if the user intent overlaps:
 - **Semantic match**: same user-facing behavior described differently?
 - **Requirement match**: does PRD.md already include this requirement?
 
+Also weigh the increment's `**Status**:` and its member requirement ids: an
+increment marked `done`, or one whose `**Features (from PRD)**:` ids already
+cover the intent, signals already-done or already-committed work rather than
+something new.
+
 ### 3. Classify
 
 Pick exactly one:

package/agents/god-roadmap-updater.md

@@ -43,7 +43,16 @@ When a planned milestone is no longer needed:
 - Mark superseded with reason
 - Don't silently delete; preserve history
 
-### 5. Re-validate
+### 5. Preserve increment ids and fields
+When editing any increment, keep its structured fields intact:
+- Keep the increment id (`M-<slug>`) stable; never renumber or reassign it.
+- Preserve and update the `**Status**:` field (pending/building/done) to match
+  reality; do not drop it.
+- Preserve and update the `**Features (from PRD)**:` requirement-id list; do not
+  drop it. Add ids when an increment gains a requirement; never silently remove
+  shipped ones.
+
+### 6. Re-validate
 
 After any update, re-check roadmap have-nots:
 - R-01: milestone goal substitution-tested
@@ -60,6 +69,12 @@ Updated `.godpowers/roadmap/ROADMAP.md` with:
 - Diff annotations: what was added, removed, moved
 - Updated dates
 - Re-validated have-nots
+- Increment ids, `**Status**:` fields, and `**Features (from PRD)**:` lists
+  preserved
+
+After updating, the deliverable ledger can be refreshed via
+`lib/requirements.writeLedger(projectRoot)` (or `/god-progress`) so
+`.godpowers/REQUIREMENTS.md` reflects the roadmap changes.
 
 Append a `## Changelog` section at the bottom:
 

package/agents/god-roadmapper.md

@@ -70,13 +70,20 @@ Rules:
 ## Process
 
 1. Read PRD (priorities) and ARCH (technical dependencies)
-2. List all features from PRD with their priority (MUST/SHOULD/COULD)
+2. List all requirements from PRD by their stable id
+   (P-MUST-NN / P-SHOULD-NN / P-COULD-NN) and priority
 3. Build dependency graph from ARCH (component A depends on component B)
 4. Topologically sort
-5. Group features into delivery increments:
-   - Each increment has a clear, substitution-tested goal
-   - Each increment has an observable completion gate
-   - Each increment is sized: S/M/L (no day-level precision without capacity input)
+5. Group requirements into delivery increments. Each increment gets:
+   - A stable id `M-<slug>` derived from the increment name
+   - An initial `Status: pending`. Status is later derived from the linkage map
+     (code linked to the increment's requirements); set `done` explicitly only
+     when the completion gate has been verified
+   - A clear, substitution-tested goal
+   - An observable completion gate
+   - A size: S/M/L (no day-level precision without capacity input)
+   - A Features list of the exact PRD requirement ids it delivers
+     (P-MUST-01, P-MUST-02, ...), so each requirement maps to one increment
 6. Assign Now/Next/Later horizons:
    - **Now**: building right now, committed
    - **Next**: planned next, flexible
@@ -92,11 +99,13 @@ as the structural starting point. Write `.godpowers/roadmap/ROADMAP.md`:
 
 ## Now
 ### Delivery Increment 1: [substitution-tested name]
+- ID: M-[slug]
+- Status: pending
 - Goal: [what users can do when this ships]
 - Gate: [observable completion criteria]
 - Size: S/M/L
-- Depends on: [list]
-- Features: [from PRD]
+- Depends on: [M-slug list]
+- Features (from PRD): [P-MUST-01, P-MUST-02, ...]
 
 ## Next
 [delivery increments]
@@ -111,6 +120,8 @@ Roadmap FAILS if:
 - Delivery increment goal passes substitution test
 - Completion gate is not observable
 - Feature appears that is not in the PRD
+- Any increment has no stable M-slug id
+- A committed (Now or Next) increment lists no PRD requirement ids
 - All increments the same size (no prioritization)
 - No dependency edges between increments
 - Day-level precision without capacity input