49 lines
3.0 KiB
Markdown
49 lines
3.0 KiB
Markdown
# Planning and Progress
|
|
|
|
- Read and follow [the workspace conventions](conventions.md) before preparing
|
|
or revising any roadmap or implementation plan. Also read the specialized
|
|
policy applicable to the planned work: [the Ansible house style](ansible.md),
|
|
[the testing house style](testing.md), or both.
|
|
- Update [the MVP roadmap](roadmap/mvp.md) 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](roadmap/features/template.md) and add the same
|
|
identifier to [workspace status](status.md).
|
|
- 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](roadmap/implementation-template.md)
|
|
and always write the current plan to
|
|
[the fixed implementation-plan location](roadmap/implementation.md). 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
|
|
policy reading, behavior, validation, completion criteria, and expected
|
|
commit. Direct the implementing agent to reread the applicable policy
|
|
documents immediately before beginning each stage.
|
|
- Resolve architectural choices during roadmap and plan review. Do not leave
|
|
unresolved design judgment to the implementation agent.
|
|
- Update [workspace status](status.md) 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](decisions/).
|
|
- Use the status values `proposed`, `ready`, `in_progress`, `blocked`, `done`,
|
|
and `deferred`.
|