9 Rules.
Zero exceptions.
VF rules are installed to .claude/rules/ via /forge-install-rules and loaded automatically by Claude Code. They are not suggestions — they are enforcement constraints that hooks and agents check at every step.
# Install to project-level .claude/rules/ /forge-install-rules # Install to global ~/.claude/rules/ (all projects) /forge-install-rules --global # Verify installation ls .claude/rules/ | grep vf- # vf-validation-discipline.md # vf-evidence-management.md # vf-platform-detection.md # vf-execution-workflow.md # vf-team-validation.md # vf-benchmarking.md # vf-forge-execution.md # vf-forge-team-orchestration.md # vf-consensus-engine.md
The no-mock mandate. Never create test files, mocks, stubs, or test doubles. Always build and run the real system. Every PASS/FAIL verdict must cite specific evidence — screenshots, API responses, build logs — that a skeptical reviewer can open and read.
- Build passing ≠ feature working
- Type-check clean ≠ UI rendering correctly
- No lint errors ≠ user journey functional
The 7-phase pipeline: RESEARCH → PLAN → PREFLIGHT → EXECUTE → ANALYZE → VERDICT → SHIP. Every validation run walks these seven phases in order. Build success at phase 2 does not imply feature correctness — that happens at phase 3, against the real running system, with evidence captured at every step.
- RESEARCH: standards, applicable criteria (WCAG, HIG, security)
- PREFLIGHT is a hard gate — failure halts the run
- EXECUTE runs against the REAL system, not a mock
- VERDICT cites evidence paths, not build output
Directory structure, naming convention, quality standards, and retention policy for all validation evidence. Evidence follows a structured lifecycle: captured at execution time, preserved post-FAIL indefinitely, eligible for cleanup after the configured retention window (default 30 days).
- File names: step-{NN}-{action}-{result}.{ext}
- Every journey dir needs evidence-inventory.txt with byte counts
- 0-byte files are INVALID evidence — enforced by hook
- Archive before purge: tar -czf before any cleanup
Detection priority order and platform-specific validation toolchain routing. VF detects iOS before React Native before Flutter before CLI before API before Web. Each platform maps to a specific start command, validation tool, and evidence method.
- iOS: .xcodeproj, .xcworkspace, *.swift, Package.swift
- Web: package.json + framework config (next.config, vite.config)
- HIGH confidence required before starting sweep
- LOW confidence → ask user to confirm platform
Multi-agent validation coordination. Each validator owns its evidence directory exclusively. Validators execute in dependency-aware waves: DB → API → Web/iOS (parallel in Wave 3). A FAIL in any wave marks all dependent validators BLOCKED — not FAIL. Blocked validators are never spawned.
- One validator per platform, max 5 per run
- No validator writes to another validator's directory
- Lead orchestrator does NOT write evidence
- BLOCKED ≠ FAIL: blocked means upstream broke, never ran
Metric collection, integrity rules, and comparative analysis for /validate-benchmark. All metrics are calculated from actual evidence files and timestamps — never estimated. Coverage = validated / total; evidence quality = files examined / files claimed. History appended, never overwritten.
- Coverage 35%: validated journeys / total discoverable features
- Evidence Quality 30%: citations, observation quality, verdict rigor
- Enforcement 25%: hooks on, no test files, no mocks, rules active
- Speed 10%: wall clock time relative to project size
Phase gate protocol, fix-loop discipline, and state persistence for the FORGE engine. Forge commands treat the pipeline as strictly sequential with hard gates — preflight failure halts the run completely. Each fix attempt must target a DIFFERENT root cause. Evidence is never reused across attempts.
- Max 3 fix attempts per journey. 4th attempt = UNFIXABLE
- Each attempt writes to forge-attempt-N/ — fresh evidence only
- Retrying the same hypothesis counts as a failed attempt
- State persists to .validationforge/forge-state.json for resume
Validator assignment, evidence ownership, verdict synthesis, and failure-blocking rules for /forge-team runs. Each validator receives ONLY its platform's journeys. FAIL propagates: every downstream platform is marked BLOCKED. The verdict writer spawns only after ALL validators complete.
- One validator per platform, maximum 5 per run
- FAIL propagates to all downstream platforms
- Partial verdicts are forbidden — wait for ALL validators
- Verdict writer reads every evidence file, not just inventories
Execution-time agreement gate for high-stakes features. N independent validators (default 3) run the same journey list blind to each other's verdicts. The synthesizer applies synthesis states (UNANIMOUS_PASS / MAJORITY_PASS / SPLIT) and computes a confidence tier (HIGH / MEDIUM / LOW). SPLIT is a real outcome — the synthesizer never invents agreement.
- HIGH confidence requires unanimity (agreement_ratio = 1.0)
- MEDIUM: ≥⅔ PASS after disagreement analysis resolves it
- LOW / SPLIT: escalate to human, never silently downgrade
- Evidence directories are exclusive — cross-writes invalidate the run