@garygentry/feature-forge 0.3.1 → 0.3.4

package/adapters/copilot/skills/forge-verify/references/verification-checklists/impl.md

@@ -46,3 +46,88 @@ Detailed checklist for the **impl** verification mode, loaded by the `forge-veri
 - [ ] **CHECK-I22**: **Runtime-required bootstrap has a non-test caller.** Every exported bootstrap / `init*` / singleton-populator the specs mark as **required for runtime** must have ≥1 **non-test** call site on a runtime path — an entrypoint such as `main` / `instrumentation` / a route / a layout / a worker, NOT only test files. Statically grep for each such symbol's references (use the stack profile `references/stacks/{stack}.md` **Runtime Entrypoints & Bootstrap-Wiring Sites** list for what counts as a runtime entrypoint in this language). A symbol that is exported and covered by tests but referenced **only** from test files is a `gap` — the #121 walking-skeleton (bootstrap wired to nothing). Degrades naturally: a feature whose specs mark no bootstrap symbol as runtime-required is `not-applicable`. Weaker than `CHECK-I21` (it proves a call site exists, not that the boot succeeds), so it complements rather than replaces the smoke.
 - [ ] **CHECK-I23**: **Heavy bootstrap wired into a universal startup entry — recommend lazy init** (#149). *Advisory heuristic — a `gap`/`improvement` at most, **never** a hard fail.* When a runtime-required `init`/bootstrap/singleton-populator is wired into a **framework bootstrap entry that runs on every startup** (a Next.js `instrumentation.ts`, an app-server preload/`register` hook, a global setup module) **and** that init pulls in a **large server-only import graph** (DB clients, ORMs, queue/background workers, telemetry exporters, the whole service layer), recommend moving to **lazy initialization at the entry that already loads that graph** — the first route / handler / worker that needs it — rather than eager wiring at the universal entry. Eager wiring drags the heavy graph into every cold start, and in dev into every module re-evaluation (the watch-loop cost `CHECK-I21` also targets). **Detect statically:** from the stack profile's **Runtime Entrypoints & Bootstrap-Wiring Sites** list, identify this stack's universal bootstrap entries; grep those files for imports of the feature's runtime-required bootstrap symbols (`CHECK-I22`) and for the server-only heavy-import markers the profile names. A match → an `improvement`/`gap` finding naming the entry, the heavy graph it pulls, and the lazier call site to move initialization to. Degrades to `not-applicable` when the stack has no universal bootstrap entry, when no heavy init is wired there, or when the profile lists no bootstrap-wiring sites — **report, do not repair.**
 
+### Work-Order Cardinality
+
+> **When this fires:** only when the implementation ships or cites an **enumerated work
+> order, coverage list, or inventory that claims to cover a set of artifacts** — a
+> per-file work order, a "files changed" table, a per-artifact review checklist, an
+> inventory table in a spec this implementation realizes, or a registry constant in code
+> that claims to list every member of a class. No such list yields **not-applicable**;
+> absence is never a hard fail.
+
+- [ ] **CHECK-I24**: **A declared work order or coverage list covers the whole artifact set it claims — name what is missing** (#170).
+  *Heuristic with a mechanical method — **not-applicable** when the implementation declares
+  no enumerated work order, coverage list, or registry claiming full coverage; absence is
+  **never a hard fail**. A true omission is a `gap` (blocking): an unreviewed artifact is
+  missing coverage.* Any declared work order or coverage list must be checked against the
+  **actual artifact set it claims to cover**, with omissions named. The incident behind
+  this check is a hand-authored work order that enumerated **15 of 16** artifacts: the
+  sixteenth was never reviewed and would have shipped, because every reviewer worked the
+  list that was in front of them. Verify by re-deriving, never by reading the list back to
+  itself:
+  1. **Find the declared lists.** Look for enumerated lists claiming coverage of a set:
+     a work order or handoff enumerating files to change, a "files changed" or "artifacts
+     touched" table, a per-artifact review or sign-off checklist, an inventory table in an
+     implementation spec, and **registry-shaped constants in code** — a tuple, array, or
+     map documented as holding every helper, every adapter target, every generated file.
+     If no such list exists, this check is **not-applicable**.
+  2. **Re-derive the covered set from its source of record.** Enumerate the actual set
+     independently: the directory listing for a per-file list, the spec's own file
+     inventory for an implementation work order, the on-disk members for a registry
+     constant, the test suite's own collected set for a coverage table. A registry claiming
+     to hold "every script the skills invoke" is re-derived by finding the invocations, not
+     by reading the tuple.
+  3. **Difference both directions and name every discrepancy.** Every member of the
+     re-derived set with no entry in the declared list is reported **by name** — path,
+     symbol, or artifact id — never as a count delta. A list entry pointing at something
+     that does not exist is a stale entry, reported the same way.
+  4. **Severity, and what to report.** A named omission is a `gap`; a stale entry, or a
+     stated total that disagrees with an otherwise complete list, is an `inconsistency`.
+     Name the list, the source of record used for the re-derivation, and each missing or
+     stale member. This check is deliberately narrower than `CHECK-I01` (which asks whether
+     each file the architecture spec lists exists): here the *list itself* is the suspect,
+     not the artifacts it names. **Report, do not repair.**
+
+### Internal Consistency
+
+> **When this fires:** on any artifact that states the same quantity, scope claim, or
+> status **in more than one place** — front matter vs body, a summary block vs the prose
+> below it, a table vs the narrative that explains it, a docstring vs the code it
+> documents. This is deliberately **intra-artifact**: contradictions *between* artifacts
+> are already the subject of the spec-compliance checks above. An artifact that states
+> each quantity exactly once yields **not-applicable** — it degrades naturally, with
+> nothing to compare.
+
+- [ ] **CHECK-I25**: **One artifact, one answer — a quantity or claim restated inconsistently inside a single artifact** (#170).
+  *Verifier judgment — read and compare; no extractor runs (deliberately, this milestone).
+  **not-applicable** when nothing is restated. Severity defaults to `inconsistency`
+  (advisory) and escalates to `error` only when the contradiction is decision-bearing, per
+  the severity conventions in the verify skill.* An artifact can be internally false while
+  every cross-artifact check passes: in the incident behind this check, one artifact
+  asserted a claim held **universally**, while its own body — two sections below — stated
+  the correct **4-of-7** breakdown. The false summary survived a full review, propagated
+  into generated output, and would have shipped. Verify by comparing the artifact against
+  itself:
+  1. **Collect the restatements.** Read the artifact end to end and note every place it
+     states: a **count or total** ("16 files", "N of M", "all four"), a **scope claim**
+     ("every", "all", "none", "only", "universal", "always", "never"), a **status claim**
+     ("complete", "pending", "removed", "supported"), or a **named identifier or version**
+     it repeats. Note each statement with its location. Anything stated exactly once is not
+     in scope for this check.
+  2. **Compare statements about the same subject.** Group the notes by what they describe,
+     then compare within each group. Two disagreeing numbers is the obvious hit; the
+     costlier one is a **scope word contradicted by the artifact's own detail** — a
+     universal claim sitting above a partial breakdown, an "all supported" above a table
+     with a gap, a "removed" beside a surviving reference.
+  3. **Decide which statement the artifact's own evidence supports.** Prefer the
+     **enumerated detail** — the table, the list, the breakdown, the code — over the
+     summary that restates it: the summary is the derived form and is usually the one that
+     drifted. Say in the finding which statement the evidence supports and why, so the fix
+     is unambiguous.
+  4. **Set severity deliberately.** Default to `inconsistency` (advisory). Escalate to
+     `error` only when the contradiction is **decision-bearing** — a reader acting on the
+     wrong statement takes a materially different action, or the wrong statement is copied
+     into generated output, a published artifact, or a gate. An inaccuracy confined to a
+     comment, a docstring, or test narration stays at `inconsistency` under the severity
+     floor. Quote both locations verbatim in the finding. **Report, do not repair.**
+

package/adapters/copilot/skills/forge-verify/references/verification-checklists/specs.md

@@ -45,7 +45,7 @@ Detailed checklist for the **specs** verification mode, loaded by the `forge-ver
 - [ ] **CHECK-S26**: Import paths match actual package export maps
 
 ### Edge Cases and Non-Functional
