@gobing-ai/spur 0.4.2 → 0.4.3

package/plugins/sp/skills/spur-cli/references/decision.md

@@ -1,6 +1,6 @@
 ---
 name: spur-cli-decision
-description: "spur-cli noun reference: operate `spur decision` as the read/serve surface over the decision catalog - list registered decisions, show one served contract (parameters, criteria vocabulary, effective maker), run a decision to a served outcome (never writes a workflow resultFile), and status the catalog layers. Backed by @gobing-ai/ts-ai-decision 0.5.22 hub; offline by default via the built-in `typesafe` maker. Introduced by task 1093."
+description: "spur-cli noun reference: operate `spur decision` as the read/serve surface over the decision catalog - list registered decisions, show one served contract (parameters, criteria vocabulary, effective maker), run a decision to a served outcome (never writes a workflow resultFile), and status the catalog layers with per-maker readiness marks (registered, configured, recorded, probed). Backed by @gobing-ai/ts-ai-decision 0.5.22 hub; offline by default via the built-in `typesafe` maker. Introduced by task 1093; readiness marks and `--probe` by feature P11."
 see_also:
   - spur-cli
 ---
@@ -25,9 +25,10 @@ Decisions resolve first-wins across three layers:
 | `registered` | folders listed in config `decisions.paths` | Operator-added catalogs |
 | `shared` | `decisions/` under the bundled config root | Shipped catalogs (`config/decisions/` in-repo) |
 
-The bundled shared catalog ships `task-triage`, `failure-class`, and `review-failure-class` (all
-`choice` type, param `wbs`). Duplicate ids across layers keep the higher layer; duplicates inside
-one file are a load error.
+The bundled shared catalog ships `task-triage`, `failure-class`, `review-failure-class`,
+`gate-evidence`, `idea-recommendation`, `needs-design`, `anatomy-validation-verdict` and
+`maker-liveness` (the last served only by `spur decision status --probe`; no workflow references
+it). Duplicate ids across layers keep the higher layer; duplicates inside one file are a load error.
 
 **Config keys** (under `decisions:` in the global `~/.config/spur/config.yaml` or project `.spur/config.yaml`):
 `paths` (extra catalog folders forming the `registered` layer), `maker` (default DecisionMaker
@@ -41,7 +42,7 @@ config error, never a silent fallback (design §3.6).
 | `list` | Every visible decision: id, type, layer, catalog file, description | `--layer <layer>`, `--json` |
 | `show <id>` | One served contract: type, parameters, criteria, fallback, minConfidence, effective maker + source | `--json` |
 | `run <id>` | Serve one outcome (closed vocabulary; **never writes a resultFile**) | `--param <pairs...>`, `--evidence <files...>`, `--maker <name>`, `--json` |
-| `status` | Layer counts, registered makers, per-decision maker resolution, load errors | `--json` |
+| `status` | Sectioned readiness report: one status line, errors, aligned `Makers` and `Decisions` tables (registration, configuration source, recorded evidence), `Catalog` block | `--probe`, `--reliability [--since <iso>]`, `--json` |
 
 All verbs support `--json` (bare payload) and `--json-envelope` (`{ok, data|error}` envelope,
 ADR-091). Failure output for `--json` commands uses the canonical error envelope only under
@@ -51,6 +52,25 @@ ADR-091). Failure output for `--json` commands uses the canonical error envelope
 (design §3.4 — load errors surface via `status`) except for an invalid `--layer` value (exit 1).
 Error envelopes use `NOT_FOUND` for an unknown id and `VALIDATION_FAILED` for every other caller mistake.
 
+## Readiness marks (`status`, feature P11)
+
+The default `status` output separates four marks per maker and per decision
+(`docs/design/decision-observability-and-adoption.md` §3.4.1):
+
+| Mark | Column | Source |
+| ---- | ------ | ------ |
+| registered | `ST` glyph on the maker row | the maker registry holds the name |
+| configured | `CONFIGURED BY` | `decisions.maker` / `decisions.makers.<id>` |
+| recorded | `RECORDED` / `ACCEPTED` / `LAST SEEN` | the recorded `decision.end` ledger, matched on `(decisionId, maker)` |
+| proven | `PROBE` (only with `--probe`) | one live liveness decision per maker |
+
+`RECORDED` with `ACCEPTED 0` is the state that reads as healthy everywhere else: the maker is
+registered and configured but has never once succeeded. `--probe` is the only path that calls a
+maker, is bounded per driver, writes no decision log row and emits no event (`--probe` with
+`--reliability` is refused). Parse the marks with `--json`: `makers[]`
+(`registered`, `configuredBy`, `serves`, `evidence`), `perDecision[].evidence`, and `probes[]`
+under `--probe`.
+
 **Exit contract for `run` (design §3.4):** any backend-observed outcome — low confidence, model
 error surfaced as fallback, declined — is still a **successful serve** (exit 0, envelope carries
 `source`/`confidence` so callers can see why). Exit 1 is reserved for caller mistakes caught
