Admin V2 Architecture And First Slice

Objective

Admin V2 is the local-first Pro console for OMEGA. It reads from local adapter contracts first and treats customer-owned providers as optional capabilities. Supabase is optional mirror infrastructure, not a required source of truth.

The first slice implemented:

• Overview
• Connections
• Health

The second slice adds:

• Settings
• License

The third slice adds:

• Projects

The fourth slice adds:

• Memory List
• Memory Detail

The fifth slice adds:

• Operations

Internal Console remains separate at /admin/internal.

Product Boundary

Admin V2 answers Pro-user operational questions:

• What is the current state of my OMEGA?
• What providers are configured?
• Is OMEGA healthy?

It must not show creator metrics, GitHub growth metrics, PyPI metrics, grants, downloads, raw cron internals, Edge Quality, audit logs, or internal research surfaces.

Route Structure

Implemented:

• /admin/v2 - Overview

• /admin/v2/connections - Connections

• /admin/v2/health - Health

• /admin/v2/settings - local installation settings

• /admin/v2/license - local license status

• /admin/v2/projects - canonical project registry

• /admin/v2/projects/[projectId] - project identity detail

• /admin/v2/memory - local memory list

• /admin/v2/memory/[memoryId] - local memory detail

• /admin/v2/operations - outcome-focused runtime operations Linked but not rebuilt in this slice:

• /admin/memories/graph - existing Memory Graph surface

• /admin/settings - legacy hosted account/settings surface

Deferred:

• /admin/v2/agents
• /admin/v2/memory/search
• /admin/v2/memory/graph

Component Structure

• admin/app/admin/v2/page.tsx
• admin/app/admin/v2/connections/page.tsx
• admin/app/admin/v2/health/page.tsx
• admin/app/admin/v2/settings/page.tsx
• admin/app/admin/v2/license/page.tsx
• admin/app/admin/v2/projects/page.tsx
• admin/app/admin/v2/projects/[projectId]/page.tsx
• admin/app/admin/v2/memory/page.tsx
• admin/app/admin/v2/memory/[memoryId]/page.tsx
• admin/app/admin/v2/operations/page.tsx
• admin/app/admin/v2/V2Shell.tsx
• admin/app/admin/v2/v2-data.ts
• admin/app/admin/v2/v2.css

The V2 pages are server-rendered. They do not introduce client-side provider fetching or new API routes.

Adapter Usage Map

Local-First Rules

• omega.db remains the canonical local store.
• Project registry is read through LocalProjectStoreAdapter.
• Health is read through LocalHealthAdapter.
• Connections are read through LocalConnectionAdapter.
• License is read through LocalLicenseAdapter.
• No page requires NEXT_PUBLIC_SUPABASE_URL or SUPABASE_SERVICE_ROLE_KEY for its data.
• No secrets or token values are rendered.
• Supabase is labeled as an optional customer-owned provider, not a required platform service.
• Projects V2 reads only canonical registry records from LocalProjectStoreAdapter; it does not infer projects from legacy memory labels, Supabase mirrors, workspace rows, or filesystem scans.
• Memory V2 uses LocalMemoryStoreAdapter.list() and LocalMemoryStoreAdapter.get() only.
• Memory V2 does not call search, graph expansion, retrieval ranking, context packet generation, Dreams, or Edge Quality.
• memories.project remains a legacy project label and is never used for Memory V2 filtering or routing.
• Operations V2 shows outcomes from local adapters only. It does not expose cron definitions, scheduler internals, raw audit logs, creator metrics, Edge Quality, Dreams, or deployment internals.

First-Time Success Contract

The first independent Pro user test depends on a single first-run path:

1. Install OMEGA.
2. Activate Pro.
3. Restart Claude Code.
4. Run omega doctor.
5. Run omega dashboard.
6. Create a memory from real Claude Code work.
7. Open Admin V2 Memory and verify the record.
8. Confirm local ownership in Overview or Settings.

The first-run activation goal is not search, graph exploration, Agents, or context packets. The activation goal is:

• Pro license is active.
• Claude Code is connected.
• Local runtime is healthy.
• At least one memory exists.
• The user can inspect that memory.
• The user can see where local OMEGA data lives.

Admin V2 supports this with:

• Overview first-run checklist.
• Overview and Settings local ownership cards.
• Memory empty state with first-memory instructions.
• Memory first-value callout once records exist.
• Projects empty-state copy that explains projects as organizational lenses.
• Operations labels that describe user-facing outcomes instead of internal implementation names.

Migration Plan From V1

V1 remains operational while V2 grows.

• Dashboard stays V1 until Overview replaces its Pro-user decisions.
• Memory Graph stays as the current Memory surface until Memory Explorer is designed.
• Projects stays V1 until local project workflows are moved behind adapters.
• Coordination stays V1 until Agents data contracts are ready for UI.
• Insights stays V1 until health and memory insight metrics are normalized.
• /admin/settings remains V1 for hosted account/workspace/subscription management.
• /admin/v2/settings replaces the Pro-user local installation visibility portion.
• /admin/v2/license replaces read-only local license visibility, but activation remains deferred to existing flows.
• /admin/v2/projects replaces the canonical project identity portion of V1 Projects, but activity, task, checklist, and dashboard summaries stay deferred.
• /admin/v2/memory replaces the record inspection portion of V1 Memory Graph, but graph navigation, search, retrieval ranking, and context packet views stay deferred.
• /admin/v2/operations replaces user-facing operational health outcomes from V1 Jobs/Diagnostics, but job internals, schedules, raw audit logs, and creator diagnostics remain internal-only.

V1 Settings Migration Matrix

V1 Projects Migration Matrix

V1 Memory Migration Matrix

V1 Operations Migration Matrix

First Implementation Plan

1. Add /admin/v2 route family.
2. Use createAdapterResolver() as the only data access boundary.
3. Build Overview from health, projects, license, and connections.
4. Build Connections from local provider connection records.
5. Build Health from public health checks only.
6. Improve mobile parity in V1 so Memory Graph and Settings are discoverable.
7. Run npm run typecheck and npm run build.

First-Time Success Sprint

Implemented as a narrow onboarding/readiness layer:

1. Add omega dashboard as the canonical dashboard launch command.
2. Update omega activate completion copy with explicit next steps.
3. Add the Overview first-run checklist.
4. Add Memory empty-state and first-memory callout copy.
5. Add local ownership cards to Overview and Settings.
6. Soften Projects empty-state behavior for new users.
7. Update Operations wording from internal process labels to user-facing outcomes.

This sprint intentionally does not add Agents V2, search, graph navigation, context packet views, retrieval changes, project registry writes, or sovereignty changes.

Risks

• Existing /admin/* middleware still depends on the current auth model. This slice removes Supabase from V2 data reads, not from the legacy admin authentication gate.
• LocalMemoryStoreAdapter is Phase 1 only, so Overview uses HealthAdapter memory count instead of memory search or graph expansion.
• Health checks are summaries. Raw job internals, audit logs, and schedule internals remain internal-only.
• Provider ownership classification is enforced by sovereignty/sync policy, not by the Connections page.

Recommended PR Sequence

1. Admin V2 first slice: routes, shell, local adapter reads, mobile parity.
2. V2 route tests and smoke tests once the project has a stable app-router test harness.
3. Memory Explorer foundation audit before building /admin/v2/memory.
4. Agents data contract audit before building /admin/v2/agents.
5. Settings write flows only after local credential/provider mutation contracts are explicitly designed.