Roadmap review

Purpose

Produce a dated, source-backed roadmap review across the confirmed project cohort. Surface explicit blockers, alignment gaps, evidence freshness, and unknown status without inventing an aggregate health judgment.

Usage

• /roadmap — review the confirmed roadmap cohort
• /roadmap [pillar] — filter by an exact configured pillar

Evidence, authority, and recovery

Treat the review as an evidence report, not a projection.

• Use the canonical status source and status date from each project record. Record the path/ID, status date, and review as-of time. Filesystem modified time is only a discovery clue, never a replacement status date.
• Cite source evidence for every status, blocker, milestone, pillar, alignment claim, and feedback item. If sources contradict, show both source dates and leave the field Unknown.
• Unknown is distinct from blocked. Use Blocked only when the canonical source explicitly identifies an unresolved dependency preventing progress.
• Define every denominator and disclose excluded projects. If the cohort or status is incomplete, report counts and coverage rather than a percentage or health score.
• Never invent status, dates, blockers, dependencies, milestones, tags, feedback, counts, or health scores.
• Keep analysis read-only. Preview requested changes, require explicit human authority, read back the target, and fail honestly on any mismatch.

Method

1. Confirm scope

Confirm:

• review as-of date and timezone;
• canonical project locations;