rcf-lite 0.28.1 → 0.28.4

package/rcf/requirements/req-173.json

@@ -0,0 +1,25 @@
+{
+  "createdAt": "2026-09-24T12:00:00Z",
+  "updatedAt": "2026-09-24T12:00:00Z",
+  "reqId": "REQ-173",
+  "prdId": "PRD-001",
+  "title": "Sidecar ledgers under rcf/define/ and the rcf define ledger verb",
+  "description": "Four sidecars live under rcf/define/, each one JSON file, each with one numbered sequence for the life of the project (proposal 2026-09-22 v3 section 2.5, 3.2, 8.2). Names and shapes: brief-ledger.json (statements[] kinded from a closed set), decisions-ledger.json (decisions[] in the numbered #241 format), concern-ledger.json (concerns[] with disposition applied or waived), probe-ledger.json (probes[] with severity low, medium, high). A local schema in rcf-lite validates every write until schemas 0.7. Reading a missing ledger file returns an empty ledger so callers can compose without a per-file null check; a malformed file raises a clear error. The rcf define ledger name verb pattern (brief, decisions, concerns, probes; add, resolve, list) is the operator surface. brief add --from <file> splits statements one per non-empty line, mints sequential ids and writes; the intake-scan-against-frozen-statements hook is a named seam this slice leaves for a later one. decisions list prints the #241 numbered format (one decision per item, options with letters, the default, what it blocks). The walker never reads under rcf/define/ so the sidecars stay invisible to every existing tree consumer.",
+  "category": "functional",
+  "domain": "defineLedgers",
+  "priority": "must",
+  "version": "0.1.0",
+  "status": "draft",
+  "shapeClassification": {
+    "shapes": ["persistence"],
+    "reason": "keyword-scan",
+    "classifiedAt": "2026-09-24T12:00:00Z",
+    "signals": [
+      { "source": "description", "shape": "persistence", "match": "record" }
+    ]
+  },
+  "rationale": "The proposal (2026-09-22 v3, section 8.2) makes ledgers the seam every later DEFINE stage draws from: D1 reads the brief ledger, D5 the concern ledger, D6 the probe ledger, D7 the decisions ledger, and D2's greenfield resolution walks the brief statements. Building the sidecars and the CLI now, before any gate reads them, keeps slice 2 free of write-side surprises. Baz's ruling of 2026-09-22 (decision 5) fixed the ownership: sidecars in rcf-lite until schemas 0.7 promotes them to manifest records. Precedent: .rcf/preflight-secrets.local.json is an rcf-lite-owned file outside the shared schema; rcf/define/ follows the same shape.",
+  "tags": [
+    "capability:define-ledgers"
+  ]
+}

package/rcf/requirements/req-174.json

@@ -0,0 +1,25 @@
+{
+  "createdAt": "2026-09-24T14:30:00Z",
+  "updatedAt": "2026-09-24T14:30:00Z",
+  "reqId": "REQ-174",
+  "prdId": "PRD-001",
+  "title": "DEFINE stage gates D1..D8 as pure check functions",
+  "description": "rcf-lite gains src/query/gates.js with one check function per stage D1..D8. Each function takes (tree, ledgers, profile, scope) and returns { stage, gate, state, checks[] } where every check is { name, ok, over: 'delta'|'tree', pass, total, failing: [{ id, why }] }. Stage state is 'passed' | 'failing' | 'acknowledged' (only for D3, D5, D6 and only when the freeze record acknowledges that gate at the current hash) | 'notApplicable' (the stage decides that itself from the scope per the proposal 2026-09-22 v3 section 3.2 rules and the summary table in section 2.7). Blocking in 0.29.0: D1 brief, D2 skeleton, D4 floors (every REQ in scope has a US; every US in scope has a testable AC, a failure AC and a must-not AC, or a reasoned opt-out per class; tacIds non-empty and resolving; no scaffold placeholder), D7 decisions, D8 freeze (prior gates passed or acknowledged at the current hash, every AC owned by exactly one FBS, queue head actionable and not a placeholder, validate clean; preflight and ui-baseline presence as the section 3.2 rules specify). Warn-with-ack in 0.29.0: D3, D5, D6 build only the cheap data-backed checks (D3: every TAC in scope has at least one interface and each interface kind is in the closed vocabulary of section 5.2; D5: TAD securityArchitecture present when any auth or httpApi REQ exists, operationalConcerns present when deployed-scope ACs exist, concern-ledger entries applied or waived where they exist; D6: validate clean tree-wide plus open probe-ledger count). The D3 template parser, entity join, D5 catalogue, D6 contradiction and unsatisfiable scans, and the probe runner are 0.30 and left as named seams. AC class is a bracketed prefix on AC description ('[failure] ...', '[must-not] ...', '[happy]', '[edge]', '[non-functional]', decision 6); opt-out per class reuses the existing manifest.baselineAcOptOuts[] array with a baselineKey of the shape 'defineD4:failure' or 'defineD4:mustNot' (recorded in ADR-4122). No storage state, no 'stale' state.",
+  "category": "functional",
+  "domain": "defineDetection",
+  "priority": "must",
+  "version": "0.1.0",
+  "status": "draft",
+  "shapeClassification": {
+    "shapes": ["persistence"],
+    "reason": "keyword-scan",
+    "classifiedAt": "2026-09-24T14:30:00Z",
+    "signals": [
+      { "source": "description", "shape": "persistence", "match": "record" }
+    ]
+  },
+  "rationale": "Baz ruled on 2026-09-22 (proposal section 9, decision 2) that gates block where the data exists and warn-with-ack for D3, D5 and D6 until 0.31 (Baz ruled 2026-09-24 that 0.31 renumbers to 0.30, so this train ships D3/D5/D6 as warn-with-ack in 0.29.0). One check function per stage is the seam every later consumer reads: the readiness view (REQ-175) composes them, the freeze verb (slice 3) refuses on any failing stage, the viewer's Readiness tab (slice 5) prints the same checks[]. Building the check functions now, with cheap data-backed checks only, keeps 0.29.0 shippable while leaving named seams for 0.30's template parser, entity join, catalogue walk, probe runner and consistency scans.",
+  "tags": [
+    "capability:define-detection"
+  ]
+}

