rcf-lite 0.28.2 → 0.29.0

package/rcf/user-stories/us-17601.json

@@ -0,0 +1,58 @@
+{
+  "usId": "US-17601",
+  "prdId": "PRD-001",
+  "reqId": "REQ-176",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "rcf define freeze runs readiness, refuses on failing, writes freeze.json and prints the section 2.5 summary",
+  "description": "User story under REQ-176. The freeze verb is the only close verb: no change-object is minted, nothing else changes state. It reads the live tree via computeReadiness, refuses on any failing stage (accepting acks only on the three warn-with-ack gates), and writes the freeze record slice 4's bundle --next and slice 5's viewer will read.",
+  "asA": "an operator wrapping up a change on the tree",
+  "iWant": "one command that says 'yes freezeable and I have written the record' or 'no here is the gate that blocks and its first failing ids', accepts --ack on the three warn-first gates with a mandatory reason, and prints a summary line I can paste into a commit message",
+  "soThat": "the freeze record is authoritative for slice 4's bundle --next and slice 5's viewer, and the same rules that gate readiness also gate the freeze",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-17601-1",
+      "description": "[happy] rcf define freeze runs computeReadiness once over walkTree(projectRoot) plus loadFreezeRecord and loadAllLedgers. When result.freezeable is true, it writes rcf/define/freeze.json via saveFreezeRecord with these fields: frozenAt (ISO UTC now), treeHash (result.tree.currentTreeHash), docHashes (delta.js currentHashes over the live tree plus 'ledger:<name>' for each ledger present), briefStatements (the count of statements in the brief ledger, ledgers.brief.statements.length or 0), gates (one entry per stage-gate with { state, at: { hash, at, reason?, by? } | null, failing: [{ id, why }] } from the live readiness plus any --ack entries), counts { req, us, ac, acByClass: { happy, edge, failure, mustNot, nonFunctional, unclassified }, tac, interfaces: { <kind>: n, ... }, adr, fbs }, litmus { attestedAt, readers: 0 }, versions { rcfLite, ruleset, schemas } read from package.json, src/ruleset/ruleset.json and node_modules/@stravica-ai/rcf-schemas/package.json, note (--note argument or null), override (always null on a fresh freeze). The verb exits 0. Immediately after the write, calling computeDelta over the live tree + the new freeze reports every list empty (changed / added / removed / briefSince).",
+      "testable": true
+    },
+    {
+      "id": "AC-17601-2",
+      "description": "[failure] When result.freezeable is false and no --ack argument covers the failing stage, the verb exits 4 without writing the freeze record. It prints the failing gates (one per line: '<stage> (<gate>): failing (<first check name>); failing ids: <id1>, <id2>, ...' capped at 20 ids per gate) to stderr, followed by the exact rcf define readiness --check <shortName> command that will re-print the same block for each failing stage. The file at rcf/define/freeze.json is not created or modified (a pre-existing file is byte-identical after the refusal).",
+      "testable": true
+    },
+    {
+      "id": "AC-17601-3",
+      "description": "[failure] --ack <gate> --reason <text> is accepted only for the three warn-with-ack gates: define.shapes / D3 / shapes, define.crosscut / D5 / crosscut, define.consistency / D6 / consistency (the same STAGE_ALIASES readiness accepts). --ack on any other gate name is a usage refusal (exit 2) with a stderr message naming the accepted set. --ack without a matching --reason argument is a usage refusal (exit 2). Multiple --ack / --reason pairs may be passed together (parseArgs multiple: true) as long as the count matches; a mismatch is a usage refusal. An acked gate lands in the written freeze.gates entry as { state: 'acknowledged', at: { hash: <currentTreeHash>, at: <frozenAt>, reason: <text>, by: <freezerId or null> }, failing: [<id>, ...] } and its acknowledgement carries into the next computeReadiness run (which reports the stage state as 'acknowledged').",
+      "testable": true
+    },
+    {
+      "id": "AC-17601-4",
+      "description": "[happy] The stdout summary derived from the delta BEFORE the freeze matches proposal section 2.5: 'frozen at <shortHash>: <n> REQ, <n> stories, <n> criteria, <n> interfaces added; <ids> amended; <impactedFbs> re-execute.' Counts of added come from delta.added grouped by tree.kindById; amended is delta.changed (US ids in the amended list per the proposal's example wording); impactedFbs is delta.impactedFbs. On the first freeze (freeze record absent before the run), the summary is 'first freeze at <shortHash>: <req> REQ, <us> stories, <ac> criteria, <interfaces> interfaces, <tac> TAC, <adr> ADR, <fbs> FBS.' --json emits { record, summary, delta } where record is the just-written freeze record body and delta is the pre-freeze DeltaResult.",
+      "testable": true
+    },
+    {
+      "id": "AC-17601-5",
+      "description": "[happy] --status prints the current record and the live delta summary, exit 0. Text: 'Frozen at <short> on <frozenAt>. Note: <note|(none)>. Counts: <req> REQ / <us> US / <ac> AC / <tac> TAC / <adr> ADR / <fbs> FBS. Acknowledged: <gate1> (\"<reason>\"); <gate2> ...(none). Litmus: attestedAt [<D3>, <D6>], readers <n>. Versions: rcfLite <v> / ruleset <v> / schemas <v>. Override: <null|<reason by at>>.' followed by the live delta summary line: '<changed> changed, <added> added, <removed> removed, <impacted> impacted, <impactedFbs> FBS re-execute.' --status --json emits { record: <freeze body>, delta: <computeDelta output> }. --status when no record exists prints 'never frozen' and exits 0 (--json: { record: null, delta: <computeDelta output over unfrozen tree> }). --status never runs the gates and never writes anything.",
+      "testable": true
+    },
+    {
+      "id": "AC-17601-6",
+      "description": "[happy] The freeze producer is wrapped with runWithAdmissibilityGate the same way readiness is (ADR-4124 carrying ADR-4123): the wrap runs first so the ruleset toolScope guard is honoured, and on a refused-admissibility verdict the CLI prints the refusal envelope to stderr as a [warn] line and the freeze compute still runs and writes if freezeable. The verb never exits 4 solely because of a refused-admissibility verdict.",
+      "testable": true
+    },
+    {
+      "id": "AC-17601-7",
+      "description": "[must-not] src/define/freeze-record.js is updated so validateFreezeRecord REQUIRES the override key (nullable): a body without override throws FreezeRecordError with field 'override'. loadFreezeRecord tolerates older records that lack the key by defaulting to null (never fails on ENOKEY). saveFreezeRecord validates first and refuses to write a body that omits override. Every existing test fixture that omits override still loads (either the loader default fills it in, or a targeted fixture update writes override: null; no legacy fixture becomes unreadable).",
+      "testable": true
+    },
+    {
+      "id": "AC-17601-8",
+      "description": "[non-functional] The src/cli/readiness.js stage header line no longer contains a double-dash: it uses a colon between the stage id and the state label ('D1 (define.brief): failing'). The CHANGELOG.md line 'The regex is now `/\\bTODO:/` -- case-sensitive uppercase `TODO`' is likewise rewritten to a colon. Any golden fixture that captured the old header text is updated. `grep -R ' -- ' src/ test/ CHANGELOG.md` returns no matches under text this slice added or edited (the grep is scoped to added lines; unrelated pre-existing occurrences elsewhere in the tree stay out of scope of the AC).",
+      "testable": true
+    }
+  ],
+  "tacIds": ["TAC-4124-define-freeze"],
+  "tags": [],
+  "createdAt": "2026-09-24T16:33:15Z",
+  "updatedAt": "2026-09-24T16:33:15Z"
+}

