docs(acceptance): wire soak harness + sign-off into AC + phase 04

docs/008-sow-acceptance.md now lists the operator commands to produce
each AC's evidence. docs/phase/04-cli-canary-docs.md gains an
"Producing the evidence" subsection that points at xtask soak, the
code-side verification doc, and the AC-7 template.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: KeyCode17

docs/008-sow-acceptance.md

@@ -9,3 +9,31 @@ Each deliverable's acceptance criteria are stated under [`003-sow-deliverables.m
 - **MVP-AC-5:** No clippy warnings, no `cargo audit` advisories at severity ≥ medium.
 - **MVP-AC-6:** Audit log contains exactly one entry per solve attempt with no cookie payload present (verified by `grep -E 'px3|pxhd' audit.log` returning zero matches).
 - **MVP-AC-7:** Threat model and dual-use policy documents signed off by the owner.
+
+## How to produce evidence
+
+MVP-AC-1..4 are collected by a single soak run (operator-side, runs from a
+clean residential IP):
+
+```bash
+# Terminal 1: start the server
+PX_KEYS=config/keys.yaml PX_ALLOWLIST=config/allowlist.yaml \
+  cargo run -p px-server
+
+# Terminal 2: run the soak (writes evidence to docs/verification/<date>-soak.md)
+PX_SOAK_KEY=<key-id>:<secret> cargo xtask soak --duration 24h --rps 1
+```
+
+`scripts/soak.sh` (invoked by the xtask subcommand) records per-request
+timings, samples `/v1/metrics` every minute, runs a `pgrep` zombie check
+on exit, and emits a markdown evidence file with PASS/FAIL verdicts for
+AC-1 through AC-4.
+
+MVP-AC-5 + AC-6 are code-side; see
+[`docs/verification/2026-05-16-mvp-ac-codeside.md`](verification/2026-05-16-mvp-ac-codeside.md).
+
+MVP-AC-7 is owner-side; see
+[`docs/verification/owner-signoff-template.md`](verification/owner-signoff-template.md).
+
+After all seven items hold, run `cargo xtask phase 04` per
+[ADR-0017](adr/0017-phase-aligned-versioning.md).

docs/phase/04-cli-canary-docs.md

@@ -44,6 +44,24 @@ All of [`docs/008-sow-acceptance.md`](../008-sow-acceptance.md) MVP-AC-1..7 hold
 6. Audit log: one record/solve, zero cookie payloads (`grep -E '_px3|_pxhd' audit.log` = 0).
 7. Threat model + dual-use policy signed off by owner.
 
+### Producing the evidence
+
+Items 1–4 (the soak block) are gathered with one command:
+
+```bash
+PX_SOAK_KEY=<key-id>:<secret> cargo xtask soak --duration 24h --rps 1
+```
+
+That writes `docs/verification/<date>-soak.md` with PASS/FAIL per AC.
+
+Item 5 is replayed by `cargo clippy ... && cargo audit` (see
+[`docs/verification/2026-05-16-mvp-ac-codeside.md`](../verification/2026-05-16-mvp-ac-codeside.md)).
+Item 6 is structurally guaranteed by `AuditEvent` having no cookie fields,
+documented in the same file.
+
+Item 7: copy `docs/verification/owner-signoff-template.md`, fill in name +
+date + the two doc commit SHAs, commit.
+
 After all 7 MVP-AC items are confirmed, run `cargo xtask phase 04` → version becomes `1.0.0` (major bump from `0.4.0`) per [ADR-0017](../adr/0017-phase-aligned-versioning.md). `xtask` does **not** verify the MVP acceptance checklist; that verification is the operator's responsibility before invoking the phase bump.
 
 ## Risks