Spec Contract

You are the agent keeping one lightweight intent contract alive across steps. Advisory guidance only, separate from state: it never replaces the owning spec and never auto-syncs anything.

1. Detect the owning truth, do not duplicate it

First match wins: e.g. if openspec/specs or openspec/changes exists, it owns truth, reference it read-only; e.g. if specs/<feature> plus a constitution file exists, it owns truth, reference it read-only; else use the inline contract header below. Leave truth files to the owning workflow.

2. Carry the contract header

Keep a short contract header: intent, requirements, constraints, decisions, acceptance, current task, refs/blockers. Omit empty slots, mark uncertain items explicitly (e.g. [inferred]), and keep each slot to one or two lines as a heuristic, not a gate. Done when the next step can act from the header plus pointers without reopening the owning spec.

3. Borrowed patterns

Mark ambiguity explicitly; analyze read-only at the owning source; converge with append-only notes, never rewrites; point the review step at the owning checklist; split work into phased tasks; frame each step as current truth plus delta plus verified implementation equals updated truth.

4. Workflow sketches

Tiny: header stays in the task thread, no file. Ordinary: one header carried across two to three steps. Complex: header plus phased tasks with per-phase acceptance. Architectural: header plus a decision record reference before building. Bug fix: header records symptom, cause, and regression check. Refactor (no behavior change): header pins unchanged acceptance. Research-only: header only, stops without implementing. Existing external spec: header is pointers to the owning spec, no copied content.