Context
The end vision is that any GitHub maintainer or repo owner starts with LoopOver the way they'd start with Lovable or Cursor: sign in, connect a repo, and drive the review agent through a chat-first dashboard — hosted, no self-hosting required, no Gittensor registration needed. The contributor side has already proven every piece of this pattern locally: #6230 specced the Lovable/Cursor-style conversational interface, #6504 shipped the action-capable miner dashboard chat (streaming renderer, read-only grounding over the loopover_miner_* tools per #6517, confirmed action-dispatch for governor/portfolio per #6521/#6838/#6839, SSE research per #6303).
Nothing equivalent exists for maintainers. apps/loopover-ui's authenticated app area (src/routes/app.maintainer.tsx, app.owner.tsx, app.workbench.tsx, etc.) is form/panel-based; there is no conversational surface, no chat grounding over ORB's maintainer data, and no chat-dispatched agent control. This epic builds the ORB-side chat platform inside the main site's app area, reusing the miner chat primitives via @loopover/ui-kit (per the secondary-UI design-system rule), grounded read-only over maintainer surfaces, with action-dispatch routed exclusively through the existing write-safety machinery.
Scope groups (native sub-issues)
- Spec — grounding-tool catalog, action catalog, authz matrix, placement, transport, tenant model. Blocks all backend/UI children below except the primitives extraction.
- Shared chat primitives — extract app-agnostic pieces of the miner chat UI into
@loopover/ui-kit (contributor-open; independent of the spec).
- Grounding backend — read-only tool registry over ORB maintainer surfaces, per-repo authz.
- Action-dispatch — chat-initiated agent controls through
resolveAgentActionMode / makeInstallationOctokit chokepoints only.
- Streaming transport — SSE on the protected API path, hosted Worker + self-host container parity.
- Session/tenant auth — installation-scoped maintainer identity, hosted-multi-tenant ready.
- Trust panel — ledger verify, anchors, decision records, calibration-with-coverage, attestation (as it lands).
- First-run onboarding — install → pick repo → guided first dry-run review conversation, zero-human path.
Hard constraints
- No new write paths. Every write action goes through the existing chokepoints (
makeInstallationOctokit(env, token, mode), resolveAgentActionMode, audit events). A chat feature that does a raw fetch() write to GitHub is defective by definition (see test/unit/no-direct-octokit.test.ts).
- Privacy boundary unchanged: no wallet, hotkey, reward, private ranking, raw trust-score, or reviewability context in any chat response. Existing redaction helpers are the mechanism, not new ad-hoc filtering.
- Design system: all UI reuses
@loopover/ui-kit; no bespoke component forks in apps/loopover-ui.
- Parity: the surface must work against a self-host deployment and the hosted control plane from the same codebase.
Expected outcome
A maintainer signs into loopover.ai, opens their repo, and can ask "what's blocking the queue?", "why did the gate close #123?", "re-gate #123", or "pause the agent on this repo" — with grounded, redaction-safe answers, confirmed dispatches, and a full audit trail. This is the maintainer half of the hosted end vision.
References
Advances #4877 (ORB Cloud Readiness — Phase B self-serve/onboarding categories). Relates to #6230, #6504, #6517, #6303, #4926, #4927, #4930, #4931, #8958.
Context
The end vision is that any GitHub maintainer or repo owner starts with LoopOver the way they'd start with Lovable or Cursor: sign in, connect a repo, and drive the review agent through a chat-first dashboard — hosted, no self-hosting required, no Gittensor registration needed. The contributor side has already proven every piece of this pattern locally: #6230 specced the Lovable/Cursor-style conversational interface, #6504 shipped the action-capable miner dashboard chat (streaming renderer, read-only grounding over the
loopover_miner_*tools per #6517, confirmed action-dispatch for governor/portfolio per #6521/#6838/#6839, SSE research per #6303).Nothing equivalent exists for maintainers.
apps/loopover-ui's authenticated app area (src/routes/app.maintainer.tsx,app.owner.tsx,app.workbench.tsx, etc.) is form/panel-based; there is no conversational surface, no chat grounding over ORB's maintainer data, and no chat-dispatched agent control. This epic builds the ORB-side chat platform inside the main site's app area, reusing the miner chat primitives via@loopover/ui-kit(per the secondary-UI design-system rule), grounded read-only over maintainer surfaces, with action-dispatch routed exclusively through the existing write-safety machinery.Scope groups (native sub-issues)
@loopover/ui-kit(contributor-open; independent of the spec).resolveAgentActionMode/makeInstallationOctokitchokepoints only.Hard constraints
makeInstallationOctokit(env, token, mode),resolveAgentActionMode, audit events). A chat feature that does a rawfetch()write to GitHub is defective by definition (seetest/unit/no-direct-octokit.test.ts).@loopover/ui-kit; no bespoke component forks inapps/loopover-ui.Expected outcome
A maintainer signs into loopover.ai, opens their repo, and can ask "what's blocking the queue?", "why did the gate close #123?", "re-gate #123", or "pause the agent on this repo" — with grounded, redaction-safe answers, confirmed dispatches, and a full audit trail. This is the maintainer half of the hosted end vision.
References
Advances #4877 (ORB Cloud Readiness — Phase B self-serve/onboarding categories). Relates to #6230, #6504, #6517, #6303, #4926, #4927, #4930, #4931, #8958.