package/rcf/requirements/req-175.json

@@ -0,0 +1,25 @@
+{
+  "createdAt": "2026-09-24T14:30:00Z",
+  "updatedAt": "2026-09-24T14:30:00Z",
+  "reqId": "REQ-175",
+  "prdId": "PRD-001",
+  "title": "computeReadiness and the rcf define readiness CLI verb",
+  "description": "rcf-lite gains src/query/readiness.js with computeReadiness(tree, { freeze, ledgers, profile, testPointers }) returning the exact section 2.4 shape { tree, delta, stages, nextAction, coverage, decisions, freezeable }. computeReadiness composes computeDelta (slice 1), calls computeImpact once per id in changed union added (the union is the fan-out; impacted names every id, impactedFbs names the re-execute subset), runs the gates D1..D8 over scope = changed union added union impacted ids, calls computeCoverage tree-wide plus per REQ ancestor of the delta (using the testPointers map the CLI produces exactly as src/cli/coverage.js builds it), lists open decisions (in the #241 numbered format from the decisions ledger), derives a nextAction { stage, check, ids, command } from the first failing gate, and reports freezeable when every stage state is passed, acknowledged or notApplicable. rcf-lite also gains src/cli/readiness.js implementing rcf define readiness [--json] [--check <stage>|all] (stage accepts D1..D8 or the gate short name: brief, skeleton, shapes, stories, crosscut, consistency, decisions, freeze). Text output: tree line, next action, stage chips, delta list, failing items. --check exits 0 green, 4 red (matching coverage refusal exit); warn-with-ack stages failing but unacknowledged exit 0 with a visible warning. The producer is wrapped with runWithAdmissibilityGate as the ruleset toolScope requires. loadAllLedgers (src/define/ledgers.js) is corrected so a project that never authored a ledger does not get ledger:<name> hashes in the docHashes map (slice-1 P3 resolution: code and JSDoc agree that absent ledger files contribute no docHash).",
+  "category": "functional",
+  "domain": "defineDetection",
+  "priority": "must",
+  "version": "0.1.0",
+  "status": "draft",
+  "shapeClassification": {
+    "shapes": ["persistence"],
+    "reason": "keyword-scan",
+    "classifiedAt": "2026-09-24T14:30:00Z",
+    "signals": [
+      { "source": "description", "shape": "persistence", "match": "record" }
+    ]
+  },
+  "rationale": "Baz ruled on 2026-09-22 (proposal section 2.4, section 6, section 9 decision 4) that Readiness is one object rendered by two consumers (the CLI and the viewer tab) so the two cannot disagree. The Product Map precedent (PR #238) established the shape: one pure compute, one JSON envelope, two renderers. computeReadiness is the object; rcf define readiness is the CLI twin the viewer tab (REQ-180, slice 5) will render unchanged. Slice 3 (rcf define freeze) reads freezeable and the per-stage state and refuses on any failing stage; slice 4's bundle --next reads the same object; slice 6's guidance points at the CLI as the one 'am I ready to build' surface. Fixing the slice-1 P3 in the same slice as the reader that consumes it keeps the ledger docHash contract single-sourced before it stabilises across the fleet.",
+  "tags": [
+    "capability:define-detection"
+  ]
+}

package/rcf/tacs/tac-4103-feedback-redact.json

@@ -10,7 +10,7 @@
     "Apply the eight redaction rules from design section 5 to title, body and evidence strings",
     "Return a ledger of { rule, before, after, count } entries for the operator disclosure",
     "Refuse on residual-secret matches (second pass) with a line pointer so the offending body is not sent",
-    "Ship a bundled allowlist of vendor hosts and honour the extension array on rcf/feedback-settings.json",
+    "Ship a bundled allowlist of vendor hosts and an `extensions` shortlist on src/feedback/redact-allowlist.json (Barry ruling 2026-09-21); the operator's rcf/feedback-settings.json may still supply additional host and extension entries which are merged at call time (design amendment R5d)",
     "Guard operator-identity substitution with a RESERVED_IDENTITY_TOKENS stopword list (agent, user, admin, api, code, system, etc.) so a common noun in the operator's identity name never folds; substitution still fires for real given names in the identity"
   ],
   "internalStructure": "src/feedback/redact.js is a pure module: redact(text, context) -> { text, ledger[] } plus small per-rule helpers. src/feedback/redact-allowlist.json ships the vendor host set; the extension array is merged at call time.",
@@ -36,5 +36,5 @@
   "tradeoffs": "Rule-based redaction is testable with a fixture corpus and deterministic under review; the cost is that it will occasionally over-redact (a benign name that matches an entropy rule), which is what the disclosure ledger exists to catch.",
   "notes": "The stored entry is never mutated by redaction; the rendered output is what leaves.",
   "createdAt": "2026-09-16T13:45:23.000Z",
-  "updatedAt": "2026-09-17T13:47:09Z"
+  "updatedAt": "2026-09-22T00:00:00Z"
 }

package/rcf/tacs/tac-4120-define-delta-and-freeze.json

