Fix RDD lifecycle consistency and skill handoffs

README.md

@@ -46,8 +46,9 @@ apply that model; `file-state/` serializes its records without redefining it.
 | `AGENTS.md` | shared agent policy and canonical entry point |
 | `PROCESS.md` | complete canonical process |
 | `CLAUDE.md` | root compatibility entry required for Claude discovery |
-| `skills/` | full-loop orchestration plus focused procedures for discovery, planning, review, building, triage, completion, and as-built verification; a focused flat-EC evaluator (`rdd-engineering-check`); corpus adoption for codebases without requirement records (`rdd-reverse-engineer`); a shared document/citation auditing utility (`rdd-audit`) |
+| `skills/` | full-loop orchestration and focused procedures with input/write/exit contracts; a flat-EC evaluator; resumable bounded corpus adoption; a scoped document/citation auditor with optional examples and adapter references |
 | `file-state/` | canonical serialization shapes for Epic, requirement, engineering-constraint, gate, work-selection, and backlog/gap records |
+| `tests/` | executable citation-auditor regressions and lifecycle walkthrough scenarios |
 
 ## Distribution
 
@@ -75,4 +76,22 @@ evidence rules, engineering-constraint semantics, or record ownership belong in
 `PROCESS.md`. Validate internal links and search the skills and flat-file shapes
 for competing authority statements whenever it changes.
 
+Run executable tooling regressions with Node's built-in test runner:
+
+```bash
+node --test tests/*.test.mjs
+git diff --check
+```
+
+Use [the lifecycle scenarios](tests/process-scenarios.md) to forward-test changed
+instructions in a fresh reviewer context. These are behavioral walkthroughs,
+not an implemented process-store engine or a substitute for an adopter's
+transition tests. Frontmatter/link validation alone cannot establish that the
+loop is executable.
+
+The evidence schema separates immutable runs from append-only assessments:
+historical RED may be `RETAINED`, while passing/regression evidence must be
+`CURRENT` at the relevant target. Older combined rows need their original run
+reports to migrate accurately; do not infer missing historical fingerprints.
+
 License: MIT.

file-state/BACKLOG.md

@@ -11,13 +11,14 @@
 Neither record type is a requirement. Neither counts toward trace, release,
 readiness, coverage, progress, or completion. Promotion out of this file always
 goes through `PROCESS.md` routing — a directly sourced item to `PROPOSED`, an
-inferred one to `DERIVED` plus its confirmation gate.
+inferred behavior to `DERIVED` plus its confirmation gate, and an observed or
+requested engineering rule to `PROPOSED` EC plus its human activation gate.
 
 ## Triage backlog
 
 Discoveries with unclear ownership or a cross-cutting concern, held until a
-human assigns them. An item that already has an owner and a source is a
-requirement and does not belong here.
+human assigns them. An item whose owner and route are known belongs in the
+appropriate requirement, EC, gap, or decision record rather than this backlog.
 
 ## BACKLOG-«NNN» — «Discovery in one line»
 

file-state/GATES.md

@@ -15,11 +15,12 @@ recorded prerequisite trace gate is unreadable, not implicitly open.
 
 ## GATE-«AREA»-«NNN» — «Transition or decision purpose»
 
-- **Kind:** trace or human / «confirmation, EC activation/retirement, engineering-check (planning/candidate/delivered), entry, decision, cold-review, start-review, completion»
+- **Kind:** trace or human / «confirmation, EC activation/retirement, engineering-check (planning/candidate/delivered), entry, release selection, decision, cold-review, start-review, completion»
 - **Transition / purpose:** «exact state transition, or the decision being asked»
-- **Exact scope:** «named EPIC/UR/SR/EC ids this gate covers; one answer may cover an Epic and named members»
+- **Exact scope:** «named EPIC/UR/SR/EC or release ids this gate covers; one answer may cover an Epic and named members»
 - **Prerequisites:** «gate ids that must be PASS before this one may leave DRAFT, or none»
