Expert — Getting Started
This manual assumes you have touched Playwright or Maestro at least once, have lived through a flaky e2e run and wondered why, and have handed work to Claude Code or Codex at some point. Hearing the term POM before is enough. The directory layout, auth reuse, and track separation are picked up in the next section, architecture.
If you have used another ddakit base, start with this difference. chrome-ext and saas-base build an app. e2e-base does not. It verifies, automatically, that an existing external app behaves the way it was described. So the “building” sections like build-and-package, real-backend, and customize-design are absent here. Their seats go to tracks, analyze-and-design, and verification.
The output is a test suite; the SUT lives outside
Section titled “The output is a test suite; the SUT lives outside”What you verify is called the SUT (System Under Test). It might be an app you built or one someone else built, reached as a deployed URL, a local dev server, a built binary, or an Expo/RN/native build. What you get from forking e2e-base is a tests/ tree that bolts onto that SUT. It is not the app source.
That frame runs through the whole manual. “How do I build the app I want to test?” is not a question this base answers. That belongs to a different base.
Three tracks
Section titled “Three tracks”You pick a track by target type. All three can coexist in one suite, but most setups use only one or two.
| Track | Default tool | Alternative |
|---|---|---|
| web | Playwright | Cypress (only for legacy compatibility) |
| electron | Playwright _electron | @wdio/electron-service (packaged-build verification) |
| mobile | Maestro | Detox (RN), Appium (general), XCUITest/Espresso (native) |
The tracks do not get split across pages. All three share the same Phase 1 through 6 workflow, and the differences sit in tool detail rather than in the flow, so the tooling wiring is gathered into a single table on the tracks page.
S6, the production ban
Section titled “S6, the production ban”One guardrail is worth naming up front. Tests never connect to a production SUT or a production database. They run only against local, staging, or a dedicated test environment. “I’ll just point the tests at the live server” is the most dangerous misread in this domain. The rest of the S1 through S8 security baseline and the forbidden patterns are gathered in verification.
The automation entry points point at one place
Section titled “The automation entry points point at one place”The Claude Code entry points are .claude/agents/ and .claude/skills/; the Codex entry point is AGENTS.md at the repo root. Both routes end up reading one file — AI_AUTOMATION.md. The test architecture rules, the S1 through S8 security baseline, the forbidden patterns, the six-dimension review rubric, and the Phase 1 through 6 flow all live there. Two tools share one canonical document, so a decision settled in Claude Code carries through a Codex session as well.
The no-contamination rule
Section titled “The no-contamination rule”Right after you fork the base, tests/ is empty. Runtime artifacts like feature_list.json, active.md, and progress.md do not exist yet. The first /start the forker runs generates an empty template, and from there the seats fill in as the phases run. What this manual teaches is the procedure that fills that empty skeleton through the phase flow — not a reference test suite for e2e-base itself.
License
Section titled “License”The manual and the landing site are public, but the template itself is on a commercial license model. Redistributing forked code is not permitted.
What this manual does not assume
Section titled “What this manual does not assume”OS-specific install branches, the Playwright browser or Maestro CLI install screens, a step-by-step walk for someone meeting a terminal for the first time — none of that lives here. For that, use the Beginner manual. Same base, a different pace.
Architecture comes next. How the tests/{web,electron,mobile} directories split, how POM and fixtures tie together, and how one line of scenario becomes one test, with two diagrams.