package/rcf/user-stories/us-18001.json

@@ -0,0 +1,55 @@
+{
+  "usId": "US-18001",
+  "prdId": "PRD-001",
+  "reqId": "REQ-180",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "Readiness as the first tab in the viewer",
+  "description": "User story under REQ-180. Opening the viewer puts Readiness first (default active tab), the former Overview tab is renamed PRD with its content preserved, the two level verdict pills carry the formatVerdictLines strings as labels, blockers group by persona ordered by the profile.md register (the non-register group collapses with its count visible, never omitted), and the Freeze now control is enabled iff levels.readyToBuild.ok. See the DEFINE step 2 spec dated 2026-10-01 (section 5) for the layout.",
+  "asA": "an operator opening the viewer",
+  "iWant": "Readiness as the first tab with the two verdict pills and persona-grouped blockers",
+  "soThat": "the first thing I see is whether I can build and whose questions stand in the way",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18001-1",
+      "description": "[happy] Given any project, when the viewer renders, then the first tab is Readiness and the second is PRD with the former Overview content unchanged.",
+      "testable": true
+    },
+    {
+      "id": "AC-18001-2",
+      "description": "[happy] Given a failing tree, when the Readiness tab renders, then it shows two verdict pills whose labels equal the formatVerdictLines strings for the same tree.",
+      "testable": true
+    },
+    {
+      "id": "AC-18001-3",
+      "description": "[happy] Given personas.productOwner.blockers non-empty, when the tab renders, then each blocker is a findings list headed by its question with its ids as anchor links into the document tabs.",
+      "testable": true
+    },
+    {
+      "id": "AC-18001-4",
+      "description": "[happy] Given a profile register of productOwner, when the tab renders, then the product-owner group is expanded first and the engineer group is collapsed with its count visible.",
+      "testable": true
+    },
+    {
+      "id": "AC-18001-5",
+      "description": "[must-not] Given any profile register, when the tab renders, then no blocker id of either persona is omitted from the DOM.",
+      "testable": true
+    },
+    {
+      "id": "AC-18001-6",
+      "description": "[failure] Given a tree where levels.readyToBuild.ok is false, when the tab renders, then the Freeze now control is disabled and names the failing gates from levels.readyToBuild.blockedBy.",
+      "testable": true
+    },
+    {
+      "id": "AC-18001-7",
+      "description": "[happy] Given the tab and the CLI --json output for the same tree hash, when compared, then every id rendered on the tab appears in the JSON for that hash.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4127-readiness-view"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-01T18:00:00Z",
+  "updatedAt": "2026-10-01T18:00:00Z"
+}

