Krzemienski Validationforge E2e Validate

ValidationForge: End-to-End Validation Orchestrator

When to use this skill

Reach for e2e-validate when you need to run validation end-to-end and aren't sure where to start. It figures out the platform, chains the right platform-specific skill at each phase, and ties everything together with a single verdict.

Use a platform-specific skill instead (e.g., flutter-validation, api-validation, ios-validation) when you already know your platform and just need the validation protocol for it. e2e-validate will call those same skills under the hood during execution — they're the detailed playbooks, this skill is the conductor.

Scope

Handles: platform detection, journey mapping, PASS criteria definition, evidence capture and review, PASS/FAIL verdict writing, fix loops, and CI/CD report generation.

Does NOT handle: individual gate evidence examination (gate-validation-discipline), mock pattern detection (no-mocking-validation-gates), isolated plan generation (create-validation-plan).

Iron Rule

IF the real system doesn't work, FIX THE REAL SYSTEM. NEVER create mocks, stubs, test doubles, or test files. ALWAYS validate through the same interfaces real users experience. ALWAYS capture evidence. ALWAYS review evidence. ALWAYS write verdicts. Evidence you don't READ is evidence you don't HAVE.

See no-mocking-validation-gates for mock pattern detection and blocking rules.

Platform Detection

Scan project root. First match wins — priorities are ordered so mobile > CLI > server > browser, because the more specialized the runtime, the narrower the validation approach.

When signals conflict

• Next.js with API routes: both frontend and backend signals match. Treat as fullstack — the web UI and API tests both run, but from one codebase.
• Django + React SPA: Django's manage.py matches priority 7, React matches priority 6. Django wins. Use django and validate the React frontend as part of the Django flow.
• iOS app with a Node.js companion server in the same repo: iOS wins by priority. Spin up a separate validation run for the server with --platform api --scope ./server.
• Next.js SPA, no backend: no API routes → web, not fullstack.
• Monorepo with both a mobile app and a web app: run two separate validations, one per subpath, with --scope set accordingly.

If the auto-detected platform is wrong, override with --platform <type> and re-run.

Automated detection: bash scripts/detect-platform.sh --project-dir=. --json prints the resolved platform + signals in JSON. Use this when you want deterministic platform-gating in CI.

Auto-detection script: scripts/detect-platform.sh (in the plugin root).

Preflight Gate (MANDATORY — Iron Rule #4)

Before any workflow below executes, the preflight skill MUST run and its verdict MUST be CLEAR (or WARN with documented acceptance). This is not optional — CLAUDE.md Iron Rule #4 states: "NEVER skip preflight — if it fails, STOP."

• --execute, --fix, --audit → invoke preflight first; abort on BLOCKED; continue on CLEAR/WARN.
• --analyze, --plan, --report → these are read-only against source files; preflight is still recommended but non-blocking (the skill will emit a soft warning if prerequisites are missing so downstream phases can plan around them).
• --ci → preflight runs as Step 1 of workflows/ci-mode.md; a BLOCKED verdict exits with code 2 (pipeline error).

The preflight step writes its report to e2e-evidence/preflight-report.md. Subsequent workflow phases must read that report before starting.

Command Routing

Start with no flag (full pipeline). Use the others when you need a specific phase in isolation.

Modifiers: --platform <type> (override detection), --scope <path> (limit scope), --parallel (sub-agents), --verbose (inline evidence), --skip-preflight (emergency override; logs a warning — only when preflight itself is broken, never to bypass a legitimate BLOCKED verdict).

Validation Order

Always validate bottom-up: Data Layer → Backend API → Frontend Logic → UI/CLI.

Why bottom-up? Higher layers depend on lower ones. A broken database makes every API call fail; broken API endpoints make every UI flow fail. If you test the UI first, every failure looks like a UI bug even when the real cause is three layers down. Starting at the bottom isolates root cause cheaply — each layer is independently verifiable, and once a layer is green you trust it for the next one up.

What bottom-up looks like per platform:

• fullstack: DB migrations → API endpoints (curl) → UI flows (Playwright)
• mobile: deep-link routing → data fetching / storage → UI screens → user journeys
• API: DB connectivity → health endpoint → auth → CRUD
• CLI: argument parsing → core operation → output format → exit codes

Bottom-up doesn't always apply: a pure CLI with no persistence is basically one layer. Use judgment — the point is to find causes before symptoms, not to follow the order dogmatically.

Platform References

Workflow Files

Success Criteria

Validation is complete only when all applicable criteria are true. The first seven apply to every platform. The last two depend on what kind of evidence the platform produces.

Rules

1. Never skip platform detection — wrong platform = wrong validation approach
2. Never execute without a plan — PASS criteria must exist before evidence capture
3. Never claim PASS without cited evidence — see gate-validation-discipline
4. Always validate bottom-up for fullstack projects

Security Policy

Evidence directories may contain screenshots of authenticated screens or API responses with tokens. Store in e2e-evidence/ (gitignored). Never commit evidence containing credentials or PII to public repositories.

Related Skills

Core skills used on every run (already loaded as critical priority):

• functional-validation — the core protocol each workflow calls into
• create-validation-plan — invoked during --plan
• gate-validation-discipline — evidence verification during verdict writing
• no-mocking-validation-gates — catches mock patterns during analysis
• preflight — environment checks before execution
• error-recovery — 3-strike recovery during --fix
• verification-before-completion — pre-completion checklist

Loaded on demand when the workflow reaches their phase:

• full-functional-audit — when --audit is set
• baseline-quality-assessment — during analysis
• condition-based-waiting — during execution, for flaky waits

Platform-specific skills are loaded at execute time based on detection. See the Platform References table above.

Source: krzemienski/validationforge — distributed by TomeVault.