Coding Design Plan

Turn a scoped task into the smallest coherent shape an implementer can build without making a new product or architecture decision. The next consumer is implement-and-review or the engineer making the change. The plan is done when it names the changed behavior, owner, boundary, verification, and any unresolved blocker.

Treat choices settled in the PRD or task as already decided. Do not reopen them through a new interview or option list.

Workflow

1. Read the approved task, acceptance contract, and active project conventions. Inspect the relevant code, tests, and current behavior before proposing a shape.

2. State the design problem in one sentence. Name the behavior that changes and the owner of that behavior.

3. Map only the affected boundary: local code, module, component, service, data store, public contract, or deployment behavior. Use change ownership to place each responsibility where the next change belongs.

4. Choose the smallest coherent shape that fits the existing code. State one decisive tradeoff when a real alternative exists. Do not compare options when the code and task make one local move clear.

5. Apply a targeted engineering check only when its trigger applies:

   1. Apply design-gate in the current role when the task changes a nonlocal boundary and no task contract has already selected the applicable lenses.
   2. Apply the task's named lens conclusions when they already exist. Do not rerun a lens to restate the same conclusion.
   3. Use to-prototype for one uncertainty that only running code can answer. Prototype code never graduates.

   Apply selected methods in the current role. An independent specialist needs a material risk or unresolved question. Before dispatch, use shared/references/model-preview.md to reuse or obtain one concrete approved route snapshot. The independent final code review remains a separate workflow requirement.