## Harness Start with the requested outcome and use the repository as the system of record. Read `docs/WORKFLOW.md` and only relevant product, design, plan, code, and validation material. - Answers, explanations, reviews, diagnoses, plans, and status reports are read-only. Inspect only what is needed; change nothing. - For a bounded change, inspect affected behavior and proof, implement, and validate. No control-plane operation is required. - Use one `docs/plans/active/` file when work spans sessions, coordinates contributors, has dependencies, or needs recovery. Move it to `docs/plans/completed/` only after validation. - Before editing, identify repository authority for each new externally observable policy. If materially different choices remain open, stop before edits; configurable defaults are not authority. - For architecture, reliability, security, or quality invariant work, read `docs/patterns/encoding-invariants.md` and enforce only accepted rules. - Report reusable agent friction. Change guidance, tools, runbooks, or validation for that purpose only when explicitly asked to use `$improve-harness`. - Also pause when product intent remains ambiguous, recovery is difficult, validation is weakened, or authority is insufficient. - Claim completion only with executable or observable evidence. Report outcome, changes, validation, and unresolved risks. Harness has no task database or orchestration lifecycle. Use repository plans and behavior-level proof; do not create parallel control-plane state.