aedee4b8231bf050c3240a00ab6645ede5d87ee9
1 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
gsxdsm
|
13bf7e001d |
Closing-bar verification pass on origin/main — one tree, one report (+ the E2E red it found) (#2660)
**Closing-bar item 4, run on one clean tree at `origin/main` (`be63e72f1`).** Nobody was assigned this and my own work is merged, so I took it. > **This PR is now REPORT-ONLY — net zero file changes.** I found the planning-lane E2E red, fixed it, then discovered **#2658 (gsxdsm) makes byte-for-byte the same change** to the same helper and was opened first. I reverted mine rather than leave two identical edits to one function to conflict. **The E2E result below depends on #2658 landing** — on `origin/main` without it, that suite is 2 failed / 5 passed. > > The duplication is worth one note for the fleet: two workers independently hit the same control-card failure and independently traced it to FN-7648's unplanned-seed gate plus a fixture that never wrote a spec. Independent confirmation of the diagnosis, but also ~an hour spent twice — the census-style work order exists to stop exactly that, and E2E fixture defects are not on it. ## Report — all four, one tree | Check | Result | |---|---| | `pnpm test:gate` | **PASS** (132 + 10 + 487 + 71 tests) | | `pnpm verify:fast` | **PASS** — 13 steps green in 89.9s, boot smoke `GET /api/health 200`, clean shutdown | | E2E families | **13 files / 109 tests PASS** — *after* the fix below; **2 failed** before it | | census | total **787**, triage **10** | ## Two corrections to the bar itself **1. It is not "all-8 E2E" any more — there are 13 families.** The suite grew while the bar was being written: ``` agent-count · agent-link · lease-rebound · lifecycle · merge-family · merge-rebound merge-safeguards · merged-board · planner-lane · planner-lane-resolution planning-lane · rebound-family · stranded-column ``` A verification pass scoped to 8 would have skipped 5 families — including the one that was red. Worth fixing the number in the bar so the final pass globs rather than counts. **2. `DELIBERATE-LITERAL (reviewed)` reads 3, and I chased it — RESOLVED, no gap.** I flagged the drop from an earlier "7" as a possible fleet-safety hole. It is not one. Reconciled against `--json byFile`: | File | markers | counted `deliberate` | counted `column` | |---|---|---|---| | `hold-release.ts` | 2 | **2** | **0** | | `live-agent-count.ts` | 1 | **1** | 6 | | `replan-target.ts` | 2 | 0 | 4 | `deliberate: 3` = hold-release 2 + live-agent-count 1, which is exactly the set of marker-covered **comparisons**. `replan-target.ts`'s two markers sit above `return "triage"` **return-value** literals, not comparisons — the census correctly does not count those as guards at all, so they are neither `deliberate` nor `column`. The earlier "7" was simply a different tree state before conversions landed; I was quoting a stale number. Worth noting the marker matcher is already hardened for the subtle case: `hasDeliberateMarker` walks every **ancestor** rather than the enclosing statement, because the real markers sit above the enclosing *function* while the comparison is a `return` inside it — a statement-only lookup "silently reclassified three reviewed literals as backlog". That is the guard-cannot-fire pattern, already caught and fixed by whoever wrote the AST version. **Consequence for the fleet: the census's categories are trustworthy as-is.** No pre-launch action needed on this. ## The red it found `workflow-planning-lane-live-e2e.pg.test.ts` — **2 failed / 5 passed**, including its own **control** case: ``` releases an ordinary held card on a default board (the control) → AssertionError: expected [] to include 'FN-OK' ``` `seedHeldTask` never wrote a `PROMPT.md`, so task creation's bootstrap seed stood, and FN-7648's `isUnplannedForExecution` correctly refused to release an unspecified card. **The sweep was right; the fixture was asking it to release a card that had never been specified.** **This is the second instance of the identical defect** — same cause and same fix as `workflow-lifecycle-live-e2e`'s `seedTask` in #2634. This suite was written after that fix and did not inherit it. The graph-entry contract doc already states the rule: *"Scheduler/release test fixtures must model a card that cleared the gate ... A held unreviewed card is the gate working."* Both failures had one cause — the mid-sweep approval-park case was downstream of the control never releasing. **5 → 7 passed**, and cards that are *supposed* to be held still are, held by their own status/marker, which is what those cases assert. Given it has now happened twice, a shared `seedPlannedTask` helper in the E2E fixture module would prevent a third. I did not add one here: it touches suites owned by U7 and U11 mid-consolidation, and this PR should stay the verification pass plus its one finding. ## Bar status after this - **gate / verify:fast / E2E** — green on one tree, with this commit. - **triage → 0** — still **10**, all in U12's `moves.ts` (4) and `register-task-workflow-routes.ts` (1) per file scan; flag resolution in flight. - **ratchet tightened (item 2)** — not done, U12's. - Once triage hits 0 and the ratchet lands, re-running this exact pass is a ~4-minute job and I can produce the final report. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |