adversarial-build-workflow

Adversarial build workflow

Overview

A regulated, bilingual build cannot be shipped on optimism. The process that worked: build in acceptance-gated phases, execute each phase by fanning out parallel builders and then adversarially reviewing their output, and verify against reality before claiming anything is done. The discipline is the deliverable as much as the code.

Phase-and-acceptance gating

Build in phases (see company-profile-website's phased plan). After each phase, run that phase's acceptance checks and stop to report: what built, which checks passed, what is blocked. Do not advance until acceptance passes. The human stays in the loop between phases. This caught regulatory and i18n mistakes while they were cheap to fix.

Fan-out, then adversarial review

For a phase with independent parts, build them in parallel (one agent per part), then run a separate adversarial reviewer whose job is to find what is wrong, not to confirm it is right. The reviewer should use distinct lenses so it catches different failure classes. The build's recurring panel:

• Correctness - does it actually work, build, and pass tests?
• Invariants - banned terms, disclaimer-by-type, logical CSS, tokens, no em dashes?
• SEO / accessibility - hreflang, canonical, alt text, RTL, focus order?
• Security - injection, redirect, secret leakage, durability?

Pick the lenses that match the phase. Then you (the orchestrator) centrally triage the findings, fix the real ones, and re-verify. Reviews routinely returned real majors (a wrong per-page hreflang, a secret leaked to the Studio bundle, a broken consent link) that the builders missed.

Verification before completion (non-negotiable)

Never claim "done", "fixed", or "passing" without running the command and reading the output. Evidence before assertion. The specific traps that produce false "done":

• curl shows the RSC pre-hydration shell, not the rendered page; a localized 404 looks wrong in curl and right in a browser. Trust the browser.
• Headless Lighthouse reports fake LCP; measure with a real browser.
• A stale next start serves an old build; kill it and wait for readiness before checking headers.
• npm install can drift the local tree (lint falsely fails); npm ci is what CI runs.
• Platform env vars pull empty (Sensitive); test via live endpoints.

Run the full gate before calling a phase complete: tsc --noEmit, lint, unit tests, a production build (confirm all-SSG), and e2e. Then runtime-verify the phase's user-facing behavior on a real server.

When to reach for multi-agent orchestration

Use parallel builders + adversarial review when a phase has genuinely independent parts or when correctness stakes are high (security audit, pre-release review, regulated content). For a security audit, run several skeptics per finding, each told to refute it, and keep only findings that survive. For unknown-size discovery (bugs, missing claims), keep spawning finders until a couple of rounds turn up nothing new. Do not fan out trivial sequential work; the coordination overhead is not worth it.

Red flags (stop and verify)

• "It compiles, so it works" - run it.
• "The review confirmed it" - did the reviewer try to break it, or just agree?
• "Looks right in curl" - check the browser.
• "I fixed it" with no command output - paste the output.
• Advancing a phase with a known failing acceptance check - stop and report instead.