package/rcf/user-stories/us-18002.json

@@ -0,0 +1,35 @@
+{
+  "usId": "US-18002",
+  "prdId": "PRD-001",
+  "reqId": "REQ-180",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "the Readiness tab renders question cards grouped by source span",
+  "description": "User story under REQ-180, reserved by DEFINE step 3 spec section 11.8 and authored here by the viewer UI refresh PR 8. The Readiness tab leads with the product owner's three questions in plain words: two VerdictCards from `levels` (Ready for engineers, Ready to build, each with its chain term `intent-complete` or `ready-to-build` muted beside the plain label; both cards rendered at equal height), QuestionCards grouped by source span (one group per blocker; one card per failing item, phrasebook-sourced today, swapping to `readiness.questions[]` when DEFINE step 3 PR 2 ships `computeQuestions`), a what-happens-next paragraph, and a Requirements that still need work table. Every engineer-level finding stays on the page one level down in one collapsed `For engineers` DocRow (closed in the productOwner register, open in engineer; never removed from the DOM). The adapter seam `toQuestions(readiness)` is a pure module reading blockers today and feature-detecting `readiness.questions` tomorrow.",
+  "asA": "a product owner opening the Readiness tab",
+  "iWant": "the questions waiting on me in plain words, grouped by their source span, without ids or stage codes",
+  "soThat": "I can answer them in my own session and see the hand-over state update as I go",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18002-1",
+      "description": "[happy] given questions[] non-empty, when the tab renders, then the block lists each group with its asks and every id is in the JSON.",
+      "testable": true
+    },
+    {
+      "id": "AC-18002-2",
+      "description": "[failure] given questions[] empty, when the tab renders, then the block shows the intent-complete verdict line.",
+      "testable": true
+    },
+    {
+      "id": "AC-18002-3",
+      "description": "[must-not] given any register, when the tab renders, then the engineer blockers are not removed from the DOM.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4133-readiness-po-layer"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-02T19:30:00Z",
+  "updatedAt": "2026-10-02T19:30:00Z"
+}

package/rcf/user-stories/us-18101.json

