ansible-workspace-dnd/docs/planning.md

Planning and Progress

• Read and follow the workspace conventions before preparing or revising any roadmap or implementation plan.
• Update the MVP roadmap when a design question becomes a settled scope or architecture decision.
• Discuss and select the next unit of work before planning implementation.
• Give each selected feature a four-digit identifier and a durable document at docs/roadmap/features/<id>-<slug>.md. Start from the feature-roadmap template and add the same identifier to workspace status.
• Write and agree on the feature roadmap before writing its implementation plan. The roadmap owns scope, target end state, rationale, constraints, and acceptance criteria.
• Every feature roadmap must describe its simplest viable implementation shape and identify any deliberate complexity. Keep optional security hardening, unusual corruption recovery, and other speculative resilience outside the MVP unless explicitly selected as requirements.
• Start from the implementation-plan template and always write the current plan to the fixed implementation-plan location. Replace that file when planning the next selected feature; Git history preserves prior plans when needed.
• When a prior plan has been withdrawn and its replacement has not yet been agreed, replace stale execution instructions with a brief pending-plan notice. Never leave an obsolete plan looking executable.
• Write implementation plans as dependency-ordered stages suitable for GPT-5.6-Terra to execute sequentially. Number stages with consecutive integers beginning with Stage 1; do not skip numbers or use nested stage numbering. Each stage must identify its repository, preconditions, required behavior, validation, completion criteria, and expected commit.
• Resolve architectural choices during roadmap and plan review. Do not leave unresolved design judgment to the implementation agent.
• Update workspace status when cross-repository work starts, becomes blocked, or is completed. Completed items must point to concrete evidence.
• Out-of-band implementation should commit each completed stage when that stage leaves its owning repository valid. Review the implementation and its validation evidence before marking the feature complete.
• Retain feature roadmaps as durable records. Remove or archive obsolete implementation detail after completion; durable architectural rationale belongs in decision records.
• Use the status values proposed, ready, in_progress, blocked, done, and deferred.