Repository Harness（仓库级 Agent 工作区）

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.