## What this is
#3251 audits the five lifecycle ratchets with staged probes and claims a
gap in mine:
> `check-inert-sync-lane-conversions` — does NOT catch: a DIRECT
`store.resolveTaskWorkflowIrSync(...)` read feeding
`resolveLifecycleColumns`
I tested it rather than accepting it, and got a **split result**: a
probe inserted into the existing `executor.ts` was **caught** (19 → 20,
exit 1), refuting the row; a standalone probe file was **missed**
(stayed 19, exit 0), confirming it. Two probes of nominally the same
thing disagreeing means one of them is describing something else.
## The actual mechanism
Instrumenting a copy of the script ruled out the file-discovery
explanations: `scanned files: 1850 | probe in list: true`, and the
probe's function `isReview` was collected into the sources list. So the
file is scanned, the function is tracked, and the guard is still not
counted — the loss is downstream, in expression walking.
The one syntactic difference between the two probes was a cast.
Measured, holding everything else fixed:
| argument to `resolveLifecycleColumns(...)` | before | after |
| --- | --- | --- |
| `store.resolveTaskWorkflowIrSync(id)` | caught (20) | caught (20) |
| `store.resolveTaskWorkflowIrSync(id) as never` | **MISSED (19)** |
caught (20) |
| `store.resolveTaskWorkflowIrSync(id)!` | **MISSED (19)** | caught (20)
|
| `(store.resolveTaskWorkflowIrSync(id) as any)!` | **MISSED (19)** |
caught (20) |
So: the direct read **is** tracked. The **cast around it** was not.
`unwrapForSyncCall` unwrapped `await`, parentheses, conditionals,
binaries and (since #3181) call arguments — but stopped at `as`,
`satisfies`, `!` and angle-bracket assertions.
**Correction to #3251's row, not a rejection of it.** The gap is real
and reproducible; the stated cause ("a direct read is untracked") is not
the one operating. That distinction matters for anyone acting on the
table: fixing "track direct reads" would have changed nothing.
## The fix
One walker clause, alongside the existing `await`/parenthesized unwrap.
Real tree unchanged at **19 guards / 3 files, exit 0** — this adds no
backlog, it closes a blind spot.
## Why it is the same story a seventh time
Inline → membership → cross-module → wrapper argument → census
switch/includes → ternary destination → **type assertion**. Across three
different tools, the rewrite that hides a guard is the one that changes
its *syntactic category* without changing its meaning.
Type assertions are the purest case yet: `as`, `satisfies` and `!` are
**erased at runtime**. They cannot alter behaviour at all — they can
only alter visibility. A guard wearing one is byte-identical in outcome
to the same guard bare, and scores as absent.
## Verification
- Mutation-verified in both directions: with the fix reverted all three
cast forms read 19; with it applied all read 20.
- All eight ratchets exit 0: `inert-sync-lanes`, `lifecycle-columns`,
`fnxc-future-dates`, `quarantine-ledger`, `move-target-literals`,
`inert-flag-seams`, `lane-wiring`, `sql-column-literals`.
- `pnpm test:gate` exit 0 (which runs this script since #3136).
- Every probe removed; `git status` clean before each measurement.
## What I did not do
I did not re-audit the other four ratchets against cast-wrapped probes.
#3251's staged-probe method is the right instrument for that and it is
that author's file; if the same blind spot exists in the census or the
flag-seam checker, it will show up as a cast form scoring zero. Worth
one pass by whoever owns those.
cf4418e3db