/moai e2e

Creates and runs E2E (End-to-End) tests for web, mobile, and desktop applications. It auto-detects the project type and selects a CLI-first toolchain per platform, executing with token usage minimized.

Info

One-line summary: /moai e2e is a “user-journey verification tool”. It runs real user flows — login → checkout → confirmation — end to end in a browser, simulator, or desktop app.

Info

Slash command: Type /moai:e2e in Claude Code to run this command directly. Typing just /moai shows the list of all available subcommands.

Where a unit test verifies a single function, an E2E test verifies the entire user journey. /moai e2e automates this process — it determines by itself whether the project is web, mobile, or desktop, picks the platform’s default toolchain, then writes and runs the test scripts.

The overall flow:

flowchart TD
    Start["Run /moai e2e"] --> Detect["Platform auto-detection
(project-marker scan)"]
    Detect --> Select["Toolchain selection
(recommended default + user confirmation)"]
    Select --> Journey["User-journey mapping
(routes and docs analysis)"]
    Journey --> Script["Test script creation"]
    Script --> Run["CLI-first execution
(output to files, only a summary in context)"]
    Run --> Record["Recording (optional)
native trace with --record"]
    Record --> Report["Result report
(per-journey status + artifact paths)"]

> /moai e2e

Run without arguments to detect the project type, get the recommended toolchain and discovered user journeys presented for selection, then proceed.

# Run directly with a specific toolchain
> /moai e2e --tool playwright

# Run a single journey only
> /moai e2e --journey login

# Record the run (traces/recordings)
> /moai e2e --record

Each platform has a fixed default toolchain, and every default path is fully executable with the CLI alone.

When the selected toolchain is not installed, the install command is presented first; upon approval it installs, re-verifies the version, then proceeds.

The platform is classified by reading the project’s marker files. Detection is marker-driven — no language or framework receives privileged treatment.

Reads the project docs and route definitions (routes.ts, urls.py, router.go, navigation graphs, etc.) to discover candidate user journeys. Critical paths such as login, the core feature, and error handling come first.

Journey: User Login
Steps:
1. Navigate to /login (web) | Launch app to login screen (mobile/desktop)
2. Enter email
3. Enter password
4. Submit
5. Verify redirect to /dashboard
6. Verify welcome message displayed

Test scripts are written under the e2e/ directory following the selected toolchain’s conventions.

Every journey step pairs with a verifiable outcome — assertion-free navigation scripts are never written.

Runs the tests and reports per-journey PASS/FAIL status, duration, and artifact paths in a table. Failed journeys come with a bounded log excerpt at the failure point plus screenshot paths.

With the --autofix flag, when Phase 3 execution surfaces failures or improvement findings, the orchestrator delegates fixes to the manager-develop agent and re-runs Phase 3 in a loop. The step is skipped when the flag is absent or Phase 3 is green.

flowchart TD
    Run["Phase 3 execution"] --> Fail{"Failure/finding?"}
    Fail -->|"No"| Green["Phase 5 report"]
    Fail -->|"Yes (--autofix)"| Approve["One-time approval"]
    Approve --> Group["Group findings
independent=parallel / dependent=sequential"]
    Group --> Fix["manager-develop
autofix: localize→repair→validate"]
    Fix --> Run

• One-time approval: the orchestrator obtains a single approval before the first delegation; it covers the whole loop and is not re-asked. Declining falls back to the standard manual next-step.
• Finding grouping: independent findings (disjoint files) fan out in parallel; dependent findings (same module) run sequentially to avoid concurrent-write conflicts.
• Loop cap: max 3 iterations (mirrors ci-autofix-protocol.md). On green it reports; on exhaustion it escalates remaining failures + artifact paths to the user.

The core design principle of /moai e2e is CLI-first. Instead of piling verbose output into the AI context, it uses the cheapest path first.

1. CLI + bounded tail: the full run log is saved to a file under e2e/.runs/, and only the exit code + the last few lines appear in context. The log file path is always cited.
2. Structured reporters: for failure triage, it selectively reads only the failed specs from JSON reporter output instead of re-running the full suite.
3. MCP is conditional: MCP tools are used only for capabilities the CLI cannot provide — live performance traces, Lighthouse-class audits. No MCP server is a hard dependency on any default path.

Reports, traces, screenshots, and recordings are stored under the project-local e2e/ directories and cited by path — their content is never inlined into context.

With the --record flag, runs are recorded via the selected toolchain’s native facility.

When no e2e-able surface is detected (for example, a pure library with no web/mobile/desktop entry point), it reports “no e2e target detected” showing which markers it checked, and exits gracefully without creating any e2e/ artifacts.

A native desktop app that is neither Electron nor Tauri (pure macOS app, WinUI, Qt/GTK, etc.) routes to this same branch — OS-level native-desktop automation is not yet provided; a deferral notice is reported with the classification evidence, followed by a graceful exit.

The execution owner of /moai e2e is the e2e-tester agent. All user-facing selection questions belong to the MoAI orchestrator; e2e-tester receives the selections and performs the execution only.

flowchart TD
    User["User request"] --> Orchestrator["MoAI orchestrator"]
    Orchestrator --> Detect["e2e-tester
platform detection + toolchain probe"]
    Detect --> Ask["Orchestrator
toolchain and journey selection questions"]
    Ask --> Exec["e2e-tester
script creation + CLI execution + recording"]
    Exec --> Report["Orchestrator
result report"]

• /moai fix - One-shot auto-fix
• /moai loop - Iterative fix loop
• /moai - Fully autonomous automation