Gate: walk the chain before anyone writes code

Confirm the spec is internally consistent and fully covered before build begins. Walk the chain from every acceptance criterion through the component that owns it, the product that realizes it, and the tasks that build it, and report anything broken. This is a gate, not an editor: it reads everything and changes nothing, routing each fix to the stage that owns it.

The checks (walk all of them)

1. Coverage, both directions. Every AC-N traces to a component (design), to a product where one is needed (techstack), and to at least one task (plan). Light spec (no ## Design, no ## Tech Stack): the plan's *Component:* name (or none) is the component link; there is no feature-level product link to walk. Missing Design/Tech Stack is not a gap. Flag any criterion with a gap, and any component, product, or task that no criterion justifies (orphan / gold-plating). Mid-chain entry: when the chain was entered below idea (e.g. a plan ingested from Linear with no upstream criteria), a task whose upstream link is explicitly untraced is not an orphan — record it in the mid-chain-entry coverage note (loud, never a silent pass) rather than flagging it Critical. Still flag a genuine gap (a criterion that exists but reaches no task) and any fabricated link (a trace to an AC-N that does not exist). In-stack fast-path: when ## Tech Stack declares the single No new products — reuses the declared stack form (feature level, zero new products), the gate recognizes that declaration as satisfying the component -> product link for all the feature's components at once — a declared claim the walk honours, not a coverage gap and not an orphan (same as it honours a materialized section or an untraced link). This is a gate-walk recognition, not a new sdlc-check rule: sdlc-check does not walk component -> product at all, so it neither parses nor enforces this form — the recognition lives only in the gate's chain walk.
2. Consistency. Terminology matches CONTEXT.md across all artifacts, and the artifacts do not contradict each other (a criterion the design ignores, a task that fights the design, a product the design did not call for).
3. Constitution. Nothing across the spec violates a MUST principle.
4. Verification integrity. Each test-backed criterion has a kind-of-oracle and a task; each reviewer-checked criterion has a named review axis; the design's criterion-to-component map and the plan stage's task-to-criterion map are both complete. Light spec: there is no feature-level criterion-to-component map; the plan *Component:* field is enough. The project's green bar — the runnable commands that define a passing build (compile, test, lint, format-check) — is declared and concrete (no placeholders), so build inherits one definition of "green". On a light spec the declaration lives on docs/specs/overview.md ## Tech Stack or the repo's existing declared commands, not on a feature ## Tech Stack. Concreteness is all the gate checks here — runnability (does each declared command actually run?) is executed and diagnosed at the build baseline (build stage), where the workspace is isolated and side-effects are expected. The gate never executes declared commands: it stays read-only. Load-bearing library claims in ## Tech Stack must each be verified-by-probe (a probe ran, output kept + referenced) or explicitly asserted — an asserted (or untagged) load-bearing claim is a finding routed to techstack. The gate checks the tag and the kept probe output's minimal evidence shape ONLY — that the referenced output is present and well-shaped (a non-empty referenced artifact / log / transcript), and NOTHING more: it never opens-to-execute, never re-runs the probe, never authenticates truth or history: a verified-by-probe tag plus a referenced, shaped output present -> the claim is treated as probed; an asserted or untagged load-bearing claim -> a finding; the gate does not and cannot re-verify the probe's truth (consistency-not-truth, ADR-0001). The probe itself runs at techstack/spike time — interactive, human-in-loop — never in the gate.
5. Hygiene. No unresolved TBDs, placeholders, or "decide later" markers remain.
6. Mechanical corroboration. After checks 1–5, run the bundled checker as a second, automated witness to the same chain: sdlc-check docs/specs/<feature>/<feature>.md (resolve per getting-started's checker-resolution rule; degrade only when no form resolves; a plain run auto-scopes to whatever artifacts exist at gate time — do not --require the ledger or verification report, they don't exist yet). node present -> run it and interpret the exit code: 0 = corroborated; nonzero, or the checker crashing, is itself a failed check (fail-closed) — it blocks the verdict exactly like a Critical finding, even if checks 1–5 came back clean. node absent -> checks 1–5 still stand alone, but state a loud, explicit degraded fallback line in the report; never skip this check silently.

Checklist (do in order)

1. Load every artifact every section of docs/specs/<feature>/<feature>.md plus docs/specs/overview.md and root constitution.md and CONTEXT.md.
2. Build the chain map for each AC-N, assemble criterion -> component -> product -> task(s) from the artifacts.
3. Note provenance + entry point record which sections carry a source marker (materialized, not hand-authored) and where the chain was entered; treat explicitly untraced links as entry artifacts to surface, not defects to block on.
4. Run checks 1–5 mechanically, not by impression. The value of this gate is the literal walk.
5. Run the checker (check 6) invoke sdlc-check over the spec when node is present. A nonzero exit or a crash is a failed check — do not issue ready to build; treat it as a stop-and-ask, and if a human explicitly overrides it, record the override in gate-report.md (who/what, and why the verdict proceeded despite the failed check). node absent -> write the degraded-fallback line into the report now, so it can't be dropped later.
6. Severity-rate each finding Critical (blocks build), High (blocks build), Medium, Low. A failed checker run (check 6) rates Critical.
7. Route each finding name the owning stage that should fix it (criteria, design, techstack, or plan) and a suggested next action.
8. State the verdict ready to build only if there are no Critical or High findings AND check 6 did not fail (or its failure was explicitly overridden and the override is recorded).
9. Write gate-report.md and stop. Do not fix anything. If Linear sync is enabled in .agent-sdlc/config.json, also post the gate's status update + report via the linear-sync skill.

Principles

• Read-only. A gate that edits its own inputs cannot be trusted to judge them. Report, never fix.
• The chain is the spine. The walk from criterion to task is the whole point; do it literally.
• Honest severity. Critical is Critical. A gate that downgrades findings to pass is theater.
• Route, don't repair. Each fix belongs to the stage that produced the gap. Send it back there.
• Believe the artifacts, flag the contradictions. Take each artifact at face value and surface where they disagree, rather than guessing the intent.
• Corroborate, don't just impress-check. The checker is a second, mechanical witness to the same chain — a nonzero exit means the automation caught something the walk missed, or contradicts it. Either way that's a real finding, not noise to wave past.
• Degrade loud, never quiet. No node, no corroboration — the manual checks still stand, but say so in the report. A silent skip reads as a clean pass it isn't.

Rationalizations (excuses to skip the bar, and the rebuttal)

Red flags (stop and fix the gate's behavior)

• The gate edited any artifact other than the report.
• A criterion with no task passed as acceptable.
• A "ready to build" verdict issued with a Critical or High finding open.
• A "ready to build" verdict with no green bar declared — build then has no shared definition of "green". On a light spec, look at overview.md or the repo's existing declared commands; missing feature ## Tech Stack is not this flag.
• A "ready to build" verdict issued with a load-bearing library claim left asserted (or untagged) — an unprobed load-bearing claim passed off as settled.
• Findings stated as impressions rather than located in a specific artifact.
• An untraced link or a materialized section silently dropped from the report — a mid-chain entry passed off as a fully-traced chain (the same failure as silently dropping review coverage).
• A "ready to build" verdict issued while sdlc-check failed, with no recorded override.
• The checker silently skipped when node was absent, instead of an announced degraded fallback.

Done when

• The full chain has been walked for every criterion, or the light-spec walk (criterion -> named existing component or none -> task) has, with missing Design/Tech Stack recorded as by-design.
• Load-bearing library claims in ## Tech Stack are each verified-by-probe (tag + referenced kept output present) or the asserted ones are surfaced as findings.
• All six checks have run, including the checker's mechanical corroboration — or, when node was absent, a loud degraded fallback is recorded in its place.
• A failed checker run either blocked the verdict or was overridden with the override recorded.
• Every finding is severity-rated, located, owner-named, and given a next action.
• A clear verdict is stated.
• gate-report.md is written, and nothing else was modified.

The artifact (output)

docs/specs/<feature>/gate-report.md, containing only:

• Chain coverage table AC-N -> component -> product -> task(s), with gaps marked.
• Findings by severity each with: location (which artifact and where), the issue, the owning stage, and a suggested next action.
• Mid-chain entry / coverage note (when applicable) — if any section was materialized from an external source or any upstream link is untraced: name the entry stage, the source (from the provenance marker), and which links are unvetted upstream. Visible, never a silent pass.
• Checker corroboration result — pass, or failed (stop-and-ask stated, plus the recorded override if one was taken), or an announced degraded fallback (node absent). Never left implicit.
• Verdict ready to build, or not, with the blocking findings listed.

Conventions

• Lives at docs/specs/<feature>/gate-report.md (root specs/ in a repo that already uses it — the back-compat rule in getting-started). Read-only over every other artifact.
• Run after the ## Plan section exists and before build. Re-run after any fix until the verdict is clean.
• Invokes sdlc-check (resolve per getting-started's checker-resolution rule; degrade only when no form resolves) after its own chain walk for mechanical corroboration, mirroring the existing pr-review <-> Review panel contract: present and clean -> corroborated; present and failing (or crashing) -> stop-and-ask, override recorded; absent -> an announced degraded fallback, never a silent skip. The checker is read-only, same as the gate itself.
• May be invoked inline by build on a freshly materialized plan (build runs the gate itself when no verdict exists for the plan in hand), as well as standalone — the checks are identical either way.
• Critical and High findings block build; the owning stage fixes them and the gate is re-run.
• Mirrors spec-kit's analyze: a read-only consistency and coverage pass that modifies nothing.
• Downstream consumer: the build stage proceeds only on a clean or explicitly accepted report.