rcf-lite 0.9.0 → 0.11.0

package/guidance/elicitation-playbook.md

@@ -4,7 +4,7 @@
 
 ## 1. Read this if
 
-You are the agent starting a project with a human. The end state is concrete: a validated RCF tree (PRD, requirements, stories with testable acceptance criteria, architecture captured as TAC / ADR) and an actionable FBS queue, reachable in one or two sittings. When you finish, `rcf validate` is clean and `rcf build --next` hands back a real work item.
+You are the agent starting a project with a human. The end state is concrete: a validated RCF tree (PRD, requirements, stories with testable acceptance criteria, architecture captured as TAC / ADR) and an actionable FBS queue, reachable in one or two sittings. When you finish, `rcf define validate` is clean and `rcf build bundle --next` hands back a real work item.
 
 This is the lite tier of the elicitation method: one operator voice, one agent, blank directory to first build loop. Section 9 states plainly what sits above this tier; section 11 states the integrity rules that hold across the whole conversation - read it, the failures it forecloses are quiet ones. Section 12 sets the register you hold with the operator throughout: plain language, one decision per message, the method invisible.
 
@@ -24,7 +24,7 @@ as it emerges     -> TAC / ADR (architecture, captured or authored)
 then              -> BS / FBS (the ordered build queue)
 ```
 
-Write documents as you go with `rcf create` and `rcf update`; do not batch the tree up in your head for one big write at the end. Run `rcf validate` after every level. Start from the scaffold:
+Write documents as you go with `rcf define create` and `rcf define update`; do not batch the tree up in your head for one big write at the end. Run `rcf define validate` after every level. Start from the scaffold:
 
 ```
 $ rcf init --project-name "Field notes" --non-interactive
