docs(roadmap): mark the v0.11 phase list complete — phase-table header + phase 0 status (shipped as v0.10.6)
The v0.11 phase-list header still read "active" and phase 0's Status cell still read "active" after the milestone shipped, so the repo's own record contradicted itself: the Overview read COMPLETE, phases 1-6 read complete, and the table two lines below them read active. The ship commit5bc899eef3flipped the Overview entry and the P6 verdict row and left the phase table behind — a reader of the phase table alone sees a live v0.11 on a line whose next milestone is not scoped yet. Evidence (read at source, 2026-10-27): - .ciagent/ROADMAP.md Overview: "Milestone v0.11 — COMPLETE (shipped as v0.10.6, 2026-10-22)". - .ciagent/REQUIREMENTS.md header: "v0.11 Requirements (Complete — Placement Tracking and Audit, Feature; shipped as v0.10.6)". - Tags v0.10.0 (8684d9d60c) .. v0.10.6 (85ddf5ea22) exist; release v0.10.6 published 2026-10-22T04:41:47Z. - main tipf4a35afbc9— "chore(P06): clear checkpoint — milestone v0.11 complete". Changed: 2 lines, 3 cells, status markers only. - "### v0.11 (active)" -> "### v0.11 (complete — shipped as v0.10.6, 2026-10-22)"; the sibling headers read "### v0.8 (complete)" and "## Phase List (v0.10 — complete)". - Phase 0 Status "active" -> "complete (v0.10.0)" — P0 -> v0.10.0 on the milestone's own tag line; the v0.10 table's phase 0 reads "complete (v0.9.0)". - Phase 0 success-criteria cell gets the same "complete (shipped as v0.10.0)" marker the v0.10 table's phase 0 carries. Blast radius: documentation only, one file (.ciagent/ROADMAP.md). No code, no dependency, no config, no shipped artifact, no requirement or phase touched. The milestone's scope is not rewritten — the cells now say what the tag, the release and git history already say. Never silently rewritten: every flip rides this auditable commit and the merge request that carries it.
This commit is contained in:
+2
-2
@@ -38,11 +38,11 @@ Payment processing and subscription management (REQ-F-018 activated per D-074, a
|
||||
|
||||
## Phase List
|
||||
|
||||
### v0.11 (active)
|
||||
### v0.11 (complete — shipped as v0.10.6, 2026-10-22)
|
||||
|
||||
| # | Name | Status | Depends On | Requirements | Success Criteria |
|
||||
|---|------|--------|------------|--------------|------------------|
|
||||
| 0 | Pre-execution | active | — | — | Specify (D-098), clarify, research, plan, grill, MVP/UX check |
|
||||
| 0 | Pre-execution | complete (v0.10.0) | — | — | Specify (D-098), clarify, research, plan, grill, MVP/UX check complete (shipped as v0.10.0) |
|
||||
| 1 | Placement store + evidence ledger | complete (v0.10.1) | 0 | REQ-11-001 | `ai_service/placements/` module: 9th D-027 store (PlacementRow + PlacementEventRow, hash-chained append-only ledger), evidence resolved from source rows only (G-302 doctrine), `create_all` idempotent on the shared DB file, Protocol + SQLite pair |
|
||||
| 2 | Application state machine | complete (v0.10.2) | 1 | REQ-11-002 | Employer routes extend the v0.6 application status from submitted-only to the full hiring lifecycle; claimed-entity authorization (403 cross-entity, G-311 gate order); every transition ledger-logged; hired creates the placement; admin oversight retained |
|
||||
| 3 | Placement reporting | complete (v0.10.3) | 2 | REQ-11-003 | Aggregate counts from the ledger (per employer, per cohort month, cumulative toward ≥1,000); employer dashboard placements section; learner outcome states; admin network overview counts |
|
||||
|
||||
Reference in New Issue
Block a user