Files
fusion/packages
gsxdsm 91c3854607 fix(fnxc): the last future-dated stamp keeping main red (#3269)
**`check-fnxc-future-dates` exits 1 on `origin/main`.** This is the last
stamp causing it.

```
packages/core/src/task-store/lifecycle-ops.ts: 1 future-dated FNXC stamp, baseline allows 0
  FNXC:Diagnostics 2026-08-01-00:50   (today is 2026-07-31)
```

Corrected to `2026-07-31-00:50`. One character.
`check-fnxc-future-dates` now exits 0; `tsc --noEmit` clean.

## Why this was left behind

Four PRs converged on this red main — #3262, #3263, #3265, and my own
#3266 (closed as superseded). Between them they covered the census rise
and the boundary-work stamps. **None touched `lifecycle-ops.ts`**, so
the gate stayed red after the others landed.

That is the predictable failure of parallel work on one symptom:
everyone fixes the part they saw first, and the residue survives because
each author checked "is main green now?" against their own branch rather
than against main.

## I claimed before working this time

```
node scripts/check-file-claimed.mjs packages/core/src/task-store/lifecycle-ops.ts
  → UNCLAIMED
```

Then pushed the branch before editing. I did the opposite on #3266 —
built it, then discovered #3265 already covered it — which was the sixth
duplication of the phase and my third. The tool answers in one command;
the discipline is running it *first*.

## Verification

- `check-fnxc-future-dates` — **exit 0** (was exit 1 on main)
- `census --strict` — exit 0 (already green; #3265's marker landed)
- `tsc --noEmit` (core) — 0 errors
- one-character diff, no behaviour change

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-31 16:48:09 -07:00
..
2026-07-26 18:11:47 -07:00
2026-07-31 14:58:53 -07:00