-- **Fingerprint:** «content/code fingerprint the gate was evaluated at»
+- **Fingerprint / input manifest:** «kind-specific hash and exact inputs per PROCESS.md Fingerprint ownership; excludes this gate's outputs and application state»
+- **Evaluation target:** «PLANNING / CANDIDATE / DELIVERED + target revision and applicable EC ids/versions for engineering gates; otherwise the exact decision/review target»
 - **State:** «trace: PENDING / PASS / FAIL / STALE — human: DRAFT / OPEN / ANSWERED / CLOSED / SUPERSEDED»
 - **Verdict / answer:** «trace verdict with exact blockers, or the human answer as given»
 - **Actor / evaluator:** «real human actor and role for a human gate; evaluating agent or check for a trace gate»

file-state/REQUIREMENTS.md

@@ -22,13 +22,33 @@
 
 ### Trace references
 
-| Evidence class | Target | Code | Test case | RED result | Passing result | Outcome | Environment | Fingerprint | Validity/revision |
-|---|---|---|---|---|---|---|---|---|---|
-| UR upper | «UR scenario or N/A» | «code refs» | TEST: | RUN: | RUN: | PASS / FAIL / SKIP | «when relevant» | «content/code fingerprint» | CURRENT / STALE / INVALID / INHERITED_UNVERIFIED + revision |
-| SR lower | «SR clause or N/A» | CODE: | TEST: | RUN: | RUN: | PASS / FAIL / SKIP | «when relevant» | «content/code fingerprint» | CURRENT / STALE / INVALID / INHERITED_UNVERIFIED + revision |
-
-The RED/Passing split carries each result's role; `Outcome`, `Environment`,
-and `Fingerprint` carry the remaining mandated evidence-record fields.
+| Evidence class | Target | Code | Test case | Historical RED result ids | Passing/regression result ids |
+|---|---|---|---|---|---|
+| UR upper | «UR scenario or N/A» | «code refs» | TEST: | «result ids» | «result ids» |
+| SR lower | «SR clause or N/A» | CODE: | TEST: | «result ids» | «result ids» |
+
+### Evidence results
+
+Repeat this block for each immutable run; never share one outcome or fingerprint
+between RED and passing results. Store-backed serializers may reference the
+equivalent complete result records by id.
+
+- **Result id / role:** «id» / BASELINE_RED / SENSITIVITY_RED / PASSING / REGRESSION
+- **Target / assertion fingerprint:** «exact clause or scenario and exercised assertions»
+- **Test case / code:** TEST: / CODE:
+- **Observed outcome:** PASS / FAIL / SKIP
+- **Command / report:** RUN:«exact command and preserved report»
+- **Environment:** «relevant configuration/runtime, or N/A with basis»
+- **Tested fingerprint / revision:** «code/configuration fingerprint and revision; record patch/tree fingerprint for an uncommitted mutation»
+- **Expected RED cause:** «assertion and observed expected failure, or N/A»
+- **Mutation / restoration:** «sensitivity mutation/target, original fingerprint, restored fingerprint and verification; N/A for other roles»
+
+Validity assessments are append-only; changing an assessment never rewrites the
+observation. Historical RED uses `RETAINED`, not a claim of passing at delivery.
+
+| Assessed at | Validity | Assessment target/revision | Basis / confirming run |
+|---|---|---|---|
+| «timestamp» | CURRENT / RETAINED / STALE / INVALID / INHERITED_UNVERIFIED | «baseline or candidate/delivered fingerprint + revision» | «role-specific basis and direct evidence; prior run/equivalence proof when confirming at a new target» |
 
 ### Gates and delivery
 
@@ -38,4 +58,6 @@ and `Fingerprint` carry the remaining mandated evidence-record fields.
 - **Engineering-check gates:** «GATES.md gate ids»
 - **Completion gates:** «GATES.md gate ids»
 - **Delivered revision:** «repository + revision or not delivered»
