[zibi-pplx]

Backup identity and retained-artifact recovery need durable provenance that survives retries and restarts. Add nullable execution/pool Node UIDs, materialization IDs, snapshot source identity, upload evidence, and constrained recovery approvals. Historical identity stays unknown; there is no backfill.

Deploy this schema before the dependent runtime PRs. DDL uses short lock timeouts; the new foreign key is added NOT VALID and validated separately. Approval history is retained independently of snapshot pruning, and the down migration refuses to erase issued approvals. Keep the additive schema on application rollback. The earlier draft migrations were never applied to a shared database, so these use fresh versions newer than main.

Validation: pinned Squawk passes all seven up migrations; fresh and main-to-new-schema PostgreSQL 17 runs produce identical schemas. Version and migration-isolation guards pass for each stack commit. PostgreSQL-backed RPC tests exercise the approval consistency constraints. Public diff review and Gitleaks passed.

Stack (land in order): #318 schema → #319 materialization ownership → #345 backup caller identity → #346 upload evidence → #283 retained-artifact recovery.

Rebuilt against d1abc66fe48bccaaa715e09593f875f7c6c4d11d. The schema is separate because current CI requires migration-only PRs. All existing PRs are reused.

Scope boundary: no file overlap with #828 (2a4988b6), #829 (1b696768), or #837 (58ceff04). Both compositions—#828+#829 and #837+#829—passed aarch64 Linux musl Clippy and all 98 selected snapshot/teardown tests each. These are component tests, not live Firecracker recovery evidence. Capture, encrypted sealing, teardown handoff, and source cleanup remain with those workstreams. Linux/KVM held-volume recovery, manager-restart/handoff failure, and live restore of the same artifact have not been validated here; issuance must remain disabled until that deployment evidence exists.

AI assistance: Codex contributed implementation, tests, and this description.

[zibi-pplx]

The schema prerequisite now also includes the per-materialization identity and bounded, audited recovery grants with attempt provenance. All columns are additive; historical worker identity remains unknown, with no backfill or enforcement. Migration-only isolation passed for this PR and all six stack commits, and required PostgreSQL fixtures exercised the schema. Runtime writers and policy changes remain in later draft PRs.

[shrikant-pplx]

Duplicate. This review was submitted twice after a GitHub API error; the findings are in #pullrequestreview-5508014453.

[shrikant-pplx]

Reviewed together with the rest of stack #345 → #318 → #319 → #346. No P0/P1 findings. One P2 and one P3 are inline.

Ran locally: scripts/check-migration-versions.sh (base ecd3f9a1d) and scripts/check-postgres-migrations-squawk.sh both pass.

1. Fixes the stated problem and root cause? Partly. It supplies the execution, pool-slot and materialization columns that #319 uses. The recovery-grant schema has no consumer, and the schema doesn't enforce "bounded".
2. Covers every affected caller and path? Partly. #319 consumes sandbox_k8s_executions.k8s_node_uid, kubernetes_pool_slots.k8s_node_uid and materialization_id. Nothing in the stack consumes snapshots.source_node_uid, snapshots.recovery_grant_id or backup_recovery_grants.
3. Every change necessary, no scope creep? No. Three of the six migration pairs arrive before any writer exists (inline P2).
4. Do the tests reproduce the failure and prove the fix and edge cases? Partly. There are no migration tests. The repo guards pass, and #319's Postgres tests exercise only the consumed columns.
5. Regression? No. The DDL is additive and nullable, with short lock timeouts and a separate foreign-key validation.

Checked and found no problem:

• Migration versions are newer than main's maximum.
• Each ADD COLUMN is nullable with no default.
• The foreign key is added NOT VALID and validated in a separate migration (SHARE UPDATE EXCLUSIVE lock).
• Down migrations run in the correct order.
• Having no index on snapshots.recovery_grant_id is fine as long as grants are never deleted.

[shrikant-pplx]

P2 [func] Speculative schema: nothing in the stack reads or writes it

At #346, nothing outside db/ references backup_recovery_grants, snapshots.recovery_grant_id or snapshots.source_node_uid (the last one comes from 20261012193402_backup_source_node_identity). #346 records its proofs in the volume-manager job payload, not here.

Applied migrations are immutable (db/README.md). Merging this fixes in place:

• a 19-column audit table
• its index
• a foreign key from snapshots

That happens before the code that defines the table's state machine has been reviewed, so any redesign needs follow-up migrations. The store guidance is also to add record columns together with their first caller.

Fix: keep 193400, 193401 and 220000, which #319 consumes. Move 193402, 223000 and 223001 into the migration PR that directly precedes their writer.

[shrikant-pplx]

P3 [check] The schema doesn't enforce "bounded"

The only time bound is expires_at > approved_at. There is:

• no maximum approval window
• no uniqueness on consumed_attempt_id
• nothing tying revoke_reason to revoked_at
• nothing stopping a grant from being both consumed and revoked

Adding these constraints is free while the table is empty. Later, they need a NOT VALID/VALIDATE pass or a concurrently built unique index.

Fix: when the table lands with its writer, add constraints that match the intended state machine. For example:

• a maximum for expires_at - approved_at
• (revoked_at IS NULL) = (revoke_reason IS NULL)
• UNIQUE (consumed_attempt_id)