-- [ ] **CHECK-S27**: Concurrent access scenarios are addressed if relevant
+- [ ] **CHECK-S27**: Concurrent access scenarios are addressed if relevant (a PRD position of "out of scope — single writer assumed" is a complete answer; for forge state writes the standing decision is `references/decisions/single-writer-threat-model.md` — cite it, do not design a mechanism)
 - [ ] **CHECK-S28**: Empty/null/undefined inputs are handled
 - [ ] **CHECK-S29**: Performance-sensitive paths are identified
 - [ ] **CHECK-S30**: Security considerations from PRD are reflected in implementation
@@ -62,3 +62,47 @@ Detailed checklist for the **specs** verification mode, loaded by the `forge-ver
 ### Traceability
 - [ ] **CHECK-S38**: Build a complete traceability matrix from every REQ-XXX-NN to the spec document and section that implements it. Any REQ ID not found in at least one spec is a gap finding.
 
+> **A quoted foreign requirement id is not an orphan.** A suite may legitimately mention a `REQ-` id it does not own — most often when a spec quotes an antecedent feature's test docstrings verbatim. Such ids may be declared, one per line, in `{resolvedFeatureDir}/.traceability-allowlist` (blank lines and `#` comments ignored), or passed as a repeatable `--allow-orphan REQ-ID` to `scripts/validate-traceability.py`. Allowed ids are reported as `ALLOWED FOREIGN REFERENCES` (`allowed_orphans` under `--json`) rather than silently dropped, and an entry matching nothing is reported as `STALE ALLOWLIST ENTRIES` (`unused_allowlist_entries`), which is advisory and does not fail the check. Before filing an orphaned reference as a finding, check whether it is already declared there — a declared id is a recorded decision, not a defect.
+
+### Internal Consistency
+
+> **When this fires:** on any single spec document that states the same quantity, scope
+> claim, or status **in more than one place** — a Requirement Coverage table vs the
+> sections it points at, a summary or overview paragraph vs the detail below it, a
+> Dependencies list vs the cross-references in the body, a stated count of documents or
+> types vs the list actually enumerated. It is **intra-document**: a contradiction
+> *between* two spec documents is already covered by the tech-spec-consistency and
+> cross-reference checks above. A document that states each quantity exactly once yields
+> **not-applicable**.
+
+- [ ] **CHECK-S39**: **One document, one answer — a quantity or claim restated inconsistently inside a single spec** (#170).
+  *Verifier judgment — read and compare; no extractor runs (deliberately, this milestone).
+  **not-applicable** when nothing is restated. Severity defaults to `inconsistency`
+  (advisory) and escalates to `error` only when the contradiction is decision-bearing, per
+  the severity conventions in the verify skill.* A spec document can contradict itself
+  while every cross-document check passes: in the incident behind this check, one artifact
+  asserted a claim held **universally**, while its own body — two sections below — stated
+  the correct **4-of-7** breakdown. The summary was the part downstream artifacts copied.
+  Verify by comparing the document against itself:
+  1. **Collect the restatements.** Note every place the document states a **count or
+     total** ("five documents", "N of M", "all three subcommands"), a **scope claim**
+     ("every", "all", "none", "only", "universal", "always", "never"), a **status claim**
+     ("out of scope", "deferred", "removed", "required"), or a **repeated identifier**
+     (a type name, a file path, a requirement id, a constant's value). Record each with its
+     location. Anything stated exactly once is not in scope for this check.
+  2. **Compare statements about the same subject.** Group by subject and compare within
+     each group. Watch specifically for: a Requirement Coverage table row pointing at a
+     section that no longer makes that claim; a count in an overview that disagrees with
+     the list enumerated below it; a scope word ("all", "universal", "never") that the
+     document's own breakdown contradicts; a constant given one value in a type definition
+     and another in prose.
+  3. **Decide which statement the document's own evidence supports.** Prefer the
+     **enumerated detail** — the table, the type definition, the numbered list — over the
+     summary that restates it. Name in the finding which statement the evidence supports,
+     so the fix does not have to re-derive it.
+  4. **Set severity deliberately.** Default to `inconsistency` (advisory). Escalate to
+     `error` only when the contradiction is **decision-bearing**: an implementer building
+     from the wrong statement writes different code, or the wrong statement is what a
+     downstream artifact or generated output copies. Quote both locations verbatim.
+     **Report, do not repair.**
+

package/adapters/cursor/.feature-forge-bundle.json

@@ -1,6 +1,6 @@
 {
   "name": "feature-forge",
-  "version": "0.14.0",
+  "version": "0.17.0",
   "agent": "cursor",
   "generatedBy": "python3 scripts/build-adapters.py"
 }

package/adapters/cursor/agents/forge-verifier.mdc

@@ -13,6 +13,8 @@ You are the "second set of eyes." You receive artifacts (PRDs, tech specs, imple
 
 You have READ-ONLY access. You cannot and should not modify any files. Your output is returned as your response — the parent agent handles writing the findings document to disk.
 
+**Your last message is the only thing the parent receives.** The host's subagent mechanism returns your final response and nothing else — no transcript, no intermediate messages, no tool results. If your run ends on a status or transition line ("Let me read the dispatch handler table."), *that line* is the entire verification result the parent gets, and the digest you spent the whole run building is silently dropped (issue #183). Your final response must therefore BE the complete report — the full Output Format block below, starting at `# Verification Report:` — never a summary of it, never an opening line, never "the report follows." Before ending, check your last message: if it is not the complete report, emit the complete report.
+
 **You ARE the verifier — you never dispatch one.** You have no Agent/host's subagent mechanism. Your pre-loaded `forge-verify` skill contains a "Subagent Delegation (parent orchestrator only)" section describing how a *parent* dispatches a `forge-verifier` — that guidance is for the parent, not for you. Ignore it: do not attempt to delegate, spawn a subagent, or return a "verification is running / will surface shortly" placeholder. Execute the verification checks yourself and return the findings block. Delegating from here is a self-referential loop that produces no work and no findings artifact.
 
 ## How You Work
@@ -55,7 +57,7 @@ At the end of each verification pass, update your memory with any new patterns y
 
 ## Output Format
 
-Return your findings as your final response using exactly this markdown structure. The parent agent will write it to `.verification/VERIFY-{mode}-{date}.md`:
+Return your findings as your final response using exactly this markdown structure — the final response IS the report (emit the entire block, not a description of it). The parent agent will write it to `.verification/VERIFY-{mode}-{date}.md`:
 
 ```markdown
 # Verification Report: {feature} ({mode})

package/adapters/cursor/references/decisions/single-writer-threat-model.md

@@ -0,0 +1,53 @@
+# Decision: single-writer state model — detection welcome, locking out of scope
+
+**Decided:** 2026-08-08 · **Issue:** [#180](https://github.com/garygentry/feature-forge/issues/180) · **Owner:** repository owner
+
+## The decision
+
+Concurrent multi-session mutation of forge state is **out of scope**. Every forge state
+writer — `forge-session.py` (`.pipeline-state.json`) and `epic-manifest.py`
+(`epic-manifest.json`, `.epic-state.json`) — assumes a **single writer**. Atomicity
+(sibling temp file → flush/fsync → `os.replace`) protects against an *interrupted* write;
+it is not, and is not intended to be, mutual exclusion between simultaneous writers.
+
+The standing posture is **detection, not locking**:
+
+- **No locking mechanism will be added on the authority of a verification finding or a
+  single feature's spec.** If concurrent multi-session use ever becomes a supported
+  workflow, that is a product decision needing its own PRD — and a state lock alone would
+  be false comfort, because git operations, the two-commit provenance protocol, and
+  adapter regeneration are equally unsynchronized.
+- **Cheap, opportunistic detection is welcome if someone proposes it** — e.g. an
+  epic-root writer re-reading and failing loudly on an unexpected `revision` before
+  `os.replace`. It is an explicitly optional hardening, not a requirement, and nothing is
+  scheduled.
+
+## Accepted residual risk
+
+Everything in-session is sequential, and member `.pipeline-state.json` files are
+disjoint. The one real exposure: two sessions working **different members of one epic**
+share two epic-root files, `epic-manifest.json` and `.epic-state.json`. A lost
+read-modify-write increment of the manifest's `revision` can leave it unchanged after a
+semantic mutation landed, and the freshness comparison then classifies a **stale epic
+verification as `fresh`** — a correctness consequence, not just a lost edit.
+
+This is **accepted and documented**, not mitigated. Anyone who hits it has this document
+to cite; do not run two concurrent sessions against members of the same epic.
+
+## What this means for verification (CHECK-S27)
+
+When `CHECK-S27` ("Concurrent access scenarios are addressed if relevant") fires against
+forge state writes, the answer is a **citation, not a design**: cite this document (or
+the per-feature requirement restating it, e.g. `stage-exit-coverage` `REQ-REL-04`,
+`epic-orchestration` `REQ-ROBUST-03`). A PRD silent on concurrency gets a one-sentence
+position recorded; a verifier must never answer the silence by specifying a mechanism.
+
+## Provenance
+
+Both precedents ran the same check; the only variable was whether the PRD had a position:
+
+- `stage-exit-coverage` V-006 raised CHECK-S27 against a silent PRD, was filed as a
+  `gap`, and induced a ~140-line portable lock protocol answering no requirement. It was
+  removed (`302c93f`), and the PRD now records the position as `REQ-REL-04`.
+- `epic-orchestration` V-008 raised the same check against a PRD that had scoped
+  concurrency out (`REQ-ROBUST-03`), was filed as an `improvement`, and cost one sentence.

package/adapters/cursor/references/epic-manifest-schema.json

@@ -4,13 +4,18 @@
   "title": "Feature Forge Epic Manifest",
   "description": "Canonical record of an epic's membership, dependency edges, charters, and contracts. Lives at {specsDir}/{epic}/epic-manifest.json. Carries NO per-feature status field (REQ-STATE-02); status is derived live from each member's .pipeline-state.json.",
   "type": "object",
-  "required": ["schemaVersion", "epic", "description", "status", "narrativeDoc", "createdAt", "updatedAt", "features"],
+  "required": ["schemaVersion", "revision", "epic", "description", "status", "narrativeDoc", "createdAt", "updatedAt", "features"],
   "additionalProperties": false,
   "properties": {
     "schemaVersion": {
       "const": 1,
       "description": "Schema evolution guard."
     },
+    "revision": {
+      "type": "integer",
+      "minimum": 1,
+      "description": "Canonical artifact revision for epic-scoped verification freshness."
+    },
     "epic": {
       "type": "string",
       "pattern": "^[a-z0-9]+(?:-[a-z0-9]+)*$",

package/adapters/cursor/references/epic-state-schema.json

@@ -0,0 +1,50 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "Feature Forge Epic Verification State",
+  "description": "Epic-scoped verification state for a single epic. Lives at {specsDir}/{epic}/.epic-state.json. Written only by forge-session.py's `state-verify` verb for epic targets (`--stage forge-0-epic`, resolved through `_load_epic_state_for_write`) — never by hand. Deliberately NOT a member `.pipeline-state.json` variant: epic verification is epic-scoped, artifact freshness is judged against the epic manifest's `revision` (never a member production-stage `version`), and there is no fallback between the two state files in either direction (REQ-SEC-01).",
+  "type": "object",
+  "required": ["epic", "updatedAt", "stages"],
+  "properties": {
+    "epic": {
+      "type": "string",
+      "description": "Epic name (matches the directory name under specsDir). epic-manifest.json's own `epic` value is canonical on conflict — the writer refuses a mismatched identity rather than resolving it."
+    },
+    "updatedAt": {
+      "type": "string",
+      "format": "date-time"
+    },
+    "stages": {
+      "type": "object",
+      "properties": {
+        "forge-verify-epic": { "$ref": "#/definitions/verifyEntry" }
+      }
+    }
+  },
+  "definitions": {
+    "verifyEntry": {
+      "type": "object",
+      "required": ["status"],
+      "description": "MIRROR of pipeline-state-schema.json#/definitions/verifyEntry (minus this description) — the repo's stdlib schema validator (tests/_state_schema.py) resolves same-file `#/definitions/*` refs only, so the definition is duplicated rather than cross-file-referenced, and tests/test_epic_state_schema_conformance.py pins the two definitions equal so they cannot drift. Edit them together.",
+      "properties": {
+        "status": {
+          "type": "string",
+          "enum": ["pending", "auto-verify-pending", "passed", "findings-reported", "findings-applied", "skipped"]
+        },
+        "findingsFile": {
+          "type": ["string", "null"],
+          "description": "Path to the verification findings document"
+        },
+        "findingsCount": {
+          "type": ["integer", "null"],
+          "description": "Number of findings reported"
+        },
+        "verifiedAt": { "type": ["string", "null"], "format": "date-time" },
+        "fixedAt": { "type": ["string", "null"], "format": "date-time" },
+        "commitHash": { "type": ["string", "null"], "description": "Git commit SHA of the verify/fix artifact commit. Recorded via the two-commit Git Commit Protocol (shared-conventions.md) so it points at the artifact commit, never an orphaned amend." },
+        "verifiedStageVersion": { "type": ["integer", "null"], "description": "The production stage's `version` at the moment this verify was resolved. The navigator's freshness ledger compares it to the stage's current `version`: equal means the verify is fresh; a mismatch (artifact revised since) or an absent field (legacy state) means stale, so auto-verify re-fires. Recorded by forge-verify/forge-fix when writing a passed/findings-applied status." },
+        "scheduledAt": { "type": ["string", "null"], "format": "date-time", "description": "UTC ISO-8601 timestamp at which unattended in-stage verification was scheduled for this entry. Written alongside the `auto-verify-pending` status and DELETED (not nulled) by any terminal result, so an absent field means 'not scheduled'." },
+        "scheduledStageVersion": { "type": ["integer", "null"], "minimum": 1, "description": "The artifact revision current when verification was scheduled — the production stage's `version` for a feature, the epic manifest's `revision` for an epic. Makes rescheduling idempotent (an identical revision does not rewrite the entry) and lets a read tell debt owed on the current artifact from debt stranded on an older one. Deleted by any terminal result." }
+      }
+    }
+  }
+}

