Development Plan Template

This file is the authoritative artifact shape and authoring contract for the persisted development plan owned by Developer.

The plan translates the active implementation contract into atomic, resumable build steps. It is not a replacement for scope, architecture, formal testing, review, or documentation.

Keep the artifact concise. Preserve DEV-NNN identifiers for the active cycle; do not renumber completed steps when revising the plan.

Every development plan is a STANDARDS cycle-owned artifact. Create it with node .standards/bin/artifact.mjs init DEVELOPMENT, which writes this block and the header below with the active cycle ID. The provenance Cycle and the visible Cycle field must always agree. Number new steps with node .standards/bin/id.mjs next DEV <plan>.

<!-- STANDARDS
Artifact: DEVELOPMENT
Cycle: <Active Work.Id>
-->

Development Plan

Implementation Contract

Scope: <Active Work.Scope | NONE>
Architecture: <Active Work.Architecture | NONE>
Request: <brief active request summary>

Build Steps

DEV-001 — concise implementation outcome

Status: PENDING | IN_PROGRESS | DONE Depends On: NONE | DEV-NNN, ... Acceptance: AC-NNN, ... | EXPEDITED_REQUEST

Goal

Describe the coherent implementation outcome this step produces.

Affected Area

Identify likely modules, components, paths, boundaries, or data areas. Use file paths only when they are established enough to be useful; do not pretend a file is known before repository inspection supports it.

Expected Outcome

State what should observably exist or behave differently when the step is done. Write this so a later Tester can understand what implementation surface is relevant without treating DEV-NNN as the requirement source.

Self-Check

List the smallest relevant Developer-level check: build, compile, typecheck, lint, existing test command, targeted runtime sanity check, inspection, or other established mechanism. Record the actual command and working directory, result, relevant assessed revision or dirty-tree content, and any limitation when the self-check runs. This is implementation feedback, not formal Tester verification. Keep the evidence sufficient for the protocol’s independent-session Tester or Reviewer handoff.

Implementation Notes

Record only non-obvious local choices or resume information. Omit when empty.

Verification Increments

Include this section when scheduling incremental verification. Omit it for a new AFTER_IMPLEMENTATION plan with no increments; retain existing entries after a cadence switch.

Increment 1

Development Steps: DEV-NNN, ... Acceptance: AC-NNN, ...

Ready Outcome

Describe the testable outcome available when these approved development steps and their dependencies are done, following the protocol’s Testable Increments. Reference acceptance conditions without redefining them.

Plan Notes

Record only cross-step sequencing or resume information that cannot be expressed on an individual step. Store suspended assignments here under the protocol’s Implementation and Verification Recovery Gates. State and routing remain canonical in STATE.md.

Authoring Rules

Create steps from the active request, completed scope/design when present, and relevant repository evidence; do not invent new requirements or architecture.
Use the required fields defined in the protocol’s Verification Cadence and Testable Increments. For an explicit user selection, follow Switch verification cadence in .standards/protocol/user-decisions.md before changing the effective setting or scheduling. Tester’s report owns assessment conclusions; record implementation readiness in this plan.
Set User Style only from an explicit user selection or a previously persisted selection for this development plan, under the protocol’s User Styles. Store an unambiguous accepted selector for the direct child file in .standards/user-styles/developer/. For a new selection, prefer its stem only when unique and usable as a record header value under User Styles; otherwise use a unique, usable full filename. With only tony.md present, both tony and tony.md persist as tony. With both tony.md and tony.md.md present, the second file persists as tony.md.md; its display identifier tony.md is ambiguous as a selector. <formal>.md persists as <formal>.md, since <formal> is a placeholder. Neither name for team | compact.md can be persisted; report this as a record-syntax limitation, not filename ambiguity. Retain working saved selectors and never shorten them into ambiguous or rejected names. If neither name is usable, report the limitation under User Styles without automatically renaming files or substituting a selection. Use NONE when no style is selected, and never store a path.
Start a new plan with User Style Locked: false. Allow selecting, changing, or clearing User Style only before first approval, while the plan remains PROPOSED. First approval covers the selection, including NONE, and sets User Style Locked: true for the rest of the cycle. Never reset the lock on revision, recovery, promotion, or a collaboration-mode switch, even if the plan returns to PROPOSED. A different style requires a new cycle and plan; replacing the current cycle’s plan does not unlock it.
On resume, reload the persisted user style before implementation. If the locked file is unavailable, stop until it is restored rather than clearing or substituting the style. User Style Locked is required; a missing field is an invalid plan and blocks implementation until corrected.
In STANDARD, reference the current Scoper-owned AC-NNN identifiers covered by each implementation step. Do not redefine their wording or use DEV-NNN as substitute requirement identity.
In EXPEDITED, use EXPEDITED_REQUEST rather than fabricating acceptance IDs.
Give each step one coherent implementation outcome. Split work when steps have materially different dependencies, observable outcomes, or failure surfaces.
Do not split mechanically by file, function, or estimated duration.
Keep dependencies acyclic and explicit when order matters.
Make the expected outcome concrete enough to distinguish DONE from partial work.
Keep self-checks proportional to the step and prefer project-established commands. Do not create Tester-owned tests as part of the plan.
Preserve existing DEV-NNN identifiers across plan revisions. Add new IDs for genuinely new steps. When recovery or rework invalidates the expected outcome of a completed step, reopen only the affected step to PENDING or IN_PROGRESS rather than renumbering it.
Reopening an existing step to correct implementation under unchanged approved intent does not require duplicate user approval. A material change to build steps, dependencies, behavior, or technical approach returns the plan to PROPOSED and requires approval before implementation.
If a plan originated in EXPEDITED and the cycle is later promoted to STANDARD, reconcile it before further implementation: update the Scope and Architecture references, replace EXPEDITED_REQUEST with current AC-NNN mappings, preserve still-valid DEV-NNN identities, and reopen invalidated steps. Bookkeeping-only reconciliation does not require duplicate approval; a material implementation-plan change does.
PROPOSED means implementation is blocked on user approval. APPROVED means the user approved the current material plan. IN_PROGRESS means at least one approved step has started or a completed plan has been reopened for correction. COMPLETE means every current approved step is DONE and Developer’s completion gate otherwise passes.