Supabase

​

Verified Engine source scope

The Engine dev revision e2166b86ac6794a1423c7b2ce1b293a3dba505c4 (read 2026-09-10) contains twenty repository-owned Supabase migrations and server-side adapters for durable records, including:

• Stripe financial ledger records, events and payment contributions;
• the Stripe mode partition and card-on-file columns (migrations dated 2026-09-06, LUCI-215);
• maintenance-inbox truth, operator-seen cursors and operator push preferences;
• operator-attention state and resolve-action deadlines in the property zone; and
• Fieldwork conversation-execution evidence.

Migrations are applied by hand. No Render deploy runs a migration step; the posture on record is that Engine migrations are hand-applied (LUCI-146, Planned). A migration file in the repository is a contract, not proof that it is applied to a live project. The ledger is partitioned by Stripe mode. STRIPE_MODE (test or live) is declared, never inferred from a key prefix; each mode names its own key pair and webhook signing secret by name, and a key whose prefix contradicts the declared mode refuses outright. Development runs in test mode; the live flip is one variable set by the founder’s hand on a production service that does not yet exist. Historical ledger rows keep their meaning. See Payment truth — current. The presence of source and migrations proves an implemented repository contract. It does not prove which migrations are applied to a live project, which storage mode is selected, or what data is present.

​

Ownership boundary

The durable rule is: Do not collapse these into a generic “Lucia Supabase” claim.

​

Source security contract

The reviewed Engine source expects server-side Supabase configuration and keeps service-role access out of Admin. Repository migrations express table and policy intent. Credential values and private provider/project identifiers must never appear in public Canon. Environment-variable names in source describe an integration contract; they do not prove that a provider environment currently has values.

​

Dated payment milestone — 2026-06-19

The accepted 2026-06-19 release record reported that:

• a Stripe sandbox checkout produced a durable financial record and event;
• Engine payment truth survived an Engine restart;
• the payment-status contract still returned confirmed-paid truth; and
• Admin rendered the Engine-owned result without payment mutation controls.

The original proof used a synthetic booking fixture. Its person-like label, booking identifier, provider-project identifier, and record identifiers are intentionally omitted here. This is historical evidence for that exact Development milestone. It is not fresh proof of current datastore connectivity, row continuity, migration state, RLS enforcement, or Admin rendering on 2026-09-10. The current payment doors and their evidence are on Payment truth — current.

​

File-backed and durable state

The Engine has historically combined file-backed state with durable adapters. For any current claim, identify:

• the exact Engine commit and environment;
• the selected storage mode;
• the applied schema/migration identity;
• the authorization path;
• the durable write/read evidence; and
• restart or recovery evidence when continuity matters.

A fallback mode must be surfaced explicitly. File-backed state must never be presented as durable Supabase truth, and a source migration must never be presented as an applied production migration.

​

Future direction

Moving additional operational data to durable storage remains deliberate work. Migrate only when the schema, workflow, authorization, audit requirement, and failure behavior are defined and verified. Roadmap intent is not current runtime state.

​

Canon rule

Every Supabase claim must distinguish:

​

See also

• 02 - Current System State
• Payment truth — current
• Lucia Payment Truth Foundation
• 01 - Render
• 11 - Domains and Live Routing
• Eval Labs current state