package/adapters/cursor/references/forge-config-schema.json

@@ -67,6 +67,12 @@
       "default": true,
       "description": "When true (default), the /feature-forge:forge navigator auto-invokes the next pipeline stage via the Skill tool after the user confirms it, instead of only printing the command to copy. Set false to keep the old copy-paste behavior (the navigator suggests the command but never launches it). Ignored on non-Claude hosts, which always fall back to printing the command."
     },
+    "docsStage": {
+      "type": "string",
+      "enum": ["prompt", "skip"],
+      "default": "prompt",
+      "description": "How forge-6-docs' Documentation Decision Gate behaves at stage entry. \"prompt\" (default) asks generate-vs-skip once per run; \"skip\" records the stage as deliberately skipped with no prompt — the skill runs the state-skip verb and closes the pipeline honestly (stage-exit --outcome skipped), so docs are never implied-mandatory for teams that document differently. The gate's refuse-to-erase guard still applies: docs that already exist are never silently reclassified, whatever this is set to. Read directly by forge-6-docs (not part of loopRunner resolution); an unrecognized or absent value behaves as \"prompt\"."
+    },
     "autoVerify": {
       "type": "boolean",
       "default": false,
@@ -75,7 +81,7 @@
     "autoVerifyStages": {
       "type": "object",
       "default": {},
-      "description": "Per-stage overrides for autoVerify. Maps a production stage id to a boolean; the effective value for a stage is autoVerifyStages[stage] if present, else autoVerify. Keys are constrained to the five verify-capable stages so a typo (e.g. 'forge-1-prod') is a schema error, not a silent no-op. forge-6-docs has no verify step and is not a valid key.",
+      "description": "Per-stage overrides for autoVerify. Maps a production stage id to a boolean; the effective value for a stage is autoVerifyStages[stage] if present, else autoVerify. Keys are constrained to the five verify-capable stages, so a typo (e.g. 'forge-1-prod') is reported as an ignored key rather than silently taking no effect. It does not fail the command. forge-6-docs has no verify step and is not a valid key.",
       "propertyNames": {
         "enum": ["forge-1-prd", "forge-2-tech", "forge-3-specs", "forge-4-backlog", "forge-5-loop"]
       },
@@ -195,6 +201,18 @@
           "default": "",
           "description": "Project-default coding agent id, so a project can fix its agent once without specifying it every run. Empty string ⇒ no project default (the runner's own default — claude-cli for rauf — applies, behaving exactly as today). Overridden by the per-run agent selector (run > project precedence, resolved inside forge before the single --agent is emitted). Ignored when agentArgument is absent."
         },
+        "agentMode": {
+          "type": "string",
+          "enum": ["prompt", "auto"],
+          "default": "prompt",
+          "description": "Gates forge-5's Step 2d agent AskUserQuestion. \"prompt\" (default) presents the agent question — byte-identical to today. \"auto\" suppresses ONLY the interactive pick: the agent resolves from defaultAgent (or the runner default when unset), and the availability probe, the verdict classification (UNKNOWN hard-reject before side-effects / UNAVAILABLE proceed-or-choose / probe-failure handling), and the Claude-alias model guard ALL still run; the resolved 'Agent: {id} (source: …)' confirmation line still shows, so the choice is never hidden. Meaningless when agentArgument is absent/empty — that capability gate already removes the entire agent surface, and this field adds no second gate. An unrecognized value behaves as \"prompt\"."
+        },
+        "reviewMode": {
+          "type": "string",
+          "enum": ["prompt", "always", "never"],
+          "default": "prompt",
+          "description": "Gates forge-5's Step 2d Run-mode AskUserQuestion (rauf only — ignored when name != \"rauf\", where no Run-mode question exists). \"prompt\" (default) surfaces the question with the review pass pre-selected — byte-identical to today. \"always\" skips the question and appends --review unconditionally; the rendered command in the confirmation still shows --review, so the choice is never hidden. \"never\" skips the question and launches the bare rendered command. Under \"always\"/\"never\", a NARROWER situational retry-blocked question still surfaces when — and only when — the backlog has blocked items (the --review decision itself is fixed by the mode and never re-asked); with no blocked items the launch is prompt-free. An unrecognized value behaves as \"prompt\"."
+        },
         "preconditionFile": {
           "type": "string",
           "default": ".rauf.json",

package/adapters/cursor/references/forge-decisions-schema.json

@@ -0,0 +1,33 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "forge-decisions",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["schemaVersion", "feature", "createdAt", "updatedAt", "decisions"],
+  "properties": {
+    "schemaVersion": { "type": "string", "enum": ["1"] },
+    "feature":       { "type": "string" },
+    "createdAt":     { "type": "string" },
+    "updatedAt":     { "type": "string" },
+    "decisions":     { "type": "array", "items": { "$ref": "#/definitions/decision" } }
+  },
+  "definitions": {
+    "decision": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["itemId", "question", "answer", "deferred", "decidedAt",
+                   "recordedBy", "appliedAt", "appliedBy"],
+      "properties": {
+        "itemId":     { "type": "string" },
+        "question":   { "type": "string" },
+        "answer":     { "type": ["string", "null"] },
+        "deferred":   { "type": "boolean" },
+        "clusterId":  { "type": "string" },
+        "decidedAt":  { "type": "string" },
+        "recordedBy": { "type": "string" },
+        "appliedAt":  { "type": ["string", "null"] },
+        "appliedBy":  { "type": ["string", "null"] }
+      }
+    }
+  }
+}

