Four goals, seventy-four open issues, and a forty-five-issue gap between them. This part grades the coverage of each existing goal, then proposes the goals that would close the gap — with the rosters that would roll up under them.
Keep all four goals — none of them is wrong. Add three: the workbench, the shared chart product, and the evidence foundation. Then link nine issues that already belong to goals that exist. That takes goal coverage of open work from 39% to 100% without inventing a single new piece of work, and it makes the --auto selection surface match the roadmap a human would describe out loud.
Coverage means: of the open issues that plainly belong to this goal's subject, how many can be reached from the goal issue by following sub-issue links?
Working. Eighteen members, real depth, and the boundary prose already does useful work: it names the done-gate, it says new chart ideas are filed rather than built, and it says what "done for the summer" looks like. This is the goal the others should be modelled on.
Two gaps. First, six chart requirements that are unambiguously in scope and already moving are not linked: hub#29, hub#43, hub#45, hub#2, hub#81, sv#99. Second, the goal's own title says "adding charts" — and roughly a dozen open issues are about making the charts already added behave like one product. Those are not additions, and #78 correctly does not claim them. That is proposal G6 below.
Correctly empty, and that is the problem. Its single member is hub#34, the design discussion that gates everything else, and its boundary prose says so: until D1 lands and the Phase 1–4 requirements are filed, every increment is pipeline-advancement. The goal is honest. But it means the app arc — a headline goal of the September story — is a single unresolved decision issue with nothing queued behind it, and the decision has been open since 2026-07-12.
The unblock is not more goals; it is filing the phase requirements the plan already describes. Part 3 proposes eight, starting with the two that do not depend on D1 at all: the obotclaw App install on open.gismo (the goal names it as a hard prerequisite) and the safetyGraphics feature-parity matrix (which the word "replacement" is currently doing without).
Working, with a boundary worth tightening. Six members, two already closed and shipped. The scope prose is specific — harden the --auto lane, triage v2, broader grants, a /goal command — and two of the named futures (grant-matrix expansion, the /goal command) have no issue yet.
The seam: this goal is about how much runs unattended. Sixteen open issues are about the machine the sessions run on — the dashboard, the diary renderer, the merge and release lanes, roadmap transparency, the bot's identity and avatar. Those make autonomy possible but they are not autonomy, and folding them in would make #73's boundaries meaningless. That is proposal G5.
Under-linked, not under-scoped. One member (hub#74, the live demo). Its own body lists candidate children — deck outline, deck build, rehearsal — and one of them already exists as an issue: hub#10, the deck requirement, filed since the hub migration. The blog series hub#22 is the deck's declared source material and is also unlinked.
This is the cheapest fix on the page: three sub-issue links turn a one-member goal into a four-member goal with a Development-stage item in it, and the roadmap starts telling the September story.
Three. Each is drafted as it would be filed — title, intent, boundaries, and the exact roster of existing issues that would roll up under it. None of these creates work; all of them are already-open issues that currently answer to nobody.
Draft title: Goal: build the workbench — the session framework obot works inside
Intent. Make the tools obot uses to do the work as deliberate as the work itself: the session framework and its bookends, the live dashboard and the wrapup report, the roadmap's own honesty about what is happening, the merge and release lanes, and the identity the bot acts under. The test is @jwildfire's time — every increment here should reduce the number of things he has to check by hand.
Boundaries. This goal owns tooling and process infrastructure; hub#73 owns how much of it runs unattended. When an item is about a lane's capability it belongs here; when it is about a lane's grant it belongs to autonomy. The policy carve-out still applies: anything touching grants, goals or merge policy waits for @jwildfire regardless of which goal it hangs from. Site and roadmap-page work belongs here; renderer documentation does not (that is G7).
Would roll up (16 open): hub#24 session hub · hub#27 diary tabs · hub#31 roadmap transparency · hub#44 unreleased-commits view · hub#48 idea queue · hub#69 Reviewer Notes · hub#76 bot avatar · hub#77 dashboard chat · hub#91 fast session startup · hub#94 release summaries · hub#3 obot GitHub App · hub#103 audit decisions · oa#14 upstream contributions · oa#32 report date flag · oa#36 release skill · oa#37 merge-lane hardening
Why it is the strongest of the three: it is the largest unclaimed cluster, it spans two repos, it contains a Review-stage requirement and a Development-stage requirement, and hub#31 already describes obot.agent's charter in exactly these terms — orchestration, session management, scaffold CI.
Draft title: Goal: make the charts one product — shared interaction across the safety.viz renderers
Intent. Nine renderers shipped as nine modules. A reviewer moving between them should not have to relearn how to select a participant, toggle a series, or read a legend. This goal is the shared layer: selection, legends, chrome, cross-chart navigation, and the defects that show up only because the modules were built one at a time.
Boundaries. No new charts — that is hub#78. Work here changes how existing renderers behave together, which means it touches many modules at once and needs the full evidence gate on each: a shared-component change is not done until every renderer that consumes it still passes. Bugs that are local to one renderer stay with that renderer's requirement; bugs caused by the absence of a shared component belong here.
Would roll up (10 open): sv#87 shared participant selector · sv#88 selection note · sv#83 click-to-filter legends · sv#84 legend toggle defect · sv#86 All Measures overview · sv#41 renderer chrome mockups · sv#33 cross-module data handling · sv#104 duplicated placebo-arm bug · hub#98 brush multiselect · hub#83 waterfall legend
The alternative is widening #78's title to "build and improve the charts" and letting it hold both. That is simpler, and it is defensible — but #78 already has eighteen members and a boundary rule that prefers small well-scoped items at night. Merging twelve more into it makes the largest goal on the board harder to select from, and erases the distinction between "we shipped a new renderer" and "the renderers finally agree with each other" — which is exactly the distinction the keynote wants to draw.
Draft title: Goal: evidence you can trust — demo data, documentation, and QC for the chart portfolio
Intent. The portfolio's claim is not "we made charts", it is "we made charts a regulated industry can check". That claim rests on things that are not charts: realistic demo data, a docs site that stays current, requirement-traceable test evidence, per-renderer user guides, and QC reporting a reviewer recognizes. This goal owns them as a workstream rather than as the tail of whichever renderer needed them last.
Boundaries. Owns data, docs, fixtures, evidence tooling and QC reporting across the chart repos. Does not own renderer behavior. The done-gate for renderers stays with the chart goals — this goal exists so the gate has something to stand on, not to move the gate. Anything requiring clinical judgment about what demo data should show gets @jwildfire's sign-off before it becomes a fixture.
Would roll up (10 open): hub#25 canonical demo data · sv#35 pharmaverse ADaM pipeline · sv#89 real hepatic signal · hub#15 qcthat QC reporting · hub#21 docs site · hub#32 hep-explorer user guide · hub#33 legacy tracker mining · sv#32 site-generator hardening · sv#51 tooling gaps · sv#109 stale e2e fixtures
The weakest of the three, and worth saying so. Its members are heterogeneous — demo data and a Word-to-HTML user guide are not obviously the same goal — and a selecting session might reasonably find it hard to prioritize inside. If only two new goals are wanted, G7 is the one to defer: its data items could hang from G6 and its docs items from G5. The argument for keeping it separate is that this is the workstream the keynote's credibility rests on, and it is the one that silently loses to renderer work every single time.
Nine issues that belong to goals that already exist. These are sub-issue links, not decisions.
hub#10 the deck requirement · hub#22 the developer-diary blog series · oa#15 the shared keynote stylesheet.
#72's own body names the deck and the diary as its material. #10 is the deck. Linking them costs nothing and puts the September story on the roadmap.
hub#29 v1.3 remaining renderers · hub#43 abnormal-baseline DILI tools · hub#45 participant profile · sv#99 lab-family dock rollout · hub#2 histogram migration · hub#81 close out the histogram fork.
All six are chart work by any reading. Three are in Development right now, which means the largest active workstream in the portfolio is invisible to goal-driven selection.
Three goal issues filed from the existing template, thirty-six sub-issue links, and one registry decision. No requirement is rewritten and no work changes hands. The result is that every open issue in the portfolio answers to a goal, which is the precondition for hub#87's weekly goal review to be a review of something rather than a review of 39% of something.
If only one change is made tonight, make it the six chart relinks — they are pure bookkeeping and they unblock goal-driven selection on the work that is actually in flight.