FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Implementing a minimal database foundation and manual migration workflow
Creating a production boundary where required database objects can be added incrementally without predesigning future features
Purpose
Later capabilities needed a production database foundation, but the initial stage should not freeze speculative tables and RPCs for future features.
A minimal, human-confirmed path was needed to manage only the initial schemas and permissions through the standard migration history.
Implementation
The initial migration creates only five schemas—api, private, app, codex, and editorial—plus initial ACLs and default-deny rules. It creates no tables, views, RPCs, triggers, indexes, seeds, RLS policies, or product data; each later capability will add its design and tests in its own work unit.
- Expose only the
apifacade schema through the Data API. - Give client roles usage of
apionly, rejecting direct domain-schema use and object creation. - Set default privileges so future tables, sequences, and functions do not automatically grant client access.
- Use the standard migration history as authority, with a manual workflow checking history and dry runs before and after application.
- Add each later capability's migration, tests, verification script, and local-only dummy fixtures in the same work unit.
A speculative local prototype was removed from the authoritative implementation and retained only as read-only reference. Permanent tests now cover invariants that remain stable as objects grow: schemas, ACLs, default privileges, and the public API boundary.
Rendering diagram…
What was confirmed
Verification results
A fresh reset, all ten assertions in one pgTAP file, and database linting over five schemas passed.
The Data API exposed only api, with zero non-RPC paths.
The migration workflow's standard link, history check, dry run, apply, and recheck sequence was verified.
Full builds, type checks, tests, secret scanning, the audit of 90 requirements and 50 acceptance conditions, and live-reference verification passed.
In production, a human confirmed the five schemas, ACLs, default privileges, and api-only Data API exposure. Product tables, an authentication owner, and the agent registry had not yet been created.
Basis for completion
The work was complete when the minimal five schemas and default-deny rules were defined through the standard migration, applied to production through the manual workflow, and confirmed by local tests and human checks of schemas, ACLs, and the Data API boundary.