Verifying Parallel Work

Parallel Output Is Parallel Risk

Parallel dispatch multiplies throughput. Five agents working simultaneously produce five times as much output as one agent working sequentially. This is the leverage that makes parallel dispatch valuable.

It is also the leverage that makes verification critical. Five agents working simultaneously produce five times as many opportunities for bugs, off-limits violations, type errors, and incomplete work to enter the codebase.

The verification layer is what converts parallel output volume into parallel quality. Without it, convergence is a merge of five untested branches into one broken state.

The Four Verification Layers

Layer 1 — Per-agent self-verification: Each worker must run its own verification before reporting done. This is non-negotiable. The verification commands are specified in the dispatch prompt. The worker pastes the literal output — not a summary. "Tests passed" is not evidence. "387 passed, 0 failed in 14.2s" is evidence.

The self-verification must cover:

• Test suite (npm run test — all tests, not just the new ones)
• Type check (npx tsc --noEmit — 0 errors)
• Scope check (git diff --name-only — only files in the declared scope were touched)
• Branch check (git branch --show-current — worker is on the correct worktree branch)

Layer 2 — Cross-worker review: After all workers report PASS, before the first cherry-pick, the orchestrator reviews each worker's diff for off-limits violations. git diff feat/agent-a --name-only shows every file the worker touched. Any file on the off-limits list (index.ts, tracks.ts, tiers.ts) is a violation that must be resolved before cherry-pick.

Layer 3 — Post-convergence full suite: After all cherry-picks and registry edits, run the complete test suite from the main working tree. This catches interactions between worker outputs that individual self-verification cannot catch. Two workers can each produce passing tests independently while their combined output fails due to duplicate exports, count mismatches, or type conflicts.

Layer 4 — 5-agent code-review-swarm: The adversarial review layer that runs before the PR is opened. Described in detail below.

The 5-Agent Code-Review-Swarm

Knox's /code-review-swarm skill dispatches five specialized reviewers simultaneously against the final diff. Each reviewer owns exactly one domain — no overlap, full specialization, no reviewer trying to catch everything.

Security Agent: Checks for tokens in URLs, dangerouslySetInnerHTML without sanitization, secrets hardcoded in lesson content, PII exposure. Academy-specific: no real API keys in code examples.

Logic Agent: Verifies quiz answer indices are correct (answer: 1 means index 1, which is the second option), diagram data is internally consistent, lesson prose does not contradict diagram content, quiz explanations actually match the stated answer.

Test Agent: Validates coverage stays at or above 90%, new lesson numbers are reflected in the integrity test's expected counts, no stub test files appear in new test additions, verification that the component renders (even if trivially).

Consistency Agent: Checks naming prefix convention (Pad for this track), no CSS variables or Tailwind in diagram components (hard-coded hex only per convention), no bi-modal styles, diagram monospace header format matches existing components.

Performance Agent: RSC safety — no useEffect, useState, or other client hooks in diagram TSX files. All diagram components must be renderable as React Server Components. No external dependencies in diagram files. No large inline data arrays that would bloat the server render.

Each reviewer runs independently and produces a severity-graded report (P0/P1/P2). The orchestrator aggregates the reports and resolves all P0 and P1 findings before opening the PR.

The Evidence Standard

The verification layer's value depends on the evidence standard it enforces. Three standards, from weakest to strongest:

Opinion: "I think it works." "It should pass." "Looks correct to me." — These are not evidence. Agents are optimistic. Beliefs are cheap. Do not accept them.

Confirmation: "I ran the tests and they passed." — Better than opinion, but lacks specificity. Which tests? How many? Any skipped?

Evidence: "npm run test output: 396 passed, 0 failed, 0 skipped in 18.4s. npx tsc --noEmit output: (empty — 0 errors)." — This is evidence. It is reproducible, specific, and auditable. Accept nothing less.

The dispatch contract template ends with: "Do not report status without running the command." This is what enforces the evidence standard without having to argue about it in every session.

What's Next

The next lesson assembles everything into the complete Parallel Dispatch Playbook: a five-phase end-to-end protocol for any parallel dispatch session, an anti-pattern reference, and a hands-on audit lab to apply the playbook to a real session.