@@ -0,0 +1,35 @@
+{
+  "usId": "US-18101",
+  "prdId": "PRD-001",
+  "reqId": "REQ-181",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "Shared pill, findings-list and diff components",
+  "description": "User story under REQ-181. Three view modules land under src/view/components/: pill, findings-list, diff. Readiness is their first consumer; existing Product Map and Requirements rendering keeps its markup where the swap is not mechanical, and no existing test expectation changes in that case. See the DEFINE step 2 spec dated 2026-10-01 (section 5) for the component contract.",
+  "asA": "a maintainer of the viewer",
+  "iWant": "one pill, one findings list and one diff component",
+  "soThat": "gate state, persona, level verdict and AC class read the same on every tab",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18101-1",
+      "description": "[happy] Given the pill component, when rendered with a gate state, a level verdict, a persona or an AC class, then it emits the same markup shape with a vocabulary class per value.",
+      "testable": true
+    },
+    {
+      "id": "AC-18101-2",
+      "description": "[happy] Given the findings-list component, when called with the same inputs from the Readiness and Product Map callers, then the two call sites produce byte-identical markup.",
+      "testable": true
+    },
+    {
+      "id": "AC-18101-3",
+      "description": "[must-not] Given the shared components, when introduced, then no existing Product Map or Requirements test changes its expected output except where this PR explicitly re-points that tab.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4127-readiness-view"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-01T18:00:00Z",
+  "updatedAt": "2026-10-01T18:00:00Z"
+}

package/rcf/user-stories/us-18202.json

@@ -0,0 +1,40 @@
+{
+  "usId": "US-18202",
+  "prdId": "PRD-001",
+  "reqId": "REQ-182",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "the DEFINE-stage guidance pack",
+  "description": "User story under REQ-182. The guidance pack prints its slugs through `rcf guidance`, the MCP server advertises every argument-free DEFINE prompt, the register scan protects every new file from em-dashes, and the managed block regeneration never removes an existing rule.",
+  "asA": "harness",
+  "iWant": "the DEFINE-stage guidance pack served through one surface",
+  "soThat": "the loop reads one slug per topic and the register scans and managed-block rules apply everywhere",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18202-1",
+      "description": "[happy] given the pack, when rcf guidance define-intent and rcf guidance discovery-prototypes run, then each prints its file.",
+      "testable": true
+    },
+    {
+      "id": "AC-18202-2",
+      "description": "[happy] given the manifest, when the MCP server lists prompts, then rcf_define_intent, rcf_define_intake, rcf_define_draft_shapes, rcf_define_litmus and rcf_discover_prototype are present and argument-free.",
+      "testable": true
+    },
+    {
+      "id": "AC-18202-3",
+      "description": "[failure] given a new guidance file containing an em-dash, when the register scan runs, then it fails.",
+      "testable": true
+    },
+    {
+      "id": "AC-18202-4",
+      "description": "[must-not] given the managed block, when regenerated, then no existing rule is removed.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4128-define-guidance"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-03T00:00:00Z",
+  "updatedAt": "2026-10-03T00:00:00Z"
+}

package/rcf/user-stories/us-18601.json

@@ -0,0 +1,55 @@
+{
+  "usId": "US-18601",
+  "prdId": "PRD-001",
+  "reqId": "REQ-186",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "the question set",
+  "description": "User story under REQ-186. computeQuestions turns every failing product-owner item into one plain question with its write-back, so the harness can ask without reading gate internals.",
+  "asA": "harness serving a product owner",
+  "iWant": "computeQuestions to turn every failing product-owner item into one plain question with its write-back",
+  "soThat": "I can ask without reading gate internals",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18601-1",
+      "description": "[happy] given a tree where brief:openQuestions, skeleton:resolvedBy and stories:reqHasUs each fail at least one item, when computeQuestions runs with persona productOwner, then questions[] holds exactly one entry per failing item with id, stage, check, itemId, heading, ask, answerKinds, writeBack and blocks intent.",
+      "testable": true
+    },
+    {
+      "id": "AC-18601-2",
+      "description": "[happy] given the same tree, when computeQuestions runs twice, then the two questions[] arrays are deep-equal and ordered D1, D2, D4, D7 then by source span.",
+      "testable": true
+    },
+    {
+      "id": "AC-18601-3",
+      "description": "[happy] given an open decision with two options and a default, when computeQuestions runs, then it appears in optional[] with blocks build and not in questions[].",
+      "testable": true
+    },
+    {
+      "id": "AC-18601-4",
+      "description": "[happy] given a tree where levels.intentComplete.ok is true, when computeQuestions runs with persona productOwner, then questions[] is empty and ok is true.",
+      "testable": true
+    },
+    {
+      "id": "AC-18601-5",
+      "description": "[happy] given persona engineer, when computeQuestions runs, then questions[] holds one entry per failing engineer item in failing stages and blocks is build.",
+      "testable": true
+    },
+    {
+      "id": "AC-18601-6",
+      "description": "[failure] given a persona value outside productOwner and engineer, when computeQuestions runs, then it throws a usage error naming the accepted values.",
+      "testable": true
+    },
+    {
+      "id": "AC-18601-7",
+      "description": "[must-not] given any tree, when computeQuestions runs, then no file under rcf/ is created or modified and no question carries a writeBack command whose verb is not registered in the CLI help.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4129-define-questions"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-02T18:00:00Z",
+  "updatedAt": "2026-10-02T18:00:00Z"
+}

