rcf-lite 0.28.4 → 0.30.0

package/blueprints/security-auth-oauth2/contributions/user-stories/security-auth-oauth2-us-10112.json

@@ -60,7 +60,7 @@
       "disposition": "fixed",
       "ownerRef": {
         "tacId": "TAC-1103-security-auth-oauth2-session-bridge",
-        "field": "interfaces.enrichPrincipal.name"
+        "field": "interfaces"
       }
     },
     {

package/blueprints/security-auth-oauth2/contributions/user-stories/security-auth-oauth2-us-10114.json

@@ -20,7 +20,7 @@
       "disposition": "fixed",
       "ownerRef": {
         "tacId": "TAC-1103-security-auth-oauth2-session-bridge",
-        "field": "responsibilities.sessionInventory"
+        "field": "responsibilities"
       }
     },
     {
@@ -34,7 +34,7 @@
       "disposition": "fixed",
       "ownerRef": {
         "tacId": "TAC-1103-security-auth-oauth2-session-bridge",
-        "field": "responsibilities.sessionInventory"
+        "field": "responsibilities"
       }
     },
     {
@@ -48,7 +48,7 @@
       "disposition": "fixed",
       "ownerRef": {
         "tacId": "TAC-1103-security-auth-oauth2-session-bridge",
-        "field": "responsibilities.sessionInventory"
+        "field": "responsibilities"
       }
     },
     {
@@ -62,7 +62,7 @@
       "disposition": "fixed",
       "ownerRef": {
         "tacId": "TAC-1103-security-auth-oauth2-session-bridge",
-        "field": "responsibilities.sessionInventory"
+        "field": "responsibilities"
       }
     },
     {
@@ -76,7 +76,7 @@
       "disposition": "fixed",
       "ownerRef": {
         "tacId": "TAC-1103-security-auth-oauth2-session-bridge",
-        "field": "responsibilities.sessionInventory"
+        "field": "responsibilities"
       }
     }
   ],

package/blueprints/security-secrets-management/contributions/requirements/security-secrets-management-req-001.json

@@ -17,6 +17,6 @@
   "updatedAt": "2026-08-30T00:00:00Z",
   "deliveredBy": {
     "tacId": "TAC-902-security-secrets-management-manifest",
-    "field": "responsibilities.manifest"
+    "field": "responsibilities"
   }
 }

package/blueprints/security-secrets-management/contributions/requirements/security-secrets-management-req-002.json

@@ -17,6 +17,6 @@
   "updatedAt": "2026-09-10T00:00:00Z",
   "deliveredBy": {
     "tacId": "TAC-901-security-secrets-management-manager-client",
-    "field": "responsibilities.vendorAdapter"
+    "field": "responsibilities"
   }
 }

package/blueprints/security-secrets-management/contributions/requirements/security-secrets-management-req-003.json

@@ -17,6 +17,6 @@
   "updatedAt": "2026-08-30T00:00:00Z",
   "deliveredBy": {
     "tacId": "TAC-901-security-secrets-management-manager-client",
-    "field": "responsibilities.slice"
+    "field": "responsibilities"
   }
 }

package/blueprints/security-secrets-management/contributions/requirements/security-secrets-management-req-004.json

@@ -17,6 +17,6 @@
   "updatedAt": "2026-08-30T00:00:00Z",
   "deliveredBy": {
     "tacId": "TAC-901-security-secrets-management-manager-client",
-    "field": "responsibilities.audit"
+    "field": "responsibilities"
   }
 }

package/blueprints/security-secrets-management/contributions/requirements/security-secrets-management-req-005.json

@@ -17,6 +17,6 @@
   "updatedAt": "2026-08-30T00:00:00Z",
   "deliveredBy": {
     "tacId": "TAC-905-security-secrets-management-agent-cli",
-    "field": "responsibilities.stdin"
+    "field": "responsibilities"
   }
 }

package/blueprints/security-secrets-management/contributions/requirements/security-secrets-management-req-006.json

@@ -17,6 +17,6 @@
   "updatedAt": "2026-08-30T00:00:00Z",
   "deliveredBy": {
     "tacId": "TAC-903-security-secrets-management-env-reflector",
-    "field": "responsibilities.env"
+    "field": "responsibilities"
   }
 }

package/blueprints/security-secrets-management/contributions/requirements/security-secrets-management-req-007.json

