root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
13,621 Commits 1 Branch 0 Tags
aedee4b8231bf050c3240a00ab6645ede5d87ee9
Commit Graph

9 Commits

Author SHA1 Message Date
gsxdsm
ebe514c3e4 FN-8677: propagate task update lanes before conversion 
Propagate cache-warmed workflow lanes through task updates so synchronous engine consumers support renamed boards.

- Add task lane cache and attach resolved lanes to task:updated metadata.
- Update scheduler, triage, and notification consumers to use carried lanes with bridge-safe fallbacks.
- Cover lane propagation and renamed-lane event behavior with core and engine tests.

Files changed:
 .changeset/fn-8677-manual-merge-hold-lanes.md      |   7 ++
 .changeset/task-updated-carries-lanes.md           |   7 ++
 ...orkflow-ir-readers-always-return-the-default.md |  22 +++++
 .../sync-workflow-ir-second-blocker.test.ts        |  43 +++-----
 .../core/src/__tests__/task-lane-cache.test.ts     |  30 ++++++
 .../task-updated-lanes-emit-surfaces.test.ts       |  92 ++++++++++++++++++
 .../__tests__/task-updated-lanes-payload.test.ts   |  42 ++++++++
 packages/core/src/index.ts                         |   1 +
 packages/core/src/store.ts                         |  36 ++++++-
 packages/core/src/task-lane-cache.ts               |  63 ++++++++++++
 .../core/src/task-store/archive-lifecycle-2.ts     |   3 +
 packages/core/src/task-store/moves.ts              |   1 +
 packages/core/src/task-store/task-artifacts-ops.ts |   1 +
 packages/core/src/task-store/task-update.ts        |   1 +
 packages/core/src/task-store/update-task-deps.ts   |   4 +-
 .../core/src/task-store/workflow-definitions.ts    |  71 +++++---------
 .../__tests__/scheduler-task-updated-lanes.test.ts | 108 +++++++++++++++++++++
 .../task-updated-lanes-bridge-compat.test.ts       |  94 ++++++++++++++++++
 ...task-updated-lanes-engine-emit-surfaces.test.ts | 101 +++++++++++++++++++
 .../src/__tests__/triage-pause-abort.test.ts       |  22 +++++
 .../src/__tests__/triage-planning-wake.test.ts     |  25 +++++
 .../notification-renamed-lifecycle-columns.test.ts |  84 +++++++++++++++-
 .../__tests__/task-wedge-notification.test.ts      |  19 ++++
 .../src/notification/notification-service.ts       |  56 ++++-------
 packages/engine/src/scheduler.ts                   |  62 +++---------
 packages/engine/src/triage.ts                      | 105 ++++++--------------
 scripts/lib/inert-sync-lane-baseline.json          |   5 +-
 27 files changed, 858 insertions(+), 247 deletions(-)

Fusion-Task-Id: FN-8677

Fusion-Task-Lineage: d8fef9db-0f88-4dfd-9813-be25e10e3588

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-08-01 01:15:10 -07:00
gsxdsm
897cce9d94 FN-8656: resolve scheduler lanes for renamed holds 
Resolve scheduler lane lookup against workflow-defined hold and terminal columns.

- Use asynchronous workflow lane resolution after the synchronous event prologue
- Preserve legacy lane fallback and recognize all terminal workflow columns
- Update scheduler regression coverage, sync-lane guardrails, and release notes

Files changed:
 .changeset/fn-8656-scheduler-renamed-hold-lanes.md |   7 ++
 .../sync-workflow-ir-callsite-allowlist.test.ts    |  10 +-
 .../scheduler-renamed-hold-events.test.ts          |  20 ++--
 ...ow-scheduler-parked-columns-live-e2e.pg.test.ts |  13 ++-
 ...-sync-role-conversion-inert-live-e2e.pg.test.ts |   8 +-
 packages/engine/src/scheduler.ts                   | 121 +++++++++------------
 scripts/check-inert-sync-lane-conversions.mjs      |   5 +
 scripts/lib/inert-sync-lane-baseline.json          |   3 +-
 8 files changed, 92 insertions(+), 95 deletions(-)

Fusion-Task-Id: FN-8656