@@ -0,0 +1,21 @@
+{
+  "createdAt": "2026-09-24T12:00:00Z",
+  "updatedAt": "2026-09-24T12:00:00Z",
+  "tacId": "TAC-4120-define-delta-and-freeze",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "draft",
+  "name": "define delta compute and freeze record",
+  "purpose": "The detection-model primitives (hashDocument, computeTreeHash, computeDelta) live in a new pure module src/query/delta.js, exported from src/query/index.js alongside computeTrace, computeImpact and computeCoverage. The freeze record I/O sits in a new module src/define/freeze-record.js with a small local schema (until schemas 0.7 promotes it to manifest.freeze per ADR-4121). Both modules are pure per call: no filesystem I/O beyond the freeze reader / writer, no state, no time. Canonical JSON is defined on the parsed body, not the raw bytes: keys sorted recursively, no whitespace, JSON.stringify escaping. A whitespace-only reformat of a document produces the same hash; two objects that parse to the same value produce the same hash. Delta granularity is the standalone document: every id in tree.byId (PRD, TAD, BS, REQ, US, TAC, ADR, FBS, TS, CN, EVAL) contributes one docHash; inline AC / TC ride inside the parent's hash; the criterion-level diff is git's job (proposal section 2.2). Ledger docHashes are added under a ledger:<name> id per sidecar the caller passes in.",
+  "responsibilities": [
+    "src/query/delta.js: canonicaliseJson, hashDocument, computeTreeHash and computeDelta pure functions; JSDoc on computeDelta names the exact return shape AC-17201-1 pins.",
+    "src/query/index.js: re-export canonicaliseJson, hashDocument, computeTreeHash and computeDelta so every consumer imports through one seam.",
+    "src/define/freeze-record.js: FREEZE_RECORD_REL_PATH (rcf/define/freeze.json), FreezeRecordError, validateFreezeRecord, loadFreezeRecord (returns null on ENOENT, throws FreezeRecordError on parse or schema failure), saveFreezeRecord (validates then writes pretty JSON with trailing newline; creates rcf/define/ on demand).",
+    "Every hash is a 'sha256:<64-hex>' string; the record's docHashes values and treeHash are validated against that shape and rejected with a named field otherwise.",
+    "Extension fields (counts, litmus, versions, note, override, gates) survive a save / load round trip; the writer refuses to persist an invalid record so a bad in-memory value never lands on disk."
+  ],
+  "internalStructure": "canonicaliseJson recurses over parsed values: object keys sorted lexicographically, arrays kept in source order, JSON.stringify handles string / number / boolean escaping (non-finite numbers coerce to 'null' as JSON does), undefined is omitted from objects and arrays (matches JSON.stringify semantics). computeTreeHash normalises the input (Map or plain object) into sorted (id, docHash) pairs, canonically encodes the pair array, and hashes the resulting string; the tree hash is thereby order-independent by construction. computeDelta walks tree.byId once, hashes each doc, adds one ledger:<name> entry per non-nullish ledger the caller passes, then either returns the whole-tree 'added' shape (freeze absent) or classifies every id against freeze.docHashes; briefSince walks the brief ledger's statements[] and reports ids above freeze.briefStatements.",
+  "interfaces": [],
+  "notes": "Slice-2 hook: the readiness module will call computeDelta once per render, pass the result through computeImpact per changed id, and hand the union of changed + added + fan-out to every gate check. Slice 3 (the freeze verb) is the only caller of saveFreezeRecord in the shipped path; this slice ships the writer so the verb can be built without a second refactor."
+}

package/rcf/tacs/tac-4121-define-ledgers.json

@@ -0,0 +1,23 @@
+{
+  "createdAt": "2026-09-24T12:00:00Z",
+  "updatedAt": "2026-09-24T12:00:00Z",
+  "tacId": "TAC-4121-define-ledgers",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "draft",
+  "name": "define ledgers module and rcf define ledger CLI",
+  "purpose": "The four sidecar ledgers land under rcf/define/ as one JSON file each, with one numbered sequence per ledger for the life of the project. The pure module src/define/ledgers.js exposes LEDGER_NAMES (the four allowed values), BRIEF_KINDS, LedgerError, emptyLedger, ledgerRelPath, ledgerPath, loadLedger, saveLedger, validateLedger, addEntry, resolveEntry, nextIdFor, parseBriefFromFile and loadAllLedgers (returns a LedgerBundle for computeDelta). The CLI verb src/cli/ledger.js wraps the module with parseArgs, wires under bin/rcf.js's define group as GROUPS.define.ledger, and prints usage text also mounted in src/cli/help.js's HELP_MAP.define.ledger so `rcf help define ledger` and `rcf define ledger --help` render the same block by construction.",
+  "responsibilities": [
+    "src/define/ledgers.js: LEDGER_NAMES = ['brief','decisions','concerns','probes']; per-ledger config maps a name to its filename (brief-ledger.json, decisions-ledger.json, concern-ledger.json, probe-ledger.json) and its body array key (statements | decisions | concerns | probes).",
+    "loadLedger returns emptyLedger(name) on ENOENT; a malformed file raises LedgerError with a code ('parseFailure' | 'schemaFailure' | 'ioFailure' | 'usage') and a named field.",
+    "addEntry mints the next id (highest current + 1), stamps addedAt and defaults status open, validates the resulting body before returning it, refuses unknown BRIEF_KINDS at validation.",
+    "resolveEntry flips status to resolved, stamps resolvedAt, throws LedgerError code 'usage' when the id is unknown, is idempotent-ish (resolving twice refreshes resolvedAt).",
+    "parseBriefFromFile splits by non-empty lines, strips leading '- ', '* ' or '<n>. ' bullets, defaults kind to 'capability', and threads --source through to every draft.",
+    "src/cli/ledger.js: `rcf define ledger <name> <verb>` argv parsing; verbs add / resolve / list; ledger-specific flags for each; renderDecisionsList formats the #241 numbered layout; list --json emits { ledger, <arrayKey>: [...] }.",
+    "bin/rcf.js: register GROUPS.define.ledger; src/cli/help.js: import LEDGER_HELP and wire into HELP_MAP.define.ledger + DEFINE_HELP + top-level DEFINE listing so per-verb help stays single-sourced."
+  ],
+  "internalStructure": "The walker never reads under rcf/define/: subdirFor in src/core/store/loader.js returns null for anything that is not a known child kind (requirements, user-stories, tacs, adrs, fbs, test-suites, code-nodes, evals), so a ledger file sitting under rcf/define/ is never enumerated for schema validation. The walker-invisibility invariant is proved by a dedicated test that seeds the four ledger files plus a bug-bait req-shaped file under rcf/define/ and asserts zero walker error paths starting with rcf/define/ and no matching id in tree.byId. Validation is JSON-schema-shaped inline (no ajv, no @stravica-ai/rcf-schemas dependency) because the sidecars ride outside the shared schema until schemas 0.7 (ADR-4121).",
+  "interfaces": [],
+  "notes": "The intake-scan-against-frozen-statements hook on brief add --from is a named seam this slice leaves for a later one: 'rcf discover intake' is the intended caller in slice 2's D1 gate check, and this slice ensures the CLI has one place to inject that seam without a second refactor. `list --json` is a keep-alive for slice 5's viewer, which will render the same object over http."
+}