@@ -17,6 +17,6 @@
   "updatedAt": "2026-08-30T00:00:00Z",
   "deliveredBy": {
     "tacId": "TAC-902-security-secrets-management-manifest",
-    "field": "responsibilities.environments"
+    "field": "responsibilities"
   }
 }

package/blueprints/security-secrets-management/contributions/requirements/security-secrets-management-req-008.json

@@ -17,6 +17,6 @@
   "updatedAt": "2026-08-30T00:00:00Z",
   "deliveredBy": {
     "tacId": "TAC-901-security-secrets-management-manager-client",
-    "field": "responsibilities.boot"
+    "field": "responsibilities"
   }
 }

package/blueprints/security-secrets-management/contributions/requirements/security-secrets-management-req-009.json

@@ -17,6 +17,6 @@
   "updatedAt": "2026-08-30T00:00:00Z",
   "deliveredBy": {
     "tacId": "TAC-904-security-secrets-management-rotation-gate",
-    "field": "responsibilities.rotationDays"
+    "field": "responsibilities"
   }
 }

package/blueprints/security-secrets-management/contributions/tacs/tac-901-security-secrets-management-manager-client.json

@@ -19,23 +19,23 @@
   "interfaces": [
     {
       "name": "vendorAdapter",
-      "kind": "read-write-api",
-      "description": "Project-supplied vendor binding implementing `readMany({ paths, credentials, environment })` returning `{ [name]: { value, lastRotatedAt } }` or an entry-level not-found marker, and `materialiseCredentials({ slicePaths, environment })` returning per-slice credentials the vendor deny-by-default enforces."
+      "kind": "other",
+      "description": "Project-supplied vendor binding implementing `readMany({ paths, credentials, environment })` returning `{ [name]: { value, lastRotatedAt } }` or an entry-level not-found marker, and `materialiseCredentials({ slicePaths, environment })` returning per-slice credentials the vendor deny-by-default enforces. (legacy kind: read-write-api)"
     },
     {
       "name": "manifest",
-      "kind": "read-api",
-      "description": "The manifest loader (TAC-902) resolving the current deployable's slice, per-environment paths, and `required` flags."
+      "kind": "other",
+      "description": "The manifest loader (TAC-902) resolving the current deployable's slice, per-environment paths, and `required` flags. (legacy kind: read-api)"
     },
     {
       "name": "auditSink",
-      "kind": "callback",
-      "description": "Structured-event sink invoked with `{ name, path, environment, principal, outcome, at }` on every fetch attempt; never invoked with the secret value."
+      "kind": "other",
+      "description": "Structured-event sink invoked with `{ name, path, environment, principal, outcome, at }` on every fetch attempt; never invoked with the secret value. (legacy kind: callback)"
     },
     {
       "name": "envSelector",
-      "kind": "read-api",
-      "description": "The boot-input resolver for the active environment: a process variable, a boot flag, or a project-authored selector. Returns exactly one environment string or refuses ambiguity."
+      "kind": "other",
+      "description": "The boot-input resolver for the active environment: a process variable, a boot flag, or a project-authored selector. Returns exactly one environment string or refuses ambiguity. (legacy kind: read-api)"
     }
   ],
   "dependencies": [

package/blueprints/security-secrets-management/contributions/tacs/tac-902-security-secrets-management-manifest.json

@@ -18,13 +18,13 @@
   "interfaces": [
     {
       "name": "fileSystem",
-      "kind": "read-api",
-      "description": "Project-supplied file reader accepting a repo-root-relative path and returning UTF-8 bytes; injected for test surface."
+      "kind": "other",
+      "description": "Project-supplied file reader accepting a repo-root-relative path and returning UTF-8 bytes; injected for test surface. (legacy kind: read-api)"
     },
     {
       "name": "yamlParser",
-      "kind": "read-api",
-      "description": "YAML parser accepting bytes and returning a plain object; injected so the project supplies its own dependency."
+      "kind": "other",
+      "description": "YAML parser accepting bytes and returning a plain object; injected so the project supplies its own dependency. (legacy kind: read-api)"
     }
   ],
   "dependencies": [],

package/blueprints/security-secrets-management/contributions/tacs/tac-903-security-secrets-management-env-reflector.json

@@ -17,13 +17,13 @@
   "interfaces": [
     {
       "name": "fileSystem",
-      "kind": "read-write-api",
-      "description": "Project-supplied file reader-writer supporting temp-file creation and atomic rename."
+      "kind": "other",
+      "description": "Project-supplied file reader-writer supporting temp-file creation and atomic rename. (legacy kind: read-write-api)"
     },
     {
       "name": "gitignoreCheck",
-      "kind": "read-api",
-      "description": "Project-supplied predicate answering whether a given path is gitignored (usually a shell-out to `git check-ignore`)."
+      "kind": "other",
+      "description": "Project-supplied predicate answering whether a given path is gitignored (usually a shell-out to `git check-ignore`). (legacy kind: read-api)"
     }
   ],
   "dependencies": [

package/blueprints/security-secrets-management/contributions/tacs/tac-904-security-secrets-management-rotation-gate.json

@@ -18,23 +18,23 @@
   "interfaces": [
     {
       "name": "vendorAdapter",
-      "kind": "read-api",
-      "description": "The same vendor binding the Secrets Manager client uses (TAC-901), scoped to a rotation-metadata read (no value fetch is required for the gate's own operation)."
+      "kind": "other",
+      "description": "The same vendor binding the Secrets Manager client uses (TAC-901), scoped to a rotation-metadata read (no value fetch is required for the gate's own operation). (legacy kind: read-api)"
     },
     {
       "name": "overrideStore",
-      "kind": "read-api",
-      "description": "Reads the operator-authored override file (project-authored path; a JSON or YAML file listing per-name `{ author, expiresAt, reason }` entries)."
+      "kind": "other",
+      "description": "Reads the operator-authored override file (project-authored path; a JSON or YAML file listing per-name `{ author, expiresAt, reason }` entries). (legacy kind: read-api)"
     },
     {
       "name": "clock",
-      "kind": "clock",
-      "description": "Injectable millisecond wall clock for the elapsed-days arithmetic."
+      "kind": "other",
+      "description": "Injectable millisecond wall clock for the elapsed-days arithmetic. (legacy kind: clock)"
     },
     {
       "name": "auditSink",
-      "kind": "callback",
-      "description": "The same sink shape TAC-901 uses; the gate emits override-applied and rotation-expired events through it."
+      "kind": "other",
+      "description": "The same sink shape TAC-901 uses; the gate emits override-applied and rotation-expired events through it. (legacy kind: callback)"
     }
   ],
   "dependencies": [

package/blueprints/security-secrets-management/contributions/tacs/tac-905-security-secrets-management-agent-cli.json

@@ -18,13 +18,13 @@
   "interfaces": [
     {
       "name": "process",
-      "kind": "read-api",
-      "description": "The host process's argv, stdin, stdout, stderr, and env; the CLI reads argv and stdin, writes to stdout and stderr, and reads a small allow-listed env slice (audit principal id, active environment)."
+      "kind": "other",
+      "description": "The host process's argv, stdin, stdout, stderr, and env; the CLI reads argv and stdin, writes to stdout and stderr, and reads a small allow-listed env slice (audit principal id, active environment). (legacy kind: read-api)"
     },
     {
       "name": "logSink",
-      "kind": "callback",
-      "description": "The CLI's own log destination (stderr by default; a file when `--log-file` is set); every write passes through the redactor."
+      "kind": "other",
+      "description": "The CLI's own log destination (stderr by default; a file when `--log-file` is set); every write passes through the redactor. (legacy kind: callback)"
     }
   ],
   "dependencies": [

package/fixtures/canary-manifest.json

@@ -1,9 +1,9 @@
 {
   "registerCanary": [
     {
-      "id": "rc-2026-09-30-001",
-      "createdAt": "2026-09-30T15:30:02.583Z",
-      "buildVersion": "0.28.4-mockdriver",
+      "id": "rc-2026-10-03-001",
+      "createdAt": "2026-10-03T21:47:34.735Z",
+      "buildVersion": "0.30.0-mockdriver",
       "fixturePromptId": "canary-prompt-01",
       "responseWordCount": 55,
       "grades": {
@@ -34,9 +34,9 @@
       "shipDespiteFailReason": "mock canary driver used; no real subagent was dispatched. This record verifies canary infrastructure only, not the register itself."
     },
     {
-      "id": "rc-2026-09-30-002",
-      "createdAt": "2026-09-30T15:30:02.584Z",
-      "buildVersion": "0.28.4-mockdriver",
+      "id": "rc-2026-10-03-002",
+      "createdAt": "2026-10-03T21:47:34.736Z",
+      "buildVersion": "0.30.0-mockdriver",
       "fixturePromptId": "canary-prompt-02",
       "responseWordCount": 55,
       "grades": {
@@ -67,9 +67,9 @@
       "shipDespiteFailReason": "mock canary driver used; no real subagent was dispatched. This record verifies canary infrastructure only, not the register itself."
     },
     {
-      "id": "rc-2026-09-30-003",
-      "createdAt": "2026-09-30T15:30:02.584Z",
-      "buildVersion": "0.28.4-mockdriver",
+      "id": "rc-2026-10-03-003",
+      "createdAt": "2026-10-03T21:47:34.736Z",
+      "buildVersion": "0.30.0-mockdriver",
       "fixturePromptId": "canary-prompt-03",
       "responseWordCount": 55,
       "grades": {

package/guidance/define-draft-shapes.md

@@ -0,0 +1,89 @@
+# Drafting the engineer's entry shapes
+
+This document is the content of the `rcf_define_draft_shapes` MCP
+prompt served argument-free by the server. The agent reads it once
+per session and runs the draft pass after L1 is green. The product
+owner is not in the room; the agent populates `[draft]`-marked
+entities, components and interfaces so the engineer walks into a tree
+whose shape is honest about what is still owed.
+
+## When to run
+
+Run this pass once `rcf define readiness --level intent` prints
+`levels.intentComplete.ok === true` and the product owner has stepped
+back. Not before. The draft pass reads only the brief ledger, the
+decisions ledger and the current tree; it writes only `[draft]`-marked
+content. `shapes:draftSettled` then lists exactly what the engineer
+has yet to own.
+
+Nothing in the draft pass can fail a product-owner check. That is the
+property that keeps L1 and the draft pass independent. If an edit
+would fail any check in the `productOwner` persona, stop and raise it
+back to the intent loop (it was not an engineer-only question).
+
+## The three homes
+
+The `[draft]` marker lives on three homes in 0.30.0. The agent writes
+to all three; `shapes:draftSettled` reads back from all three.
+
+- `TAD.dataArchitecture.coreEntities[].description` begins `[draft]`
+  for every entity minted from an `entity` statement. The marker
+  reports under id `TAD.entity:<name>`.
+- `TAC.purpose` begins `[draft]` for every TAC stub minted from a
+  `surface` or `externalSystem` cluster. The marker reports under id
+  `<tacId>`.
+- `TAC.interfaces[].description` begins `[draft]` for every interface
+  pre-populated inside a draft stub. The marker reports under id
+  `<tacId>:<name>`.
+
+Each marker is `[draft]` followed by a space and the one-sentence
+seed body. Leading whitespace is tolerated by the reader; keep the
+marker at the start of the string regardless.
+
+## The four writes
+
+Walk the brief in this order; each step writes `[draft]` content only.
+
+1. One `TAD.dataArchitecture.coreEntities[]` entry per `entity`
+   statement. `description` begins `[draft]` and quotes the
+   statement's source so the engineer can trace it. Use the statement
+   text to pick a name in UpperCamel; the engineer renames when the
+   entity is owned.
+2. One TAC stub per `surface` or `externalSystem` cluster when no
+   TAC exists for it. `purpose` begins `[draft]`; `responsibilities`
+   lists the statements the surface or external system serves (one
+   bullet per statement, in the brief's words). Pick a `tacId` of the
+   next free number and a descriptive slug; the engineer renames when
+   the TAC is owned.
+3. On each draft TAC, `[draft]` interfaces with real kinds from the
+   closed vocabulary (`recordShape`, `httpRoute`, `event`,
+   `cliCommand`, `uiRoute`, `port`, `fileFormat`, `fixture`,
+   `other`). Draft one of each kind the surface uses:
+   - a `recordShape` per entity the surface owns, with `fields:`
+     guessed from the brief;
+   - a `uiRoute` per surface;
+   - an `httpRoute` per exchange with an external system.
+   `description` begins `[draft]` with the one-line what-this-is.
+4. `rcf discover req-classify` over every REQ created in the loop, so
+   `skeleton:reqShape` passes where the classifier is confident and
+   the engineer sees only the rest. The classifier is already
+   available under `src/review/` or `src/discover/`; this prompt only
+   invokes it.
+
+## The read-back
+
+After the pass, run `rcf define readiness --json` and read
+`stages[].checks[]`. `shapes:draftSettled` is the engineer's entry
+list: every id it names is a shape the agent pre-populated and the
+engineer still has to settle. `shapes:tacHasInterface` and
+`shapes:kindVocabulary` have already applied to drafts, so an empty
+`shapes:tacHasInterface` finding means every stub carries at least
+one interface and an empty `shapes:kindVocabulary` finding means
+every interface's kind is in the closed vocabulary. The template
+marker check and the entity join arrive in a later PR; the draft
+pass does not need them to be honest about what is drafted.
+
+Hand over by naming the three id forms the engineer will see
+(`<tacId>:<name>`, `<tacId>`, `TAD.entity:<name>`) and the one verb
+they will run to walk them (`rcf define readiness`). Nothing further
+is said; the engineer owns the ladder from here.

package/guidance/define-intake.md

@@ -0,0 +1,97 @@
+# Document intake into the brief ledger
+
+This document is the content of the `rcf_define_intake` MCP prompt
+served argument-free by the server. It walks the harness through
+intake and lands every finding as an open-question statement the
+intent loop then asks.
+
+## What intake is
+
+The owner hands over a folder. One file is the brief (short, prose,
+the "what we are building" document); the rest are supporting
+documents (ADRs, spec sketches, old READMEs, OpenAPI YAML, meeting
+notes). The split that reaches the brief ledger is the harness's
+work; the mechanical scans and the follow-up questions are
+rcf-lite's.
+
+Intake is harness-split and tool-scanned. The harness writes
+`<source>.statements.md` beside each source; rcf-lite mints the
+statements, runs the three mechanical scans against the existing
+body, and appends one `openQuestion` statement per finding. The loop
+then reads one check (`brief:openQuestions`) and the owner answers
+in one place (ADR-4130).
+
+## The walk
+
+Walk the folder brief-first. For each source, in this order:
+
+1. Open the source.
+2. Split it into one statement per line. A statement is a sentence
+   that stands on its own: a capability (something the product must
+   do), a constraint (a rule it must obey), an actor (a person or
+   role), an entity (a thing it keeps track of), an externalSystem
+   (another system), a surface (a screen or channel), outOfScope
+   (something explicitly not in), an openQuestion (a question still
+   to answer), or an amendment (a correction to an earlier
+   statement).
+3. Write `<source>.statements.md` next to the source. Each line is
+   one statement with a leading `[kind]` marker and a trailing
+   `(source: <path>:<line-span>)` marker.
+4. Show the file to the owner in one message. Correct based on their
+   reply.
+5. Run `rcf define ledger brief add --from <path>` (or the
+   `rcf_define_ledger` MCP tool with `verb: add`, `from: <path>`).
+   The mechanical scans run by default; findings are appended as
+   openQuestion statements. Report the scan findings as plain
+   questions.
+6. Move to the next source.
+
+Never add two sources through one `brief add --from`. Each `add`
+scans the new ids against the existing body, and the scan source
+marker `scan:<name>:<ids>` names the ids from both sides.
+
+## The line grammar
+
+Each line of a statement file is a statement. The grammar:
+
+```
+[<kind>] <text> (source: <path>:<line-span>)
+```
+
+- `[<kind>]` is one of the nine kinds above. When absent, the kind
+  defaults to the harness's `--kind` flag (default `capability`), or
+  to `openQuestion` when the line ends with `?` or begins with
+  `TBC`, `TBD`, `Open:` or `Question:`.
+- `(source: ...)` names the file and the line range in the source.
+  When absent, the harness's `--source` flag or the file path itself
+  is used.
+- Everything between the two markers is the statement text,
+  verbatim.
+
+## What the owner sees
+
+A statement file is operator prose. The owner reads it; the harness
+corrects based on their reply. Example:
+
+```
+[capability] Officers can put a loan on hold for up to 30 days. (source: briefs/loans.md:12-14)
+[constraint] A loan on hold must not accrue late fees. (source: briefs/loans.md:15)
+[openQuestion] Who approves a hold longer than 30 days? (source: briefs/loans.md:16)
+```
+
+After `brief add --from` runs, the loop will ask about each of these
+through `rcf define questions --persona productOwner`.
+
+## After intake
+
+Run `rcf define questions --persona productOwner`. The next set is
+the `resolvedBy` questions for every capability, constraint, entity,
+actor, externalSystem and surface statement, suggesting existing
+REQ titles that share two or more words of 4+ characters. The owner
+decides which become new REQs, which point at existing REQs, and
+which are omitted.
+
+At L1 (`levels.intentComplete.ok === true`) the agent pre-populates
+`[draft]` entities, components and interfaces as engineer entry
+material. These are drafts the engineer refines; they are never a
+product-owner blocker.

package/guidance/define-intent.md

@@ -0,0 +1,107 @@
+# The product-owner intent loop
+
+This document is the operator-side reference for the DEFINE step 3
+intent-complete loop. It is the content of the `rcf_define_intent` MCP
+prompt and the `rcf://docs/define-intent` resource. The agent reads it
+once per session and drives the loop; the product owner never sees any
+of it.
+
+## The shape of a turn
+
+A turn is four steps and nothing else.
+
+1. Run `rcf define questions --persona productOwner` (or
+   `rcf_define_questions` over MCP). The call returns the next question
+   set from the readiness object. Nothing is stored for the loop; the
+   tree, the four ledgers (`rcf/define/`) and the profile
+   (`rcf/.identity/profile.md`) are the state.
+2. Ask the first one to three questions in one group, in plain words,
+   with the passage from the document quoted exactly. Never show more
+   than one group at a time; never show ids, verbs or stage names
+   unless the owner asks.
+3. Run the write-back the question carries. Every question's
+   `writeBack[]` names one command per answer kind; pick the one that
+   matches the owner's reply and run it. The write-back is idempotent:
+   running it twice does not change the tree.
+4. Re-run `rcf define readiness --level intent` (or
+   `rcf_define_readiness`). On exit 0 the loop is finished and you
+   print the verdict (section below). On exit 4 the loop continues:
+   go back to step 1.
+
+The loop is monotone. Each answer removes its item or converts it into
+at most two further product-owner items (an openQuestion promoted to a
+decision asks `wellFormed` once if the harness under-fills it; a
+statement resolved to a new REQ asks `reqHasUs` once). No engineer
+edit can re-open the PO loop.
+
+## The register
+
+The first turn's first act is replacing the Register choice list in
+`rcf/.identity/profile.md` with `productOwner` when the person
+driving is the product owner. The profile is operator prose; you edit
+it directly (no verb owns it). The same holds for the Surface choice
+list.
+
+The PO register has three wording rules.
+
+- Plain sentences. No method terms. "What this is for" beats
+  "capability statement". "Who uses this" beats "AC-18602-4 user story
+  elicitation".
+- Quote the passage. When the question is about a brief statement,
+  quote the statement text in double quotes. The owner recognises their
+  own words. "Your document says 'Officers can put a loan on hold.'"
+  beats "statement 7".
+- One group at a time. The question object groups by source span so
+  the owner thinks about one passage before moving on. Never collapse
+  two groups into one prompt.
+
+## Starting a session
+
+A product-owner session starts with `rcf define questions --persona
+productOwner`. If the brief is empty, the only question the loop
+returns is `brief:sinceFreeze`: hand me your document, or tell me in a
+few sentences what this is for. Walk the folder with the intake prompt
+(`rcf_define_intake`) first when the owner has supplied one; otherwise
+take their sentences and feed them in through `rcf define ledger brief
+add --text "<text>"`.
+
+## Ending a session
+
+When `rcf define readiness --level intent` returns ok, print exactly
+these lines:
+
+```
+Intent-complete: yes.
+Your document has been turned into N requirements with M user stories.
+The engineer blockers remaining are K.
+```
+
+Then run `rcf define readiness --level intent --json` and save the
+output beside the source folder as `<folder>.intent-complete.json`
+(outside `rcf/`; readiness writes nothing itself). Commit the tree.
+The Readiness tab URL is the artefact a delivery stream attaches.
+
+## The engineer register
+
+The same compute runs with `--persona engineer`: the question set is
+the engineer blockers in failing stages, and its exit is
+`levels.readyToBuild.ok`. Per-check question templates and per-check
+write-backs for the engineer register are NOT part of DEFINE step 3
+PR 2 (spec §1.1: "The engineer register is the same mechanism with
+`--persona engineer`; it is not designed here beyond that flag and
+is what step 4 inherits."). Until step 4 lands, the engineer-persona
+questions return the shared compute shape with empty `writeBack` and
+`answerKinds`; the harness reads the raw blocker and runs the
+engineer verb that matches the check by hand.
+
+## What the loop does NOT do
+
+- No conversation state in rcf-lite. The tree, the ledgers and the
+  profile are the state (ADR-4129).
+- No separate findings list. Intake scan findings become
+  `openQuestion` statements and the loop reads one check
+  (`brief:openQuestions`) rather than two surfaces (ADR-4130).
+- No stale title-hit fallback. A statement whose `resolvedBy` is a
+  REQ id outside the closed grammar fails `skeleton:resolvedBy`; the
+  question returns the title hit as a suggestion rather than the
+  compute accepting it silently.