# SPEC-P3 — Seam re-audit + thin chains (LIVE engine)

audience: AI coding agents first.
Target: `modules/harness/v2` + `modules/harness/v2/bin`. DO NOT touch `modules/harness/src` (dead WIP). Depends on SPEC-P1 + SPEC-P2 landed. Reference: sssf `adw_scout.py`, `adw_plan_build_test.py` (vendored).

Order: A1 audit → A2 fixes → T1 scout → T2 quick (gated).

## A1 — Live seam audit (evidence, not assertion)

Earlier seam claims (foreground/daemon drift, acceptance-criteria enforcement, dependency wave-ordering) were made against the DEAD `src` layout — do not trust them. Audit the LIVE engine for exactly these questions, each answered with file:function evidence:

1. Any dispatch-result path reaching commit/merge without passing reply validation + review (grep from `run.js integrateCheckpoint` backwards).
2. Plan validation: are dependency/wave-order violations rejected at load? Are acceptance criteria enforced or advisory?
3. Launch modes: which submission paths exist (`v2/bin/runplan.js`, `supervision.js`, `queue.js`), do spec + `run-plan` skill + code agree on foreground contract?
4. Wrapper parity: do all wrappers (`ca.sh`, `codex.sh`, `pi.sh`, north) emit status + usage in the shapes `verdict-status.py` and the usage reader expect? (pi.sh usage-after-status ordering already flagged.)

Output: `modules/harness/spec/factory/SEAM-AUDIT.md` — finding, evidence, severity, fix-or-justify. Every finding becomes either an A2 fix task or a written justification IN that file. No silent drops.

## A2 — Fix confirmed findings

Scoped fix tasks derived from A1, same test bar as P1/P2. Nothing speculative: no finding, no task.

## T1 — `scout` thin chain

Small read-only recon must not pay full-engine cost. `modules/harness/v2/bin/scout.js <prompt>`: one dispatch through existing seat/wrapper machinery, journals as a normal run (visible in /plans with zero UI work), validated reply `{ status, summary, findings:[{file,note}], proposals:[] }`, post-dispatch tree snapshot MUST equal pre (any repo change → failureClass `scope-violation`).

## T2 — `quick` thin chain (GATED)

`quick <prompt-or-plan.md>`: single-task plan→build→gate→review→commit reusing `runTrustedTask` machinery, no waves/integration branch. GATE: dispatch only after one green supervised full-engine run under P1+P2 instrumentation — do not multiply orchestration paths before the shared primitives are proven.

## Exit criteria

- SEAM-AUDIT.md exists; zero findings left neither fixed nor justified.
- `scout` end-to-end on a real repo, observable in /plans, repo untouched.
- `quick` ships a one-file change end-to-end with review enforced (post-gate).