feat(miner-ui): wire the chat rail to the read-only streaming backend (#6518)

[jaytbarimbao-collab]

Closes #6518.

Fills the persistent chat rail's content slot (#6513) with a ChatConversation integration that composes the standalone composer (#6514), message list (#6515), and streaming renderer (#6516) around the read-only POST /api/chat backend (#6517). This is the first point either rail presentation holds a live conversation. Pure wiring — no forked/reimplemented component internals.

What changed

• New src/lib/chat-stream.ts — a fetch() + ReadableStream SSE client (not EventSource, which can't send the POST body). POSTs the conversation to /api/chat, reassembles data: frames across read boundaries, and yields each text delta as a ChunkSource for the shared streaming renderer. tool_call/tool_result grounding frames are consumed and skipped, an error frame rejects, done ends the stream, and a non-2xx validation response throws before any delta.
• New src/components/chat/conversation.tsx — owns the conversation state, pipes composer submissions → stream → message list append. The composer is disabled (not just dimmed) for the whole in-flight window, so a second request can't fire into an in-flight one. Loading/empty/error render through the message list's shared StateBoundary props — no fifth hand-rolled branch.
• src/components/chat-rail.tsx — RailBody now renders ChatConversation, so both the desktop docked panel and the mobile slide-over sheet get the wiring from one place.

Scope / safety

• Read-only: the only network call is streamChat → POST /api/chat. No action/write endpoint (portfolio release/requeue, governor pause/resume, discover/attempt) is called, stubbed, or imported. No config flag is added.
• None of the four existing routes (index/run-history/portfolio/ledgers) or their lib/*.ts fetchers (use-polled-fetch, run-history, portfolio-queue, portfolio-queue-actions, ledgers) are modified — verified in the diff. __root.tsx and the routed <Outlet/> are untouched (the rail was already mounted there by Chat rail: persistent collapsible shell mounted in __root.tsx #6513).
• apps/loopover-miner-ui/** is outside Codecov's coverage.include, so no Codecov patch check applies.

State-in-effect note

All conversation state writes (append user turn, commit the streamed answer, clear the in-flight flag) run inside the source generator's async continuation driven by useStreamingText, never synchronously in a useEffect body — clean under react-hooks/set-state-in-effect.

Verification

• Full miner-ui gate green: 257 tests pass (incl. new chat-stream.test.ts — SSE parse/skip/split/error/non-2xx — and chat-conversation.test.tsx — composer disabled-while-streaming + re-enable, answer commit, wire-shaped history, and the message-list error state), typecheck, lint (0 errors), build.

Both rail presentations, driven end-to-end (composer → SSE stream → committed message list)

Desktop — persistent ~380px docked rail:

Narrow viewport — slide-over sheet:

[superagent-security]

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

[superagent-security]

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

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-16 18:11:46 UTC}

5 files · 1 AI reviewer · no blockers · readiness 86/100 · CI green · unknown

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR wires the composer, message list, and streaming renderer into the chat rail via a new fetch()+ReadableStream SSE client (chat-stream.ts) and a ChatConversation component that owns conversation state. The SSE parsing correctly reassembles frames across read boundaries, skips tool_call/tool_result grounding frames, propagates error frames as rejections, and the composer-disabled-during-streaming logic correctly guards against concurrent submissions (including the subtle setActiveSource(() => source) closure-vs-updater gotcha, called out in a comment). Tests exercise frame splitting, tool-event skipping, error propagation, and the full component flow (empty/loading/error states), and all cited CI checks pass.

Nits — 5 non-blocking

• conversation.tsx has no unmount guard around the async generator's setMessages/setStreaming calls, so navigating away from the rail mid-stream will trigger a 'set state on unmounted component' warning — consider an isMounted ref or AbortController tied to the component lifecycle.
• chat-stream.ts:44 throws `chat backend responded ${response.status}` even when response.ok is true but response.body is null, which mislabels a body-less-200 edge case as if it were an HTTP error.
• ChatConversation's handleSubmit/generator body is fairly large (~84 lines per the size-smell scan); the inline async generator could be extracted to a small helper for readability, though the current inline form is not hard to follow.
• parseFrame (chat-stream.ts:29) only reads the first `data:` line per frame — fine given the server always emits single-line JSON payloads (vite-chat-api.ts's formatSseEvent), but worth a one-line comment noting that assumption so it doesn't silently break if the server ever emits multi-line data.
• Add an isMounted/AbortController guard in conversation.tsx's stream generator so a user navigating away mid-stream doesn't produce a React state-update-after-unmount warning.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6518
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High 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: 158 registered-repo PR(s), 83 merged, 4 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jaytbarimbao-collab; Gittensor profile; 158 PR(s), 4 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: jaytbarimbao-collab
• 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: 158 PR(s), 4 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 1 step in the Signals table above.

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.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop	before /	after /	—
/	mobile	before / (mobile)	after / (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 LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review