feat(miner-ui): portfolio-queue summary cards over the local queue store

[reyanthony062001-ops]

Closes #4306

What

Portfolio/queue summary cards in apps/gittensory-miner-ui/: read-only counts by status (queued / in_progress / done) over the local miner_portfolio_queue store, with a per-repo breakdown table when the local queue spans multiple repos — the cross-repo shape portfolio-queue.js's schema already supports.

Design, per the issue's guidance

• Same local data-access layer as the run-history view (feat(miner-ui): add read-only run-history table view #4305): a sibling Vite dev/preview middleware (vite-portfolio-queue-api.ts) serves GET /api/portfolio-queue through portfolio-queue.js's EXISTING exports (resolvePortfolioQueueDbPath/listQueue) — no SQL and no new queue-store methods.
• Aggregation is client-side and pure (summarizePortfolioQueue in src/lib/portfolio-queue.ts), exactly as the issue suggests: a read + aggregate over what listQueue() already returns, unit-tested independently of rendering. The middleware serves raw rows and duplicates no aggregation.
• Strictly read-only, including the fresh-install path: listQueue() lazily initializes the default store (which would CREATE the SQLite file), so the handler probes the resolved DB path first and serves { rows: [] } without touching the store when no DB exists yet — asserted in tests (no listQueue call happens on that path), matching the run-state endpoint's contract.
• The view (src/routes/portfolio.tsx, mounted in the shell's nav) renders four states: loading, error (inline alert, never a crash), the fresh-install empty state, and the populated cards — with the per-repo table appearing only for multi-repo queues so a single-repo install stays uncluttered.
• routeTree.gen.ts regenerated and committed via the router plugin.

Testing

15 new cases: pure-aggregation tests (multi-repo counts + sorted breakdown, empty queue), component tests for all four view states plus the multi-repo/single-repo table rendering split, fetch-client tests (happy path, non-2xx, malformed payloads, thrown fetch), and middleware-handler tests (rows via existing exports, the no-write fresh-install path, fall-through, store-failure → 500). Workspace test (29/29) / typecheck / lint / build all green locally; the diff is confined to apps/gittensory-miner-ui/**.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-10 09:03:52 UTC}

7 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
Adds a read-only portfolio-queue summary view (cards + per-repo breakdown table) that follows the existing run-history pattern closely: a sibling Vite middleware (`vite-portfolio-queue-api.ts`) wraps the existing `portfolio-queue.js` exports with no new SQL or store methods, aggregation is a pure client-side function (`summarizePortfolioQueue`) unit-tested independently of rendering, and the fresh-install path is verified read-only (probes `existsSync` before calling `listQueue()`, asserted via a test that `listQueue` is never invoked). Traced the aggregation logic and fetch/error-handling boundary (non-2xx, malformed payload, thrown fetch, per-repo `??` nullish-vs-present branch) against the 15 added tests and all the meaningful branches are genuinely exercised, not fabricated. `routeTree.gen.ts` is the standard router-plugin-generated file (matches the `run-history` route's prior diff shape) and closes the linked issue #4306 per its stated design guidance.

Nits — 5 non-blocking

• `apps/gittensory-miner-ui/src/routes/portfolio.tsx:31` — `PortfolioQueueView` is a single 62-line function mixing the 4-state branch logic with full card/table JSX; consider extracting the table into a small `RepoBreakdownTable` component to keep it under the file's usual function-size norm.
• `apps/gittensory-miner-ui/vite-portfolio-queue-api.ts:47-52` — the raw `200`/`500` status literals could reasonably stay as-is (they're standard HTTP codes), but if this repo has a shared status-constant convention elsewhere (as in `vite-run-state-api.ts`), match it for consistency.
• `apps/gittensory-miner-ui/src/portfolio-queue.test.tsx` — several assertions use non-null assertions (`screen.getAllByText("Queued")[0]!`) instead of `getAllByText(...).at(0)` with an explicit truthy check; minor test-readability nit, not a correctness issue.
• The per-repo table's status columns duplicate `STATUS_LABELS`/status-key ordering inline (`portfolio.tsx:70-81`) instead of mapping over `QUEUE_STATUSES`; low-risk DRY nit since the three statuses are unlikely to change independently of the type.
• Consider factoring the repeated `<th>`/`<td>` status-column trio in `portfolio.tsx`'s table into a `QUEUE_STATUSES.map(...)` loop the same way the card grid already does, so adding a future status only requires touching `QUEUE_STATUSES` and `STATUS_LABELS`.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#4306
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 29 registered-repo PR(s), 18 merged, 1 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	reyanthony062001-ops; Gittensor profile; 29 PR(s), 1 issue(s).
Gate result	✅ Passing	No configured blocker found.

Linked issue satisfaction

Addressed
The PR adds a portfolio.tsx view with summary cards for queued/in_progress/done counts plus a per-repo breakdown table for multi-repo queues, backed by a pure summarizePortfolioQueue aggregation over listQueue()'s output via a new read-only Vite middleware that mirrors the run-history pattern without adding queue-store methods, and includes a fresh-install empty state plus extensive component/unit

Review context

• Author: reyanthony062001-ops
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 29 PR(s), 1 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/portfolio	desktop			—
/portfolio	mobile			—
/	desktop			—
/	mobile			—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[loopover-orb]

Gittensory approves — the gate is satisfied and CI is green.