package/rcf/user-stories/us-18602.json

@@ -0,0 +1,50 @@
+{
+  "usId": "US-18602",
+  "prdId": "PRD-001",
+  "reqId": "REQ-186",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "the verb and the tools",
+  "description": "User story under REQ-186. `rcf define questions` and `rcf_define_questions` return the same object, so the CLI loop and the MCP loop cannot disagree.",
+  "asA": "operator or harness",
+  "iWant": "the verb and the MCP tool to return the same object",
+  "soThat": "the two loops cannot disagree",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18602-1",
+      "description": "[happy] given a failing tree, when rcf define questions --json runs, then stdout is the computeQuestions object and the exit code is 0.",
+      "testable": true
+    },
+    {
+      "id": "AC-18602-2",
+      "description": "[happy] given no --persona, when the verb runs on a profile whose register is engineer, then persona is engineer; with no profile it is productOwner.",
+      "testable": true
+    },
+    {
+      "id": "AC-18602-3",
+      "description": "[happy] given --stage skeleton and --limit 2, when the verb runs, then questions[] holds at most two D2 entries and remaining counts every D2 item.",
+      "testable": true
+    },
+    {
+      "id": "AC-18602-4",
+      "description": "[happy] given the MCP tool rcf_define_questions with the same arguments, when it is called, then structuredContent deep-equals the verb's --json output.",
+      "testable": true
+    },
+    {
+      "id": "AC-18602-5",
+      "description": "[failure] given --persona architect, when the verb runs, then it exits 2 with the usage line naming productOwner and engineer.",
+      "testable": true
+    },
+    {
+      "id": "AC-18602-6",
+      "description": "[must-not] given any invocation of rcf define questions, when it completes, then no file under rcf/ has been created or modified.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4129-define-questions"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-02T18:00:00Z",
+  "updatedAt": "2026-10-02T18:00:00Z"
+}

package/rcf/user-stories/us-18603.json

@@ -0,0 +1,45 @@
+{
+  "usId": "US-18603",
+  "prdId": "PRD-001",
+  "reqId": "REQ-186",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "write-back and termination",
+  "description": "User story under REQ-186. Every answer lands through a verb and the loop ends at the computed verdict, so nothing about intent lives only in a chat.",
+  "asA": "product owner",
+  "iWant": "every answer to land through a verb and the loop to end at the computed verdict",
+  "soThat": "nothing about my intent lives only in a chat",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18603-1",
+      "description": "[happy] given the scripted loop fixture, when every writeBack the question set returns is applied and readiness recomputed each turn, then the question count strictly decreases every turn and reaches zero.",
+      "testable": true
+    },
+    {
+      "id": "AC-18603-2",
+      "description": "[happy] given a statement resolved to a newly created REQ carrying description and domain, when readiness recomputes, then skeleton:reqIntent passes that REQ and stories:reqHasUs asks for it once.",
+      "testable": true
+    },
+    {
+      "id": "AC-18603-3",
+      "description": "[happy] given a tree at L1, when [draft] entities, TAC stubs and interfaces are added, then levels.intentComplete.ok stays true and the product-owner question set stays empty.",
+      "testable": true
+    },
+    {
+      "id": "AC-18603-4",
+      "description": "[failure] given an openQuestion promoted to a decision with one option and no default, when readiness recomputes, then decisions:wellFormed asks once and brief:openQuestions does not.",
+      "testable": true
+    },
+    {
+      "id": "AC-18603-5",
+      "description": "[must-not] given any product-owner check, when readiness recomputes after an engineer-only edit, then no product-owner check changes from ok to failing.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4129-define-questions"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-02T18:00:00Z",
+  "updatedAt": "2026-10-02T18:00:00Z"
+}

package/rcf/user-stories/us-18701.json

