Repository navigation
fix(aggregator): item detail pages — empty sections must say why (unresolved ≠ none, fixture comments ≠ no comments) #1500
Description
Problem (observed live, 2026-10-27)
Item detail pages render empty sections that read as facts about the work when they are really facts about the dashboard's resolution path.
Field evidence (aggregator live on the laptop, ~13:56 CDT):
/item/kaneo%3Aopencode%2Fys1ofxfyjl6q5y31kw91an87— a card with 2 linked refs (developing-today/opencode#538,#544) — renders "Linked issues / PRs — none resolved" and "Activity stream — no comments"./api/healthfacets at the same moment:items: live (project pool · fleet feed · 4m old) + fixtures for 412 ref(s) outside the pool;comments: fixtures.- The 65 KB detail page mentions "fixtures" exactly twice — both inside the collapsed footer "source detail"
<details>. The sections themselves carry no cause.
A reader cannot distinguish "this work has no linked issues and no discussion" from "the dashboard cannot resolve them right now". "No comments" is the misleading case: GitHub comment streams are fixture-sourced for every ref while the projector is off (#1199), so the stream can show nothing — or fixture content — while the words on the page claim neither.
Design
In-place honesty on the detail surfaces, keyed off the facet states the page already receives as provenance:
- Linked issues / PRs — when resolution is partial, the section header carries the tally and the cause:
2 linked · 0 resolved — resolution fell back to fixtures (projector off, #1199). When every ref resolves, no banner (no false alarms). - Activity stream — when the comment facet is fixture-sourced, an in-place banner above the stream says so, and the empty wording becomes
no comments loaded — the comment stream is fixture-sourced while the projector is off (#1199), never a bare "no comments". - Same treatment for
/discuss/<ref>when its thread includes fixture-sourced GitHub comments.
Implementation path
renderItem in src/render.ts already receives provenance; thread the items/comments facet states (live / partial-fixtures / fixtures) through the /item route in src/server.ts (they are computed in src/sources/live.ts today and surface via /api/health). Wording keyed off facet state only — no new data plumbing, no dependency on the #1199 decision: whichever way #1199 lands (deploy or retire), the page must say what its sections are made of.
Acceptance
- With the projector off, the example card above states the resolution tally + cause inside the Linked issues section, and the Activity stream names its fixture sourcing in place.
- A fully pool-resolved card shows no banner and no tally caveat.
- Tests in the style of
test/dashboard-overhaul.test.tscover both facet states for both sections.
Related, not duplicates: #1199 (deploy-or-retire decision for the projector itself), #1141 (raise pool resolution coverage + publish the ratio — this issue is the rendering side that stays necessary at any coverage < 100%).
Activity
developing-today commentedon Oct 27, 2026
CODE-565
dezren39 commentedon Oct 27, 2026
Intake review
Related, not duplicates: #1199 (projector deploy-or-retire decision), #1141 (resolution coverage). Liveness: no merged PR threads facet states into
renderItem— checked merged aggregator PRs through 2026-10-27; issue is live. Its## Acceptancesection is complete in substance, so no duplicate was appended.Notes / risks / suggested approach: Risk: wording must key off facet state only — no banner on a fully pool-resolved card (no false alarms). Suggested approach: thread items/comments facet states from
src/sources/live.tsthrough the/itemroute; add tests in the style oftest/dashboard-overhaul.test.tsfor both facet states.🤖 Agent note · filed
/discuss/<ref>).dezren39 commentedon Nov 1, 2026
agent-note:v1 — queue task 2600 (lane E) — triage verdict: CONFIRMED on current main
Verified 2026-11-01 against origin/main 0ea0a0f:
pm-stack/aggregator/src/render.ts:1685still renders the Linked issues/PRs empty state as a barenone resolved, and:1687the Activity stream empty state as a bareno comments— unconditionally, with no reference to facet state.fixture-sourcedandno comments loadedappear nowhere in render.ts, and the facet states (live / partial-fixtures / fixtures, computed in sources/live.ts and already surfaced via /api/health) are not threaded into the section wording.Route: scoped implementation packet enqueued as queue task 5017 (small_fix), following the implementation path the issue itself specifies: thread facet states through the /item route into renderItem, tally+cause in the Linked header, fixture banner + honest empty wording in the Activity stream, same treatment on /discuss/, wording keyed off facet state only (no dependency on the #1199 decision).
dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 1, 2026
🤖 Agent note · blocked (packet defect)
render.ts:1948,1950); no matching PR found. The packet requirespartial-fixtures, butProvenanceFacet.statehas no such member and mixed live+fixture provenance is currently classified aslive(model.ts:207–217,sources/live.ts:1222–1236). The packet also forbids new data plumbing, so intended state semantics are unclear.dezren39 commentedon Nov 3, 2026
agent-note:v1
event: blocked (packet defect)
task: 6846 (repo-health-code-pilot, repo-worker-code; OpenChamber scheduled lane c8b9355e-319a-4640-8096-7ad19480d151)
state: re-triage confirms issue is live but the implementation packet is not actionable as written; no code/worktree changes.
verified: Fresh 2026-11-03: #1500 OPEN/status/blocked+queue/blocked; related #1199 CLOSED; no open matching PR. On main b7ee423, aggregator/src/render.ts:2075-2076 still emits and . in src/model.ts:208 is only live|fixtures|stale|absent|invalid|error; live.ts classifies facet state from its text and does not distinguish mixed live/fixture refs. Prior task 5017 documented this same defect.
blocker: Acceptance requires partial linked-ref tally/cause and uses partial-fixtures semantics, but the available type/classifier does not represent partial coverage; implementation path simultaneously says existing facets suffice/no new plumbing. A corrected packet needs to choose and specify (a) adding partial provenance state/classification, or (b) deriving resolution coverage per ref from fetched maps, and reconcile the no-new-plumbing constraint. This triage task will not invent that contract.
labels: preserving status/blocked + queue/blocked; removing stale work/assigned because no worker holds implementation work.
resume: after packet/spec is clarified, enqueue a corrected implementation task and revalidate fresh.
bookkeeping: sandbox backlog and sweep log deferred to fleet reconciliation.
dezren39 commentedon Nov 3, 2026
Correction to the preceding agent note (shell quoting damaged inline code spans only; the evidence and blocker remain unchanged):
agent-note:v1
event: blocked (packet defect) — clarification
task: 6846 (repo-health-code-pilot, repo-worker-code; OpenChamber scheduled lane c8b9355e-319a-4640-8096-7ad19480d151)
verified: On main b7ee423, pm-stack/aggregator/src/render.ts:2075-2076 still emits “none resolved” and “no comments”. pm-stack/aggregator/src/model.ts:208 defines ProvenanceFacet.state as live|fixtures|stale|absent|invalid|error; pm-stack/aggregator/src/sources/live.ts classifies facet state from its text without distinguishing mixed live/fixture refs.
blocker: The packet requires partial linked-ref coverage and partial-fixtures semantics, but no such state exists; the implementation path also says existing facets suffice/no new plumbing. A corrected packet must specify whether to extend facet classification or derive resolution coverage per ref from fetched maps, and reconcile the no-new-plumbing constraint.
labels: status/blocked + queue/blocked retained; stale work/assigned removed.
resume: after packet/spec clarification, enqueue a corrected implementation task and revalidate fresh.
bookkeeping: sandbox backlog and sweep log deferred to fleet reconciliation.
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 6846 (triage, blocked, priority 40) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03