Journeys

One flow per journey

A journey is a single path a person takes to get one thing done. Keep the recording to that path. When the path changes, you re-record or edit that flow — not an 80-step mega-script that also logs in, also searches, also checks out.

Typical splits:

• Sign in
• Create or update a record
• Add to cart
• Pay
• Toggle a config or feature flag

Why not one giant recording

Giant recordings fail in the middle and waste the rest of the run. They are also harder to reuse: staging vs prod, a different user, a skip-login when you already have a session. Small journeys compose; a blob does not.

Compose with folders

Put related journeys in a folder and run them in order as a feature suite — login, then payment. Select the set you want; it fail-fasts on the first failure.

Edit instead of re-recording everything

After capture you can change any step: waits, asserts, variables. Optional advanced steps: extract, condition, loop, API call, script, network mock, prompt/OTP. Use those when the UI is awkward (a custom widget, an OTP) — not as a reason to turn one journey into a program.

What a journey is not

This is not a test-management suite, a shared project, or a CI job. A journey is a local flow in Chrome. If you later want it in CI, export Playwright TypeScript and own that file in your repo.