Repository navigation
Description
Problem
Condition 0 in .squad/e2e/E4-agent-binding-verification.md currently does three jobs, but only documents one:
| job | status |
|---|---|
liveness floor — ≥1 issue created by activate |
designed and documented |
| seed exclusion — census by author, excluding seed issue | patched in after the 48-second hole |
| premature-read guard | undocumented and unowned |
Why the third job exists
The #1784 measurement is a safe_outputs effect — job 5 of 6 in the gh-aw pipeline (pre_activation, activation, agent, detection, safe_outputs, conclusion).
agent ✅ lands before the label state is written. Reading at that moment fails in both directions, depending on instrument:
| read prematurely | symptom |
|---|---|
| label census | false RED — the three pre-existing squad:lead/squad:devrel/squad:reviewer definitions look like a confirmed #1784 reproduction |
timeline labeled events |
vacuous GREEN — Condition 2 "passes" on an empty event list |
Switching instruments does not help: the hazard is temporal, not instrumental.
Condition 0 catches both, because a premature read yields zero Squad-authored issues → INCONCLUSIVE → stop before 1–3 are scored. A premature read and a dead pipeline are indistinguishable at the census, which is exactly why the same check covers both.
Why this is fragile
This robustness is accidental. Nobody wrote it down. The condition says it is a liveness floor, so a future reader who can see the run is obviously alive will reasonably move it later or drop it as ceremony. The timing guard then disappears silently and nothing fails — both hazards only fire on an early read, which is rare and unlogged. It returns weeks later as a false red or a vacuous green with no connection to the edit.
Fix
One sentence, living next to the condition it protects (not in a session log):
Evaluating this first is what makes Conditions 1–3 readable. A premature read is indistinguishable from a dead pipeline here, so this check also guards against reading the label state before
safe_outputscompletes.
Plus a line in the capture procedure: wait for all six jobs including conclusion; agent ✅ is not sufficient.
Context
Found during the E4 staged walk (2026-08-21), gate 8 of 8. Raised by EECOM off a corrected relay about the pipeline's job count. The correction — "I read a mid-run job list as the pipeline's shape" — is what generated the hazard; the corrected fact alone would not have.
Owner: Sims (owns .squad/e2e/E4-agent-binding-verification.md). Not urgent for the 9am series — Condition 0 works today; this protects it from being refactored away.
Activity
docs(e2e): amend E4 for #1811/#1812, formalize E1 Rule D gate, add fo…