GPT Review — Backup Recovery Root Cause sandbox_tac

Date: 2026-04-27
Scope: Review Opus evaluation and Claude Code backup recovery report knowledge/dev/laws/dieu38-trien-khai/reports/p9-g6-backup-integrity-recovery-2026-04-27.

Verdict

Claude Code: PASS. Backup integrity remains BLOCKED. Do not retry G6. Do not issue GRANT immediately.

The report identifies a serious root cause: pg_dump run as role directus cannot access schema sandbox_tac, so backup output is effectively empty/header-only. This makes G6 retry unsafe until backup integrity is restored.

Evidence checked

• knowledge/dev/laws/dieu38-trien-khai/reports/p9-g6-backup-integrity-recovery-2026-04-27 rev 1.
• knowledge/current-state/reports/s174-fix-01-pg-backup-report — prior PG backup repair context.
• knowledge/dev/reports/gpt-review-backup-integrity-recovery-dispatch-final-pass-2026-04-27.md.

Findings

1. Claude Code followed the dispatch: VPS context, governed backup script, no script edit, no cron edit, no unrelated DDL/DML, report uploaded, STOP.
2. Fresh backup still failed integrity; new output was also header-only/20 bytes.
3. Single shared root cause appears to be directus missing privileges on sandbox_tac, causing pg_dump lock-table failure.
4. This likely affects both local Directus backup and full VPS backup finalization.
5. The backup failure is more important than G6 and must be fixed before any further DB dry-run.

Law / constitutional check

Rule	Result	Finding
Hiến pháp / Zero Trust	PASS for investigation; BLOCK for retry	No valid recent DB backup = no G6 retry.
Đ33 DB governance	BLOCK for immediate GRANT	GRANT/REVOKE is production DDL and needs a scoped governed gate.
Đ35 / 100% DOT-AI	PASS if fixed through governed AI/DOT flow	Do not run manual psql GRANT from chat.
Đ32 gate discipline	PASS	Mutation must be separately authorized.
Đ24	PASS	No labels/entity labels involved.

Position on GRANT

Do not execute GRANT immediately from this report alone.

Reason: sandbox_tac may be a pilot/test schema, a leftover, or an intentionally restricted schema. We must verify its status and backup requirements before choosing the fix.

Acceptable fix options after triage:

1. Grant path: grant USAGE on schema and read permissions on tables/sequences to the backup role if sandbox_tac should be included in DB backups.
2. Backup-role path: run backups under a dedicated backup role/superuser-equivalent if that is the established architecture.
3. Exclude/drop path: exclude or remove sandbox_tac only if it is confirmed obsolete and governed cleanup is authorized.

Required next block

Perform one compact Backup Incident Triage + Fix Plan block before mutation:

1. Read-only inspect sandbox_tac: owner, tables, row counts, privileges, Directus exposure, dependency/reference, last modified if available.
2. Read-only audit backup history: last good backup timestamp and size; how many days are broken; whether script exits non-zero on pg_dump failure.
3. Read-only inspect pg-backup.sh behavior: why it produces/keeps 20-byte output and how exit code/heartbeat behave.
4. Recommend one scoped fix option with exact pre-checks, SQL/API, rollback/compensation, action log path, and post-verify.
5. If the fix is GRANT, package it as a governed one-shot AI/DOT execution gate, not manual psql.

No G6 retry, no GRANT, no DROP, no backup script edit until the plan is reviewed/authorized.

Memory correction

Record/update operational memory:

• code-backup to GDrive may run 4x/day.
• Full VPS/Directus DB backup is daily; freshness window should be around 30h unless actual cron differs.
• Remote name observed in investigation: gdrive-backup:, not GDrive:.