shapeup-sdlc 3.4.0 → 3.6.0

package/kernel/verify/trace.mjs

@@ -211,8 +211,16 @@ export function traceLint(slug, { cwd, gate = false }) {
   const findings = [];
 
   // 1. Covers-closure.
+  //
+  // THE WHOLE ARM IS GATED ON THE REGISTRY EXISTING — both halves of it, and the second half is the
+  // one that was missing. With no `requirements.md` there are no clauses, so `REQ-UNCOVERED` cannot
+  // fire; but `dangling` is derived from the BOARD, which needs no registry to carry a `covers:`
+  // clause, so a tree with no registry reported "covers-closure not applicable" in the same breath
+  // as a red finding for every `covers:` on the board. An arm that reports itself skipped and emits
+  // findings anyway is not skipped, and the report says the opposite of what the findings do.
   const reqPath = join(shared, "requirements.md");
-  const clauses = existsSync(reqPath) ? parseRequirements(readFileSync(reqPath, "utf8")) : [];
+  const closureChecked = existsSync(reqPath);
+  const clauses = closureChecked ? parseRequirements(readFileSync(reqPath, "utf8")) : [];
   const board = readBoard(cwd, slug);
   const covered = coveredReqIds(board);
   const knownIds = new Set(clauses.map((c) => c.id));
@@ -227,12 +235,13 @@ export function traceLint(slug, { cwd, gate = false }) {
     findings.push({ severity: "red", code: "REQ-UNCOVERED", req: id,
       message: `${id} (status: covered) is named by no AC's covers: — the clause "${(c?.clause || "").slice(0, 60)}" would silently vanish. Cover it with an AC, or mark it CUT (PO-approved).` });
   }
-  for (const id of dangling) {
-    findings.push({ severity: "red", code: "COVERS-DANGLING", req: id,
-      message: `an AC declares (covers: ${id}) but ${id} is not in requirements.md — a covers: link must resolve to a registered REQ.` });
+  if (closureChecked) {
+    for (const id of dangling) {
+      findings.push({ severity: "red", code: "COVERS-DANGLING", req: id,
+        message: `an AC declares (covers: ${id}) but ${id} is not in requirements.md — a covers: link must resolve to a registered REQ.` });
+    }
   }
 
-  const closureChecked = existsSync(reqPath);
   const coversClosure = {
     checked: closureChecked,
     requirements_total: clauses.length,
@@ -240,8 +249,8 @@ export function traceLint(slug, { cwd, gate = false }) {
     cut_status: cut.length,
     covered_by_ac: [...covered].filter((id) => knownIds.has(id)).length,
     uncovered,
-    dangling_covers: dangling,
-    pass: uncovered.length === 0 && dangling.length === 0,
+    dangling_covers: closureChecked ? dangling : [],
+    pass: uncovered.length === 0 && (!closureChecked || dangling.length === 0),
     skipped_reason: closureChecked ? null : "no requirements.md registry — covers-closure not applicable (non-regression on pre-spine specs).",
   };
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "shapeup-sdlc",
-  "version": "3.4.0",
+  "version": "3.6.0",
   "description": "Shape Up for coding agents \u2014 with gates the agent can't talk its way past. Harness for Claude Code.",
   "bin": {
     "shapeup-sdlc": "bin/init.mjs"

package/skills/ba-pitch-analyzer/SKILL.md

@@ -98,6 +98,21 @@ its phase; templates live in `assets/templates/`.
 (red). An invariant-backed regression task still anchors to its owning UC — there is no
 second path to green.
 
+**The requirement edge is written on the AC line, or it does not exist.** An acceptance
+criterion that grades a registry requirement ends with `(covers: REQ-…)` — the trailing clause,
+in the checkbox text, not a mention in prose. Measured on two runs of one pitch: every
+requirement had an acceptance criterion somewhere on the board and only half reached a criterion
+the judge grades, because a board AC reaches the judge through the refuted list alone — it can
+yield a FAIL and can never yield a PASS. An AC nothing cites by id produces no evidence for the
+requirement it was written for.
+
+**A requirement with no natural use-case home still becomes a task.** Contrast, localisation, a
+performance ceiling, a test surface — a non-functional clause has no actor+action and so no UC of
+its own, and the habit is to record it in the risk register, where nothing grades it. Give it a
+task whose AC reaches the committed spec (the invariant, the contract field or the Test Surface
+row that states it) and carries its `(covers: REQ-…)`. A line in the risk table is a note; a
+covered AC is a requirement the run can be measured against.
+
 ---
 
 ## The other three operations — same craft, different payload + whitelist
@@ -106,7 +121,7 @@ second path to green.
 |---|---|---|
 | `reconcile` | Verify `ledger.feature == payload.feature` (mismatch → STOP). Map each `[+]` Keep item → its owning UC; new task continues numbering (never renumber); `~`/Cut → synthesis "Hammered Out" row, no file. A Keep item asserting a new invariant → APPEND `[INV-NN]` + TS-INV row to that UC (append-only sections in your substrate). A new actor/action with no UC → `status: "escalated"` + a `deviations[]` spec-ambiguity entry: spawning a UC mid-cycle is silent re-shaping, the PO decides. Finish with board-derive (appetite overflow → report) + spec-lint | re-run phases 1–5; edit UC Steps; resolve the appetite HAMMER yourself |
 | `retrofit-surface` | Append `## Test Surface` (derived rows only, after Error Cases) to each UC of a pre-surface spec; an all-sources-empty UC gets the explicit empty-sources line | touch anything else — append-only substrate |
-| `coverage` | Extract **atomic** customer requirement clauses from `payload.requirements` (default: the pitch) and write the SHARED `shapeup/<slug>/requirements.md` registry: one `\| REQ-id \| clause (verbatim) \| source \| status \| note \|` row per clause. Split compound sentences into one testable clause each — a clause lost *inside* a bigger sentence is a requirement nothing can be traced to. **Assign REQ-ids ONCE and freeze them** (they behave like scope_id, never TASK-NNN — every `covers:` link rots otherwise): re-running, append new clauses with fresh ids, mark a removed clause `CUT (PO-approved)`, never renumber or delete. Status starts `covered` (a live requirement); only the PO sets `CUT`. The REQ source itself is frozen — the registry is a separate derived file | edit the REQ source; renumber existing REQ-ids; delete a dropped clause instead of marking it CUT; invent a requirement not in the source |
+| `coverage` | Extract **atomic** customer requirement clauses from `payload.requirements` (default: the pitch) and write the SHARED `shapeup/<slug>/requirements.md` registry: one `\| REQ-id \| clause (verbatim) \| source \| status \| note \|` row per clause. Split compound sentences into one testable clause each — a clause lost *inside* a bigger sentence is a requirement nothing can be traced to. **Assign REQ-ids ONCE and freeze them** (they behave like scope_id, never TASK-NNN — every `covers:` link rots otherwise): re-running, append new clauses with fresh ids, mark a removed clause `CUT (PO-approved)`, never renumber or delete. Status starts `covered` (a live requirement); only the PO sets `CUT`. The REQ source itself is frozen — the registry is a separate derived file. **Numbering.** A source clause already carrying an `R<n>` keeps its number — `R12` → `REQ-12` — and its `source` cell records where it came from verbatim (`shaping.md R12`), because that cell is the only thing that survives a re-run. A clause with no R-id takes the next free number ABOVE the highest `R<n>` in the source, so it can never collide with one added later. Splitting a compound clause keeps `REQ-12` for the first atomic part and records `shaping.md R12 (split 2/3)` for the rest — a requirement graded in parts is why splitting matters at all. On a re-run, match an existing id by its frozen `source` cell and clause text, **never** by re-deriving the number from the source's current order | edit the REQ source; renumber existing REQ-ids; delete a dropped clause instead of marking it CUT; invent a requirement not in the source; re-point an existing REQ-id because the source's R-numbers shifted |
 ---
 
 ## Anti-rationalization table

package/skills/coach/SKILL.md

@@ -93,7 +93,7 @@ never lands in any worker's KB.
 Orchestrated, this skill is dispatched like every worker: a **WorkOrder** in (`--order <path>`,
 operation `coach` or `scan`), a **WorkResult** out. Standalone, the raw feedback is passed
 directly; it maps onto the one payload field registered for this worker in the central domain
-registry (`skills/tech-lead/schemas/domain.schema.json`, `x-payload-by-worker`):
+registry (`kernel/schemas/domain.schema.json`, `x-payload-by-worker`):
 
 | Payload field | Standalone form | Meaning |
 |---|---|---|
@@ -117,7 +117,13 @@ fields nobody used" → "Prefer the minimum DTO that satisfies the AC; don't add
 fields"). Keep the originating why — a rule without its reason gets ignored or misapplied.
 
 ### Step 2 — ⏸ GATE COACH-1: Categorize (ASK, never assume)
-This is the load-bearing gate. **Do not infer which skill a rule belongs to** — a
+This is the load-bearing gate. **Resolve it first** — `node
+"${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" gate --resolve COACH-1 --slug <slug>
+[--file <path>|--preset <name>]` — so the ledger carries a row for the decision this gate makes,
+same as every other gate in the run. Exit 0 (`decision=skip`) — an unattended lane with no live PO;
+record nothing and stop here, the same outcome the CI preset's own note already documents. Exit 4
+(`ask`) — proceed with the categorization below, which IS the PO conversation this decision opens.
+**Do not infer which skill a rule belongs to** — a
 miscategorized rule lands in a file the wrong worker reads (or no worker reads). Present every
 candidate rule and ask the PO to assign each one. Emit this block, then stop and wait:
 

package/skills/hill-chart/SKILL.md

@@ -10,7 +10,7 @@ re-runs a computation that would erase true history.**
 
 You are not a worker: no WorkOrder, no WorkResult, invoked directly by the user (or by `/hill`)
 exactly like `shapeup` is. There is nothing to declare in
-`skills/tech-lead/schemas/domain.schema.json` and nothing to teach `harness compile` or
+`kernel/schemas/domain.schema.json` and nothing to teach `harness compile` or
 `harness reduce ingest` — those steps exist only for dispatched workers.
 
 ## What you read
@@ -71,9 +71,8 @@ Build one `{ scope_id, phase }` object per file.
 ## Rendering — the injection contract
 
 The engine ships at `assets/dashboard.template.html` — a complete, self-contained HTML page
-(inline CSS/JS, no external fetch beyond Google Fonts, no build step — the same convention as
-this repo's own `docs/visualize/*.html`). Do not rewrite it from a text description; read it,
-fill in real data, and write the result.
+(inline CSS/JS, no external fetch beyond Google Fonts, no build step). Do not rewrite it from a
+text description; read it, fill in real data, and write the result.
 
 1. For each discovered slug, build one entry:
 

package/skills/scope-architect/SKILL.md

@@ -41,6 +41,16 @@ the ship report's census table.
            scalars and [a, b] lists, a `## Affordances` table for affordance_manifest, and a
            short `## Why this slice` paragraph. A reviewer must be able to read the substrate
            in a PR; regeneration preserves prose under headings you do not own.
+           ► affordance_manifest lives in the TABLE and NOWHERE ELSE. Do not also write it in
+             the frontmatter: nothing reads it there, so the copy is discarded — and a run has
+             been lost to exactly that. The frontmatter copy said required_states: [idle], the
+             table cell said a bare idle, the table won, the value was a string where an array
+             was required, and four scopes were never dispatched — the board green, the contract
+             lint-clean, each leg reporting done with no error, every round, until EVAL refused
+             to grade a round whose scopes had never run. A contract declaring no affordances
+             writes `affordance_manifest: []` in frontmatter and no table.
+           ► A LIST INSIDE A TABLE CELL IS WRITTEN `[a, b]`, brackets and all — `[idle]`, never
+             `idle`. A bare word in that cell is a string, and required_states is an array.
              scope_id, topology_type                         — the stable join key is the scope
              use_cases[]                                     — the UC ids this scope implements.
                                                                THE ONLY LINK YOU WRITE TO THE
@@ -53,7 +63,12 @@ the ship report's census table.
                                                                the board's own use_case_refs
              covers[]                                        — optional REQ-ids from
                                                                requirements.md this scope answers
-                                                               for; stable, never renumbered
+                                                               for; stable, never renumbered.
+                                                               WRITE THE REGISTRY'S OWN KEY:
+                                                               `REQ-12`, not the pitch's `R12`.
+                                                               Both resolve — readers normalise —
+                                                               but one spelling in the committed
+                                                               contract is one thing to read
              depends_on[]                                    — scope_ids this scope builds AFTER.
                                                                This is the build ORDER — declare
                                                                it whenever one scope consumes

package/skills/scope-hammer/SKILL.md

@@ -72,6 +72,14 @@ H0.1  Unresolved scopes (breaker cases only):
 H0.2  QA findings (qa-edge-hunter's hunt-report.md, when present) — all `~` by default.
 H0.3  Discovered-task ledger entries still open (discovery/ledger.md, `[+]`/`~` unresolved).
 H0.4  Attempt-budget hammer proposals (scopes that exhausted their T0 attempts during BUILD).
+H0.4b Requirements with no PASS evidence — the pitch clauses the run never showed working. Run
+        node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" probe requirements --slug <slug> --format table
+      and take its `no evidence` rows; cite the row, the same way H0.0 cites ownership. Each is a
+      census item carrying its source clause (`REQ-12 ← shaping.md R12`). A `cut` row is an answer
+      the PO already gave — not an item. An inconsistency row (a criterion anchored to a
+      requirement no acceptance criterion covers) is reported to the PO as a reconciliation, never
+      counted as evidence and never promoted as a finding. No registry on disk → this input is
+      empty and the census is unchanged (absent artifact ⇒ arm skipped).
 H0.5  Classify every item: MUST-HAVE (the pitch's core problem is unsolved without it) vs
       NICE-TO-HAVE (`~`, improves but doesn't block the core promise). Default to NICE-TO-HAVE
       unless the item traces directly to a pitch boundary or a scope's business_goal — a
@@ -81,7 +89,8 @@ H0.5  Classify every item: MUST-HAVE (the pitch's core problem is unsolved witho
 **GATE H0 Output:**
 ```
 ⏸ GATE H0 — Census
-Must-have (unresolved)  : [N] — [list, each with source: scope | QA | discovered | advisor-overflow]
+Must-have (unresolved)  : [N] — [list, each with source: scope | QA | discovered | requirement |
+                                 advisor-overflow]
 Nice-to-have (~)        : [M]
 Carry candidates        : [scopes still uphill/downhill, or exhausted attempt budget]
 ```
@@ -141,7 +150,7 @@ the harness (this is neither the generator nor the evaluator).
 Orchestrated, this skill is dispatched like every worker: a **WorkOrder** in (`--order <path>`,
 operation `hammer`), a **WorkResult** out. The standalone flags below map 1:1 onto the payload
 fields registered for this worker in the central domain registry
-(`skills/tech-lead/schemas/domain.schema.json`, `x-payload-by-worker`):
+(`kernel/schemas/domain.schema.json`, `x-payload-by-worker`):
 
 | Payload field | Standalone flag | Meaning |
 |---|---|---|

package/skills/spec-evaluator/SKILL.md

@@ -152,13 +152,23 @@ round. Write it so someone without your context can answer it in one reply.
     "t0_citations": [ { "scope_id": "cart", "path": "…/t0/verdicts/r2-a3.json", "sha256": "…" } ],
     "criteria": [ { "criterion": "UC-01 step 3", "dimension": "spec-conformance",
                     "verdict": "FAIL", "confidence": "high", "reprobed": true,
-                    "evidence": "Pay click throws — apps/web/checkout/Pay.tsx:84" } ],
+                    "evidence": "Pay click throws — apps/web/checkout/Pay.tsx:84",
+                    "traces_to": ["REQ-4"] } ],
     "refuted": [ { "task_id": "TASK-007", "ac": "<the checkbox text your evidence disproves>" } ],
     "bugs": [ /* report-schema bug entries */ ]
   }
 }
 ```
 
+**`traces_to` is copied, not invented.** Fill it from the `(covers: REQ-…)` clause of the
+acceptance criteria your criterion grades: the AC already carries the link, written when the plan
+was reviewed, and you record which requirement your criterion maps back to. An AC with no `covers:`
+clause yields no anchor — leave the array empty rather than guessing, and never read the pitch to
+supply one. This changes nothing you grade: the anchor is a navigation path, never a grading input,
+and a criterion passes or fails on its evidence exactly as before. It matters downstream because
+the requirement matrix at GATE L4 and the census at GATE H are projected from these anchors; a
+verdict that drops them grades the build and says nothing about what the pitch asked for.
+
 **Every FAIL criterion's `evidence` MUST carry a `file:line` locator** — schema-enforced, not
 advice: the envelope is validated against `work-result.schema.json` at ingest and a locatorless
 FAIL is rejected before any write. A PASS may cite plain output. (Observed, not theorized: a
@@ -175,6 +185,7 @@ separation is the whole point of the architecture.
 ## Verification checklist
 
 - [ ] Every criterion traces to committed spec text (UC/domain-model/contract/Done-when/Non-Go)
+- [ ] `traces_to` copied from the graded ACs' `covers:` clauses — empty where they carry none
 - [ ] Every PASS cites a confirming probe; every FAIL cites evidence or "NO EVIDENCE"
 - [ ] Every FAIL was re-probed once; confidence assigned per the ledger rule
 - [ ] Scoped spec → T0 citations present with recomputed sha256 (else the run returned `failed`)

package/skills/tech-lead/SKILL.md

@@ -60,15 +60,15 @@ check the lane:
   legacy loop instead — `references/protocol.md` (BUILD(r)/EVAL) + `references/protocol.md`
   carry the full step-by-step for both the tiny lane and a scope-less BUILD loop, verbatim, non-
   regression. Stop reading this file here for that run.
-- **Otherwise** (the common case — a scoped spec, any auto level): build `RunArgs`
-  (`domain.schema.json` `$defs/RunArgs` — `{slug, runId, autoLevel, answers, lane,
-  models:{exec,eval,qa}, budgets:{maxRounds,attemptBudget,wallClockS}, pluginRoot, startedAt}`,
-  plus every switch the operator typed — `references/gates.md` GATE L0.9 has the flag→field table,
-  and a flag that stops here is a flag that was accepted and ignored). **Write that exact object to
-  `.shapeup/<slug>/run-args.json` before launching**, fresh on every launch and relaunch: the flags
-  reach the workflow as a value in memory, so it is the run's only evidence of what it was launched
-  with, and a run that cannot state its own configuration cannot have a claim about it checked.
-  Then launch with the **`Workflow` tool** — naming `init run`'s staged copy, never the install path:
+- **Otherwise** (the common case — a scoped spec, any auto level): resolve every switch the
+  operator typed (`references/gates.md` GATE L0.9b has the flag→field table) and run the kernel's
+  sole `RunArgs` writer: `node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" init run-args --slug
+  <slug> --auto-level <level> --exec-model <n> [--eval-model <n>] [--qa-model <n>] --max-rounds <N>
+  --attempts <N> --plugin-root "${CLAUDE_PLUGIN_ROOT}" [--answers <a>] [--lane <l>] [--no-eval]
+  [--no-qa] [--adversarial-verify] [--parallel-scopes <N>]`. It writes `.shapeup/<slug>/run-args.json`
+  fresh on every launch/relaunch and prints that identical object — **pass it to `Workflow`
+  verbatim, never re-type it**. Then launch with the **`Workflow` tool** — naming `init run`'s
+  staged copy, never the install path:
 
 ```
 Workflow({
@@ -114,7 +114,7 @@ did not actually receive from the PO — an unattended lane with no answer for a
 
 FIRST freeze the evidence — run state is gitignored, so `shapeup/<slug>/REPORT.md` (already
 written by `shapeup-run.js` via `harness reduce ship`, or write it now on a `gate_h` close) is all a
-teammate sees. Then emit:
+teammate sees. Then RESOLVE the gate — `references/gates.md` GATE L4 has the call — and emit:
 
 ```
 ⏸ GATE L4 — Ship Sign-Off

package/skills/tech-lead/references/gates.md

@@ -113,11 +113,13 @@ Collect (explicit — never inferred):
         gate to be its first execution.
 ```
 
-**L0.9b — the launch record.** Every switch the operator typed becomes a `RunArgs` field, or it
-does nothing at all: the workflow cannot read a config file and cannot ask a follow-up, so a flag
-that stops at the skill boundary was accepted and ignored. That is not hypothetical — `--no-qa` was
-documented in seven places across the shipped set and inert in all of them, because no line of this
-protocol ever put `noQa` into the record.
+**L0.9b — the launch record.** Every switch the operator typed to *this launch* becomes a `RunArgs`
+field, or it does nothing at all: the workflow cannot read a config file and cannot ask a follow-up,
+so a flag that stops at the skill boundary was accepted and ignored. That is not hypothetical —
+`--no-qa` was documented in seven places across the shipped set and inert in all of them, because no
+line of this protocol ever put `noQa` into the record. `--wall-clock-budget` is the one flag below
+that is not a `RunArgs` field at all — it is consumed earlier, at `init run` itself, and never
+needed to reach this launch; see its row for where it actually lands.
 
 | Flag | `RunArgs` field |
 |---|---|
@@ -125,14 +127,19 @@ protocol ever put `noQa` into the record.
 | `--no-qa` | `noQa: true` |
 | `--parallel-scopes N` | `maxParallelScopes: N` — how many scopes build at once (default 4; `1` = sequential) |
 | `--adversarial-verify` | `adversarialVerify: true` |
-| `--rounds N` / `--attempts N` / `--wall-clock-budget S` | `budgets.{maxRounds,attemptBudget,wallClockS}` |
+| `--rounds N` / `--attempts N` | `budgets.{maxRounds,attemptBudget}` |
 | `--gate-answers <set>` | `answers` |
+| `--wall-clock-budget S` | *(not a `RunArgs` field)* — typed once, on the `harness init run` command line itself, not on this launch; it lands straight in the run receipt as `wall_clock_budget_s`, and the deadline breaker reads that receipt field directly — consumed by `kernel/verify/budget.mjs` as `wall_clock_budget_s`. `budgets` declares only `maxRounds`/`attemptBudget` — the schema, `SKILL.md`'s own RunArgs contract line and this script's own header comment all agree there is no third member |
 | `--orch-model/--exec-model/--eval-model/--qa-model` | `models.{…}` (L0.8) |
 
-The assembled object is written to `.shapeup/<slug>/run-args.json` before the launch, fresh on every
-launch and relaunch. It is the only artifact that records what a run was configured with; the ship
-report, a resumed session and any later measurement all read it, and none of them can recover a
-value that only ever existed as an argument.
+`harness init run-args` (invoked at Step 2 of `SKILL.md`) is the sole writer of the assembled
+object: it takes the resolved values above, writes `.shapeup/<slug>/run-args.json` fresh on every
+launch and relaunch, and prints the same object back so the launch never re-assembles it by hand. It
+is the only artifact that records what a run was configured with; the ship report, a resumed session
+and any later measurement all read it, and none of them can recover a value that only ever existed
+as an argument. Step 2 is not merely advisory: `shapeup-run.js`'s own Preflight refuses to dispatch
+ORIENT (or anything past it) when this file is missing at the run's local root — a launch that
+skipped this step aborts there rather than proceeding on a silent default.
 
 **L0.0 — intake precondition (before any other L0 collection):**
 ```
@@ -161,7 +168,14 @@ Model matrix : orch=[model] exec=[model] eval=[model] qa=[model] digester=[scrip
 Budgets      : round_budget=[N] (outer)   attempt_budget=[N] (inner, per scope)
 Knowledge    : [tech-lead.md — N workflow rules, M suggested values (confirmed above) | none — `/retro --scan` or `/retro --research <stack>` seeds it (optional)]
 ```
-Do NOT start ORIENT until confirmed (interactive/auto). Under --unattended, proceed.
+**Resolve it** — this gate is this skill's own (the workflow never sees it), so it is this skill
+that runs the same tool every other gate resolves through, not a paragraph read as a stand-in for
+one: `node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" gate --resolve L0 --slug <slug>
+[--file <path>|--preset <name>]`. Exit 4 (`ask`) is the confirmation this block already asks for —
+put it to the PO and wait, same as the paragraph above always meant. Exit 0 (`decision=proceed`) —
+continue straight to ORIENT, which is what `--unattended`'s pre-answered set resolves to. Exit 5
+(`abort`) — stop; do not launch. Either way, the gate's own ledger row is what lets a later reader
+see the decision that opened the run, not only the decisions that closed it.
 
 ---
 
@@ -297,6 +311,12 @@ Scope contracts present:
     - scope-summary "Done when" headline statements
     - the Deferred Places from ux-behavior.md (breadboard Places this shape will not build) —
       each one needs the PO's yes; a rejected deferral goes back to the planner as a screen
+    - the REQ → AC table from requirements.md, one row per registered requirement: REQ-id, the
+      source clause it came from (`REQ-12 ← shaping.md R12`), and the acceptance criterion that
+      grades it — or the scope that claims it, or CUT (PO-approved). Omitted entirely when the run
+      has no registry. A requirement with none of the three is already a red below; this table is
+      what the PO reads to answer it — cover it, or cut it on the record. Printed, never asked:
+      the table decides nothing at this gate
 No scope contracts (pre-v0.3.0, unchanged from v0.2.6):
   Read tasks/_index.md (LOCAL root). Print:
     - task count by package/variant (.shared / .be / .web / .mobile / .e2e)
@@ -312,7 +332,15 @@ this is the orchestrator's own re-confirmation before committing to a build sequ
     waiting to happen), PA1 (directory-aligned scope), PA2 (size cap), SCOPE-ANCHOR (a scope
     naming no committed use case, or one that does not resolve), TIER-DIRECTION (a committed
     contract naming LOCAL task ids), SCOPE-DEPS (a build-order id naming a scope that is not
-    in this run), BREADBOARD-PLACE (a breadboard Place with UI affordances has no
+    in this run), REQ-UNCOVERED (a requirement in requirements.md that no acceptance criterion
+    grades and no scope claims — the PO's two ways out are an AC carrying `(covers: REQ-…)` or
+    `CUT (PO-approved)` in the registry; silent on a run with no registry),
+    CONTRACT-SCHEMA (a scope contract that parses but not into the shape a WorkOrder carries —
+    most often a list written bare in a table cell where the dialect wants `[a, b]`; without
+    this the compiler refuses the order later and the scope is never dispatched at all, with
+    the board green and the leg reporting done), CONTRACT-UNREADABLE (a table the parser could
+    not see, or a table field also declared in frontmatter where nothing reads it),
+    BREADBOARD-PLACE (a breadboard Place with UI affordances has no
     `## Screen: … (P#)` in ux-behavior.md and is not deferred), BREADBOARD-UI (a U# not
     specified on a screen of its own Place). Any red → HARD STOP, past a 🔴 at the
     architect's own checkpoint. The breadboard reds are the planner's to fix — add the screen
@@ -513,12 +541,42 @@ Feature   : [slug] — [SHIPPED (deployed) | BUILT & VERIFIED — deploy pending
 Rounds    : [r] (build+eval cycles)
 Verdict   : PASS (dims: [spec-conformance]; not evaluated: [security, performance])
 QA        : [hunt done — N findings, M promoted+fixed, rest ~ | skipped (--no-qa) | n/a (pre-QA spec)]
+Requirements: [15/17 PASS · 1 CUT (PO) · 1 no evidence (REQ-12 ← R12) | n/a (no registry)]
 Ledger    : harness-run.md
 ```
+The Requirements line is TRANSCRIBED, never composed — run
+`node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" probe requirements --slug <slug> --format table`
+and copy its `Requirements:` summary. It joins each registered clause to the acceptance criterion
+that covers it and to the criterion the judge graded, over the run named in its own output. It
+decides nothing here: a requirement with no PASS evidence is a fact GATE H's census and the
+baseline comparison weigh, not a ship blocker.
 Question (max 1): "Anything to record before I close the run? (y/n) or provide feedback for the next sprint."
 On confirm:
 - If the PO provides substantive feedback (not just 'y' or empty) → automatically delegate via Agent (model: exec — see references/protocol.md "Invocation mechanism"): Skill(shapeup-sdlc-plugin:coach) with the provided feedback for RLHF. The coach runs its own GATE COACH-1 to have the PO categorize each rule, then files it under the responsible skill in `shapeup/knowledge-base/<skill>.md` (committed → team-shared). Coachable: `task-executor`, `ba-pitch-analyzer`, `qa-edge-hunter`, `orient`, `scope-architect`, `solution-architect` (each reads its own file at the top of its next run) and `tech-lead` (workflow guidance, read at the next GATE L0). Guidance never decides a gate: a filed rule may add a question or a check to a gate block, never an answer. The tech lead does not categorize the feedback itself — that is the coach's gate, by design (no assumptions).
 - Then output → `✅ [slug] [shipped & deployed | built & verified, deploy pending] — [r] rounds, verdict PASS.`
 
+**Resolve the gate itself before any of the above** — this is the decision that shipped the run,
+and without it the trace holds no record of that decision at all: `node
+"${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" gate --resolve L4 --slug <slug>
+[--file <path>|--preset <name>]`. Exit 0 (`decision=ship|hold`) — render the block above and close
+the run: `node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" probe resume --slug <slug> --close shipped
+--cause "verdict=<verdict> rounds=<r> decision=<ship|hold>"`. Always issue this call — a `gate_h`
+close is the ordinary case where `shapeup-run.js` handed off without closing the run, and the
+GATE H → L4 path (scope-hammer's census, then this gate) is the one this instruction exists for.
+The close itself is a once-only fact IN THE KERNEL (`closeRun`'s own guard reads a `closed_status:`
+line that only `closeRun` ever writes — never the mutable `status:` line every phase rewrites, this
+call included), not a conditional this instruction has to get right: if this run_id was NOT already
+closed, this call performs the close, fresh. If it was already closed `shipped` (or `aborted`) and
+the cause text is byte-identical to what is already on the ledger, this call is a true idempotent
+no-op. If it was already closed with the SAME status but a genuinely different cause — a run closed
+more than once across relaunches, the ordinary shape a `gate_h` hand-off after an earlier abort takes
+— this call SUPERSEDES it: the new cause is written, the prior one is folded into the same
+`close_cause` line rather than lost, and the kernel call itself still exits 0 (only the RunReturn a
+launch's own `withWarnings` wraps carries the resulting `state_warning` — a prose-driven close like
+this one has no RunReturn to attach it to, so read `close_cause` by hand if this branch matters to
+you). If it was already closed with a DIFFERENT status altogether, this call is refused outright —
+cause intact, never silently flipped. Exit 4 (`ask`) — the block above IS that stop; put it to the
+PO and wait, same as always. L4's answer set carries no `abort`.
+
 ---
 

package/skills/tech-lead/references/protocol.md

@@ -630,7 +630,7 @@ trace. See `references/gates.md` — GATE L0.1.
 ## Central domain registry
 
 Every record type and payload field that crosses a skill boundary is defined exactly once in
-`skills/tech-lead/schemas/domain.schema.json` — the envelope schemas (`work-order.schema.json`,
+`kernel/schemas/domain.schema.json` — the envelope schemas (`work-order.schema.json`,
 `work-result.schema.json`) only `$ref` it. The registry annotates each entity's tier
 (SHARED/LOCAL), location, sole writer, and readers, carries the machine-readable ERD (`x-erd`),
 and maps which payload fields each worker may rely on (`x-payload-by-worker`).
@@ -686,13 +686,15 @@ lens: lite | standard | cross-context
 eval_dimensions: [spec-conformance]   # the set from GATE L0.5 (init-run --dimensions); every EVAL order is compiled from THIS line
 max_rounds: 3
 auto_level: interactive | auto | unattended
-status: orienting | mapping | building | evaluating | shipped | escalated
+status: orienting | mapping | building | evaluating | shipped | escalated | aborted
 final_verdict: ~ | pass | fail | not-evaluated
 rounds_used: [N]
 discovered_rounds: [N]
 deploy: ~ | deployed | pending-po
 started_at: [ISO]
 closed_at: ~ | [ISO]
+close_cause: ~ | [why the run ended at that terminal status — `probe resume --close` writes this and closed_at together]
+closed_status: ~ | [the terminal status actually closed — written ONLY by `probe resume --close`, never by `--set-status`, so it is immune to `status:` above being rewritten by ordinary phase traffic after the close]
 ---
 ```