Skip to content

E4: document that Condition 0 must be evaluated first — it is the premature-read guard, not just a liveness floor #1811

Closed

Description

@bradygaster

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_outputs completes.

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

  1. added
    squadSquad triage inbox — Lead will assign to a member
    on Aug 21, 2026
  2. added a commit that references this issue on Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationgh-awGitHub Agentic Workflows integrationsquadSquad triage inbox — Lead will assign to a member

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions