rcf-lite 0.9.0 → 0.10.0

package/rcf/fbs/fbs-007.json

@@ -22,7 +22,7 @@
   "estimatedSize": "medium",
   "estimatedHours": 6,
   "deliverables": [
-    "rcf delete verb with reference-safe default",
+    "rcf define delete verb with reference-safe default",
     "Cascade flag with parent-reference cleanup"
   ],
   "riskLevel": "medium",

package/rcf/fbs/fbs-014.json

@@ -2,7 +2,7 @@
   "createdAt": "2026-07-20T17:05:46.941Z",
   "updatedAt": "2026-07-20T17:05:46.941Z",
   "summary": "Harden the build-cycle guidance so every build lands a documented local preview as its default outcome, every verification claim names the runtime it was checked against, and the method carries interim fresh-context self-review guidance. Edits the build-cycle playbook, the build-cycle contract and the harness fragment; no runtime subsystem.",
-  "approach": "In the build-cycle guidance, make a working, documented local preview loop (dev server, seeded data where needed, ideally one command) a required, hosting-independent part of a build's definition of done. Require every 'verified'/'tested' claim - in the Test and Finalise stages and in the PR body's verification section - to name the runtime it was checked against, forbid any claim implying deploy-runtime verification that did not happen, and add an explicit labelled-claim example. Add an interim self-review section describing a periodic and end-of-build fresh-context reviewer dispatch that drives the app against its ACs, targeting session-class bugs, false-promise UI, runtime mismatch, dead auth paths and dead code, scoped honestly as a stopgap until rcf-verify-lite and explicitly not the independent gate. Add matching harness-fragment rules and extend the guidance drift tests.",
+  "approach": "In the build-cycle guidance, make a working, documented local preview loop (dev server, seeded data where needed, ideally one command) a required, hosting-independent part of a build's definition of done. Require every 'verified'/'tested' claim - in the Test and Finalise stages and in the PR body's verification section - to name the runtime it was checked against, forbid any claim implying deploy-runtime verification that did not happen, and add an explicit labelled-claim example. Add an interim self-review section describing a periodic and end-of-build fresh-context reviewer dispatch that drives the app against its ACs, targeting session-class bugs, false-promise UI, runtime mismatch, dead auth paths and dead code, scoped honestly as a stopgap until rcf verify-lite and explicitly not the independent gate. Add matching harness-fragment rules and extend the guidance drift tests.",
   "deliverables": [
     "Build-cycle guidance: local preview loop as default, hosting-independent definition-of-done item",
     "Build-cycle and PR-authoring guidance: runtime-provenance labelling with a worked example",

package/rcf/fbs/fbs-015.json

@@ -4,19 +4,20 @@
   "bsId": "BS-001",
   "buildOrder": 15,
   "executionStatus": "complete",
-  "title": "`rcf verify` subcommand routing (0.7.1 consolidation)",
-  "summary": "Route the adversarial ship-gate verifier under the unified `rcf` CLI as `rcf verify <run|report|provision|cleanup|mcp>`. The pre-existing `rcf-verify` bin becomes a transition-grace alias that dispatches through the same handlers and emits a one-line stderr deprecation notice when invoked directly.",
-  "approach": "One dispatcher, two entry points. bin/rcf.js imports the `main` export from bin/rcf-verify.js and registers it as the `verify` entry on the top-level SUBCOMMANDS map, so `rcf verify --help` and `rcf-verify --help` share the same code path by construction. The alias bin gains a deprecation notice guarded by RCF_QUIET for scripted callers. The unified CLI's help output lists `verify <verb>` alongside the other top-level commands, sourced from the same verify TOP_LEVEL_HELP the alias bin uses (single-source rule).",
+  "title": "`rcf verify` group routing (0.10.0 CLI reorganisation)",
+  "summary": "Route the adversarial ship-gate verifier under the unified `rcf` CLI as `rcf verify <run|report|provision|cleanup|mcp|browser>`. The legacy standalone `rcf-verify` bin (0.7.1 transition-grace alias) is deleted outright; consumers move to `rcf verify <verb>` in one hop.",
+  "approach": "bin/rcf.js declares a `verify` entry in the top-level GROUPS map whose sub-verbs (run, report, provision, cleanup, mcp, browser) resolve to the corresponding main() exports from src/verify/cli/*.js and src/cli/browser-verify.js. The unified CLI's help output lists the verify group with its sub-verbs, sourced from the per-verb HELP exports via HELP_MAP.verify (single-source rule). The dispatcher additionally recognises pre-0.10.0 flat verb tokens through OLD_FLAT_MAP: on match it writes a one-line stderr hint naming the new grouped form before exiting 2. This is a usage-error affordance, not a fallback; the invocation fails.",
   "deliverables": [
-    "bin/rcf.js: `verify` on the top-level SUBCOMMANDS map, dispatching to the alias bin's exported main",
-    "bin/rcf-verify.js: one-line stderr deprecation notice on direct invocation, suppressible via RCF_QUIET",
-    "src/cli/help.js: `verify <verb>` listed in the top-level command table; `help verify` prints the alias bin's TOP_LEVEL_HELP block"
+    "bin/rcf.js: `verify` on the top-level GROUPS map, dispatching per sub-verb to the verify-suite handlers plus browser-verify",
+    "bin/rcf.js: OLD_FLAT_MAP recognises pre-0.10.0 flat verbs and emits a stderr hint at the new grouped form before exit 2",
+    "package.json: `bin` field carries only `rcf`; the historical `rcf-verify` entry and bin/rcf-verify.js file are deleted",
+    "src/cli/help.js: verify group header + sub-verb catalogue in TOP_LEVEL_HELP; `rcf help verify` prints the group help; `rcf help verify <verb>` prints per-verb help via HELP_MAP"
   ],
   "estimatedSize": "small",
   "estimatedHours": 1,
   "riskLevel": "low",
   "domain": "cli",
-  "notes": "Ratified in the 2026-08-06 packaging-consolidation proposal (R3). Pure repackage relative to 0.7.0 verify behaviour; the invocation form gains a canonical route, existing scripts keep working via the alias.",
+  "notes": "Ratified in the 2026-08-26 CLI group-design ruling (clean break: no aliases, no shims, no back-compat fallbacks). Supersedes the 0.7.1 alias-bin transition-grace posture; the alias bin is deleted.",
   "contextRequirements": {
     "tacIds": [],
     "adrIds": []
@@ -28,5 +29,5 @@
   ],
   "dependsOnFbsIds": [],
   "createdAt": "2026-08-11T00:00:00Z",
-  "updatedAt": "2026-08-11T00:00:00Z"
+  "updatedAt": "2026-08-26T00:00:00Z"
 }

package/rcf/fbs/fbs-016.json