@@ -95,11 +115,16 @@ spur decision run task-triage --param wbs=1093 --json
 spur decision run failure-class --param wbs=1093 \
     --evidence .spur/run/<runId>-test-output.txt    # redacted evidence -> instructions
 spur decision status --json | jq '.loadErrors'      # audit catalog health
+spur decision status                                 # readiness marks: registered / configured / recorded
+spur decision status --probe                          # prove each effective maker answers now
+spur decision status --json | jq '.makers[] | {name, registered, recorded: .evidence.recorded}'
 ```
 
 ## References
 
-- Design: `docs/design/decision-catalog.md` (§2 catalog authoring, §3.4 CLI surface)
+- Design: `docs/design/decision-catalog.md` (§2 catalog authoring, §3.4 CLI surface),
+  `docs/design/decision-observability-and-adoption.md` (§3.4 reliability report, §3.4.1 readiness view)
 - Hub: `@gobing-ai/ts-ai-decision` 0.5.22 (`DecisionService`, catalog schema, maker registry)
-- App service: `packages/app/src/decision/decision-service.ts`
+- App service: `packages/app/src/decision/decision-service.ts` (makers, `probeMaker`),
+  `packages/app/src/decision/decision-status-readiness.ts` (readiness marks, probe loop)
 - Shipped catalogs: `config/decisions/*.yaml`

package/plugins/sp/skills/spur-cli/references/features.md

@@ -81,9 +81,45 @@ mode needs its own required args).
 spur feature update H2 active
 ```
 
-Valid statuses: `backlog → active → verifying → blocked → done → cancelled`. The lifecycle engine
-enforces legal transitions; `verifying` is the gate where AC traceability must hold (L4).
-**One active goal** at a time is enforced by `check` (a corpus invariant).
+Valid statuses: `backlog → active → verifying → blocked → done → cancelled`, plus the frozen
+`deprecated`. The lifecycle engine enforces legal transitions; `verifying` is the gate where AC
+traceability must hold (L4). **One active goal** at a time is enforced by `check` (a corpus invariant).
+
+**`deprecated` — frozen, not terminal (ADR-136).** The state means *retained and frozen*: the record
+stays readable and countable, but nothing may attach new work to it or advance it. It is entered from
+`backlog`, `active`, `verifying`, `blocked` and `done`, and left only to `active` (un-deprecate,
+mandatory History entry) or `cancelled` (removed) — every other edge out of `deprecated` is undeclared
+and refused by the graph. The freeze, as shipped:
+
+- **Task links are refused** — `task create`, `update --feature` and `batch-create` exit non-zero and
+  write nothing (no sibling hint; `--no-reopen` is irrelevant for a frozen parent):
+
+  ```
+  parent-feature-status: feature <id> is deprecated (frozen); new tasks cannot link to it. Run removal work under its own feature, or un-deprecate: spur feature update <id> active
+  ```
+
+- **`L4.feature-deprecated`** — `task check` warns (does not error) for a *live* task under a
+  deprecated feature; a terminal task is the correct end state and gets no finding; `--strict`
+  elevates the warning as usual:
+
+  ```
+  Feature "<id>" is deprecated (frozen) — re-parent this live task (`spur task update <wbs> --feature <otherId>`) or cancel it.
+  ```
+
+- **`update --section` still lands** (exit `0`), appending a warning to `warnings[]`:
+
+  ```
+  Feature <id> is deprecated (frozen); change it only as part of removal
+  ```
+
+- **`sync` / `refresh` / `check --fix` never move it** — derivation is sticky and returns the no-op
+  proposal `{ from: 'deprecated', to: 'deprecated', reason: 'Feature is deprecated (frozen)' }`.
+
+- **`advance` refuses** with exit `1`, naming the un-deprecate command:
+
+  ```
+  <id> is deprecated; un-deprecate first: spur feature update <id> active
+  ```
 
 **Scalar field set:**
 
@@ -113,7 +149,8 @@ spur feature advance H2 --to verifying
 ```
 
 Walks the legal forward path (`backlog → active → verifying → done`) hop-by-hop until `--to`
-(default `done`). No-op when already at the target.
+(default `done`). No-op when already at the target; a `deprecated` feature is refused up front (see
+the freeze block above).
 
 ## Acceptance criteria conventions
 
@@ -169,7 +206,8 @@ the AC coverage map. Habits that keep it green:
 Use feature hierarchy for user-facing capabilities and roadmap themes; keep technical-module mapping
 as prose or notes unless the product surface is developer infrastructure. Priority is a scalar field
 (`spur feature update <id> --field priority --value P1`), while status is lifecycle state
-(`backlog → active → verifying → blocked → done → cancelled`). Do not conflate the two.
+(`backlog → active → verifying → blocked → done → cancelled`, plus the frozen `deprecated`). Do not
+conflate the two.
 
 **Structure first:** [features/hierarchy-mece.md](features/hierarchy-mece.md) (MECE roots, when to
 extend vs create). **Then priority:** [features/roadmap-priority.md](features/roadmap-priority.md).
@@ -216,6 +254,9 @@ spur feature sync H2 --force                   # re-derive live: bypass replay +
 spur feature sync H2 --folder docs/custom-tasks --json   # non-default tasks folder
 ```
 
+- **`deprecated` is sticky:** derivation returns no proposal for it
+  (`reason: 'Feature is deprecated (frozen)'`), so neither `sync` nor `check --fix` moves a frozen
+  feature — see the freeze block in §Editing a feature.
 - **`[id]`** syncs one feature; **`--all`** syncs every feature with linked tasks. One of the two is
   required - exit `2` if neither is given.
 - **`--dry-run`** reports proposed transitions without applying. **`--force`** applies a *reopen*

package/plugins/sp/skills/spur-dev/references/execution-batch-report.md

@@ -126,7 +126,7 @@ success exits 0 printing
 `{"ok":true,"persisted":<n>,"skipped":[{"id":<run-id>,"reason":"id-exists"|"external-key-conflict"|"record-conflict:<file>"|"record-missing:<file>"|"cited-directory:<name>"|"cited-symlink:<name>"|"cited-non-file:<name>"}],"evidenceSkipped":[{"name":<file>,"reason":"foreign-divergent","newer":"invoking"|"worktree"}]}`
 (`evidenceSkipped` is omitted when empty; the same object is written to `<invoking-tree>/.spur/run/persist-out.json` for `persist-out-check` to read)
 — an `external-key-conflict` skip leaves the target run unchanged **and fails the pass (1049)**: the delegate exits 1 printing `{"ok":false,"error":…}` naming the skipped source run ids, because that (workflow, external key) identity already belongs to a different receiving run — the batch was not persisted, so reconcile the source worktree by hand (it stays the provenance owner of record) before any teardown: auditable reconciliation names the original archived DB snapshot and the skipped source run identities, verifies the archive by file hash and by merged-commit ancestry of the source branch, and treats any residual deletion as explicit operator-authorized cleanup under the strict canonical evidence rules above. Task 1149 R1 grades a terminal duplicate lifecycle row (`task-lifecycle`/`feature-lifecycle`) as `external-key-conflict-bookkeeping` (non-fatal), so guarded transitions driven inside the worktree do not block teardown; the receiving lifecycle row is reconciled automatically during persist-out. An `id-exists` replay repairs missing owned artifacts and task links without duplicating them. A
-`record-conflict:<file>` never overwrites a divergent invoking-tree record and causes the delegate to exit 1, retaining the worktree. A
+`record-conflict:<file>` never overwrites a divergent invoking-tree record and causes the delegate to exit 1, retaining the worktree. Before reconciling one by hand, check **what** the invoking record is: when the run closed `done` inside a linked worktree the owning tree holds that run's **WT-0 landing obligation** (`landing: required branch=… path=… base=…`, see [execution-worktree-landing.md § WT-0](execution-worktree-landing.md#wt-0--markerless-worktree-runs)) — a 3-line record that is *not* a stub of the worktree's stage narrative, so copying the worktree record over it destroys the very obligation a later merge must rewrite. The reconciliation is therefore: discharge the obligation in place (`landing: merged <sha>` or `landing: retained`), and preserve the worktree narrative beside it (e.g. `<runId>.worktree-provenance.md`) rather than in place of it. A
 `record-missing:<file>` skip is a known `task-lifecycle`/`feature-lifecycle` row with no record file
 at all (its inserted DB row still counts in `persisted` — 0984 R5). Any failure
 exits 1 printing `{"ok":false,"error":<message>}` (a worktree DB run id that is not a single safe

package/plugins/sp/skills/spur-dev/references/execution-batch.md

@@ -606,15 +606,25 @@ The cheap rule gates fail fast when run first — the full-gate run is dominated
 suite, so a gate run that dies at `test-post-check` or `corpus-check` wastes most of its wall time.
 Before launching a full `spur-check-new`:
 
-1. **Run the two rule gates first** — `bun run test-pre-check` (43 rules: `no-console-output`,
+1. **Run the static checks first** — `bun run lint` (biome over the whole tree plus every workspace
+   typecheck). They fail in ~20 s and are the two defects that most often kill a full launch: a
+   formatting miss in a touched test file, or a generated declaration surface that no longer lists a
+   new export. Measured 2026-10-12: two consecutive `spur-check` launches died here and each spent
+   its whole wall time before reaching the suite.
+2. **Then the two rule gates** — `bun run test-pre-check` (43 rules: `no-console-output`,
    `no-direct-process-spawn`, `cli-*`, `require-corresponding-test`) and `bun run test-post-check`
    (`every-export-has-tsdoc`, `coverage-gate`). They catch boundary/TSDoc violations in seconds.
-2. **Promoted code must satisfy the boundary rules `scripts/` never enforced.** A command module
+   Two `coverage-gate` facts change how you call post-check: it **fails closed when
+   `.coverage/lcov.info` is absent**, which is the normal state of a fresh worktree, so run it after
+   the suite has written coverage or expect that one error instead of reading it as a finding; and a
+   targeted `bun test <file>` **overwrites** the tracefile, so post-check judges partial data if it
+   runs after one (the `coverage-gate` rule's own header documents both facts).
+3. **Promoted code must satisfy the boundary rules `scripts/` never enforced.** A command module
    moving from `scripts/` into `apps/cli/src` must route output through the `CommandOutput` seam (no
    `console.*`), spawn processes via `NodeProcessExecutor` (no `Bun.spawnSync`), get a
    `runtime-boundaries` fs-io exemption for sync reads (mirrors `task.ts`), and a non-command helper
    must not live in `apps/cli/src/commands/` (the noun scan treats every file there as a noun).
-3. **Doc/TSDoc edits shift `file:line` anchors** cited by other tasks — the per-task gate surfaces
+4. **Doc/TSDoc edits shift `file:line` anchors** cited by other tasks — the per-task gate surfaces
    them as `L4.anchor-subject-mismatch` (0775: the corpus sweep retired; run `spur task check <wbs>`
    on touched tasks). Repoint the shifted citations (via `spur task update --section`)
 

package/plugins/sp/skills/spur-dev/references/execution-worktree-landing.md

@@ -16,6 +16,28 @@ When the batch completes with **no failed task**, fast-forward-merge the worktre
 base ref. The terminal action after the merge differs by mode (ownership rule: *the flag removes
 only what it created*):
 
+**Duplicate-WBS sweep before the merge (observed 2026-10-12).** WBS allocation is per-tree — a
+worktree's allocator reads only its own corpus and DB — so two trees cut from the same base both
+allocate the same next number, and the collision surfaces only here (measured: the F42 batch's
+residual task shipped as `1183` while the base ref had already given `1183` to another task, so the
+file had to be re-filed before landing). Run this against the ref you are about to merge INTO:
+
+```bash
+TARGET=<base-ref>; BRANCH=sp/<branch>
+for f in $(git diff --diff-filter=A --name-only "$(git merge-base "$TARGET" "$BRANCH")..$BRANCH" -- docs \
+           | grep -E '^docs/tasks[0-9]*/'); do
+  wbs=$(basename "$f" | cut -c1-4)
+  git ls-tree -r --name-only "$TARGET" -- docs | grep -qE "/${wbs}_" && echo "COLLISION $wbs $f"
+done
+```
+
+A hit means one file must lose: keep the target's task, re-create the branch's task in the invoking
+tree through `spur task create` (the allocator picks the next free number), and drop the branch's
+file in the merge resolution — never land both, and never renumber by hand. Verified against a
+fixture (flags a duplicate, silent on a free WBS). The pathspec form is load-bearing: `-- docs` plus
+the `^docs/tasks[0-9]*/` filter, because plain `docs/tasks*` matches nothing under `ls-tree` here and
+`:(glob)` magic is rejected by `ls-tree`/`diff` (it works for `git status`).
+
 #### Create mode — merge, remove, delete
 
 ```bash