package/adapters/cursor/references/pipeline-state-schema.json

@@ -37,7 +37,7 @@
     },
     "notes": {
       "type": "string",
-      "description": "Free-form notes persisted between sessions (user can add context before stepping away)"
+      "description": "Free-form notes persisted between sessions (user can add context before stepping away). A single string with latest-note-wins semantics: `state-note` (its only sanctioned writer) OVERWRITES the previous value — an author folds any still-relevant earlier note into the one combined string. Read by the navigator dashboard AND by each downstream stage's Step 1 carried-over note check (forge-2-tech through forge-5-loop), which surfaces it as stage input; it never overrides artifacts or config."
     },
     "epicChangeRequests": {
       "type": "array",
@@ -127,7 +127,7 @@
         "forge-4-backlog": { "$ref": "#/definitions/stageEntry" },
         "forge-verify-backlog": { "$ref": "#/definitions/verifyEntry" },
         "forge-5-loop": { "$ref": "#/definitions/stageEntry" },
-        "forge-6-docs": { "$ref": "#/definitions/stageEntry" },
+        "forge-6-docs": { "$ref": "#/definitions/docsStageEntry" },
         "forge-verify-impl": { "$ref": "#/definitions/verifyEntry" },
         "forge-verify-prd": { "$ref": "#/definitions/verifyEntry" },
         "forge-verify-tech": { "$ref": "#/definitions/verifyEntry" }
@@ -165,13 +165,45 @@
         }
       }
     },