package/rcf/tacs/tac-4122-define-gates.json

@@ -0,0 +1,25 @@
+{
+  "createdAt": "2026-09-24T14:30:00Z",
+  "updatedAt": "2026-09-24T15:48:40Z",
+  "tacId": "TAC-4122-define-gates",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "draft",
+  "name": "define stage gates D1..D8",
+  "purpose": "src/query/gates.js lands as a new pure module beside delta.js. Every stage has one exported check function that takes (tree, context) and returns the { stage, gate, state, checks[] } shape section 2.4 pins. computeReadiness (TAC-4123) is the composer; every gate function is otherwise consumable in isolation for tests and for future viewers that render one stage. No I/O, no state, no time: the caller supplies ledgers, profile, freeze, delta, validate errors, probe count and coverage rollups.",
+  "responsibilities": [
+    "src/query/gates.js: STAGE_ORDER = ['D1','D2','D3','D4','D5','D6','D7','D8']; STAGE_GATES map (D1 -> 'define.brief' etc.); INTERFACE_KINDS closed set matching proposal section 5.2; STAGE_SHORT_NAMES map (D1 -> 'brief' etc.).",
+    "checkD1Brief: intake acknowledged (brief-ledger has at least one statement since the freeze high-water mark), every statement kinded from BRIEF_KINDS, every openQuestion statement resolved or promoted to a decisions-ledger entry, profile.md carries surface (viewer | runningApp | prDiff) and register (productOwner | engineer | unstated) markers.",
+    "checkD2Skeleton: every 'capability' and 'constraint' statement in scope resolves to a REQ (via a REQ id in the statement's resolvedBy field OR by name-match against a REQ title, cheap check); every REQ in scope has non-TODO description, shapeClassification and domain; TAD dataStores and coreEntities non-empty when any persistence REQ exists; exactly one deploy or deferral ADR tree-wide (title prefix 'Deploy target:' or 'Deploy deferral:').",
+    "checkD3Shapes: every TAC in scope has at least one interface; every interface's kind is in INTERFACE_KINDS. Template markers, entity join, ownerRef resolution and path resolution are seams (0.30).",
+    "checkD4Stories: every REQ in scope has at least one US (fbsByAcId inversion via reqByUs is enough); every US in scope has a testable AC (ac.testable !== false and description non-empty), a failure AC or a project-scoped or req-scoped opt-out with baselineKey 'defineD4:failure', a must-not AC or an opt-out with baselineKey 'defineD4:mustNot', tacIds non-empty and every id resolving to a walker-known TAC, and no AC description containing the scaffold TODO placeholder pattern (case-sensitive uppercase 'TODO:' with a colon -- the literal shape src/core/store/init.js writes; incidental prose mentioning 'todo' does NOT trip the gate, and the validate CLI's broader whole-word notice stays separate).",
+    "checkD5Crosscut: TAD.securityArchitecture non-empty when tree carries any REQ with shape 'auth' or 'httpApi'; TAD.operationalConcerns non-empty when any AC description carries the '[deployed]' marker; every concern-ledger entry on a REQ in scope has disposition applied or waived (no status 'open').",
+    "checkD6Consistency: caller-supplied validateErrors is empty (tree-wide); caller-supplied probeOpenCount is zero.",
+    "checkD7Decisions: no decisions-ledger entry with status 'open'.",
+    "checkD8Freeze: prior stages passed | acknowledged at the current tree hash; every AC id owned by exactly one FBS (walker.fbsByAcId length 1); computeQueue.nextActionable is not null (queue head actionable) and the head's title is not 'TODO' or empty; validateErrors empty."
+  ],
+  "internalStructure": "Every stage function follows the same shape: 1) decide notApplicable per section 3.2 and return { state: 'notApplicable' } with a single-check summary; 2) build checks[] as a list of { name, ok, over, pass, total, failing: [{ id, why }] }; 3) fold to state: 'passed' if every ok is true; 'failing' otherwise, unless the stage is D3/D5/D6 AND freeze.gates[<gate>].state === 'acknowledged' AND freeze.gates[<gate>].at.hash === currentTreeHash, in which case state is 'acknowledged'. Blocking-vs-warn is a property of the stage, not of the state: D3/D5/D6 use the acknowledged fold, D1/D2/D4/D7/D8 do not. The caller (readiness) folds the array of stage results into freezeable and nextAction.",
+  "interfaces": [],
+  "notes": "Slice-3 hook (rcf define freeze): reads state to refuse on any 'failing'; --ack <gate> --reason <text> writes freeze.gates[<gate>] = { state: 'acknowledged', at: { hash: <currentTreeHash>, reason: <text>, by: <id> } } and re-runs computeReadiness to check freezeable. Slice-5 hook (viewer): reads the same object end-to-end."
+}

package/rcf/tacs/tac-4123-define-readiness.json