@@ -5,7 +5,7 @@
   "buildOrder": 16,
   "executionStatus": "notStarted",
   "title": "Blueprint verb family (add, list, remove, upgrade) with manifest.blueprints[] writes",
-  "summary": "Introduce the `rcf blueprint <verb>` verb family and its manifest-writing path. Adds `src/blueprint/` module (loader, applier, contribution-writer) and `src/cli/blueprint.js` (parseArgs, dispatch, HELP block). Adds `blueprint` to the top-level SUBCOMMANDS map on `bin/rcf.js` and to the `TOP_LEVEL` block on `src/cli/help.js` so `rcf --help` advertises it. Every apply writes an entry to `manifest.blueprints[]` per the 0.4.4 schema (slug, version, appliedAt, source, namespace, contributions[]). `add` is idempotent on a clean re-apply; `remove` refuses when any project-authored doc references a contribution id.",
+  "summary": "Introduce the `rcf define blueprint <verb>` verb family and its manifest-writing path. Adds `src/blueprint/` module (loader, applier, contribution-writer) and `src/cli/blueprint.js` (parseArgs, dispatch, HELP block). Adds `blueprint` to the top-level SUBCOMMANDS map on `bin/rcf.js` and to the `TOP_LEVEL` block on `src/cli/help.js` so `rcf --help` advertises it. Every apply writes an entry to `manifest.blueprints[]` per the 0.4.4 schema (slug, version, appliedAt, source, namespace, contributions[]). `add` is idempotent on a clean re-apply; `remove` refuses when any project-authored doc references a contribution id.",
   "approach": "One dispatcher, one loader, one applier, one writer. bin/rcf.js gains `blueprint: blueprintMain` on SUBCOMMANDS; src/cli/blueprint.js parses `add|list|remove|upgrade` and dispatches to src/blueprint/ handlers. Blueprint loading is a small package-metadata reader (slug, version, ADR contributions with optional scope, doc contributions manifest); Phase 1 keeps the resolver `file://` and `link:` only, with the registry/git-ref shape captured in the source string so the schema forward-compat holds. Contribution writing goes through the existing store writer paths so a blueprint apply produces the same doc files a hand-created doc would. Removal is a manifest patch + contribution-path unlink; the referring-doc check reuses the existing tree walker to enumerate every string field for id occurrences.",
   "deliverables": [
     "src/cli/blueprint.js: parseArgs + HELP + main() dispatching add/list/remove/upgrade",

package/rcf/fbs/fbs-017.json

@@ -5,7 +5,7 @@
   "buildOrder": 17,
   "executionStatus": "notStarted",
   "title": "Namespaced blueprint ids and scope:global ADR conflict surfacing",
-  "summary": "Blueprint-contributed docs are namespaced by the blueprint's slug: REQ/US/PRD/BS/TAD/TS via the 0.4.4 slug PREFIX (e.g. `spa-REQ-001`), and ADR/TAC/FBS/CN via the 0.4.3 kebab SUFFIX (e.g. `ADR-005-rest-versioning`). `rcf blueprint add` runs a conflict-detection pass BEFORE writing anything: two blueprints both contributing an ADR tagged `scope: global` on the same topic exit non-zero with both sides printed and four honest resolution paths named (adopt-incoming, keep-existing, supersede via project ADR, declare-on-add via `--resolve`). Non-global TACs, ADRs, REQs, USs and FBSes namespace cleanly and cannot topic-conflict; cross-blueprint id claims (an incoming id already recorded on another applied blueprint) are refused via the authoritative manifest record, not string grammar.",
+  "summary": "Blueprint-contributed docs are namespaced by the blueprint's slug: REQ/US/PRD/BS/TAD/TS via the 0.4.4 slug PREFIX (e.g. `spa-REQ-001`), and ADR/TAC/FBS/CN via the 0.4.3 kebab SUFFIX (e.g. `ADR-005-rest-versioning`). `rcf define blueprint add` runs a conflict-detection pass BEFORE writing anything: two blueprints both contributing an ADR tagged `scope: global` on the same topic exit non-zero with both sides printed and four honest resolution paths named (adopt-incoming, keep-existing, supersede via project ADR, declare-on-add via `--resolve`). Non-global TACs, ADRs, REQs, USs and FBSes namespace cleanly and cannot topic-conflict; cross-blueprint id claims (an incoming id already recorded on another applied blueprint) are refused via the authoritative manifest record, not string grammar.",
   "approach": "Namespacing is enforced at the loader: contribution ids are stamped with the blueprint slug at load time; a contribution whose declared id already carries a namespace is trusted verbatim (author declaration is the truth for what that blueprint owns; the earlier grammar-veto of legitimate slug-tail ids like `ADR-201-spa-theme` under blueprint `spa` was retired in w-2026-08-19-005). Ownership of a written contribution is answered by the manifest's `appliedBlueprintRecord.contributions[]` list — the authoritative record — not by re-parsing the id string. Conflict detection reads the applied `blueprints[]` and the applying blueprint's contributions, and scores collisions along two axes: `scope: global` ADR topic collision (two applied ADRs both tagged `scope: global` with a matching `topic` field), and cross-blueprint ownership (an incoming id whose manifest record is on a DIFFERENT applied blueprint's contribution list — the class the record consultation catches once grammar stopped being a trust surface). Presentation: per-conflict block leads with both ADR titles and their one-sentence decisions, ids and paths as a footer, and four honest resolution paths with actual blueprint slugs filled in — no placeholders. A `--json` output shape is available for agent-driven composition. Phase 3.5 (w-2026-08-19-008) added the `supersede` and `diff` verbs plus the `--resolve` add-time flag, backed by `manifest.resolutions[]` on the 0.4.5 schema; both blueprint ADRs may now co-reside on disk as superseded history alongside a project-level ADR that supersedes them.",
   "deliverables": [
     "src/blueprint/namespace.js: pure functions that stamp/verify contribution namespacing for all doc kinds",

package/rcf/fbs/fbs-018.json

@@ -4,8 +4,8 @@
   "bsId": "BS-001",
   "buildOrder": 18,
   "executionStatus": "notStarted",
-  "title": "Standards ingestion: rcf standards add + reference-by-default",
-  "summary": "Introduce a `rcf standards <verb>` verb family (`add`, `list`) that registers standards packs on the project manifest. Reference-by-default when the source lives inside the project root; copy into `rcf/standards/<slug>/` only when the source lives outside. Manifest registration is authoritative; every add writes a `manifest.standards[]` entry per the 0.4.4 `standardsPackRecord` schema.",
+  "title": "Standards ingestion: rcf define standards add + reference-by-default",
+  "summary": "Introduce a `rcf define standards <verb>` verb family (`add`, `list`) that registers standards packs on the project manifest. Reference-by-default when the source lives inside the project root; copy into `rcf/standards/<slug>/` only when the source lives outside. Manifest registration is authoritative; every add writes a `manifest.standards[]` entry per the 0.4.4 `standardsPackRecord` schema.",
   "approach": "One dispatcher, one applier. src/cli/standards.js parses `add|list`; src/blueprint/standards.js resolves whether the source is inside or outside the project root (via node:path.relative + startsWith), copies when needed, and writes the manifest entry. Copy path is fs.cp recursive with a per-run overwrite guard (idempotent re-adds refuse to re-copy unless `--refresh` is passed; Phase 1 keeps to add-only + idempotent read, `refresh` verb deferred to Phase 3).",
   "deliverables": [
     "src/cli/standards.js: parseArgs + HELP + main() for add/list",

package/rcf/requirements/req-008.json

@@ -4,7 +4,7 @@
   "category": "functional",
   "priority": "must",
   "description": "The agent guidance pack teaches a build method that keeps the deployment runtime present in the loop from elicitation to verification, so that a non-coding owner who cannot self-verify is not led into an undeployable stack or a false 'verified' claim. It requires four properties of the method the tool ships: (1) every build lands a working, documented local preview loop as its default outcome; (2) elicitation establishes where the app will run early and constrains the stack to that answer, with a jargon-free hosting-choice walkthrough when the owner does not know; (3) every 'verified' or 'tested' claim names the runtime it was checked against and never implies deploy-runtime verification that did not happen; (4) the method carries guidance for a periodic and end-of-build fresh-context self-review that drives the app against its acceptance criteria, subordinate to the independent verification gate rather than a substitute for it. This requirement governs the shipped guidance/prompt surface, not a new runtime subsystem.",
-  "rationale": "The five-run rcf-persona-testing programme (concluded 2026-07-20) found the tool builds excellently at every level but its own loop missed a ship-blocking or user-facing defect in three of five runs, with a single root cause: the deploy runtime is absent from the loop. It is absent from elicitation (runs 03/04 chose Cloudflare-incompatible stacks a CF-only holder cannot host, run 03 silently) and absent from verification (run 05 shipped a production auth 500 while 89/89 tests were green and the tool claimed a live-Worker verification its E2E never ran). The target user cannot diagnose 'wrong stack for your host' or 'verified against the wrong runtime', so the method itself must foreclose both. These are Tier-1 hardening fixes to make the base offering usable now, while the productised independent verification gate (rcf-verify-lite) is built separately.",
+  "rationale": "The five-run rcf-persona-testing programme (concluded 2026-07-20) found the tool builds excellently at every level but its own loop missed a ship-blocking or user-facing defect in three of five runs, with a single root cause: the deploy runtime is absent from the loop. It is absent from elicitation (runs 03/04 chose Cloudflare-incompatible stacks a CF-only holder cannot host, run 03 silently) and absent from verification (run 05 shipped a production auth 500 while 89/89 tests were green and the tool claimed a live-Worker verification its E2E never ran). The target user cannot diagnose 'wrong stack for your host' or 'verified against the wrong runtime', so the method itself must foreclose both. These are Tier-1 hardening fixes to make the base offering usable now, while the productised independent verification gate (rcf verify-lite) is built separately.",
   "reqId": "REQ-008",
   "prdId": "PRD-001",
   "title": "Deploy-aware, runtime-honest build guidance",

package/rcf/requirements/req-009.json

@@ -2,11 +2,11 @@
   "reqId": "REQ-009",
   "prdId": "PRD-001",
   "title": "Umbrella CLI: verify as a first-class subcommand",
-  "description": "Post 0.7.1 packaging consolidation the RCF Lite suite ships as one npm package with one unified `rcf` CLI. The adversarial ship-gate verifier that used to live behind its own `rcf-verify` bin is mounted as `rcf verify <run|report|provision|cleanup|mcp>` on that unified CLI. The pre-existing `rcf-verify` bin remains as a transition-grace alias that dispatches through the same handlers, deprecated in favour of `rcf verify`. Behaviour of each verify verb is unchanged; only the invocation form gains a canonical route.",
+  "description": "Post 0.7.1 packaging consolidation the RCF Lite suite ships as one npm package with one unified `rcf` CLI. The adversarial ship-gate verifier that used to live behind its own `rcf verify` bin is mounted as `rcf verify <run|report|provision|cleanup|mcp>` on that unified CLI. The pre-existing `rcf verify` bin remains as a transition-grace alias that dispatches through the same handlers, deprecated in favour of `rcf verify`. Behaviour of each verify verb is unchanged; only the invocation form gains a canonical route.",
   "category": "functional",
   "domain": "cli",
   "priority": "must",
-  "rationale": "The packaging consolidation ruling (docs/2026-08-06_packaging-consolidation-proposal.md, ratified 2026-08-11) picks one install (`rcf-lite`) with one CLI verb space (`rcf`). Verify is a first-class part of the RCF chain (define, build, verify) and must sit inside that verb space, not beside it. Keeping `rcf-verify` as an alias avoids a hard break for existing scripts across a transition window.",
+  "rationale": "The packaging consolidation ruling (docs/2026-08-06_packaging-consolidation-proposal.md, ratified 2026-08-11) picks one install (`rcf-lite`) with one CLI verb space (`rcf`). Verify is a first-class part of the RCF chain (define, build, verify) and must sit inside that verb space, not beside it. Keeping `rcf verify` as an alias avoids a hard break for existing scripts across a transition window.",
   "tags": [
     "packaging",
     "cli",

package/rcf/requirements/req-010.json

@@ -1,7 +1,7 @@
 {
   "createdAt": "2026-08-18T22:54:27.031Z",
   "updatedAt": "2026-08-18T22:57:45.660Z",
-  "description": "The framework provides a Blueprint mechanism the operator uses to compose blueprint packages (specifications + assets, not code) onto a project tree at any point in its life. Composition is many blueprints per project. Blueprint-contributed docs are namespaced by the blueprint's slug so multiple blueprints cannot collide on ids. Standards packs register at rcf init (or later via rcf standards add), reference-by-default, copied to rcf/standards/<slug>/ only when the source lives outside the project root. Manifest registration is authoritative. Selective retrieval populates fbs.contextRequirements.standardIds at bundle-assembly time by analysing the FBS work text against the standards tag vocabulary; operator override is supported by authoring the array on the FBS. scope:global ADR contributions surface as blocking conflicts at rcf blueprint add time.",
+  "description": "The framework provides a Blueprint mechanism the operator uses to compose blueprint packages (specifications + assets, not code) onto a project tree at any point in its life. Composition is many blueprints per project. Blueprint-contributed docs are namespaced by the blueprint's slug so multiple blueprints cannot collide on ids. Standards packs register at rcf init (or later via rcf define standards add), reference-by-default, copied to rcf/standards/<slug>/ only when the source lives outside the project root. Manifest registration is authoritative. Selective retrieval populates fbs.contextRequirements.standardIds at bundle-assembly time by analysing the FBS work text against the standards tag vocabulary; operator override is supported by authoring the array on the FBS. scope:global ADR contributions surface as blocking conflicts at rcf define blueprint add time.",
   "reqId": "REQ-010",
   "prdId": "PRD-001",
   "title": "Blueprint library mechanism (composition, standards, selective retrieval)",

package/rcf/test-suites/PENDING.md

@@ -15,8 +15,8 @@ a genuine feature gap - was closed by porting the parallel-safe tier
 computation from the full RCF platform into the build queue and binding
 TC-014-independent-items-share-tier to it.
 
-Status: **76 bound / 0 pending** of 76 ACs. `rcf coverage --strict`
-exits 0, and CI runs `rcf validate` and `rcf coverage --strict` as
+Status: **76 bound / 0 pending** of 76 ACs. `rcf audit coverage --strict`
+exits 0, and CI runs `rcf define validate` and `rcf audit coverage --strict` as
 required steps, so a new uncovered AC or a non-resolving testPointer
 fails the build. A future genuine gap gets a row here (AC id, US, kind,
 what a sufficient test must assert, nearest existing test) until its

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

@@ -37,7 +37,7 @@
       "acId": "AC-202-1",
       "description": "the view serves from a local server process and never writes files to disk",
       "status": "pending",
-      "testPointer": "test/view/cli.test.js::rcf view never writes any files to disk (regression against static mode)"
+      "testPointer": "test/view/cli.test.js::rcf audit view never writes any files to disk (regression against static mode)"
     }
   ],
   "status": "draft"

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

@@ -15,21 +15,21 @@
       "acId": "AC-301-2",
       "description": "reading an unknown id exits 2 with a structured not-found usage error",
       "status": "pending",
-      "testPointer": "test/cli/read.test.js::rcf read UNKNOWN-999 exits 2 (usage, unknown id)"
+      "testPointer": "test/cli/read.test.js::rcf define read UNKNOWN-999 exits 2 (usage, unknown id)"
     },
     {
       "id": "TC-006-read-reports-valid",
       "acId": "AC-301-1",
       "description": "read returns the body on stdout and reports the document valid against its schema on stderr",
       "status": "pending",
-      "testPointer": "test/cli/read.test.js::rcf read REQ-001 returns the body and reports it valid against its schema (AC-301-1)"
+      "testPointer": "test/cli/read.test.js::rcf define read REQ-001 returns the body and reports it valid against its schema (AC-301-1)"
     },
     {
       "id": "TC-006-read-invalid-content-plus-errors",
       "acId": "AC-301-3",
       "description": "read on an invalid-but-present document returns the content together with the validation errors",
       "status": "pending",
-      "testPointer": "test/cli/read.test.js::rcf read on an invalid-but-present document returns the content together with the validation errors (AC-301-3)"
+      "testPointer": "test/cli/read.test.js::rcf define read on an invalid-but-present document returns the content together with the validation errors (AC-301-3)"
     }
   ],
   "status": "draft"

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

@@ -16,7 +16,7 @@
       "acId": "AC-303-1",
       "description": "a valid update persists the change and advances updatedAt on disk",
       "status": "pending",
-      "testPointer": "test/cli/update.test.js::rcf update REQ-001 --set title=X changes the title and bumps updatedAt"
+      "testPointer": "test/cli/update.test.js::rcf define update REQ-001 --set title=X changes the title and bumps updatedAt"
     },
     {
       "id": "TC-008-invalid-update-refused",
@@ -30,7 +30,7 @@
       "acId": "AC-303-3",
       "description": "update on a nonexistent id returns a structured not-found error naming the id and writes nothing",
       "status": "pending",
-      "testPointer": "test/cli/update.test.js::rcf update REQ-999 returns a structured not-found error and writes nothing (AC-303-3)"
+      "testPointer": "test/cli/update.test.js::rcf define update REQ-999 returns a structured not-found error and writes nothing (AC-303-3)"
     }
   ],
   "status": "draft"

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

