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.
Live progress
Live progress from Plane (read-only) · synced 2026-06-14
This is the live progress of the open cycle. The recorded numbers for closed cycles - not the ~100% post-cleanup reading - are in the sprint reviews.
What lives here
Phases by customer scale + industry, and when they land.
The 16-group, 74-feature inventory - all Phase-1 features shipped.
Twelve epics for the 1-3B band + retail, code-grounded.
Per module: PRD → ADR → dev → test → runbook. Empty cells = gaps.
Per-cycle health, delivery, risks, actions - verified against code.
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 - Delivered 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.
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