feat(confidence-engine): define investigation persistence schema

This commit is contained in:
2026-09-08 16:56:07 +01:00
parent 30bf44f2e5
commit b949eea831
3 changed files with 60 additions and 0 deletions
+5
View File
@@ -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: