aedee4b8231bf050c3240a00ab6645ede5d87ee9
8 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
gsxdsm
|
dfe050e8d4 |
FN-8640: add FNXC stamp anomaly advisory
Add a non-blocking census for implausible future-dated FNXC stamps. - Classify tolerated future stamps by timezone plausibility and report notable anomalies. - Add injectable gate seams and coverage for advisory, report, baseline, and discovery behavior. - Document the advisory and preserve read-only check-mode baseline handling. Files changed: docs/testing.md | 4 + scripts/__tests__/check-fnxc-future-dates.test.mjs | 185 ++++++++ scripts/check-fnxc-future-dates.mjs | 495 +++++++++++---------- 3 files changed, 439 insertions(+), 245 deletions(-) Fusion-Task-Id: FN-8640 Fusion-Task-Lineage: 7e57feb0-95e2-46b9-a1cf-9bd93c40d8e0 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
9abec9f235 |
fix(gate): the fnxc check WROTE to the tree it was checking — nine PRs chased three defects (#3287)
Root-cause fix for the duplicate-PR pileup tracked in #3267. **Running the check modified the working tree.** ## Reproduction ``` clean: 0 files dirty $ node scripts/check-fnxc-future-dates.mjs # no flags, no --update-baseline exit 0 after: 1 file dirty → M scripts/lib/fnxc-future-dates-baseline.json ``` `:227` auto-tightened and `writeFileSync`'d on every run. ## Why that produced nine PRs The tightening is **right in substance** — the comment above it explains why banking a stale allowance is worse than re-recording. Doing it as a *side effect of checking* is what hurt: every worker who ran the gate received an identical uncommitted diff they had not written, and reasonably committed it. The clearest evidence is #3283 and #3285 — five minutes apart, `+0/-1` each, both deleting the same baseline line. **Neither author wrote that line.** The gate wrote it, in both of their checkouts. I also mis-attributed my own dirty tree to leftover work while retracting a measurement on #3277/#3278. The dirt was this script. ## The change Still computed, still reported loudly — only **written** under `--update-baseline`: ``` [check-fnxc-future-dates] baseline CAN BE TIGHTENED for 1 file(s): packages/cli/src/__tests__/cli-active-count-lanes.test.ts: 10 -> 5 run `pnpm check:fnxc-future-dates --update-baseline` to record it (one commit, one author) ``` **A plain run stays green rather than failing on a tightening.** Stamps age into the past on their own, so failing would redden main on a clock tick — which is precisely why the auto-write existed. Report, don't enforce. ## Measured, both directions | scenario | result | |---|---| | stale allowance, plain run | reports + hint; baseline **unchanged** (verified still inflated at 10) | | stale allowance, `--update-baseline` | `baseline written: 122 stamp(s) in 63 file(s)`; value reset to 5 | | clean tree, plain run | exit 0, **zero files dirty** | | `census --strict` / eslint | 0 / clean | The first row is the one that matters: I inflated an allowance, ran the check, and confirmed the file was **still inflated afterwards**. Asserting only "exit 0, no diff" would have passed even if the write had silently succeeded and produced no net change. ## Scope One script. CI is unaffected — it never committed the side-effect write, so that write was always discarded there. The only behaviour change is that an interactive run no longer edits your tree. This is a smaller intervention than the claim-protocol I proposed earlier in #3267, and I now think that one was treating a symptom: workers were not colliding because they lacked a protocol, but because the tool handed each of them the same diff. |
||
|
gsxdsm
|
40bb621fd8 |
fix(gate): print the exact UTC stamp when the date gate fails (#3271)
## What **Three separate commits landed a future-dated FNXC stamp this evening**, each turning this blocking gate red on main (#3261 fixed six across five engine files; #3270 fixes a third in core). This makes the failure message actionable. Tooling only. The message said *"Use the current date and a real clock time."* That tells the author to use the value they already believed they had. It now prints the exact stamp: ``` Current UTC stamp to use: 2026-07-31-23:39 ``` Copy-paste instead of a second judgement call, computed only on a path that has already failed. ## Why a message change rather than a rule **The offsets are the evidence.** `00:50` against `23:34`; the engine batch similar — consistently **1–2 hours into tomorrow**, not wrong dates. That is the shape of a clock or timezone difference, not carelessness, and no amount of restating the rule fixes a clock. AGENTS.md already says to take the stamp from `date -u`; three actors violated it in one evening anyway. **I am one of those actors** — I have broken this rule twice today. So this is not a complaint about anyone's diligence; it is an argument that the instruction is doing less work than a printed value would. ## I made the same mistake inside this change The FNXC comment documenting the fix was stamped **two minutes ahead** of the real UTC time. Corrected from `date -u`. **The gate did not catch it** — it scans `packages/` and not `scripts/`, so FNXC stamps in the tooling itself are entirely unchecked. That is a genuine scope gap and I am reporting rather than closing it: pulling `scripts/` into scope would surface existing stamps across the tooling and needs its own baseline pass, which does not belong in a message fix. There is something clarifying about writing a future-dated stamp *in the fix for future-dated stamps*, in a file the checker cannot see. It is the same lesson this whole session kept producing — **an instrument's blind spot is invisible in exactly the way its subject is** — and I walked into it while holding the flashlight. ``` lint clean; gate prints the stamp on failure ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved validation feedback for future-dated entries by showing the exact UTC timestamp format and value to use when corrections are needed. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
gsxdsm
|
1e7e6baef1 |
fix(fnxc): the gate compared author stamps against ONE machine's calendar — five reds in two hours (#3277)
Root-cause fix for tonight's repeated red `main`, instead of repointing stamps one at a time — **four PRs across three lanes did that in ninety minutes** (#3261, #3269, and my #3263 and #3272, two of which I closed as superseded by concurrent work). ## The defect The fleet writes stamps from **many** machines; this gate evaluates them on **one**. #2941 fixed the case where the author sits **west** of the runner — a correct 5pm-in-California stamp read as "tomorrow" under a UTC comparison — by switching to the runner's **local** calendar. The mirror case was left open, and that is what broke `main`: | commit | landed (PDT) | = UTC | stamp written | |---|---|---|---| | `9094d1640e` | 16:12 | 23:12 Jul 31 | `2026-08-01-00:20` | | `e52da740a5` | 16:32 | 23:32 Jul 31 | `2026-08-01-00:50` | | `3f95c6d53e` | 16:40 | 23:40 Jul 31 | `2026-08-01-01:05` | Those are **neither** the runner's local date **nor** UTC. They are the *author's* local date in a UTC+1 container — and they are **correct** by this project's own convention ("authors write the local date"). The gate, running in PDT, called all three "tomorrow" and reddened `main` for every other lane. ## The fix A stamp is future only if it is ahead of **both** the local and UTC calendar dates. - Accepts both honest directions (author east or west of the runner). - **Preserves #2941**, doesn't revert it — west of Greenwich the local date is the earlier of the pair, so the 5pm-in-California case still passes. - Still catches an invented date: `scheduler.ts`'s `2026-08-06` stamp (six days out) remains counted, and a mutation probe at `2026-09-15` fails the gate. ## AGENTS.md corrected in the same commit It still instructed **`date -u`**, which describes the *pre-#2941* gate. That instruction is now the one that **produces** the failure from any machine east of the runner — I followed it myself earlier tonight and repointed stamps that were already correct. Rewritten to say: write your own local date; the gate accepts anything not ahead of both calendars. ## Baseline Auto-tightened for **37 files** — the gate's no-author drop path. Those allowances were false positives carried since the UTC-only era, so this **strengthens** the ratchet rather than widening it (`scheduler.ts` 2 → 1, keeping the genuinely-invented stamp counted). ## Verification ``` check-fnxc-future-dates green check-inert-sync-lane-conversions green check-lane-wiring green check-sql-column-literals green census --strict green MUTATION: FNXC:MutationProbe 2026-09-15-10:00 → gate fails (real future dates still caught) ``` No changeset: tooling/gate + internal docs. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
9ad3a2a93a |
fix(gate): name the offending FNXC stamp and which rule it broke (#3009)
**`main` is currently red**, so every open PR shows a failing Lint job that is not its own fault. #3004 is how I found it — its gates all pass in isolation and fail against main. ## Cause: an hour that does not exist ``` FNXC:OperatorScriptLaneAssumptions 2026-07-30-26:10 ^^ hour 26 ``` Four of them, across three files, from #2994. ## The part worth fixing is the message, not the stamps This gate counts **two** defects — a date after today, and an impossible clock time — but the failure text only ever explained the first: ``` scripts/reconcile-task-state-consistency.mjs: 2 future-dated FNXC stamp(s), baseline allows 0 A stamp dated after today (2026-07-31) records the change as happening in the future... ``` Every stamp in that file is dated `2026-07-30` or earlier — all valid past dates. So the message sends you to inspect stamps that are fine, and the natural conclusion is *the gate is broken*, not *the stamp is*. I spent several minutes reproducing the regex by hand and getting `future count = 0` before instrumenting the real script and finding `hits += impossibleClockTimes(source)`. A gate that detects the right defect and describes a different one is worse than a slightly less sensitive gate, because it spends the reader's trust. Now: ``` scripts/reconcile-task-state-consistency.mjs FNXC:OperatorScriptLaneAssumptions 2026-07-30-26:10 (impossible clock time) ``` **Mutation-verified**: restoring one `26:10` stamp reproduces the failure, and the message names it. ## The stamps: `2026-07-31-02:10`, not `23:59` Hour 26 on the 30th is the informal spelling of 02:10 the next day. Clamping to `23:59` would keep the file's stamps in a plausible order but silently move the event; this preserves what the author meant. Reversible either way — say the word if you would rather they were clamped. ## The 176-file baseline drop is unrelated `475 -> 183 known`. The clock crossed midnight, so yesterday's stamps are no longer future-dated, and the ratchet auto-lowers on drops by design. It rides along because the gate must leave a baseline matching reality — an allowance nothing occupies is somewhere a real regression can hide. It is not part of the fix. ## Verification - `check:fnxc-future-dates` — exit 0 (was **exit 1 on main**) - `check:lifecycle-columns`, `check:sql-column-literals`, `check:inert-flag-seams`, `check:lane-wiring` — all exit 0 - eslint clean ## Worth someone's attention beyond this PR `#2994` landed four impossible timestamps. The gate caught them, but only after the clock crossed midnight changed which files it reported — meaning the impossible-time check was live but effectively invisible until it collided with an unrelated drop. It is worth asking whether that check has ever produced a message anyone acted on before today. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
72f5f8e51a |
fix(gate): the FNXC stamp gate never validated the hour, so 25:30 passed (#2995)
`check-fnxc-future-dates.mjs` validates the **date** portion of a stamp
and never looks at the clock time:
```js
const STAMP = /FNXC:[A-Za-z0-9_-]+\s+(\d{4}-\d{2}-\d{2})/g;
…
for (const match of source.matchAll(STAMP)) if (match[1] > today) hits += 1;
```
The capture stops before the hour, so a stamp may carry **any** `hh:mm`
and pass. Found while pre-flighting #2992, whose new comments read
`2026-07-30-25:30`.
## It is not one typo
Four stamps **already on `main`** carry a clock time that cannot exist:
```
packages/cli/src/__tests__/task-list-board-columns.test.ts:2 -24:40
packages/cli/src/commands/task.ts:29 -24:40
packages/cli/src/commands/task.ts:636 -24:40
scripts/check-lane-wiring.mjs:18 -24:00
```
Three separate authors, so this is the gate's blind spot rather than one
person's slip — and #2992 adds two more, which is how I noticed.
AGENTS.md specifies `yyyy-MM-dd-hh:mm`. The stamp's whole purpose is to
make the FNXC record a readable chronology of *why* code exists; a
timestamp that cannot exist quietly costs it that, and nothing was going
to catch it.
## The fix
Hours `00-23`, minutes `00-59`, counted per file **alongside** the
future-dated population rather than as a separate gate — same defect
class (a stamp that does not describe a real moment), and one ratchet is
cheaper to keep honest than two.
**Mutations, both directions:**
| stamp | result |
|---|---|
| `2026-07-30-25:00` | **flagged** |
| `2026-07-30-23:75` | **flagged** |
| clean tree | `475 known future-dated stamp(s), none added`, exit 0 |
## On the four existing stamps
Normalized by clamping the impossible hour to `23`, minutes preserved,
so relative ordering within each file survives. **That is a
normalization with a stated rule, not a claim about the true minute** —
`-24:40` most plausibly meant "just past midnight", but writing
`2026-07-31-00:40` would be future-dated against today's local calendar
and fail the very gate this PR extends. Clamping keeps every stamp real,
ordered, and non-future; the exact minute was already unrecoverable.
**Verified:** FNXC gate exit 0, lane-wiring gate exit 0,
`task-list-board-columns` 5/5, lint clean.
Comment-only changes to the CLI files (stamp text inside FNXC blocks),
so no behaviour change and no changeset.
Noted separately on #2992 so its two new stamps get corrected there
rather than landing and immediately failing this gate.
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
gsxdsm
|
255741e9ab |
fix(gate): scan every file type that carries an FNXC stamp (#2954)
The walk's extension filter was `/\.(tsx?|m?js|cjs|md)$/` — the file types stamps were **expected** in, rather than the ones they **occur** in. Wherever the convention spread on its own, the gate could not see it. ## How I found it Chasing four stamps dated `2026-10-19` — three months out, so unlike the rest of the population they would not age out on their own. All four were in `packages/core/dist/`, which the gate correctly skips as generated. The *source* they were compiled from is a `.sql` migration, which the gate skips for a different and much worse reason: it was never scanned at all. ## Why `.sql` is the expensive omission A migration's stamp records **when a schema change landed**. That is the case where a wrong date misleads most — it is the file you read to reconstruct the order schema changes happened in. 69 migration files carry stamps; 10 were future-dated and none were visible. `.css` had drifted furthest by volume: **1023 stamps across 123 files**, almost all from the dashboard CSS split. `.html`, `.ya?ml`, `.json`, `.sh` are included too; they add coverage but contribute no baseline entries. ## The 9 new baseline entries are newly VISIBLE, not new 5 `.css` + 4 `.sql`. Every one predates this change and would have been caught had the gate ever looked. Recording them is a **reclassification**, the same distinction the census draws for its DELIBERATE-LITERAL marker — a baseline that grows here is the gate's coverage improving, not the codebase regressing. Reading the rise as a regression would be exactly backwards. ## Verified by mutation, not by reading - A future-dated stamp appended to `ChatView.css` → gate **exit 1**. - A future-dated stamp appended to `0036_chat_session_tags.sql` → gate **exit 1**. - Both reverted → **exit 0**. Without this, both probes pass silently. ## Two notes on the diff - **Zero removals.** My first attempt rewrote the baseline with sorted keys, which turned unmoved lines into add/remove pairs and made it look like entries were being dropped. Rebuilt in walk order so the diff is additions only. - `reads.ts` is deliberately left at `2` here even though it now measures `0`. That drop belongs to #2953; duplicating it across two open PRs is how this queue got tangled before. The gate auto-tightens it at runtime and still exits 0. ## What this does not fix The **478** future-dated stamps still in the tree. They are agent-written (mine included) and most are one or two days out, so the count falls on its own as the clock advances — it should not be read as cleanup progress. This PR only makes the gate able to *see* the SQL and CSS ones, so no new stamp can land there unnoticed. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
b1bd571682 |
batch-sql-ratchet: the census / gate-ratchet family — collection branch, fold here (#2941)
## Family branch for consolidation directive item 4 `batch-sql-ratchet` did not exist and ~10 open PRs are waiting for a collection point, so this establishes it. **Fold your census/ratchet commit here and close your own PR as superseded.** ```bash git fetch origin batch-sql-ratchet git checkout -B batch-sql-ratchet origin/batch-sql-ratchet git cherry-pick <your-sha> # verify scoped, not full suite: pnpm --filter @fusion/core exec vitest run src/__tests__/archived-column-gate-parity.test.ts --silent=passed-only --reporter=dot git push origin HEAD:batch-sql-ratchet ``` **Candidates I can see open right now** (owners: please fold + close): | PR | branch | |---|---| | #2938 | `fix/comments-ops-sentinel` | | #2935 | `fix/task-artifacts-sentinels` | | #2933 | `chore/commit-tightened-census-baseline` | | #2931 | `fix/async-comments-sentinels` | | #2928 | `fix/audit-ops-sentinel-marker` | | #2925 | `live-task-column-lanes` | | #2923 | `fix/task-id-integrity-sentinel` | | #2921 | `fix/plugin-store-migration-marker` | | #2894 | `gate/sql-literals-match-census-placement` | That is **10 → 1** once folded. I have not cherry-picked anyone else's commits — folding someone's work without them verifying it is how a batch lands broken. --- ## What is in it so far (mine, from #2924) **Clears a live main red:** `archived-column-gate-parity` fails on `origin/main` today. ``` AssertionError: TypeScript encoding changed. async-comments-attachments.ts: 8 → 5 ``` #2886 fixed a real bug — archived-document guards failing in *opposite* directions on a renamed lane — by replacing three `column === "archived"` comparisons with `isArchivedLane(column, archivedColumns)`. The AST scan counts raw comparisons, so the tally dropped. **What I did not do is record it as three sites converted**, because measured, it is not: ``` grep -rn "archivedColumns:" packages/core/src packages/engine/src --include="*.ts" | grep -v __tests__ → (no matches) ``` No caller passes it. The parameter defaults to `LEGACY_ARCHIVED_LANES = new Set(["archived"])`, so every call resolves to the literal it replaced — byte-identical behaviour, resolved branch dead. That matters for this guard's whole argument: its header warns that converting the TypeScript half while the Drizzle and raw-`sql` halves still compare the string is a split brain *"no test would catch, because every builtin workflow spells the column `archived` so the two halves agree by accident on every board we ship."* **There is no split brain today precisely because the resolved half is unwired** — it becomes one the moment a caller threads real lanes in without the SQL sides moving. Recorded inline so `5` cannot be read as "3 sites done"; flagged on #2886. Verified not a split brain: the Drizzle and raw-sql inventories are unchanged and both pass — worth stating because those assertions run *after* the TypeScript one, so a plain red says nothing about them. Scoped edit to `AUDITED_TS_SITES` by line range: these paths appear in more than one inventory here, and an unscoped replace would quietly edit the raw-sql side too, making the parity guard agree with itself (the trap I hit in #2817). Guard still bites: appending a real `task.column === "archived"` to an audited file fails it. Core **4852 passed / 0 failed**, lint clean, test-only. Closing #2924 as superseded by this. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved task delegation messages when workflow pickup cannot be confirmed. * Delegation results now clearly indicate when a task has not been verified for pickup. * **Quality Improvements** * Added validation checks to catch future-dated markers and inconsistent SQL-column usage. * Refined workflow checks to distinguish stale configuration from incomplete configuration. * **Documentation** * Updated lifecycle conversion guidance with more accurate audit findings and limitations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |