shapeup-sdlc 1.6.3 → 3.0.0

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

@@ -2,12 +2,26 @@
 
 The full collect-lists, gate-output blocks, and delegation scripts for every gate and delegation
 step, extracted from `SKILL.md` (progressive disclosure). **Read the relevant section when you
-reach that gate** — `SKILL.md` carries the workflow spine, the build/eval loop, and the hard
-rules; this file carries the step-by-step playbooks. The L2/L4 gates stay hook-enforced regardless
-of where the prose lives.
+reach that gate** — `SKILL.md` carries the workflow spine and the hard rules; this file carries the
+step-by-step playbooks. The L2/L4 gates stay hook-enforced regardless of where the prose lives.
 
-Order matches the run: GATE L0 → ORIENT → GATE L1a → WIRE/L1a.5 → MAP SCOPES → GATE L1b →
-(BUILD → GATE L2 → EVAL, in SKILL.md) → GATE L3 → SHIP → GATE L4.
+**Which lane these playbooks serve.** The gate blocks below are lane-independent: every
+lane emits them verbatim, and on the scoped lane `shapeup-run.js` returns the `block` field for
+`SKILL.md` to print unchanged. What differs is who runs the loop *between* the gates:
+
+| lane | BUILD → GATE L2 → EVAL is | read |
+|---|---|---|
+| a spec with committed `scopes/*.md` (the common case) | **code** — `skills/tech-lead/workflows/shapeup-run.js`'s round loop | that script's comments |
+| `--tiny`, or a spec with no scope contracts yet | **prose**, unchanged and non-regression | `references/protocol.md` (`:11-22` states the same split) |
+
+Order matches the run: GATE L0 → ORIENT → GATE L1a → ANALYZE → WIRE/L1a.5 → MAP SCOPES →
+GATE L1b → (BUILD → GATE L2 → EVAL — see the table above) → GATE L3 → SHIP → GATE L4.
+
+⟐ **ANALYZE runs before WIRE.** MAP SCOPES' two dispatches split around
+L1a.5: `analyze` writes the spec tree, then `wire` reads its `usecases/` — one wiring-map entry per
+use case — then `map-scopes` slices. Dispatching WIRE first hands `solution-architect` an empty
+spec folder, which its own input contract excludes (`skills/solution-architect/SKILL.md:43-44`); it
+escalates, writes nothing, and every relaunch re-dispatches it.
 
 ---
 
@@ -37,11 +51,16 @@ Collect (explicit — never inferred):
           - LOCAL   .shapeup/<slug>/      — run-trace (hidden, gitignorable):
               harness-run.md (this ledger), digest, orient/, evaluation/, qa/,
               discovery/ledger.md, orders/ + results/ (the envelope port), tasks/ (the task
-              board, v3.2 — regenerable via a generate-board order on any machine)
           spec_folder = shapeup/<slug>/spec/ (the deliverable arg passed to ba/eval/exec)
   L0.3  lens: lite | standard | cross-context   (passed to planner at step 8)
   L0.4  stack hint (e.g. "pnpm, Next 16 web :3000") — aims orient's code-surface sweeps + run commands
-  L0.5  eval dimensions: default [spec-conformance]; only add if user asks
+  L0.5  eval dimensions: default [spec-conformance]; only add if user asks. An added dimension
+        must reach `harness init run --dimensions <a,b>` — it is recorded in the ledger's
+        `eval_dimensions:` line and every EVAL order is compiled from there, so a set agreed
+        in conversation and not passed to the flag grades nothing. Shipped ids:
+        spec-conformance, tdd-surface, integration, completeness, test-surface-conformance
+        (security + performance ship disabled). Whatever is left out is reported at L4 as
+        `dims_not_evaluated` — "shipped" never silently means "verified for all".
   L0.6  max_rounds: default 3, appetite-informed (see L0.1b)
   L0.7  auto level:
           interactive (default) — pause at every L-gate; sub-skills keep their own gates
@@ -49,18 +68,18 @@ Collect (explicit — never inferred):
                                    at L1a/L1b (orient+plan), L3 (verdict), L4 (ship)
           --unattended           — auto-confirm all L-gates too; stop only on PASS,
                                    max_rounds, or hard error (for headless / Agent SDK / CI)
