shapeup-sdlc 3.18.2 → 4.0.0

package/bin/init.mjs

@@ -26,9 +26,9 @@ import { fileURLToPath } from "node:url";
 import { spawnSync } from "node:child_process";
 import { createInterface } from "node:readline";
 import { LOCAL, LEGACY, metricsDir } from "../kernel/lib/paths.mjs";
-import { mergePipelinePermissions as mergeGrant, isWorkspaceTrusted, WORKFLOW_RULE } from "./lib/grant.mjs";
+import { mergePipelinePermissions as mergeGrant, isWorkspaceTrusted } from "./lib/grant.mjs";
 
-/** The root a project migrating off the pre-ADR-0001 layout may still be carrying. */
+/** The root a project migrating off the earlier layout may still be carrying. */
 const LEGACY_LOCAL = LEGACY.local;
 
 const PKG_ROOT = resolve(dirname(fileURLToPath(import.meta.url)), "..");
@@ -43,24 +43,21 @@ Options:
   -d, --directory <path>   Target project directory (default: current directory)
   -o, --override           Overwrite existing files in target
   -y, --yes                Run unattended (answer yes to all prompts)
-      --no-native-workflow Do not grant the unscoped "Workflow" permission (see below)
+      --no-native-workflow Accepted and ignored (kept so existing scripts that pass it still run)
   -h, --help               Print this help
 
-The grant this writes is two Bash rules for the harness kernel, plus — unless
---no-native-workflow is given — the "Workflow" token that lets the tech-lead
-launch its run script without approving each launch. That token is UNSCOPED: it
-authorises every dynamic workflow script in the project, not only this plugin's.
-Declining it leaves the harness fully functional in an interactive session; only
-the unattended lane needs the pre-approval.`;
+The grant this writes is two Bash rules for the harness kernel, and nothing else.
+The plugin no longer asks for the unscoped "Workflow" permission and no longer
+needs it; a "Workflow" token already in your settings is yours and is left alone.`;
 
