Hosted readiness
What must be true before pointing the product at hosted Supabase - migrations, RLS, repository surface, and deployment wiring.
link to this sectionHosted readiness
The canonical checklist lives in the repository runbook `docs/hosted-readiness.md`. This page orients you; the runbook gates you.
link to this sectionThe shape of the hosted path
- Reads are served by the api-edge worker through the hosted Supabase
repository (SupabaseReadRepository), which talks PostgREST.
- Writes happen through signed protocol commands with row-level security
pinning the acting actor.
- The web app reads the same API, so a hosted migration is invisible to
readers when done correctly.
link to this sectionCurrent write-path scope
The hosted worker wires the read repository plus the personal-interaction writes (identity provisioning, watch/save interactions). Full protocol command writes (tasks, claims, evidence, runs) are not wired yet: those endpoints answer *_UNAVAILABLE 503 until their command dependencies are configured and validated. Do not declare the write path ready based on read-path checks alone.
link to this sectionBefore you trust it
- Migrations are applied to the hosted database (direct delta, not the
local migrate script).
- RLS policies are verified with the signing-role simulation in
packages/database/scripts/verify-rls.mjs.
- Every repository method the query modules require exists on the hosted
read surface - the hosted-read-surface test is the gate that once caught every detail endpoint erroring in production.
link to this sectionWhen something 500s
Start from the request id in the error response, then read docs/runbooks/production-release.md for the operational checks.