@@ -0,0 +1,25 @@
+{
+  "createdAt": "2026-09-24T14:30:00Z",
+  "updatedAt": "2026-09-24T15:48:40Z",
+  "tacId": "TAC-4123-define-readiness",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "draft",
+  "name": "computeReadiness compute and rcf define readiness CLI",
+  "purpose": "src/query/readiness.js and src/cli/readiness.js land as a matched pair. The pure module composes computeDelta, computeImpact, the eight gate check functions from TAC-4122, computeCoverage, and the decisions ledger into the single-object contract section 2.4 pins; the CLI is its twin. Text output for readable status; --json for machine consumers and the viewer slice; --check <stage>|all for targeted inspection with the same 0-green / 4-red exit shape rcf audit coverage uses.",
+  "responsibilities": [
+    "src/query/readiness.js: computeReadiness(tree, { freeze, ledgers, profile, testPointers }) returns { tree, delta, stages, nextAction, coverage, decisions, freezeable } exactly as section 2.4 specifies; internal computeScope collects changed + added + impacted ids into a Set; internal composeStages calls each check function in D1..D8 order; internal computeNextAction picks the first failing stage and check; internal deriveTreeSummary shortens the tree hash to eight characters for the tree line.",
+    "src/query/readiness.js: computeImpact is called once per id in changed union added; impacted is the deduplicated union of every impact node id excluding the pivots; impactedFbs is the subset with kind 'fbs' AND actionNeeded === 're-execute'.",
+    "src/query/readiness.js: computeCoverage is called once tree-wide (strict per-AC, testPointers threaded through) for coverage.tree; coverage.delta is one CoverageResult per unique REQ ancestor of the delta ids (via tree.parentByChild walk to the reqId, or the doc's own reqId field).",
+    "src/query/readiness.js: freezeable is true when every stage state in ['passed', 'acknowledged', 'notApplicable'] and false otherwise; nextAction is null when freezeable is true.",
+    "src/cli/readiness.js: parseArgs on --json, --check, --help; findProjectRoot; walkTree; loadFreezeRecord; loadAllLedgers; resolveTestPointers; runWithAdmissibilityGate wraps a producer that invokes computeReadiness; on refuse the CLI prints an informational '[warn] readiness: chain admissibility refused (informational; the readiness compute still ran).' on stderr and STILL runs the compute so the diagnostic reports which stage blocks (readiness is a diagnostic, not a gate that hides its answer); the top-level exit stays 0 in that case and --check <stage> follows its normal per-stage exit rule; on ok the CLI renders text (default) or JSON.",
+    "src/cli/readiness.js: text output = tree line, next-action line, chip line (D1..D8 with state color words), stage-by-stage failing items (checks with failing ids); --check exits 4 for a blocking stage that is failing, 0 with a stderr [warn] for a warn-with-ack stage that is failing but not acknowledged, 0 otherwise.",
+    "src/define/ledgers.js (P3 resolution): loadAllLedgers checks each ledger file's existence with statPath and omits missing files from the returned bundle; loadLedger keeps returning an empty ledger on ENOENT so single-ledger callers retain the ergonomic default.",
+    "bin/rcf.js: register GROUPS.define.readiness -> readinessMain; src/cli/help.js: import READINESS_HELP and wire into HELP_MAP.define.readiness + DEFINE_HELP + top-level DEFINE listing.",
+    "src/query/index.js: export computeReadiness (plus its subhelpers where useful for tests) so downstream consumers (slice 3 freeze, slice 5 viewer) import through the same seam every other query verb does."
+  ],
+  "internalStructure": "readiness.js is a linear composer: 1) compute delta and its docHashes; 2) fan-out impacted / impactedFbs; 3) build stage context (freeze, delta, scope, ledgers, profile, validateErrors, probeOpenCount, coverageTree); 4) call the eight check functions; 5) fold freezeable and nextAction. The CLI parses flags, loads the tree once, loads the four ledgers and the freeze record once, computes the readiness, then routes to the text or JSON emitter. --check maps its argument to the STAGE_SHORT_NAMES map (brief -> D1 ... freeze -> D8) or accepts D1..D8 directly. The runWithAdmissibilityGate wrap sits inside main so refusals ride the same exit path as coverage's admissibility refusals.",
+  "interfaces": [],
+  "notes": "Slice-3 hook (rcf define freeze) reads freezeable and stages[].state; --ack <gate> writes into freeze.gates[<gate>] and re-computes readiness. Slice-5 hook (viewer) fetches the same JSON object over the existing tab wire and renders the pill vocabulary + findings-list + diff components. Performance seam: computeImpact per id on a whole-tree delta (before freeze) may be quadratic on very large trees; the compute stays fast on the dogfood chain (~700 documents, sub-second) but the CLI notes the wall time in text mode so an operator can spot regression."
+}

package/rcf/test-suites/ts-188.json

@@ -1,6 +1,6 @@
 {
   "createdAt": "2026-09-16T15:27:35Z",
-  "updatedAt": "2026-09-17T13:47:28Z",
+  "updatedAt": "2026-09-22T00:00:00Z",
   "purpose": "Cover AC-15601-1 (rcf feedback preview renders each pending entry as the title and body that would be filed, lists the destination, and prints the redaction ledger over the full eight-rule vocabulary), AC-15601-2 (preview marks residual-secret findings so the operator sees before consenting; the submit half of AC-15601-2 lands with slice 4), AC-15601-3 (preview never mutates the stored entries.jsonl), AC-15601-4 (a final whole-text residual-secret pass on the fully rendered and normalised issue body and each bundle refuses submit on any hit) and AC-15701-1 (a stable 12-hex fingerprint is attached per entry, folds across blueprint versions when the anchor+class match, and falls back to normalised-title tokens with a warning when the anchor is absent).",
   "testLevel": "integration",
   "acIds": [
@@ -9,7 +9,8 @@
     "AC-15601-3",
     "AC-15601-4",
     "AC-15701-1",
-    "AC-15601-5"
+    "AC-15601-5",
+    "AC-15601-6"
   ],
   "id": "TS-188",
   "usId": "US-15601",
@@ -168,6 +169,13 @@
       "description": "Cover AC-15601-5 via the unit test: redact runs over a body containing the docs URL 'https://stravica.ai/docs/rcf/how-the-agent-files-feedback', the prose 'when the agent stops the queue' and the personal name 'Alice reviewed this', with operatorName seeded as 'The Agent Alice'; the docs URL is emitted verbatim; the prose 'when the agent stops the queue' is emitted verbatim; 'Alice' folds to <operator>; no operator-identity ledger row names 'agent' or 'the'.",
       "status": "pending",
       "testPointer": "test/feedback/redact.test.js::AC-15601-5 operator-identity stopword guard: common nouns in the identity string are never folded; real given names still fold"
+    },
+    {
+      "id": "TC-188-redact-filename-extensions-allowlist",
+      "acId": "AC-15601-6",
+      "description": "Cover AC-15601-6 via the unit test: redact runs over a body containing 'Backstory-product-brief.md', 'intake.json', 'report.log', 'foo.example.com', 'foo.example.com/path', 'Backstory-example.com' and 'a.b.c'; the three filename tokens survive verbatim with no hostname ledger row; foo.example.com folds to <host>; foo.example.com/path folds via the URL rule; Backstory-example.com folds; a.b.c folds; extending redact-allowlist.json extensions with 'xyz' also lets 'file.xyz' survive.",
+      "status": "pending",
+      "testPointer": "test/feedback/redact.test.js::AC-15601-6 filename tokens carrying a known extension survive rule 4"
     }
   ],
   "status": "draft"

package/rcf/test-suites/ts-191.json

@@ -1,6 +1,6 @@
 {
   "createdAt": "2026-09-16T17:23:12Z",
-  "updatedAt": "2026-09-16T17:23:12Z",
+  "updatedAt": "2026-09-22T00:00:00Z",
   "purpose": "Cover AC-15701-2 (submit calls gh search + create/comment per the zero/one/many hit table) and AC-15701-3 (search unavailable falls through to create with dedupe: unchecked; closed-state hit stamps a previously reported reference into the create body). Slice 4 arm of US-15701.",
   "testLevel": "integration",
   "acIds": [
@@ -21,16 +21,16 @@
     {
       "id": "TC-191-submit-one-hit-comments",
       "acId": "AC-15701-2",
-      "description": "Cover AC-15701-2 (one-hit arm) via the CLI test: with matches returning one issue, submit calls ghIssueComment on that number and no ghIssueCreate.",
+      "description": "Cover AC-15701-2 (one-hit verified arm, 0.28.2 #234) via the CLI test: with the fake returning one search match whose body carries the same fingerprint line, submit calls ghIssueGetBody to verify, then ghIssueComment on that number with the full report; no ghIssueCreate.",
       "status": "pending",
-      "testPointer": "test/cli/feedback-submit.test.js::AC-15701-2: one-hit search calls gh issue comment on that number"
+      "testPointer": "test/cli/feedback-submit.test.js::AC-15701-2: a verified fingerprint match folds via comment; comment body carries the full report; stdout names the matched title"
     },
     {
       "id": "TC-191-submit-many-hit-comment-lowest",
       "acId": "AC-15701-2",
-      "description": "Cover AC-15701-2 (many-hit arm) via the CLI test: with three matches returning numbers 30/12/47, submit comments on #12 (lowest) and the body mentions #30 and #47.",
+      "description": "Cover AC-15701-2 (many verified matches arm, 0.28.2 #234) via the CLI test: with three matches whose bodies all carry the entry's fingerprint line, submit comments on the lowest number and the comment body carries the full report + mentions of the other numbers.",
       "status": "pending",
-      "testPointer": "test/cli/feedback-submit.test.js::AC-15701-2: many-hit search comments on the lowest number and names the others"
+      "testPointer": "test/cli/feedback-submit.test.js::AC-15701-2: many verified fingerprint matches fold on the lowest number and mention the others"
     },
     {
       "id": "TC-191-submit-search-unchecked",
@@ -45,6 +45,20 @@
       "description": "Cover AC-15701-3 (closed-hit arm) via the CLI test: with open search empty and closed search returning #88, submit creates a new issue whose body carries 'Previously reported and closed as #88'.",
       "status": "pending",
       "testPointer": "test/cli/feedback-submit.test.js::AC-15701-3: closed-state hit produces a create with previously reported reference"
+    },
+    {
+      "id": "TC-191-submit-fingerprint-mismatch-creates",
+      "acId": "AC-15701-2",
+      "description": "Cover AC-15701-2 (fingerprint-verification arm, 0.28.2 #234) via the CLI test: a search hit whose body carries a DIFFERENT fingerprint line is a non-match; submit falls through to create rather than comment.",
+      "status": "pending",
+      "testPointer": "test/cli/feedback-submit.test.js::AC-15701-2: a search hit whose body carries a DIFFERENT fingerprint is a non-match; submit creates rather than comments"
+    },
+    {
+      "id": "TC-191-submit-anchor-mismatch-creates",
+      "acId": "AC-15701-2",
+      "description": "Cover AC-15701-2 (refuse fold across differing anchor/target arm, 0.28.2 #234) via the CLI test: a fingerprint match against a candidate whose anchor disagrees is refused; submit creates rather than comments.",
+      "status": "pending",
+      "testPointer": "test/cli/feedback-submit.test.js::AC-15701-2: a fingerprint match against a candidate whose anchor disagrees is refused; submit creates rather than comments"
     }
   ],
   "status": "draft"

package/rcf/test-suites/ts-204.json

@@ -0,0 +1,30 @@
+{
+  "id": "TS-204",
+  "usId": "US-17001",
+  "title": "Product Map shape grouping",
+  "purpose": "Cover the shape-grouping renderer and its drill-down for AC-17001-1 and AC-17001-2.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17001-1",
+    "AC-17001-2"
+  ],
+  "testCases": [
+    {
+      "id": "TC-204-shape-buckets-present",
+      "acId": "AC-17001-1",
+      "description": "Rendering the tree emits a product-map tab with shape buckets covering every classified shape plus Unclassified and Business rules.",
+      "status": "passing",
+      "testPointer": "test/view/product-map.test.js::product-map shape grouping renders one bucket per shape plus Unclassified and Business rules"
+    },
+    {
+      "id": "TC-204-shape-drill-req-us-ac",
+      "acId": "AC-17001-2",
+      "description": "The shape grouping drills bucket -> REQ (status pill) -> US -> AC using the shared detailsWrap helper; every id inside the Product Map tab is bucket-scoped so the same REQ can appear under multiple buckets without duplicating ids.",
+      "status": "passing",
+      "testPointer": "test/view/product-map.test.js::product-map shape grouping drills bucket to REQ to US to AC with status pill, ids scoped to the bucket (P2-1)"
+    }
+  ],
+  "status": "approved",
+  "createdAt": "2026-09-21T17:00:00.000Z",
+  "updatedAt": "2026-09-21T18:02:10.540Z"
+}