-let targetDir = ".", yes = false, override = false, nativeWorkflow = true;
+let targetDir = ".", yes = false, override = false;
 const positional = [];
 for (let i = 0; i < argv.length; i++) {
   const a = argv[i];
   if (a === "-d" || a === "--directory") targetDir = argv[++i];
   else if (a === "-y" || a === "--yes") yes = true;
   else if (a === "-o" || a === "--override") override = true;
-  else if (a === "--no-native-workflow") nativeWorkflow = false;
+  else if (a === "--no-native-workflow") { /* accepted, ignored: the installer never writes the token */ }
   else if (a === "-h" || a === "--help") { console.log(usage); process.exit(0); }
   else if (a.startsWith("-")) { console.error(`Unknown option: ${a}\n${usage}`); process.exit(1); }
   else positional.push(a);
@@ -125,7 +122,7 @@ warnIfUntrusted(target);
 ensureAgentImport(join(target, "CLAUDE.md"), "CLAUDE.md");
 
 // ---- 3. .gitignore ----------------------------------------------------------
-// Both roots are listed, deliberately. A project may still be carrying the pre-ADR-0001 local root
+// Both roots are listed, deliberately. A project may still be carrying the earlier local root
 // alongside the current one, and a run trace committed by accident from either is exactly the
 // mistake the tier split exists to prevent. Ignoring a directory that does not exist costs nothing.
 const GITIGNORE_RULE = `# Shape Up SDLC run workspace
@@ -274,10 +271,10 @@ function installClaude() {
  * @returns {void}
  */
 function mergePipelinePermissions(settings) {
-  mergeGrant(settings, { nativeWorkflow });
-  if (!nativeWorkflow) {
-    console.log(`  [claude] --no-native-workflow: "${WORKFLOW_RULE}" not granted — launch the run`);
-    console.log("           script interactively and approve it, or re-run init without the flag.");
+  mergeGrant(settings);
+  if ((settings.permissions?.allow || []).includes("Workflow")) {
+    console.log('  [claude] your settings carry a "Workflow" permission. This plugin no longer needs it and');
+    console.log("           leaves it alone — remove it yourself if nothing else in the project uses it.");
   }
 }
 

package/bin/lib/grant.mjs

@@ -48,10 +48,10 @@
 // verify by eye. Scope is unchanged in kind and narrower in fact: one dependency-free, network-free
 // script that ships with the plugin. It grants no general `Bash(node:*)`.
 //
-// THE WORKFLOW GRANT is separate and optional (see {@link workflowRule}). The `Workflow` permission
-// token is UNSCOPED — it authorises every dynamic workflow script in the project, not just this
-// plugin's — so the installer states that plainly and lets `--no-native-workflow` decline it. A
-// project that declines runs the harness interactively, approving the launch each time.
+// NO `Workflow` TOKEN. The run is driven by the loop in the session, not launched as a script, so
+// nothing here needs the unscoped `Workflow` permission and the installer does not add it. It does not
+// remove it either: a project may rely on that token for workflow scripts of its own, so a token already
+// in a user's settings is the user's, and the merge below leaves it exactly where it is.
 
 import { existsSync, readFileSync } from "node:fs";
 import { join, resolve } from "node:path";
@@ -60,14 +60,6 @@ import { homedir } from "node:os";
 /** The kernel's path inside the installed plugin — the one executable the grant has to cover. */
 export const KERNEL_ENTRY = "kernel/harness.mjs";
 
-/**
- * The unscoped permission token that lets the tech-lead launch its Workflow script.
- *
- * Opt-in at install. Named here rather than spelled at each call site so the installer, the docs
- * check and the structural suite all mean the same string.
- */
-export const WORKFLOW_RULE = "Workflow";
-
 /**
  * The `permissions.allow` rules for the harness kernel.
  *
@@ -127,19 +119,16 @@ export function isWorkspaceTrusted(projectDir) {
 /**
  * Merge the harness grant into a parsed settings object, in place.
  *
+ * Adds the two kernel rules and drops only the rules this plugin itself once wrote and superseded;
+ * every other entry — a user's own rule, a `Workflow` token — is left alone.
+ *
  * @param {object} settings - Parsed settings.json.
- * @param {object} [opts] - Options.
- * @param {boolean} [opts.nativeWorkflow=true] - Also grant the unscoped `Workflow` token, which is
- *   what lets the tech-lead launch its run script without a per-launch approval. `false` removes it
- *   if a previous install added it, so `--no-native-workflow` is a real opt-out and not a no-op.
  * @returns {void}
  */
-export function mergePipelinePermissions(settings, { nativeWorkflow = true } = {}) {
+export function mergePipelinePermissions(settings) {
   settings.permissions = settings.permissions || {};
   const allow = new Set(settings.permissions.allow || []);
   for (const r of [...allow]) if (isSupersededRule(r)) allow.delete(r);
   for (const r of pipelineRules()) allow.add(r);
-  if (nativeWorkflow) allow.add(WORKFLOW_RULE);
-  else allow.delete(WORKFLOW_RULE);
   settings.permissions.allow = [...allow].sort();
 }

package/commands/build.md

@@ -4,8 +4,8 @@ description: Implement a task's acceptance criteria exactly (minimum code, surgi
 Use the **task-executor** skill on $ARGUMENTS.
 
 Standalone build: implements one task (`TASK-NNN`) from a spec folder — assumption scan first,
-minimum code, surgical diffs, verified observable outcomes. Inside an orchestrated run the
-tech-lead dispatches this skill through the envelope port instead; this command is for picking
+minimum code, surgical diffs, verified observable outcomes. Inside a run the `building` loop
+dispatches this skill through the envelope port instead; this command is for picking
 up a single task directly.
 
 If no task ID was given, read the board (`.shapeup/<slug>/tasks/_index.md`) and take the
@@ -16,19 +16,14 @@ the harness working, not an error to route around.
 ## Building a whole scoped feature is not this command
 
 This command builds **one task**. A full BUILD round — every scope, the per-scope attempt loop,
-T0 verification, the inner circuit breaker, then the single EVAL — is a workflow-script launch, and
-it belongs to the orchestrator:
+T0 verification, the inner circuit breaker, then the single EVAL — belongs to the loop:
 
 ```
-Workflow({
-  scriptPath: ".shapeup/workflows/shapeup-run.js",
-  args: <the RunArgs object>
-})
+/ship <pitch>
 ```
 
-Reach it through `/ship` (or the `tech-lead` skill), which opens the run properly — `harness init run`
-first, so the receipt exists. Do not hand-roll the round by calling this command once per task: the
-attempt loop, the T0 ratchet and the breakers are branches in that script, not steps a caller can
-be trusted to reproduce, and a session that rebuilds them by hand is the prose lane the cutover
-replaced. On a `--tiny` run or a spec with no committed `scopes/*.md`, the prose loop in
-`skills/tech-lead/references/protocol.md` still applies, unchanged and by design.
+`/ship` opens the run properly — `harness init run` first, so the receipt and the launch record
+exist — and then follows the loop's phase table over the run's files. Do not hand-roll the
+round by calling this command once per task: the attempt loop, the T0 ratchet and the breakers are
+the loop's discipline, not steps a caller can be trusted to reproduce, and a session that
+rebuilds them by hand is the prose lane the loop replaced.

package/commands/eval.md

@@ -9,8 +9,8 @@ The single judge. Two modes, chosen by the arguments:
 - `--spec <folder> --feature <slug> --single-pass` — the once-per-round verdict on the whole
   board.
 
-Round mode is watched: a PreToolUse hook (GATE L2) **warns** while any task on the board is
-unfinished, naming the offenders — advisory since ADR-0001, so the call proceeds, but a verdict
-taken now grades a partial board and the warning is recorded. The correct response is to route
+Round mode crosses the Round Close gate first: while any task on the board is unfinished the gate block
+carries the unfinished scopes — advisory, so the call proceeds, but a verdict
+taken now grades a partial board and the crossing is recorded as a `warn`. The correct response is to route
 back to `/build` and finish them — do not shrug the warning off, and do not use `--task` as a
 loophole to simulate a round verdict piecemeal.

package/commands/hammer.md

@@ -1,12 +1,16 @@
 ---
-description: GATE H — must-have census, baseline comparison, cut list + ship verdict
+description: The Cut-List Review gate — must-have census, baseline comparison, cut list + ship verdict
 ---
-Use the **scope-hammer** skill on $ARGUMENTS.
+Use the **building** skill's `stop` sub-command on $ARGUMENTS.
 
 The stop decision. Censuses the open items (QA findings, discovered-ledger rows, attempt-budget
-hammer proposals), compares the product to the **pitch's baseline — what customers live with
-today, never the ideal** — and returns a cut list plus a ship verdict for the TL/PO to confirm.
+proposals), compares the product to the **pitch's baseline — what customers live with today, never
+the ideal** — and returns a cut list plus a ship verdict for the TL/PO to confirm. You do it in this
+session, and every ownership, exhaustion and requirement claim cites the file it came from — the scope
+contracts, the dispatch receipts and trials, the verdict and `requirements.md`.
 
 Handles all three arrival paths: the normal stop (all scopes finished), an exhausted round
 budget, and an exhausted per-scope attempt budget. The verdict is a proposal — promotion of cut
-items is the human's call at the gate, not the skill's.
+items is the human's call at the gate, not the census's — and it is written as data to
+`reports/hammer-census.json` under the run's local root, which the Ship Sign-off gate reads before any answer set
+may say `ship`.

package/commands/retro.md

@@ -1,29 +1,30 @@
 ---
-description: File ship-gate feedback into the team-shared, per-skill knowledge base
+description: File ship-gate feedback into the team-shared, per-reader knowledge base
 ---
-Use the **coach** skill on $ARGUMENTS.
+Use the **building** skill's `retro` sub-command on $ARGUMENTS.
 
-Turns raw PO/TL feedback (usually from the L4 Ship gate) into per-skill guideline files under
-committed `shapeup/knowledge-base/<skill>.md`, which the coachable skills read back at
-the top of their next run, and which the tech lead reads at GATE L0 for workflow guidance.
+Turns raw PO/TL feedback (usually from the Ship Sign-off gate) into per-reader guideline files under
+committed `shapeup/knowledge-base/<reader>.md` — readers are `task-executor`, `orient`,
+`qa-edge-hunter`, the `plan` activity and the loop itself (`building`, read at the Intake & Config gate, where it may
+also suggest Intake & Config values the loop confirms before pinning).
 
-`/retro --scan` runs the coach's **scan** operation instead: it reads the project on disk (build
+`/retro --scan` runs the retro's **scan** instead: it reads the project on disk (build
 and toolchain files, CI config, CLAUDE.md, README) and drafts the same kind of guidelines from
 it, before the first feature or after the toolchain changes. Optional, and never on the scan's
-own authority — every drafted rule goes through GATE COACH-1 like feedback.
+own authority — every drafted rule goes through the Retro Ownership gate like feedback.
 
-`/retro --research <stack>` runs the **research** operation: for a project with nothing on disk
+`/retro --research <stack>` runs the **research**: for a project with nothing on disk
 yet, it drafts the same kind of guidelines from the platform's official documentation only —
 build, launch, test, package manager, lint, in that order of leverage — each rule cited with url,
 version and fetch date; on a project that has been scanned, it cross-checks every scan rule
 against the documentation and reports each as confirmed, contradicted or unknown. The stack is
 required and never guessed. Research is a source, not a verification: nothing it reads runs, and
-the tech lead still pins every suggested command at GATE L0 before the kernel executes it. A
+the loop still pins every suggested command at the Intake & Config gate before the kernel executes it. A
 later `--scan`, once the first feature has created a toolchain, retires the research rules it
 confirms with disk evidence.
 
-Two rules the skill enforces and this command must not soften: GATE COACH-1 **asks** the PO
-which skill owns each rule — it never assumes; and feedback whose root cause is the mechanism
+Two rules the retro enforces and this command must not soften: the Retro Ownership gate **asks** the PO
+which reader owns each rule — it never assumes; and feedback whose root cause is the mechanism
 itself (a gate, hook, or contract defect) is categorized `harness-defect` and filed to the
 defect register as a raw idea for the Betting Table, never as worker steering. A third holds
 for every category: guidance never decides a gate — a rule may add a question or a check to a

package/commands/scopes.md

@@ -1,15 +1,4 @@
 ---
 description: Decompose the pitch into a spec tree + board, then map the scope contracts
 ---
-This is step 8 (Map Scopes), which is two skills in sequence:
-
-1. Use the **ba-pitch-analyzer** skill on $ARGUMENTS — pitch → linked DDD spec tree (domain
-   model → use cases → tasks) with BDD scenarios and the derived Test Surface. Pass through an
-   operation when the user names one: `analyze` (the default — spec tree + board), `reconcile`
-   (fold discovered-ledger items back into the board and UC invariants), `retrofit-surface`
-   (append a Test Surface to a spec written before there was one), or `coverage` (extract the
-   shared `requirements.md` registry that anchors covers-closure).
-2. Then use the **scope-architect** skill (`map-scopes`) to write the committed scope contracts
-   (`scopes/*.md`) — import-graph slicing by flow, write-whitelist substrates, fixtures.
-
-If the user asked for only one half ("just analyze", "just the contracts"), run only that half.
+Alias of `/ship plan`: use the **building** skill's plan activity on $ARGUMENTS and stop once the scope contracts are on disk and the Board Review gate is crossed — run the planning substeps the phase table hands out.

package/commands/ship.md

@@ -1,106 +1,63 @@
 ---
 description: Run the full Shape Up harness on a pitch, with human sign-off at gates
 ---
-Use the **tech-lead** skill to run the full harness on $ARGUMENTS.
+Use the **building** skill to run the full harness on $ARGUMENTS.
 
-Default to **interactive** (`auto_level = interactive`): pause at every ⏸ gate and require PO
-sign-off — especially the Ship gate (L4). The harness's safety depends on the human being in the
+Default to **interactive** (`auto_level = interactive`): pause at every gate and require PO
+sign-off — especially the Ship Sign-off gate. The harness's safety depends on the human being in the
 loop; do not skip gates by default.
 
-**Before anything else, dispatch `tech-lead` and let it open the run** — its first action is
-`harness init run`, which writes the run receipt. Do not summarise what the harness will do;
-a session that dispatches the orchestrator and leaves no receipt is blocked at `Stop` by
-`hooks/gate-zerowork.mjs`.
+**Before anything else, dispatch `building` and let it open the run** — its first action is
+`harness init run`, which writes the run receipt and the launch record. Do not summarise what the harness will do:
+a run that left no receipt did not happen.
 
-## How the run actually executes
+## How the run executes
 
-On a spec with committed `scopes/*.md` — the common case — `tech-lead` holds the L0 intake
-conversation, writes `project-profile.md`, then hands the whole pipeline to a single background
-launch and does not drive it turn by turn:
+`building` drives the run in this session. It opens the run, then reads the run's files and takes the first
+phase whose condition holds, over and over: dispatch a worker, build the released scopes, run a kernel
+command, cross a gate, close. Three things follow:
 
-```
-Workflow({
-  scriptPath: ".shapeup/workflows/shapeup-run.js",
-  args: <the RunArgs object>
-})
-```
+- **A gate is answered where it is reached.** The loop prints the gate block, asks the PO one
+  question with a recommendation, records the answer with the source `PO (live)`, and goes on. There
+  is no relaunch after an answer.
+- **A killed session loses nothing.** The next phase is read off the files on disk, never from
+  the conversation, so `/ship` again over an open run resumes it: a finished phase is not re-run.
+- **Every agent the run spawns is a worker** — `orient`, `task-executor`, `spec-evaluator` and
+  `qa-edge-hunter` — and each leaves a row in the run's records. Planning is not a worker: the loop does it in this session, under a write fence of its own. Nor are the census at the Cut-List Review gate, the ship report, the retro after a ship, or the English copy of a non-English pitch: the loop does those itself.
 
-ORIENT → L1a → ANALYZE → WIRE → L1a.5 → MAP SCOPES → L1b → rounds of BUILD/L2/EVAL → QA → GATE H
-all run inside it. Three things follow, and they are the point of the cutover rather than trivia:
-
-- **A gate pause is a return value, not a stop.** The launch returns `{status: "paused", paused_at,
-  block}`; emit `block` **verbatim**, get the PO's decision, write it to
-  `.shapeup/<slug>/gate-answers.json`, and **relaunch the same call with the same args**. The
-  fast-forward re-derives position from disk and re-dispatches nothing already finished.
-- **A killed session loses nothing.** Resume state comes off disk, never from context, so a fresh
-  session picks the run up where it died — the property the whole launch shape exists to buy.
-- **The launch is the `Workflow` tool**, which is what gives the run resume-from-journal, worktree
-  isolation, and sub-agents that share the session's prompt cache instead of paying a cold start
-  each. `npx shapeup-sdlc init` writes the `"Workflow"` grant it needs. That grant is unscoped — it
-  authorises every dynamic workflow script in the project — so an install may decline it with
-  `--no-native-workflow`, in which case the launch asks for approval once per session and the
-  unattended lane is unavailable.
-
-`--tiny`, and any spec with no committed `scopes/*.md` yet, take the unchanged prose lane in
-`skills/tech-lead/references/protocol.md` instead — non-regression, by design.
+**`--tiny` is no longer served** — a breaking change in 4.0. The separate small-change lane (the `tech-lead`
+skill's prose loop) was retired with that skill, and `init run` refuses `--tiny` and `--lane` as unknown flags (exit 2). If
+`--tiny` is typed, say so plainly and run the full loop instead, with the pitch's appetite small (`~1 week` gives
+a two-round budget, and a small shape yields one scope): the gates and the verification floor are the same ones
+a bigger pitch crosses, and nothing is waived for a one-file fix. Do not take any other route — a hand-built
+change outside the loop is what the harness exists to prevent.
 
 Only run headless/auto if the user explicitly asks for it in their message:
-- `--auto` → advance low-risk gates automatically, still pause at L4 (Ship sign-off).
+- `--auto` → advance low-risk gates automatically, still pause at Ship Sign-off.
   Implies `--gate-answers guarded` unless a set is named.
 - `--unattended` → fully headless, `max_rounds 3`. Intended for CI, not day-to-day local runs.
-  Implies `--gate-answers ci` unless a set is named.
-  **In a `claude -p` invocation, set `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0` first.** Print mode
-  terminates a session's background tasks after 600 s, and the entire pipeline is one background
-  launch, so without it the run is killed roughly ten minutes in — mid-phase, with no error beyond
-  the CLI's own "background tasks still running; terminating". Resume state is on disk, so a
-  relaunch fast-forwards past whatever finished; the cost is a relaunch, not the run.
-  **Typing the flag IS the confirmation — do not stop to ask for another one.** Emit the warning
-  that no human will review the verdict before ship as the run's first line, then proceed straight
-  into GATE L0 in the same turn.
-
-  > Why this is spelled out: asking for confirmation here made `--unattended` unusable for the
-  > only job it has. In a non-interactive invocation (`claude -p …`, a CI step) there is no second
-  > turn in which to answer, so the run spent its turn requesting permission and
-  > exited having written nothing. A headless flag that cannot complete a headless run is a defect,
-  > not a safety feature — and the warning, which is the part that carries the safety value, is
-  > still printed. `--auto` remains the middle setting that pauses at L4.
-
-- `--tiny` → the small-change lane: orient (light) → single-task board → build → T0 → done.
-  Skips wiring, scope contracts, EVAL, and QA; only gates L0 and L4 pause. The tech-lead's L0
-  fit-check applies (≤ ~2 files, no new domain concept/dependency/flow) — if the change isn't
-  tiny, it will say so and recommend the full lane.
+  Implies `--gate-answers ci` unless a set is named. **Typing the flag IS the confirmation — do not
+  stop to ask for another one.** Emit the warning that no human will review the verdict before ship as
+  the run's first line, then proceed straight into the Intake & Config gate in the same turn. (In a non-interactive
+  invocation there is no second turn in which to answer; a headless flag that waits for one cannot
+  complete a headless run.)
 
-Additional flags, pass through to `tech-lead` only when the user names them:
+Additional flags, pass through to `building` only when the user names them:
 - `--breadboard <path>` → the pitch's breadboard, when it is not beside the pitch. A pitch shaped
-  with `/shapeup` is `shaping.md` + `breadboard.md`; the run finds a `breadboard.md` in the same
-  folder (or in `shaping/`) on its own, and reads one written inline in a single `pitch.md`. Name
-  it only when it lives somewhere else. Its Places become the spec's screens, and spec-lint stops
-  the run at GATE L1b when one is missing or folded into another screen.
+  with `/shapeup` is `shaping.md` + `breadboard.md`; the loop finds a `breadboard.md` in the same
+  folder (or in `shaping/`) on its own, and reads one written inline in a single `pitch.md`. Its
+  Places become the spec's screens, and the Board Review gate is where a missing or folded one is caught.
 - `--gate-answers <ci|guarded|interactive|path.json>` → the pre-recorded PO decisions this run
-  crosses its gates with. Gates still emit their blocks and still record a decision; the
-  decision's **source** becomes the answer set instead of a live human, and the ledger says so.
-  Generate one with `harness gate --init --preset ci --by "<name>"`. This is what makes a
-  headless lane finish: without it an unattended run waits at the first ⏸ until the wall-clock
-  budget expires, having built nothing.
-- `--wall-clock-budget <seconds>` → arm the deadline breaker. Off by default. Set it in any lane
-  with a hard clock (CI, an overnight run) and set it *below* the external kill, so
-  the harness trips its own breaker first: past the deadline `harness verify budget` denies new
-  `task-executor` work and routes to GATE H, where scope-hammer ships whatever is green. A run
-  killed from outside ships nothing — including the scopes that already passed T0.
-- `--parallel-scopes N` → how many scopes build at once (default 4). Concurrency is a cost
-  question before it is a speed one — every extra leg is another worker's full context — so this
-  is a dial rather than a constant. `1` builds scopes one at a time, which is the setting for a
-  project whose workers are not safe to run beside each other.
-- `--adversarial-verify` → before a FAIL finding costs a whole fix round, spend one independent
-  skeptic on it, prompted to refute and to default to "real" when it cannot. Off by default; it
-  does not touch the single-judge invariant, because a refutation retracts a finding rather than
-  issuing a verdict.
+  crosses its gates with. Gates still emit their blocks and still record a decision; the decision's
+  **source** becomes the answer set instead of a live human, and the ledger says so. Generate one
+  with `harness gate --init --preset ci --by "<name>"`. Without one an unattended run waits at the
+  first gate, having built nothing.
+- `--parallel-scopes N` → how many scopes build at once (default 4). Concurrency is a cost question
+  before it is a speed one — every extra leg is another worker's full context. `1` builds scopes one
+  at a time.
 - `--no-qa` → skip the QA Edge Hunt. QA is a level-up, not a gate.
-- `--rounds N` → override the outer circuit breaker (build+eval cycles, default 3).
-- `--attempts N` → override the inner circuit breaker (per-scope T0 attempts, default 5;
-  no-op on specs without scope contracts).
-- `--exec-model / --eval-model / --qa-model <name>` → override GATE L0.8's
-  resolved model matrix for this run only (highest precedence over `.claude/settings.local.json`
-  / `.claude/settings.json` / skill defaults). `--orch-model` is shown in the L0 block and changes
-  nothing: the orchestrator is the session already running this command, so its model is the one
-  that session was started with.
+- `--no-eval` → skip the evaluator; the run ships as not evaluated, and says so.
+- `--rounds N` → override the outer circuit breaker (build+eval cycles, default 3). Passed to `init run` as `--max-rounds N`.
+- `--attempts N` → override the inner circuit breaker (per-scope T0 attempts, default 5). Passed to `init run` as `--attempts N`.
+- `--exec-model / --eval-model / --qa-model <name>` → override the resolved model matrix for this run
+  only (highest precedence over `.claude/settings.local.json` / `.claude/settings.json` / skill defaults).

package/commands/wire.md

@@ -1,11 +1,4 @@
 ---
 description: Write the wiring map — engine → seam → entry-point call site, per use case
 ---
-Use the **solution-architect** skill (operation `wire`) on $ARGUMENTS.
-
-This is gate L1a.5 — it front-loads the integration seam so no engine ships orphaned. The skill
-is the sole writer of the committed `wiring-map.md`, resolved against `project-profile.md`'s
-`entry_point`; `harness verify trace` later checks reachability against it.
-
-It needs the spec folder (for the use cases) and the project profile. If either is missing, say
-which one rather than inventing it.
+Alias of `/ship plan`: use the **building** skill's plan activity on $ARGUMENTS and stop after the wiring map (the Wiring Review gate) — it needs the spec folder and `project-profile.md`; if either is missing, say which rather than inventing it.

package/hooks/dispatch-receipt.mjs

@@ -33,6 +33,28 @@
 // because a future host that reports failures through this event must not be able to satisfy the
 // wall by firing at all.
 //
+// THE PLUGIN'S WORKERS ARE AGENT DEFINITIONS (`agents/<worker>.md`), and a dispatch of one is an
+// `Agent` call whose result names the AGENT that ran (`tool_response.agentType`). An agent type the
+// host cannot resolve is rejected upstream exactly as an unknown skill is, and the worker's skill is
+// preloaded by the definition, so no `Skill` call happens inside it — the agent's name is the
+// attestation, and the same result carries what the host measured (`totalTokens`, `totalDurationMs`,
+// `resolvedModel`), recorded on the row so no session has to copy a figure by hand.
+//
+// THE MODEL THE CALL ASKED FOR IS RECORDED BESIDE THE ONE THAT RAN. The agent definitions say
+// `model: inherit`, so a dispatch that carries no `model` runs on the launching session's model whatever
+// the launch record asked for — measured across every archived run: the record said `sonnet` and the
+// receipts of the runs that were compared named two different models. `model_requested` is the call's own
+// `tool_input.model` (null when it carried none, which is "inherited", never a guess), and the ship gate
+// reads `usage.model` against the launch record; without both columns a cost or a verdict can be read
+// against a model that never ran.
+//
+// A SCOPE LAUNCHED IN THE BACKGROUND reports no agent at all: the result is "Async agent launched"
+// plus an `agentId`, because the host has not run anything yet. Parallel scope builds are exactly that
+// case, and without this arm the receipt hook went blind to every one of them. What the host did
+// establish is that it accepted the call — an agent type it cannot resolve is rejected before this
+// event — so the name the CALL carried (`subagent_type`) is the attestation, and the usage is null
+// because there is none to record yet.
+//
 // WHAT IT WILL NOT ATTEST. A receipt is written only when the tool result NAMES the skill that ran
 // (`tool_response.commandName`). An `Agent` dispatch whose prompt merely mentions `--order` gets no
 // receipt: the prompt is a plan to dispatch, not evidence of one, and minting attestation from it
@@ -86,6 +108,60 @@ export function skillInvokedFrom(toolResponse) {
   return name.slice(name.lastIndexOf(":") + 1) || null;
 }
 
+/**
+ * Did the host launch this `Agent` call in the background and accept it?
+ *
+ * A background launch returns no `agentType`: its result says the agent was launched and names an
+ * `agentId`. Both must hold — a call asked to run in the background AND a result that reports a launch —
+ * so a failed or empty result never counts as one.
+ *
+ * @param {object} toolResponse - The `tool_response` block of an `Agent` call.
+ * @param {object} toolInput - The `tool_input` block of the same call.
+ * @returns {boolean} True for an accepted background launch.
+ */
+export function backgroundLaunch(toolResponse, toolInput) {
+  if (toolInput?.run_in_background !== true || !toolResponse) return false;
+  const text = typeof toolResponse === "string" ? toolResponse : JSON.stringify(toolResponse);
+  return /\bagentId\b/.test(text) && /launched/i.test(text);
+}
+
+/**
+ * Which worker an `Agent` dispatch ran, from the tool result — or, for a background launch, from the
+ * name the accepted call carried.
+ *
+ * The host reports the agent NAMESPACED (`shapeup-sdlc-plugin:orient`); the bare name is compared
+ * against the WorkOrder's `worker`, so a general-purpose agent that merely had `--order` in its prompt
+ * attests as `general-purpose` and the ingest gate refuses it.
+ *
+ * @param {object} toolResponse - The `tool_response` block of an `Agent` call.
+ * @param {object} [toolInput] - The `tool_input` block of the same call.
+ * @returns {string|null} The bare agent name, or null when nothing names an agent.
+ */
+export function agentWorkerFrom(toolResponse, toolInput) {
+  const name = typeof toolResponse?.agentType === "string" && toolResponse.agentType
+    ? toolResponse.agentType
+    : (backgroundLaunch(toolResponse, toolInput) ? toolInput?.subagent_type : null);
+  if (typeof name !== "string" || !name) return null;
+  return name.slice(name.lastIndexOf(":") + 1) || null;
+}
+
+/**
+ * What the host measured for an `Agent` dispatch, as the leg row carries it.
+ *
+ * Absent figures stay null — a figure the host did not give is never inferred and never zero.
+ *
+ * @param {object} toolResponse - The `tool_response` block of an `Agent` call.
+ * @returns {{tokens_total:(number|null), duration_ms:(number|null), model:(string|null)}} The usage.
+ */
+export function usageFrom(toolResponse) {
+  const num = (v) => (typeof v === "number" && Number.isFinite(v) && v >= 0 ? v : null);
+  return {
+    tokens_total: num(toolResponse?.totalTokens),
+    duration_ms: num(toolResponse?.totalDurationMs),
+    model: typeof toolResponse?.resolvedModel === "string" ? toolResponse.resolvedModel : null,
+  };
+}
+
 /**
  * Build the receipt row for one dispatch.
  *
@@ -106,12 +182,20 @@ export function receiptRow(order, skillInvoked, payload) {
     skill_invoked: skillInvoked,
     // Corroboration, not the wall — see the header. `success` is absent on hosts that do not
     // report one, and an absent field must not read as a successful dispatch.
-    dispatch_ok: payload?.tool_response?.success === true,
+    dispatch_ok: payload?.tool_response?.success === true || payload?.tool_response?.status === "completed"
+      || backgroundLaunch(payload?.tool_response, payload?.tool_input),
     tool: payload?.tool_name ?? null,
     // Present when the dispatch came from a sub-agent, absent when the operator called it directly.
     // That is the difference between an orchestrated leg and someone driving a skill by hand.
-    agent_id: payload?.agent_id ?? null,
-    agent_type: payload?.agent_type ?? null,
+    agent_id: payload?.agent_id ?? payload?.tool_response?.agentId ?? null,
+    agent_type: payload?.agent_type ?? payload?.tool_response?.agentType
+      ?? (backgroundLaunch(payload?.tool_response, payload?.tool_input) ? payload.tool_input.subagent_type : null),
+    // What the host measured for an Agent dispatch; null for a Skill call, which reports none.
+    usage: payload?.tool_name === "Agent" ? usageFrom(payload.tool_response) : null,
+    // The model the call asked for, as written; null when the call carried none and the agent inherited
+    // the session's. Compared with `usage.model` by whoever reads the row, never reconciled here.
+    model_requested: payload?.tool_name === "Agent" && typeof payload?.tool_input?.model === "string" && payload.tool_input.model
+      ? payload.tool_input.model : null,
   };
 }
 
@@ -166,11 +250,13 @@ export async function main() {
     const cited = orderPathFrom(p.tool_input);
     if (!cited) defer("no --order threaded — not an orchestrated dispatch", "no-order");
 
-    const skillInvoked = skillInvokedFrom(p.tool_response);
+    const skillInvoked = p.tool_name === "Agent"
+      ? (agentWorkerFrom(p.tool_response, p.tool_input) ?? skillInvokedFrom(p.tool_response))
+      : skillInvokedFrom(p.tool_response);
     if (!skillInvoked) {
-      // The `Agent` case, and any host result that does not name what ran. Attesting here would
-      // mint the fact rather than record it.
-      defer("dispatch result names no resolved skill — nothing to attest", "no-skill-named");
+      // A host result that does not name what ran. Attesting here would mint the fact rather than
+      // record it.
+      defer("dispatch result names no resolved skill or agent — nothing to attest", "no-skill-named");
     }
 
     // The order path is relative to the shell; the receipt file is relative to the project root
@@ -190,7 +276,7 @@ export async function main() {
       rule: written ? "receipt-written" : "receipt-write-failed",
       reason: written
         ? `dispatch receipt: ${row.order_id} ran ${skillInvoked} (declared ${row.worker_declared}, ok=${row.dispatch_ok})`
-        : `dispatch receipt could not be written for ${row.order_id} — ingest will refuse this result unless --no-receipt-check`,
+        : `dispatch receipt could not be written for ${row.order_id} — this attempt cannot be counted as attested`,
     };
   });
 }