Implementation Governance

Choose implementation scope deliberately, then make consistent implementation and materialization decisions inside it. Do not equate disciplined implementation with automatically choosing the narrowest intervention.

Workflow

1. Diagnose the request at both the immediate and structural levels. Read references/workflow.md and references/scope-options.md first. Inspect enough surrounding code, ownership, repetition, convention, and change friction to determine whether the immediate problem is isolated or evidence of a deeper code-health problem.

2. Set the solution horizon before implementation. Use the canonical horizons contained, structural, and foundational. Honor an explicit user preference. Treat a task-connected, evidence-backed improvement in correctness, ownership, consistency, testability, or future change cost as a reason to surface a broader option when its durable benefit is material relative to its cost and risk. When a contained solution and a credible broader solution differ materially in long-term quality, recommend an option, explain the tradeoff, and wait for the user's choice before editing. Use references/decision-previews.md to show the smallest consumer-oriented code or structural artifact that materially clarifies the difference. A strong recommendation does not remove this decision gate. Treat delegation as explicit only when the user authorizes choosing the solution horizon, scope, or architecture; ordinary permission to implement, fix, proceed, or make the appropriate change is not scope delegation. If the user explicitly delegates that decision, choose and continue. If no broader option is supported by evidence, continue with contained without manufacturing a choice.

3. Identify what kind of change the selected horizon requires. Read references/change-kinds.md to classify the work with one primary change kind and any secondary change kinds that materially affect scope, extraction, or validation. Treat change kind and solution horizon as separate decisions.

4. Decide the correct scope and contract handling inside the selected horizon. Use references/scoping.md to choose the smallest complete scope that fulfills the selected horizon, decide what stays with the current owner, and determine when broader ownership is justified. If the change alters a public export, interface, schema, route shape, event payload, database contract, or external integration boundary, read references/escalation.md first. Read references/contract-changes.md only after that contract-affecting change is confirmed.