aedee4b8231bf050c3240a00ab6645ede5d87ee9
214 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
gsxdsm
|
aedee4b823 |
feat(docker): ship ripgrep in the image
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> |
||
|
gsxdsm
|
3105b06102 |
fix(docker): install ca-certificates so git can clone over HTTPS
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> |
||
|
gsxdsm
|
2b99b365de |
FN-9141: rescue plugin-runner tests and enforce quarantine lockstep
Rescue the plugin-runner suite before deletion while making quarantine records mechanically consistent. - preserve logger assertions across worker-reused mock cleanup with a stable hoisted logger - remove the rescued suite from the quarantine ledger and Vitest exclusion - enforce ledger-to-exclude lockstep and cover missing or dangling quarantine entries - document the reproduction evidence, rescue disposition, and strict checker behavior Files changed: .../suite-only-flakes-observed-register.md | 14 +- docs/testing.md | 17 +- .../engine/src/__tests__/plugin-runner.test.ts | 37 ++-- packages/engine/vitest.config.ts | 14 +- scripts/__tests__/check-quarantine-ledger.test.mjs | 217 +++++++++--------- scripts/__tests__/ci-test-shard-timings.test.mjs | 5 +- scripts/check-quarantine-ledger.mjs | 245 +++++++++++++-------- scripts/lib/test-quarantine.json | 10 +- 8 files changed, 314 insertions(+), 245 deletions(-) Fusion-Task-Id: FN-9141 Fusion-Task-Lineage: 5b0549bf-3cc6-495e-bf99-a30a2dffb029 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
6d7b4a3ac3 |
FN-9140: make Vitest timeout ownership surveys deterministic
Replace ambiguous setup-boundary observations with calibrated, repeatable timeout ownership evidence. - record fixture lifecycle events in an append-only JSONL ledger with process-safe ordering - classify four timeout-budget arms across repeated isolate-mode cells and fail closed on incomplete evidence - expand connectionless unit coverage and document the terminal insufficient-data survey result Files changed: .../test-failures/postgres-ddl-admission-bound.md | 2 + .../vitest-setup-boundary-timeout-ownership.md | 37 +++ docs/testing.md | 2 +- scripts/__tests__/pg-setup-boundary-probe.test.mjs | 195 ++++++++---- scripts/pg-setup-boundary-probe.mjs | 341 ++++++++++++--------- 5 files changed, 371 insertions(+), 206 deletions(-) Fusion-Task-Id: FN-9140 Fusion-Task-Lineage: 9c6970b8-af80-400a-b2b2-49718d4fe87f Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
1a3e68de5d |
FN-9139: add bounded PostgreSQL pre-admission measurement
Establish an inert PostgreSQL setup signal and repeatable evidence tooling without changing harness behavior. - add explicit setup participation semantics and inertness coverage - survey Vitest setup boundaries with isolated report-only fixtures - bound interleaved campaigns by process group and campaign deadline - reject missing backend samples and enable candidate diagnostics - document the rejected boundary result and successor protocol Files changed: .../test-failures/postgres-ddl-admission-bound.md | 15 ++ docs/testing.md | 10 ++ packages/core/package.json | 2 +- .../src/__test-utils__/pg-setup-participation.ts | 22 +++ .../src/__tests__/pg-setup-participation.test.ts | 21 +++ .../__tests__/vitest-setup-pg-inertness.test.ts | 10 ++ packages/core/vitest.pg.config.ts | 10 ++ .../__tests__/pg-preadmission-campaign.test.mjs | 63 +++++++ scripts/__tests__/pg-setup-boundary-probe.test.mjs | 92 ++++++++++ scripts/pg-preadmission-campaign.mjs | 194 +++++++++++++++++++++ scripts/pg-setup-boundary-probe.mjs | 182 +++++++++++++++++++ 11 files changed, 620 insertions(+), 1 deletion(-) Fusion-Task-Id: FN-9139 Fusion-Task-Lineage: 2cf8ccbf-37f9-4fdc-8e8f-326df823e1cd Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
8bb56a2185 |
FN-9134: add drift-resistant PostgreSQL DDL lane metric
Add a report-only acceptance metric and terminal evidence for PostgreSQL DDL structural experiments. - require seven ordered control/candidate pairs with green Vitest summaries and zero leaked databases - reject missing tests, failed summaries, nonzero exits, and unhandled runner errors - document the no-improvement campaign result and retain the next candidate direction - cover timing statistics, ordering, leak rejection, and runner-log validation Files changed: .../test-failures/postgres-ddl-admission-bound.md | 8 ++ .../suite-only-flakes-observed-register.md | 2 +- docs/testing.md | 24 ++++ scripts/__tests__/pg-ddl-lane-metric.test.mjs | 62 +++++++++ scripts/pg-ddl-lane-metric.mjs | 139 +++++++++++++++++++++ 5 files changed, 234 insertions(+), 1 deletion(-) Fusion-Task-Id: FN-9134 Fusion-Task-Lineage: 3466ebf8-7125-475b-9574-6c4c92198bb3 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
53acaf96c3 |
FN-9123: Repair script test contract drift
Repair script-test contracts to match the current repository policies and live workflow coverage. - Align static-gate and pretest mirrors with authoritative validator chains. - Update the merger-rule floor and parameterized flake registration. - Repoint workflow reliability evidence to the surviving dispatch test. Files changed: .../test-failures/suite-only-flakes-observed-register.md | 4 +++- scripts/__tests__/agents-md-invariants.test.mjs | 10 ++++++++-- scripts/__tests__/engine-vitest-gate-policy.test.mjs | 6 ++++++ scripts/__tests__/run-static-gate-checks.test.mjs | 7 +++++++ scripts/__tests__/verify-fast.test.mjs | 6 ++++++ scripts/lib/workflow-reliability-release-check.json | 4 ++-- 6 files changed, 32 insertions(+), 5 deletions(-) Fusion-Task-Id: FN-9123 Fusion-Task-Lineage: 1a3dad24-69e3-423e-a159-56fd3f1085a3 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
fe910fcce7 |
FN-9122: align merge gate timing and policy baselines
Re-establish a trustworthy W33 merge-gate timing baseline without weakening blocking coverage. - Document the controlled W33 re-measurement and future regression protocol. - Align static-validator test ledgers with all 15 canonical gate checks. - Correct gate composition, engine-core inventory, and bundle metrics in testing guidance. Files changed: .../merge-gate-w33-walltime-regression.md | 82 ++++++++++++++++++++++ docs/testing.md | 12 ++-- .../__tests__/engine-vitest-gate-policy.test.mjs | 12 ++++ scripts/__tests__/run-static-gate-checks.test.mjs | 2 + scripts/__tests__/verify-fast.test.mjs | 8 +++ 5 files changed, 111 insertions(+), 5 deletions(-) Fusion-Task-Id: FN-9122 Fusion-Task-Lineage: 47ace0d7-902d-4ea5-848d-3d2386867c42 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
374ae08d56 |
test(engine): repoint source-scan contracts to the peeled module layout
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> |
||
|
gsxdsm
|
6d2c1bf0c9 |
FN-9020: parallelize boot smoke preflights
Reduce durable boot-smoke latency while preserving its CLI, initialization, health, and shutdown assertions. - Run independent help and init preflights concurrently with bounded async child processes. - Add phase timing diagnostics and deterministic init failure classification. - Cover phase scheduling and isolated environment behavior, and document the diagnostics flag. Files changed: docs/testing.md | 4 +- scripts/__tests__/boot-smoke.test.mjs | 65 ++++++++++- scripts/boot-smoke.mjs | 201 +++++++++++++++++++++++++--------- 3 files changed, 214 insertions(+), 56 deletions(-) Fusion-Task-Id: FN-9020 Fusion-Task-Lineage: 1f5d3d7f-dc0c-4d16-a4ab-fd5e3952dbdf Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
c4467b0a5b |
FN-9007: upgrade Pi runtime to 0.84.1
Upgrade the bundled Pi runtime closure to version 0.84.1. - Pin direct and transitive Pi runtime packages to a coherent 0.84.1 closure. - Adapt runtime interfaces and test assertions for Pi 0.84.1 behavior. - Guard the added Pi client, protocol, and telemetry packages in desktop packaging checks. Files changed: .changeset/fn-9007-pi-0-84-1.md | 7 + packages/cli/package.json | 4 +- packages/cli/src/__tests__/package-config.test.ts | 6 +- packages/cli/vitest.config.ts | 2 +- packages/core/package.json | 2 +- packages/dashboard/package.json | 4 +- packages/dashboard/src/routes.ts | 6 +- packages/engine/package.json | 4 +- packages/engine/src/__tests__/pi.test.ts | 45 ++-- .../src/__tests__/provider-registration.test.ts | 4 +- packages/engine/src/auth/auth-storage.ts | 20 +- packages/engine/src/pi.ts | 5 + packages/pi-claude-cli/package.json | 8 +- pnpm-lock.yaml | 283 ++++++++++++--------- pnpm-workspace.yaml | 14 +- .../__tests__/check-pi-versions-pinned.test.mjs | 27 +- scripts/check-pi-versions-pinned.mjs | 8 + 17 files changed, 279 insertions(+), 170 deletions(-) Fusion-Task-Id: FN-9007 Fusion-Task-Lineage: 89045e86-d4c8-4fc3-bbf6-5ba38fc786e7 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
f2c729bf77 |
FN-8994: add workspace package graph validation
Prevent cold workspace installs from failing on missing or unglobbed local packages. - Validate workspace-protocol dependencies and overrides against glob-covered packages. - Add static-gate coverage and regression tests for missing plugin packages. - Document the workspace package graph check. Files changed: docs/testing.md | 4 +- package.json | 9 +- scripts/__tests__/check-workspace-package-graph.test.mjs | 103 +++++++++++++++ scripts/check-workspace-package-graph.mjs | 138 +++++++++++++++++++++ 4 files changed, 249 insertions(+), 5 deletions(-) Fusion-Task-Id: FN-8994 Fusion-Task-Lineage: 17dbe062-79aa-4417-ae38-43df881e9fa4 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
Phil Larson
|
210c22c485 |
fix(ci): classify workflowRole as role vocabulary (#3408)
## 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 --> |
||
|
gsxdsm
|
f1fe399184 |
FN-8991: add runtime skill-loader drift gate
Enforce the intentional Claude-to-Grok runtime skill-loader clone relationship across verification lanes. - Add an exact rename-diff validator with fixture and live-loader coverage. - Run the validator in pretest, fast verification, and static merge-gate checks. - Document the loader duplication contract and expanded static-validator inventory. Files changed: AGENTS.md | 2 + docs/testing.md | 4 +- package.json | 7 +- .../check-runtime-skill-loader-drift.test.mjs | 113 +++++++++++++++++++++ scripts/__tests__/run-static-gate-checks.test.mjs | 1 + scripts/__tests__/verify-fast.test.mjs | 1 + scripts/check-runtime-skill-loader-drift.mjs | 113 +++++++++++++++++++++ 7 files changed, 236 insertions(+), 5 deletions(-) Fusion-Task-Id: FN-8991 Fusion-Task-Lineage: a3b67752-0043-4336-9a2a-ff391672b31f Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
0eaa3c7b9a |
FN-8990: clean up plugin reload scratch files
Keep plugin hot-reload cache-busting copies ephemeral and remove legacy tracked artifacts. - Delete tracked plugin reload scratch files. - Remove temporary import copies after successful and failed reloads. - Add cleanup and tracked-artifact regression coverage. Files changed: .changeset/fn-8990-plugin-reload-scratch-cleanup.md | 7 ++ packages/core/src/__tests__/plugin-hot-reload.test.ts | 25 ++++ - packages/core/src/plugins/plugin-loader.ts | 16 ++- plugins/fusion-plugin-droid-runtime/src/.index.reload-1.ts | 84 ---------------- plugins/fusion-plugin-droid-runtime/src/.index.reload-2.ts | 84 ---------------- plugins/fusion-plugin-hermes-runtime/src/.index.reload-1.ts | 108 -------------------- plugins/fusion-plugin-hermes-runtime/src/.index.reload-2.ts | 108 -------------------- plugins/fusion-plugin-hermes-runtime/src/.index.reload-3.ts | 108 -------------------- plugins/fusion-plugin-openclaw-runtime/src/.index.reload-1.ts | 95 ----------------- plugins/fusion-plugin-paperclip-runtime/src/.index.reload-1.ts | 112 --------------------- scripts/__tests__/no-tracked-plugin-reload-artifacts.test.mjs | 27 +++++ 11 files changed, 72 insertions(+), 702 deletions(-) Fusion-Task-Id: FN-8990 Fusion-Task-Lineage: 2221ebaf-b8ab-4a3c-8934-addfa348c98c Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
34e74d2fe4 |
perf(verify:fast): run independent steps concurrently
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> |
||
|
gsxdsm
|
878db6dca7 |
FN-8951: repair script-test governance drift
Keep test-shard timing governance aligned with the current workspace and workflow seams. - Add a safe timing-snapshot pruning mode with coverage. - Align Todo plugin Vitest isolation and Docker dependency manifests. - Refresh workflow reliability evidence and remove deleted test timings. Files changed: Dockerfile | 7 ++- docs/testing.md | 9 ++- plugins/fusion-plugin-todos/vitest.config.ts | 26 ++++++-- scripts/__tests__/ci-test-shard-timings.test.mjs | 71 ++++++++++++++++++++++ scripts/ci-test-shard.mjs | 65 ++++++++++++++++++-- .../lib/workflow-reliability-release-check.json | 22 +++---- scripts/test-timings.json | 21 ------- 7 files changed, 175 insertions(+), 46 deletions(-) Fusion-Task-Id: FN-8951 Fusion-Task-Lineage: fbf7e79f-4cb2-43e2-9982-09f3f94de70d Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
6cf95433bf |
FN-8928: evict flaky workflow IR PG gate canary
Remove the flaky sync-workflow-IR PostgreSQL canary from the blocking merge gate while preserving non-blocking coverage. - Remove the default workflow-IR PostgreSQL test from the gate canary script. - Update gate-policy coverage expectations and flake-eviction documentation. - Record the observed setup-hook timeout and retained regression coverage. Files changed: .../suite-only-flakes-observed-register.md | 25 +++++++++++++-- docs/testing.md | 6 ++-- packages/core/package.json | 2 +- .../sync-workflow-ir-is-always-default.pg.test.ts | 6 ++++ .../__tests__/engine-vitest-gate-policy.test.mjs | 37 +++++++++++----------- 5 files changed, 51 insertions(+), 25 deletions(-) Fusion-Task-Id: FN-8928 Fusion-Task-Lineage: b725ba1a-fb33-4d49-89b4-277a64246cdd Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
3d6a908b95 |
FN-8898: document inert prerebase settings
Clarify that legacy prerebase settings are inert on the production merge path. - Mark retained prerebase configuration and audit events as legacy-only. - Add a static validator and tests preventing new prerebase callers. - Update merge architecture, testing, and settings documentation. Files changed: AGENTS.md | 2 +- docs/architecture.md | 3 +- docs/settings-reference.md | 6 +- docs/testing.md | 2 +- package.json | 6 +- packages/core/src/types/settings/settings-scope.ts | 32 +++-- .../src/errors/transient-merge-error-classifier.ts | 12 +- packages/engine/src/merge/merger-auto-prerebase.ts | 12 +- packages/engine/src/util/run-audit.ts | 2 + scripts/__tests__/check-prerebase-inert.test.mjs | 73 +++++++++++ scripts/__tests__/run-static-gate-checks.test.mjs | 1 + scripts/__tests__/verify-fast.test.mjs | 1 + scripts/check-prerebase-inert.mjs | 146 +++++++++++++++++++++ scripts/lib/source-projection.mjs | 87 ++++++++++++ 14 files changed, 359 insertions(+), 26 deletions(-) Fusion-Task-Id: FN-8898 Fusion-Task-Lineage: 9cfd836d-17c2-44a0-a076-56fef0917935 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
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> |
||
|
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> |
||
|
gsxdsm
|
56819e21e9 | fix: restore plugin SDK and Todo packaging | ||
|
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. |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
gsxdsm
|
dfe050e8d4 |
FN-8640: add FNXC stamp anomaly advisory
Add a non-blocking census for implausible future-dated FNXC stamps. - Classify tolerated future stamps by timezone plausibility and report notable anomalies. - Add injectable gate seams and coverage for advisory, report, baseline, and discovery behavior. - Document the advisory and preserve read-only check-mode baseline handling. Files changed: docs/testing.md | 4 + scripts/__tests__/check-fnxc-future-dates.test.mjs | 185 ++++++++ scripts/check-fnxc-future-dates.mjs | 495 +++++++++++---------- 3 files changed, 439 insertions(+), 245 deletions(-) Fusion-Task-Id: FN-8640 Fusion-Task-Lineage: 7e57feb0-95e2-46b9-a1cf-9bd93c40d8e0 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
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. |
||
|
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 -->
|
||
|
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> |
||
|
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> |
||
|
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.
|
||
|
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. |
||
|
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> |
||
|
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. |
||
|
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. |
||
|
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 -->
|
||
|
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> |
||
|
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> |
||
|
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. |
||
|
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> |
||
|
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. |
||
|
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.
|
||
|
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> |
||
|
gsxdsm
|
72f5f8e51a |
fix(gate): the FNXC stamp gate never validated the hour, so 25:30 passed (#2995)
`check-fnxc-future-dates.mjs` validates the **date** portion of a stamp
and never looks at the clock time:
```js
const STAMP = /FNXC:[A-Za-z0-9_-]+\s+(\d{4}-\d{2}-\d{2})/g;
…
for (const match of source.matchAll(STAMP)) if (match[1] > today) hits += 1;
```
The capture stops before the hour, so a stamp may carry **any** `hh:mm`
and pass. Found while pre-flighting #2992, whose new comments read
`2026-07-30-25:30`.
## It is not one typo
Four stamps **already on `main`** carry a clock time that cannot exist:
```
packages/cli/src/__tests__/task-list-board-columns.test.ts:2 -24:40
packages/cli/src/commands/task.ts:29 -24:40
packages/cli/src/commands/task.ts:636 -24:40
scripts/check-lane-wiring.mjs:18 -24:00
```
Three separate authors, so this is the gate's blind spot rather than one
person's slip — and #2992 adds two more, which is how I noticed.
AGENTS.md specifies `yyyy-MM-dd-hh:mm`. The stamp's whole purpose is to
make the FNXC record a readable chronology of *why* code exists; a
timestamp that cannot exist quietly costs it that, and nothing was going
to catch it.
## The fix
Hours `00-23`, minutes `00-59`, counted per file **alongside** the
future-dated population rather than as a separate gate — same defect
class (a stamp that does not describe a real moment), and one ratchet is
cheaper to keep honest than two.
**Mutations, both directions:**
| stamp | result |
|---|---|
| `2026-07-30-25:00` | **flagged** |
| `2026-07-30-23:75` | **flagged** |
| clean tree | `475 known future-dated stamp(s), none added`, exit 0 |
## On the four existing stamps
Normalized by clamping the impossible hour to `23`, minutes preserved,
so relative ordering within each file survives. **That is a
normalization with a stated rule, not a claim about the true minute** —
`-24:40` most plausibly meant "just past midnight", but writing
`2026-07-31-00:40` would be future-dated against today's local calendar
and fail the very gate this PR extends. Clamping keeps every stamp real,
ordered, and non-future; the exact minute was already unrecoverable.
**Verified:** FNXC gate exit 0, lane-wiring gate exit 0,
`task-list-board-columns` 5/5, lint clean.
Comment-only changes to the CLI files (stamp text inside FNXC blocks),
so no behaviour change and no changeset.
Noted separately on #2992 so its two new stamps get corrected there
rather than landing and immediately failing this gate.
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
gsxdsm
|
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.
|
||
|
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.
|
||
|
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.
|
||
|
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> |