Files
fusion/packages/engine
gsxdsm 97b945f980 docs(engine): the scheduler flag's reason went stale, and two deferrals read as unexamined (#3142)
My own flag on these two literals went stale, in exactly the way I have
spent this session cataloguing in other people's notes.

## What the note said, and why it is now wrong

It said these two stay because converting them would be **inert** — the
sync resolver answers with the default board. True when written.

#3128 then converted the rest of this listener by deferring each resolve
into a `void (async () => ...)` block, which reaches the **async**
resolver and is genuinely correct. So async resolution *is* available
here now, and my stated reason no longer explains why these two are
different.

## The real reason, which #3128 itself states

Three branches down, in its own note:

> The `planningTaskIds.delete` stays SYNCHRONOUS — it is the
edge-trigger bookkeeping, and deferring it would let a second update
re-enter this branch.

Both remaining literals are that case:

| literal | why it cannot move behind an await |
|---|---|
| `failedTaskIds.add` | edge-trigger bookkeeping raced against
`moveTask` clearing the failure metadata — its own comment says so.
Deferring the add can miss that window. |
| PR-monitoring guard | it gates `getTrackedPrs()` /
`startMonitoring()`, where `tracked.has(task.id)` **is** the re-entrance
guard. Move the lane answer behind an await and two updates for the same
task can both pass that check before either starts — **double-starting a
monitor**. |

## Why the distinction is worth a PR

"Blocked on a resolver" invites the next person to wait for the sync
reader. What these actually need is somewhere to put the answer that is
**not behind an await** — the emitter-carried `lanes` #3109 added to
`task:moved`, whose extension to `task:updated` is measured as expensive
rather than impossible (#3123: 26 emit sites against 7, on the hottest
write path).

Those are different tickets with different owners. Leaving the wrong one
written down is how a blocker outlives its cause — the failure I have
now found in five separate notes this session, including two of my own.

## Measured

- Comment-only.
- `src/__tests__/scheduler*` — **14 files / 144 tests pass**.
- `tsc --noEmit -p packages/engine` clean; `check-inert-sync-lanes` and
census `--strict` clean.
- `check-fnxc-future-dates` is red from `main`'s own #3128 stamps —
**#3139** fixes that; this branch inherits it and does not add to it.

## Census

No movement. Both literals stay counted, now with the correct reason
attached.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-31 10:18:30 -07:00
..
2026-07-26 18:11:47 -07:00