test-planlisted

# test-plan Define **what must be proven**, not how development must proceed. The Test Contract may be written before implementation or added to an existing project later, but its release criteria must be fixed before `release-gate` executes. Read the repository instructions and its `## harness-ship` Config v3 block first. Run `hs-setup` only when the block is absent or unsupported. Keep Config v3 policy-only; store test capabilities and release criteria in the Test Contract instead of expanding project configuration. ## Where the records live Every Harness Ship record is a file under `.harness-ship/` at the repository root, committed with the code it describes. `test-plan` writes the contract files; `advise` may create the tree first. | Record | Path | Written by | |---|---|---| | Quality report | `.harness-ship/quality-report.md` | `advise` | | Approved Test Contract | `.harness-ship/test-contract.md` | `test-plan` | | Test Contract revision in progress | `.harness-ship/test-contract.draft.md` | `test-plan` | | Bug Case, then its Diagnosis Receipts appended | `.harness-ship/bugs/<BUG-ID>.md` | `bug-workflow`, `diagnose` | | Candidate handoff, execution ledger, test report | `.harness-ship/candidates/<short-sha>/` — or the contract-defined candidate identifier, below | `testing-workflow` | `<short-sha>` is the first 12 characters of the candidate's full source SHA; the full SHA stays inside each record and is what binds evidence, so on any mismatch the record wins and