Roadmap usage audit — the public story lags reality

2026-07-11 · audit window 2026-07-08 → 07-11 · roadmap.html vs. what actually shipped · read-only: no stage or issue state was changed by this audit

Development lane: empty most of 07-11 actual: 21 PRs merged, 3 releases, 4 agents

Trigger. On the evening of 2026-07-11 — the day safety.viz v1.0.0 (22:31 EDT) and obot.agent v0.1.0 (21:42 EDT) both shipped, with four agents concurrently running builds — @jwildfire opened the public roadmap page and found nothing "In Development". The page was not broken: it faithfully rendered a board that nobody had updated while the work ran. This report explains the mechanism, reconstructs the gap with specifics, names the root causes, and lists corrections (tier 1, not applied — awaiting @jwildfire) and practice changes (tier 2), flagging what belongs in the session-hub requirement (#24).

1 · How roadmap.html decides "In Development"

The page is generated at deploy time by scripts/build_roadmap.mjs (never committed; rebuilt by .github/workflows/deploy-site.yml on every push to main touching site/ diary/ reports/ scripts/ requirements/design/, plus daily at 10:00 UTC). A row appears in the Development section if and only if:

It is an issue in jwildfire/obot.roadmap carrying the requirement label — issues in implementation repos (safety.viz, obot.agent, gsm.safety) never render, and neither do hub issues without the label (e.g. #23, which sat at board-Status "Development" all afternoon, invisibly); and
Its item on the obot Roadmap user project has the single-select Status field set to "Development", read via the ROADMAP_TOKEN secret (confirmed working: the live page reflects board Status, including open issues shown as Released).

The only signal is the manually-set board field. No PR, merge, commit, release, sub-issue state, or agent activity feeds the page. If no human or agent moves the Status field, the page cannot know work is happening. Two secondary signal losses compound it: the Tasks column parses only inline ### Tasks checkboxes in the requirement body (it cannot see sub-issues — yet the requirement-tasks skill makes sub-issues the canonical task tracker), and "Released / closed" items collapse into a folded <details> at the bottom of the page, out of sight.

Fallback worth knowing: without a readable Status the script groups by issue state + milestone (stageOf()), a scheme in which "Development" is unreachable. That fallback was not the cause here — the token works — but it means a token regression would silently empty the Development lane forever.

2 · What actually happened, 07-08 → 07-11

Repo	PRs merged	Issues closed	Releases	Notes
safety.viz	15 (#3, #4, #9–#13, #16, #18, #22, #23, #28, #30, #31, #36)	18 (#1, #2, #5–#8, #14, #15, #17, #19–#21, #24–#27, #29, #34)	v0.1.0 07-11 08:04 EDT v1.0.0 07-11 22:31 EDT	Ultraplan fan-out: five new renderers, evidence framework, docs-site v1.0, binning QC — issues #14–#35 all opened and mostly closed inside the window
obot.agent	6 (#10, #11, #16, #17, #19, #20)	3 (#12, #13, #18)	v0.1.0 07-11 21:42 EDT (rc1 promoted same evening)	Full gsm.agent-overlay conversion; session-hub PR #24 open implementing issues #21–#23
obot.roadmap	0 (direct commits to main, per the standing grant)	2 (#23, #26)	v0.2 07-10 21:33 EDT	Issues #23–#27 opened; designs #17 and #24 published; skills adopted then handed to obot.agent; 3 reports + session-report exemplar added
gsm.safety	0	0	—	Quiet; #27/#28/PR #29 added to the board 07-10 (Backlog/Review)

Four agents were active late 07-11: the safety.viz release build (hub #1), the obot.agent release (hub #17), demo-data migration research (hub #25), and the devops-dashboard requirement design (hub #24).

What the page said meanwhile

Reconstructed from site/roadmap-changelog.json and diary entries:

When (EDT)	Board event	Page's Development lane after deploy
07-08 (logged 07-09, v1.2.0)	#1, #3 → Review	#2 only (held by the done-gate)
07-10 ~21:53 (v1.3.0)	#1, #3 Review → Released ("scoped deliverable shipped"; issues left open)	#2 only
07-11 ~08:41 (v1.4.0)	#2, #21 → Released (v0.1.0 shipped)	Empty
07-11 ~13:10 (v1.5.0)	#17 Requirement Gathering → Review (skipping Design and Development); #23 → Development (not requirement-labeled — invisible); #24 added at Requirement Gathering	Empty
07-11 evening (unlogged)	#24 → Development	#24 only (page regenerated 22:59 EDT)

So for the whole shipping day the Development lane showed zero requirements, and by ~23:00 exactly one — the session-hub requirement — while neither of the two requirements that actually shipped releases appeared as active anywhere above the fold.

3 · Gap analysis — five specific examples

#	Gap	Detail
1	Hub #1 (safety.viz) filed under "Released" during its biggest development day	Moved Review → Released at the 07-10 wrapup on a "scoped deliverable (library scaffold) shipped" rationale, issue left open. Then 12+ PRs merged and two releases (v0.1.0, v1.0.0) shipped under it on 07-11 while the page showed it inside the collapsed "Released / closed" fold. Its Tasks column reads `0/1`; only 1 of ~20 implementation issues (safety.viz#1) is linked as a sub-issue — safety.viz #2, #5–#8, #14–#35 are all unlinked.
2	Hub #17 (obot.agent) skipped Development entirely	One move, Requirement Gathering → Review, at the 07-11 13:10 wrapup — by the time anyone touched the stage, the design was approved and the three stacked implementation PRs were already in review, so the Development stage never existed on the public page. v0.1.0 then shipped at 21:42 EDT with the board still saying Review. Page Tasks: `0/5` despite 3 of 5 sub-issues closed (inline checkboxes never ticked). Sub-issue obot.agent#18 (docs refresh, closed via PR #19) was never linked.
3	Hub #21 (docs site) built entirely while marked "Requirement Gathering"	Its whole implementation — safety.viz #5–#8, four PRs, 07-09 → 07-11 — ran while the board said Requirement Gathering (added 07-09, v1.2.0). It jumped straight to Released at the 07-11 morning wrapup, never passing Development or Review. Page Tasks still shows `2/4` though all four sub-issues are closed.
4	19 of 52 board items have no Status at all	Work items get added to the board (a good instinct — diary 07-10/07-11 records the adds) but `gh project item-add` sets no Status, so safety.viz #20–#27, #29–#35 and obot.agent #12–#15 sit in no lane on the board — and being non-hub issues they never render on the page regardless. Board Status totals: 19 none, 14 Released, 8 Backlog, 6 Review, 3 Requirement Gathering, 2 Development.
5	Stage-semantics drift and unlogged moves	"Released" (lifecycle stage 6: "included in a quarterly release") is being applied to open requirements at first ship — #1, #2, #3, #21 are all OPEN issues in Released, which is what evicted #1 from the active lanes. Hub #23 is CLOSED but its board Status still says Development. #24's move to Development happened without the changelog entry AGENTS.md requires for stage moves. Meanwhile the one workstream tracked correctly — #24 itself: design published, five sub-issues linked, moved to Development as its PR opened — proves the lifecycle works when it's driven.

Sub-issue linkage scorecard

Requirement	Linked sub-issues	Missing
#1 safety.viz	1 (safety.viz#1)	safety.viz #2, #5–#8, #14–#35 (~20 issues — the entire v0.1 → v1.0 arc)
#17 obot.agent overlay	5 (obot.agent #12–#15, hub #23)	obot.agent #18
#21 docs site	4 (safety.viz #5–#8)	— complete
#24 session hub	5 (obot.agent #21–#23, hub #26, #27)	— complete (the model citizen)
#25 demo data	0	safety.viz #35 (the demo-data refactor issue it spawned from)

4 · Root causes

Stage moves are a wrapup-only, approval-gated ritual. The only documented place stages move is phase 3 of the session-wrapup skill ("apply the agreed changes — issue updates, stage moves…"), after interactive discussion with @jwildfire. Nothing in the development loop — tdd, opening a PR, merging, tagging a release — touches the board. On a day when four agents outrun the wrapup, the public page necessarily trails reality by up to a full session; and because wrapups batch the moves, requirements teleport across stages (#17: Requirement Gathering → Review; #21: Requirement Gathering → Released) rather than dwelling in Development where observers would see them.
"Released" was redefined downward. Moving #1/#3 (07-10) and #2/#21 (07-11) to Released while leaving the issues open — "scoped deliverable shipped" — removed them from every visible lane just before the largest push. The lifecycle table has no answer for a requirement that spans multiple releases, so the board improvised one that hides active work.
The page reads a different signal than the one agents actually maintain. Agents diligently update issues, PRs, sub-issues, evidence comments, and releases — the page reads none of those. It reads one manual field (project Status) plus inline body checkboxes that sub-issue-based tracking has obsoleted. High-fidelity work signals exist; the page is wired to the lowest-fidelity, least-maintained one.

In one sentence: the roadmap page renders only the hand-moved board Status of hub requirement issues, and the only ritual that moves that field is the end-of-session wrapup — so on a day when the work outran the wrapup (and "Released" had already been applied to the open safety.viz requirement), the public page showed an empty Development lane while 21 PRs merged and two releases shipped.

5 · Recommendations

Tier 1 — immediate corrections (not applied; each is one board/issue action awaiting @jwildfire)

Hub #1: board Released → Review, with a v1.0.0 evidence comment. Then decide: close it as delivered (re-filing the open remainder — safety.viz #32/#33/#35 — under a follow-on requirement or #25), or keep it in Review until the v1.0 sign-off. An open requirement should not sit in Released.
Hub #17: v0.1.0 shipped with sign-off — move Review → Released and close, re-homing the two open sub-issues (obot.agent #14 upstream staging, #15 stylesheet) — e.g. under hub #18 or as standalone board items. Alternatively hold in Review if a formal post-release review is wanted; either way the stage should record the decision, not the backlog of one.
Hub #23 (closed): board Development → Released (or Done).
Set a Status on all 19 no-status board items: closed ones (safety.viz #20/#21 issues, #22–#27, #29, #31, #34; obot.agent #12/#13) → Released; open in-flight ones (obot.agent #21–#23 are already Review via a later add — verify; safety.viz #32/#33/#35, obot.agent #14/#15) → Backlog or Development to match reality.
Link the missing sub-issues: safety.viz #2, #5–#8, #14–#35 → hub #1 (or at minimum the v1.0-cycle set #14–#35); obot.agent #18 → hub #17; safety.viz #35 → hub #25.
Sync the inline Tasks checklists in #17, #21, #24 (and #1 if kept open) to sub-issue state — or replace each with a one-line pointer to the sub-issue list, since the page can't read sub-issues yet (see tier 2).
Log the corrections: one site/roadmap-changelog.json patch entry covering #24's unlogged Development move plus whatever subset of the above is applied.

Tier 2 — practice and process changes

Move stages at work boundaries, not wrapups. Adopt one rule: a requirement moves to Development when its first implementation PR opens (or its first sub-issue goes in progress), to Review when the last planned PR merges and evidence posts, to Released only when the release is tagged and signed off — at which point the issue closes. Wire it into the working skills: kickoff (session-init flags any requirement about to be worked that isn't in Development), the tdd/PR-open step (move the parent), and release tagging. Wrapup then verifies stages instead of being the only thing that moves them.
Fix the Released semantics. Either scope requirements per release (close #-style: v0.1 requirement closes at v0.1, a new requirement carries v1.0) or allow explicit regression (Released → Development re-opens the lane when a new cycle starts under the same requirement). Pick one; the current improvisation hides work.
Board adds always set a Status. Every gh project item-add is immediately followed by a Status edit; "(no status)" is treated as a lint error at wrapup.
Sub-issue linking at creation time. When an agent files implementation issues for a requirement (the ultraplan filed 8 in one evening), linking them to the parent via the sub-issue-linking skill is part of filing, not cleanup.
Teach the page to read the signals agents maintain (small build_roadmap.mjs changes, independent of #24): render sub-issue progress via the GraphQL subIssuesSummary instead of (or alongside) inline checkboxes; show open-PR / recent-merge counts on each requirement row as an activity hint; and un-fold "Released / closed" entries that are still open issues so a mis-staged requirement stays visible.

What belongs in hub #24 (session hub) scope

The findings that are live-activity problems, not lifecycle problems, belong in the session-hub requirement its sibling agent is designing now:

The "who is building what right now" layer. roadmap.html is the intent view (lifecycle lanes); the session hub's live dashboard is the activity view (agents ↔ requirements ↔ PRs). Wiring a "live" badge onto a roadmap row when the hub reports an active session on that requirement would have answered tonight's question at a glance.
Stage-drift detection. The wrapup report (and live mode) can compute exactly what this audit computed by hand: board Status vs. sub-issue/PR/release state, no-status board items, unticked Tasks, unlinked sub-issues — surfaced as a drift list the wrapup's phase-3 discussion resolves. Wrapup already has a "stage correct?" checklist item; #24 can make it evidence-driven instead of recall-driven.
Optionally, the automation hook for the "Development on first PR" rule — a small event-driven action fits #24's collectors better than the static site generator.