@@ -0,0 +1,50 @@
+{
+  "usId": "US-18701",
+  "prdId": "PRD-001",
+  "reqId": "REQ-187",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "the statement file",
+  "description": "User story under REQ-187. The harness writes a statement file beside each source with a leading bracketed kind and a trailing (source: ...) marker; `brief add --from` parses the markers and mints the statements.",
+  "asA": "harness",
+  "iWant": "a line grammar for kind and source",
+  "soThat": "the split I propose to the owner is what gets minted",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18701-1",
+      "description": "[happy] given a line \"- [constraint] A loan on hold must not accrue late fees. (source: briefs/x.md:15)\", when brief add --from runs, then one statement is minted with kind constraint, that text and that source.",
+      "testable": true
+    },
+    {
+      "id": "AC-18701-2",
+      "description": "[happy] given a line with no markers under --kind actor --source doc.md, when brief add --from runs, then the statement has kind actor and source doc.md.",
+      "testable": true
+    },
+    {
+      "id": "AC-18701-3",
+      "description": "[happy] given a line ending with \"?\" and no kind marker, when brief add --from runs, then the statement has kind openQuestion.",
+      "testable": true
+    },
+    {
+      "id": "AC-18701-4",
+      "description": "[happy] given a 0.29.0 line-per-statement file, when brief add --from runs, then the minted statements equal the 0.29.0 output.",
+      "testable": true
+    },
+    {
+      "id": "AC-18701-5",
+      "description": "[failure] given a line \"[gadget] text\", when brief add --from runs, then it exits 2 naming the accepted kinds and writes nothing.",
+      "testable": true
+    },
+    {
+      "id": "AC-18701-6",
+      "description": "[must-not] given --dry-run, when brief add --from runs, then rcf/define/brief-ledger.json is not created or modified.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4130-define-intake-brief"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-02T16:40:00Z",
+  "updatedAt": "2026-10-02T16:40:00Z"
+}

package/rcf/user-stories/us-18702.json

@@ -0,0 +1,50 @@
+{
+  "usId": "US-18702",
+  "prdId": "PRD-001",
+  "reqId": "REQ-187",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "scans into open questions",
+  "description": "User story under REQ-187. The intake scans run inside `brief add --from` over the new statements against every existing statement, and every finding becomes an openQuestion statement with source `scan:<name>:<ids>`.",
+  "asA": "product owner",
+  "iWant": "contradictions and gaps the tool can see to reach me as questions",
+  "soThat": "the first readiness run tells me what is still mine",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18702-1",
+      "description": "[happy] given two new statements the contradiction scan flags, when brief add --from runs with scans on, then one openQuestion statement is appended with source scan:contradiction:<id>,<id> and brief:openQuestions fails it.",
+      "testable": true
+    },
+    {
+      "id": "AC-18702-2",
+      "description": "[happy] given a --findings file with two findings, when brief add --from runs, then two openQuestion statements are appended with source scan:<name>.",
+      "testable": true
+    },
+    {
+      "id": "AC-18702-3",
+      "description": "[happy] given a frozen tree, when brief add --from runs, then the scans compare the new statements against every existing statement.",
+      "testable": true
+    },
+    {
+      "id": "AC-18702-4",
+      "description": "[happy] given --json, when brief add --from runs, then stdout holds added[] and findings[].",
+      "testable": true
+    },
+    {
+      "id": "AC-18702-5",
+      "description": "[failure] given --no-scan together with --findings, when brief add runs, then it exits 2.",
+      "testable": true
+    },
+    {
+      "id": "AC-18702-6",
+      "description": "[must-not] given --text, when brief add runs, then no scan runs and no openQuestion statement is appended.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4130-define-intake-brief"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-02T16:40:00Z",
+  "updatedAt": "2026-10-02T16:40:00Z"
+}

package/rcf/user-stories/us-18801.json

