FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Separating synchronization schemas from database-migration ownership
Narrowing the Connector to runtime and Edge Functions while centralizing database changes in one source
Purpose
Migrations for the same database project existed in both the synchronization runtime and display application. Applying them independently made migration order and responsibility for database structure ambiguous.
The goal was to move synchronization data into a dedicated schema, perform migration creation, reset, and application from only one source of truth, and limit the Connector to synchronization runtime and Edge Function implementation and operation.
Implementation
The health check in synchronization client was pointed at the codex schema rather than assuming database objects lived in public. Tables and RPC schemas used by the synchronization runtime are now explicit and aligned with the new boundary.
- restricted ingestion endpoint calls its batch-ingestion RPC from the
codexschema. - heartbeat endpoint calls the device-heartbeat RPC from the same schema.
- Edge Function authentication and owner boundaries remain intact; only the RPC schema references changed.
Duplicate database migrations were removed from the Connector, and database change set states that this directory is not the migration application source. Migration additions, local resets, and remote application are performed from the display application's source of truth.
database runtime settings was aligned with the shared local Supabase project. The Connector can serve and update Edge Functions but no longer owns database lifecycle scripts, avoiding two migration histories for one project.
- security guide now describes schema-specific privileges and runtime boundaries.
- database setup guide separates the execution source for database work from Edge Function work.
- The integration guide and project guide align shared-project and continuous-synchronization procedures with the new ownership model.
Diagnostics and one-shot synchronization were run in addition to type checking, tests, and a build, and both Edge Functions were checked with their new schema references. RPC calls and continued synchronization were also inspected against the remote database.
The Connector retained runtime references only while database migration history moved to a single owner. Runtime queries were updated to name their target schema explicitly.
Rendering diagram…
What was confirmed
Verification results
The combined check passed with TypeScript type checking, 38 tests, and the production build.
Diagnostics and one-shot synchronization succeeded with the new codex schema references.
Both Edge Functions were updated remotely and called their corresponding RPCs from the new schema.
Duplicate migrations were removed from the Connector, and database lifecycle versus runtime responsibility agreed across documentation, scripts, and configuration.
At the cutoff, the schema references and migration-ownership separation had been applied to the target, with continued remote synchronization confirmed. The migration contents themselves and the display application's public-administration boundary belong to separate work.
Basis for completion
The work was complete when runtime and Edge Function schema references were aligned, duplicate migrations and database-lifecycle scripts were removed, remote synchronization passed under the documented single migration source, and the result was applied to the target.