implementation-plan

Implementation Plan

Design the smallest sequence of independently verifiable vertical slices that satisfies the accepted intent.

Authority Boundary

Planning is read-only by default. Do not edit source, create issues, install dependencies, commit, push, deploy, or publish while producing a plan unless the user explicitly requested that action.

Workflow

1. Read the contract: Re-read the accepted spec or request. Extract requirements, non-goals, constraints, success criteria, authority limits, and unresolved decisions.
2. Inspect reality: Read repository instructions, status, relevant source, tests, manifests, task definitions, recent history, and existing patterns. Preserve staged, unstaged, and untracked user work.
3. Verify APIs: Confirm installed dependency versions and read their exact local source plus current authoritative documentation before planning against an unfamiliar API.
4. Map the change: Describe the current flow, desired flow, affected components, interfaces, data, trust boundaries, and operational consumers. Record existing code to reuse or delete.
5. Compare real options: For a meaningful architectural or tooling choice, present two or three numbered options with complexity, maintenance, security, reversibility, and migration trade-offs. Recommend the simplest adequate option.
6. Lock boundaries: Assign each file or package one responsibility. Prefer deep modules that hide decisions over pass-through layers, put tests and callers across the same real seam, and delay a generalized adapter until more than one concrete variation proves it. Record interface signatures, ownership, invariants, domain vocabulary, and compatibility behavior shared across tasks.
7. Slice vertically: Order work by dependencies so each slice delivers a coherent behavior through its test boundary. Fold scaffolding, configuration, documentation, and telemetry into the slice that needs them.
8. Design proof first: For each slice, name the failing or characterization test, focused command, full project gate, runtime/manual evidence, and expected failure or success signal.
9. Plan safe change: Cover data or schema migration, backward compatibility, feature flags, observability, rollout, rollback, support, and cleanup only when applicable.
10. Mark concurrency: Parallelize only independent tasks with disjoint ownership. Name shared files, generated outputs, runtime leases, and merge order explicitly.
11. Self-review: Map every requirement to a task and proof, remove placeholders and speculative flexibility, verify paths and symbols, and identify anything that still requires a user decision. Apply the deletion test: an abstraction earns its place only when removing it would spread meaningful complexity or violate a real seam.