+    "docsStageEntry": {
+      "type": "object",
+      "required": ["status"],
+      "description": "The forge-6-docs stage entry: identical to stageEntry except that `skipped` is a legal status and `skippedAt` records when the deliberate skip was written (by the `state-skip` verb, never by hand). `skipped` is a terminal, done-for-selection status — the pipeline ends without the stage claiming artifacts it never produced (#197). Deliberately scoped to the docs stage: a skipped PRD or specs stage is not a representable state, so the shared stageEntry enum does NOT carry `skipped`.",
+      "properties": {
+        "status": {
+          "type": "string",
+          "enum": ["pending", "in-progress", "complete", "stale", "skipped"]
+        },
+        "version": {
+          "type": "integer",
+          "description": "Incremented each time this stage's artifacts are revised"
+        },
+        "artifacts": {
+          "type": "array",
+          "items": { "type": "string" },
+          "description": "Relative paths to artifacts produced by this stage"
+        },
+        "startedAt": { "type": ["string", "null"], "format": "date-time" },
+        "completedAt": { "type": ["string", "null"], "format": "date-time" },
+        "skippedAt": { "type": ["string", "null"], "format": "date-time", "description": "UTC ISO-8601 timestamp of the deliberate skip (status: skipped). Written by `state-skip`; absent on every other status." },
+        "commitHash": {
+          "type": ["string", "null"],
+          "description": "Git commit SHA of this stage's artifact commit (Commit 1 of the two-commit Git Commit Protocol in shared-conventions.md). Written by a small follow-up commit so it points at the artifact commit itself, never at an orphaned amend or the hash-recording commit. null until recorded (or when there was no new artifact commit)."
+        },
+        "basedOnVersions": {
+          "type": "object",
+          "description": "Upstream stage versions this artifact was built against",
+          "additionalProperties": { "type": "integer" }
+        }
+      }
+    },
     "verifyEntry": {
       "type": "object",
       "required": ["status"],
       "properties": {
         "status": {
           "type": "string",
-          "enum": ["pending", "passed", "findings-reported", "findings-applied", "skipped"]
+          "enum": ["pending", "auto-verify-pending", "passed", "findings-reported", "findings-applied", "skipped"]
         },
         "findingsFile": {
           "type": ["string", "null"],
@@ -184,7 +216,9 @@
         "verifiedAt": { "type": ["string", "null"], "format": "date-time" },
         "fixedAt": { "type": ["string", "null"], "format": "date-time" },
         "commitHash": { "type": ["string", "null"], "description": "Git commit SHA of the verify/fix artifact commit. Recorded via the two-commit Git Commit Protocol (shared-conventions.md) so it points at the artifact commit, never an orphaned amend." },
-        "verifiedStageVersion": { "type": ["integer", "null"], "description": "The production stage's `version` at the moment this verify was resolved. The navigator's freshness ledger compares it to the stage's current `version`: equal means the verify is fresh; a mismatch (artifact revised since) or an absent field (legacy state) means stale, so auto-verify re-fires. Recorded by forge-verify/forge-fix when writing a passed/findings-applied status." }
+        "verifiedStageVersion": { "type": ["integer", "null"], "description": "The production stage's `version` at the moment this verify was resolved. The navigator's freshness ledger compares it to the stage's current `version`: equal means the verify is fresh; a mismatch (artifact revised since) or an absent field (legacy state) means stale, so auto-verify re-fires. Recorded by forge-verify/forge-fix when writing a passed/findings-applied status." },
+        "scheduledAt": { "type": ["string", "null"], "format": "date-time", "description": "UTC ISO-8601 timestamp at which unattended in-stage verification was scheduled for this entry. Written alongside the `auto-verify-pending` status and DELETED (not nulled) by any terminal result, so an absent field means 'not scheduled'." },
+        "scheduledStageVersion": { "type": ["integer", "null"], "minimum": 1, "description": "The artifact revision current when verification was scheduled — the production stage's `version` for a feature, the epic manifest's `revision` for an epic. Makes rescheduling idempotent (an identical revision does not rewrite the entry) and lets a read tell debt owed on the current artifact from debt stranded on an older one. Deleted by any terminal result." }
       }
     }
   }

