e2e-red-triage, for the reds the preflight could not have predicted

Terms are as in e2e-environment-preflight: a row is one acceptance check in the test plan, a red is a row that failed or gave no answer, a journey is one end-to-end scenario made of rows, the suite is all the rows of a journey, and preflight is the set of environment checks that must be green before the first row runs.

Never auto-triggered, and normally never needed. One caller, the agent running the suite, and one moment:

The e2e-environment-preflight checks were all green, and a row went red anyway, or produced a null, an empty, a zero, or a silence nobody can yet explain.

If preflight was not green, the suite should not have started. If a red is an ordinary product failure with a clear cause, fix it and move on; this is not the ceremony for an ordinary bug. This is the residual after the gate has done its work, a small fraction, and one that shrinks every time move 3 is honoured.

Why this needs its own protocol

The preflight handles the failures somebody could enumerate in advance. What is left is the class where the failure produced nothing rather than an error, and the nothing appeared far from its cause. One null can mean five different things across five runs of the same suite; "no results" can mean the query matched nothing or the search never ran.

The hours such a red costs are spent attributing an absence, arguing about what a missing thing meant, from evidence that never contained the answer. Guessing feels faster than instrumenting and is not: a wrong guess costs a full suite run to disprove, and a plausible wrong guess is worse than an implausible one because it stops the search.