package/rcf/test-suites/ts-205.json

@@ -0,0 +1,22 @@
+{
+  "id": "TS-205",
+  "usId": "US-17002",
+  "title": "Product Map status filter",
+  "purpose": "Cover AC-17002-1: status filter control and empty-bucket collapse.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17002-1"
+  ],
+  "testCases": [
+    {
+      "id": "TC-205-status-filter-control",
+      "acId": "AC-17002-1",
+      "description": "The tab renders a status filter with six options; server-rendered outer pm-req counts per status match a model-side prediction across every grouping (the same DOM the client-side applyPmStatusFilter reads).",
+      "status": "passing",
+      "testPointer": "test/view/product-map.test.js::product-map status filter markup + server-rendered per-bucket status counts match the model (P2-3 real assertion)"
+    }
+  ],
+  "status": "approved",
+  "createdAt": "2026-09-21T17:00:00.000Z",
+  "updatedAt": "2026-09-21T18:02:10.757Z"
+}

package/rcf/test-suites/ts-206.json

@@ -0,0 +1,22 @@
+{
+  "id": "TS-206",
+  "usId": "US-17003",
+  "title": "Product Map component grouping",
+  "purpose": "Cover AC-17003-1: TAD-rooted TAC hierarchy with Unmapped bucket.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17003-1"
+  ],
+  "testCases": [
+    {
+      "id": "TC-206-component-tad-root",
+      "acId": "AC-17003-1",
+      "description": "Component grouping shows TAD -> TAC (with dependencies) -> US -> REQ -> AC, with an Unmapped bucket for REQs no component reaches.",
+      "status": "passing",
+      "testPointer": "test/view/product-map.test.js::product-map component grouping roots at TAD and lists TAC to US to REQ to AC with an Unmapped bucket"
+    }
+  ],
+  "status": "approved",
+  "createdAt": "2026-09-21T17:00:00.000Z",
+  "updatedAt": "2026-09-21T17:00:00.000Z"
+}

package/rcf/test-suites/ts-207.json

@@ -0,0 +1,22 @@
+{
+  "id": "TS-207",
+  "usId": "US-17004",
+  "title": "Product Map trace coverage",
+  "purpose": "Cover AC-17004-1: each REQ bucketed by trace completeness with a plain-text \"what is missing\" line.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17004-1"
+  ],
+  "testCases": [
+    {
+      "id": "TC-207-trace-coverage-buckets",
+      "acId": "AC-17004-1",
+      "description": "Trace coverage grouping buckets each REQ into the FIRST bucket whose rule it meets (missing-stories, missing-ac-scope, missing-component, missing-tests, complete); a synthetic fixture asserts the classification per REQ id, including the P1-4 dangling-TAC case landing in missing-component.",
+      "status": "passing",
+      "testPointer": "test/view/product-map.test.js::product-map trace coverage places each REQ in the FIRST bucket whose condition it meets, on a synthetic fixture (P2-3)"
+    }
+  ],
+  "status": "approved",
+  "createdAt": "2026-09-21T17:00:00.000Z",
+  "updatedAt": "2026-09-21T18:02:10.973Z"
+}

package/rcf/test-suites/ts-208.json

@@ -0,0 +1,22 @@
+{
+  "id": "TS-208",
+  "usId": "US-17005",
+  "title": "Product Map capability grouping",
+  "purpose": "Cover AC-17005-1: capability:<slug> tag consumption and Unclassified bucket.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17005-1"
+  ],
+  "testCases": [
+    {
+      "id": "TC-208-capability-buckets",
+      "acId": "AC-17005-1",
+      "description": "Capability grouping enumerates one bucket per distinct capability:<slug> tag; multi-tag REQs appear in each bucket; untagged REQs go to Unclassified.",
+      "status": "passing",
+      "testPointer": "test/view/product-map.test.js::product-map capability grouping enumerates one bucket per capability slug with Unclassified for untagged REQs"
+    }
+  ],
+  "status": "approved",
+  "createdAt": "2026-09-21T17:00:00.000Z",
+  "updatedAt": "2026-09-21T17:00:00.000Z"
+}

package/rcf/test-suites/ts-209.json

@@ -0,0 +1,22 @@
+{
+  "id": "TS-209",
+  "usId": "US-17101",
+  "title": "Dogfood REQs carry capability tags",
+  "purpose": "Cover AC-17101-1: every REQ file carries at least one capability:<slug> tag drawn from the documented taxonomy.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17101-1"
+  ],
+  "testCases": [
+    {
+      "id": "TC-209-every-req-has-capability-tag",
+      "acId": "AC-17101-1",
+      "description": "Every requirement file under packages/rcf-lite/rcf/requirements/ carries at least one capability:<slug> tag, and each slug is listed in docs/capability-tags.md.",
+      "status": "passing",
+      "testPointer": "test/view/capability-tags.test.js::every dogfood REQ carries at least one capability tag mapped to a documented slug"
+    }
+  ],
+  "status": "approved",
+  "createdAt": "2026-09-21T17:00:00.000Z",
+  "updatedAt": "2026-09-21T17:00:00.000Z"
+}

package/rcf/test-suites/ts-210.json