@@ -61,11 +61,11 @@ One testable capability per REQ. Capture `category` (functional or non-functiona
 Decomposition heuristics. Too big: the REQ needs "and" to state ("capture and search and tag notes" is three). Too vague: no observable behaviour survives questioning ("the product should be fast" becomes a non-functional REQ only once "fast at what, measured how" has an answer). A REQ that resists both splits and sharpening usually belongs in the PRD's out-of-scope list instead.
 
 ```
-$ rcf create req --parent PRD-001 --title "Capture a note from the command line"
+$ rcf define create req --parent PRD-001 --title "Capture a note from the command line"
 REQ-002 created at rcf/requirements/req-002.json
 ```
 
-The created document carries a TODO description and default category / priority values; replace the description and add the rationale with `rcf update` before moving on. TODOs left in place are honest, visible debt, but a REQ still wearing its defaults is not yet elicited.
+The created document carries a TODO description and default category / priority values; replace the description and add the rationale with `rcf define update` before moving on. TODOs left in place are honest, visible debt, but a REQ still wearing its defaults is not yet elicited.
 
 ## 5. Stories and acceptance criteria (US / AC)
 
@@ -77,7 +77,7 @@ Question frames per REQ:
 - Walk me through one concrete use, start to finish. The walk-through is where ACs come from.
 
 ```
-$ rcf create us --parent REQ-002 --title "Capture a note in one command" --from-file story.json
+$ rcf define create us --parent REQ-002 --title "Capture a note in one command" --from-file story.json
 US-201 created at rcf/user-stories/us-201.json
 ```
 
@@ -91,7 +91,7 @@ The testable-AC quality bar, applied to every AC before it lands:
 - **`testable: true` means a machine could check it.** Read the AC as a test skeleton; if you cannot see the assertion, rewrite the AC.
 
 ```
-$ rcf create ac --parent US-201 --description "Adding a note creates a note file and exits 0" --from-file ac.json
+$ rcf define create ac --parent US-201 --description "Adding a note creates a note file and exits 0" --from-file ac.json
 AC-201-2 created at rcf/user-stories/us-201.json
 ```
 
@@ -169,17 +169,17 @@ Same story, one AC versus five. The extra four are not gold-plating - they are t
 
 Every REQ this playbook draws out has a shape (§5.5.1), and each shape carries a baseline set of acceptance criteria (§5.5.2) that must hold unless the operator explicitly rules otherwise. Baselines exist because a UI REQ without a shared-nav AC lets the build ship a UI without a shared nav, and a persistence REQ without a crash-safety AC lets the build ship a store that loses writes on kill. The four-questions sweep of §5 asks the operator what they want, which is the right question. It does not ask what any operator would want if they knew to ask. The baselines are that second question, mechanised.
 
-Silence is not agreement. When the sweep proposes a baseline AC, the operator either accepts it or opts out with a recorded reason. A "we can skip that for now" without a reason leaves the sweep open, and Stage 1 (Define) refuses `rcf build --next` for any FBS that binds ACs on a story with open sweeps. The refusal is the safeguard against the exact failure mode that produced four review-phase defects on the cold run.
+Silence is not agreement. When the sweep proposes a baseline AC, the operator either accepts it or opts out with a recorded reason. A "we can skip that for now" without a reason leaves the sweep open, and Stage 1 (Define) refuses `rcf build bundle --next` for any FBS that binds ACs on a story with open sweeps. The refusal is the safeguard against the exact failure mode that produced four review-phase defects on the cold run.
 
 ### 5.5.1 The five shapes
 
-`webUi` for HTML rendered for a person to look at. `httpApi` for programmatic HTTP endpoints for machine clients. `auth` for identity, sessions, credentials. `persistence` for durable storage the operator's data lives in across restarts. `notifications` for outbound delivery to a human channel. A REQ can carry more than one; a REQ that carries none records `shapes: [none]` (legitimate for pure business-rule REQs). Detection is deterministic keyword-scan over the REQ's `title`, `description` and `rationale` plus the parent PRD's `intent` and `problem` as fallback context; the classifier fires automatically on `rcf create req` and `rcf update req --description`, and `rcf req-classify <req-id>` re-runs it on demand.
+`webUi` for HTML rendered for a person to look at. `httpApi` for programmatic HTTP endpoints for machine clients. `auth` for identity, sessions, credentials. `persistence` for durable storage the operator's data lives in across restarts. `notifications` for outbound delivery to a human channel. A REQ can carry more than one; a REQ that carries none records `shapes: [none]` (legitimate for pure business-rule REQs). Detection is deterministic keyword-scan over the REQ's `title`, `description` and `rationale` plus the parent PRD's `intent` and `problem` as fallback context; the classifier fires automatically on `rcf define create req` and `rcf define update req --description`, and `rcf discover req-classify <req-id>` re-runs it on demand.
 
 ### 5.5.2 Baseline sweep and opt-out ledger
 
-`rcf req-baseline sweep --req <id>` walks every US under the target REQ and proposes any baseline AC not yet present. The operator accepts each candidate (which writes it as an AC with `provenance.authoredBy: baseline` and the `baselineKey` set) or opts out with a reason (which writes a `baselineAcOptOuts[]` entry so future USes under the same REQ inherit the ruling). The opt-out reason has a 20-character floor: a one-word "no" reads as silence, and silence is exactly what the ledger exists to prevent. The C+D-native `rcf req-baseline opt-out` verb is always available; Track A preflight's design-shape questions surface (`auth.htmlLoginPage` in v1) writes the same ledger for the preflight-driven case, so a preflight session and this playbook share one truth.
+`rcf discover req-baseline sweep --req <id>` walks every US under the target REQ and proposes any baseline AC not yet present. The operator accepts each candidate (which writes it as an AC with `provenance.authoredBy: baseline` and the `baselineKey` set) or opts out with a reason (which writes a `baselineAcOptOuts[]` entry so future USes under the same REQ inherit the ruling). The opt-out reason has a 20-character floor: a one-word "no" reads as silence, and silence is exactly what the ledger exists to prevent. The C+D-native `rcf discover req-baseline opt-out` verb is always available; Track A preflight's design-shape questions surface (`auth.htmlLoginPage` in v1) writes the same ledger for the preflight-driven case, so a preflight session and this playbook share one truth.
 
-Cross-references: the four-questions sweep of §5 still runs; baselines augment it, do not replace it. Track A preflight (see the build-cycle playbook §3 and `rcf preflight`) owns the design-shape questions that flip baselines before build. Track B's `uiBaseline.defaults` is the truth source for `webUi` baseline values (see `rcf ui-baseline`).
+Cross-references: the four-questions sweep of §5 still runs; baselines augment it, do not replace it. Track A preflight (see the build-cycle playbook §3 and `rcf discover preflight`) owns the design-shape questions that flip baselines before build. Track B's `uiBaseline.defaults` is the truth source for `webUi` baseline values (see `rcf discover ui-baseline`).
 
 ## 6. Capturing architecture as it emerges (TAC / ADR)
 
@@ -191,7 +191,7 @@ What is asked early is the question, not a provider. The owner is free to answer
 
 - **Ask it as its own item, early.** Put the deploy-target question in the conversation before the architecture takes any concrete shape. A one-line answer is enough to constrain everything downstream: "I've got Netlify", "it lives on my Cloudflare account", "it runs on my own machine". Those three are in alphabetical order, which is the only ordering rule this list has - it is not a ranking, and nothing in this playbook picks a provider for the owner.
 - **Constrain the stack to the answer.** Once the target is known, the stack you choose (section below) must be one that target can actually host. Do not commit a stack the host cannot run - a Node-and-native-module stack on a Cloudflare-only account is the exact dead-end this rule exists to foreclose. If the only good stack for the app is incompatible with the stated host, that is a tradeoff to surface (section 11), not a silent override.
-- **Capture it as an ADR on the project's own tree.** Record the deploy target and the stack constraint it implies as an ADR, so the decision is visible and revisable rather than buried in the agent's head. `rcf create adr --parent TAD-001 --title "Deploy target: <where> - stack constrained to <what it can host>"`.
+- **Capture it as an ADR on the project's own tree.** Record the deploy target and the stack constraint it implies as an ADR, so the decision is visible and revisable rather than buried in the agent's head. `rcf define create adr --parent TAD-001 --title "Deploy target: <where> - stack constrained to <what it can host>"`.
 - **Not choosing is also an answer.** "I do not know", "not yet", "I am not sure I want this built" and "this is not being deployed" are complete answers to the question, not failures to answer it. The two branches below take them, and neither ends with you naming a provider for the owner.
 
 ### When the owner does not know and wants to settle it: the hosting-choice walkthrough
@@ -213,7 +213,7 @@ Deferral does not mean the same thing for every capability, so branch on what th
 
 So the question per capability is "what would deferring this actually cost to keep open?", not "is this deferred?". Defer the decision that needs an account. Build the part that does not.
 
-**Record the deferral as the ADR.** A deferral is a decision and gets written down like one: `rcf create adr --parent TAD-001 --title "Deploy target: deferred - no target chosen"`, `status` left at `proposed`, context stating that the owner has not committed, consequences naming what stays open (the stack is unconstrained by a host; the done state is the local preview), alternatives being the options that were on the table and not taken. Leave it revisable - a deferral is a decision to decide later, and this ADR is what the later conversation reopens. An undecided deploy target recorded nowhere is indistinguishable from one nobody ever asked about.
+**Record the deferral as the ADR.** A deferral is a decision and gets written down like one: `rcf define create adr --parent TAD-001 --title "Deploy target: deferred - no target chosen"`, `status` left at `proposed`, context stating that the owner has not committed, consequences naming what stays open (the stack is unconstrained by a host; the done state is the local preview), alternatives being the options that were on the table and not taken. Leave it revisable - a deferral is a decision to decide later, and this ADR is what the later conversation reopens. An undecided deploy target recorded nowhere is indistinguishable from one nobody ever asked about.
 
 **Never let a deferral become a silent stub.** This is the one thing deferral must not do. When a capability is deferred outright, the acceptance criteria that require it are deferred with it, visibly - marked deferred, or lifted out of the queue and named as lifted - or scoped down to a stub the owner explicitly agreed to, in those words. An agent that quietly fakes the deferred thing (an auth path that waves everyone through, a store that forgets on restart, a send that goes nowhere) and then reports the build green has manufactured exactly the false green the verification side of this method exists to prevent. Deferring is honest; stubbing without saying so is not. The tree gives you nowhere to hide it either: an AC either holds or it is deferred, and both of those are things you say out loud.
 
@@ -224,9 +224,9 @@ Which document: a **TAC** is a lasting component - it has a purpose, responsibil
 Minimum capture: a TAC needs its purpose and responsibilities; an ADR needs context, decision and consequences, plus the alternatives considered and why each was not chosen. One honest sentence per field beats a page of hedged ones.
 
 ```
-$ rcf create tac --parent TAD-001 --title "Note store"
+$ rcf define create tac --parent TAD-001 --title "Note store"
 TAC-002 created at rcf/tacs/tac-002.json
-$ rcf create adr --parent TAD-001 --title "Notes are plain files on disk"
+$ rcf define create adr --parent TAD-001 --title "Notes are plain files on disk"
 ADR-002 created at rcf/adrs/adr-002.json
 ```
 
@@ -247,7 +247,7 @@ Group ACs into FBS items. One FBS is a coherent deliverable, buildable in one si
 - **Sizing bands.** `small` is roughly an hour to half a day (1-4h), `medium` half a day to a day (4-8h), `large` one to two days (8-16h). The schema caps `estimatedHours` at 16: an item that wants more is two items.
 
 ```
-$ rcf create fbs --parent BS-001 --title "Note capture command" --acs AC-201-2
+$ rcf define create fbs --parent BS-001 --title "Note capture command" --acs AC-201-2
 FBS-002 created at rcf/fbs/fbs-002.json
 ```
 
@@ -258,9 +258,9 @@ The done-bar, all five together:
 1. Every REQ has at least one US.
 2. Every US has at least one testable AC.
 3. The queue's head item is actionable: `rcf build` shows a `Next actionable` id.
-4. `rcf validate` is clean.
-5. `rcf coverage` has been run and its zero-covered baseline is understood.
-6. Every classified REQ has completed its baseline sweep (no open candidates). `rcf req-baseline sweep --all --status` prints the open-candidate queue; the Stage 1 gate refuses `rcf build --next` for any FBS binding an AC on a US that still has one.
+4. `rcf define validate` is clean.
+5. `rcf audit coverage` has been run and its zero-covered baseline is understood.
+6. Every classified REQ has completed its baseline sweep (no open candidates). `rcf discover req-baseline sweep --all --status` prints the open-candidate queue; the Stage 1 gate refuses `rcf build bundle --next` for any FBS binding an AC on a US that still has one.
 
 Queue-head evidence from the scratch project:
 
@@ -283,12 +283,12 @@ Parallel-safe tiers (items in the same tier have no dependency between them and
 Next actionable: FBS-001
 ```
 
-Note the head item: it is the scaffold's placeholder FBS, still wearing its TODO title, and it will be the first thing `rcf build --next` hands the build loop. Rescope it to real work or delete it before you declare the queue done; a placeholder at the head of the queue fails the done-bar even though it is technically actionable.
+Note the head item: it is the scaffold's placeholder FBS, still wearing its TODO title, and it will be the first thing `rcf build bundle --next` hands the build loop. Rescope it to real work or delete it before you declare the queue done; a placeholder at the head of the queue fails the done-bar even though it is technically actionable.
 
 And the coverage baseline:
 
 ```
-$ rcf coverage
+$ rcf audit coverage
 Coverage mode: shallow-any
 Requirements: 2  covered: 0  uncovered: 2
 
@@ -299,15 +299,15 @@ REQ-002      no       AC-201-1  no          -
                       AC-201-2  no          -
 ```
 
-Zero covered is the correct end state for elicitation. Tests come from the build cycle, stage by stage, not from this conversation. Stopping here is the discipline: the tree does not need to be complete, it needs to be valid, honest and actionable. New requirements will surface during the build; they enter through `rcf create`, not through reopening elicitation wholesale.
+Zero covered is the correct end state for elicitation. Tests come from the build cycle, stage by stage, not from this conversation. Stopping here is the discipline: the tree does not need to be complete, it needs to be valid, honest and actionable. New requirements will surface during the build; they enter through `rcf define create`, not through reopening elicitation wholesale.
 
 **Offer a review before the build starts.** The done-bar is met and the build loop is next, but the operator has not seen the tree you drafted from their answers. Do not roll straight into building. Offer the review, in plain words rather than document names: "The plan is drafted and everything checks out: what we're building, the requirements, and the build order. Want to look it over before I start building, or shall I go?" Then wait. A tree the operator never saw becomes a build they cannot course-correct, and the review is cheapest now, before any code hangs off the ACs. The build-cycle playbook (section 11) holds the same gate from the build side.
 
-**UI-baseline check when a Web UI REQ is present (Track B soft nudge).** After the tree is drafted and before Stage 1 of the first UI-bearing FBS begins, look at the requirements one more time: does any REQ shape as a Web UI (matched by the shared `matchReqShapeSignals` classifier's `webUi` shape, or by the operator naming pages / screens / dashboards in prose)? If so, prompt the operator to run `rcf ui-baseline init` before the build cycle picks up its first FBS. The baseline captures the ruled UI defaults once per project (theme mode, shared layout, contrast targets, component vocabulary, auth-flow expectations); every subsequent UI-bearing FBS inherits from it. This is a soft check, not a hard gate at elicitation time - the hard refusal fires later at `rcf design <fbs-id>` when the FBS is uiBearing and no baseline exists.
+**UI-baseline check when a Web UI REQ is present (Track B soft nudge).** After the tree is drafted and before Stage 1 of the first UI-bearing FBS begins, look at the requirements one more time: does any REQ shape as a Web UI (matched by the shared `matchReqShapeSignals` classifier's `webUi` shape, or by the operator naming pages / screens / dashboards in prose)? If so, prompt the operator to run `rcf discover ui-baseline init` before the build cycle picks up its first FBS. The baseline captures the ruled UI defaults once per project (theme mode, shared layout, contrast targets, component vocabulary, auth-flow expectations); every subsequent UI-bearing FBS inherits from it. This is a soft check, not a hard gate at elicitation time - the hard refusal fires later at `rcf define design <fbs-id>` when the FBS is uiBearing and no baseline exists.
 
 ## 8.5 Pre-flight config
 
-Between the tree being drafted (section 8) and the build cycle picking up its first FBS (build-cycle playbook, section 3), one more session runs: `rcf preflight`. The session is not part of elicitation but sits at the seam between it and the build. It exists because a mocked integration test looks identical to a live one, and the honest answer to "how are we verifying this" has to be captured while the operator is thinking about the product, not while a test suite is going green.
+Between the tree being drafted (section 8) and the build cycle picking up its first FBS (build-cycle playbook, section 3), one more session runs: `rcf discover preflight`. The session is not part of elicitation but sits at the seam between it and the build. It exists because a mocked integration test looks identical to a live one, and the honest answer to "how are we verifying this" has to be captured while the operator is thinking about the product, not while a test suite is going green.
 
 **What it is.** One pass over every third-party service the PRD (and optionally a TAD) names. The scanner surfaces candidates; the session forces one of five attestation modes per service, plus any applicable design-shape answers (v1 catalogue: `auth.htmlLoginPage`), and writes a `preFlightConfig` record on the manifest. No code changes at this stage.
 
@@ -327,7 +327,7 @@ Pick honestly. A `mocked` where the ship intent is `live` is the exact failure t
 
 **Credentials never enter the chain.** The session prompts for env-var NAMES only. Values are read from the shell at test / finalise time; the name-metadata lives in `.rcf/preflight-secrets.local.json`, which is gitignored via the managed block written by `rcf init`.
 
-**Hand-off to the build cycle.** Once the record is written, the build cycle picks up as normal. `rcf build --next` warns (not refuses) when an in-scope FBS touches an AC whose services are not covered by any `preFlightConfig` record; the operator re-runs `rcf preflight` and continues.
+**Hand-off to the build cycle.** Once the record is written, the build cycle picks up as normal. `rcf build bundle --next` warns (not refuses) when an in-scope FBS touches an AC whose services are not covered by any `preFlightConfig` record; the operator re-runs `rcf discover preflight` and continues.
 
 ## 9. What this playbook deliberately does not do
 
@@ -368,18 +368,18 @@ Agent:    So: as a note keeper, you want to capture a note with one
 The commands behind that exchange, run as it happened:
 
 ```
-$ rcf create req --parent PRD-001 --title "Capture a note from the command line"
+$ rcf define create req --parent PRD-001 --title "Capture a note from the command line"
 REQ-002 created at rcf/requirements/req-002.json
-$ rcf create us --parent REQ-002 --title "Capture a note in one command" --from-file story.json
+$ rcf define create us --parent REQ-002 --title "Capture a note in one command" --from-file story.json
 US-201 created at rcf/user-stories/us-201.json
-$ rcf create ac --parent US-201 --description "Adding a note creates a note file and exits 0" --from-file ac.json
+$ rcf define create ac --parent US-201 --description "Adding a note creates a note file and exits 0" --from-file ac.json
 AC-201-2 created at rcf/user-stories/us-201.json
 ```
 
 And the captured document, read back:
 
 ```
-$ rcf read US-201
+$ rcf define read US-201
 {
   "createdAt": "2026-07-06T12:26:00.851Z",
   "updatedAt": "2026-07-06T12:26:00.931Z",
@@ -410,7 +410,7 @@ $ rcf read US-201
 }
 ```
 
-One piece of visible debt in that read-back: `AC-201-1` is the placeholder `rcf create us` seeds every new story with. Fill it from the next walk-through or delete it; do not leave TODO criteria in a tree you are about to call done.
+One piece of visible debt in that read-back: `AC-201-1` is the placeholder `rcf define create us` seeds every new story with. Fill it from the next walk-through or delete it; do not leave TODO criteria in a tree you are about to call done.
 
 Frame, answer, document, command. That rhythm, held level by level through sections 3 to 7, is the whole method.
 

package/guidance/harness-template.md

@@ -92,7 +92,7 @@ leaving it out.
 
 ### RULE 3: The test layer is mandatory.
 
-Author TS and TC documents and run `rcf coverage --strict`. Do not
+Author TS and TC documents and run `rcf audit coverage --strict`. Do not
 declare the work done while coverage fails, unless the stakeholder has
 explicitly accepted the gap.
 
@@ -180,10 +180,52 @@ things the operator does not want in the shared repo. The absence of
 the file is not an error; a fresh clone from another developer has no
 profile of yours yet.
 
+### RULE 11: Validate the chain before you act on it.
+
+Before you emit a build spec, execute one, edit the tree, or run any
+verb that reads the tree as truth, run `rcf define validate`. The
+operator does not have to ask, and the check does not wait for a stage
+that names it. A dirty tree is caught here rather than mid-Build, mid-
+Test, or at the ship gate. If validation fails or coverage is broken
+against the work in hand, stop and surface the finding to the operator
+(RULE 12) before touching code or authoring documents. Everything
+downstream assumes the tree you are reading is the tree the referee
+thinks it is; the pre-action check is what keeps that assumption true.
+
+### RULE 12: Surface method findings in the operator's language.
+
+When `rcf define validate`, `rcf audit coverage`, `rcf audit trace` or a
+spec inspection turns up a gap, translate it into plain intent before
+you raise it. The operator hears the behaviour that is missing, not the
+document id that is missing. "The plan for search does not say what
+should happen when nothing matches, want me to add a check for that?"
+beats "AC-207 has no covering TS". Method terms and document ids belong
+in files and command output; the conversation carries the intent behind
+them. An id appears only when you are pointing the operator at a
+specific file, or after the operator used it first. The general
+register for talking to the operator is set higher in this file; this
+rule is that register applied to findings.
+
+### RULE 13: The method's failure modes are yours to catch.
+
+The failure modes the method exists to guard against are agent-side
+self-checks, not defects for the operator to spot and name. Skipping a
+layer, gold-plating past the AC set, editing a test to pass instead of
+fixing the code, marking complete before the merge, drifting off the
+bundle, inventing a fact the stakeholder never gave you, treating a
+rubber-stamp read as review, marking a stage done without its referee
+output: you catch each one before the stage ends. Before you commit a
+stage, run the self-check: every in-scope AC maps to a diff location;
+every planned step traces to an AC id; the referee output actually ran
+and named the id you were working on; nothing landed the bundle did not
+ask for. A failure the operator has to point out is a failure you did
+not check for. The depth for each stage's self-check lives in the
+build-cycle playbook.
+
 ### Session start
 
-Run `rcf validate`. A broken tree is fixed or reported before anything
-else. Run `rcf build` for queue state: what is done, in progress,
+Run `rcf define validate`. A broken tree is fixed or reported before anything
+else. Run `rcf build queue` for queue state: what is done, in progress,
 blocked. Run `rcf doctor` if the last upgrade of the package changed
 these rules. The block you are reading may be out of date; `rcf doctor
 --fix` rewrites it.
@@ -194,17 +236,17 @@ Docs-review gate: when the tree has just been elicited, offer the
 stakeholder a review of it before the first build. Do not roll from
 elicitation straight into building without the offer.
 
-Run `rcf build --next` to get the spec bundle for the next actionable
+Run `rcf build bundle --next` to get the spec bundle for the next actionable
 item, then execute the five-stage runbook it prints: Define, Build,
 Review, Test, Finalise. Every stage ends in a commit. Drive the whole
-queue, not one item. After each item's Finalise, loop `rcf build --next`
+queue, not one item. After each item's Finalise, loop `rcf build bundle --next`
 until it reports the queue complete. If your harness can spawn
 sub-agents, run each FBS in its own worker so the driving context stays
 clean across the queue: one write worker at a time.
 
 Record lifecycle transitions with the exact mark commands the bundle
-prints. Never mark backwards. Run `rcf validate` after any tree edit,
-and `rcf trace <id>` or `rcf impact <id>` before touching anything with
+prints. Never mark backwards. Run `rcf define validate` after any tree edit,
+and `rcf audit trace <id>` or `rcf audit impact <id>` before touching anything with
 dependents. PR bodies are evidence-first: lead with what was verified
 and how, traced to AC and FBS ids, not a diff walk.
 
@@ -212,7 +254,7 @@ Run the fresh-context self-review every few FBS builds and once at the
 end: a reviewer that drives the running app against its ACs, not one
 that reads the code. Method: `rcf guidance build-cycle-playbook`,
 section 16. It is the cheap in-loop check between builds, and it is not
-the independent verification gate. `rcf finalise` runs that, and only
+the independent verification gate. `rcf build finalise` runs that, and only
 that writes `verified`.
 
 If context gets unreliable on a large build, do not stall. Write a
@@ -224,7 +266,7 @@ without re-elicitation.
 ### Write discipline
 
 Prefer the `rcf` verbs (`create`, `update`, `delete`, `link`) for tree
-edits. After any hand edit to a file under `rcf/`, run `rcf validate`
+edits. After any hand edit to a file under `rcf/`, run `rcf define validate`
 before proceeding.
 
 ### Escalation
@@ -254,4 +296,4 @@ These rules only govern a session that loads this fragment. A project that was n
 
 ## Check it took
 
-Four checks. Ask the agent to state the loop; the answer should name the five stages and the mark commands. Ask what it does before authoring documents; the answer should name the elicitation playbook and stakeholder questions, not drafting. Watch its first `rcf build --next` cycle: the bundle's runbook should be followed stage by stage, with a commit at each stage end. And read its first message to the operator: it should be a few plain sentences ending in one clear question, with no rule numbers and no document-id inventory.
+Four checks. Ask the agent to state the loop; the answer should name the five stages and the mark commands. Ask what it does before authoring documents; the answer should name the elicitation playbook and stakeholder questions, not drafting. Watch its first `rcf build bundle --next` cycle: the bundle's runbook should be followed stage by stage, with a commit at each stage end. And read its first message to the operator: it should be a few plain sentences ending in one clear question, with no rule numbers and no document-id inventory.

package/guidance/managed/README.md

@@ -35,7 +35,7 @@ doctor writes into an installed project, see the files below.
   reports and exits 0 clean, 3 dirty. `rcf doctor --fix` is the only
   path that repairs.
 - **Never auto-repair.** No hook, no post-install script, no `rcf init`
-  or `rcf validate` sub-call invokes `--fix` implicitly. Init writes
+  or `rcf define validate` sub-call invokes `--fix` implicitly. Init writes
   the block on a fresh scaffold; doctor maintains an existing project.
   Both are operator-typed.
 

package/guidance/managed/agent-instructions-block.hash

@@ -1 +1 @@
-7f5e3c3bd4c2c6c4bc7d98d77f7d715c7c43278a39e5ecfd0e85ed8d64e199f5
+70e0048d6160f15191dfbcf43588b0ba4cd24349b7ee8098671f121110677348

package/guidance/managed/agent-instructions-block.md

@@ -79,7 +79,7 @@ leaving it out.
 
 ### RULE 3: The test layer is mandatory.
 
-Author TS and TC documents and run `rcf coverage --strict`. Do not
+Author TS and TC documents and run `rcf audit coverage --strict`. Do not
 declare the work done while coverage fails, unless the stakeholder has
 explicitly accepted the gap.
 
@@ -167,10 +167,52 @@ things the operator does not want in the shared repo. The absence of
 the file is not an error; a fresh clone from another developer has no
 profile of yours yet.
 
+### RULE 11: Validate the chain before you act on it.
+
+Before you emit a build spec, execute one, edit the tree, or run any
+verb that reads the tree as truth, run `rcf define validate`. The
+operator does not have to ask, and the check does not wait for a stage
+that names it. A dirty tree is caught here rather than mid-Build, mid-
+Test, or at the ship gate. If validation fails or coverage is broken
+against the work in hand, stop and surface the finding to the operator
+(RULE 12) before touching code or authoring documents. Everything
+downstream assumes the tree you are reading is the tree the referee
+thinks it is; the pre-action check is what keeps that assumption true.
+
+### RULE 12: Surface method findings in the operator's language.
+
+When `rcf define validate`, `rcf audit coverage`, `rcf audit trace` or a
+spec inspection turns up a gap, translate it into plain intent before
+you raise it. The operator hears the behaviour that is missing, not the
+document id that is missing. "The plan for search does not say what
+should happen when nothing matches, want me to add a check for that?"
+beats "AC-207 has no covering TS". Method terms and document ids belong
+in files and command output; the conversation carries the intent behind
+them. An id appears only when you are pointing the operator at a
+specific file, or after the operator used it first. The general
+register for talking to the operator is set higher in this file; this
+rule is that register applied to findings.
+
+### RULE 13: The method's failure modes are yours to catch.
+
+The failure modes the method exists to guard against are agent-side
+self-checks, not defects for the operator to spot and name. Skipping a
+layer, gold-plating past the AC set, editing a test to pass instead of
+fixing the code, marking complete before the merge, drifting off the
+bundle, inventing a fact the stakeholder never gave you, treating a
+rubber-stamp read as review, marking a stage done without its referee
+output: you catch each one before the stage ends. Before you commit a
+stage, run the self-check: every in-scope AC maps to a diff location;
+every planned step traces to an AC id; the referee output actually ran
+and named the id you were working on; nothing landed the bundle did not
+ask for. A failure the operator has to point out is a failure you did
+not check for. The depth for each stage's self-check lives in the
+build-cycle playbook.
+
 ### Session start
 
-Run `rcf validate`. A broken tree is fixed or reported before anything
-else. Run `rcf build` for queue state: what is done, in progress,
+Run `rcf define validate`. A broken tree is fixed or reported before anything
+else. Run `rcf build queue` for queue state: what is done, in progress,
 blocked. Run `rcf doctor` if the last upgrade of the package changed
 these rules. The block you are reading may be out of date; `rcf doctor
 --fix` rewrites it.
@@ -181,17 +223,17 @@ Docs-review gate: when the tree has just been elicited, offer the
 stakeholder a review of it before the first build. Do not roll from
 elicitation straight into building without the offer.
 
-Run `rcf build --next` to get the spec bundle for the next actionable
+Run `rcf build bundle --next` to get the spec bundle for the next actionable
 item, then execute the five-stage runbook it prints: Define, Build,
 Review, Test, Finalise. Every stage ends in a commit. Drive the whole
-queue, not one item. After each item's Finalise, loop `rcf build --next`
+queue, not one item. After each item's Finalise, loop `rcf build bundle --next`
 until it reports the queue complete. If your harness can spawn
 sub-agents, run each FBS in its own worker so the driving context stays
 clean across the queue: one write worker at a time.
 
 Record lifecycle transitions with the exact mark commands the bundle
-prints. Never mark backwards. Run `rcf validate` after any tree edit,
-and `rcf trace <id>` or `rcf impact <id>` before touching anything with
+prints. Never mark backwards. Run `rcf define validate` after any tree edit,
+and `rcf audit trace <id>` or `rcf audit impact <id>` before touching anything with
 dependents. PR bodies are evidence-first: lead with what was verified
 and how, traced to AC and FBS ids, not a diff walk.
 
@@ -199,7 +241,7 @@ Run the fresh-context self-review every few FBS builds and once at the
 end: a reviewer that drives the running app against its ACs, not one
 that reads the code. Method: `rcf guidance build-cycle-playbook`,
 section 16. It is the cheap in-loop check between builds, and it is not
-the independent verification gate. `rcf finalise` runs that, and only
+the independent verification gate. `rcf build finalise` runs that, and only
 that writes `verified`.
 
 If context gets unreliable on a large build, do not stall. Write a
@@ -211,7 +253,7 @@ without re-elicitation.
 ### Write discipline
 
 Prefer the `rcf` verbs (`create`, `update`, `delete`, `link`) for tree
-edits. After any hand edit to a file under `rcf/`, run `rcf validate`
+edits. After any hand edit to a file under `rcf/`, run `rcf define validate`
 before proceeding.
 
 ### Escalation

package/guidance/manifest.json

@@ -8,7 +8,7 @@
     {"slug": "persona-programme", "file": "persona-programme.md", "title": "Persona programme: tail-interview template"}
   ],
   "prompts": [
-    {"name": "rcf_execute_build_cycle", "file": "build-cycle-playbook.md", "description": "How to execute the RCF 5-stage build cycle well: per-stage guidance, referee commands, failure modes, escalation rules. Fetch once per session, then drive rcf build --next."},
+    {"name": "rcf_execute_build_cycle", "file": "build-cycle-playbook.md", "description": "How to execute the RCF 5-stage build cycle well: per-stage guidance, referee commands, failure modes, escalation rules. Fetch once per session, then drive rcf build bundle --next."},
     {"name": "rcf_elicit_requirements", "file": "elicitation-playbook.md", "description": "How to draw a valid RCF tree out of a conversation: question frames for PRD / REQ / US / AC, the testable-AC quality bar, TAC / ADR capture, FBS queue construction, and when to stop."}
   ],
   "platformInvariants": [

package/guidance/overview.md

@@ -25,9 +25,9 @@ The full per-type detail is in `rcf://docs/document-model`.
 
 Every RCF query is one of three questions:
 
-1. **Is it covered?** Does every acceptance criterion have a test case whose pointer resolves to a real test? (`rcf coverage`)
-2. **What does it trace to?** Which requirement asked for this; which stories, criteria and tests hang off it? (`rcf trace`)
-3. **What breaks if it changes?** Which documents and tests are invalidated by a change to this one? (`rcf impact`)
+1. **Is it covered?** Does every acceptance criterion have a test case whose pointer resolves to a real test? (`rcf audit coverage`)
+2. **What does it trace to?** Which requirement asked for this; which stories, criteria and tests hang off it? (`rcf audit trace`)
+3. **What breaks if it changes?** Which documents and tests are invalidated by a change to this one? (`rcf audit impact`)
 
 ## The build cycle in five lines
 
@@ -41,7 +41,7 @@ Every stage ends in a commit. The normative statement is `rcf://docs/build-cycle
 
 ## Mechanical, not semantic
 
-The tool referees structure, never adequacy. `rcf validate` proves every document matches its schema and every reference resolves; `rcf coverage` proves every acceptance criterion has a test case whose `testPointer` resolves to a real, named test in the tree - a test-case row with a dead or missing pointer is reported as `covered-unresolved`, never as coverage. Neither proves that the acceptance criteria capture the requirement's intent, or that a test asserts the right behaviour: a renamed test is caught, a gutted test that kept its name is not. That judgement belongs to the agent and the human operating the loop. The tool's contribution is to make the structural half of confidence mechanical, so judgement is spent only where judgement is needed.
+The tool referees structure, never adequacy. `rcf define validate` proves every document matches its schema and every reference resolves; `rcf audit coverage` proves every acceptance criterion has a test case whose `testPointer` resolves to a real, named test in the tree - a test-case row with a dead or missing pointer is reported as `covered-unresolved`, never as coverage. Neither proves that the acceptance criteria capture the requirement's intent, or that a test asserts the right behaviour: a renamed test is caught, a gutted test that kept its name is not. That judgement belongs to the agent and the human operating the loop. The tool's contribution is to make the structural half of confidence mechanical, so judgement is spent only where judgement is needed.
 
 ---
 

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "rcf-lite",
-  "version": "0.9.0",
+  "version": "0.11.0",
   "type": "module",
-  "description": "One-install tooling for the Requirements Confidence Framework (RCF): the unified `rcf` CLI (init, view, validate, build, verify, finalise and 25+ more verbs), an MCP server, the live tree viewer and the fresh-context adversarial ship-gate verifier. Consumes @stravica-ai/rcf-schemas.",
+  "description": "One-install tooling for the Requirements Confidence Framework (RCF): the unified `rcf` CLI grouped into the five RCF tool groups (discover, define, build, verify, audit) plus a small core set (init, doctor, guidance, mcp), an MCP server, the live tree viewer and the fresh-context adversarial ship-gate verifier. Consumes @stravica-ai/rcf-schemas.",
   "license": "Apache-2.0",
   "homepage": "https://github.com/Stravica/rcf-lite",
   "bugs": "https://github.com/Stravica/rcf-lite/issues",
@@ -20,8 +20,7 @@
     "node": ">=24.0.0"
   },
   "bin": {
-    "rcf": "bin/rcf.js",
-    "rcf-verify": "bin/rcf-verify.js"
+    "rcf": "bin/rcf.js"
   },
   "files": [
     "bin",
@@ -71,7 +70,6 @@
     "vendor": "node scripts/vendor-mermaid.mjs",
     "build:managed": "node scripts/gen-managed-artefacts.mjs",
     "canary:register": "node scripts/canary-register.mjs",
-    "rcf": "node bin/rcf.js",
-    "rcf-verify": "node bin/rcf-verify.js"
+    "rcf": "node bin/rcf.js"
   }
 }

package/rcf/adrs/adr-008.json

@@ -8,7 +8,7 @@
     {
       "name": "Require verification against the deployed runtime",
       "summary": "Mandate that every verification run against the real deployed target, removing the provenance ambiguity by removing local verification.",
-      "reasonNotChosen": "Not always possible for the owner (no deploy yet, no account), and it belongs to the productised independent gate (rcf-verify-lite); the base offering's job is to label provenance honestly, not to force a deployed run."
+      "reasonNotChosen": "Not always possible for the owner (no deploy yet, no account), and it belongs to the productised independent gate (rcf verify-lite); the base offering's job is to label provenance honestly, not to force a deployed run."
     },
     {
       "name": "Trust green suites as verification",

package/rcf/adrs/adr-009.json

@@ -1,12 +1,12 @@
 {
   "createdAt": "2026-07-20T17:03:19.722Z",
   "updatedAt": "2026-07-28T16:40:20.554Z",
-  "context": "The persona programme showed self-verification is only as truthful as the runtime it verifies against, and that a green suite plus a confident claim can still ship a user-facing defect (runs 03 and 05). The durable answer is a productised independent verification gate (rcf-verify-lite), being scoped separately at HQ. But the base offering needs a stopgap now, and it must not pretend to be the independent gate: an in-loop self-review by the same agent is not an independent check and cannot be sold as one.",
-  "decision": "The guidance carries interim self-review guidance - documentation and prompt-level, not a new subsystem - for a carefully-scoped manual-review subagent dispatch: a periodic review every few FBS builds plus one at the end of the build. The reviewer runs fresh-context, drives the APP against the acceptance criteria rather than reading the code, and targets the defect classes green suites miss: session-class bugs, false-promise UI (stubs that imply real actions), runtime mismatch (localhost versus deployed), dead auth paths, and dead code. The guidance states plainly that this is an interim stopgap until rcf-verify-lite exists and that it is not the independent verification gate.",
-  "consequences": "The base offering gains a review step that catches the defect classes the five-stage loop demonstrably missed, at documentation cost and with no new code surface to maintain. Because it is guidance, it can ship now and be retired or folded into rcf-verify-lite later without a migration. The cost and the honesty boundary are the same point: a same-programme reviewer is better than nothing and weaker than an independent gate, and the guidance says so rather than overclaiming. Update 2026-07-28: rcf-verify-lite has since shipped and rcf finalise runs it as the independent gate, so the 'stopgap until the gate exists' framing recorded in the decision above is spent. The decision itself stands - the self-review is still guidance, still not a subsystem, still not the gate - but it is now positioned as the cheap in-loop check that runs between builds, subordinate to the finalise gate rather than a placeholder for it, and AC-805-4 and the guidance were reworded to match.",
+  "context": "The persona programme showed self-verification is only as truthful as the runtime it verifies against, and that a green suite plus a confident claim can still ship a user-facing defect (runs 03 and 05). The durable answer is a productised independent verification gate (rcf verify-lite), being scoped separately at HQ. But the base offering needs a stopgap now, and it must not pretend to be the independent gate: an in-loop self-review by the same agent is not an independent check and cannot be sold as one.",
+  "decision": "The guidance carries interim self-review guidance - documentation and prompt-level, not a new subsystem - for a carefully-scoped manual-review subagent dispatch: a periodic review every few FBS builds plus one at the end of the build. The reviewer runs fresh-context, drives the APP against the acceptance criteria rather than reading the code, and targets the defect classes green suites miss: session-class bugs, false-promise UI (stubs that imply real actions), runtime mismatch (localhost versus deployed), dead auth paths, and dead code. The guidance states plainly that this is an interim stopgap until rcf verify-lite exists and that it is not the independent verification gate.",
+  "consequences": "The base offering gains a review step that catches the defect classes the five-stage loop demonstrably missed, at documentation cost and with no new code surface to maintain. Because it is guidance, it can ship now and be retired or folded into rcf verify-lite later without a migration. The cost and the honesty boundary are the same point: a same-programme reviewer is better than nothing and weaker than an independent gate, and the guidance says so rather than overclaiming. Update 2026-07-28: rcf verify-lite has since shipped and rcf build finalise runs it as the independent gate, so the 'stopgap until the gate exists' framing recorded in the decision above is spent. The decision itself stands - the self-review is still guidance, still not a subsystem, still not the gate - but it is now positioned as the cheap in-loop check that runs between builds, subordinate to the finalise gate rather than a placeholder for it, and AC-805-4 and the guidance were reworded to match.",
   "alternativesConsidered": [
     {
-      "name": "Wait for rcf-verify-lite",
+      "name": "Wait for rcf verify-lite",
       "summary": "Ship no review step until the productised independent gate exists.",
       "reasonNotChosen": "Leaves the base offering shipping the exact defect classes the programme caught, for months, against users who cannot catch them themselves."
     },

package/rcf/code-nodes/cn-016.json

@@ -2,7 +2,7 @@
   "cnId": "CN-016",
   "path": "src/view/mermaid-diagram.js",
   "title": "Mermaid diagram emission (file-level)",
-  "description": "Builds the per-requirement mermaid subdiagrams (REQ -> US -> AC -> FBS, and Code Node cross-links) that rcf view renders.",
+  "description": "Builds the per-requirement mermaid subdiagrams (REQ -> US -> AC -> FBS, and Code Node cross-links) that rcf audit view renders.",
   "implementsAcIds": [
     "AC-201-1",
     "AC-201-2",

package/rcf/code-nodes/cn-019.json

@@ -1,7 +1,7 @@
 {
   "cnId": "CN-019",
   "path": "src/cli/read.js",
-  "title": "rcf read subcommand (file-level)",
+  "title": "rcf define read subcommand (file-level)",
   "description": "Prints a document body or a single dot-path field by id, including inline AC / TC resolution.",
   "implementsAcIds": [
     "AC-301-1",

package/rcf/code-nodes/cn-020.json

@@ -1,7 +1,7 @@
 {
   "cnId": "CN-020",
   "path": "src/cli/create.js",
-  "title": "rcf create subcommand (file-level)",
+  "title": "rcf define create subcommand (file-level)",
   "description": "CLI parsing, per-kind mandatory-field checks and defaults for the create verb; delegates persistence to the writer.",
   "implementsAcIds": [
     "AC-302-1",

package/rcf/code-nodes/cn-021.json

@@ -1,7 +1,7 @@
 {
   "cnId": "CN-021",
   "path": "src/cli/update.js",
-  "title": "rcf update subcommand (file-level)",
+  "title": "rcf define update subcommand (file-level)",
   "description": "Parses --set dot-path lists and --from-file patches into a writer update call; refuses to touch immutable fields.",
   "implementsAcIds": [
     "AC-303-1",

package/rcf/code-nodes/cn-022.json

@@ -1,7 +1,7 @@
 {
   "cnId": "CN-022",
   "path": "src/cli/delete.js",
-  "title": "rcf delete subcommand (file-level)",
+  "title": "rcf define delete subcommand (file-level)",
   "description": "Refuses a delete by default when the target has dependents; --cascade opts in and drops backrefs; --dry-run plans without executing.",
   "implementsAcIds": [
     "AC-304-1",

package/rcf/code-nodes/cn-049.json

@@ -10,5 +10,5 @@
   "createdAt": "2026-07-20T18:03:32.280Z",
   "updatedAt": "2026-07-28T16:39:55.660Z",
   "title": "Self-review scoped as an in-loop check, not the gate",
-  "description": "Playbook s16 scopes the review as an in-loop check subordinate to the rcf finalise gate, guidance not a subsystem, not the independent gate (AC-805-4)."
+  "description": "Playbook s16 scopes the review as an in-loop check subordinate to the rcf build finalise gate, guidance not a subsystem, not the independent gate (AC-805-4)."
 }

package/rcf/code-nodes/cn-055.json

@@ -10,5 +10,5 @@
   "createdAt": "2026-08-11T00:00:00Z",
   "updatedAt": "2026-08-11T00:00:00Z",
   "title": "Unified `rcf` bin: verify subcommand dispatch",
-  "description": "The umbrella CLI entry point. Imports the alias bin's `main` and registers it as the `verify` entry on the top-level SUBCOMMANDS map so `rcf verify <verb>` dispatches through the same handlers as `rcf-verify <verb>`."
+  "description": "The umbrella CLI entry point. Imports the alias bin's `main` and registers it as the `verify` entry on the top-level SUBCOMMANDS map so `rcf verify <verb>` dispatches through the same handlers as `rcf verify <verb>`."
 }