package/plugins/sp/skills/spur-dev/references/execution-worktree-setup.md

@@ -180,6 +180,13 @@ main-repo hooks from inside the "isolated" tree. Scripts are skipped only at thi
 a normal clone keeps `prepare`. The worktree still gets a usable dependency tree — the install
 exists so the first `bun test` resolves workspace imports.
 
+**Generated trees are still missing after the install.** A gitignored generated tree does not ride the
+worktree, so any suite comparing the canonical source against its generated copy fails until the
+generator runs. In this repo that is `apps/cli/config/` (from `bun run bundle:config`): without it
+`plugins/sp/tests/command-flag-parity.test.ts` fails on the missing generated pipeline YAML under that
+directory (observed 2026-10-12, A91 batch). Run the generator once after a create-mode install, and
+again after a rebase or merge that touches the canonical workflow sources it is built from.
+
 #### Reuse mode (`--worktree <name>`)
 
 Creation is **skipped entirely**. `$BRANCH` is the resolved worktree's already-checked-out branch; a
@@ -374,6 +381,13 @@ same call, verifies the WT-3 identity, and never relies on a persistent `cd` or
 > concurrent writer happened to leave in the tree — the two incidents this guard exists for are
 > `a94f9f431` and `36f274590` — so a driver stages only through `commit-guard stage`.
 