package/adapters/cursor/references/process-overview.md

@@ -37,7 +37,7 @@ The pipeline compiles a fuzzy feature idea into a machine-executable `backlog.js
 **Method:** Clean-context analysis producing actionable findings with an ordered fix plan.
 
 **Manual or automatic.** By default the navigator offers verification after each stage. Because
-it runs in a fresh, read-only subagent (clean-room by construction, never needs a `/clear`), it is
+it runs in a fresh, read-only subagent (clean-room by construction, never needs a session clear), it is
 safe to automate: set `autoVerify: true` (or per-stage via `autoVerifyStages`) in
 `forge.config.json` and the navigator runs `forge-verify` automatically once a stage completes,
 returning only a compact digest to the session. The freshness ledger (verify entries record the
@@ -118,7 +118,7 @@ they track the current model tier automatically.
 
 ### forge-verifier
 - **Purpose:** Read-only verification of pipeline artifacts
-- **Used by:** `forge-verify` skill (delegation via Agent tool)
+- **Used by:** `forge-verify` skill (delegation via host's subagent mechanism)
 - **Tools:** Read, Glob, Grep, Bash (read-only operations only)
 - **Model:** Opus (judgement-heavy gap/inconsistency analysis)
 - **Memory:** Project-scoped persistent memory — accumulates knowledge about recurring issues and project-specific patterns across sessions

package/adapters/cursor/references/ralph-loop-contract.md

@@ -58,9 +58,12 @@ defined authoritatively in rauf's
 > item aside and **keeps working other runnable items to completion** (rauf:
 > `runner.ts` needs_human handler). So a supervising session can surface those
 > events live (visibility) and cancel early, but it cannot inject an answer and
-> resume the set-aside item mid-run — resolution is a follow-up retry pass. A
-> first-class pause/resume-with-answer capability is a desirable runner
-> enhancement (see `plans/rauf-enhancement-recommendations.md`).
+> resume the set-aside item mid-run — resolution is the **Post-Run Recovery
+> Procedure** (`skills/forge-5-loop/references/recovery-procedure.md`): record the
+> answer via `decision-record` at the moment of collection, then drive recovery
+> from the record after the run ends. A first-class pause/resume-with-answer
+> capability is a desirable runner enhancement (see
+> `plans/rauf-enhancement-recommendations.md`).
 
 ## rauf is the default and reference implementation