How work breaks down from product milestone to task.
How the tracker breaks work down, from the biggest outcome to the smallest task. This resolves the earlier overload where "milestone" meant three different things. There are now two clearly distinct milestone levels, with a clean chain down to tasks.
| Level | TroveSnap term | Industry analogue | Spans | "Done" when | Lives in |
|---|---|---|---|---|---|
| 1 | Product Milestone (major) | Release goal / milestone marker | many sprints & phases | all its gates pass | roadmap.json productMilestones |
| 2 | Phase | Epic / workstream theme | many sprints | all its gates pass | roadmap.json phases |
| 2′ | Sprint | Time-box / iteration | one slice of a phase | all its gates pass | derived from owningSprint |
| 3 | Gate (phase gate / acceptance gate) | Exit criterion / Definition-of-Done check | within one phase | its work items are verified | roadmap.json milestones (A1, P1, B1 …) |
| 4 | Work Item | Story / deliverable | one sprint | its tasks done + verify met | status.json sections[].items[] |
| 5 | Task | Subtask / checklist step | hours–days | checked off with evidence | status.json item todos[] |
Cross-cutting (attached at the right level, not a rank): Requirements
(requirements.md, cited per gate), HITL tasks (hitl-tasks.json),
Decisions (decision-log.md), Retrospectives (retrospectives/).
code vs HITL QA) and an optional
cost flag (turns on an API / paid tier). Gates are the unit a sprint
burns down. Formerly (and confusingly) also called "milestones."Rule of thumb: if it would appear on an investor/partner timeline, it's a Product Milestone. If it's an engineering checkpoint a sprint closes, it's a Gate.
Task ✓ → contributes to Work Item %
Work Item verified → satisfies its Gate(s)
Gate passed (evidence) → contributes to Phase %, Sprint %, and Product Milestone %
Product Milestone % = gates passed / gates total (auto, never hand-set)
Start → POC % = all POC-scoped gates passed / total
Every Work Item points up to the Gate(s) it satisfies and the Product Milestone(s) it advances, and down to its Tasks — so nothing floats unattached and progress is always derivable, never manually asserted.
The same work is shown two ways:
Phases and sprints are orthogonal: a phase is what kind of work; a sprint is when it's pulled. A work item belongs to exactly one sprint and maps to gates in one phase.
Queued → In progress → Blocked → Review → Done (plus Deferred).
Queued = planned/ready to pull. Review = built, awaiting human/QA check
(pairs with HITL QA gates). Gates themselves stay todo → in_progress → done
(a gate is passed or not).
The plan (this hierarchy: phases, gates, product milestones, work-item
definitions) stays git-versioned in roadmap.json / status.json. The
activity (status, sprint, owner, and every change with actor + reason) is
planned to live in the triunalabs-internal Supabase project so that
move-to-backlog / move-to-sprint / status changes are dynamic and carry a
who/when/why audit, and HITL human tasks live next to their evidence. Design +
migration: tracking-db-design.md and migrations/0001_internal_tracker.sql
(proposal — not yet applied). Decision D13.