pm-stack(aggregator): overview front door throws on a lined-up task with a non-GitHub ref — reconciledInProgress reaches refUrl unguarded #6205

Problem

The aggregator's overview — the front door at /, served via /frag/overview and /api/overview.json — throws (500 / dead fragment) whenever the orchestration section contains a goal with an in-progress lined-up task whose ref is not a GitHub owner/repo#N ref, or whose title mentions owner/repo#<number> with a number too large to be a safe integer.

Lined-up tasks legitimately carry non-GitHub refs in the real feed (goal ids, bare numbers — the same data reality behind #6174 and #6195), and the feed gate does not check the field: isLinedUpElement (pm-stack/aggregator/src/feed.ts:223-232) validates title/horizon/status/horizonWhy only. LinedUpTask.ref is typed RefKey (pm-stack/aggregator/src/model.ts:640-642) but nothing enforces that promise at the boundary.

Evidence (verified this run, laptop primary @ 36b346f399)

reconciledInProgress (pm-stack/aggregator/src/render.ts:3552, called by deriveOverview at render.ts:3703) walks orchestration.goals[].linedUp:

• render.ts:3592-3593 — if (task.ref) { signal(task.ref, "active-session", task.title); continue; } — no validity check.
• signal → ensure (render.ts:3574) falls back to url: project?.issueUrl ?? item?.url ?? url ?? refUrl(ref) whenever the ref is absent from the pool and the items map (always true for a non-GitHub ref). refUrl → parseRef (model.ts:454-460) throws on anything that is not owner/repo#<safe integer>.
• Second vector, same function: the no-ref title path first routes through refsInText (render.ts:3596), which correctly filters with isValidRef (model.ts:467-484, the shared pm-stack(aggregator): validateNewComment/validateNewAction accept ref keys parseRef rejects (GH_REF number unbounded) #4952 rule) — then the very next loop (render.ts:3597-3599) re-scrapes the title with a raw matchAll(/([\w.-]+\/[\w.-]+)#(\d+)/g) and signals every match without the safe-integer check, re-admitting exactly what refsInText refused.

Call sites have no guard around the throw: server.ts:1329 (/frag/overview), server.ts:1781 (/api/overview.json), and renderOverview (render.ts:3771, the /?full=1 no-JS path).

Probe (bun, real deriveOverview imported from the tree, ~/git/fleet/probe-overview-ref/probe.ts):

Why it matters

The overview is the aggregator's front door — the first page every viewer (and the dashboard's own refresh fragment) loads. One in-progress lined-up task with a goal-id or numeric ref takes the whole overview down for everyone until the orchestrator's next run happens to change the lined-up set; it does not degrade to a missing row. This is a different surface and failure mode from its siblings: #6174 (/today objectives, render.ts:3368), #6195 (board in-flight lane swallowed by a catch, sources/live.ts:634), #4316 (lined-up blockedBy gate → todayFromSection). Same root family: consumers reaching parseRef/refUrl without routing through the shared isValidRef rule (#4952).

Acceptance criteria

• deriveOverview never throws for a feed-valid orchestration section: a lined-up in-progress task with a non-GitHub ref (goal_…, bare number, any other string) produces no in-progress row for that ref (or a row with no GitHub URL), and the rest of the overview renders normally.
• The title-scrape path applies the same validity rule as refsInText (isValidRef, including the safe-integer check) — e.g. by dropping the duplicate raw matchAll loop or guarding its matches — so owner/repo#<unsafe integer> in a title cannot throw either.
• Valid refs behave exactly as today: a lined-up in-progress task referencing a real owner/repo#N (in pool/items or not) still yields an in-progress row with the correct GitHub URL, from both the ref field and a title mention.
• Pinning tests in pm-stack/aggregator/test/overview.test.ts (or a sibling suite) cover: goal-id ref, numeric ref, unsafe-integer title mention, and the valid-ref controls; the aggregator test suite passes.
• Related but out of scope: the feed-gate question (should isLinedUpElement validate ref when present?) is pm-stack(aggregator): /today render 500s on a lined-up task with a non-GitHub ref — objectives call refUrl unguarded and the section gate never checks linedUp ref #6174's layer — do not change gate semantics here beyond what the overview fix needs. Cross-ref pm-stack(aggregator): /board, /api/board.json, /api/overview.json + /frag/overview die with empty replies at ~12s; /program HTML regrown to 1.16MB #5082 (same endpoints, different failure mode: ~12s empty replies) in the fix PR if it touches these handlers.