Context
apps/loopover-miner-ui/src/lib/demo-data.ts (#5963 / PR #7209) provides the VITE_DEMO_MODE=1 fixture
layer that lets the dashboard run with zero real backend. Two of its fixtures describe the same
portfolio queue from two different angles, and they disagree:
DEMO_PORTFOLIO_QUEUE_SUMMARY (consumed by routes/portfolio.tsx's PortfolioQueueView via
fetchPortfolioQueue) reports byStatus: { queued: 9, in_progress: 3, done: 15 } — i.e. 18
actionable (in_progress + done) items exist across the fleet.
DEFAULT_DEMO_PORTFOLIO_QUEUE_ITEMS (consumed by routes/portfolio.tsx's
PortfolioQueueActionsSection via fetchPortfolioQueueItems) only lists 4 actionable items (2
in_progress, 2 done).
In the real (non-demo) system these two numbers are meant to agree: vite-portfolio-queue-actions-api.ts's
items-get route returns store.listQueue() filtered to in_progress/done — i.e. every actionable
row, the same rows the dashboard-summary aggregation counts. A real operator with 3 in-progress + 15 done
items would see all 18 in the "Queue actions" table (paginated at PAGE_SIZE = 20, so still on one page).
A demo visitor instead sees status cards claiming "In progress: 3, Done: 15" directly above a table that
only ever contains 4 rows — a visible, internally-inconsistent demo that undercuts exactly what #5963's
demo-mode work is for (giving people something real to point at).
demo-data.test.ts already has a test asserting DEMO_PORTFOLIO_QUEUE_SUMMARY's per-repo totals sum to
its own fleet total (so the summary fixture is internally consistent) but nothing cross-checks the
summary against the separate actionable-items fixture.
Requirements
DEFAULT_DEMO_PORTFOLIO_QUEUE_ITEMS in apps/loopover-miner-ui/src/lib/demo-data.ts must contain
exactly as many in_progress entries as DEMO_PORTFOLIO_QUEUE_SUMMARY.byStatus.in_progress (3) and
exactly as many done entries as DEMO_PORTFOLIO_QUEUE_SUMMARY.byStatus.done (15) — 18 items total.
- Every added item must reference one of the four repos already used elsewhere in
demo-data.ts
(acme/widgets, acme/api-gateway, acme/docs-site, northwind/inventory) with a plausible,
synthetic identifier (matching the existing wgt-2451/gw-118/inv-77-style pattern) — no new repo
names, no real repo/org names anywhere in the fixture (per this file's own "entirely synthetic" rule).
Per-repo counts do not need to reconcile with DEMO_PORTFOLIO_QUEUE_SUMMARY.repos[].byStatus (that
breakdown includes queued items, which PortfolioQueueActionItem cannot represent — only the
fleet-wide in_progress/done totals need to match); do not attempt to force per-repo parity.
resetDemoDataForTest's restore-to-defaults behavior must continue to work unchanged against the
expanded fixture.
Deliverables
Test Coverage Requirements
apps/** is outside this repo's Codecov coverage.include scope (confirmed in PR #7082's own body), so
this is not gated by codecov/patch. The actual bar is apps/loopover-miner-ui's own Vitest suite
(npm test in that workspace) passing, plus the new regression test above actually failing against the
current 4-item fixture before the fix and passing after.
Expected Outcome
A VITE_DEMO_MODE=1 build of the dashboard shows a "Queue actions" table whose row count matches the
status-card numbers directly above it, on both the Portfolio route and (indirectly, via the same fixture)
anywhere else the demo data is consumed — no visible self-contradiction in the demo.
Links & Resources
apps/loopover-miner-ui/src/lib/demo-data.ts, apps/loopover-miner-ui/src/lib/demo-data.test.ts,
apps/loopover-miner-ui/src/routes/portfolio.tsx (PortfolioQueueView / PortfolioQueueActionsSection),
apps/loopover-miner-ui/vite-portfolio-queue-actions-api.ts (items-get's real, unfiltered-by-count
behavior), #5963 (the demo-mode epic this fixture layer serves).
Context
apps/loopover-miner-ui/src/lib/demo-data.ts(#5963 / PR #7209) provides theVITE_DEMO_MODE=1fixturelayer that lets the dashboard run with zero real backend. Two of its fixtures describe the same
portfolio queue from two different angles, and they disagree:
DEMO_PORTFOLIO_QUEUE_SUMMARY(consumed byroutes/portfolio.tsx'sPortfolioQueueViewviafetchPortfolioQueue) reportsbyStatus: { queued: 9, in_progress: 3, done: 15 }— i.e. 18actionable (
in_progress+done) items exist across the fleet.DEFAULT_DEMO_PORTFOLIO_QUEUE_ITEMS(consumed byroutes/portfolio.tsx'sPortfolioQueueActionsSectionviafetchPortfolioQueueItems) only lists 4 actionable items (2in_progress, 2done).In the real (non-demo) system these two numbers are meant to agree:
vite-portfolio-queue-actions-api.ts'sitems-getroute returnsstore.listQueue()filtered toin_progress/done— i.e. every actionablerow, the same rows the dashboard-summary aggregation counts. A real operator with 3 in-progress + 15 done
items would see all 18 in the "Queue actions" table (paginated at
PAGE_SIZE = 20, so still on one page).A demo visitor instead sees status cards claiming "In progress: 3, Done: 15" directly above a table that
only ever contains 4 rows — a visible, internally-inconsistent demo that undercuts exactly what #5963's
demo-mode work is for (giving people something real to point at).
demo-data.test.tsalready has a test assertingDEMO_PORTFOLIO_QUEUE_SUMMARY's per-repo totals sum toits own fleet total (so the summary fixture is internally consistent) but nothing cross-checks the
summary against the separate actionable-items fixture.
Requirements
DEFAULT_DEMO_PORTFOLIO_QUEUE_ITEMSinapps/loopover-miner-ui/src/lib/demo-data.tsmust containexactly as many
in_progressentries asDEMO_PORTFOLIO_QUEUE_SUMMARY.byStatus.in_progress(3) andexactly as many
doneentries asDEMO_PORTFOLIO_QUEUE_SUMMARY.byStatus.done(15) — 18 items total.demo-data.ts(
acme/widgets,acme/api-gateway,acme/docs-site,northwind/inventory) with a plausible,synthetic
identifier(matching the existingwgt-2451/gw-118/inv-77-style pattern) — no new reponames, no real repo/org names anywhere in the fixture (per this file's own "entirely synthetic" rule).
Per-repo counts do not need to reconcile with
DEMO_PORTFOLIO_QUEUE_SUMMARY.repos[].byStatus(thatbreakdown includes
queueditems, whichPortfolioQueueActionItemcannot represent — only thefleet-wide
in_progress/donetotals need to match); do not attempt to force per-repo parity.resetDemoDataForTest's restore-to-defaults behavior must continue to work unchanged against theexpanded fixture.
Deliverables
DEFAULT_DEMO_PORTFOLIO_QUEUE_ITEMSexpanded to 3in_progress+ 15doneentries (18 total)apps/loopover-miner-ui/src/lib/demo-data.test.tsassertinggetDemoPortfolioQueueItems().filter(i => i.status === "in_progress").lengthequalsDEMO_PORTFOLIO_QUEUE_SUMMARY.byStatus.in_progress, and the same for"done"vs.byStatus.done,so this can't silently drift again
Test Coverage Requirements
apps/**is outside this repo's Codecovcoverage.includescope (confirmed in PR #7082's own body), sothis is not gated by
codecov/patch. The actual bar isapps/loopover-miner-ui's own Vitest suite(
npm testin that workspace) passing, plus the new regression test above actually failing against thecurrent 4-item fixture before the fix and passing after.
Expected Outcome
A
VITE_DEMO_MODE=1build of the dashboard shows a "Queue actions" table whose row count matches thestatus-card numbers directly above it, on both the Portfolio route and (indirectly, via the same fixture)
anywhere else the demo data is consumed — no visible self-contradiction in the demo.
Links & Resources
apps/loopover-miner-ui/src/lib/demo-data.ts,apps/loopover-miner-ui/src/lib/demo-data.test.ts,apps/loopover-miner-ui/src/routes/portfolio.tsx(PortfolioQueueView/PortfolioQueueActionsSection),apps/loopover-miner-ui/vite-portfolio-queue-actions-api.ts(items-get's real, unfiltered-by-countbehavior), #5963 (the demo-mode epic this fixture layer serves).