+> **`stage` takes files, never directories.** A directory argument is refused as `(unchanged since
+> base)` and stages *nothing*, so a task whose diff lives in a moved tree must expand the changed
+> paths (`git status --porcelain` plus the filter for the task's own files) instead of passing
+> `plugins/sp/hooks` or `packages/app/tests/hooks`. Symptom observed on 2026-10-12 (A91 batch): the
+> first commit captured only the pre-staged `git mv`/`git rm` renames and needed an amend to carry
+> the rest of the task.
+
 The FF-only git merge carries only commits — uncommitted writes in the worktree would be left
 behind by the merge and then destroyed by create mode's `git worktree remove`. WT-3b exists so
 that can never happen.

package/plugins/sp/skills/spur-dev/references/inline-pipeline-driver.md

@@ -441,9 +441,9 @@ Action semantics come from the YAML and the workflow action contract:
   recheck's `no-progress` guard honours it, so a cap-kill reads as a red gate the next time. Preserve
   the signal-induced receipt under a distinct name (`<wbs>-check-receipt.false-fail-<signal>.json`)
   and say so in the run log before re-running: never delete it silently, and never report a
-  cap-killed attempt as a genuine gate failure. Measured this session: one foreground gate call
-  (25.6 min host-wide lock wait + 7.4 min runtime) was SIGTERM-killed at the host cap and produced
-  exactly that false FAIL receipt.
+  cap-killed attempt as a genuine gate failure. Measured 2026-10-10 (before the gate-lock removal):
+  one foreground gate call (25.6 min host-wide lock wait + 7.4 min runtime) was SIGTERM-killed at the
+  host cap and produced exactly that false FAIL receipt.
 - `note` — append the expanded message to the inline run log.
 - `doctor.probe` — run the declared Spur doctor once, persist its status file, and apply any
   `setVars` result (including a resolved executor) before the next action or state.
@@ -766,7 +766,7 @@ host-owned gate sat between the stages, or when the platform cannot address comp
 **Implement and test-fix workers never run the full gate (task 1142 R3).** Workers use the light tier as their iteration check (task 1142 R3) in exact order:
 1. the **changed-path matrix** (`code-implementation/SKILL.md` § Changed-path targeted checks) over the paths they touched;
 2. the resolved `quality-gate` script in `light` mode (source-repo probe, else the installed twin) (biome, per-workspace typecheck, rule presets, related tests).
-Neither step takes the full-gate lock. The pipeline's `test` and `test-recheck` hops remain the only full gate. Carry
+Neither step takes the full gate. The pipeline's `test` and `test-recheck` hops remain the only full gate. Carry
 `--gate-log <path>` through to the child **verbatim**: never paraphrase it into "re-run the named
 gate command". That paraphrase is not cosmetic — it sent a worker into a full gate run instead of
 targeted iteration checks. The pipeline's next `test` (recheck)
@@ -835,6 +835,19 @@ The quality gate's `proofDigest` certifies a specific tree. Two rules protect it
    before a review dispatch is spent. The mismatch routes through the existing tripwire to `failed`;
    there is no new re-certify path.
 
+**A host-driven pass that skips the `test` hop has no digest-bound receipt.** `proofDigest` is
+captured by the `test` state's `proof.fingerprint` action, so hops driven out of band — an operator
+implementing/verifying/recording by hand, or an audit of a task whose gate the host ran directly —
+leave no `.spur/run/<wbs>-check-receipt.json`. The deciding artifacts are then
+`.spur/run/<wbs>-test-gate.status` plus its gate log. Two consequences, in order of preference:
+
+1. **Drive the pipeline** for anything that must be certified: only a digest-bound full receipt
+   satisfies a review/verify/record boundary (`sp-spur-check`), and the `test` hop owns the capture.
+2. **When a host-driven pass is unavoidable, say so in the verdict** — name the status file and gate
+   log as the evidence and grade confidence `MEDIUM`. A `HIGH` claim needs re-runnable evidence from a
+   checked path (the `sp-code-verification` ladder); claiming a receipt that was never written is the
+   failure mode this note exists to prevent (observed across four A91 tasks, 2026-10-12).
+
 **A mismatch names the drifted paths (R5).** At gate entry the pipeline snapshots the non-corpus tree
 state (`git status --porcelain=v1 -uall` plus `git diff --name-only HEAD`, excluding
 `docs/tasks*` / `docs/features*`) into `.spur/run/<run-id>-gate-paths.txt`. On a mismatch the
@@ -909,21 +922,25 @@ verdict artifact exists (tasks 0617, 0619 — the clobbering spiral).
 
 ## Running the full gate (task 0872 / 1127 R7)
 
-The full gate serializes behind a host-wide lock and legitimately runs 10-25 minutes. Two rules keep
-it from becoming a hazard (both violated once on 2026-10-10, blocking every other session for ~11
-minutes and aborting the run's own verification):
+The full gate legitimately runs 10-25 minutes. Two rules keep it from becoming a hazard (both
+violated once on 2026-10-10, aborting the run's own verification):
 
 - **Never wrap it in an external `timeout`, and never treat its runtime as a hang.** An outer bound
-  that fires mid-suite leaves the holder alive holding the lock while the caller believes it is gone.
-- **Run it detached and poll the log**, so losing the foreground call cannot lose the holder:
+  that fires mid-suite leaves a half-finished suite behind while the caller believes it is gone.
+- **Run it detached and poll the log**, so losing the foreground call cannot lose the run:
 
   ```bash
   nohup bash -c 'bun run spur-check > /tmp/gate.log 2>&1; echo "EXIT=$?" >> /tmp/gate.log' &
   ```
 
-- **Never kill a gate holder whose pid is alive.** The waiter line `waiting for holder (… held Nms)`
-  is printed only after `isProcessAlive(held.claim.pid)` succeeded, so a printed holder is a live one
-  by construction; only the lock's own dead-pid reclaim is authorised to clear a claim.
+- **Preserve a signal-induced receipt.** A cap-killed attempt leaves a red receipt that the next
+  recheck's `no-progress` guard honours, so it reads as a genuine failure unless the receipt is kept
+  under a distinct name and the run log says so.
+
+> Historical (task 1127, removed in task 1173): these rules were once stated in terms of a host-wide
+> `full-gate.lock`. The lock mechanism was deleted (`refactor(gate): remove gate-lock mechanism and
+> simplify quality-gate`), so nothing serializes gate runs today — the guidance above stands on its
+> own without it.
 
 ## Runtime interface contracts (from run evidence)