Fusion-Task-Lineage: 389a95a1-289f-4dde-86b3-1e450f8d43db

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-07-31 22:19:32 -07:00
gsxdsm
a6d67844b8 fix(triage): the "unconvertible" site was convertible — the blocker was two test harnesses (#3191) 
#3141 measured this site as unconvertible, and I twice reported the
cause as a production constraint. It was not. This is the instrumented
answer to the probe I recommended there and then ran myself.

## The isolation

| configuration | result |
|---|---|
| flag only, no conversion | **8 passed** → the orphan arm is *not* the
cause |
| flag + conversion | **5 failed** → the conversion is |
| same, with a realistic mock store | **8 passed** → the mock was the
cause |

`triage-stuck-requeue-preserve-draft.test.ts` defined neither
`getTaskWorkflowSelection` nor its async twin — exactly like
`triage.test.ts` did before #3189. Both made
`resolveWorkflowIrForTaskWithProvenance` **throw** and take its catch
branch: the *"could not ask"* shape, which a production store never
presents.

So the 5 failures I deferred as a possible semantics change were the
same harness gap in a second file — confirmed, not argued.

## What changes

**`selectionAbsent`** marks the determinate case: the store *answered*
"no selection", so the workflow is the default and its IR is in hand.
Added as a **separate field, not a third `source` value** — `source ===
"default"` is compared in **31 places** in `self-healing.ts` meaning "be
conservative", and a new enum value would silently stop matching every
one of them while still compiling and still passing on a default board.

**`recoverApprovedTask`** now accepts a legacy `triage` row *explicitly*
(its workflow does not declare that column) instead of depending on
`resolvePlannerLanes` **failing** and falling back to legacy ids.
Correctness resting on a resolver's failure mode is what this removes.

## Measured

| | result |
|---|---|
| broad suite (triage / self-healing / recovery / planning) | **77
files, 1302 tests passed** |
| the three directly affected suites, post-rebase | **245 passed** |
| the flag is load-bearing | conversion **without** it: **18 failed \|
221 passed** |
| `census --strict`, `check-fnxc-future-dates` | exit 0 |

**The inert-sync-lane count is unchanged at 7 for `triage.ts`.** This
site was never among the counted guards, so this is **not** a ratchet
reduction — stating that rather than letting a conversion imply one. It
removes a real inert dependency the ratchet cannot see, which is the
blind-spot class this phase has been mapping.

## Why this took four attempts

I described this blocker at four levels: merged intake/hold, orphan-arm
scoping, identity verification (filed as **#3187**, closed as wrong),
and finally the harness. **The two I instrumented held; the two I
reasoned to did not.** The fix here is the probe I wrote down for
someone else — which is where it should have started.

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 09:36:03 -07:00
gsxdsm
24c565540e gate: a sync lane handed to a wrapper is still inert — 13 scheduler guards were invisible (#3181) 
## The fourth shape: a sync lane handed to a wrapper

#3169 taught `unwrapForSyncCall` to walk await, parenthesized,
conditional and binary expressions. It still stops at the **call
boundary**, so a source call sitting in an *argument* position stays
invisible:

```ts
const parked = mergeParkedColumns(resolveTaskParkedColumnsSync(store, id), lanes);
```

That prefers the event payload and falls back to the sync answer
whenever `lanes` is absent. The callee is `mergeParkedColumns`, not a
source — so the walker never looked inside, and **the entire
`scheduler.ts` file read as clean**.

```
main today:   9   (triage 7, executor 2, scheduler 0)
this PR:     22   (scheduler 13, triage 7, executor 2)
```

Thirteen guards. And `check:inert-sync-lanes` has run in `test:gate`
since #3136, so CI is currently enforcing a ratchet that reports a file
it cannot see into as fully converted. The green is official, which
makes it worse than the version nobody ran.

## Is the fallback still reachable?

Yes, which is why these are not retired. #3135 attached lanes at every
*live* emitter, but absence remains reachable three ways: the two
`lifecycle-ops.ts` emitters on the SQLite-only polling path, any future
emitter added without lanes, and the three forwarders
(`project-manager.ts`, `remote-node-runtime.ts`,
`child-process-runtime.ts`) that reconstruct the event object
field-by-field rather than forwarding it.

A rarely-exercised fallback is still a fallback. Counting it as clean is
how the ledger stops meaning anything.

## The change

One line inside your walker, plus its note:

```js
if (ts.isCallExpression(n)) { for (const a of n.arguments) walk(a); }
```

Every shape #3169 added is preserved. Still a name match, not dataflow —
the limits section still applies.

## Mutation evidence — all three shapes, one tree

| Mutant | Result |
|---|---|
| baseline (22) | exit 0 |
| **argument position** (this PR) | **exit 1**, 13 → 14 |
| conditional (#3169's) | exit 1, 13 → 14 |
| inline (#3062's) | exit 1, 13 → 14 |

`scheduler.ts` restored clean after each run.

## Baseline 9 → 22

**Detection, not regression.** No production file changes in this PR. 22
is the exact union I measured before #3169 merged (13 + 7 + 2) and
posted on both PRs at the time — it landing unchanged is the
confirmation that the two fixes were additive rather than overlapping.

## Census before / after

```
before:  COLUMN guards (the backlog):   12
after:   COLUMN guards (the backlog):   12
```

Unchanged — this converts nothing. It restores 13 guards to a ledger
that had silently dropped them.

## Supersedes #3122

#3122 carried this fix as a standalone rewrite of `syncLaneLocals` and
conflicted with #3169 the moment it landed. This is the six-line version
I offered there; #3122 is closed.

## Verification

`test:gate` exit 0 · `check:inert-sync-lanes` exit 0 at the re-recorded
baseline · plus `fnxc-future-dates`, `lifecycle-columns`,
`quarantine-ledger`, `inert-flag-seams`, `lane-wiring`,
`sql-column-literals` — all exit 0. Gate script + baseline only.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Improved detection of synchronous operations nested within wrapper
arguments.
* Updated synchronization checks to report all currently identified
findings, including additional scheduler-related cases.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-07-31 08:56:32 -07:00
gsxdsm
fa62c951cf fix(gate): the inert ratchet went quiet exactly when the code improved (conditional initializer) (#3169) 
Found by dogfooding my own change: I wrote `executor.ts` in the
payload-first/sync-fallback shape while adopting #3140's better
fallback, **predicted in a comment that the guards would stay counted**,
and the gate reported **zero**. The prediction was wrong in the
direction that matters — the gate under-reports.

## The gap

`syncLaneLocals` registered a local only when its initializer **was** a
call expression:

```ts
const sync = payload ? undefined : localSync(store, id);
return column === sync?.hold;          // inert, and counted as nothing
```

Conditionals and `??`/`||` chains are now unwrapped, so a sync call in
any branch registers the local. Still a **name** match, not dataflow —
the file's LIMITS section still applies.

## Why this shape matters more than the inline one already guarded

**The missed shape is the one authors are steered toward.** Falling back
to the sync resolver is *better* than falling back to legacy literals —
it is best-effort under legacy SQLite, whereas a literal can never be
right on a renamed board. So writing the guard well is what made it
invisible.

A ratchet that goes quiet exactly when the code improves is worse than
none: it rewards the worse degraded path with a tidier number.

## Known remaining gap, stated in the test rather than implied

Only **one hop** is followed. The two-hop form is still uncounted:

```ts
const sync  = payload ? undefined : localSync(store, id);
const lanes = { hold: payload?.hold ?? sync?.hold ?? "todo" };
if (from !== lanes.hold) …            // still invisible
```

`executor.ts` is written that way today, which is why it reads 0 while
the sync call is still present. Closing it needs propagation through
object-literal construction — a larger change than this one, and I would
rather ship the one-hop fix with the gap documented than imply full
coverage.

## Verification

| | result |
|---|---|
| gate on `main` | **exit 0**, output unchanged (11 = triage 7 +
executor 4) |
| test suite | **5 pass** |
| new case against the **unfixed** gate | **fails** — `the
conditional-initializer shape must be counted` |

The regression case drives a real file through the scanned tree rather
than calling a helper, because the bug was in which nodes the scan
**visits**. A helper-level assertion would have been written against the
same wrong mental model that produced the gap — which is how the
inline-spelling hole in this same file survived its first draft.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Improved detection of sync-lane conversions in conditional
expressions, fallback logic, awaited and parenthesized values, and
object-literal relays.
  * Corrected matching for identifiers containing special characters.
* Updated validation results to include two additional findings that
were previously missed.

* **Tests**
* Added integration coverage for conditional initializers, chained
object-literal conversions, and special-character identifiers.
  * Ensured temporary test files are cleaned up automatically.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 08:20:06 -07:00
gsxdsm
d7324c1a20 fix(gate): main is RED on check-inert-sync-lanes — my #3137 dropped the count without re-recording (#3172) 
`check-inert-sync-lane-conversions` is inside `test:gate`, so **the
merge gate itself is red on `main` right now**.

```
inert-sync-lane: total fell 11 -> 7.
  Good news — but re-record the baseline in the SAME commit, or the allowance stays
  high and the gate silently accepts that many NEW inert conversions
exit 1
```

## Cause: mine

#3137 converted `executor.ts`'s planner-evacuation guards (4 → 0 under
the current scan) and **did not re-record the baseline in the same
commit**. The gate fails an unrecorded drop by design — a stale-high
allowance is four free slots for new inert conversions — and that
requirement is stated both in its failure text and in its own test suite
(*"an unrecorded DROP fails, so the allowance cannot stay stale-high"*).
I knew the rule and still shipped without it; the drop only became
visible once the PR merged.

This PR is the baseline only: **11 → 7**, `executor.ts` 4 → 0,
`triage.ts` unchanged at 7.

## Ordering note for my two open gate PRs

#3169 and #3170 make the scan follow a sync lane through a **conditional
initializer** and through an **object literal**. `executor.ts` is
written in exactly that shape after #3137, so with those fixes the count
**rises 7 → 9** — a legitimate rise from better detection, not a
regression. That re-record belongs in #3170's own commit, which is where
the gate asks for it, and I will put it there rather than pre-baking it
here.

So the expected sequence is: **7 now**, **9 when #3170 lands**.

## Process notes

- I checked for an existing fix PR before writing this one.
- I also caught this only because I re-measured the exit code **without
a pipe**. `node gate.mjs | head` then `echo $?` reads `head`'s status
and reported 0 — the exact harness trap recorded in this program's
learnings doc, which I walked into while checking whether main was
healthy.

## Verification

- gate **exit 1 on `origin/main`**, **exit 0** here
- diff is the baseline file only

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 07:44:42 -07:00
gsxdsm
6483f9ce2b fix(scheduler): resolve task:updated / task:deleted lanes asynchronously (scheduler inert 5 → 0) (#3128) 
The last inert guards in `scheduler.ts`. Independent of my other
branches.

## Inert-guard ratchet

| Scope | Before | After |
|---|---:|---:|
| `scheduler.ts` | 5 | **0** |
| total | 12 | **7** (triage.ts 8 → other worker; executor.ts 4 → #3112)
|

## The live bug

These read `resolveTaskParkedColumnsSync`, which answers with the
**default** workflow in production. On a renamed board the scheduler
**never woke** on unpause or planning-finish, and a **deleted blocker
never unblocked its dependents** — the card sat behind a task that no
longer existed.

## The criterion, restated because I got it wrong before

**What blocks a guard is whether its answer is consumed synchronously —
not whether the enclosing listener is declared sync.** I assumed the
latter earlier in this program and reverted for it.

All three fail that test: two only gate `schedule()`, which is itself
`async`, fire-and-forget and re-entrance-guarded; the third already sits
below an `await getSettings()`. The edge-trigger bookkeeping
(`planningTaskIds.delete`) **stays synchronous** on purpose — deferring
*that* would let a second update re-enter the branch.

## The union is load-bearing, not defensive

Post-U11 the default lineage has no `triage` column, so a **resolved**
answer returns `intake: "todo"` where the inert path fell back to
`"triage"`. Converting without unioning the legacy ids silently
**narrowed** the wake set and stopped waking cards in a legacy-named
lane — caught by *"schedules when planning clears in triage"*.

**A resolved conversion must be a superset of what it replaces, or it is
a behaviour change wearing a vocabulary change's clothes.** That's the
reusable lesson here.

## Tests

- Drained with the repo's existing **`flushAsyncHandlers`** helper —
written for exactly this fire-and-forget shape — rather than loosening
any assertion.
- **The characterization test flipped, as designed.**
`workflow-scheduler-parked-columns-live-e2e.pg.test.ts` asserted *"a
dependent in a RENAMED hold column is NEVER unblocked"*, with its author
noting: *"expected to flip to null the moment the resolver is fixed —
and that flip is the whole point of writing it down."* It flipped.
Inverted to a REGRESSION case so the assertion holds the fix rather than
the defect; it now matches its own CONTROL arm, which still guards
against a vacuous pass.

## Verification

- 21 scheduler suites — **361 green**, including the live PostgreSQL e2e
- **`pnpm test:gate` green**; eslint and `tsc` clean
- Changeset added; `check:changesets` passes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 05:41:16 -07:00
gsxdsm
7d75633daa gate: follow sync-lane sources across module boundaries (11 inert guards were invisible) (#3079) 
## Eleven inert guards were invisible to the check that exists to find
them

#3062 shipped this check collecting sync-lane sources **per file**, and
recorded the module-boundary gap as a known limit. That limit has
stopped being theoretical.

`resolvePlannerLanes` is defined in `replan-target.ts` and consumed in
`triage.ts` and `executor.ts`. `triage.ts:723` already reads:

```ts
if (task.column === disposeLanes.hold || task.column === disposeLanes.intake || task.column === "in-progress") return;
```

A sync-resolved pair sitting directly beside a literal. That is
precisely the site a fleet worker reaches for next — the "conversion" is
a one-word edit, it drops the census by one, and it changes nothing,
because `resolvePlannerLanes` resolves through
`store.resolveTaskWorkflowIrSync` and always describes the default
board. **The shipped check could not have seen it.**

## What changed

Sources are collected in a **first pass over the whole tree**;
consumption is counted in a **second pass** against that repo-wide set.

| file | guards now visible |
|---|---|
| `packages/engine/src/scheduler.ts` | 18 |
| `packages/engine/src/triage.ts` | **7 — previously invisible** |
| `packages/engine/src/executor.ts` | **4 — previously invisible** |

**Baseline 20 → 29. The rise is detection, not regression.** Those
eleven guards were already inert; nothing in the tree got worse and no
production file is touched by this PR. Flagging that explicitly because
the check's own failure text says *"do NOT re-record the baseline to
clear this"* — that rule is about a code change, and this is a detector
widening. The distinction matters and I would rather state it than have
it inferred.

## Mutation evidence, on the motivating site

Converting `triage.ts`'s literal to `disposeLanes.wip` — the exact inert
edit this widening exists to prevent:

| | result |
|---|---|
| check as shipped on main | **exit 0** — missed entirely |
| this PR | **exit 1**, `triage.ts: 7 → 8` |

`scheduler.ts` restored clean after every run.

## Third widening — and the honest read on that

This is the third hole found in this check, each discovered the same
way:

1. **#3062**: matched only the local-variable spelling; the inline
`resolveX(...).review` walked past.
2. **#3068**: matched only comparisons; `parked.terminal.has(to)` walked
past — and worse, made the count *fall*, inviting a re-record that would
have retired live sites.
3. **here**: matched only same-file sources; a cross-module helper
walked past.

Every time, the check was correct about the shape in front of it and
blind to a trivially different spelling of the same defect. I said in
#3068 that the durable fix is to key on **the source** rather than
enumerate consuming syntax; this closes the module-boundary half of
that. The remaining half is value-level dataflow (a sync-resolved id
assigned through an intermediate, passed as an argument, or returned),
which needs a type-aware pass and is a larger change than a gate script
should carry casually.

I am not claiming this version is complete. It is measurably better than
the shipped one on a site that exists in the tree today.

## Census before / after

```
before:  COLUMN guards (the backlog):   84
after:   COLUMN guards (the backlog):   84
```

Unchanged — this converts nothing. It makes eleven already-inert guards
countable so the next conversion of them fails loudly instead of reading
as progress.

## Verification

`test:gate` exit 0 · `pnpm check:inert-sync-lanes` exit 0 ·
lifecycle-column census exit 0 · `pnpm lint` clean. Gate script +
baseline only.

Still open and unrelated: **#3073** re-greens the archived-gate parity
ratchet, which is red on `main` right now and sits outside the merge
gate.
 2026-07-31 05:03:11 -07:00
gsxdsm
bdedb6cf1a gate: fail the build on a NEW inert sync-lane conversion (#3062) 
## Claim, and why it turned into a gate

I claimed the largest unclaimed unflagged cluster, `executor.ts` (4
guards at 3557/3581/3632/3642). All four are conditions of a
**synchronous** `store.on("task:moved", …)` listener — the same class as
`scheduler.ts`. Converting them needs either an `await` in a sync
prologue or the sync resolver, and the sync resolver is inert.

`executor.ts` already says so, at line 10459, dated 2026-07-30:

> **THE SYNCHRONOUS RESOLVER IS A NO-OP IN PRODUCTION.** … every
sync-resolved conversion resolves the DEFAULT workflow and answers with
the legacy ids no matter what board the task is on. That makes a sync
conversion cosmetic: the census counts it as converted, `--strict` goes
down by one, and the guard behaves exactly as the literal did. **Worse
than leaving the literal, because the number says the site is done.**

The next day, #3051 did exactly that to ten `scheduler.ts` arms. Census
fell by ten; nothing changed on any board (refuted live in #3058).

So the finding was already written down, in the file a converter would
be reading, in capitals — and the fleet phase produced the defect
anyway. **A comment cannot fail a build.** Converting `executor.ts`'s
four the only available way would have made me the third instance. I
flagged them and built the guard instead.

## What the check does

Per file: finds functions reaching `resolveTaskWorkflowIrSync`, the
locals assigned from them, and the `===`/`!==` guards consuming those
roles. Baselined per file; **fails on a rise.**

Not zero, deliberately. The existing sync guards are real and documented
— the scheduler's listeners genuinely cannot `await` today and their
authors said so. Demanding zero forces a revert or a day-one exemption
marker. What must not happen is *more* literals quietly becoming
inert-resolved.

Complements `check-inert-flag-seams.mjs`, which catches the opposite
shape (a lane parameter **no** caller supplies). This catches a
parameter that **is** supplied, from a source that always answers the
same thing — which passes that check cleanly.

## Why the shape is invisible

The obvious reading is wrong, and it is what makes this survive review.
The helper does **not** receive `undefined` and fall through to `??
"in-review"`. It receives a **real IR that resolves real traits** — the
default board's — so it answers with full confidence and the `??` arms
beside it are dead code.

```
tsc passes         the value is a string, correctly typed
tests pass         on the default board the constant answer IS the right answer
the census DROPS   it counts comparisons against literals, and the literal really is gone
```

## Mutation evidence — including one against this check itself

| Mutant | Result |
|---|---|
| baseline | exit 0, 20 guards in `scheduler.ts` |
| convert one more literal to a sync-resolved lane (the #3051 move) |
**exit 1, 20 → 21** |
| convert the same literal to an **async**-resolved lane | exit 0 —
correctly silent |

The first draft **failed its own mutation test**: it matched only the
local-variable spelling (`const parked = resolveX(...)` then
`parked.review`), which is what #3051 used, and the inline spelling
`resolveX(store, id).review` walked straight past it while being exactly
as inert. A ratchet one rewrite evades is worse than none, because the
green result reads as proof. Both spellings now count.

## Limits, stated so nobody over-trusts it

Sources are matched **within a file by function name**, so a helper
imported from another module is not followed — this finds the dominant
local-helper shape and will miss a cross-module one
(`resolvePlannerLanes`, consumed in `executor.ts`/`triage.ts`, is
currently outside its reach). It proves a guard consumes a sync-resolved
answer, not that the answer is wrong for every caller. Tests are
excluded. Treat a report as a pointer to investigate.

## Census before / after

```
before:  COLUMN guards (the backlog):   104
after:   COLUMN guards (the backlog):   104
```

Unchanged by design — this converts nothing. It stops the count from
moving for the wrong reason.

Worth recording alongside it, measured across the current backlog: **21
of 104 already carry an explicit flag note**, **51 are
`self-healing.ts`** (concurrently claimed by **#3055, #3050 and #3049**
— three PRs, one file, still worth de-conflicting), and **28 are
genuinely unclaimed and unflagged**, the largest being these
`executor.ts` four. The cluster-sized work is close to exhausted; what
is left is scattered and mostly blocked, which is the pressure that
produced #3051.

## Verification

`test:gate` exit 0 · `pnpm lint` clean · lifecycle-column census exit 0
· `pnpm check:inert-sync-lanes` exit 0. No production file touched.
 2026-07-31 02:57:32 -07:00