@@ -0,0 +1,22 @@
+{
+  "id": "TS-210",
+  "usId": "US-17102",
+  "title": "Capability taxonomy documented",
+  "purpose": "Cover AC-17102-1: docs/capability-tags.md exists and is linked from docs/README.md.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17102-1"
+  ],
+  "testCases": [
+    {
+      "id": "TC-210-taxonomy-doc-present",
+      "acId": "AC-17102-1",
+      "description": "docs/capability-tags.md exists, lists every taxonomy slug with a one-line meaning, states the \"add a capability\" rule, and is linked from docs/README.md.",
+      "status": "passing",
+      "testPointer": "test/view/capability-tags.test.js::docs carry the capability taxonomy and link to it from the docs README"
+    }
+  ],
+  "status": "approved",
+  "createdAt": "2026-09-21T17:00:00.000Z",
+  "updatedAt": "2026-09-21T17:00:00.000Z"
+}

package/rcf/test-suites/ts-211.json

@@ -0,0 +1,22 @@
+{
+  "createdAt": "2026-09-21T18:46:16.398Z",
+  "updatedAt": "2026-09-21T18:46:16.604Z",
+  "purpose": "Cover the collapsed-by-default buckets, jump-nav rail, per-status mini counts, expand/collapse-all and open-bucket hash restore for AC-17006-1.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17006-1"
+  ],
+  "id": "TS-211",
+  "usId": "US-17006",
+  "title": "Product Map interaction model",
+  "testCases": [
+    {
+      "id": "TC-211-interaction-model-buckets",
+      "acId": "AC-17006-1",
+      "description": "Every bucket renders as a collapsed <details class=pm-bucket> with a per-status mini row and a jump-nav chip row per grouping.",
+      "status": "pending",
+      "testPointer": "test/view/product-map.test.js::product-map buckets are <details class=\"pm-bucket\"> collapsed by default with a per-status mini row (AC-17006-1)"
+    }
+  ],
+  "status": "draft"
+}

package/rcf/test-suites/ts-212.json

@@ -0,0 +1,22 @@
+{
+  "createdAt": "2026-09-21T18:46:16.821Z",
+  "updatedAt": "2026-09-21T18:46:17.106Z",
+  "purpose": "Cover the initial-render skeletons and raw-JSON suppression the lazy render depends on for AC-17007-1.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17007-1"
+  ],
+  "id": "TS-212",
+  "usId": "US-17007",
+  "title": "Product Map lazy first-load payload",
+  "testCases": [
+    {
+      "id": "TC-212-lazy-skeletons",
+      "acId": "AC-17007-1",
+      "description": "Initial contentHtml emits data-pm-lazy=true skeletons for every grouping and never inlines a raw-JSON disclosure inside a pm-req card.",
+      "status": "pending",
+      "testPointer": "test/view/product-map.test.js::product-map lazy render: initial contentHtml emits skeletons for every grouping (AC-17007-1)"
+    }
+  ],
+  "status": "draft"
+}

package/rcf/test-suites/ts-213.json

@@ -0,0 +1,50 @@
+{
+  "createdAt": "2026-09-22T11:59:39Z",
+  "updatedAt": "2026-09-22T15:00:00Z",
+  "purpose": "Cover the blueprint badge on every REQ row and the by-blueprint grouping (bucket per applied blueprint plus Application bucket, capability second level, hash round-trip, /product-map/blueprint partial endpoint) for AC-17008-1.",
+  "testLevel": "integration",
+  "acIds": [
+    "AC-17008-1"
+  ],
+  "id": "TS-213",
+  "usId": "US-17008",
+  "title": "Product Map by-blueprint grouping and blueprint badge",
+  "testCases": [
+    {
+      "id": "TC-213-badge",
+      "acId": "AC-17008-1",
+      "description": "In the shape grouping rendered over a fixture project that applies one blueprint contributing two REQs, both contributed REQ rows carry a pm-blueprint-badge in their summary while the non-blueprint (Application) REQ rows do not.",
+      "status": "pending",
+      "testPointer": "test/view/product-map.test.js::product-map: blueprint badge on every contributed REQ row across groupings (AC-17008-1)"
+    },
+    {
+      "id": "TC-213-buckets",
+      "acId": "AC-17008-1",
+      "description": "The by-blueprint grouping over a fixture with one applied blueprint (2 contributed REQs) and 2 non-blueprint REQs renders exactly two buckets: a blueprint bucket with count 2 and an Application bucket with count 2.",
+      "status": "pending",
+      "testPointer": "test/view/product-map.test.js::product-map: by-blueprint grouping yields one bucket per applied blueprint plus an Application bucket (AC-17008-1)"
+    },
+    {
+      "id": "TC-213-capability-second-level",
+      "acId": "AC-17008-1",
+      "description": "Inside each by-blueprint bucket the second level is capability (existing capability:<slug> tags), then requirement rows, then the usual drill-down.",
+      "status": "pending",
+      "testPointer": "test/view/product-map.test.js::product-map: by-blueprint bucket second level is capability then REQ (AC-17008-1)"
+    },
+    {
+      "id": "TC-213-hash-and-lazy-endpoint",
+      "acId": "AC-17008-1",
+      "description": "The inline script's PM_GROUPS constant lists 'blueprint', the lazy fetch endpoint /product-map/blueprint is exposed on the pre-rendered pmPartials, and renderProductMapGrouping(model, 'blueprint') returns a non-empty string.",
+      "status": "pending",
+      "testPointer": "test/view/product-map.test.js::product-map: by-blueprint grouping wired into PM_GROUPS, pmPartials and renderProductMapGrouping (AC-17008-1)"
+    },
+    {
+      "id": "TC-213-empty-blueprints",
+      "acId": "AC-17008-1",
+      "description": "A project with no applied blueprints (manifest.blueprints empty) renders the by-blueprint grouping with a single Application bucket and no error banner.",
+      "status": "pending",
+      "testPointer": "test/view/product-map.test.js::product-map: by-blueprint grouping on a project with no applied blueprints renders a single Application bucket (AC-17008-1)"
+    }
+  ],
+  "status": "draft"
+}