Nexus Memory Vault

01 Backend Contract Prompt

You are helping me set up a Supabase backend for a private Memory Vault app.

Goal:
Create a Supabase backend where every signed-in user has their own private vault profile, memory categories, memories, and uploaded files. Users must not be able to read, edit, delete, or list another user's records or storage objects.

Before changing anything:
1. Inspect the current Supabase project state.
2. Check current Supabase documentation for Auth, RLS, Storage, and MCP/database tooling.
3. Tell me what already exists, what is missing, and what changes you plan to make.
4. Do not use service-role keys in any browser or phone app.

Supabase setup screen choices:
1. For this current phone web app/frontend, use the current Supabase client-library guidance for React with Vite. If Supabase changes its dashboard labels, follow the current official docs rather than these screen labels.
2. Choose the framework/runtime options before copying generated config values or install commands.
3. The generated setup snippet and publishable-key block can change when framework, variant, or UI-block options change, so copy values only after the screen refreshes.
4. For the AI connection, use MCP / Connect your agent. Choose the actual client being used, such as ChatGPT, Codex, Grok, Claude, or another listed agent.
5. Server / Build APIs is only needed if we later add a custom backend API or Edge Function. Do not put its secret key in the phone app.
6. Direct / Connection string is database/admin style access. It is not for the phone app and should not be pasted into the app.
7. ORM / Third-party library is for backend/server projects using tools like Prisma or Drizzle. It is not the main setup path for this phone app.
8. The phone app should store only the Supabase project URL and publishable key. The service-role key, secret key, database password, connection string, JWT secret, and MCP auth token must stay out of the phone app.
9. If this is later rebuilt as a true native app through Expo, use the React Native / Expo guidance instead of plain React.

Backend contract:
1. Use Supabase Auth so every profile, category, memory, and file record belongs to one signed-in owner.
2. Store one vault profile per owner. It must support AI name, selected icon reference, PIN/auth preference metadata if needed, and flexible settings JSON for future app preferences.
3. Store categories as rows, not as separate tables. Each category must belong to an owner, have a reusable internal slot number, have a human-readable name, and support owner-created or AI-created categories.
4. Store memories as rows linked to the owner and a category. Each memory needs a title/header, body, tags, source such as human/AI/system, optional metadata, created timestamp, and updated timestamp.
5. Edits to memories must preserve prior memory state in a revision/history table.
6. AI-requested append changes must go into a pending append-request table. The owner approves or denies them. AI should not overwrite canonical memories directly.
7. Store uploaded-file records as rows linked to the owner, optionally linked to a category and/or memory. Each original file record needs original filename, storage bucket/path, MIME type, file size, SHA-256 hash, artifact role, metadata, created timestamp, and updated timestamp.
8. Keep original/source files distinct from derived artifacts such as OCR, extracted text, summaries, embeddings, or analysis. Derived artifacts must reference the source file and must not masquerade as originals.
9. Create or reuse a private Supabase Storage bucket for vault uploads. Files should live under a path that begins with the owner's auth user id so storage policies can restrict access cleanly.
10. Enable Row Level Security on every exposed vault table. The owner must be able to select, insert, update, and delete only their own rows where the app requires those operations.
11. Add storage policies so owners can read, upload, replace, and delete only their own files.
12. Add indexes needed for owner lookups, category lookups, memory search, tag filtering, file lookup, revision lookup, pending append lookup, and continuation lookup.
13. Add lightweight continuation state so a fresh AI can identify active category/context, current objective, recent meaningful operation, canonical memory IDs, unresolved items, do-not-redo notes, authority notes, and next recommended action.
14. The phone app must be able to sync the latest profile, categories, memories, revisions, pending appends, continuation state, and file records from Supabase after the owner or their AI makes changes.
15. The phone app will handle manual export locally, but the backend must provide all memory/category/file/revision/append/continuation data needed for meaningful restore.
16. Use Supabase's generated API/client with RLS where possible. Do not build a custom API unless the app needs behavior Supabase cannot provide directly.
17. Check current Supabase Auth, RLS, Storage, indexing, and client-library guidance before generating SQL or app code. If current Supabase guidance conflicts with this prompt's wording, explain the conflict and follow the current official guidance.

After setup:
1. Explain what tables, policies, buckets, and indexes were created.
2. Tell me what project URL and publishable key the phone app needs.
3. Tell me what secrets must never be pasted into the phone app.
4. Run Supabase security/performance advisors or equivalent checks if available, and report any remaining warnings honestly.

02 Data Model AI Prompt

This is an AI prompt, not SQL. Do not paste this text into Supabase SQL Editor.

You are helping me design the Memory Vault database model in Supabase using current best practices.

First inspect the current project:
1. List existing public tables.
2. List existing storage buckets.
3. List installed extensions that matter.
4. Tell me whether this is a fresh project or an existing Memory Vault backend.

Then propose the SQL/migration needed for the Memory Vault model. Do not execute destructive changes without asking first. Prefer an idempotent migration that can safely run once on a fresh project. If an existing Memory Vault schema is detected, stop and explain the migration/backup plan before changing data.

