nxtgauge-backend-rust/crates/db/migrations/20260718200000_create_verifications_and_approvals.down.sql

DROP TABLE IF EXISTS approval_logs;
DROP TABLE IF EXISTS approval_requests;
DROP TABLE IF EXISTS verification_logs;
DROP TABLE IF EXISTS verifications;
fix: verifications/approval_requests tables never existed — the single biggest gap The most severe finding in this audit: `verifications` backs the entire admin approval system this whole session's work depends on (every role's profile submission, job posting, and requirement approval flow goes through VerificationRepository). No active migration ever created it, verification_logs, or approval_requests/approval_logs. The correct schema for all of these already existed in scripts/init-db.sql — a "complete schema" reference doc — but that file is never actually executed by the real migration runner: Dockerfile.migrate only COPYs crates/db/migrations into the image, and crates/db-migrate's main.rs only ever reads that directory. init-db.sql has been dead documentation this whole time, describing the schema this codebase should have without any path to actually get there. Cross-referencing init-db.sql against the Rust code that reads/writes these tables found two bugs in init-db.sql itself: - verification_logs.verification_request_id pointed at a separate, unrelated `verification_requests` table instead of `verifications` (already independently discovered and patched by an existing migration, 20260718210823_fix_verification_logs_fk — this new migration just creates it correctly from the start). - approval_requests was missing UNIQUE(entity_type, entity_id), which apps/users/src/handlers/verifications.rs's `INSERT ... ON CONFLICT (entity_type, entity_id) DO UPDATE` requires. Positioned before the earliest active migration that already assumed these tables existed (20260718210823). The custom db-migrate runner (crates/db-migrate) has no applied-migration tracking — it just re-runs every *.up.sql file in filename order on every invocation — so there's no "already applied, don't touch" risk from adding an earlier-dated migration; idempotent IF NOT EXISTS guards make it safe regardless. 2026-07-21 02:26:15 +05:30			`DROP TABLE IF EXISTS approval_logs;`
			`DROP TABLE IF EXISTS approval_requests;`
			`DROP TABLE IF EXISTS verification_logs;`
			`DROP TABLE IF EXISTS verifications;`