/verify-build — the merge gate

The single objective gate every branch passes before merge. It exists to kill the "looks done" failure: a build ships only when the gate is green, not when an agent says it's finished.

The rule: no branch merges to `main` without a PASS verdict from this skill. The agent that wrote the code does NOT get to wave it through (maker ≠ checker).

Run these six checks (from the worktree root)

1. Unit tests — the suites touched by the change (or the package suite):

cd packages/crm && node --import tsx --test tests/unit/<area>/*.spec.ts PASS = fail 0. Use node --import tsx, not bare tsx (the @/ alias needs the import hook).

1. Type check — packages/crm/node_modules/.bin/tsc -p packages/crm/tsconfig.json --noEmit

PASS = 0 NEW errors. The ONLY allowed baseline is the ~10 pre-existing .next/types/validator.ts React-19 generated artifacts (already ignoreBuildErrors-ed). Any other error = FAIL.

1. use-server hygiene — bash scripts/check-use-server.sh src

PASS = clean (every "use server" module exports only async functions).

1. Migration journal (only if the change added a migration) — confirm packages/crm/drizzle/meta/_journal.json gained exactly one appended entry (the new tag) and the journal check reports 0 orphans.

⚠️ The drizzle dir has pre-existing un-journaled .sql files with colliding numbers (0025/0026/0027/0028…). These are known cruft. Judge by the journal append + the new migration being additive, NOT by cat 00NN_*.sql (which globs the orphan too).

1. Regression grep — confirm the change did NOT touch the files it promised to leave alone. For each build, name the forbidden set and grep the diff:

git diff --name-only origin/main..HEAD | grep -E '<forbidden paths>' → must be empty. Common forbidden sets: workspace booking (bookings/actions.ts, bookings/create-for-customer.ts, bookings/providers.ts); messaging confirmation (messaging/skills/booking-confirmation.ts, messaging/dispatch.ts); email/sms paths when the change shouldn't touch them.

1. Live smoke (any change that affects a served route/page) — after the deploy

(confirm the live sha via curl -s .../api/version first), hit each CHANGED route and assert three things: HTTP 200, a DOM sentinel (a string the change should have put on the page — or at minimum the page's known heading), and no error signature in the structured logs for that request. A few curl + grep, or one haiku agent reading the responses. PASS = every changed route 200s with its sentinel. ⚠️ Why this is a gate and not a nice-to-have: tsc + next build + check-use-server were ALL green on a change that 500'd every dynamic render in prod (the buttonVariants RSC outage — dynamic routes are never prerendered, so next build can't see a render-time crash). Static gates prove it compiles; only a live request proves it runs.

Verdict (return ONE line)

• PASS — all six green. Safe to merge. State: the test count, that tsc/use-server/journal are clean, that the regression grep was empty, and which routes were live-smoked.
• FAIL — name the exact failing check + the failure. Do NOT merge. Hand back to the implementer.

Why this is the keystone

This is the one block that turns repetition into progress. Without it a loop bills you in silence (the "Ralph Wiggum" early-exit — an agent declares done on a half-finished job). With it, the maker can be fast + cheap because the gate is strict + independent. Prove it manually a few times, then it becomes the verifier inside /ship-feature and the heartbeat of a scheduled green-main guardian.

Framing the loop this gate closes (the goal contract)

This gate is only the stop condition of a loop. A loop converges when its goal is written as a contract the runner can check itself against — five parts, stated up front before any code:

1. Objective — one sentence, the observable end state ("SeldonChat can set a hero background and the result renders legibly"), not a task list.
2. Constraints — the invariants that must hold: files/systems to leave alone, the house rules (add named files only, money-safe, org-scope every query, SSRF-guard user URLs), flag-gating, "no new deps."
3. Validation command — the exact runnable check that decides done. For a merge, that command is /verify-build (the six checks above) — plus vision-verify for anything with a visual surface. Name it explicitly so the loop runs it, not guesses.
4. Stop condition — when to stop: "validation green AND an independent reviewer approved," or a hard iteration cap. Never "when it looks done."
5. Docs / context — the 2-3 files, specs, or seams to read first, so the runner starts with the map, not a blank slate.

The one rule that protects the whole loop: never weaken the validation to make it pass. Do not delete or loosen a failing assertion, lower a threshold, skip a test, or narrow a rubric to get green. A test that no longer asserts the behavior is worse than a red one — it launders "broken" into "done." If a check is genuinely wrong, fix the check and say so; don't quietly file it down. This is what keeps maker ≠ checker honest: the gate only means something if the maker can't move it.