Gate 3c: 6-Module Per-Module Backend Verification

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:

1. profiles — user identity
2. cms_insights — content management
3. enrollments — education
4. partner_portal_accounts — partner portal
5. newsletter_subscribers — marketing
6. cms_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.