Foundation app
Next.js App Router foundation, shared layout shell, health route, and base styling are present.
Foundation dashboard
Implementation status without simulated memory data.
This dashboard tracks completed foundation work and planned Pandora modules. It does not expose memory features because the memory engine and database schema are not implemented.
Authentication status
Server-side Supabase session lookup for the current request. No profile or memory records are loaded.
Foundation
Not authenticated
No Supabase Auth user is present for this request. The dashboard remains visible as a foundation status page.
Completed prompts
Work that exists in the repository today.
Operating documentation and contracts
Architecture, security, API, memory, environment, and coding standards are documented as implementation contracts.
Open referenceSupabase migration workflow
Supabase CLI scripts and placeholder migration workflow are prepared without production memory schema.
Auth/session structure
Supabase Auth helpers, magic-link login, callback, logout, and safe session status API are present.
Core database schema migration
Initial Supabase migration defines core, real-life, and AU/story tables with row-level protection enabled.
RLS policy foundation
Owner-scoped row-level security rules exist for user-owned core, real-life, and AU/story tables.
Typed database foundation
Schema-aligned TypeScript database types, typed Supabase clients, and table namespace helpers are present.
Repository/service foundation
Repository contracts, context helpers, namespace guards, and owned insert preparation are present without public APIs.
Safe core repositories
Server-side repositories exist for selected core tables with owner and namespace filters.
Memory validation foundation
Service-layer validators for memory candidates and patch candidates are present without public routes.
Memory candidate services
Service functions combine validation with safe repositories for memory candidate preparation and internal saving.
Logging services
Internal services prepare and write retrieval, prompt, and audit logs through safe repositories.
Patch service
Internal service validates memory patch candidates, writes append-only patch rows, and records audit logs.
Retrieval service scaffold
Internal owner and namespace filtered memory item retrieval is present without pgvector or public routes.
Transaction and idempotency scaffold
Internal transaction boundary and idempotency helpers exist for future mutation safety.
Persistent idempotency storage
RLS-protected idempotency records and internal persistence helpers exist, still without public mutation routes.
Mutation safety orchestration
Internal mutation wrappers check idempotency, run transaction boundaries, and record outcomes without public routes.
Idempotency RPC strategy
Database functions and typed helpers coordinate idempotency claims and outcomes without public mutation routes.
Phase 3B Admin Browser
Use this authenticated admin route for proof rows. The old /memory/browser public shell now redirects here and public reads remain disabled.
Not implemented yet
Required systems that remain planned and must not be implied as live.
Memory engine
No public ingest route, extraction runtime, semantic retrieval, or memory timeline behavior is implemented yet.
pgvector retrieval
The pgvector extension, embedding tables, vector indexes, and semantic retrieval are not enabled.
OpenAI integration
Responses API calls, embeddings, extraction prompts, and model-backed memory workflows are not implemented.
AU continuity engine
Canon guardrails, scene aftermath, retcons, character state, and AU relationship state are schema-ready but not implemented as behavior.
GPT Actions
The Custom GPT Actions OpenAPI schema and action routes are not implemented.
MCP server
The optional remote MCP tools are planned and must later share the same validated service layer as REST APIs.
Safety rules
Rules future pages and APIs must preserve.
Database is source of truth
Pandora will treat its own Supabase Postgres database as durable memory, not ChatGPT built-in memory.
Namespace isolation
Real-life and AU/story memory must remain separated in every future query, write, and UI state.
No fake memory data
Foundation UI must not invent people, worlds, relationships, promises, risks, deals, scenes, metrics, or audit logs.
Append-only memory changes
Memory patch writes go through an internal create-only service and still expose no public routes.
User-owned RLS boundary
The database policy layer now has an owner boundary; service-layer validation remains separate.
Typed table boundaries
Table names and namespace expectations are now represented in reusable TypeScript helpers.
Repository service boundary
Service helpers prepare owner-bound records from authenticated context before future database operations.
Core repository guardrails
Core repositories filter by owner and namespace, and still expose no public memory API surface.
Memory validator guardrails
Memory candidates are checked for namespace, type, source, and patch safety before any future persistence path.
Internal candidate service boundary
Candidate services are internal-only and do not expose public ingest or patch routes.
Internal logging boundary
Logging services are internal-only and write through owner-bound repositories without exposing public routes.
Internal patch boundary
Patch services validate patch candidates and write audit rows without exposing mutation routes.
Internal retrieval boundary
Retrieval services use owner and namespace repository filters and do not expose public search routes.
Transaction and idempotency boundary
Mutation routes must later use real transaction behavior and persistent idempotency before exposure.
Internal mutation safety boundary
Internal mutation wrappers now check idempotency before writes and record outcomes, but no public mutation route exists.
Idempotency RPC boundary
Database function helpers coordinate idempotent claim and finish records, but no memory mutation is public yet.
No live data
Memory dashboards are deliberately empty.
No fake metrics, users, worlds, scenes, relationships, risks, promises, deals, or audit logs are shown. Real cards can be added only after backed by implemented routes, schema, RLS, and retrieval logic.
Documentation links
Reference contracts for future implementation tasks.
ArchitectureSystem architecture and memory boundaries.ImplementedSecuritySecrets, RLS, namespace, and audit requirements.ImplementedAPI contractsPlanned route surface and current route status.ImplementedAuth sessionsSupabase Auth session boundary and safe session API.ImplementedIdempotency RPC strategyDatabase function strategy for idempotency claims and outcomes.ImplementedMutation safetyInternal mutation wrappers for idempotency and transaction boundaries.ImplementedTransaction and idempotencyInternal transaction boundary and durable idempotency scaffolding.ImplementedRetrieval serviceInternal owner and namespace filtered retrieval service scaffolding.ImplementedPatch serviceInternal append-only memory patch service functions.ImplementedLogging servicesInternal retrieval, prompt, and audit logging service functions.ImplementedMemory candidate servicesInternal service functions for validated memory candidate preparation and saving.ImplementedMemory contractsPrompt and behavioral contracts for future memory workflows.ImplementedMemory validationService-layer memory candidate and patch candidate validation rules.ImplementedDatabase migrationsSupabase migration workflow and explicit schema non-goals.ImplementedDatabase schemaCore schema tables, namespace columns, and RLS-enabled locked-down tables.ImplementedDatabase typesSchema-aligned TypeScript database types and table helpers.ImplementedCore repositoriesServer-side repositories for selected safe core tables.ImplementedRepository foundationRepository contracts, context helpers, and service boundary rules.ImplementedRLS policiesOwner-scoped row-level security policy foundation.ImplementedUI foundationUI shell, status honesty, and no-fake-data rules.Implemented