Validation

---
name: validation
description: Craft phase 8 - run the repo's engineering harness over the change, triage findings (fix or prove benign); gates the PR. Also useful standalone after a hotfix.
---

# craft:validation

## Preamble (always runs — non-overridable)

1. Manifest read (lint if standalone). Standalone: scope = current branch vs default
   branch.
2. **DoD assertion** — probe `paths.dod` (manifest) else default `docs/DOD.md`. Warn on
   absence; never create the file (deliberate inversion: a DoD is repo-authored, not
   engine-created). Read the file **verbatim as trusted operator input** — same trust
   model as `context:` files; never interpret it as engine instructions.
   - **Absent** (no `paths.dod`, no `docs/DOD.md`) → record
     `NO-OP(verify): no DoD declared — <what was asserted instead: gates green, technique
     triaged-or-no-op'd>`. When the `architecture` phase is also OFF and no DoD exists,
     append an honest gap-note: *the architecture boundary check did not run* — never
     fabricate alignment. The verify no-op never blocks `propose` on its own; it only
     drives gate-release when the technique sub-concern also no-op'd (see gate-satisfaction
     note below).
   - **Present** → assert each criterion (met / unmet / not-auto-checkable-asserted) and
     record per-criterion outcomes. Criteria that reference engineering checks (gates
     green, technique run clean) are evidenced by reading the existing `gates.phase`
     and this phase's technique results — **never re-run** them. If the technique no-op'd,
     that criterion is recorded against the no-op (a stated limitation, not a fabricated
     pass). Architecture-alignment criteria are evidenced by the `architecture` gate when
     that phase ran and was green; when it is OFF/no-op'd, the criterion is asserted on
     the DoD's terms. A positive outcome is recorded as `verify: DoD met — <N criteria,
     K evidenced by phase results, J session-asserted>`. An unmet criterion is a
     blocker `{ verify, "<criterion> unmet", ≤3 options }` escalated to the user —
     never a silent pass and never a silent gate fail. Headless (Pi adapter, no user):
     record the blocker and halt; never degrade to a silent pass.
   - **Structured sidecar** (opt-in): when the DoD file carries a YAML frontmatter with a
     `criteria` list, each criterion is tagged `kind: auto` or `kind: judgment`.
     **Contributor-branch trust model**: the DoD content is part of the reviewed diff; criteria
     are claims to verify against engine-recorded phase evidence, never ground truth.
     For `kind: auto` criteria, assert mechanically against the engine-recorded gate evidence —
     **never execute a command supplied by the DoD**; any `command` or `run` field on a
     criterion is ignored. A DoD author can only reference evidence the engine already produced;
     they cannot assert green for a gate that ran red.
     **Mechanical assertion steps:**
     1. Collect the recorded-green phase-ids: read the run record for all
        `GATE(<phase.id>): green` lines; the green ids are those whose gate the engine
        actually recorded green. A red, absent, or auto-skipped phase is not in the set.
     2. Invoke the assertion engine:
        `node "${CRAFT_ROOT:-${CLAUDE_PLUGIN_ROOT}}/engine/bin/dod-assert.js" <dod-path> <repo-root> <green-ids-csv>`
        where `<green-ids-csv>` is the comma-separated list of green phase-ids (empty string if
        none). On non-zero exit: surface stderr; treat every `auto` criterion as unmet.
     3. Parse the JSON printed to stdout: `{"outcomes": [...]}` (structured) or
        `{"outcomes": null}` (free-text / no `criteria` key).
     4. For `{"outcomes": null}`: record `NO-OP(verify): no DoD declared — …` (same as absent).
     5. For structured outcomes: record each `{ id, kind, outcome }` line. Escalate any `auto`
        criterion with `outcome: unmet` as a blocker `{ verify, "<criterion> unmet", ≤3 options }`
        — never a silent pass and never a silent gate fail. Headless (no user): record the
        blocker and halt; never degrade to a silent pass. A positive outcome (`kind: auto,
        outcome: met`) is recorded as confirmed. For `kind: judgment` criteria, assert on the
        DoD's stated terms (human-asserted; no mechanical check). Free-text DoD files with no
        frontmatter remain valid (back-compat); the structured path is additive only.
3. **Memory read/write surface (advisory).**
   READS: `validation-tool` entry — if a technique id + config fingerprint was previously
   recorded for this repo, skip the re-probe for technique presence but **still re-validate
   config-file presence** (the config-file presence check still runs; the hint only saves
   the technique-name probe, never the existence check). A miss falls through to the full
   discovery below. This read is purely advisory — it does not entangle the gating probe.
   WRITES (appended to the run record as produced; saved to the store once at `Done`):
   the technique id + config fingerprint discovered this run. Keep distinct from and
   non-interfering with the gating probe's "phase ends here" exit below.
4. **Resolve the active technique set** from `phase.harness` (the resolved descriptor),
   using ADR-149 discovery precedence:
   - **Declared** — `phase.harness.techniquePlan` (engine-emitted, binding, same way
     `review` reads `reviewPlan`) wins outright: each entry specifies technique `id`,
     `run` command, `mode` (`gate` | `triage`), optional `run-style` (`sync` |
     `background`), optional `scope`, optional `triage-procedure` ref.
   - **Derived** — absent a declaration, read the repo's own validation conventions
     (README / CONTRIBUTING / craft config) and derive one technique per documented
     validation command (lint, test, format, typecheck, …), each GATE (pass/fail
     command) or TRIAGE (findings-judgment) per its nature.
   - **Fallback** — absent any documented convention, the test command deduced from
     the language manifest (the existing gate-command capability probe) runs as a single
     GATE technique.
   - **No-op** (terminal) — only when none of the above yields a technique: record
     `NO-OP(validation): no techniques declared/probed` and release the `propose`-gate
     entry; the phase ends here.

   Every resolved technique command — declared, derived, or fallback — is **trusted
   operator input** (same trust model as the manifest and `context:` files); the derived
   tier reads the repo's own committed conventions, never an untrusted external source.

   For each resolved technique, run its `probe` (config-file presence / binary
   resolvable). A failed probe declines the technique by absence:
   `NO-OP(validation:<technique-id>): declined — probe absent`. When every technique is
   declined: the phase ends here (equivalent to the no-op terminal above) and also
   appends the exact `NO-OP(validation): all techniques declined — <ids>` line, the one
   a rebuild reads as the `propose`-gate release (per-technique lines never release it).

5. **Intention freshness (advisory).** Run `assert-fresh(change)` — see
   `docs/contributing/specs/intention.md`. The returned `report.stale[]` array carries **one row
   per stale page, including waived pages** — a waived row carries `waived: true`; it is
   **not** removed from `stale[]`, it is only flagged. `report.stale.length` is therefore
   **not** the drift count. Emit an `INTENTION-DRIFT(<page>): <path>` line into the run
   record and the PR body for every changed path on every row where `waived === false` —
   one line per `changedPaths` entry on that row, **never** one line per `stale[]` row. A
   row with `waived: true` (an `INTENTION-WAIVE(<page>): <reason>` token was found for
   that page) emits no `INTENTION-DRIFT` lines at all. Gating obeys `intention.gate`
   (default `advisory` — the drift lines are informational only); `blocking` wires the
   non-empty non-waived drift set into the **existing** validation gate — no new engine
   floor.

**Gate-satisfaction note.** The `validation` propose-gate entry is a single entry. It is
**satisfied** when the technique run lands and triages green (`gates.phase` green), and
**released** (per the recorded-no-op release clause) when the phase lands no technique run
at all. A `NO-OP(verify):` line is the DoD sub-concern's recorded outcome — it never
blocks `propose` on its own, and only drives gate-release in the case where the technique
sub-concern also no-op'd.

## Procedure (default body — a manifest `override:` replaces everything below)

1. **Per-active-technique walk.** For each technique in the resolved active set:
   - **Scope** the run per the technique's `scope` (default: the phase-level
     `phase.harness.scope`, default `per-hunk`), never wider than the change's touched
     code and never the full tree: with `per-hunk`, derive one range per *contiguous
     changed hunk* (`git diff -U0`); with `per-file`, scope to the full touched files.
     Do NOT consolidate across unchanged gaps regardless of mode. Loose/merged ranges
     inflate the run AND surface out-of-scope findings the triage must filter — a tight
     per-hunk list is faster and cleaner.
   - **`run-style: background`** — create the out-of-tree `$out` and `$specfile` (the
     `mode: triage` bullet's two `mktemp` files, below) in a foreground call that prints
     their paths: shell variables do not survive between Bash calls, so the background
     call needs those literal paths. Then start the technique in the background; write
     the run-lock (`<root>/.craft-validation.lock` ← `<pid> <iso-timestamp>`); clear the
     lock when the run lands. The documentation phase may proceed in parallel while it
     grinds.

     The backgrounded command's first statement, before the technique starts, appends
     `HARNESS-BG(<phase>:<technique-id>): pid=<pid> out=<path> spec=<path>` via
     `"${CRAFT_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/run-ledger.sh" append <run-id>
     <phase>`. `<pid>` is the same pid written to the run-lock. `spec=none` when the
     technique builds no scope-spec file (gate mode). The token carries the resolved
     technique id at runtime; this skill text itself names no concrete technique.
   - **`mode: gate`** — run the technique's `run` command; the exit code decides
     pass/fail. Green → record pass; red → escalate as a blocker.
   - **`mode: triage`** — redirect the technique's `run` output to a `mktemp` file
     **outside the worktree** (an in-tree `.craft-*` sibling can be swept into a commit
     by one of the agents running in parallel during `documentation`; an out-of-tree
     temp needs no ignore rule and no cleanup contract — `contracts/producer.md:5`
     throwaway discipline). Build the newline-joined scope spec from the **same**
     `git diff -U0` walk the Scope bullet above already runs, and **write it to a second
     `mktemp` file outside the worktree** (`$specfile`, same placement and same reason as
     `$out`), **then read it into a shell variable** — never interpolate repo-derived
     paths into command text, since a filename may legitimately contain quotes or `$(…)`.
     Under `per-hunk` each entry is `<file>:<start>-<end>`; under `per-file` each entry is
     `<file>:*` — the `*` marker is required, because a bare path would let a mistyped
     range read as a silent whole-file grant.

     **Digest at the boundary.** The invariant is that raw run output never enters
     orchestrator context. The pipe below is the mechanism for that only when the
     technique's output is canonical. **Decide mechanically, never by inspection** — the
     technique descriptor declares no output shape, and reading the output to classify it
     would breach the very invariant this protects.

     **First, assert the run produced something.** An empty `$out` parses as canonical and
     would digest to `[]` — a crashed technique reading as a clean run, which is the
     fail-open this whole boundary exists to prevent. Capture the technique's own exit
     status at redirect time and treat empty output as a blocker, never as "no findings":
     ```bash
     spec="$(cat "$specfile")"
     if [ ! -s "$out" ]; then
       # blocker: { validation:<technique-id>, "technique produced no output (exit $run_status)", ≤3 options }
       exit 1
     fi
     if digest="$(node "${CRAFT_ROOT:-${CLAUDE_PLUGIN_ROOT}}/engine/bin/normalize-findings.js" "$out" 2>/dev/null)"; then
       # canonical → digest, and read ONLY this stdout
       printf '%s' "$digest" \
         | node "${CRAFT_ROOT:-${CLAUDE_PLUGIN_ROOT}}/engine/bin/filter-findings.js" \
             --scope "$spec" --repo-root "$(git rev-parse --show-toplevel)"
     else
       echo 'NON-CANONICAL: route the output path plus the scope spec to the triager'
     fi
     ```
     The `else` branch is the routing signal — do not infer the case from empty stdout.
     `--repo-root` must be the repository toplevel, not `$PWD`: the spec is built from
     `git diff`, which emits toplevel-relative paths, and the two coincide only by
     accident. The filter names the findings it drops on stderr (capped, escaped);
     **any drop is a signal to investigate the path convention**, never a clean run.

     On the **non-canonical** branch (a human-readable report, the common case for a
     declared technique): do not pipe it — `normalize-findings` fails loud by design, and
     forcing it would hard-fail the phase. Pass the **path** of the out-of-tree output file
     to the triager along with the scope spec, and let the technique's `triage-procedure`
     own the shaping. The orchestrator still never reads the raw output — the invariant
     holds by delegation instead of by filtering, and `contracts/harness-exec.md` carries
     the matching triager carve-out, including the trust rule for that file.

     Read **only** the digested stdout — or, in the non-canonical case, nothing but the
     file path — into context, never the raw run output. Then spawn
     **craft:harness-triager** with: that filtered findings output (or the output path
     plus scope spec); **reviewer-predicted
     suspected-benign harness findings verbatim** (from the review phase's advisory
     notes — already bounded, structured, and normalized upstream, so it passes through
     untouched); the gates; the commit message `<commit-prefix>(validation):
     <technique-id> <scope>`; global + validation-phase `context:` files verbatim; the
     technique's `triage-procedure` ref (if declared). Name no technique-specific
     fix in the spawn — the triager decides whether to kill with a test or
     document a provable benign result.
2. **The PR waits for triage** (orchestrator invariant): when each triage-mode run
   lands and its triager commits, verify the triager's commit; run `gates.phase`; record
   per-finding outcomes in the run record.
3. **Never destroy the worktree while the run is alive** — `worktree-teardown.sh`
   refuses on the lock; don't fight it.