Spec: conversational chat interface for loopover (Lovable/Cursor-style)

[JSONbored]

Problem

Today, interacting with loopover (either the AMS or ORB side) means using the CLI, MCP tools, or reading structured dashboard panels (apps/loopover-ui) — there's no conversational, chat-style interface for asking questions about a repo's review state, a miner's opportunity pipeline, or steering an in-progress task, the way Lovable's or Cursor's chat panel lets a user converse with an agent about their project in natural language instead of only issuing discrete commands.

Area

apps/loopover-ui (new chat surface), likely bridging to existing MCP tools as the chat agent's own tool-calling backend (reuse, don't reinvent, the ~150 tools already registered across packages/loopover-mcp and src/mcp/server.ts), and whatever LLM-routing layer already exists for this repo's own AI-reviewer calls (advisoryAiRouting, per existing settings) — check whether that routing infra is reusable for a chat surface or whether chat needs its own.

Proposal (open questions a design pass needs to answer — not yet decided)

• Scope: is this a maintainer-facing chat over their own repo's review/gate state (e.g., "why did PR feat(data): add contributor reconciliation reports #123 get held back?"), a miner-facing chat over their own opportunity pipeline/track record, or both? These likely want different tool access and different privacy postures (a maintainer chat could reasonably see more than a miner chat, given this repo's existing privacy boundary around wallet/score/reviewability context).
• Backend: does the chat agent call the SAME MCP tools an external agent would (dogfooding loopover's own tool surface — arguably a strong forcing function for MCP quality, and directly synergizes with the MCP Platform epic, Epic: MCP platform — shared-core decision + usage telemetry #6226), or a separate internal API?
• Where it lives: a persistent panel within the existing dashboard (apps/loopover-ui), a separate route, or an embeddable widget? Prefer reusing existing dashboard chrome/auth over a new surface if the data model fits.
• Cost/rate-limiting: a chat interface implies unpredictable, potentially high-volume LLM calls per user session — needs a cost-control model before it ships broadly (check how existing AI-reviewer spend controls, e.g. submitter-reputation-based downgrades, might inform this).

Deliverables

• A decided scope: audience (maintainer/miner/both), backend approach (dogfood MCP vs. separate API), and placement within apps/loopover-ui.
• A written spec/ADR that a future contributor-open implementation (once shape is decided) can be scoped from.

Resources

• apps/loopover-ui/src/components/site/app-panels/ (existing dashboard panel conventions to potentially extend)
• packages/loopover-mcp, src/mcp/server.ts (the tool surface a chat agent would likely call)
• #6226 (MCP Platform epic — a chat interface built on MCP tools is a natural forcing function for that epic's tool-parity/quality work)

Boundaries

• maintainer-only until scope (audience, backend, placement, cost model) is decided — this is a new product-surface decision, not incremental UI work.
• Must respect this repo's existing Privacy Boundary (no wallet/hotkey/reward/trust-score data surfaced in a chat response, matching every other public-facing surface's existing constraint).
• Should not be decomposed into contributor-open implementation issues until the scope questions above are answered.

[linear-code]

JSO-4317

[JSONbored]

Decision (resolved)

This turns out to be much closer to already-shipped than the original framing suggested. @loopover chat <question> (#4595, closed) already exists: a grounded LLM Q&A surface answering questions about a PR's review/gate state, with a full cost-control model already built (advisoryAiRouting.chatQa, Ollama-first by default, chatQaFrontierFallback opt-in for frontier tokens, commandRateLimitPolicy co-requisite) and — critically — a dedicated isolation guarantee: src/services/ai-chat-qa.ts deliberately cannot import any write/action-command path, enforced by test/unit/ai-chat-qa-import-isolation.test.ts. It only narrates already-deterministic facts; it never synthesizes claims or takes action.

Scoping this decomposition to match that precedent exactly, not expand past it:

• Audience: maintainer-facing only, for now. This is the half with a real, safe precedent to build from (explaining a repo's own PR/gate state). A miner-facing chat over an AMS opportunity pipeline is a genuinely different feature — different grounding data, different backend, no existing precedent — and is explicitly out of scope here rather than silently bundled in. If that's wanted, it should be its own freshly-scoped issue once AMS's own local-data-only constraints are researched the way this one now is.
• "Steering an in-progress task" (from the original Problem statement) is also explicitly out of scope — the existing ai-chat-qa.ts isolation guarantee is exactly what makes this safe today, and giving the dashboard version any write/action capability would break that guarantee and need its own dedicated security design. Read-only, same as today.
• Backend: reuse ai-chat-qa.ts as-is — not a new API, not the full ~150-tool MCP surface (which includes action tools). This is "expose an existing, already-safe capability in a new UI location," not a new capability.
• Where it lives: a new panel within apps/loopover-ui/src/components/site/app-panels/maintainer-panel.tsx, per this repo's existing dashboard-chrome-reuse preference.
• Cost/rate-limiting: unchanged — the dashboard entry point must share the SAME commandRateLimitPolicy budget as the PR-comment command, not a separate parallel budget an operator could double-spend against.

Filing the implementation as a contributor-open child issue.