robbond/confidence-engine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(confidence-engine): add authenticated investigation persistence

Browse Source
This commit is contained in:
robbond
2026-09-08 17:15:46 +01:00
parent b949eea831
commit 6dd447e56a
6 changed files with 193 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/current-handoff.md
+2 -2
View File
@@ -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.
docs/current-project-state.md
+1 -1
View File
@@ -36,7 +36,7 @@ The product direction is a **facilitated investigation** presented across three
**Authentication boundary:** Supabase Auth magic links gate product and CE API routes. Sessions are cookie-backed and `/auth/callback` exchanges the auth code before returning to `/`. This does not alter localStorage investigation persistence or introduce user ownership into CE snapshots; dedicated `confidence_engine` PostgreSQL persistence remains future work.
**Database contract (v0.62b):** A pending version-controlled migration defines `confidence_engine.investigations` outside `public`. Its platform metadata is `id`, `user_id`, and timestamps; the CE payload remains an opaque JSONB `snapshot`. Authenticated RLS ownership is `user_id = auth.uid()`. The migration is not yet applied, `confidence_engine` is not yet exposed through PostgREST, and localStorage remains the production persistence authority.
**Database contract (v0.62b):** The applied `confidence_engine.investigations` schema sits outside `public`. Its platform metadata is `id`, `user_id`, and timestamps; the CE payload remains an opaque JSONB `snapshot`. Authenticated RLS ownership is `user_id = auth.uid()`, and external PostgREST configuration exposes the schema. Server save/load/list capability is available through the authenticated/RLS path, but localStorage remains the production persistence authority; controlled cutover and legacy migration are future work.
The user controls which question to investigate, how deeply to investigate it, when to say Done for now, whether Current Understanding is sufficient, whether to reopen work, and when to review the Report. The engine facilitates — it does not steer or prioritise.