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

195 Commits

Author SHA1 Message Date
gsxdsm
07dccbe2bd FN-8783: parallelize static merge-gate validators 
Run independent static merge-gate policy validators concurrently without weakening gate ordering.

- Add a fail-closed concurrent static-validator runner with coverage for inventory and failures.
- Preserve curated engine, PostgreSQL, unit, and CI-shape gate contracts.
- Document the gate composition and warm-cache performance policy.

Files changed:
 docs/testing.md                                    |  13 ++-
 package.json                                       |   3 +-
 packages/cli/src/__tests__/ci-workflow.test.ts     |  21 ++--
 packages/engine/vitest.config.ts                   |  36 +++++--
 .../__tests__/engine-vitest-gate-policy.test.mjs   |  90 +++++++++++++----
 scripts/__tests__/run-static-gate-checks.test.mjs  | 100 +++++++++++++++++++
 scripts/run-static-gate-checks.mjs                 | 106 +++++++++++++++++++++
 7 files changed, 332 insertions(+), 37 deletions(-)

Fusion-Task-Id: FN-8783

Fusion-Task-Lineage: d5d3c9e1-b3c4-45ff-a3e7-f9555585cd70

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-08-04 09:21:07 -07:00
gsxdsm
0d492f9056 FN-8770: consolidate task display sorting 
Centralize workflow column sorting in core and remove the duplicate dashboard implementation.

- Export shared display-column sort options and complete-column modes from core.
- Route board, lane, list, and column consumers through the shared sorter.
- Harden inert flag seam checks for same-named module functions.

Files changed:
 .../display-ranking-roles-resolved.test.ts         |   6 +-
 packages/core/src/__tests__/task-priority.test.ts  |  63 +++++++
 packages/core/src/index.gate.ts                    |   2 +
 packages/core/src/index.ts                         |   2 +
 packages/core/src/tasks/task-priority.ts           |  87 +++++----
 packages/core/src/types.ts                         |   9 +
 packages/dashboard/app/components/Board.tsx        |  45 +----
 packages/dashboard/app/components/Column.tsx       |   4 +-
 packages/dashboard/app/components/Lane.tsx         |  34 +---
 packages/dashboard/app/components/ListView.tsx     |  19 +-
 .../app/components/__tests__/Lane.test.tsx         |   8 +-
 .../app/components/__tests__/taskSorting.test.ts   | 201 ---------------------
 packages/dashboard/app/components/taskSorting.ts   | 138 --------------
 scripts/__tests__/check-inert-flag-seams.test.mjs  |   4 +-
 scripts/check-inert-flag-seams.mjs                 |  83 +++------
 15 files changed, 177 insertions(+), 528 deletions(-)

Fusion-Task-Id: FN-8770

Fusion-Task-Lineage: 81740c52-0a3c-44df-9fbb-addaefdfeb82

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-08-03 16:15:12 -07:00
gsxdsm
56819e21e9 fix: restore plugin SDK and Todo packaging 2026-08-03 12:16:32 -07:00
gsxdsm
19e9f5bc88 chore(release): require interactive confirm; drop authorized/--yes skips 
Remove the typed authorization phrase and the --yes/-y auto-confirm path so
every real release must confirm y/N in an interactive terminal. Reject --yes
with a clear error so old muscle memory cannot skip the proceed prompt.
 2026-08-02 19:58:37 -07:00
gsxdsm
1e7f510ee2 fix: stop blocking tasks on open-PR file claims — board tasks are the only blockers 
Remove the FN-8700 PR/file-claim blocking mechanism end to end (operator
decision after FN-8728 parked on unrelated PR #2398):

- Drop the AGENTS.md claim-check rule and scripts/check-file-claimed.mjs
- Executor prompt + fn_task_done no longer accept pr:N refs or treat open
  PRs as blocked-exit reasons
- execution-block-classifier classifies on Fusion task dependencies only;
  legacy pr refs are discarded, reason prose never makes a block durable
- Remove the session-log BLOCKED promotion and the gh-backed
  reconcile-external-pr-blockers self-healing sweep
- Legacy file-claim parks are no longer honored, so previously PR-blocked
  rows recover via normal paths

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-08-02 17:06:38 -07:00
gsxdsm
9c9dd7db2f FN-8706: scan paginated PR files for claims 
Scan paginated pull-request file lists so claim checks remain reliable for large diffs.

- Replace truncated PR diff scans with count-validated paginated GitHub API requests.
- Fail closed when open PR or file-list data is incomplete, malformed, or exceeds the API ceiling.
- Add coverage for large diffs, API failures, count mismatches, and claim precedence.

Files changed:
 scripts/__tests__/check-file-claimed.test.mjs | 186 ++++++++++++++++++++++++++
 scripts/check-file-claimed.mjs                | 119 +++++++++++-----
 2 files changed, 272 insertions(+), 33 deletions(-)

Fusion-Task-Id: FN-8706
Fusion-Task-Lineage: 1edf3546-553b-4e35-8c41-cd5143c08e0a
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-08-01 09:39:38 -07:00
gsxdsm
cced31208e FN-8672: document observed suite-only flakes 
Record first-sighting evidence for three suite-only flakes while preserving their substantial test coverage.

- Define the narrow first-sighting observed-register exception and second-sighting quarantine escalation.
- Add reproduction data for the core and engine PostgreSQL-adjacent flakes.
- Validate register metadata, paths, hierarchy segments, and escalation guidance.

Files changed:
 AGENTS.md                                          |  4 ++
 .../suite-only-flakes-observed-register.md         | 74 ++++++++++++++++++++++
 docs/testing.md                                    |  4 ++
 scripts/__tests__/observed-flake-register.test.mjs | 61 ++++++++++++++++++
 4 files changed, 143 insertions(+)

Fusion-Task-Id: FN-8672

Fusion-Task-Lineage: b52c74fb-aa7b-49e3-9f1d-a2c8c577f9c7

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-08-01 00:21:14 -07:00
gsxdsm
744c01f7fb FN-8657: extract move-target literal counter 
Make the move-target literal ratchet directly testable without changing its scan behavior.

- Export the AST-based legacy destination counter for fixture testing
- Cover literal destinations, private moves, and deliberate exemptions

Files changed:
 .../__tests__/check-move-target-literals.test.mjs  | 30 ++++++++-
 scripts/check-move-target-literals.mjs             | 77 +++++++++-------------
 2 files changed, 60 insertions(+), 47 deletions(-)

Fusion-Task-Id: FN-8657

Fusion-Task-Lineage: 5b1f9ac4-6026-4baf-b42c-f41ab0562679

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-07-31 21:34:25 -07:00
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>
 2026-07-31 19:03:08 -07:00
gsxdsm
b7c7977c09 fix(gate): catch cast move-targets, keep ?? fallbacks unflagged, and pin all of it (#3253) 
Follow-up to #3250. Two changes, and **one of them is a decision not to
widen** — which is the part I would review first.

## Caught now: the cast form

```ts
moveTask(id, "done" as ColumnId)   // was invisible
```

Columns are typed `ColumnId`, so a cast is the **natural** spelling
wherever the parameter is nominally typed. The gate was weakest exactly
where this codebase is most likely to write a literal.
Cast-wrapping-a-ternary is caught too.

## Deliberately NOT caught: `??` / `||` / `&&`

I recommended these arms on #3250. **I was wrong, and the tree proved
it.** Adding them flagged:

```ts
moveTask(id, (await resolveTaskLifecycleColumns(store, id))?.complete ?? "done", ...)
```

That is the fail-soft idiom this entire programme rests on — resolve,
fall back to the legacy id when the workflow is unreadable, exactly as
the role helpers degrade. It is the **correct** pattern.

A gate that demands a `DELIBERATE-LITERAL` marker on every safe fallback
teaches people to add markers by habit, and a habitual marker is how the
next real literal walks straight through. So: a legacy id **after** `??`
is the safe shape and stays unflagged; a legacy id as the **whole**
destination is caught. Backed out, with the reasoning at the site so
nobody re-adds it.

If you disagree, the counter-argument is that a fallback could mask a
lane that should have resolved — but that wants its own report, not this
ratchet's exit code.

## Pinned — the gate had no tests at all

Fifth spelling missed across three rounds, and every earlier probe was
run by hand and thrown away, because the scanner executed on import.
Commit 1 makes it importable (behaviour-preserving, `--strict`
identical); commit 2 adds **12 tests in both directions**:

| catches | does not catch |
|---|---|
| direct, backtick, ternary, nested ternary, parenthesised, cast,
cast-over-ternary | `??` fallback, `\|\|` fallback, resolved
destination, substituted template |

The negatives are load-bearing, not padding — four of them encode false
positives that either shipped or arrived while widening.

## The root cause, recorded in the test header

**The destination is a POSITION; every fix so far has enumerated NODE
KINDS.** A kind list is something the language extends faster than we
guess — I started that pattern myself in #3246 by requiring
`arguments[1]` to *be* a literal. The durable defence is that each shape
someone finds stays found.

## Measured

| check | result |
|---|---|
| real tree | **0** targets, `--strict` exit 0 (the `??` false positive
is gone) |
| gate tests | **12 pass / 0 fail** |
| anti-vacuity | removing the cast arm **fails** the suite; restoring
passes |
| eslint / `check-fnxc-future-dates` | clean / 0 |

One test corrected itself during writing: I asserted `"drafting"`
extracts to `[]`, and it returns `["drafting"]` — legacy filtering is
the caller's job. Kept as a test of that split, since folding the
vocabulary into the extractor would force every future shape to thread
the legacy list.
 2026-07-31 15:35:08 -07:00
gsxdsm
301bd8ed1e fix(census): detect membership and switch column guards, which could land silently (#3247) 
## What

The census prints **"a new guard cannot land silently"** next to a zero.
That claim was true only for the guard form it happened to parse. This
closes the two it could not see. No product change.

The comparison walk visits `BinaryExpression` only, so neither of these
was visible:

```ts
["done", "archived"].includes(task.column)
switch (task.column) { case "todo": ... }
```

Both are lifecycle-column guards by any reading.

## How I found it

By applying this program's own rule — **break the guard on purpose** —
to the guard itself. I staged a probe file with five guard forms and
measured which moved the count:

| form | counted before |
|---|---|
| `t.column === "todo"` | ✅ |
| `t.column !== "in-review"` | ✅ |
| `["done","archived"].includes(t.column)` | ❌ |
| `switch (t.column) { case "triage": }` | ❌ |
| SQL string `"column" = 'done'` | ❌ (separate gate owns this) |

A worker converting a `===` chain into an array membership would have
scored the conversion **and kept the guard**.

*(The first probe run was itself invalid — the file was untracked and
the census enumerates git-tracked files, so the scanned count stayed at
1961 and nothing was measured. Staging it moved the scan to 1962.
Checking the scanned count is what caught that.)*

## The near-miss worth reading

My first implementation counted **unless** the receiver looked like a
role or status — mirroring the `===` walk. On the real tree it reported
**7 column guards**, and I nearly published that as a hidden backlog.

Six were false: `switch (eventName)`, `switch (state)`, `switch (event)`
— event and state enums routinely carry `case "done"` / `case
"archived"`. Landing it would have injected six phantom guards into a
backlog the ratchet treats as zero, and `--strict` would then have
**failed every other worker's PR**.

So the new walks require a **positive** column signal instead. That
regression is pinned by a test asserting all three receivers stay
uncounted.

## Measured

```
real repo, before and after:  COLUMN guards 0, STATUS 185   (no false positives)
staged probe:                 2 detected before -> 4 after
new tests:                    6/6 pass; 3 FAIL with the extension reverted
existing lifecycle-census test: 9/9 still green
lint clean; census --strict passes; fnxc-future-dates: none added
```

## Known limit, stated rather than left to be discovered

The positive signal is the receiver **name**, so `switch (column.id)` —
a `Column` object rather than a task's column — is **not** counted. That
is a real guard shape and it is deliberately out of scope: widening to
reach it is exactly what produced the six false positives, so it needs
its own discrimination rather than a looser regex. Flagged here so the
next person extends it deliberately instead of assuming coverage.

## Why this and not another conversion PR

The conversion queue has been genuinely empty for several cycles —
census 0, 116 resolver sites unchanged across four commits, every site
blinded and pinned. The remaining risk in this program was never another
literal; it was that **the instrument defining "done" could not see two
of the shapes it claims to protect against**. A zero from a detector
with blind spots is the exact failure this phase has spent its time
documenting.


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

## Summary by CodeRabbit

* **New Features**
* Added lifecycle-column guard detection for array membership checks and
`switch` cases.
* Recognizes supported column receiver names and classifies findings
consistently with existing guards.
* Ignores status, event, and state receivers, and avoids duplicate trait
fallback findings.

* **Tests**
* Added coverage for membership checks, `indexOf`, `switch` guards, and
deliberate-literal suppression.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-07-31 14:48:20 -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
4db4052451 fix(gate): the inert-sync-lane ratchet had two free slots — my own drop went unrecorded (#3117) 
Found by merging all five of my open branches together and running the
gates — a check none of them gets individually. The finding turned out
not to be about those branches at all: **`main` itself carries a
baseline of 20 against a real count of 18.**

## It is mine

#3065 replaced three `to === parked.complete || to === parked.archived`
guards with `parked.terminal.has(to)` and took the count **20 → 18**.
The gate *warned* and exited **0**, so nothing failed, I did not
re-record, and the allowance stayed high.

Bisected to be sure rather than inferred:

| commit | count |
|---|---|
| #3051 (`scheduler.ts 12 → 2`) | 20 |
| **#3065 (mine)** | **18** |
| #3100 (mine, comment-only) | 18 |

## The consequence is concrete

The gate whose entire purpose is to stop the inert-conversion class
growing **would have accepted two new inert conversions.**

Verified, not reasoned: with the baseline at 20, adding one new
`parked.wip` comparison to `scheduler.ts` still passed. With the
baseline corrected to 18, the same edit fails.

This is the exact failure mode I called out earlier in this program — a
fix landing without its ledger update — committed by me. The lenient
exit code is why it stayed invisible for a day.

## Two changes

1. **Re-record the baseline 20 → 18.** Restores the ratchet today.
2. **An unrecorded drop now exits 1**, matching the sibling
`check-lane-wiring.mjs`. Restores it tomorrow.

A ratchet that only tightens on request does not ratchet. Two gates
guarding the same program should not disagree about how seriously they
take their own ledger — `check-lane-wiring` already fails here and
explains why; this is the same rule for the same reason.

## Tests, because the exit code *is* the contract

Nothing covered this script's exit codes. The new cases drive it by
**running the script** against a temporarily swapped baseline rather
than importing a helper — a version that printed exactly the right
warning and still exited 0 would satisfy any assertion about its output.

- rise → exits 1, names the file
- unrecorded drop → exits 1, **and the message names
`--update-baseline`**, because a failure that does not name its fix is
noise to whoever hits it
- committed baseline matches the tree → exits 0
- **anti-vacuity**: the scan still finds real guards, so the two
mutated-baseline cases cannot pass against a gate that stopped reading
source and merely compares a number to itself

The baseline file is restored in a `finally`, so a failing test cannot
leave the repo's real ledger modified.

## Measured

- 4 new cases pass (`node --test`).
- Gate exits **1** before the re-record, **0** after, and **1** again
when a synthetic new inert conversion is added.
- `check-lane-wiring`, census `--strict`, `check-fnxc-future-dates` all
clean.

## Census

No movement — this is a gate fix, not a conversion.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 05:47:09 -07:00
gsxdsm
53aef245f9 test(release): the dry-run safety probe matched a prompt that no longer exists (#3045) 
## A release-safety alarm that was firing on wording

```
AssertionError: dry-run must exit before proceed confirmation
```

The probe searched for ``await confirm(`Proceed with release``. The
prompt has since become:

```js
await confirm(`Proceed with ${CHANNEL} release v${chosenVersion} (build, publish to npm tag '${NPM_DIST_TAG}', tag)?`)
```

so `indexOf` returned **-1**, `dryRunExitIndex < -1` was false, and this
has been red on `main` ever since.

## The property itself holds — verified directly, not inferred from a
green suite

| | offset |
| --- | --- |
| first `if (DRY_RUN) {` guard, calling `process.exit(0)` | **28808** |
| the sole `await confirm(` call site | **44503** |

Two dry-run exit guards, one confirmation, exit first. **`pnpm release
--dry-run` cannot reach the proceed prompt.** This was never a real
safety failure.

The probe is narrowed to the stable prefix `await confirm(\`Proceed with
`, which still names the one confirmation in the file while surviving
the interpolated channel and version. The sentence was never the safety
property.

## Why this one mattered more than an ordinary stale probe

A stale probe on a *safety* test spends the alarm on cosmetics. Everyone
learns the assertion is red for no reason — so a genuine reordering
later arrives at an alarm nobody reads. That is a worse outcome than the
test not existing.

## Proven to still catch the real regression

I injected a `confirm(` call **above** the first dry-run exit in
`release.mjs`:

```
confirm injected before the dry-run exit  →  ℹ pass 5   ℹ fail 1   (dry-run must exit before proceed confirmation)
reverted                                  →  ℹ pass 6   ℹ fail 0
```

**No release command was run.** The mutation was local to a scratch copy
of `release.mjs`, reverted immediately, and the working tree verified
clean — `release.mjs` is untouched by this commit, and the diff is the
test file only.

## Fifth and last of the mechanically-fixable suites

That closes the mechanical half of the seven red `scripts/__tests__`
suites I found: `plugin-authoring-docs` (#3036), `verify-fast` (#3038),
`ci-test-shard-timings` (#3040), `engine-vitest-gate-policy` (#3044),
and this.

**`workflow-reliability-release-check` is the one that is not
mechanical** and I am still not touching it: its acceptance map cites 13
test files with **8 missing** and **2 of 5 rows carrying zero surviving
evidence**. That needs its owner to decide, per row, whether the
coverage moved or was deleted — a repoint would launder the gap
(diagnosed on #3036).

Five of six looked identical from the failure line. Only that one is
unsafe to fix without owning the subject.

## Verification (measured)

- this suite — **6 passed / 0 failed** (was 1 failed)
- `eslint` — clean

Test-only. No changeset.
 2026-07-31 02:17:09 -07:00
gsxdsm
b01a2026a0 test(ci): record the third PG gate canary — the policy ledger has been red since #2759 (#3044) 
## The PG gate ledger has been red since #2759

```
AssertionError: the PG gate must stay a narrow, explicit canary list
+   'src/__tests__/postgres/sync-workflow-ir-is-always-default.pg.test.ts'
```

#2759 (`ae4ff9c111`) added that test **and** its entry in
`packages/core`'s `test:pg-gate` script in one commit, without updating
the ledger this assertion compares against.

## Recorded, not approved — and that distinction is why I touched it
carefully

My first instinct was to leave it: ratifying someone else's gate
admission is exactly the "make it green" move I have refused elsewhere
in this sweep.

What changed my mind is that **a red policy test protects nothing**.
While it fails, the *next* gate admission is invisible too — which is
the opposite of what a narrow-canary ledger exists for. The admission is
already live; the gate runs three tests today whatever this file says.
Restoring the ledger re-arms the guard for everything after it.

And the admission does carry the evidence of value AGENTS.md requires,
so recording it is not a rubber stamp. The test pins that
`resolveTaskWorkflowIrSync` returns the **default** IR for every task in
production, which means a guard written as:

```ts
resolveLifecycleColumns(store.resolveTaskWorkflowIrSync(id))?.hold
```

reads as converted, counts as census progress, and is **silently wrong
for every custom workflow** — the non-optional return type hides the
substitution from every caller. Ten call sites depend on that fact
today. Catching that class at the gate is cheaper than catching it in
review; I would have argued for admission had I been asked.

**If the gate's owner disagrees with a third canary, the fix is to
remove it from `test:pg-gate` and shorten this ledger again — not to
leave the assertion red.** I have said so in the code comment too, so
the next reader gets the choice rather than the fait accompli.

## The guard is bidirectional — verified against the gate, not the
ledger

A ledger synced to whatever the gate currently says would be worthless,
so I mutated the **gate script**:

```
removed a canary from packages/core test:pg-gate  →  ℹ pass 3   ℹ fail 1
restored                                          →  ℹ pass 4   ℹ fail 0
```

So it still catches silent gate **shrinkage** as well as growth — a
canary quietly dropping out of the merge gate would fail here.
`package.json` is restored; the diff is the test file only.

## One thing worth passing on

That test names a *class*, not a single bug: ten call sites resolve
lanes through the sync resolver and read as converted while always
getting the default IR. I checked where they live — **all in
`packages/core` and `packages/engine`, none in `packages/cli` or
`plugins`** — so my own territory is clear of it, but whoever owns those
two packages may want the list.

## Verification (measured)

- this suite — **4 passed / 0 failed** (was 1 failed)
- `eslint` — clean

Fourth of the red `scripts/__tests__` suites. Test-only. No changeset.
 2026-07-31 02:11:31 -07:00
gsxdsm
0b10f6ccd3 test(docs): validate nested TOC anchors, and fix the slugify that hid one (#3039) 
**Stacked on #3036** (its commit is the parent). That PR fixes a guard
that had been red on `main`; this closes the gap it leaves and, in doing
so, turned up a second defect in the helper.

## 1. Nested anchors were accepted but never resolved

#3036 makes the parser recognise sub-entries — correct, and it fixes the
red. But it validates only their link *shape*. Measured on that branch:

| corruption | result |
|---|---|
| **nested** entry → `#kb-nonexistent-anchor` | **passes** |
| **top-level** entry → `#kb-nonexistent-anchor` | fails |

A TOC guard exists so links resolve. Checking that for one class of
entry and not the other leaves a dead sub-link to be found by a reader
clicking it.

## 2. Resolving them exposed the slugify bug

Adding the check failed immediately — on the **real document**, against
a heading that exists:

```
Nested TOC anchor #theming--overlay-layering-for-dashboard-views matches no heading
```

The document is right; the helper was wrong. `slugifyHeading` collapsed
whitespace **runs**:

```js
.replace(/\s+/g, "-")     // theming-overlay-layering-...
.replace(/\s/g,  "-")     // theming--overlay-layering-...  ← GitHub, and the doc's own link
```

GitHub emits one hyphen **per space**. `### Theming & Overlay Layering
for Dashboard Views` loses the `&` and keeps both spaces, so the true
anchor carries a double hyphen.

**This was latent, not dormant-and-harmless:** the two spellings differ
only when punctuation is stripped from *between* words, and all eighteen
numbered section titles are punctuation-free — so every existing use of
the helper agreed. The first heading with an `&` in it would have
produced a false failure against a correct document, which is the shape
most likely to get a guard edited rather than believed.

## Mutations (all four)

| mutation | result |
|---|---|
| clean | 4/4 pass |
| nested anchor broken | **fails** ← was green before this PR |
| top-level anchor broken | fails |
| malformed top-level line | fails |
| `slugify` reverted to collapsing | **fails** — the helper fix is
load-bearing |

Lint clean, FNXC gate exit 0. Test-only.

## Note

This is the fifth guard in this batch to ship with a hole found by
mutating it rather than reading it, and the second where fixing one
class of input revealed the checker had been quietly wrong about
another. The pattern is consistent enough to be worth expecting: **when
a guard starts examining something it previously skipped, the first
thing it finds is usually its own bug.**

If #3036 lands first this rebases to a single commit; if taken together
the stack applies as-is.

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

## Summary by CodeRabbit

* **Bug Fixes**
* Improved heading links to match GitHub-style anchors when punctuation
separates words.
* Enhanced nested table-of-contents validation to confirm links point to
headings in the document.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 02:06:03 -07:00
gsxdsm
19b97e9f09 test(verify-fast): the pretest-validator mirror is stale by two, and has been red on main (#3038) 
## The pretest-validator mirror is stale by two

```
assert.deepEqual(PRETEST_STATIC_CHECK_SCRIPTS, PRETEST_CHECKS);
+   'scripts/check-no-cwd-relative-dashboard-test-reads.mjs',
+   'scripts/check-capacity-pool-id.mjs',
```

Production found ten validators; the test's mirror listed eight. **The
world was right and the assertion was stale** — the good direction.

`PRETEST_STATIC_CHECK_SCRIPTS` is *derived* from `package.json`'s
pretest chain, so `verify:fast` picked both new validators up
automatically when they were added. They are real scripts, they run in
pretest, and verify:fast was already running them. Only the mirror
needed telling.

Added in production order, since the assertion is a `deepEqual` and
order is part of it. Plain strings for these two — the surrounding
entries are split and re-joined to keep banned phrases (the port-kill
and nohup literals) off a single source line for the policy scanner, and
neither new name contains one.

## The guard is load-bearing — verified against the source of truth, not
the mirror

Syncing a mirror is worthless if the assertion can no longer fail, so I
mutated `package.json`'s pretest chain rather than the test:

```
dropped check-capacity-pool-id from pretest  →  ℹ pass 16   ℹ fail 1
restored                                     →  ℹ pass 17   ℹ fail 0
```

So it still catches a validator silently leaving `verify:fast`, which is
the regression that actually matters. `package.json` is restored; the
diff here is the test file only.

## Second of seven, and the contrast is the point

This is the second of the seven red `scripts/__tests__` suites I found
on clean `main` (after #3036). It was genuinely mechanical.

`workflow-reliability-release-check` was not, and I did **not** fix it —
diagnosed on #3036 instead:
`docs/custom-workflow-reliability-acceptance-map.md` cites 13 test files
of which **8 are missing**, and **2 of 5 rows have zero surviving
evidence**, including *"a custom workflow can be authored/imported,
rejected on invalid IR, saved, discovered, selected, and reloaded"*. The
obvious repoint would have turned it green while the behaviour stayed
unverified.

That contrast is why I am taking these one at a time rather than
sweeping them green: two of seven look identical from the failure line,
and only one of them is safe to fix without owning the subject.

## Verification (measured)

- this suite — **17 passed / 0 failed** (was 1 failed)
- `eslint` — clean

Test-only. No changeset.
 2026-07-31 01:57:59 -07:00
gsxdsm
f411d55591 test(docs): the PLUGIN_AUTHORING TOC guard rejected legal nested entries, and has been red on main (#3036) 
## A legal Markdown sub-entry turned this guard red

```
AssertionError: Invalid TOC line: - [Theming & Overlay Layering for Dashboard Views](#theming--overlay-layering-for-dashboard-views)
```

That line is an ordinary nested TOC entry, indented under item 8 of
`docs/PLUGIN_AUTHORING.md`. The parser did `.map(line => line.trim())`
**first** and then required every line to match the top-level `N.
[title](#anchor)` shape — so indentation, the one thing distinguishing a
sub-entry from a malformed top-level one, was destroyed before it could
be used.

**The doc was never wrong.** Only the parser was, and it has been red on
`main` since the entry was added.

Indentation is now read before trimming. Sub-entries are still required
to be well-formed links; they just do not participate in the numbering
or the count.

## Both guard directions verified by breaking them

A looser parser that skipped anything unrecognised would have made the
failure go away while quietly ending the guard's usefulness — so I
checked it still fails in both directions:

| mutation | result |
| --- | --- |
| top-level `9.` rewritten as a bullet | still fails (`Invalid TOC
line`) |
| nested entry replaced with un-linked prose | still fails (`Invalid
nested TOC line`) |

## The wider finding, which matters more than this fix

I found it by sweeping `scripts/__tests__` against clean `main`: **688
passing, 7 failing test files.**

| suite | failing assertion |
| --- | --- |
| `ci-test-shard-timings` | committed timing snapshot references live
test files |
| `dependency-security-floor` | pnpm overrides pin transitive protobufjs
to a safe floor |
| `engine-vitest-gate-policy` | pg gate canaries remain a subset of the
enabled suite |
| `plugin-authoring-docs` | **this PR** |
| `release-prompt-gate` | release dry-run exits before proceed
confirmation |
| `verify-fast` | defaults to every canonical pretest validator |
| `workflow-reliability-release-check` | manifest references existing
seam files |

All sit **outside the merge gate**. That is now the third instance of
this pattern I have hit — #2969's 15 red agent-action tests and #3033's
stale ratchet list were the others — and it is clearly systemic rather
than incidental.

I fixed only the one in plugin territory. The rest span CI sharding,
**dependency security** (that protobufjs floor is a security assertion
currently not holding), release gating and workflow manifests. Each
needs its owner's judgement about whether the assertion or the world is
wrong, and a drive-by "make it green" is exactly how a real signal gets
erased — `dependency-security-floor` especially.

## Verification (measured)

- this suite — **4 passed / 0 failed** (was 1 failed)
- `eslint` — clean

Test-only; the doc is untouched. No changeset.
 2026-07-31 01:52:13 -07:00
gsxdsm
83294a6958 fix(test): the protobufjs security floor was asserted against an empty object (reads like a deleted pin; it moved) (#3035) 
`scripts/__tests__` has **seven** files failing on main. None are in the
merge gate, so nobody is blocked — which is exactly how this survived.
This fixes the one that names a real risk.

## It reads like a deleted security pin. It isn't.

```
AssertionError: package.json pnpm.overrides: protobufjs range undefined
                must include an explicit semver version
```

#2220 moved pnpm overrides from `package.json` to `pnpm-workspace.yaml`
for pnpm 11 readiness. The assertion kept reading `package.json`, where
`pnpm.overrides` is now `{}`.

**Nothing was ever exposed**: `pnpm-workspace.yaml` still pins
`protobufjs: ^7.5.8` and the lockfile resolves `7.6.5`, comfortably
above the 7.5.5 floor. The sibling assertion that checks lockfile
resolutions has been passing the whole time — which is the only reason
this was survivable.

But no reader could distinguish this message from a genuinely removed
pin without doing the archaeology, and a guard that is permanently red
while naming a real risk teaches its readers that red means nothing
here. That is worse than no guard: it launders a real removal into
background noise.

## Measured both ways

| change to `pnpm-workspace.yaml` | result |
|---|---|
| pin removed | **fails** — `protobufjs range undefined must include an
explicit semver version` |
| pin lowered to `^7.4.0` | **fails** — `range ^7.4.0 is below required
floor 7.5.5` |
| unchanged | passes |

## Second assertion

`package.json` must declare **no** `pnpm.overrides`. If overrides move
again — or come back — that fails and points at the next reader, instead
of letting the floor go silently unchecked. That is precisely the
failure mode #2220 produced, and nothing would otherwise catch a second
occurrence.

## The other six

Left alone deliberately; each needs its own diagnosis and they are
unrelated to one another (I checked — the "seven files, one failure
each" pattern looked like a common cause and is not):

- `workflow-reliability-release-check` — manifest references
`workflow-definition-store.test.ts`, which no longer exists. **Likely a
real signal**: a release check pointing at a deleted seam file covers
nothing. Best next one to pick up.
- `ci-test-shard-timings` — snapshot references missing test files;
affects shard balancing.
- `verify-fast`, `engine-vitest-gate-policy` — validator/canary list
drift.
- `plugin-authoring-docs` — a TOC anchor for a heading containing `&`.
- `release-prompt-gate` — dry-run no longer exits before the proceed
confirmation.

## Verification

`node --test scripts/__tests__/dependency-security-floor.test.mjs` **4
passed** · `pnpm test:gate` 161 + 13 + 487 + 71 · lint · changesets —
green.


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

## Summary by CodeRabbit

* **Bug Fixes**
* Updated security validation to correctly read protobufjs version
overrides from the workspace configuration.
* Added safeguards to detect outdated override locations and help
prevent future security-check regressions.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-07-31 01:46:56 -07:00
gsxdsm
ccf562f178 gate: compare mirrored INTERFACES too, and delete the dead prop that found (#3034) 
> **Re-landing the second half of #3031.** That PR merged into #3029's
branch and only its first commit reached `main` — the arity rule
shipped, the interface rule and its finding did not. Verified on `main`:
the gate reports *"7 mirrored function(s)"* with no interface count, and
the dead prop below is still there.

## What

The arity rule covers exported functions. The same files also mirror
**interfaces**, which is the larger surface — six copies of
`PluginDashboardViewContext` alone.

**One direction only.** A mirror may declare *fewer* properties, and all
six do (6, 8, 7, 7, 3, 6 against the real nine) because a plugin mirrors
the fields it uses. Demanding equality would fail every plugin for not
using everything — which is how a check gets ignored and then deleted. A
property the real type **doesn't have** is the drift that matters: a
rename nobody propagated, where the plugin keeps compiling and reads a
field the host never sends.

## Its first interface run found a live one

```
dashboard-interop.d.ts:67  TaskCardProps.workflowStepNameLookup is not a property of the real TaskCardProps
```

Git history says it **was** one when FN-2466 and FN-7039 added this
threading. The dashboard removed it later; nothing propagated that to
the plugin's hand-written declaration. So the plugin built a lookup map
from `context.workflowSteps` on every render, threaded it through two
components, and handed it to a `TaskCard` with no such prop.

Deleted rather than exempted — a new gate shouldn't ship with a waiver
for its own first finding. Behaviour-preserving: the value never reached
anything.

## Measured on `main`

| check | result |
|---|---|
| population | **7 functions + 10 interfaces across 6 plugins**, all
matching after the deletion |
| control probe | phantom property **caught**; clean tree exits 0 |
| anti-vacuity | now also requires a non-zero *interface* comparison |
| gate's own suite | **5 → 8** |
| dependency-graph suite | 179 green; `tsc` clean |
| other five gates · census | green |

## Running total for this check

Three real drifts, none of which any other instrument reported:

1. `isTaskStuck` stuck at three parameters through the whole lane
conversion (#3003)
2. `taskStuckTimeoutMs?: number` vs the required `number | undefined` —
in **two independent authors'** declarations
3. `workflowStepNameLookup` outliving its removal from `TaskCard`

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 01:43:58 -07:00
gsxdsm
a460a9bbc0 fix(plugins,dashboard): the dependency graph drew every card with the LEGACY lane vocabulary (#3029) 
## The third producer of unflagged cards — the one a host-side fix could
not reach

#3025 fixed the two producers that go through `renderTaskCard`.
`GraphTaskNode` is a third: it imports `TaskCard` **directly** through
the plugin's interop shim, so that fix bypassed it and every role helper
inside a graph card kept reading the legacy ids.

The same component also called the stuck predicate without its flags:

```ts
const isStuck = isTaskStuck(task, taskStuckTimeoutMs, lastFetchTimeMs);   // no columnFlags
```

so `isWipColumnRole` fell back to the literal and **no card in the graph
could ever be stuck on a renamed board**. Because `isStuck` gates
`isActive`, a wedged card rendered with the **active** styling — the
graph reported *"running"* about a task that had not moved in hours,
while the main board showed the same card as stuck.

That asymmetry between two views of one task is the defect, and it is
what the new test pins.

## One cause, so one fix

Both symptoms came from the same gap: `PluginDashboardViewContext`
exposed `tasks` and nothing about the board's vocabulary. It now carries
`columnFlagsByTaskId` — the same per-task map `renderTaskCard` already
uses, **two lines away in the same object literal**.

## I filed this twice as blocked on a public-API change. It was not.

```
packages/dashboard                        @fusion/dashboard                        private: true
packages/plugin-sdk                       @fusion/plugin-sdk                       private: true
plugins/fusion-plugin-dependency-graph    @fusion-plugin-examples/dependency-graph private: true
```

No published surface anywhere in the path — three in-repo private
packages and a hand-written `.d.ts`. **#3026 landed the general form of
that mistake while I was still making it**: a deferral's stated blocker
is a claim, and mine decayed unchecked until I finally measured it.

## Two type decisions worth reviewing

- **`Partial<TraitFlags>`** in the plugin-facing type, not the
dashboard's `ExecutorColumnFlags` — that module's own header restricts
it to `@fusion/core` and `react` imports so external plugin builds can
consume it. Same runtime object either way.
- **`MainContentProps.columnFlagsByTaskId` widened** from `{complete,
archived, intake, hold}` to the flags the map really carries. It is
built from `workflow.columns.find(...).flags`, so the four-flag
declaration was a narrower view than the value — and `countsTowardWip`,
which every wip predicate needs, was invisible through it. That narrow
type is why threading this looked impossible at first.

Absent still means legacy, matching how the host treats remote rows and
off-board columns: the degraded answer is the documented literal, never
*"this board has no wip lane"*.

## Revert proof

Dropping the 4th argument:

```
AssertionError: expected 'graph-task-node graph-task-node--acti…' not to contain 'graph-task-node--active'
      Tests  1 failed | 26 passed (27)
```

The paired case (a fresh legacy `in-progress` card still reads active)
passes both ways by design — it guards against over-detection, so I am
not counting it as coverage.

The gate agrees independently:
`plugins/fusion-plugin-dependency-graph/src/GraphTaskNode.tsx: 1 -> 0`,
baseline re-recorded 16 → 15 in the same commit.

## Verification (measured)

- plugin suite — **185 passed / 20 files**
- dashboard `dashboard/` + `plugins/` suites — **48 passed / 6 files**
- `tsc --noEmit` clean in both packages; `pnpm lint` clean
- `lifecycle-column-census --strict`, `check-lane-wiring` (15, none
added), `check-sql-column-literals`, `check-inert-flag-seams`,
`check-fnxc-future-dates` — green

No changeset: all three packages are `private: true`.

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 01:30:47 -07:00
gsxdsm
5897d87e95 fix(gate): the lane census judged a call against a signature it never had (the false positive #3013's merge introduced) (#3021) 
#3013's merge of same-named declarations fixed a false **negative** and
introduced a false **positive**.

`ModelSelectorTab` declares its own two-parameter
`resolveEffectiveExecutor(task, settings)` — a pass-through with nothing
lane-related — while an unrelated exported function of the same name in
`effective-model-resolution.ts` takes `columnFlags`. Both local calls
were reported unwired against a signature they have never had.

Only **exported** declarations enter the accepting map, so the rule is
exact: if the calling file declares the name itself and the map entry
came from a different file, the call resolves to the local declaration
and is not a lane call here.

## The version I did not ship

My first attempt re-ran the detector over the single calling file and
used that result. It scored *better* on this tree — **19 → 16** instead
of 19 → 17, also clearing `bucket-mapping.ts` — and I threw it away.

A single-file pass cannot resolve an **imported** options interface. A
locally-declared function with an imported context type would quietly
stop being lane-accepting, and every call to it would stop being
checked. That is a false negative, which is the one failure a ratchet
must not have; the better-looking number came from the gate seeing less.
The global pass still does all type resolution here — only the *choice*
of declaration is local.

## Measured

| | |
|---|---|
| new tests | 3 |
| against the old census | **1 of 3 fails** — the positive |
| baseline | **19 → 17**, exactly the two `ModelSelectorTab` sites |

Both negatives pass either way and they are the ones that matter: a file
declaring its **own** exported lane function is not shadowed by itself,
and a file declaring nothing is judged normally. Shadowing must not
become a way to disappear a genuine unwired call.

## Still flagged, honestly

`bucket-mapping.ts:75` stays in the baseline. `bucketForTask(task:
TaskItem)` is only lane-accepting because `TaskItem` *declares*
`columnFlags` — the lane data rides on the domain object, so passing
`task` forwards it inherently. That is a different limitation
(options-bag vs domain-entity parameters) and I have not tried to fix it
here; it accounts for 2 of the remaining 17 along with
`otherBucketSecondaryLabel`.

## Verification

`node --test scripts/__tests__/check-lane-wiring.test.mjs` **19 passed**
· `pnpm test:gate` 13 + 161 + 487 + 71 · lint · lifecycle census
`--strict` · lane-wiring · fnxc-dates (TZ=UTC) · changesets — green.
 2026-07-31 01:03:24 -07:00
gsxdsm
3a016b1f17 fix(scripts): four FNXC stamps carried hour 26, and main has been red on them (#3010) 
## `main` is currently red on `check-fnxc-future-dates`

Four stamps read `2026-07-30-26:10` — an hour that cannot exist.

They're exactly what #2995 taught this gate to catch. That PR landed the
hour validation (`00-23`) *after* #2999 had already merged these four,
so the gate started reporting a defect that was already sitting there
rather than one introduced afterwards. **The guard is working**; nothing
was checking before it.

```
scripts/lib/backend-db.mjs:41
scripts/reconcile-task-state-consistency.mjs:8, :51
scripts/__tests__/reconcile-task-state-consistency.test.mjs:109
```

Corrected by **literal normalisation** — 26:10 on the 30th *is* 02:10 on
the 31st — rather than flattening them to an arbitrary in-range hour.
AGENTS.md specifies `yyyy-MM-dd-hh:mm`, and the stamp exists to give a
readable why-does-this-exist trail, so the ordering is the part worth
preserving.

## The baseline tightening rides along, and it's a date rollover

Stamps written yesterday as `2026-07-31` were future *then* and were
baselined as such. Today they're past, so **176 files ratchet to zero**.
Nobody did anything.

The gate rewrites the baseline as a side effect and exits 0, so leaving
it uncommitted dirties the tree on every subsequent run **for everyone**
— which is why it belongs in this commit rather than a later one.
Re-recording on a decrease is the rule this gate and its siblings
already state.

Worth knowing about the design, since I wrote it: this churn recurs
whenever a day boundary passes with future-dated stamps in the baseline,
and it shrinks only as people stop writing them — which is the behaviour
the gate exists to produce. **93 files still carry a non-zero
allowance**, so the drain isn't finished. If it stays noisy once those
clear, the gate's fail-on-tighten contract is the thing to revisit, not
the stamps.

## Measured

| check | result |
|---|---|
| gate | red before, **exit 0 after**, stable across two consecutive
runs |
| baseline | −176/+25 entries, all date-rollover |
| inert-seam · sql-literal · lane-wiring · census | all green |
| reconciler's own suite | green |

## One correction to a claim I made earlier this session

While investigating I reported the gate as hanging for 600s. It wasn't —
the harness killed the process (exit 144) and the empty output made it
look like a stall. The gate completes in seconds. Noting it because I
nearly filed a performance bug against a healthy script.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 00:36:21 -07:00
gsxdsm
ffe9898710 fix(gate): the lane-wiring census could not see three of the shapes it asks for (incl. a false positive it started reporting) (#3013) 
**The gate could not see three of the shapes it exists to check** —
including the wiring I landed this week in #2990 and #3004. Found by
using it: the baseline still listed `useBlockerFanout.ts`,
`ExecutorStatusBar.tsx`, and `TaskDetailModal.tsx` as unwired *after*
those PRs merged.

### 1. Conditional shapes

Passing lanes only when they resolved is the **correct** way to write
these — an empty trait index means "not loaded yet", not "nothing is
terminal", so the caller must fall through to the documented legacy
default rather than fabricate one. Both idioms that produces were
invisible:

```ts
computeBlockerFanoutMap(tasks, flags ? { columnFlagsByTaskId: flags } : {})   // ConditionalExpression
computeBlockerFanoutMapCore(tasks, N, { ...(flags ? { classify } : {}) })     // SpreadAssignment, name === undefined
```

Either branch supplying the lane now counts. **Neither branch supplying
it is still unwired** — that negative is tested.

### 2. Vocabulary

`columnFlagsByTaskId`, the per-task trait index the dashboard threads,
was never added. It answers every lane question at once, so a call site
dropping it reverts to the legacy vocabulary wholesale — and the gate
would have stayed silent.

### 3. Name collisions — the false positive

Declarations were `set` by name, so the **last one parsed won**. Core's
`computeBlockerFanoutMap(tasks, n, opts)` and the dashboard wrapper
`computeBlockerFanoutMap(tasks, opts)` put their lane options at
**different argument indices**, so core's callers were checked against
the wrapper's signature: `task-priority.ts:141` passes `terminalColumns`
at index 2 and was reported unwired.

I caught this because adding the vocabulary entry in (2) made it appear.
A ratchet that reports a correctly-wired site is worse than one that
misses it — the first person to open one learns the number is noise.
Both shapes are now merged; a call satisfying either counts.

### Measured

| | |
|---|---|
| new tests | **6** — every positive paired with its negative |
| against the old census | **3 of 6 fail** — exactly the three
positives; the negatives pass either way, which is why they exist |
| baseline | **23 → 19** — four sites recognized as *already* wired; no
site newly excused |
| new flags | none |

### Verification

`node --test scripts/__tests__/check-lane-wiring.test.mjs` **16 passed**
· `pnpm test:gate` 161 + 13 + 487 + 71 · lint · lifecycle census
`--strict` · fnxc-dates (TZ=UTC) · changesets — green.

Seven other `scripts/__tests__` files fail on main independently of this
change (`verify-fast`, `dependency-security-floor`,
`engine-vitest-gate-policy`, `plugin-authoring-docs`,
`release-prompt-gate`, `ci-test-shard-timings`,
`workflow-reliability-release-check`). None are in the merge gate and
none are touched here — noting them because I looked, not because this
PR affects them.
 2026-07-31 00:33:13 -07:00
gsxdsm
f10261f424 fix(scripts): the contamination audit scanned four legacy lanes and claimed it had (#3005) 
## An audit that scanned four legacy lanes — and claimed it had

Two halves of the same wrong answer.

**The query allowlisted the lanes:**

```sql
WHERE deleted_at IS NULL AND "column" IN ('triage','todo','in-progress','in-review')
```

On a board whose lanes are named anything else that matches **nothing**,
so the audit scans zero rows and reports zero contamination — a clean
bill of health from a scan that never happened. `triage` is in that list
too, a lane U11 (#2515) deleted.

**And the report asserted the coverage it did not have:**

```js
scannedColumns: ["triage", "todo", "in-progress", "in-review"],
```

printed regardless of what the query returned. When I first surveyed
this script I called that field "the one thing keeping it from being
fully silent" — it turns out it was a **claim, not an observation**, so
it was not keeping it honest at all. It is now derived from the rows
that came back.

## Fix: exclude finished lanes instead of allowlisting active ones

Inverted so the default is the safe one — an unrecognised lane is active
work by assumption and **is** audited; only lanes that genuinely mean
finished drop out. An allowlist fails **closed** (skip everything
unknown), a denylist fails **open** (look at it), and for an audit one
extra finished branch is a far smaller error than auditing nothing.

Filtered in JS rather than by building a dynamic SQL exclusion: it keeps
**one** place deciding what "finished" means, and removes the last
raw-SQL lane literal from this file.

## Revert proof

```
✖ scannedColumns reports the board's real lanes, not a fixed legacy claim
✖ reports each scanned lane once, and nothing at all for an empty board
ℹ pass 1   ℹ fail 2
```

## A demonstration of #3000, for free

This PR removes a 4-literal raw-SQL clause, and
`check-sql-column-literals` here reports **22, unchanged and green** —
because this branch predates #3000 and the gate still walks `packages/`
only. That is precisely the blind spot #3000 closes, reproduced a second
time.

## Merge order

This removes the 4 literals #3000 baselines. Landing this **after**
#3000 drops that count and its gate fails on DECREASE — that gate
auto-rewrites the baseline and asks for the commit, unlike
`check-lane-wiring` which needs an explicit `--update-baseline`. Either
order works; one of them needs a re-record, and I am happy to push it.

## Verification (measured)

- `node --test` — **3 passed / 0 failed** (1 pre-existing + 2 new)
- `node --check`, `eslint` — clean
- `lifecycle-column-census --strict`, `check-lane-wiring`,
`check-fnxc-future-dates` — green

No changeset: root `scripts/` is repo tooling, not part of the published
package.

## Territory status

This was the last item I know of in `scripts/`. The four operator
scripts holding lane assumptions — `recover-stale-blocked-by` (#2992),
`reconcile-task-state-consistency` (#2994),
`reconcile-leaked-soft-deletes` (#2999) and this one — are now either
resolved or, where a script genuinely cannot resolve lanes, made loud
rather than silent.
 2026-07-31 00:27:41 -07:00
gsxdsm
52a66297fc fix(gate): main is red — normalize #2994's four impossible-hour stamps (#3006) 
**`main` is currently red on the FNXC gate.**

```
$ node scripts/check-fnxc-future-dates.mjs   # on origin/main
  scripts/reconcile-task-state-consistency.mjs: 2 future-dated FNXC stamp(s), baseline allows 0
  scripts/lib/backend-db.mjs: 1
  scripts/__tests__/reconcile-task-state-consistency.test.mjs: 1
exit 1
```

#2994 carried four `2026-07-30-26:10` stamps. I flagged them on that PR
before it merged; #2995 (the hour check) landed first, so the merge
order turned the warning into a red gate rather than a red PR.

Clamped to `23:10` — same rule as the nine before it: hour to `23`,
minutes preserved, so ordering within each file survives. This is a
normalization with a stated rule, not a claim about the true minute.

**Verified:** FNXC gate exit 0, `reconcile-task-state-consistency` 8
pass / 0 fail. Comment-text only.

### Worth fixing at the source

Thirteen impossible-hour stamps across six PRs in two days, and the
hours climb — `24:40` → `25:30` → `26:10`. They are being written as a
continuing sequence past midnight rather than read off a clock, which is
a reasonable instinct and produces an invalid stamp every time.

The trap is that the honest spelling does not work either: a genuine
post-midnight stamp needs *tomorrow's* date, and the gate compares
against the **local** calendar — so `2026-07-31-00:40` written from
UTC-7 is future-dated and fails for a different reason. Clamping to
`23:xx` is currently the only spelling that satisfies both, which is not
obvious and is why this keeps recurring.

If it recurs again, the fix is probably in the error message rather than
more normalization PRs: the gate could name the valid range and the
timezone it compares against, so the next author sees the constraint at
the moment they hit it.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-31 00:16:39 -07:00
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>
 2026-07-31 00:03:02 -07:00
gsxdsm
5adf0d955a fix(scripts): the soft-delete reconciler wrote a literal archived into boards that do not have one (#2999) 
## A repair script that wrote a column the board does not have

Under `--apply`, against an operator's live database:

```js
await tx.execute(sql`UPDATE project."tasks" SET "column" = 'archived' WHERE id = ${row.id}`);
```

On a board that does not declare `archived`, that is not a mislabel — it
parks the row in a column the workflow does not have, **manufacturing
exactly the undeclared-column state this migration keeps repairing
elsewhere**.

The selection was wrong in the same direction, which made the write far
worse. "Leaked" meant `column !== "archived"`, so on a renamed board
**every** soft-deleted row looked leaked — including the ones resting
correctly in that board's own archived lane. The repair then rewrote
them. The tool's fix *was* the damage.

## Three changes, because fixing one would have left the others deciding

**The SQL pre-filter carried the same literal** (`AND "column" !=
'archived'`), so the query and the planner each imposed the legacy
vocabulary independently. Dropped it — soft-deleted rows are a small
set, so selecting them all and filtering in the pure planner costs
nothing and leaves **one** place that decides what "archived" means.

**The filter takes the set**; a row resting in *any* of the board's
archived lanes is not leaked.

**The write resolves per task**, because the destination must be that
card's own lane, not a board-wide pick. A row whose archived lane cannot
be resolved is **skipped and reported**, never written with a guessed
id. A recovery script that declines to act on rows it does not
understand is recoverable; one that writes a plausible wrong value is
not.

Verified rather than assumed — a store that answers nothing resolves to
the default lifecycle:

```
lifecycle from unanswering store: {"intake":"todo",…,"archived":"archived"}
```

so a legacy board repairs exactly as before.

## Correcting myself

On #2994 I wrote that this follow-up "needs the same `importCore` seam".
It doesn't: `openBackend` already returns `{ core, store, … }` and this
script already destructures `core`. No new plumbing was required. I
posted that correction on #2994 too, since acting on it would have
wasted someone's time.

## Revert proof

```
✖ a soft-deleted row already in the board's RENAMED archived lane is not leaked
✖ a board with several archived lanes treats all of them as resting places
ℹ pass 5   ℹ fail 2
```

The other two new cases pass both ways by design — they guard the legacy
meaning and the still-catches-a-real-leak direction — so I am not
counting them as coverage of the defect.

## Verification (measured)

- `node --test` across all three script suites — **17 passed / 0
failed**
- `node --check`, `eslint` — clean
- `check-sql-column-literals`, `lifecycle-column-census --strict`,
`check-lane-wiring`, `check-fnxc-future-dates` — green

No changeset: root `scripts/` is repo tooling, not part of the published
package.

## Gate blind spot found while verifying this, NOT fixed here

I removed a raw-SQL lane literal and expected
`check-sql-column-literals` to drop from 22 — its own header says *"a
LOWER count fails too so the baseline is ratcheted down"*. It stayed at
**22 and green**, because it walks `PACKAGES` only and **never scans
`scripts/`**.

That is the same shape as the lane-wiring gap #2978 closed (it scanned
neither `plugins` nor `dashboard/app`).
`scripts/audit-branch-cross-contamination.mjs:185` still holds `WHERE …
"column" IN ('triage','todo','in-progress','in-review')`, invisible to
the gate. Left as a separate follow-up rather than bundled into a
product fix.
 2026-07-30 23:59:54 -07:00
gsxdsm
ac67b8d585 fix(scripts): the FN-4000 consistency reconciler failed in BOTH directions on a renamed board (#2994) 
## The FN-4000 consistency reconciler failed in *both* directions

`findTaskStateInconsistencies` keyed both checks on legacy lane
literals, and they break in opposite ways:

```js
const hasDoneTransient = task.column === "done" && (status failed || error || worktree || blockedBy || …);
if (task.status === "failed" && task.column !== "in-review") { … }
```

| check | on a renamed board | effect |
| --- | --- | --- |
| `hasDoneTransient` | **never fires** | a finished card still holding
`status:"failed"`, a worktree, a blockedBy or live recovery counters is
never reported and never normalized — precisely the stale state FN-4000
exists to clear |
| `failed-status-outside-in-review` | **fires for every failed card** |
no column equals the literal, so the report lists the whole board |

The second is the more dangerous of the two: a tool that reports nothing
looks broken, but a tool that reports everything looks like it is
working.

## Wiring, and why the resolver is injected rather than built inline

Lanes are resolved **per task** (a board can span workflows) and passed
in. Resolving inside the loop would drag `importCore()` — and therefore
a built `packages/core/dist` — into every unit test of a pure
reconciliation loop.

`main` wires the real resolver whenever it opened a real backend, so
this is **not** the inert optional-parameter shape this migration keeps
finding. A caller injecting its own store (tests) has no staged dist and
falls back to the documented legacy literals, which is exactly today's
behaviour.

`importCore` is now exported from `scripts/lib/backend-db.mjs` so
operator scripts reach core helpers through the **same staged-dist seam
`openBackend` already uses**, rather than each growing its own dist path
— `@fusion/core` is not resolvable from repo-root `scripts/`, which is
what made the obvious import fail.

The normalization move now targets the card's **own** column: naming
`"done"` was only ever a way of spelling *"where it already is"*, since
the move exists to trigger the store's done-normalization.

## One of my test expectations was wrong before the code was

My first version asserted that a card in a renamed complete lane with
`status:"failed"` yields only the transient-state finding. It yields
**both** — and that is correct, because a failed card outside the review
lane genuinely is flagged. I isolated the case (dropping
`status:"failed"`, keeping the worktree) so it pins one behaviour
instead of blurring two, rather than "fixing" the expectation to match
whatever came out.

## Revert proof

Restoring the four literals:

```
✖ reports stale transient state in a RENAMED complete lane
✖ does NOT flag a failed card that is sitting in the board's own review lane
✖ runReconciliation normalizes a renamed complete lane by moving the card to its OWN column
ℹ pass 5   ℹ fail 3
```

The remaining two new cases pass both ways by design — "still flags a
failed card outside the resolved review lane" and "unresolved lanes keep
exactly the legacy behaviour" guard against over-correction, so I am not
counting them as coverage of the defect.

## Verification (measured)

- `node --test` — **8 passed / 0 failed** (3 pre-existing + 5 new)
- sibling script suites (`recover-stale-blocked-by`,
`reconcile-leaked-soft-deletes`) — **7 passed**, unaffected by the
shared-lib export
- `node --check`, `eslint` — clean
- `lifecycle-column-census --strict`, `check-sql-column-literals`,
`check-lane-wiring`, `check-fnxc-future-dates` — green

No changeset: root `scripts/` is repo tooling, not part of the published
package.

## Still not addressed in this territory

`reconcile-leaked-soft-deletes.mjs` carries a raw `UPDATE
project."tasks" SET "column" = 'archived'` — on a renamed board that
writes a column the workflow does not declare, creating the
undeclared-column state this migration keeps repairing elsewhere. It
holds a raw backend rather than a store, so it needs the same
`importCore` seam this PR exports; left for a follow-up rather than
bundled here.
 2026-07-30 23:49:05 -07:00
gsxdsm
bb6c08d9d6 fix(scripts): the blocked-by recovery reported "Repairs: 0" on a board it never examined (#2992) 
## A recovery tool that reports "Repairs: 0" without having examined
anything

Every lane test in `recover-stale-blocked-by.mjs` is a legacy id:

```js
function isTerminalColumn(column) { return column === "done" || column === "archived"; }
const isActive = row.column === "in-progress" || (row.column === "in-review" && row.worktree && !row.paused);
if (row.column !== "todo" || !row.blockedBy) continue;          // ← the candidate gate
```

On a board whose lanes are named anything else, that gate matches
**nothing**. The planner returns no findings and the script prints
`Repairs: 0`.

An operator running a recovery reads that as *"the board is fine"* when
the tool never examined a single card. **A silently empty answer from a
recovery tool is the worst shape available** — indistinguishable from
success, and consulted precisely during an incident.

This is not dead code: `docs/soft-delete-verification-matrix.md` cites
it as the GREEN backstop for FN-5528, and it has its own test file.

## Detection only — and why I did not "fix" the classification

Correct classification needs the board's resolved trait vocabulary. This
script holds a **raw backend** (`openBackend` → `asyncLayer` + `sql`),
not a `TaskStore`, so resolving lanes here would mean reimplementing IR
trait resolution inside a `.mjs` script — a worse bug than the one it
fixes, and precisely the kind of second, drifting copy this migration
keeps deleting.

So the assumptions are not repaired; they are made **loud**. That is the
same principle the lane-wiring gate applies to itself:

> a gate whose errors land on "nothing to report" is the one failure
mode a ratchet must not have

The unknown-lane list rides on the returned array as a
**non-enumerable** property rather than widening the return type —
`recoverBlockedBy` is consumed as `findings[]` by the entry point and by
tests, and an operator may be scripting around that shape.

## The first test pins the gap rather than papering over it

```js
assert.deepEqual(unrecognisedLanes(rows), ["backlog", "checking"]);
// The gap this warns about, pinned rather than claimed fixed: the planner still sees nothing.
assert.deepEqual(planRecoverBlockedBy({ rows, tasksDir }), []);
```

I would rather the next reader find that assertion than discover it
themselves during an incident.

## Revert proof

With `unrecognisedLanes` returning `[]` (the pre-fix behaviour):

```
✖ names lanes the planner does not understand, so an empty result cannot read as healthy
✔ stays quiet on a legacy board, so the warning means something when it appears
✖ reports each unknown lane once, ignoring rows with no column at all
ℹ pass 5   ℹ fail 2
```

The legacy-board case passes **both ways by design** — it guards against
the warning firing spuriously, so I am not counting it as coverage of
the defect.

## Verification (measured)

- `node --test` — **7 passed** (4 pre-existing + 3 new), 0 failed
- `node --check`, `eslint` — clean
- `check-sql-column-literals`, `lifecycle-column-census --strict`,
`check-lane-wiring`, `check-fnxc-future-dates` — green

No changeset: root `scripts/` is repo tooling, not part of the published
package.

## How this was found, since the method matters more than the fix

My batch is "cli + plugins + anything left", and I had been reading
*"anything left"* as nothing. Eight packages and all of `scripts/` sit
outside the four named batches. This is the first thing I found there;
sibling one-shot scripts (`reconcile-task-state-consistency.mjs`,
`reconcile-leaked-soft-deletes.mjs` — which contains a raw `UPDATE … SET
"column" = 'archived'`) carry the same hardcoded assumptions and are
**not** addressed here.
 2026-07-30 23:41:03 -07:00
gsxdsm
684c324084 fix(gate): the lane-wiring census counted { reviewColumns: undefined } as wired (#2984) 
## What

Follow-up to the finding @gsxdsm left on #2981, taking the direction
offered there.

Both arms of this census asked whether the lane argument was
**present**, not whether it carried anything:

```ts
isThing(task, { reviewColumns: undefined });   // property present -> counted as wired
isThing(task, undefined);                      // arity satisfied  -> counted as wired
```

The callee receives exactly what it received before: nothing. The seam
is still inert, the board still reads the legacy vocabulary — the census
just stops saying so, which is the one failure mode a ratchet must not
have.

Same defect as the positional one #2981 fixes in
`check-inert-flag-seams`, one level in. The two gates are complementary
by design — this one owns the options-object and default-valued shapes
the other is structurally blind to — so the hole had to be closed in
**both**. Neither covered it, confirmed by probing each with a control
shape.

## The direction I took, since the review raised it as a contract
question

> *tightening just relocates the dishonesty into whichever spelling
survives... especially as I have already spent three attempts learning
that heuristic tightening here trades false positives for worse false
negatives.*

Agreed, which is why this is the narrowest possible reading rather than
a heuristic:

**Only a literal `undefined` / `void 0` counts as empty.** Shorthand `{
reviewColumns }` forwards a variable whose value is not knowable from
syntax, and treating it as unwired would flag every correct forwarding
wrapper in the tree — exactly the false-positive wave that trains
readers to skip a gate. Same for a call expression, a conditional, or
anything else with a value at runtime.

That keeps the rule provable from syntax alone. It doesn't relocate the
dishonesty so much as remove the one spelling that is *demonstrably*
empty; anything ambiguous still counts as wired, so the gate stays
conservative in the direction that matters.

## No tests existed for this census

`check-lane-wiring` and `lane-wiring-census.mjs` had no unit coverage on
`main`, so both rules ship with tests rather than resting on the probe
that found them.

## Measured

| check | result |
|---|---|
| clean `main` | exit 0, unchanged — all five gates green |
| now caught | property spelled `undefined` · property spelled `void 0`
|
| correctly **not** flagged | a real value · shorthand forwarding · a
call-expression value · a middle `undefined` with a real argument after
it |
| new suite | **8 tests**; reverting both rules fails **exactly** the 3
positives, negatives hold |

## Not done here, deliberately

The second finding on #2981 — `computeBlockerFanoutMap`'s dashboard
wrapper dropping all four lane options, so the fanout display reads
legacy literals on a renamed board — is **not** in this PR. Confirming
the diagnosis: `useBlockerFanout.ts`'s `UseBlockerFanoutOptions`
declares only `staleHighFanoutAgeThresholdMs` and forwards only that,
and all three dashboard call sites (`Board`, `TaskDetailModal`,
`ExecutorStatusBar`) have the same gap.

One correction to how it's framed, though: core already has the right
seam for it. `classify` and `escalationClassify` are documented there as
*"the only correct option on a multi-workflow board"*, precisely because
the set-shaped options assume a column id means the same thing
everywhere. So the fix should thread **per-task classifiers**, not
resolved column-flag sets — otherwise it reproduces the union read that
this program's own learnings doc lists as the fourth failure shape.

What's genuinely undecided is where a per-task role answer comes from in
a sync render path: `Board` holds `columnDef.flags` for the *selected*
workflow only, and the dashboard has no per-task resolver hook. That's
the design call, and it's dashboard-batch work rather than a mechanical
edit — so I've left it for whoever owns that batch rather than guessing
at it inside a gate PR.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 23:30:07 -07:00
gsxdsm
2411699756 fix(gate): passing undefined for the lane answer read as supplying it (#2981) 
## What

Continuing the #2979 discipline — probe a ratchet with shapes its author
did *not* have in mind — applied to my own inert-seam gate. Four probes,
three got through. Two turned out to be the sibling gate's job. This is
the one that's nobody's:

```ts
resolveSomething("KB-1", undefined)
```

The seam is a trailing optional parameter, so the gate asked how many
**arguments** a call site passes. Spelling the omission out satisfies
that count while the callee receives exactly what it received before:
nothing. The parameter is still inert, the board still reads the legacy
vocabulary — the gate just stops saying so.

Not an exotic spelling. It's what a partial wiring-up produces when
flags are threaded through an intermediate that has none to pass, and
what a mechanical positional edit produces when it fills argument slots.

## Missed by both gates — checked before touching anything

`check-lane-wiring` (#2966) covers the default-valued and options-object
shapes this gate is structurally blind to. I probed it first, and it
caught **both**, so the two remain genuinely complementary rather than
overlapping. But it counts arguments the same way here, so this shape
was uncovered by either.

| probe | inert-seam (before) | lane-wiring |
|---|---|---|
| omitted entirely | caught | — |
| default-valued param | missed | **caught** |
| options-object flags | missed | **caught** |
| explicit `undefined` | missed | **missed** ← this PR |

## The trim is trailing-only

A **middle** `undefined` still positions the arguments after it, so
those are real answers. That's the case that keeps the trim honest, and
it's pinned as a test.

## Measured

| check | result |
|---|---|
| clean `main` | exit 0, unchanged |
| now caught | explicit `undefined` · `void 0` · several trailing
undefineds |
| correctly **not** flagged | a real trailing value · a middle
`undefined` with a real value after it |
| gate's own suite | **12 → 18 tests**, all green |
| reverting to the raw argument count | fails **exactly** the 3
positives; the negatives hold |

## One note on the fourth gate

`check-fnxc-future-dates` went red on this branch — on my own comments.
I'd stamped them `2026-07-31`, which is tomorrow. Fixed by correcting
the stamps to today, not by re-recording the baseline; the baseline
already tolerates some pre-existing future stamps and adding mine to it
would have been appeasement. Worth noting that the gate earned its keep
against the person who has been writing the other gates.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 23:08:08 -07:00
gsxdsm
634d487c3e fix(gate): a lane id hoisted into a const evaded the SQL column-literal gate (#2980) 
## What

In #2979 I argued a ratchet should be mutation-probed with shapes its
author did **not** have in mind, on the day it ships. Applying that to
my own gate: two of three probes walked straight through.

```ts
const LANE = "done";
sql`... WHERE "column" = ${LANE}`                       // MISSED

const LANES = ["in-progress", "in-review"];
sql`... WHERE "column" IN (${sql.join(LANES)})`         // MISSED
```

Both bind the query to the legacy vocabulary exactly as an inline
`'done'` does. An interpolation that wasn't a column reference collapsed
to the NUL sentinel, so the predicate dissolved before the matcher ever
ran.

**This is the shape a cleanup produces.** Hoisting a repeated string to
a named const reads as tidying, which makes it the likeliest way one of
these gets rewritten — and the gate would have gone quiet on a file that
changed only in punctuation. Third time this scanner has had that
failure (static-span join, element-access column ref, now this). The
array form isn't hypothetical: `IN ('in-progress','in-review')` was the
live workflow-analytics defect.

## The first version of this fix was wrong, and that's the useful part

Resolving *any* string-valued const double-counted the analytics files,
which build queries as:

```ts
const completedClauses = [`t."column" = 'done'`, "t.columnMovedAt IS NOT NULL"];
```

Those elements are SQL fragments **already counted where they're
written**. Resolving the const re-injected each into the outer template.
The three analytics files went `3/3/1` → `6/5/2` — and it read exactly
like a genuine find. Only **bare lane ids** are resolved now; the
fragment-array case is pinned as a test.

I also nearly shipped that version on a bad probe: `node gate | tail`
then `echo $?` reads *tail's* exit status, not the gate's. Every probe
reported "caught" while the gate was actually failing on main for an
unrelated reason. Worth repeating because the harness looked fine and
agreed with what I expected.

## Measured

| check | result |
|---|---|
| clean `main` | **22 sites, exit 0, unchanged** — no false positives
introduced |
| now caught | const string · const array via `sql.join` · as-const via
`inArray` |
| correctly **not** flagged | resolver-produced lanes · non-legacy ids ·
SQL-fragment array |
| gate's own suite | **26 → 32 tests**, all green |
| blinding the resolution | fails **exactly** the 3 new positive tests;
the 3 negatives still pass |

The negatives outnumber what feels necessary on purpose: eager
resolution is how this went wrong the first time, and the fragment-array
test is the one that would have caught it.

## Scope

Same-file `const` declarations only. Cross-file imports need a type
checker and a program-wide pass — a constant imported from another
module is **still invisible**, and `--list` output is where that gets
audited. Stating the boundary rather than half-resolving it and calling
the gate complete.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 22:59:56 -07:00
gsxdsm
ee8ae1eb23 fix(census): the header claimed 0 trait-fallback branches while sites of that shape existed (#2874) 
The census header has been printing `of the column guards, 0 are
trait-fallback branches (already converted)` while sites of exactly that
shape exist. I flagged this on #2842 as a suspected classifier gap; this
confirms and fixes it.

## The miss

Only `cond ? trait : literal` was recognised. The other spelling — a
**negative** test with the literal on the **true** branch — is what a
caller writes once it hoists its resolved lanes:

```ts
complete: completeLanes === undefined ? columnId === "done" : completeLanes.includes(columnId)
```

That is `github-tracking-state.ts:245-246` — a fully converted resolver
whose two degraded arms were reported as unconverted debt. **The backlog
read higher than the remaining work**, and a reader chasing it was sent
to lines that are already correct.

Second half of the miss: `completeLanes` matches no hint. Adding `Lanes`
to the hint list does **not** work, and the reason is itself a prior fix
— hints are word-bounded because the unbounded form once let `hold`
match `threshold` and `household`. `\bLanes\b` cannot match inside
`completeLanes`, where the boundary does not exist. So resolved-lane
identifiers get an explicit suffix rule.

## Both guards on the new rule exist because I broke them while writing
it

Worth stating, because each failure ran in the **dangerous direction** —
marking a *live* line "already converted", which removes a real guard
from a backlog people trust:

| mistake | what it excused |
|---|---|
| widened the shared `testsTraitData` | fed the ancestor-walking rules
too, which marked `step.status === "done" \|\| step.status ===
"in-progress"` at `register-task-workflow-routes.ts:941` — a
step-**status** comparison, not a column guard — as converted |
| let the new rule walk ancestors | excused any literal inside a block
governed by a negative lane test |

Measured: the count went to **6 with two of them wrong** before I caught
it. The rule is now immediate-parent-only with its widened identifier
match local to it, and reports exactly the **2 real sites**.

## Verification

- Census: **176 guards, 2 trait-fallback** (was 176 / 0). The total is
unchanged — this sub-count is diagnostic and does not move the ratchet,
so `--strict` exits 0 with no baseline re-record.
- 5 cases in
`scripts/__tests__/lifecycle-census-inverted-fallback.test.mjs`,
including both negatives that pin the mistakes above plus one for the
suffix rule not over-reaching (`airplanes` is not a lane test).
- `pnpm lint` clean; gate green (161/487/13/71).

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

## Summary by CodeRabbit

* **Bug Fixes**
* Improved lifecycle analysis accuracy for trait fallback logic,
including inverted conditions, legacy fallback syntax, and null or
undefined checks.
* Added safeguards to avoid misclassifying complex conditions, unrelated
identifiers, and nested expressions.
  * Improved handling of lifecycle lane and column naming patterns.

* **Tests**
* Expanded coverage for valid and invalid fallback scenarios, identifier
boundaries, parent-expression restrictions, and property-path checks.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 16:43:31 -07:00
gsxdsm
ef50244234 feat(gate): freeze the SQL column-literal surface — 30 sites, none may be added (#2841) 
Instruments a surface no existing check can see. Follows #2839, and
**corrects the count I reported there** (12 → 14).

## Why it was invisible

The lifecycle census parses TypeScript **comparisons**; a legacy id
inside a SQL string is string data. The inert-seam gate reasons about
parameters and call sites. Neither has ever looked here.

**What it cost:** `cleanupStaleMergeQueueRowsImpl` filtered on `t.column
!= 'in-review'`, so on a renamed board every queued card looked stale,
its `merge_queue` row was deleted, and the card became **unleaseable**.
The operator found it reviewing #2819 — in SQL I had already read past
during that same work.

The quieter half is analytics: five sites count `"column" = 'done'`, so
throughput, cycle time, and team dashboards report **zero completed
work** on a renamed board. Nothing errors, which is why nobody files it.

## What this does, and does not do

It does **not** fix the sites. `resolveProjectColumnsForRoles` is the
mechanism and its migration has an owner (#2839). This freezes the
population so the surface cannot grow underneath that migration: a new
file or a higher count fails, **and a lower count fails too** — so the
baseline ratchets down as sites migrate rather than leaving slots to
silently regrow into. That is the same rot as an allow-list entry for a
deleted function, which this repo already hit once.

AST-based, deliberately: a line grep for the same pattern reports **37**
hits, **25 of them prose** quoting `column === "done"` in explanatory
notes. A guard that is 68% false positives trains its readers to skip it
— a lesson this program has already paid for.

## Two corrections found by mutation-testing my own gate

**1. Clause fragments were missed.** Requiring a SQL keyword *in the
same literal* skipped `team-analytics.ts`, which builds
`["assignedAgentId IS NOT NULL", `"column" = 'done'`, ...]` and joins
them into a `WHERE` later. That fragment is as vocabulary-bound as any
full query but contains no keyword. Fixing it took the population **12 →
14**, so the number I put on #2839 was low.

**2. My first mutation test proved a direction it had not.** I replaced
the first textual occurrence in a file — which was inside a **comment**
— and read the unchanged count as the scanner being broken. The scanner
was right; my test was wrong. All three directions are now driven
against real SQL:

| mutation | result |
|---|---|
| add a full query with a legacy comparison | `3 SQL column literal(s),
baseline allows 2` |
| add a bare clause **fragment** (no keyword) | caught — same failure |
| migrate one away (count drops) | `1 site(s) now, baseline still allows
2 — re-record it` |
| restore | exit 0 |

I am flagging that second one because it is the exact failure mode this
program keeps finding: a green result read as evidence when the
experiment was invalid.

## Verification

`pnpm test:gate` green with the new check in it · lint 0 · single AST
pass. Wired into `test:gate` and both `pretest` hooks.

🤖 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**
* Added automated checks to detect increases in legacy SQL column
literals.
* Added baseline tracking to ensure known SQL literal counts do not
regress.

* **Tests**
* Expanded pre-test and gated verification steps with SQL literal and
mock completeness checks.
  * Updated test validation workflows to enforce the new safeguards.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 16:06:24 -07:00
gsxdsm
5a3541315c fix(gate): pnpm test is red on main — stale exemptions, plus two false positives they were masking (#2851) 
**`pnpm test` and `pnpm test:full` fail on `main` right now** (commit
`51934931e1`). Found by running the gates against `main` after my
earlier PRs landed, not by CI telling me.

> **Correction to this PR's first version.** I originally wrote that
`pnpm test:gate` was failing. It is not: `check-inert-flag-seams` runs
in the `pretest` and `pretest:full` hooks, not in `test:gate`. So the
blocking merge gate (Lint / Typecheck / Build / Gate) is unaffected and
PRs are not blocked — what is broken is every local `pnpm test` run,
which fails before a single test executes. Lower urgency than I claimed,
still worth fixing promptly, and I would rather correct the scope than
leave an overstated one standing.

Three causes, each surfaced by fixing the one before it.

## 1. Stale exemptions — the mechanism working

#2819 and #2823 merged, so the two `ALLOWED_OMISSIONS` entries covering
those call sites became stale and the staleness check failed them.
Removed. This is my cleanup: the entries were designed so they could not
outlive their fixes, and they didn t.

## 2. Renamed imports were not resolved

Removing the first entry surfaced:

```
enqueueMergeQueue() — best call passes 2 of 5
```

Its only production caller passes all five — through `import {
enqueueMergeQueue as enqueueMergeQueueAsync }`. Call sites were recorded
under the **local** name, so an aliased supplier was invisible and the
seam read as unsupplied. The local name is now mapped back to the
exported one.

## 3. Method calls were conflated with module functions

That fix then surfaced two engine sites as omitting — but
`store.enqueueMergeQueue(taskId, opts)` is a **2-arg `TaskStore`
method** that resolves the review columns internally (#2819), not the
5-arg module function sharing its name. Property-access calls are no
longer attributed to module-level seams.

**Tradeoff, stated at the site:** a genuine `namespace.fn(...)` call is
now skipped. This codebase calls module functions as bare identifiers,
and aliases are resolved by fix 2, so that shape does not currently
occur. Recorded rather than left for someone to discover.

## Both directions re-verified

A fix that quietly disarms the gate would be worse than the red, so I
re-ran the defects it exists to catch:

| mutation | result |
|---|---|
| drop `Column.tsx`'s flags argument (partial supply) | `supplied by
10/11 call sites; omitted at .../Column.tsx:1 (of 2)` |
| drop the aliased 5-arg supplier (wholly unsupplied) | `best call
passes 3 of 5` |
| restored | exit 0 |

My first attempt at the second row grepped for the wrong message shape
and printed nothing. **I re-ran it rather than reading silence as
success** — which is the failure this gate exists to prevent, and one I
have made in this same file before.

## Verification

`pnpm test:gate` green (it was never affected) · `node
scripts/check-inert-flag-seams.mjs` exit 0 · lint 0 · gate reports `21
lane/flag seams, all supplied at every production call site`.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 15:10:45 -07:00
gsxdsm
8b039a543e fix(desktop): advance Pi runtime pin to 0.82.1 for packaging PR lane (#2465) 
## Summary
- Advance the matched Pi runtime pin (`pi-ai`, `pi-coding-agent`,
`pi-agent-core`, `pi-tui`) from **0.82.0 → 0.82.1** so
electron-builder's production-dependency walk accepts `pi-agent-core`'s
`pi-ai@^0.82.1` requirement.
- Fixes the Desktop packaging PR-lane failure:
`Production dependency @earendil-works/pi-ai not found for package
@earendil-works/pi-agent-core` (required `^0.82.1`).
- Keep the workspace override guard; update pin-policy fixtures and CLI
package-config expectations.
- Tighten the advisory packaging step-order test so it asserts against
the real `electron-builder --dir` step (not a missing release-only step
name that previously passed via `indexOf === -1`).
- Run `pnpm dedupe` so the packaging lane's lockfile dedupe
early-warning is clean.

## Context
#2439 pinned the full Pi closure at 0.82.0 and made recent main-based
packaging runs green. This advances to the current upstream patch so
deploy + electron-builder stay aligned with `pi-agent-core@0.82.1`'s
declared dependency range.

## Test plan
- [x] `node scripts/check-pi-versions-pinned.mjs`
- [x] `node --test scripts/__tests__/check-pi-versions-pinned.test.mjs`
- [x] `pnpm --filter @runfusion/fusion exec vitest run
src/__tests__/package-config.test.ts`
- [x] `pnpm --filter @fusion/desktop exec vitest run
src/__tests__/release-workflow.test.ts`
- [x] `pnpm dedupe --check`
- [ ] GitHub: Desktop packaging (should run full packaging walk —
lockfile/package.json touched)
- [ ] GitHub: PR Checks (Lint, Typecheck, Build, Gate)
 2026-07-26 23:47:49 -07:00
gsxdsm
f1a2d9ae1f FN-8626: validate committed test timing snapshot 
Add an automated guard that keeps CI test-sharding timings usable.

- Validate snapshot structure, freshness, and recorded test-file paths.
- Confirm planning loads the snapshot and shard dry-runs use it without stale warnings.

Files changed:
 scripts/__tests__/ci-test-shard-timings.test.mjs | 50 +++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

Fusion-Task-Id: FN-8626

Fusion-Task-Lineage: ada6525f-8dcc-4494-8586-3aa2e41618f3

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-07-26 20:42:30 -07:00
Phil Larson
0643a64f0d fix(desktop): pin complete Pi runtime closure (#2439) 
## Summary
- pin `pi-agent-core`, `pi-ai`, `pi-coding-agent`, and `pi-tui` to one
exact 0.82.0 workspace override set
- extend the Pi version policy guard to reject missing, ranged, or
mismatched desktop runtime closure overrides
- add a patch changeset for the legacy desktop packaging fix

## Test plan
- `node --test scripts/__tests__/check-pi-versions-pinned.test.mjs` (5
passed)
- `node scripts/check-pi-versions-pinned.mjs`
- `corepack pnpm check:changesets --strict`
- focused engine fixtures: 4 files / 47 tests passed
- GitHub: Desktop packaging, Lint, Typecheck, Build, Gate, and Greptile
Review passed
 2026-07-26 07:34:50 -07:00
gsxdsm
084dd76d64 feat(release): write release copy with opus and draft tweets for betas too 
- distillation runs on opus (env-overridable) with a 4-minute budget
- highlights must name the surface and outcome; vague filler is banned
- tweets target 200-280 chars with concrete changes and varied structure
- betas get their own tester-facing draft carrying `fn update --channel beta`
- prerelease openers read as "Fusion 0.74 beta:" instead of "Fusion 0.74-beta.0"
 2026-07-24 23:15:36 -07:00
gsxdsm
330e4970f0 refactor(release): move the version-anchor package.json rewrite into the shared lib 
Makes the re-anchor file mutation unit-testable alongside the anchor decision.
 2026-07-24 23:01:11 -07:00
gsxdsm
dba9746287 fix(release): base the next beta on the shipped stable version 
After a stable release, main stayed inside the old pre-mode cycle, so the next
beta numbered below the published stable (v0.73.0-beta.7 after v0.73.0) and the
dev checkout kept reporting the last beta.

- beta releases re-anchor a stale pre-mode cycle on the newest stable tag
- both channels refuse a version at or below the newest published stable
- stable promotion now back-merges release into main automatically (fail-soft
  on conflict) so the local dev version is the stable version
 2026-07-24 22:59:19 -07:00
gsxdsm
e3dba364d1 FN-8564: update bundled Pi runtime to 0.82.0 
Update Fusion's matched Pi dependencies and compatibility coverage for version 0.82.0.

- Pin Pi AI and coding-agent packages to the exact 0.82.0 release pair.
- Refresh provider catalog, supplemental model, auth storage, and Droid thinking coverage.
- Add the published CLI patch changeset.

Files changed:
 .changeset/fn-8564-pi-082.md                       |   7 +
 packages/cli/package.json                          |   4 +-
 packages/cli/src/__tests__/package-config.test.ts  |   2 +-
 packages/core/package.json                         |   2 +-
 packages/dashboard/package.json                    |   2 +-
 ...ister-model-routes-kimi-k3-supplemental.test.ts |   6 +-
 packages/engine/package.json                       |   4 +-
 .../src/__tests__/provider-registration.test.ts    |   4 +-
 packages/engine/src/auth-storage.ts                |  11 +-
 packages/engine/src/pi.ts                          |   6 +
 packages/pi-claude-cli/package.json                |   8 +-
 .../src/thinking-config.ts                         |  10 +-
 pnpm-lock.yaml                                     | 176 +++++++++++----------
 pnpm-workspace.yaml                                |   6 +-
 .../__tests__/check-pi-versions-pinned.test.mjs    |   8 +-
 15 files changed, 142 insertions(+), 114 deletions(-)

Fusion-Task-Id: FN-8564

Fusion-Task-Lineage: 543c5e17-4cb2-446f-9a1c-ec7ec8b8117a

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-07-24 19:06:14 -07:00
gsxdsm
6166b496e4 FN-8559: refresh test timing snapshots 
Refresh timing data and keep velocity reports aligned with the current snapshot.

- Attribute CI timing reports from absolute checkout paths
- Render report-only slowest tests from the latest timing snapshot
- Update timing snapshot data and regression coverage

Files changed:
 scripts/__tests__/ci-test-shard-timings.test.mjs  |    9 +
 scripts/__tests__/test-velocity-baseline.test.mjs |   38 +
 scripts/ci-test-shard.mjs                         |   13 +
 scripts/test-timings.json                         | 2522 +++++++++++++--------
 scripts/test-velocity-baseline.mjs                |   33 +-
 5 files changed, 1616 insertions(+), 999 deletions(-)

Fusion-Task-Id: FN-8559

Fusion-Task-Lineage: 09ed6b78-f82f-4732-a5e3-1066efe385b3

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-07-24 06:21:53 -07:00
gsxdsm
c5a8421533 FN-8560: forward desktop test telemetry flags 
Desktop test execution now preserves CI reporter and JSON output flags.

- Forward caller-selected Vitest reporters and output files through the desktop test wrapper.
- Add coverage for reporter syntax and shard timing command forwarding.
- Document desktop timing artifact requirements.

Files changed:
 docs/testing.md                                    |  7 ++++-
 packages/desktop/scripts/__tests__/test-args.test.ts | 36 ++++++++++++++++++++++
 packages/desktop/scripts/test-args.ts              | 13 ++++++++
 packages/desktop/scripts/test.ts                   |  3 +-
 scripts/__tests__/ci-test-shard.test.mjs           |  9 ++++++
 5 files changed, 66 insertions(+), 2 deletions(-)

Fusion-Task-Id: FN-8560

Fusion-Task-Lineage: 2a89b28d-39f6-4949-aec2-1123c36126cf

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-07-24 05:30:45 -07:00
gsxdsm
c5e9a7956a fix(ci): stop watchdog false-kills of the grown core slice; actually upload timing artifacts 
- Shard watchdog floor 25min (was 15): the July PG-cutover test growth pushed
  @fusion/core past 900s on contended CI runners; run 30075604930 killed a
  healthy core run at exactly the floor because the 27-day-old (still "fresh")
  undercounting timings snapshot tightened the budget to it — the same
  false-kill class as the 5->15min raise. Floor pin + in-band example updated.
- full-suite.yml timing upload: include-hidden-files — the .timings/ dot-dirs
  were silently excluded by upload-artifact@v4, so the step has uploaded
  nothing since it was added and the snapshot could never be refreshed from CI.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-24 00:55:38 -07:00
gsxdsm
ff165ecb5a fix: scope beta release notes to that beta's changesets; stable keeps full-cycle rollup 
Pre-mode preserves consumed changeset .md files, so every beta's distilled notes and GitHub prerelease body aggregated the entire cycle since the last stable (v0.73.0-beta.4 shipped the full 0.72.0→0.73.0 aggregate). Betas now distill only changesets not yet recorded in pre.json's consumed ledger, and fail loudly when a beta would ship nothing new. Stable promotion still feeds the full preserved set, keeping its notes an explicit rollup of every beta in the cycle.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-23 12:18:24 -07:00
gsxdsm
28e8c0abc9 FN-8524: cover workspace manifests in Docker builds 
Ensure the builder install layer includes every selected workspace manifest.

- Copy the five omitted plugin manifests before frozen installation.
- Validate pre-install Dockerfile coverage against pnpm workspace entries.
- Document the manifest coverage requirement and focused test command.

Files changed:
 Dockerfile                                         |   8 +-
 docs/docker.md                                     |   3 +-
 .../dockerfile-workspace-manifests.test.mjs        | 111 +++++++++++++--------
 3 files changed, 78 insertions(+), 44 deletions(-)

Fusion-Task-Id: FN-8524

Fusion-Task-Lineage: 16a4d9df-ff08-4051-9e53-0da414ef6a85

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-07-22 22:04:32 -07:00
gsxdsm
f120e6c879 FN-8506: run static checks in verify:fast 
Run canonical pretest validators before test-free verification work.

- Derive read-only static check steps from the root pretest script.
- Test fail-fast static-check planning and execution.
- Document the expanded verify:fast gate and correct changeset metadata.

Files changed:
 .changeset/mobile-board-pointercancel-settle.md |   2 +-
 docs/testing.md                                 |   5 +-
 scripts/__tests__/verify-fast.test.mjs          | 105 ++++++++++++++++++++++--
 scripts/verify-fast.mjs                         |  86 ++++++++++++++++---
 4 files changed, 174 insertions(+), 24 deletions(-)

Fusion-Task-Id: FN-8506

Fusion-Task-Lineage: 87f74fda-1fd0-4e08-9bfe-51e0c4c9a31d

Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-07-22 18:26:33 -07:00
gsxdsm
9002fca9de FN-8497: reduce merge gate wall time 
Keep merge-gate coverage focused while running its independent test lanes concurrently.

- Limit PostgreSQL gate coverage to lifecycle and transactional-handoff canaries.
- Run engine and PostgreSQL gate lanes concurrently while preserving failure propagation.
- Enforce canary coverage policy and refresh velocity documentation and history.

Files changed:
 docs/test-velocity-baseline.md                     |  16 +--
 docs/testing.md                                    |   5 +-
 package.json                                       |   2 +-
 packages/core/package.json                         |   2 +-
 .../__tests__/engine-vitest-gate-policy.test.mjs   |  79 +++++++++++++-
 scripts/test-velocity-history.json                 | 115 +++++++++++++++++++++
 6 files changed, 204 insertions(+), 15 deletions(-)

Fusion-Task-Id: FN-8497
Fusion-Task-Lineage: 8777959c-6d8c-4686-a975-d91af2c169ea
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
 2026-07-22 15:47:24 -07:00