@@ -0,0 +1,45 @@
+{
+  "usId": "US-18801",
+  "prdId": "PRD-001",
+  "reqId": "REQ-188",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "the draft homes",
+  "description": "User story under REQ-188. Every pre-populated shape across the three draft homes (`TAC.purpose`, `coreEntities[].description`, `TAC.interfaces[].description`) carries the `[draft]` marker; `shapes:draftSettled` reports all three id forms so nothing drafted reads as settled.",
+  "asA": "engineer picking up an intent-complete tree",
+  "iWant": "every pre-populated shape marked",
+  "soThat": "nothing drafted reads as settled",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-18801-1",
+      "description": "[happy] given a coreEntities entry whose description starts with [draft], when D3 runs, then shapes:draftSettled fails TAD.entity:<name>.",
+      "testable": true
+    },
+    {
+      "id": "AC-18801-2",
+      "description": "[happy] given a TAC whose purpose starts with [draft], when D3 runs, then shapes:draftSettled fails <tacId> and shapes:tacHasInterface treats the TAC as present.",
+      "testable": true
+    },
+    {
+      "id": "AC-18801-3",
+      "description": "[happy] given the three marker homes cleared, when D3 runs, then shapes:draftSettled passes.",
+      "testable": true
+    },
+    {
+      "id": "AC-18801-4",
+      "description": "[failure] given a [draft] recordShape without fields:, when D3 runs, then shapes:templateMarkers fails it exactly as a settled one.",
+      "testable": true
+    },
+    {
+      "id": "AC-18801-5",
+      "description": "[must-not] given any [draft] content, when readiness runs, then no productOwner check reads it.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4122-define-gates"
+  ],
+  "tags": [],
+  "createdAt": "2026-10-03T00:00:00Z",
+  "updatedAt": "2026-10-03T00:00:00Z"
+}

package/rcf/user-stories/us-204.json

@@ -0,0 +1,59 @@
+{
+  "usId": "US-204",
+  "prdId": "PRD-001",
+  "reqId": "REQ-002",
+  "version": "0.1.0",
+  "status": "draft",
+  "title": "An engineer sees the FBS DAG",
+  "description": "The Build tab's DAG sub-tab lays FBS out by dependency depth from `dependsOnFbsIds` with click-to-highlight closure, a dependency inspector, status/area/Buildable-now/Critical-path/Show-unconnected filters, a hidden unconnected lane with a count, and `#tab=build&sub=dag&entity=<id>` deep links so a node is a link. The canvas scrolls inside its own box and the viewer never scrolls horizontally. See viewer UI refresh design doc section 7.",
+  "asA": "an engineer looking at the build sequence",
+  "iWant": "a dependency DAG of the FBS with click-to-highlight closure, an inspector and filters",
+  "soThat": "I can see what feeds what, pick the next buildable work and spot the critical path without reading JSON",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-204-1",
+      "description": "[happy] Given the Build tab's DAG sub-tab, when it renders, then every connected FBS sits in a column whose index equals its longest dependency depth from `dependsOnFbsIds` (0 for no dependency) and rows inside a column are ordered by `buildOrder` ascending.",
+      "testable": true
+    },
+    {
+      "id": "AC-204-2",
+      "description": "[happy] Given the DAG canvas, when a node is clicked, then it is selected, its upstream closure outlines in the link colour and its downstream closure outlines in the warning colour; a second click on the same node clears the selection.",
+      "testable": true
+    },
+    {
+      "id": "AC-204-3",
+      "description": "[happy] Given a selected FBS, when the inspector renders, then it lists status, area, AC count, size, build order, a buildable-now flag, direct and transitive needs, direct and transitive waits-on and an \"Open in Specs\" link that moves to `#tab=build&sub=specs&entity=<id>`.",
+      "testable": true
+    },
+    {
+      "id": "AC-204-4",
+      "description": "[happy] Given a selection, when it is set or cleared, then the hash becomes `#tab=build&sub=dag&entity=<id>` (or drops the entity key when cleared) and a reload with that hash restores the selection and scrolls the node into view.",
+      "testable": true
+    },
+    {
+      "id": "AC-204-5",
+      "description": "[happy] Given the DAG toolbar, when the Status, Area, Buildable-now, Critical-path or Show-unconnected filter changes, then the visible nodes update and the current selection is kept.",
+      "testable": true
+    },
+    {
+      "id": "AC-204-6",
+      "description": "[failure] Given a `dependsOnFbsIds` cycle on disk, when the DAG renders, then the cycle is reported as a finding in the toolbar area and the remaining non-cycle FBS still render.",
+      "testable": true
+    },
+    {
+      "id": "AC-204-7",
+      "description": "[must-not] Given the DAG canvas, when a node is clicked, filtered or inspected, then no `postMessage` is sent to the parent window and no outbound network request is made.",
+      "testable": true
+    }
+  ],
+  "tacIds": [
+    "TAC-4131-build-dag-view"
+  ],
+  "tags": [
+    "view",
+    "build",
+    "dag"
+  ],
+  "createdAt": "2026-10-02T18:00:00Z",
+  "updatedAt": "2026-10-02T18:00:00Z"
+}