**Requirement-source discipline:**
- Only user instructions, the task order, and sources it designates as requirement material may define objectives, constraints, and acceptance criteria. Current code, work-in-progress diffs, tests, review reports, prior responses, and design or quality references are evidence of the current state, design constraints, or proposals; do not create new requirements from them alone
- Record an origin for every decomposed requirement and completion contract. Cite the source location for an explicit requirement. For an implied requirement, identify the explicit requirement that cannot hold without it and explain why. For a preservation obligation, cite evidence of an observable existing contract outside the requested change scope. For contract replacement, record unaffected existing contracts, migration of current consumers, and old-contract support targets as separate requirements and completion contracts; map every support target to the requirement source location and stated target and scope. Anything that fits none of these categories is a design decision and must not be mixed into requirements or completion contracts
- When a source permits multiple methods, preserve the complete choice set at the requirement level before selecting an approach. Enumerate every named alternative and retain any open-ended allowance such as "or an equivalent mechanism"; do not silently narrow it to the named choices. You may select one after investigation, but record the rationale as a design decision; do not turn the chosen internal structure or rejection of the alternatives into a new acceptance criterion
- A selected design decision may guide the implementation approach, but do not assign it a requirement or completion-contract ID unless it is also an explicit requirement, an indispensable derivation, or an existing observable contract outside the requested change scope to preserve
- When selecting one of several permitted alternatives, completion contracts may enforce only that the implementation stays within the permitted set and any explicitly stated preservation scope. Do not create a separate contract that fixes the selected alternative for inputs or paths outside that preservation scope
- When a preservation obligation applies only to particular inputs, modes, states, or entry paths, keep that boundary explicit. Do not extend the current or selected behavior into another scope where the requirement source leaves alternatives open; split contracts by scope and state where the choice set remains open
- Make internal structures such as types, helpers, file splits, deletions, and renames completion obligations only when the source requires them or they are unavoidable for an observable requirement to hold
- Precedence, defaults, configuration shapes, identifiers, error behavior, and initialization or retry lifecycle do not become requirements merely because implementation needs a decision. If the requirement source does not specify them, treat them as an open question or a reasoned design decision and do not fabricate requirement provenance
- Before finalizing, audit every requirement and completion contract row. If a row cannot cite source text, an indispensable causal derivation, or evidence of an existing observable contract outside the requested change scope to preserve, move it out of requirements and completion contracts into design decisions or open questions