feat(confidence-engine): add authenticated investigation persistence
This commit is contained in:
@@ -14,8 +14,8 @@ Initial-decomposition hardening is frozen for the current MVP stage.
|
||||
|
||||
## 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.
|
||||
- The version-controlled `confidence_engine.investigations` migration is live and PostgREST exposure was configured externally. Live SQL proved RLS rejects one authenticated user inserting a row owned by another.
|
||||
- Authenticated server save/load/list capability now uses the RLS-scoped `confidence_engine` schema with server-derived identity. Production CE persistence remains localStorage-backed: no migration or cutover has occurred.
|
||||
|
||||
**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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user