Delivery
The project's living layer — where we track plan vs. progress and link every shipped thing back to the requirement that asked for it. Kept current every sprint.
What lives here
Phases by customer scale + industry, and when they land.
The 16-group, 74-feature inventory with build status + MVP gate.
Seven epics for the 1–3B band + retail/grocery, code-grounded.
Per module: PRD → ADR → dev → test → runbook. Empty cells = gaps.
Per-cycle health, delivery, risks, actions — verified against code.
What shipped, in human terms, and why.
How the pieces connect
Two co-existing taxonomies
This wiki has two halves. The product/engineering knowledge half (Overview · Modules · Developer · Runbook) is timeless reference. This Delivery half is time-bound — it tracks where we are, what shipped, and what's next.
- The Roadmap says what we intend to build, grouped by business scale and industry. Phase 1 — What Shipped is the detailed done-inventory; Phase 2 — Plan is the next-up epics.
- Each Module hub (
/modules/<tier>/<module>) carries a traceability block linking its PRD, ADRs, dev docs, tests, and runbook. - The Traceability Matrix rolls those up into one coverage table — empty cells are visible gaps.
- Sprint Reviews record each cycle and feed progress back to the roadmap.
- The Changelog is the human-readable record of what actually shipped.
Conventions
Board is verified against code
Sprint reviews follow .agents/workflows/sprint-review.md — board state is reconciled against the codebase before any metric is computed. A closed cycle's review is recorded here as sprint-reviews/YYYY-WKNN.md and mirrored as a Plane Report item. Module/PRD/ADR links follow the module docs convention §6 (stable IDs, reciprocal links).
Related Pages
- Overview — business context and product knowledge
- Modules — per-feature hubs (the spine of traceability)
- Module Docs Structure — ID & linking rules