The repo keeps binary assets as Git LFS objects, but the runner stage
installed plain git. Without git-lfs, checkout writes ~130-byte pointer files
in place of the real content and reports a clean tree, so an agent reads a
text stub where an image should be and any `git lfs` subcommand fails. That
is silent corruption of a working checkout, not a visibly missing tool, which
is why it goes in beside git rather than with the optional tooling.
Confirmed in the running container: screenshots/fn-061-medieval-desktop.png
was a `version https://git-lfs.github.com/spec/v1` stub — 129 tracked files
in that state — and became a valid 753KB PNG (signature and IEND intact)
after installing git-lfs and running `git lfs pull`.
The Dockerfile manifest guard now asserts the package so it cannot be dropped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reorganize the suite-only flake register around its current decision state.
- Separate active observations, gate evictions, and archived closed records while preserving entry anchors.
- Mark entry 1 as an escalated second sighting and restore FN-9126/FN-9131, FN-9128, and FN-9127 ownership.
- Add regression checks for active counts, exact states and owners, and testing-guide anchors.
Files changed:
.../suite-only-flakes-observed-register.md | 189 +++++++++++++--------
scripts/__tests__/observed-flake-register.test.mjs | 65 +++++++
2 files changed, 181 insertions(+), 73 deletions(-)
Fusion-Task-Id: FN-9145
Fusion-Task-Lineage: 39b3292a-db48-4be4-878c-7d2b026abae3
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
## Problem
PR #3472 resolved a `.changeset/pre.json` rebase conflict against a copy
predating the v0.76.0 stable:
| | at `v0.77.0-beta.1` | after #3472 |
|---|---|---|
| `initialVersions["@runfusion/fusion"]` | `0.76.0` | `0.75.1` |
| consumed ledger | 67 entries | 158 (the pre-0.76.0 cycle's) |
Nothing failed at PR time. Days later `pnpm release` saw the cycle
anchored below the shipped `v0.76.0`, fired its stale-cycle re-anchor
(`pre exit` → rewrite all 36 `package.json` → `pre enter`), and proposed
**`0.77.0-beta.0`** — below the already-published `0.77.0-beta.1`. The
re-anchor guard exists to stop a beta numbering under a stable; fed a
stale anchor it caused exactly that.
`pre.json` is generated by changesets, hand-edited by nobody, and
conflicts in nearly every long-lived branch — so a wrong resolution is
invisible until release day. This moves the failure to the PR that
causes it.
## The check
`scripts/check-pre-json-anchor.mjs`, three invariants:
- **`anchor-below-stable`** — `initialVersions` must not sit below the
newest `v*` stable tag. This is the exact predicate
`evaluateBetaCycleAnchor` keys on in `release.mjs`, so green here means
the release will *not* re-anchor.
- **`ledger-regression`** — the consumed ledger must stay a **superset**
of the last `chore(release):` commit's. Deliberately not a count test:
#3472's ledger *grew* 67 → 158 while dropping all 67 real entries, so a
size comparison would have passed it.
- **`dangling-ledger-entry`** — every consumed entry keeps its
`.changeset/*.md`, which pre-mode needs to aggregate notes into the
eventual stable release.
Skips cleanly outside pre-mode (the stable track deletes `pre.json`).
## Wiring
Added to the **Lint** job and `pretest`. Job names are unchanged, so no
branch-protection update is needed. The Lint checkout takes
`fetch-depth: 200` + `fetch-tags` rather than a full 486MB clone —
releases land every few days, so that always reaches a baseline; out of
range the ledger rule reports `SKIPPED` rather than passing vacuously,
and the two local rules still run.
## Verification
- Reproducing #3472's exact `pre.json` in the tree → **exit 1** on all
three rules, with the 67 dropped entries named.
- Clean `main` → exit 0.
- 11 unit tests (`scripts/__tests__/check-pre-json-anchor.test.mjs`),
including an explicit assertion that the ledger *grew* in the regression
case.
- `eslint` clean; workflow YAML parses; job names still `Lint,
Typecheck, Build, Gate`.
No changeset: CI config only, no `@runfusion/fusion` behavior change.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added automated validation for beta release-cycle metadata.
* Checks anchor versions, consumed changeset records, and corresponding
changeset files.
* Provides clear success or error messages and skips checks when release
history is unavailable or not applicable.
* **Chores**
* Pull request checks now run the beta-cycle validation automatically.
* Added comprehensive coverage for valid, invalid, and skipped
validation scenarios.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
## Summary
- removes the deleted taskStuck helper from dashboard package exports
and local build/test aliases
- removes the dependency-graph plugin TypeScript path for the deleted
dashboard module
- adds a script regression so the removed module cannot be reintroduced
as a stale alias
## Test Plan
- pnpm test:scripts --
scripts/__tests__/dashboard-stuck-task-removal.test.mjs
- pnpm check:changesets
- pnpm exec eslint
scripts/__tests__/dashboard-stuck-task-removal.test.mjs
packages/dashboard/vite.config.ts packages/dashboard/vitest.config.ts
- pnpm --filter @fusion/dashboard typecheck
- pnpm --filter @fusion-plugin-examples/dependency-graph build
- pnpm --filter @fusion/dashboard build
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Removed stale stuck-task references from dashboard package and build
configurations.
* Prevented unavailable task-stuck utilities from being exposed or
resolved.
* **Tests**
* Added validation to ensure removed task-stuck references do not
reappear in dashboard or plugin configuration.
* **Documentation**
* Recorded the cleanup in the project’s release notes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Operator asked for cloudflared, tailscale, rg, git and gh available by default
in the container. git/ca-certificates/ripgrep already landed; this adds the
remaining three.
Each comes from its vendor's own signed apt repository rather than a
curl-to-shell installer, so signature checking and upgrades follow the normal
apt path:
gh https://cli.github.com/packages
tailscale https://pkgs.tailscale.com/stable/debian
cloudflared https://pkg.cloudflare.com/cloudflared
Why each belongs in the image: gh backs Fusion's gh-cli GitHub auth mode (the
auth route instructs operators to run `gh auth login`, impossible without the
binary), cloudflared backs the dashboard's remote-access feature whose in-app
installer cannot bootstrap itself reliably in a slim container, and tailscale is
the private-network option for the same box.
Installing tailscale does NOT make tailscaled runnable by itself: the daemon
also needs --cap-add NET_ADMIN --device /dev/net/tun at docker run. Shipping the
binary is the image's part; granting kernel capabilities stays an explicit
operator decision.
Commands were validated live in a running container before being written here;
the guard test asserts both the repo wiring and the package names so half a
change cannot silently ship.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The coding agents Fusion drives reach for `rg` as their primary search tool. It
was absent from the image, so inside a container they silently fall back to
slower or partial search while working fine on a developer machine that has it
installed. Operator asked for it by default.
Installed alongside git and ca-certificates in the runner stage, and covered by
the same runner-stage guard so it cannot quietly drop out again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator hit "Git clone failed: ... server certificate verification failed.
CAfile: none CRLfile: none" the moment they tried to add a project in the
container.
The runner stage installed git but not ca-certificates, and the slim base ships
zero CA certificates (/etc/ssl/certs was empty). git verifies TLS against the
SYSTEM trust store, so every HTTPS remote failed and project setup — the first
thing anyone does after logging in — was impossible in Docker.
It hid because Node carries its OWN bundled CA store: the dashboard, model API
calls, and the OAuth token exchanges against platform.claude.com and OpenAI all
worked fine, so the image looked healthy right up until the first clone. Nothing
else in the image exercises the system trust store, so a guard is added rather
than trusting someone to notice next time.
Verified in the running container: installing ca-certificates took it from 0 to
301 certs and `git clone https://github.com/Runfusion/Fusion.git` then succeeded
as the node user.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Full-suite repair, engine source-scan cluster. The package code
organization waves moved ~30 engine modules into subdirectories
(plugins/, execution/, scheduling/, healing/, worktree/, executor/
peels); the log-severity manifest, prompt carve-out, emit-surface,
failure-lane, and worktree-invariant scanners now read the moved
locations, verified per file via git log --follow. Two scans caught
real drift rather than moves: the lifecycle census had 12 unexamined
column guards (resolved with DELIBERATE-LITERAL markers for the mailbox
archived tab, the FN-9059 lease-owner terminality check, and the FN-9056
legacy done fallback — baseline re-recorded with zero absorbed debt),
and planning-claim gained a genuine second writer in self-healing's
FN-8998 transport-failure recovery, admitted to the allowlist with its
CAS-guarded justification. 9 files / 119 tests green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
## Summary
- Classify workflow work-item `workflowRole` comparisons as role
vocabulary in the lifecycle-column census.
- Add a regression test so triage role comparisons cannot raise a
phantom lifecycle-column guard.
## Test Plan
- `node --test scripts/__tests__/lifecycle-census*.test.mjs`
- `corepack pnpm check:lifecycle-columns`
- `corepack pnpm lint`
- `corepack pnpm check:changesets --strict`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved classification of workflow role comparisons, including
`workflowRole === "triage"`, so they are recognized separately from
lifecycle-column comparisons.
* Ensured workflow role values are correctly identified as role
vocabulary rather than lifecycle-column values.
* **Tests**
* Added automated coverage to verify accurate workflow role and column
identification across comparison patterns.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
verify:fast ran every step serially, so its wall clock was the sum of steps with no
ordering relationship between them. Static checks and per-package typechecks are
each independent, so they now run as bounded-concurrency groups.
static checks ~6.0s -> ~1.6s (11 validators, mostly node startup)
typecheck 11.0s -> 7.4s (engine + dashboard)
no-change run 28.1s -> 22.3s
Ordering that matters is untouched: bootstrap, builds, and boot smoke stay serial
and in plan order, and each group is a barrier. A failing group awaits its in-flight
siblings before throwing rather than abandoning partial tsbuildinfo/dist state, and
reports the first failure in plan order so the message does not depend on which
sibling lost the race. FUSION_VERIFY_FAST_SERIAL=1 restores the old behavior when
interleaved child output makes a failure hard to read.
Boot smoke is now 84% of a no-change run (18.8s); it re-runs initdb into a throwaway
HOME every time. Left alone -- caching that would change what the gate proves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
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>
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>
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.
## 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 -->
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>
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>
## 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.
## 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.
**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>
## 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.
