E1/E4 hardcode a deleted fixture repo — repoint to octodemo/aspiregregator-squad-e2e #1851

Problem

.squad/e2e/E1-merge-continuation-relay.md and .squad/e2e/E4-agent-binding-verification.md both hardcode the fixture bradygaster/aspiregregator-squad-e2e. That repository no longer exists — all test repos were deliberately deleted. Verified with private-repo visibility as bradygaster; it is absent from a 200-repo listing, so this is deletion rather than a permissions artifact.

Both E-scenarios are therefore unrunnable as written, which blocks the M2 — E2E verdict milestone, which in turn hard-gates M3 and M4.

Replacement fixture

Created octodemo/aspiregregator-squad-e2e (internal) as a clean copy of bradygaster/Aspiregregator, which is the pristine origin template the old fixture was itself derived from.

• Repo name is deliberately identical, so E1's validation rule at L127 — "the URL path MUST contain /<fixture-repo>/actions/runs/" — continues to hold unchanged.
• Only the owner differs, so the fix is confined to the $FIXTURE assignments.
• Starting state is pristine: .github/workflows only, no .squad/, matching what E4 Phase 0 expects to squadify.
• Lives in octodemo because Actions minutes must not bill to the bradygaster org. octodemo policy blocks public repos, so it is internal.

bradygaster/Aspiregregator is read-only — the leave-it-alone origin. Copy it; never modify it. Confirmed untouched by this work (pushedAt unchanged at 2026-08-08T03:43:21Z).

Work

1. Repoint $FIXTURE in E1-merge-continuation-relay.md (L4, L136) and E4-agent-binding-verification.md (L27, L348) to octodemo/aspiregregator-squad-e2e.
2. Update .squad/e2e/README.md §Fixture, which names the old repo as the target of all E-scenarios.
3. Prefer a single declared fixture constant per document over repeated literals, so the next migration is a one-line change.
4. E4 Phase 0 needs review beyond a rename. It pins seed issue Agent progress updates: surface periodic status during long-running work #22, cites prior run IDs (32432129404 → 32433493989), and byte-compares source against the fixture's own copies. A from-scratch fixture has none of that history, so Phase 0's refresh/freshness gate needs re-derivation rather than a find-and-replace.

Note on procedure durability

E4 Phase 0's refresh procedure assumed the fixture would persist. It did not, and there is no recorded decision covering its disposal. Worth deciding whether E-scenarios should provision a fixture from the template as step zero — making them self-contained and repeatable — rather than depending on a long-lived repo that can vanish between runs.

Owner

Sims owns the E-scenarios. Related: #1822 (E4 Phase 3b manufactures dispositive PASS values), which must land before any E4 re-run is trustworthy.