feat(confidence-engine): define investigation persistence schema
This commit is contained in:
@@ -12,6 +12,11 @@ Initial-decomposition hardening is frozen for the current MVP stage.
|
||||
- Confidence Engine uses self-hosted Supabase Auth with magic-link email, `/auth/callback` code exchange, cookie-backed sessions, and protected product routes/API requests; unauthenticated API requests receive 401.
|
||||
- Investigation persistence remains wholly localStorage-backed and independent of authentication. No `confidence_engine` database schema, tables, snapshot ownership fields, Supabase server configuration, or PostgREST configuration were changed; server persistence remains future work.
|
||||
|
||||
## Database foundation (v0.62b)
|
||||
|
||||
- Version-controlled migration defines `confidence_engine.investigations`: the existing CE UUID is the row ID, platform ownership is `user_id`, and the opaque CE snapshot is JSONB. RLS permits authenticated users only where `user_id = auth.uid()`; timestamps include automatic `updated_at` maintenance.
|
||||
- The migration has not been applied to the self-hosted Supabase environment. Application persistence remains localStorage-backed; the external infrastructure step is to apply the migration and add `confidence_engine` to PostgREST's exposed schemas before server persistence is wired.
|
||||
|
||||
**Current product checkpoint:** Read `docs/confidence-engine-product-checkpoint-2026-09-08.md` before planning new product, live-evidence, or commercial work. The core investigation loop is now sufficiently established to prioritise realistic end-to-end use, report experience, prospective-user value, repeat use, and willingness to pay—not endless isolated reasoning-mechanics experiments. Preserve user ownership and address trust-critical defects when found.
|
||||
|
||||
Do not resume:
|
||||
|
||||
Reference in New Issue
Block a user