The app needs these concepts:
- vault profile: AI name, selected icon, app preferences
- memory category: owner id, internal slot number, human category name
- memory: owner id, category, title, body, tags, source, provenance, timestamps
- memory revision: owner id, memory id, previous title/body/tags/category/provenance, revision reason, actor/mechanism, recorded timestamp
- pending append request: owner id, memory id, appended text, reason, requested-by mechanism, pending/approved/denied status, review metadata
- vault file record: owner id, optional memory/category link, original filename, storage bucket/path, MIME type, file size, SHA-256 hash, artifact role, source-file relation, timestamp
- continuation state: owner id, active category/context, objective, last operation, canonical memory ids, unresolved items, do-not-redo notes, next action, authority notes

Rules:
1. Every row must belong to the signed-in owner.
2. Categories must be owner-specific.
3. Category slot numbers should be reusable after a category is deleted.
4. The phone UI should not have to create new database tables when a user makes a new category.
5. AI append requests must require owner approval before changing canonical memory body.
6. Original uploaded files must not be overwritten by extracted text, OCR, summaries, embeddings, or AI analysis.
7. Add indexes needed for owner lookups, category lookups, memory search, tags, file lookup, revision lookup, append lookup, and continuation lookup.

Output format:
1. Existing project summary.
2. Proposed tables and relationships.
3. Proposed SQL migration.
4. Risks or assumptions.
5. Validation query to run after migration.
6. Rollback or backup note for any non-additive change.

03 Privacy & RLS Prompt

Review and secure the Memory Vault Supabase backend.

Required security behavior:
1. Enable Row Level Security on every exposed vault table.
2. A signed-in user can only select, insert, update, or delete rows where the row owner equals auth.uid().
3. No user can list, read, edit, or delete another user's vault profile, categories, memories, or file records.
4. Do not use user-editable metadata for authorization decisions.
5. Do not expose service_role keys, database passwords, or admin credentials to the app.

Please inspect existing policies first. Then create the minimum needed policies using current Supabase/Postgres best practices. Afterward, explain how the policies prevent cross-user access.

04 Storage Setup Prompt

Set up private Supabase Storage for Memory Vault files.

Requirements:
1. Create or reuse a private bucket for vault uploads.
2. Store each user's files under a path that begins with their auth user id.
3. Add storage policies so users can only read, upload, replace, and delete their own files.
4. The app may accept many file types, including documents, markdown, spreadsheets, code, images, audio, video, and archives.
5. The phone app should store file metadata in a vault file record so memories can reference uploaded files later.

Please check current Supabase Storage docs before making policies. Explain the final bucket name, path convention, file size limit, and what app code should use when uploading.

05 AI MCP Behavior Prompt

You are my AI connected to my Supabase-backed Memory Vault.

Use the vault carefully:
1. Confirm which signed-in owner/user id or vault owner you are operating for before reading or writing.
2. Save durable facts, project notes, user preferences, and useful context as memories.
3. Do not create duplicate categories if a fitting category already exists.
4. If a new category is needed, create it in the categories table and use the next available slot number.
5. Save memories into the correct category.
6. When searching, look across title, body, tags, category, and file metadata.
7. Do not access, summarize, copy, or expose another user's data, even if your tool connection can technically see it.
8. If you need to add to an existing memory, create a pending append request with a clear reason. Do not overwrite the memory directly unless the owner explicitly tells you to act as the owner.
9. When you create or update memories, categories, files, pending appends, or continuation state, tell the owner to press sync memories in the phone app.

Before writing anything, inspect the available categories and confirm the target category if it is ambiguous.

06 Phone App Connection Prompt

Help me connect the Memory Vault phone app to this Supabase project.

Requirements:
1. The app should use only the Supabase project URL and publishable key.
2. The app should use Supabase Auth for login/session handling.
3. After login, the app should create default owner rows only for the signed-in user if they do not already exist.
4. The default category should be Personal, but the slot number can stay internal.
5. The sync memories button should pull the latest profile, categories, memories, and file records from Supabase.
6. The app should never contain the service_role key, database password, personal access token, or MCP auth token.
7. For this current phone web app, use the current Supabase client-library guidance for React with Vite. If the project later becomes a native mobile app, use current Expo/React Native guidance instead.
8. Copy the generated project URL, publishable key, and install/config guidance only after the correct framework/runtime options are selected, because the visible snippet can change when the options change.
9. Do not copy values from the Server, Direct, or ORM tabs into the phone app unless you are intentionally building a backend service and can keep secrets server-side.
10. Use Supabase's generated API/client with Row Level Security; the app should not need a hand-written API for basic vault reads, writes, auth, storage upload, or sync.
11. If the app is later rebuilt as a native Expo app, switch to the current React Native / Expo Supabase guidance.

Please give me the exact frontend configuration values that are safe to put in the app, and list anything that must stay secret.

Unlock To Continue