@@ -17,7 +17,7 @@
       "acId": "AC-304-1",
       "description": "delete without cascade refuses with exit 4 naming dependents",
       "status": "pending",
-      "testPointer": "test/cli/delete.test.js::rcf delete REQ-001 without --cascade refuses with exit 4"
+      "testPointer": "test/cli/delete.test.js::rcf define delete REQ-001 without --cascade refuses with exit 4"
     },
     {
       "id": "TC-009-cascade-removes-subtree",
@@ -31,7 +31,7 @@
       "acId": "AC-304-3",
       "description": "deleting an unreferenced leaf removes the file with exit 0 on a still-valid tree",
       "status": "pending",
-      "testPointer": "test/cli/delete.test.js::rcf delete leaf ADR-001 removes the file (exit 0)"
+      "testPointer": "test/cli/delete.test.js::rcf define delete leaf ADR-001 removes the file (exit 0)"
     }
   ],
   "status": "draft"

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

@@ -24,7 +24,7 @@
       "acId": "AC-602-2",
       "description": "rcf_build returns the assembled bundle deep-equal to the CLI output for the named FBS",
       "status": "pending",
-      "testPointer": "test/mcp/parity.test.js::parity: rcf_build FBS-001 structuredContent deep-equals live `rcf build FBS-001 --format json`"
+      "testPointer": "test/mcp/parity.test.js::parity: rcf_build FBS-001 structuredContent deep-equals live `rcf build bundle FBS-001 --format json`"
     },
     {
       "id": "TC-017-mcp-invalid-write-refused",

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

@@ -37,7 +37,7 @@
     {
       "id": "TC-024-in-loop-not-the-gate",
       "acId": "AC-805-4",
-      "description": "the self-review is scoped as an in-loop check naming rcf finalise as the gate",
+      "description": "the self-review is scoped as an in-loop check naming rcf build finalise as the gate",
       "status": "pending",
       "testPointer": "test/guidance/tier1-hardening.test.js::AC-805-4: the self-review is honestly scoped as an in-loop check subordinate to the independent gate"
     }

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

@@ -1,8 +1,8 @@
 {
   "id": "TS-025",
   "usId": "US-901",
-  "title": "`rcf verify` subcommand routing (0.7.1 consolidation)",
-  "purpose": "Verify the umbrella CLI mounts `rcf verify` as a first-class subcommand that dispatches to the same handlers the transition-grace `rcf-verify` alias bin exposes, that the top-level help advertises it, and that the alias bin emits a one-line stderr deprecation notice (suppressible via RCF_QUIET) when run directly.",
+  "title": "`rcf verify` group routing (0.10.0 CLI reorganisation)",
+  "purpose": "Verify the umbrella CLI mounts the `verify` group with the six sub-verbs (run, report, provision, cleanup, mcp, browser), that the top-level help advertises the group with its catalogue, and that the legacy standalone `rcf-verify` bin is deleted at 0.10.0 (with old flat verb tokens on the umbrella `rcf` bin refused with a stderr hint at the new grouped form).",
   "testLevel": "unit",
   "acIds": [
     "AC-901-1",
@@ -11,42 +11,56 @@
   ],
   "testCases": [
     {
-      "id": "TC-025-verify-routes-to-alias-dispatcher",
+      "id": "TC-025-verify-group-routes-per-subverb",
       "acId": "AC-901-1",
-      "description": "the `verify` entry on the top-level SUBCOMMANDS map is the same `main` function the alias bin exports",
+      "description": "`verify` on the top-level GROUPS map wires each sub-verb (run / report / provision / cleanup / mcp / browser) to its corresponding verify-suite main() (browser routes to src/cli/browser-verify.js main)",
       "status": "pending",
-      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-1: `verify` on the top-level SUBCOMMANDS map is the alias bin's dispatcher"
+      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-1: `verify` group on GROUPS wires each sub-verb to the verify-suite handler"
     },
     {
-      "id": "TC-025-verify-help-parity",
+      "id": "TC-025-verify-help-routes-to-group-help",
       "acId": "AC-901-1",
-      "description": "`rcf verify --help` and `rcf-verify --help` print byte-identical help",
+      "description": "`rcf verify --help` prints the verify group help (Usage: rcf verify <verb>) including the browser sub-verb",
       "status": "pending",
-      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-1 (routing surface): `rcf verify --help` dispatches to the same help block as `rcf-verify --help`"
+      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-1 (routing surface): `rcf verify --help` prints the verify group help"
     },
     {
-      "id": "TC-025-top-level-help-lists-verify",
+      "id": "TC-025-top-level-help-lists-verify-group",
       "acId": "AC-901-2",
-      "description": "the top-level rcf --help output lists `verify <verb>` alongside the other commands",
+      "description": "the top-level `rcf --help` output carries the verify group header with its sub-verb catalogue (run, report, provision, cleanup, mcp, browser)",
       "status": "pending",
-      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-2: `rcf --help` advertises the verify subcommand"
+      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-2: `rcf --help` carries the verify group header and sub-verb catalogue"
     },
     {
-      "id": "TC-025-alias-emits-deprecation-notice",
+      "id": "TC-025-alias-bin-deleted-file",
       "acId": "AC-901-3",
-      "description": "`rcf-verify` alias bin emits exactly one stderr line pointing at `rcf verify` when invoked directly",
+      "description": "the pre-0.10.0 alias bin file is deleted: bin/rcf-verify.js does not exist in the published package",
       "status": "pending",
-      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-3: `rcf-verify` alias emits a one-line stderr deprecation notice on direct invocation"
+      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-3: bin/rcf-verify.js is deleted from the package"
     },
     {
-      "id": "TC-025-alias-honours-quiet-env",
+      "id": "TC-025-alias-bin-deleted-package-json",
       "acId": "AC-901-3",
-      "description": "RCF_QUIET=1 silences the deprecation notice for scripted callers",
+      "description": "package.json bin field carries only `rcf`; the historical `rcf-verify` entry is gone",
       "status": "pending",
-      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-3 (silencing): `rcf-verify` with RCF_QUIET=1 does not emit the deprecation notice"
+      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-3: package.json:bin carries no `rcf-verify` entry"
+    },
+    {
+      "id": "TC-025-old-flat-validate-refused",
+      "acId": "AC-901-3",
+      "description": "calling `rcf <old-flat-validate>` via the umbrella bin exits 2 with a stderr hint at `rcf define validate` as the new grouped form",
+      "status": "pending",
+      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-3: `rcf <old-flat-validate>` exits 2 with a stderr hint at `rcf define validate`"
+    },
+    {
+      "id": "TC-025-old-flat-browser-verify-refused",
+      "acId": "AC-901-3",
+      "description": "calling `rcf <old-flat-browser-verify>` via the umbrella bin exits 2 with a stderr hint at `rcf verify browser` as the new grouped form",
+      "status": "pending",
+      "testPointer": "test/cli/rcf-verify-subcommand.test.js::AC-901-3: `rcf <old-flat-browser-verify>` exits 2 with a hint at `rcf verify browser`"
     }
   ],
   "status": "draft",
   "createdAt": "2026-08-11T00:00:00Z",
-  "updatedAt": "2026-08-11T00:00:00Z"
+  "updatedAt": "2026-08-26T00:00:00Z"
 }

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

@@ -2,7 +2,7 @@
   "id": "TS-026",
   "usId": "US-1001",
   "title": "Blueprint verb family",
-  "purpose": "Cover rcf blueprint add/list/remove verb family behaviour and the manifest.blueprints[] write path.",
+  "purpose": "Cover rcf define blueprint add/list/remove verb family behaviour and the manifest.blueprints[] write path.",
   "testLevel": "unit",
   "acIds": [
     "AC-1001-1",

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

@@ -55,36 +55,36 @@
     {
       "id": "TC-027-shipped-blueprints-option-3-executable",
       "acId": "AC-1002-5",
-      "description": "shipped SPA + REST option-3 verbatim-from-refused-state money probe: fresh scaffold; add spa; add rest (refused with the reshaped message); follow option 3 EXACTLY as printed (`rcf blueprint supersede errorEnvelope --incoming <rest>` and `rcf blueprint supersede authModel --incoming <rest>`) with ZERO prep; then re-run `rcf blueprint add <rest>` and verify co-residence + honour",
+      "description": "shipped SPA + REST option-3 verbatim-from-refused-state money probe: fresh scaffold; add spa; add rest (refused with the reshaped message); follow option 3 EXACTLY as printed (`rcf define blueprint supersede errorEnvelope --incoming <rest>` and `rcf define blueprint supersede authModel --incoming <rest>`) with ZERO prep; then re-run `rcf define blueprint add <rest>` and verify co-residence + honour",
       "testPointer": "test/blueprint/cli.test.js::shipped SPA + REST: option 3 executes VERBATIM from the refused-add state (rev-3 P1-1, Baz ruling on the conflict-pair supersede precondition)",
       "status": "pending"
     },
     {
       "id": "TC-027-add-reason-persists",
       "acId": "AC-1002-6",
-      "description": "rcf blueprint add --reason attaches the ruling text to every resolutions[] record on that add",
-      "testPointer": "test/blueprint/cli.test.js::rcf blueprint add --reason: reason lands on every resolution record (rev-2 P1-2)",
+      "description": "rcf define blueprint add --reason attaches the ruling text to every resolutions[] record on that add",
+      "testPointer": "test/blueprint/cli.test.js::rcf define blueprint add --reason: reason lands on every resolution record (rev-2 P1-2)",
       "status": "pending"
     },
     {
       "id": "TC-027-add-reason-whitespace-refused",
       "acId": "AC-1002-6",
       "description": "whitespace-only --reason on add refused at the writer edge (exit 2, no record written)",
-      "testPointer": "test/blueprint/cli.test.js::rcf blueprint add --reason: whitespace-only reason is refused at the writer edge (rev-2 P1-2)",
+      "testPointer": "test/blueprint/cli.test.js::rcf define blueprint add --reason: whitespace-only reason is refused at the writer edge (rev-2 P1-2)",
       "status": "pending"
     },
     {
       "id": "TC-027-add-resolve-dedupes-with-warn",
       "acId": "AC-1002-7",
       "description": "duplicate --resolve for the same topic keeps the first declaration, drops the rest, and warns on stderr",
-      "testPointer": "test/blueprint/cli.test.js::rcf blueprint add --resolve: duplicate topic dedupes with a stderr warning; only one record persists (rev-2 P3-b)",
+      "testPointer": "test/blueprint/cli.test.js::rcf define blueprint add --resolve: duplicate topic dedupes with a stderr warning; only one record persists (rev-2 P3-b)",
       "status": "pending"
     },
     {
       "id": "TC-027-add-resolve-error-no-double-prefix",
       "acId": "AC-1002-7",
       "description": "--resolve validation error carries the CLI's single '[error] blueprint add: ' prefix — the underlying rcfError message MUST NOT prepend its own 'blueprint add: '",
-      "testPointer": "test/blueprint/cli.test.js::rcf blueprint add --resolve: validation error carries no doubled prefix (rev-2 P3-a)",
+      "testPointer": "test/blueprint/cli.test.js::rcf define blueprint add --resolve: validation error carries no doubled prefix (rev-2 P3-a)",
       "status": "pending"
     },
     {
@@ -105,7 +105,7 @@
       "id": "TC-027-supersede-no-double-prefix",
       "acId": "AC-1002-10",
       "description": "every error path in supersede.js exits at the CLI with exactly one `[error] blueprint supersede: ` prefix; the doubled `blueprint supersede: blueprint supersede:` string never appears",
-      "testPointer": "test/blueprint/cli.test.js::rcf blueprint supersede: every rcfError message lands with exactly one `[error] blueprint supersede:` prefix (rev-3 mechanical P1)",
+      "testPointer": "test/blueprint/cli.test.js::rcf define blueprint supersede: every rcfError message lands with exactly one `[error] blueprint supersede:` prefix (rev-3 mechanical P1)",
       "status": "pending"
     }
   ],

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

@@ -2,7 +2,7 @@
   "id": "TS-028",
   "usId": "US-1003",
   "title": "Standards ingestion",
-  "purpose": "Cover rcf standards add reference-by-default and out-of-root copy paths.",
+  "purpose": "Cover rcf define standards add reference-by-default and out-of-root copy paths.",
   "testLevel": "unit",
   "acIds": [
     "AC-1003-1",

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

@@ -5,40 +5,40 @@
   "version": "0.1.0",
   "status": "draft",
   "title": "Blueprint verb family: add, list, remove, upgrade",
-  "description": "A `rcf blueprint` verb family provides the primary operator seat for composing blueprints onto a project. Every verb runs against the current tree, is idempotent where the semantics allow, and writes to the manifest's `blueprints[]` registry so the applied set is greppable and mechanical.",
+  "description": "A `rcf define blueprint` verb family provides the primary operator seat for composing blueprints onto a project. Every verb runs against the current tree, is idempotent where the semantics allow, and writes to the manifest's `blueprints[]` registry so the applied set is greppable and mechanical.",
   "asA": "operator on an RCF project",
-  "iWant": "to add, list, remove and upgrade blueprints against my project tree from a single `rcf blueprint` verb family",
+  "iWant": "to add, list, remove and upgrade blueprints against my project tree from a single `rcf define blueprint` verb family",
   "soThat": "composition is a first-class action instead of a one-shot init flag, and I can layer several blueprints across the life of a project without hand-editing the manifest",
   "acceptanceCriteria": [
     {
       "id": "AC-1001-1",
-      "description": "`rcf blueprint add <slug>` on a project with no blueprints applied writes an entry into `manifest.blueprints[]` and prints the applied slug and version",
+      "description": "`rcf define blueprint add <slug>` on a project with no blueprints applied writes an entry into `manifest.blueprints[]` and prints the applied slug and version",
       "given": "a validated project tree with no existing `blueprints[]` entries and a resolvable blueprint slug",
-      "when": "`rcf blueprint add <slug>` runs",
+      "when": "`rcf define blueprint add <slug>` runs",
       "then": "the manifest gains one `blueprints[]` entry (slug, version, appliedAt, source, and any contributions[] the blueprint wrote), and stdout names the slug and applied version",
       "testable": true
     },
     {
       "id": "AC-1001-2",
-      "description": "`rcf blueprint list` prints every applied blueprint (slug, version, appliedAt) in apply order",
+      "description": "`rcf define blueprint list` prints every applied blueprint (slug, version, appliedAt) in apply order",
       "given": "a project with one or more blueprints already applied",
-      "when": "`rcf blueprint list` runs",
+      "when": "`rcf define blueprint list` runs",
       "then": "every applied blueprint prints, one per line, ordered by `appliedAt`, with slug, version and apply timestamp columns",
       "testable": true
     },
     {
       "id": "AC-1001-3",
-      "description": "`rcf blueprint remove <slug>` removes the manifest entry and refuses when any project-authored doc references a contributed id",
+      "description": "`rcf define blueprint remove <slug>` removes the manifest entry and refuses when any project-authored doc references a contributed id",
       "given": "a project with the blueprint applied and no project-authored doc referencing any of the contributions[] ids",
-      "when": "`rcf blueprint remove <slug>` runs",
+      "when": "`rcf define blueprint remove <slug>` runs",
       "then": "the `blueprints[]` entry is dropped from the manifest; when a project-authored doc DOES reference a contribution, the verb exits non-zero and prints the referencing id + path without mutating the manifest",
       "testable": true
     },
     {
       "id": "AC-1001-4",
-      "description": "`rcf blueprint add <slug>` is idempotent: repeating on an already-applied clean slug is a no-op with a friendly message",
+      "description": "`rcf define blueprint add <slug>` is idempotent: repeating on an already-applied clean slug is a no-op with a friendly message",
       "given": "a project with `<slug>` already in `blueprints[]`",
-      "when": "`rcf blueprint add <slug>` runs again with no conflicts to surface",
+      "when": "`rcf define blueprint add <slug>` runs again with no conflicts to surface",
       "then": "the manifest is not rewritten, exit code is 0, and stdout names the slug as already applied at the applied version",
       "testable": true
     },

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

@@ -5,7 +5,7 @@
   "version": "0.1.0",
   "status": "draft",
   "title": "Composition, namespaced ids and scope:global ADR conflict surfacing",
-  "description": "Multiple blueprints may be applied to a single project. Blueprint-contributed docs are namespaced by the blueprint's slug so ids cannot collide across blueprints. A blueprint's ADR contributions may be tagged `scope: global`; two applied blueprints each contributing a `scope: global` ADR are a genuine conflict and `rcf blueprint add` surfaces both entries and refuses to write. Conflict-presentation ergonomics are prototype-unknown #1 (design brief); this US covers the first pass.",
+  "description": "Multiple blueprints may be applied to a single project. Blueprint-contributed docs are namespaced by the blueprint's slug so ids cannot collide across blueprints. A blueprint's ADR contributions may be tagged `scope: global`; two applied blueprints each contributing a `scope: global` ADR are a genuine conflict and `rcf define blueprint add` surfaces both entries and refuses to write. Conflict-presentation ergonomics are prototype-unknown #1 (design brief); this US covers the first pass.",
   "asA": "operator on an RCF project",
   "iWant": "blueprint contributions to compose without id collisions, and for `scope: global` ADR conflicts to be surfaced with both sides visible before anything is written",
   "soThat": "composition never silently merges incompatible whole-project decisions",
@@ -14,15 +14,15 @@
       "id": "AC-1002-1",
       "description": "Blueprint-contributed doc ids are namespaced with the blueprint's slug so composition cannot collide on ids at the id layer",
       "given": "two blueprints `spa` and `rest` that both contribute a REQ, a US and an ADR",
-      "when": "both are applied to the same project via `rcf blueprint add`",
+      "when": "both are applied to the same project via `rcf define blueprint add`",
       "then": "every contributed id carries the blueprint slug as its prefix (REQ/US: `spa-REQ-001`, `rest-REQ-001`) or as its kebab-suffix (ADR: `ADR-004-spa-theme`, `ADR-005-rest-versioning`); no two contributed ids across the two blueprints match",
       "testable": true
     },
     {
       "id": "AC-1002-2",
-      "description": "`rcf blueprint add <slug>` refuses when the new blueprint contributes a `scope: global` ADR on a topic already contributed by an applied blueprint",
+      "description": "`rcf define blueprint add <slug>` refuses when the new blueprint contributes a `scope: global` ADR on a topic already contributed by an applied blueprint",
       "given": "a project with blueprint `alpha` already applied contributing an ADR tagged `scope: global` on topic `versioning`",
-      "when": "`rcf blueprint add beta` runs and blueprint `beta` also contributes a `scope: global` ADR on `versioning`",
+      "when": "`rcf define blueprint add beta` runs and blueprint `beta` also contributes a `scope: global` ADR on `versioning`",
       "then": "the verb exits non-zero, prints both ADR ids and their file paths, and the manifest is unchanged",
       "testable": true
     },
@@ -31,7 +31,7 @@
       "description": "Conflict output leads with per-side headers (ADR title + one-sentence decision) and names four honest resolution paths with actual blueprint slugs filled in (Phase 3.5 reshape)",
       "given": "the conflict case above",
       "when": "the verb prints the conflict",
-      "then": "the output opens with `conflict on topic (<topic>)` and one line per side carrying `blueprint <slug>: <title> — <decision>` (or `<id> at <path>` when the tree did not carry the ADR body), a `refs:` footer with both ids + paths, and four honest resolutions numbered 1-4: adopt-incoming (`rcf blueprint remove <existing-slug>`), keep-existing (do not add the incoming), supersede via a project-level ADR (`rcf blueprint supersede <topic>`), and declare-on-add (`rcf blueprint add <source> --resolve <topic>=project:<ADR-id>`) — all with the actual conflicting blueprint slugs already substituted, no `<slug>` placeholders",
+      "then": "the output opens with `conflict on topic (<topic>)` and one line per side carrying `blueprint <slug>: <title> — <decision>` (or `<id> at <path>` when the tree did not carry the ADR body), a `refs:` footer with both ids + paths, and four honest resolutions numbered 1-4: adopt-incoming (`rcf define blueprint remove <existing-slug>`), keep-existing (do not add the incoming), supersede via a project-level ADR (`rcf define blueprint supersede <topic>`), and declare-on-add (`rcf define blueprint add <source> --resolve <topic>=project:<ADR-id>`) — all with the actual conflicting blueprint slugs already substituted, no `<slug>` placeholders",
       "testable": true
     },
     {
@@ -44,15 +44,15 @@
     },
     {
       "id": "AC-1002-5",
-      "description": "The supersession record's two sides are the CONFLICT PAIR — one currently-applied blueprint's scope:global ADR on the topic PLUS one incoming (would-be-applied) blueprint's scope:global ADR on the same topic — and the `rcf blueprint supersede` verb accepts the incoming blueprint as the second side. Operator ruling (Baz, w-2026-08-19-008 round 3): option 3 as printed in the reshaped conflict message MUST be executable EXACTLY as printed from the refused-add state, with zero prep. Mechanism (builder judgement against the chain): the reshaped conflict message names option 3 as `rcf blueprint supersede <topic> --incoming <source>`, carrying the very same `<source>` argument the refused add was invoked with; `supersede` loads the incoming blueprint from `--incoming <source>`, finds its scope:global ADR on `<topic>`, stamps its id into the incoming blueprint's namespace, and uses `{slug, adrId}` for the incoming blueprint as the second side of `manifest.resolutions[].supersedes[]`. The scaffolded project ADR file lists both blueprint ADR ids (applied + incoming stamped) under `relatedAdrs[]`; after supersede returns, re-running `rcf blueprint add <source>` succeeds because the detector honours the freshly-recorded resolution. `--incoming <source>` is required when applied count on the topic is < 2 and is silently accepted (informational) when applied count is already >= 2.",
+      "description": "The supersession record's two sides are the CONFLICT PAIR — one currently-applied blueprint's scope:global ADR on the topic PLUS one incoming (would-be-applied) blueprint's scope:global ADR on the same topic — and the `rcf define blueprint supersede` verb accepts the incoming blueprint as the second side. Operator ruling (Baz, w-2026-08-19-008 round 3): option 3 as printed in the reshaped conflict message MUST be executable EXACTLY as printed from the refused-add state, with zero prep. Mechanism (builder judgement against the chain): the reshaped conflict message names option 3 as `rcf define blueprint supersede <topic> --incoming <source>`, carrying the very same `<source>` argument the refused add was invoked with; `supersede` loads the incoming blueprint from `--incoming <source>`, finds its scope:global ADR on `<topic>`, stamps its id into the incoming blueprint's namespace, and uses `{slug, adrId}` for the incoming blueprint as the second side of `manifest.resolutions[].supersedes[]`. The scaffolded project ADR file lists both blueprint ADR ids (applied + incoming stamped) under `relatedAdrs[]`; after supersede returns, re-running `rcf define blueprint add <source>` succeeds because the detector honours the freshly-recorded resolution. `--incoming <source>` is required when applied count on the topic is < 2 and is silently accepted (informational) when applied count is already >= 2.",
       "given": "a fresh project with ZERO applied blueprints and the shipped SPA + REST blueprints on disk (both carry scope:global ADRs on camelCase topics `errorEnvelope` and `authModel`)",
-      "when": "the operator runs the flow verbatim as printed: `rcf blueprint add <spa>`; `rcf blueprint add <rest>` (refused with the reshaped four-honest-paths message); then follows option 3 EXACTLY as printed: `rcf blueprint supersede errorEnvelope --incoming <rest>` and `rcf blueprint supersede authModel --incoming <rest>`; then re-runs `rcf blueprint add <rest>`",
-      "then": "each supersede exits 0, scaffolds a project ADR at `rcf/adrs/adr-NNN-<kebab-topic>.json` (topic string verbatim on `manifest.resolutions[].topic`; ADR id tail kebab-ified per ADR-010), and appends a `manifest.resolutions[]` record listing both blueprint ADR ids in `supersedes[]`; the subsequent `rcf blueprint add <rest>` exits 0 (detector honours the resolution) and both blueprint ADR files co-reside on disk with the project supersedes-ADR alongside them",
+      "when": "the operator runs the flow verbatim as printed: `rcf define blueprint add <spa>`; `rcf define blueprint add <rest>` (refused with the reshaped four-honest-paths message); then follows option 3 EXACTLY as printed: `rcf define blueprint supersede errorEnvelope --incoming <rest>` and `rcf define blueprint supersede authModel --incoming <rest>`; then re-runs `rcf define blueprint add <rest>`",
+      "then": "each supersede exits 0, scaffolds a project ADR at `rcf/adrs/adr-NNN-<kebab-topic>.json` (topic string verbatim on `manifest.resolutions[].topic`; ADR id tail kebab-ified per ADR-010), and appends a `manifest.resolutions[]` record listing both blueprint ADR ids in `supersedes[]`; the subsequent `rcf define blueprint add <rest>` exits 0 (detector honours the resolution) and both blueprint ADR files co-reside on disk with the project supersedes-ADR alongside them",
       "testable": true
     },
     {
       "id": "AC-1002-6",
-      "description": "`rcf blueprint add --reason <text>` attaches the operator's ruling text to every `manifest.resolutions[]` record minted on that add. Whitespace-only reasons are refused at the writer edge (schema does not enforce a minimum floor on the field itself; the writer's floor is emptiness, not length).",
+      "description": "`rcf define blueprint add --reason <text>` attaches the operator's ruling text to every `manifest.resolutions[]` record minted on that add. Whitespace-only reasons are refused at the writer edge (schema does not enforce a minimum floor on the field itself; the writer's floor is emptiness, not length).",
       "given": "an incoming blueprint whose apply would collide on one or more topics, resolved via one or more --resolve declarations",
       "when": "the operator adds `--reason \"...\"` alongside the --resolve flags",
       "then": "every newly-minted resolutions[] record carries the reason string verbatim; a whitespace-only --reason exits 2 with an error naming the topic and no record is written",
@@ -60,7 +60,7 @@
     },
     {
       "id": "AC-1002-7",
-      "description": "Duplicate `--resolve` declarations for the same topic within a single `rcf blueprint add` are deduped: the first declaration is kept, subsequent declarations on the same topic are dropped, and a `[warn]` line names each dropped topic on stderr. The add still exits 0 on success; the manifest carries exactly one resolutions[] record per topic.",
+      "description": "Duplicate `--resolve` declarations for the same topic within a single `rcf define blueprint add` are deduped: the first declaration is kept, subsequent declarations on the same topic are dropped, and a `[warn]` line names each dropped topic on stderr. The add still exits 0 on success; the manifest carries exactly one resolutions[] record per topic.",
       "given": "an incoming blueprint whose apply would collide on topic X",
       "when": "the operator passes `--resolve X=project:ADR-A --resolve X=project:ADR-B` on the same command",
       "then": "the manifest carries exactly one resolutions[] record on topic X with `resolvedByAdrId: ADR-A` (first-wins), and stderr carries a warn line naming X as a duplicate --resolve topic",
@@ -70,7 +70,7 @@
       "id": "AC-1002-8",
       "description": "Conflict enrichment is symmetric: the CLI's conflict report and `--json` output both carry `title` + one-sentence `decision` on BOTH sides of a globalAdrTopic conflict — the existing side read from the walker's tree, the incoming side read from the blueprint's ADR file on disk. Round-1 only enriched the existing side, which read asymmetrically against shipped blueprints.",
       "given": "an incoming blueprint that would collide with an applied blueprint on a scope:global ADR topic, both ADRs carrying a title and a decision",
-      "when": "`rcf blueprint add <source>` refuses with the reshaped message (with or without --json)",
+      "when": "`rcf define blueprint add <source>` refuses with the reshaped message (with or without --json)",
       "then": "both `incoming` and `existing` sides render `blueprint <slug>: <title> — <decision>` in the terminal output, and `conflicts[].incoming` and `conflicts[].existing` both carry `title` and `decision` in the --json output",
       "testable": true
     },
@@ -86,7 +86,7 @@
       "id": "AC-1002-10",
       "description": "Error-message prefix discipline on supersede: rcfError messages returned from `src/blueprint/supersede.js` MUST NOT prepend their own `blueprint supersede: ` prefix — the CLI edge already writes `[error] blueprint supersede: ` on every rcfError from the supersede verb. Round-2 caught the same bug on the `add` path; round-3 catches it on the supersede path (six sites: supersede.js:54, :70, :85, :107, :145, :160).",
       "given": "any error path in `src/blueprint/supersede.js` (missing topic, --reason whitespace-only, sub-2 applied ADRs, missing prd/tad, overwrite guard tripped, ADR write ioFailure)",
-      "when": "`rcf blueprint supersede ...` runs into that error path at the CLI",
+      "when": "`rcf define blueprint supersede ...` runs into that error path at the CLI",
       "then": "the printed stderr line matches `^\\[error\\] blueprint supersede: <message>$` with exactly one `blueprint supersede: ` prefix; the string `blueprint supersede: blueprint supersede:` does not appear anywhere in the output",
       "testable": true
     }