Scope and evidence
The current rootpackage.json, src/App.tsx, src/main.tsx, and root deployment configuration identify the active Vite/React application. legacy-orbit-vite/, legacy-orbit-enterprise-app/, Website/, tmp/librechat-reference/, examples/, and generated dist/ or build/ outputs are separate, legacy, reference, or generated content and are not treated as routes or features of the root application. Website/ is a separately configured Next.js project. No claim here means that a deployment is currently live or that an external service is provisioned.
Database behavior is described from migrations under supabase/migrations/; deployed migration state and actual production policies were not queried. Claims tagged as needing verification require a configured runtime, authorized account, or product-team evidence.
Existing architecture
The active web and mobile UI is React 18 and TypeScript, built with Vite, React Router 6, Tailwind, Radix and shadcn primitives, TanStack Query, and Lucide. Capacitor selects hash routing on native; Electron adds desktop bridges for local actions, voice, and artifact generation.src/App.tsx owns route registration, authentication and MFA and admin guards, query cache, workspace and auth and moderation providers, analytics page events, and lazy page loading.
Supabase is the application backend: Auth, Postgres, Storage, Realtime, and Edge Functions. src/integrations/supabase/client.ts requires public URL and key configuration and persists auth using browser or Electron storage.
Existing routes
Active routes are registered insrc/App.tsx:
Staff, admin, and growth routes are also present. Most product routes are auth guarded. There is no addressable
/chat/:conversationId route yet.
Major components
Database table families
There are 72 root Supabase migrations. Core families include:
Migrations are authoritative;
project.sql is a generated or bootstrap representation and may lag until regenerated. Generated Supabase TypeScript types can lag later migrations; some call sites use a narrowly documented any adapter for those tables.
Supabase functionality and security
Browser code uses RLS-bound Supabase queries for user data and invokes Edge Functions for privileged or model operations. Migrations define RLS for workspace, library/chat, AI control-plane, mission, billing, and other user-owned records; storage policies constrain upload and read paths. Database tests undersupabase/tests/database cover workspace, library, quota, agent, role/credit, function privilege, and admin security. Security posture is migration-driven and cannot be fully certified from static repository inspection alone. Deployment drift, function secrets, deployed policy state, and storage bucket configuration require the linked project to be queried. Existing SQL tests are useful evidence but do not prove remote deployment parity.
AI, models, agents, research, and execution
orbit-chatEdge Function handles model discovery and real start/cancel generation actions. Shared provider code resolves configured upstreams. The client subscribes tochat_generationsRealtime updates and displays persisted partial output, status, and usage. It does not fake token streaming in the UI.- Chat thread and message persistence is in
src/lib/library.ts; assistant generation, attachment upload, usage labels, stop, and branch behavior are insrc/lib/orbit-chat.tsplussupabase/functions/orbit-chat. - Model options are loaded from the edge function. The chat UI also has legacy modes and access checks; keep those restrictions when simplifying presentation.
- Agent execution is routed through
run-agent; missions/workflows and their execution history are handled bymission-controland the mission tables./agentsand/automationsare aliases into the unified Mission Control surface, rather than independent implementations. - Research and web search is not established as an independent, verifiable first-party backend capability by the active route and function inventory. Do not present it as working unless a configured tool or provider is confirmed.
- Pulsar/Pro Pulsar has a desktop bridge and substantial Rust implementation. Counterpoint is not confirmed as an active web execution path by this inventory; preserve existing code and disclose availability only where integration is verified.
Broken, duplicate, dead, and demo behavior found
- Static inspection did not establish a reproducible list of runtime defects. The root test suite and a running app are needed to identify actual failures; this document does not label untested code as broken.
- The same chat home is mounted at
/and/app; history returns to/app. Chat state is primarily loaded by a per-user, per-mode localStorage thread pointer, so conversations are not yet directly addressable by URL. Supabase remains the durable source when available. - The app includes duplicate/legacy project trees and
tmp/librechat-reference; root Vite configuration should be treated as the boundary for production scope. - For signed-out preview,
IndexcontainsbuildLocalOrbitReply, a deterministic local canned-response path. It is explicitly presented as preview, but conflicts with a strict no-fake-AI policy and should be removed or replaced with a clear sign-in or backend-unavailable state. - Sidebar currently emphasizes broad workspace/account/admin links; it does not provide recent conversation rows or first-class Research/Files destinations in the compact primary navigation. Existing History/Library provides real library search; it is not a dedicated full-text search over every message.
- Some shell styling remains inconsistent with new design tokens (legacy teal/emerald utility classes, blur/shadow, and a desktop
zoom: 0.6rule insrc/index.css). These are implementation findings, not proof of broken behavior.
Existing features to preserve
Preserve auth and MFA, workspaces, billing and entitlements, real model routing, persisted chat and generation cancellation, file and image attachment flow, image and document generation, voice, desktop actions, Pro Pulsar, agents, Mission Control, automations, library, developer and admin surfaces, moderation, and analytics. Do not duplicate agents or automations outside the mission and control-plane implementation.Recommended migration order
- Establish baseline typecheck, build, and test status and identify in-flight user changes before editing.
- Consolidate app design tokens and shell surfaces without changing business logic.
- Add addressable chat URLs and maintain existing root and app deep links.
- Improve compact navigation and expose existing chat, history, and search functionality without inventing backends.
- Refine the existing composer/generation lifecycle, model picker, stop/error states, and attachments.
- Integrate verified agent/mission/file/research capabilities through existing services; label unsupported capabilities accurately.
- Audit RLS, storage, and function authorization against the deployed project and add migration-backed fixes only for demonstrated gaps.
- Run root checks and browser/mobile flows; report deployment-dependent limitations separately.
Implementation status in this change
This audit is the baseline. The checkout already contains extensive user modifications, including chat generation persistence, new workspace analytics, updated design tokens, and provider/function edits. Those modifications are preserved. The transformation work should be layered on top and checked withgit diff; no broad reset or replacement is safe.