05 · Orchestrate

Team Validation

Spawn N independent validators across platforms or perspectives. Dependency-aware waves. Isolated evidence directories. A single synthesized verdict with confidence scoring — not a feelings-based consensus.

Max validators

Wave layers

Platform types

Default consensus

Cross-writes allowed

01 Dependency-Aware Execution Waves

Validators fire in dependency order. A downstream platform cannot produce meaningful verdicts against a failing upstream. Each wave runs in parallel internally; the next wave waits for unanimous PASS.

02 Wave Structure Reference

Wave	Validators	Depends On	Launch Condition
Wave 1	DB · Design · CLI	—	Immediate — no upstream dependencies
Wave 2	API	Wave 1	DB validator reports PASS
Wave 3	Web · iOS (parallel)	Wave 2	API validator reports PASS
Wave 4	Integration	Waves 1–3	ALL validators in Wave 3 report PASS

03 Evidence Ownership

Each validator owns one evidence directory exclusively. Cross-writes are forbidden and invalidate the run. The lead coordinator writes nothing — it only coordinates.

evidence directory structuretree

e2e-evidence/
  <span class="cmd">web/</span>         ← Web Validator only (exclusive write)
    step-01-landing-rendered.png
    step-02-login-form.png
    step-03-session-cookie.txt
    evidence-inventory.txt
    verdict.md

  <span class="cmd">api/</span>         ← API Validator only (exclusive write)
    step-01-post-users.json
    step-02-response-headers.txt
    evidence-inventory.txt
    verdict.md

  <span class="cmd">ios/</span>         ← iOS Validator only (exclusive write)
    step-01-simulator-boot.png
    step-02-ui-state.json
    evidence-inventory.txt
    verdict.md

  <span class="cmd">design/</span>      ← Design Validator only (exclusive write)
    step-01-token-audit.json
    step-02-visual-comparison.png
    evidence-inventory.txt
    verdict.md

  <span class="ok">report.md</span>    ← Verdict Writer only (reads all dirs, writes here)

Role	Writes To	Reads From
Lead Coordinator	(nothing)	all validator verdict.md files
Web Validator	e2e-evidence/web/	source code, running app
API Validator	e2e-evidence/api/	routes, DB schema
iOS Validator	e2e-evidence/ios/	Xcode project, simulator
Design Validator	e2e-evidence/design/	DESIGN.md, screenshots
Verdict Writer	e2e-evidence/report.md	all e2e-evidence/*

04 Spawning Protocol

Before spawning any validator the lead resolves the dependency graph, checks upstream status, and records every decision. Skipping the check is an iron rule violation.

example spawn logconsole

<span class="c">[lead] Resolving dependency graph...</span>
<span class="c">[lead] Wave 1: DB · Design (no deps)</span>
<span class="ok">SPAWN DB     — deps: none</span>
<span class="ok">SPAWN Design — deps: none</span>
<span class="c">[lead] Waiting for Wave 1...</span>
<span class="ok">  DB     → PASS  (2m 14s)</span>
<span class="ok">  Design → PASS  (1m 47s)</span>
<span class="c">[lead] Wave 2: API</span>
<span class="ok">SPAWN API    — deps: DB=PASS</span>
<span class="ok">  API    → PASS  (3m 02s)</span>
<span class="c">[lead] Wave 3: Web · iOS (parallel)</span>
<span class="ok">SPAWN Web    — deps: API=PASS</span>
<span class="ok">SPAWN iOS    — deps: API=PASS</span>
<span class="ok">  Web    → PASS  (4m 18s)</span>
<span class="ok">  iOS    → PASS  (5m 44s)</span>
<span class="c">[lead] Wave 4: Integration</span>
<span class="ok">SPAWN Integ  — deps: Web=PASS,iOS=PASS</span>
<span class="ok">  Integ  → PASS  (6m 30s)</span>
<span class="c">[lead] All waves PASS — spawning verdict writer</span>

failure blocking — DB failsconsole

<span class="ok">SPAWN DB     — deps: none</span>
<span class="fail">  DB     → FAIL  (missing migration: add_users_table)</span>
<span class="fail">BLOCK API    — deps: DB=FAIL</span>
<span class="fail">BLOCK Web    — deps: API=BLOCKED (upstream: DB=FAIL)</span>
<span class="fail">BLOCK iOS    — deps: API=BLOCKED (upstream: DB=FAIL)</span>
<span class="fail">BLOCK Integ  — deps: Web=BLOCKED,iOS=BLOCKED</span>
<span class="c">[lead] Run aborted — fix DB failures, then re-run</span>
<span class="c">[lead] BLOCKED validators not counted toward fix-attempt quota</span>

05 Role Responsibilities

Lead Coordinator

Resolves the dependency graph, spawns waves in order, monitors completion, and invokes the verdict writer. Does NOT write evidence — that invariant is load-bearing. A lead that captures evidence has implicit bias.

Platform Validator

Receives its platform's journeys, PASS criteria, iron rules, and evidence path. Executes independently against the real system. Reports via task completion, not messages to other validators.

Design Validator

Visual audit is independent of runtime behavior — always in Wave 1. Checks design token parity, visual regression, and responsive breakpoints. Uses the design-token-audit and visual-inspection skills.

Verdict Writer

Spawned only after ALL validators complete. Reads every evidence directory. Produces per-journey PASS/FAIL with cited files. Missing evidence = FAIL, never INCONCLUSIVE. Writes only to e2e-evidence/report.md.

06 Running Team Validation

full team runconsole

<span class="c"># Multi-platform project (web + api + iOS)</span>
<span class="cmd">/validate-team</span>

<span class="c"># Force maximum validators (5)</span>
<span class="cmd">/validate-team --max-validators 5</span>

<span class="c"># Platform subset (skip iOS, run web + api only)</span>
<span class="cmd">/validate-team --platforms web,api</span>

<span class="c"># Dashboard after run</span>
<span class="cmd">/validate-team && /validate-dashboard</span>

<span class="c"># CI mode — exit 1 on any FAIL or BLOCKED</span>
<span class="cmd">/validate-ci --team</span>

auto-detect config in .vf/config.jsonjson

{
  <span class="key">"platform"</span>: <span class="str">"fullstack"</span>,
  <span class="key">"platforms"</span>: [<span class="str">"web"</span>, <span class="str">"api"</span>, <span class="str">"ios"</span>],
  <span class="key">"enforcement"</span>: <span class="str">"strict"</span>,
  <span class="key">"evidence_retention_days"</span>: 30,
  <span class="key">"team_validation"</span>: {
    <span class="key">"max_validators"</span>: 5,
    <span class="key">"dependency_aware"</span>: true,
    <span class="key">"block_on_fail"</span>: true
  }
}

07 Team Validation Iron Rules

01Never write to another validator's evidence directory

02Never spawn a dependent validator against a failing upstream

03The lead coordinator writes no evidence

04BLOCKED is never the same as FAIL in the verdict

05The verdict writer must read every evidence file, not just inventories

06Partial verdicts are forbidden — wait for ALL validators

07Missing evidence = FAIL, never INCONCLUSIVE

08BLOCKED validators do not count toward fix-attempt quota