Back to Build LogSHIP LOG
Gate 3c: 6-Module Per-Module Backend Verification
Extended Gate 3c from single-table to 6-module per-module runtime verification. Each module independently proves database connectivity with a real SELECT query. Shell wrapper emits parseable GATE_3C_RESULT=PASS for automated governance.
Share
Gate 3c asks one question: does your backend actually work? Not "do your migration files exist." Not "did TypeScript compile." Does a real query return a real result from a real database?
The single-table problem
Our first Gate 3c implementation queried the profiles table and declared PASS. Technically correct — the database was reachable. But the platform has 6 modules, each with its own data model. Querying one table and calling it verified is like checking one tire and declaring the car roadworthy.
6 modules, 6 queries
We built scripts/verify-db-connection.ts. It runs one representative query per module:
profiles— user identitycms_insights— content managementenrollments— educationpartner_portal_accounts— partner portalnewsletter_subscribers— marketingcms_team_members— team management
Each runs SELECT 1 FROM [table] LIMIT 1. All 6 must pass. One failure = Gate 3c FAIL.
The shell wrapper pattern
Our governance skill parser reads stdout for GATE_3C_RESULT=PASS|FAIL. The verification logic is TypeScript. So we created a shell wrapper — gate-3c-verify.sh — that calls the TS script and emits the parseable line. The wrapper is zero-logic. The script is all logic. The skill reads the wrapper output.
This pattern lets us write verification in any language while maintaining governance compatibility. TypeScript today, Python tomorrow, Rust next year — the wrapper interface stays stable.