/e2e-environment-preflight

name: e2e-environment-preflight
description: "Check external services, hosts, browser sessions, model endpoints, and agents before an end-to-end run. MANUAL-ONLY: load when a caller names it. NEVER auto-load from context for ordinary testing or debugging."
requires:
  programs: []
  harness:
    - {slot: 4.shell, need: required}
    - {slot: 4.file-read-write, need: required}

e2e-environment-preflight — the gate that runs before the first row

**Never auto-triggered.** Named callers only:

| Caller | Moment | |---|---| | A requirements document or test plan | once end-to-end proof is required and the document names an external system | | A task brief | before staffing any end-to-end journey | | `e2e-red-triage` | when a red turns out to be environmental and owes a new check |

This skill is self-contained: the trigger and the three artifacts.

Terms: the **owner** is whoever owns the work, usually the user; a **row** is one acceptance check in the test plan; a **journey** is one end-to-end scenario made of rows; a **red** is a row that failed or gave no answer; the **suite** is all the rows of a journey.

**Each repository binds this locally.** A repo-level `e2e-environment-preflight` names its own systems, its own primer directory, its own evidence paths, and its own configuration decisions. This file is the contract; the local one is the address book. If the repository has no local binding, the first journey that needs one writes it.

The trigger, as an operational test

> The preflight is required when **any acceptance row's evidence comes from a system outside the > repository under test** — a running service, a host, a browser session, a live model endpoint, > an installed agent. Rows whose evidence is produced entirely by code in the repository do not > trigger it.

The test plan or requirements document states the answer as one of two literal forms:

External systems: none — <scope fact> External systems: <name>, <name> — preflight required

A library with no external systems answers `none` and never sees this skill again. **A plan that names a system for which no primer exists does not pass** — that refusal is how the first primer for a system gets written, without anyone having to remember to write it.

Why this exists

The three classes that reliably burn days — anything with a login, anything driving a browser, anything driving another agent — share one property: **when they break they produce nothing rather than an error, and the nothing appears far from the cause.** A revoked credential still reads as valid locally. A missing profile looks like an empty result. A dead actor looks like a slow one.

So an hour goes into attributing an absence, and goes again next month on the next system. The preflight moves that cost to the front, where it is paid once and mechanically.

Three reasons it is a gate and not a checklist: **you cannot tell a product defect from a setup defect** once the suite is running; **every mid-run fix invalidates the rows already passed**, so the suite stops being one observation and becomes N observations of N environments; and **fix-one-rerun is a serial loop with a full suite inside it** — twelve missing preconditions found one at a time cost twelve suite runs, found together they cost one repair pass.

**No row starts while any check is red. Amber is red.** A check going red at row 14 stops there: the run is void, rows 1–13 do not carry over, repair happens outside the run, and the preflight runs again from the top.

Two stages, in this order

Checking before the configuration is settled is checking against nothing. These are defaults; a project may choose otherwise and record it in its local binding.

**Stage A — settle the decisions.** Some preconditions cannot be checked because nobody has said what correct means. A product with several valid configurations has no wrong setting to detect; run the suite against whichever one happened to be set and it measures an arbitrary configuration and answers a question nobody asked.

The sorting test is one sentence: **if two defensible answers would make the same row pass and fail, it is the owner's decision.** Everything else the agent settles from the approved plan, the repository, or a written ruling — handing those up is noise, and noise makes the real questions get skimmed.

Always the owner's, and most often forgotten: **the ceilings** — wall-clock, spend, and which hosts may be destroyed. Ask with a recommendation derived from a measured sample. Without a recorded ceiling the budget check cannot be green or red at all, and an executor invents one, silently changing what *pass* means.

**Onboarding is part of this and is the part that gets skipped.** A run of a real flow starts where a real user starts. If the product has a first-run path, the preflight names which path the run takes. A suite that begins after onboarding has excluded the part most likely to break for a new user, and it keeps passing while every new user fails.

Collect the owner's set from the whole plan first and ask in **one** exchange, each item with options, downstream consequence, and your recommendation. Answers become configuration-of-record in the preflight artifact — a configuration that lives only in a chat window cannot be reproduced and cannot be cited.

**Stage B — derive the checks.** The standing floor — the checks every run needs whatever the plan says, such as the credential and absent-variable checks below — always applies. The project half is read off the approved plan, never invented: every actor (service, agent, or process) named alive during the test, every artifact path in an evidence requirement, every capability a planted defect needs. A precondition no row needs is not added; a row whose preconditions were never extracted is a defect in the plan.

**A plan cannot name a precondition its author does not know exists.** That is what the primer supplies, and it is why Stage B depends on on