+- **Review corrections:** «direct finding, unchanged approval, affected items, correction boundary, required reruns, and resolution; or none»
+- **Hold history:** «WORK-SELECTION.md per-item hold/restoration rows, or none»
 - **Gaps / deferrals / blockers / notes:** «refs or none»

file-state/WORK-SELECTION.md

@@ -9,6 +9,16 @@
 - **Source store/revision:** «database revision or repository SHA»
 - **Active release:** «release with its USER: source»
 
+## Release registry
+
+Record every release and its selection decision; the active-release field above
+references the sole active row after reconciliation. Apply current answered
+release decisions before checking that exactly one row is active.
+
+| Release id | State | USER source | Selection gate | Applied at revision |
+|---|---|---|---|---|
+| «id» | INACTIVE / ACTIVE | «attributable release decision» | «gate id» | «application revision or pending» |
+
 Work selection is authoritative state, not a derived queue. It records which
 scope is frozen, at which fingerprint, and which phase it is waiting on.
 Rendered queues, progress counts, and dashboards are regenerated from the
@@ -22,18 +32,37 @@ authoritative store and are not recorded here.
 - **Frozen at fingerprint:** «selected content/scope fingerprint; EC applicability is unresolved here»
 - **Reconnaissance revision:** «named revision the packet was authored against»
 - **Applicable EC set / fingerprint:** «unresolved before reconnaissance; then exact active EC ids and set fingerprint»
+- **Planning inputs / fingerprint:** «manifest and hash per PROCESS.md; excludes attached review outputs»
+- **Review attachments:** «engineering/cold-review result ids, findings/dispositions, independent reviewer context and reviewed fingerprint»
+- **Entry fingerprint / approvals:** «planning + prerequisite review references; per-item current applied approvals, not a shared lifecycle status»
+- **Next action:** «affected item subset, next legal action, required inputs, and exact resume condition»
 - **Current phase:** «source / plan / cold review / entry / build / verify / completion / triage»
 - **Waiting on:** «gate id, blocker, external prerequisite, or nothing»
 - **Owner:** «who holds the selection»
 
 ## Suspended selections
 
-One row per scope held at `BLOCKED` or `DEFERRED`, so the suspended state is
-recoverable rather than inferred.
+One row per held item, including differently progressed members of a held
+scope. Preserve each suspended-from state and its gate/evidence basis. Append
+release facts after reassessment; do not overwrite the prior-state record.
 
-| Scope | Suspended status | Restored-to status | Reason | Owner | Target | Blocker/gate |
+| Scope / item | Hold state | Suspended from / basis | Held at | Reason / owner / target | Blocker/gate | Released at / restored to / basis |
 |---|---|---|---|---|---|---|
-| «EPIC/SR id» | BLOCKED or DEFERRED | «strongest state supported when released» | «reason» | «owner» | «target» | «gate id or ref» |
+| «scope id / EPIC, UR or SR id» | BLOCKED or DEFERRED | «prior lifecycle status + gate/evidence refs» | «timestamp/revision» | «reason, owner, target» | «gate id or ref» | «pending, or timestamp/revision + strongest supported state + current gate/evidence refs» |
+
+## Adoption campaigns
+
+Adoption progress is not release commitment or delivery readiness. Retain the
+campaign after a context is handed to the normal loop, so another context can
+resume without re-deriving confirmed records.
+
+- **Campaign id / authority:** «stable id and USER request authorizing the bounded surface»
+- **Original baseline / latest inspected revision:** «repository revisions»
+- **Context inventory / scope:** «explicit context set and inventory references»
+
+| Context | Progress | Observation keys / candidate ids | Confirmation gates | Remaining work / next action |
+|---|---|---|---|---|
+| «context id» | NOT_STARTED / PARTIAL / AWAITING_CONFIRMATION / HANDED_OFF | «stable source/behavior keys and exact candidate ids» | «gate ids» | «uncovered observations, drift to recheck, or next delivery pass» |
 
 ## Selection history