FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
fresh Supabase local baselineを構築する
後続componentが共有するdatabase、Auth、Data API、安全な書込み境界をlocalで固定する
目的
同期、Control Center、Public Web、編集実行が、旧schemaやraw table accessに依存せず使える共通backend contractが必要だった。
本番resourceを作る前に、権限、agent registry、認証callback、容量とbackupによる書込みgateをlocalでfail closedに検証する必要があった。
実装
fresh databaseをrelationsとAPI・ACLの2つのbaseline migrationへ分け、6つのschemaにdomain責務を割り当てた。Data APIへ公開するのはfacadeだけとし、domain tableとprivate helperはRLS、default revoke、principal別RPCで直接利用を防ぐ。
- runtime観測と公開agent定義を分離し、revision、relationship、visual allowlist、runtime bindingを管理する。
- agent registry未初期化時は初期化以外の変更を拒否し、active mainを正確に一件へ保つ。
- ConnectorとRunnerのuser、session、installation bindingを毎回databaseから導出し、revokeを優先する。
- Google OAuthのstateとPKCE、native callback、6桁OTP recoveryのsingle-use境界を検証する。
- capacity snapshotとinitial backup完了を揃えるまで通常書込みを許可しない3段階stateを持つ。
- TLS verify-full、credentialを引数へ含めない接続、ephemeral password file、pure-SQL parserを共通化する。
exact 8 datasetのbackup manifest、local専用dummy fixture、固定backupとidempotent restoreを用意した。production targetを示すrowがある環境ではdummy投入やlocal restore helperを拒否する。
図を描画しています…
確認したこと
確認結果
fresh resetと2 migration・8 dataset manifestの一致が通った。
10のpgTAP fileに含まれる236 assertionとdatabase lint 0 errorを確認した。
raw domain routeは非公開で、公開schemaのOpenAPIはRPCだけになった。
TypeScript 21件、Swift contract 1件、build、typecheck、secret scan、仕様監査、live参照検証が通った。
dummy dataの再投入と、messageを2件から1件へ減らした後に2件へ戻すlocal backup・restoreが通った。
local baselineは対象へ反映された。production databaseの作成・設定とremote適用はcutoff時点で未実施だった。
完了とした根拠
fresh schema、facade RPC、RLS・ACL、agent registry、Auth callback、write safety、backup manifestを実装し、236 assertion、API境界、local restore、全体検証が通ったことをもって完了とした。