## Red on main
#2783 (batch-core) landed and put **5 failures** on `main`. Both causes
are the bookkeeping half of correct changes, not defects in them.
## 1. The census baseline — 4 failures
`census-baseline-corruption-guard` plus 3 `lifecycle-column-census`
ratchet cases, all downstream of one thing:
```
lifecycle-column-census --strict: column-guard count ROSE
packages/core/src/task-move-disposer.ts (DELIBERATE-LITERAL: in-progress): 0 -> 1
packages/core/src/task-move-disposer.ts (DELIBERATE-LITERAL: todo): 0 -> 1
packages/core/src/task-store/archive-lifecycle-2.ts (DELIBERATE-LITERAL: archived): 0 -> 1
packages/dashboard/src/github-tracking-comments.ts (DELIBERATE-LITERAL: done): 0 -> 1
packages/dashboard/src/gitlab-tracking-comments.ts (DELIBERATE-LITERAL: in-progress): 0 -> 1
packages/dashboard/src/server.ts (DELIBERATE-LITERAL: archived): 0 -> 1
```
**The rise is legitimate.** #2783 *annotated* documented fast-path
literals — e.g. `task-move-disposer.ts`'s *"a fast path, not the guard …
the actual lane decision is the RESOLVED membership test inside this
block"* — and the census tracks marked literals per file. Re-recorded
with `--strict --update-baseline`; the same run also **tightened 20
entries whose counts dropped**, so this moves the ratchet down as well
as up.
## 2. The disposal-order test — 1 failure
```
executor-user-cancel > re-dispatch (task:moved → in-progress) awaits prior disposal before execute()
AssertionError: expected -1 to be greater than 2
```
`-1` reads like the re-dispatch was **dropped**. It was not — that would
be a real cancel-race bug, so I checked before touching the test:
```
PROBE_MICROTASK callOrder=["abort-started","abort-resolved","dispose","execute"]
PROBE_AFTER_TIMER callOrder=["abort-started","abort-resolved","dispose","execute"]
```
Correct order, reached once drained, unchanged after a real 50ms timer.
The test drained exactly **two** microtask turns and #2783's disposer
refactor added await hops, so `execute` had not been recorded yet.
A fixed turn count encodes today's await depth into the test: any added
`await` on the product path fails it for a reason that has nothing to do
with the invariant. It now waits on the **outcome** via `vi.waitFor`.
The ordering assertion is untouched and is still the point.
## Evidence
| mutation | result |
|---|---|
| `execute` never recorded (stands in for a dropped re-dispatch) |
**fails** — `waitFor` times out |
| `execute` observed *before* `dispose` | **fails** — `expected
'execute' to be 'dispose'` |
| baseline: fresh `--strict` run | *"every file matches its baseline
exactly"* |
Engine **10985 passed / 0 failed** (was 5 failed) · gate **732 green** ·
lint clean.
## Method note, against myself
I pre-flighted #2783 and **reported it clean** — but I ran only
`@fusion/core` and the dashboard `api` group, because that is what the
diff touches. The census and disposal tests live in `packages/engine`,
which batch-core does not modify at all.
**The suite that breaks is not always the suite the diff points at.** A
cross-package ratchet like the census is exactly the case where scoping
pre-flight to the changed packages produces a confident "clean" that is
wrong. Pre-flight needs the engine suite regardless of which package a
batch touches; I have adjusted accordingly for the remaining queue.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
9fab32e1d9