-  L0.8  Model & budget resolution (addendum Blueprint F, four layers, highest precedence
+  L0.8  Model & budget resolution (four layers, highest precedence
         first) — resolve ONCE here, record the resulting matrix in the ledger header:
           /ship flags  →  .claude/settings.local.json (per-member, Tier C)  →
           .claude/settings.json (team defaults, committed)  →  skill-shipped defaults
         Env knobs read at this layer: SHAPEUP_ORCH_MODEL, SHAPEUP_EXEC_MODEL,
         SHAPEUP_EVAL_MODEL, SHAPEUP_QA_MODEL, SHAPEUP_ATTEMPT_BUDGET (default 5),
-        SHAPEUP_DIGESTER_MODEL (default "script" — aegis-digest.mjs's regex pass; falls
+        SHAPEUP_DIGESTER_MODEL (default "script" — harness probe digest's regex pass; falls
         back to a Sonnet dispatch only when the digester reports unrecognized log formats).
         A requested model unavailable on the member's plan → degrade to the next tier down,
         record the degrade in the ledger (R2 — invariants are code paths, so adherence
         survives even when the model tier doesn't).
-  L0.9  attempt_budget: the INNER circuit breaker (design spec DD-9), nested inside
+  L0.9  attempt_budget: the INNER circuit breaker, nested inside
         max_rounds (the OUTER breaker, unchanged, L0.6). Default 5 — the number of T0 verify
         attempts a single scope gets inside one round before its attempt loop trips and
         queues a hammer PROPOSAL for GATE H rather than blocking the round. Only meaningful
@@ -73,6 +92,27 @@ Collect (explicit — never inferred):
         attempts. Set per scope (`no_progress_k` on the contract) or per run in the payload.
 ```
 
+**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.
+
+| Flag | `RunArgs` field |
+|---|---|
+| `--no-eval` | `noEval: true` |
+| `--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}` |
+| `--gate-answers <set>` | `answers` |
+| `--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.
+
 **L0.0 — intake precondition (before any other L0 collection):**
 ```
 resolve intake from, in order:
@@ -84,8 +124,7 @@ none resolvable  ->  ABORT. Print the ✋ NO INTAKE block from SKILL.md and stop
                      Do NOT describe the pipeline that "will" run.
 ```
 An orchestrator with no spec has nothing to orchestrate. Narrating the gate list in that state
-produces output that reads exactly like a successful run and contains no work — measured at 29%
-acceptance, n=3, on the benchmark. Fail loudly instead.
+produces output that reads exactly like a successful run and contains no work. Fail loudly instead.
 
 **GATE L0 Output:**
 ```
@@ -109,7 +148,7 @@ The Shape Up Building phase opens with **Orient, not planning**: the team reads
 and spikes the scary parts *before* any board exists, so the board comes out reality-born.
 
 ```
-Invoke via Agent (model: exec — see references/delegation.md "Invocation mechanism"):
+Invoke via Agent (model: exec — see references/protocol.md "Invocation mechanism"):
         Skill(shapeup-sdlc-plugin:orient) --pitch <intake> --spec <path> --stack "<hint>" [--auto]
 Owns:   its own GATE O-A/O-B; runs straight through under --auto.
 Writes: .shapeup/<slug>/orient/ → code-surface.md, spike-<area>.md, discovered-seed.md, hill-signal.md.
@@ -126,7 +165,7 @@ re-scanning the codebase. Pass `--auto` only when the run level is `--auto`/`--u
 committing to a scope map. This is the first Hill read (area-level — slices don't exist yet).
 
 ```
-Read .shapeup/<slug>/orient/. Render the 🗻 Hill from hill-signal.md (see ledger-schema.md "Hill report"):
+Read .shapeup/<slug>/orient/. Render the 🗻 Hill from hill-signal.md (see protocol.md "Hill report"):
   - each suspected area → uphill (open unknowns) | crest (approach proven by the spike) | downhill
 Print: the code-surface headline (where it lands), the spiked area + result, the riskiest
        open unknowns going into mapping.
@@ -149,9 +188,14 @@ Do NOT enter MAP SCOPES until Orient is accepted.
 2. WIRE — compile-order --operation wire --slug <slug> (worker→solution-architect), payload
    {project_profile}. Sole writer of committed wiring-map.md (per-UC engine → seam → entry-point
    call site → affordance). ⏸ GATE L1a.5: confirm each UC has a declared seam before slicing.
-3. COVERAGE (folds into MAP SCOPES) — compile-order --operation coverage → ba writes the SHARED
+   ⟐ PRECONDITION: MAP SCOPES step 1 (ANALYZE) has already run and usecases/ is
+   populated. WIRE writes one entry per use case, so dispatching it against an empty spec folder
+   is an escalation, not a wiring map — and a phase that writes no artifact is re-dispatched on
+   every relaunch. Verify: node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" probe resume
+   --slug <slug> --require analyze (exit 0 = the spec tree is there; exit 6 = do not dispatch WIRE).
+   Post-check the same way after the dispatch: --require wire.
    requirements.md registry (atomic REQ clauses, frozen ids).
-4. trace-lint — node "${CLAUDE_PLUGIN_ROOT}/skills/tech-lead/scripts/trace-lint.mjs" --slug <slug>. ADVISORY at L1b:
+4. trace-lint — node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" verify trace --slug <slug>. ADVISORY at L1b:
    covers-closure (every covered REQ named by ≥1 AC's covers:) + reachability (every UC engine
    reaches entry_point). Promote to --gate only once covers: is populated.
 ```
@@ -160,8 +204,13 @@ Do NOT enter MAP SCOPES until Orient is accepted.
 
 ## MAP SCOPES (step 8) — delegate to ba-pitch-analyzer (orient-informed)
 
+⟐ **Step 1 runs BEFORE the WIRE section above; step 2 runs after it.** The two
+dispatches sit either side of L1a.5: ANALYZE writes the use cases WIRE reads, and MAP SCOPES slices
+against the seams WIRE declared. Sequence: ORIENT → L1a → **ANALYZE** → **WIRE** → L1a.5 →
+**MAP SCOPES** → L1b.
+
 ```
-Two orders, two workers, one step (both model: exec — see references/delegation.md):
+Two orders, two workers, one step (both model: exec — see references/protocol.md):
 1. ANALYZE + BOARD — compile-order --operation analyze --slug <slug> --worker ba-pitch-analyzer
      --payload '{"pitch": "<path>", "lens": "<lens>", "orient_dir": ".shapeup/<slug>/orient/"}'
    dispatch: Skill(shapeup-sdlc-plugin:ba-pitch-analyzer) --order <path>. The order hands it
@@ -173,13 +222,13 @@ Two orders, two workers, one step (both model: exec — see references/delegatio
 2. MAP SCOPES — compile-order --operation map-scopes --slug <slug> --worker scope-architect
    dispatch: Skill(shapeup-sdlc-plugin:scope-architect) --order <path>. Sole writer of the
    committed scopes/<scope-id>.md contracts (import-graph slicing, substrate whitelists,
-   affordance manifest, fixtures, PA1/PA2 — mechanically linted by spec-lint.mjs).
+   affordance manifest, fixtures, PA1/PA2 — mechanically linted by harness verify spec).
 Record in ledger: planner duration + task count + scope count.
 ```
 Faithful note: keep the planner ambitious on scope but high-level on tech — do not push it
 to over-specify implementation. Errors baked into the spec cascade into every build round.
 Honest deviation: `ba` is heavier than Shape Up's light "map scopes" bucketing — that extra
-upfront spec-traceability is a deliberate trade for an LLM builder (redesign doc D8), not
+upfront spec-traceability is a deliberate trade for an LLM builder, not
 "pure Shape Up". State it; don't pretend otherwise.
 
 ---
@@ -203,7 +252,6 @@ v0.2.6 (non-regression).
 `.shapeup/<slug>/tasks/_index.md` missing AND `shapeup/<slug>/spec/usecases/`
 exists → a teammate (or a `--from build` resumed run) has the SHARED spec via git but no LOCAL
 task board on this machine — `.shapeup/` is gitignored and never travels with a branch.
-compile-order --operation generate-board --slug <slug> --worker ba-pitch-analyzer, then
 Agent (model: exec): Skill(shapeup-sdlc-plugin:ba-pitch-analyzer) --order <path> + ingest —
 regenerates the board from the committed usecases/domain-model/scopes. Record the bootstrap in
 the ledger. No-op on a fresh r=1 run (MAP SCOPES just wrote the board on this same machine) or
@@ -224,17 +272,27 @@ No scope contracts (pre-v0.3.0, unchanged from v0.2.6):
     - any SPIKE tasks (third-party feasibility) that block others
     - scope-summary "Done when" headline statements
 
-Substrate-disjointness assertion (design spec §5.1 Blueprint A, only when
+Substrate-disjointness assertion (only when
 shapeup/<slug>/scopes/*.md exist — scope-architect's lint pass already ran;
 this is the orchestrator's own re-confirmation before committing to a build sequence):
-  - Run `node "${CLAUDE_PLUGIN_ROOT}/skills/ba-pitch-analyzer/scripts/spec-lint.mjs" --slug <slug>`: DISJOINT (a file in two
+  - Run `node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" verify spec --slug <slug>`: DISJOINT (a file in two
     scopes' `allowed_file_substrate` without BOTH declaring it `shared_substrate` — PA3
-    waiting to happen), PA1 (directory-aligned scope), PA2 (size cap). Any red → HARD STOP,
-    route a remap order to scope-architect before BUILD — a human may have hand-approved
-    past a 🔴 at the architect's own checkpoint.
+    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). Any red → HARD STOP, past a 🔴 at the architect's own checkpoint.
   - Lock the build SEQUENCE riskiest-first: order scopes by open-unknowns count (from
     hill/<scope-id>.yml if present, else the orient hill signal), not by file count or
     alphabetical — Shape Up's "solve in the right sequence" (step 10).
+    DEPENDENCIES CONSTRAIN THAT ORDER, and each contract declares its own: scope A follows scope
+    B when A names B in `depends_on`. The order lives in the same committed tier as the contracts
+    it orders, so it survives a clone. Risk orders the scopes; the dependencies decide when each one is
+    RELEASED — a scope starts as soon as the scopes it consumes have settled, not when its whole
+    level has, so a scope may well start while a sibling is still building. A scope that consumes
+    the others' output (an entry point wiring up command modules) therefore cannot be scheduled
+    alongside them however low its unknowns count. It fails open: a contract declaring no
+    `depends_on`, or naming a scope that is not in this run, falls back to releasing a level at a
+    time, and then to no constraint at all (spec-lint SCOPE-DEPS reports the dangling id).
 
 Ask (max 2): scope cuts? lens correct? any SPIKE to resolve before build?
   Scope-hammer framing: reference the appetite from the pitch
@@ -247,27 +305,42 @@ Do NOT enter BUILD until the board is accepted.
 
 ---
 
+## GATE L2 — Board 100% Done (Pre-Eval)
+
+**Purpose:** The single exit point from the BUILD loop into EVAL. It ensures every scope is green before invoking the evaluator.
+
+**Output:**
+```
+⏸ GATE L2 — Board 100% ✅ + T0-green
+Feature   : [slug]
+Round     : [r]
+Scopes    : [N] green, [M] queued for hammer
+```
+
+Under `--interactive` / `--auto`, the hook warns if the board is not truly green (advisory) and requires explicit PO approval to proceed. Under `--unattended`, it automatically aborts on a red board or proceeds on a green one.
+
+---
+
 ## GATE L3 — Verdict & Loop
 
 ```
 Render the 🗻 Hill report (slice-level) — NOT a task count. Scope contracts present → read
-  committed hill/<scope-id>.yml shards (mechanical phases from GATE L2.4, DD-10). No contracts →
+  committed hill/<scope-id>.yml shards (mechanical phases from GATE L2, never authored). No contracts →
   fall back to the board + open-unknowns heuristic (uphill/crest/downhill/done). See
-  references/ledger-schema.md "Hill report". Roadmap rule unchanged either way: progress is
+  references/protocol.md "Hill report". Roadmap rule unchanged either way: progress is
   reported by hill position, never by "N/M tasks done".
 
 Read EVAL-FEATURE-<slug>.md verdict.
 
 PASS:
   → first PASS of the run AND not --no-qa:
-      delegate ▶ QA EDGE HUNT → Agent (model: qa — see references/delegation.md
+      delegate ▶ QA EDGE HUNT → Agent (model: qa — see references/protocol.md
       "Invocation mechanism"): Skill(shapeup-sdlc-plugin:qa-edge-hunter) (pure worker; see
       round-protocol "QA edge hunt"). Args: spec folder, EVAL report path, ledger path, app URL.
       Its GATE Q0/Q1 pauses surface here. Output: `~` findings → .shapeup/<slug>/discovery/ledger.md
       + .shapeup/<slug>/qa/hunt-report.md. No verdict — the run's verdict stays this EVAL's PASS.
       → then proceed to SHIP (triage of QA findings happens at SHIP S.0/GATE L4).
   → subsequent PASS (a promoted-findings fix round): Agent (model: qa):
-    Skill(shapeup-sdlc-plugin:qa-edge-hunter) --recheck on the promoted items only, then SHIP.
   → --no-qa or skill absent: proceed straight to SHIP; ledger records `qa: skipped`.
 
 FAIL:
@@ -289,7 +362,7 @@ Decision  : [SHIP | re-build bugs in round r+1 | escalate: max rounds hit]
 ```
 The Hill is the progress narrative; the board's `N/N ✅` is execution substrate (it gates
 EVAL at L2), never the headline. Slices come from `ba`'s board; if slice IDs aren't present
-yet (D3 deferred), report at task-group level and note the fallback in the ledger.
+yet, report at task-group level and note the fallback in the ledger.
 
 ---
 
@@ -297,14 +370,14 @@ yet (D3 deferred), report at task-group level and note the fallback in the ledge
 
 ```
 S.0  GATE H — delegate to scope-hammer (this IS Shape Up's "Decide When to Stop", step 11):
-     Invoke via Agent (model: exec — see references/delegation.md "Invocation mechanism"):
+     Invoke via Agent (model: exec — see references/protocol.md "Invocation mechanism"):
        Skill(shapeup-sdlc-plugin:scope-hammer) --slug <slug> --baseline <shaping/baseline.md if present>
              [--breaker outer]   when round_budget hit 0 with scopes still open
              [--breaker inner --scope <id>]   once per queued hammer proposal (attempt_budget
                                               exhausted scopes accumulated during BUILD)
              (no --breaker flag)              normal stop — all scopes FINISHED, post-QA-hunt
      Feeds it: qa/hunt-report.md findings (when present), discovery/ledger.md open items,
-               advisor-protocol budget-overflow flags, the hammer-proposal queue from BUILD.
+               the hammer-proposal queue from BUILD (attempt-budget exhaustions).
      Reads back: its GATE H0/H1/H2 output — census, baseline comparison, cut list + verdict.
      Authority: scope-hammer proposes; the tech lead records the PO's decision in
        round-ledger.md and performs the actual close (S.1 onward). It never ships on its own.
@@ -326,36 +399,54 @@ S.2  Print a feature summary: tasks shipped, rounds used, final verdict, dims ev
      (and explicitly: dims NOT evaluated, so "shipped" is never read as "verified for all").
 S.3  Point to the traceability: tasks/_index.md (all ✅) + EVAL-FEATURE-<slug>.md (PASS) +
      harness-run.md (the round ledger).
-S.4  task-executor's GATE E remains the formal per-task close; the tech lead confirms the
-     feature-level close.
+S.4  task-executor's own verification checklist remains the formal per-task close; the tech
+     lead confirms the feature-level close.
 S.5  Deploy truth — "done means deployed", honestly. Building stops at "built & verified";
      deployment is an outward-facing action gated to the PO. Either:
-       - PO says yes → run the project deploy (docs/infra/DEPLOYMENT.md) and record "deployed".
+       - PO says yes → run the project's own deploy procedure and record "deployed".
        - otherwise → record "built & verified — deploy pending (PO)".
      NEVER auto-deploy; "shipped" must never silently mean "deployed".
-     (Baseline-anchored scope-hammering at ship time is redesign-doc D5 — deferred; for now,
+     (Baseline-anchored scope-hammering at ship time is deliberately deferred; for now,
       `ba`'s Appetite Guard covers overflow and cuts go to synthesis "Hammered Out".)
-S.6  Harvest one signal row → append to `shapeup/metrics/<machine-id>.jsonl`
-     (committed, SHARED root; sharded per machine so concurrent runs never merge-conflict on
-     one file — addendum Δ3; an aggregate view is `cat shapeup/metrics/*.jsonl`).
+S.6  Harvest one signal row → append to `.shapeup/metrics/<machine-id>.jsonl`
+     (LOCAL root, gitignored since ADR-0001 — a committed shard keyed on a hostname only
+     grows and publishes a machine name; sharded per machine so shards can be pooled
+     deliberately without colliding on one filename. The read plane is
+     `harness probe stats`, or `cat .shapeup/metrics/*.jsonl`).
      Copy fields that ALREADY exist as structured output (run-state, final EVAL report,
      discovery ledger, qa/hunt-report, breadboard B5). Two hard rules:
        1. Harvest only fields that already exist at ship time — never evaluate something new.
        2. Record facts, never compute a new verdict (no `run_quality_score` — that would be
           a second judge behind spec-evaluator). The eval suite interprets; harvest records.
      `final_audit_score` is COPIED from the EVAL report, never re-graded.
-     ALSO copy the two v1.5 exit measurements, both produced by scripts at zero model tokens:
-       node "${CLAUDE_PLUGIN_ROOT}/skills/tech-lead/scripts/stats.mjs" --ratchet --slug <slug>
+     ALSO copy two run-quality measurements, both produced by scripts at zero model tokens:
+       node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" probe stats --ratchet --slug <slug>
          → `ratchet`: {trials, scopes_multi_trial, improvement_rate, monotone_rate,
                        sawtooth_count, mean_trials_to_green}
-       node "${CLAUDE_PLUGIN_ROOT}/skills/tech-lead/scripts/stats.mjs" --hooks
+       node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" probe stats --hooks
          → `hooks`: {evaluations, denials, errors, per_hook}
-     Harvest them HERE or lose them: both read LOCAL ledgers (t0/trials.jsonl,
-     decisions.jsonl) under the gitignored `.shapeup/` root, so a number left there
-     answers its question exactly once and is then wiped. The committed shard is the only
-     record that accumulates across runs and across machines — which is what both exit
-     criteria require, since neither is meaningful from a single run.
-     → full field list + row template: references/ledger-schema.md "Harvest row".
+     Harvest them HERE or lose them: both read per-run working ledgers (t0/trials.jsonl,
+     decisions.jsonl) that the next run's bookkeeping supersedes, so a number left there
+     answers its question exactly once. The metrics shard is the one record that
+     accumulates across runs — and neither measurement is meaningful from a single run.
+     ALSO copy `run_id` from `receipt.json`. It is the row's only link to the run trace
+     that produced it: every other field here is a count, and `feature_slug` groups runs
+     TOGETHER rather than apart. It is what joins this row to the S.7 export.
+     → full field list + row template: references/protocol.md "Harvest row".
+S.7  Export the run's records → one keyed dataset, before the trace is superseded.
+       node "${CLAUDE_PLUGIN_ROOT}/kernel/harness.mjs" report export --slug <slug>
+     Same argument as S.6, applied to the records the harvest row does NOT carry: orders,
+     results, the agent-call journal, T0 verdicts, trial rows, criterion verdicts and this
+     run's hook decisions all live in the LOCAL tier, which is regenerable and gets wiped.
+     The export freezes them as fact tables under `.shapeup/exports/<run_id>/` (JSONL, one
+     object per line), keyed by run id so a second run of the same feature is a second
+     dataset rather than an overwrite. `--out <dir>` sends it somewhere durable instead.
+     It is READ-ONLY: it writes nothing into the trace, so it may be re-run at any time.
+     WHY IT IS NOT A HARVEST FIELD. Run economics — cost, wall clock, turns-to-first-write —
+     is DERIVED from this dataset (`harness probe stats --economics`), never copied into the metrics
+     shard, because that row's contract rejects clock fields on purpose (see
+     protocol.md "Rejected fields"). Preserving the trace keeps the figures available
+     without putting a velocity number in the signal feed.
 ```
 
 ---
@@ -372,7 +463,7 @@ Ledger    : harness-run.md
 ```
 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/delegation.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 skills: `task-executor`, `ba-pitch-analyzer`, `qa-edge-hunter`; each reads its own file at the top of its next run. The tech lead does not categorize the feedback itself — that is the coach's gate, by design (no assumptions).
+- 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 skills: `task-executor`, `ba-pitch-analyzer`, `qa-edge-hunter`; each reads its own file at the top of its next run. 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.`
 
 ---