Bumps [tar](https://github.com/isaacs/node-tar) from 7.5.13 to 7.5.22.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="2a22bfc5d3"><code>2a22bfc</code></a>
7.5.22</li>
<li><a
href="df1cd8dc09"><code>df1cd8d</code></a>
Allow transform to be falsey</li>
<li><a
href="0cd9cc3c58"><code>0cd9cc3</code></a>
7.5.21</li>
<li><a
href="631ae59121"><code>631ae59</code></a>
list: prevent unbounded recursion</li>
<li><a
href="ebbb720941"><code>ebbb720</code></a>
7.5.20</li>
<li><a
href="2f271963a7"><code>2f27196</code></a>
fix: fully disable and dispose of unzip when aborting parser</li>
<li><a
href="be440da64e"><code>be440da</code></a>
7.5.19</li>
<li><a
href="2812e93386"><code>2812e93</code></a>
add maxDecompressionRatio guard against explosive decompression</li>
<li><a
href="9ecd4d2956"><code>9ecd4d2</code></a>
7.5.18</li>
<li><a
href="9e78bf058b"><code>9e78bf0</code></a>
refuse to let header size be less than 0</li>
<li>Additional commits viewable in <a
href="https://github.com/isaacs/node-tar/compare/v7.5.13...v7.5.22">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
**Problem:** Each dashboard/engine project consumer polled
`task_deleted` outbox on a fixed 5s setInterval, so ~44 per-project
consumers thundered together on the same cadence — an idle DB query
storm and CPU hot-spot even when projects were paused/idle.
**Fix:** The outbox consumer reschedules itself from each poll outcome:
an idle poll (zero events) grows the next delay by
`TASK_DELETED_OUTBOX_BACKOFF_STEP_MS` toward `MAX_POLL_MS`, with ±20%
jitter so the consumers de-synchronize; a poll that delivered events
resets to the fast base. A paused/idle project drains its outbox and
backoff alone drops the DB load.
**Includes:** regression test (bounded jitter + idle growth),
performance changeset, solution doc, deploy handoff script.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Performance**
- Reduced unnecessary idle polling by gradually increasing the polling
interval, up to 60 seconds, with bounded timing variation.
- Restored the faster 5-second polling cadence when new events, waits,
or transient errors occur.
- Preserved event ordering, delivery guarantees, acknowledgements, and
independent behavior across concurrent consumers.
- **Documentation**
- Added guidance on polling behavior, deployment verification, and
monitoring targets.
- **Tests**
- Added coverage for backoff growth, jitter limits, event bursts,
concurrent consumers, error handling, retries, and clean shutdown.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Auditing for repeats of the `pnpm dev --tunnel` bugs turned up the same
mistakes elsewhere.
Remote tunnels assumed 4040. ProjectEngine's Cloudflare quick tunnel
hardcoded http://localhost:4040, so a dashboard on an explicit --port, a PORT
override, or runDashboard's EADDRINUSE rebind published a PUBLIC tunnel to
whatever else held 4040. The dashboard now records its bound port
(setLocalDashboardPort, from both runDashboard and headless serve) and the
tunnel reads it, keeping 4040 only as the pre-report default.
register-discovery-routes already derived its port from req.socket.localPort
and is untouched.
Stopping the dev wrapper orphaned everything it started. It installed no
signal handlers, so teardown only ran from the child's close handler:
signalling the wrapper left the dev server AND its cloudflared alive —
observed twice, four surviving processes each time, including a public
trycloudflare URL still serving a dev server believed to be down. Ctrl-C hid
it by signalling the whole process group.
SessionTerminal appended scrollback instead of clearing first, though the
server sends it as a separate frame precisely so the client can clear. Latent
today because every reattach builds a fresh xterm; a duplicated-history bug
the moment an in-place reconnect appears.
And BackupManager's centralDbPath is gone: written, never read, and a
leftover of the removed SQLite backup — the same class of stale artifact that
onboarding was using as evidence about a Postgres install.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
**Problem:** Scheduler was re-reading each task's
`task_workflow_selection` once per park-resolution (sweep, hold-release,
moved, unpause/wake), causing a nonstop PostgreSQL query storm (~232
idx_scan/s) on idle polling — a major engine CPU hot-spot.
**Fix:** Memoize the workflow selection per scheduler tick/event —
thread a shared, per-event selection cache through
`resolveWorkflowIrForTask` and all park-resolution handlers, then throw
it away. Each task resolves its parked columns with at most one read of
`task_workflow_selection` per tick. A selection write is always observed
on the next event's fresh cache (never a global/infinite LRU).
**Includes:** regression test asserting the once-per-tick read
invariant, performance changeset + per-tick-cache solution doc,
deploy+verify handoff script, and the parallel quarantine-ledger merge
(origin FN-9125 + RUFU-072 OOM entries both retained).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Performance Improvements**
* Reduced repeated workflow-selection reads during scheduler ticks and
related event processing.
* Improved scheduler and health API responsiveness through per-operation
caching and read deduplication.
* Preserved existing behavior, including retry handling for failed reads
and synchronous data-store support.
* **Documentation**
* Added architectural guidance covering workflow-selection performance,
caching behavior, and verification criteria.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Fusion <noreply@runfusion.ai>
The gate blocked approved clean-room squashes on per-file shrinkage with no
override path ("AI merge diff-volume gate blocked the approved squash").
Removed by operator decision: delete checkDiffVolume/DiffVolumeRegressionError,
the merge:diff-volume-blocked audit event, the runDiffVolumeGate call sites in
every legacy squash finalizer, the AI-merge pre-land check, and the
mergeDiffVolume* settings. File scope remains the pre-land guard; the
post-squash audit policy remains the shrinkage backstop.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Slow-test trim, OPTIMIZE tier (harness owner). Profiling showed 163ms
of the shared harness's 169ms per-test beforeEach was one TRUNCATE over
~110 tables (per-table catalog/fsync constants, row-independent). The
reset is now a single DO block: transaction-local
session_replication_role=replica, DELETE only from non-empty tables,
and sequence resets reproducing RESTART IDENTITY exactly — 169ms → 10ms
per test across every harness file, with the legacy TRUNCATE retained
as an automatic error fallback for non-superuser roles. sqlite-migrator
(the live SQLite→PG upgrade path; all 43 tests kept incl.
VAL-MIGRATE-001..006) now provisions targets from a golden-template
clone via new createBaselinedPgTestDatabase/createEmptyPgTestDatabase
exports — the dry-run test keeps a pristine empty DB so its
no-schemas-left-behind assertions stay meaningful — 148.8s → ~26s.
taskstore-lifecycle, data-layer, and taskstore-remaining migrate onto
the shared harness with byte-identical test bodies (187s → ~11s
combined); data-layer's close() test closes a private layer so the
shared pool survives. Seeding hoists were measured and deliberately
skipped: the harness fix already exceeded their projected savings and a
beforeAll seed would weaken the clean-DB-per-test contract.
Verified: 287 tests green across the touched files plus untouched
harness consumers (schema-applier 80/80, mission-store 62/62).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Slow-test trim, OPTIMIZE tier (mechanical sweep). These files each
created and baselined a fresh database per test (~3-4.6s/test); they now
use the shared golden-template harness (TRUNCATE per test) or, where a
private database is genuinely required (postgres-health drift/VACUUM
subjects, allocator-cross-project RLS connection sets), a per-test
template clone instead of raw DDL. Zero assertion lines changed
(verified), identical test counts, 110/110 green. Deliberately left
alone: startup-factory-integration and embedded-lifecycle (own-database
boot IS the subject) and schema-applier (real DDL is the subject).
Measured: ~195s serial → ~30s for these files.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Slow-test trim, CONDENSE tier. The three satellite-store files each
hand-rolled CREATE DATABASE + schema baseline per test (38 database
creations, ~75s serial); their describes now live verbatim — every it
name, assertion, and FNXC provenance comment preserved, 38/38 tests —
inside one shared-harness file with a single boot. The 3-test
custom-v1-workflow-dispatch characterization (13s alone) moved into the
adjacent no-selection-default-workflow-move harness file. Measured:
~92s serial → ~8s for the same coverage.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Full-suite repair, engine source-scan cluster. The package code
organization waves moved ~30 engine modules into subdirectories
(plugins/, execution/, scheduling/, healing/, worktree/, executor/
peels); the log-severity manifest, prompt carve-out, emit-surface,
failure-lane, and worktree-invariant scanners now read the moved
locations, verified per file via git log --follow. Two scans caught
real drift rather than moves: the lifecycle census had 12 unexamined
column guards (resolved with DELIBERATE-LITERAL markers for the mailbox
archived tab, the FN-9059 lease-owner terminality check, and the FN-9056
legacy done fallback — baseline re-recorded with zero absorbed debt),
and planning-claim gained a genuine second writer in self-healing's
FN-8998 transport-failure recovery, admitted to the allowlist with its
CAS-guarded justification. 9 files / 119 tests green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Full-suite repair, core cluster. Two real product regressions caught by
the red tests: (1) the wave-18 refactor dropped the task.title argument
FN-8840 added to isDuplicateRedirectOnlyPrompt inside
isTaskAwaitingPlanning, so a title-only DUPLICATE:<ID> redirect read as
executable Ready instead of awaiting planning; (2) FN-8998 scoped every
workflow-definition read by layer.projectId but left the INSERT on the
session-GUC default, so a JS-bound layer created workflow rows it could
never read back — the insert now stamps the bound projectId like the
FN-8997 workflowSteps insert. Test-lag fixes: analytics renamed-lanes
harnesses now bind projectId 'p1' to match FN-8957/FN-8998 scoping,
project-ownership-runtime-scope replaces a hardcoded expired approval
date, schema-applier learns migrations 0059/0060 (115 project tables,
baseline 0060), and builtin-workflow-settings-triage learns FN-8932's
memoryConsolidationEnabled with position-independent lookups.
Verified: 10 files / 128 tests green, core typecheck clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Full-suite repair, mechanical cluster: the wave-18 executor peel (#3317)
moved the audited child-spawn bound to executor/create-spawn-agent-tool.ts,
the admission-reason unification moved the binding-gate discriminator into
concurrency/concurrency.ts, and the FN-9059-era merge-claim and direct
workflow-continuation defers read the shared ceiling through
resolveActiveTaskCapacityLimit (OFF-mode aware) — all audited with reasons,
none is a new raw gate. Core's vitest config now aliases the
@fusion/core/mcp-builtin-servers subpath before the bare alias (mirroring
engine's config) so core PG tests that exercise engine's mcp-resolution
resolve it from source.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
check:lane-wiring runs in CI's Lint gate and has been failing on main since FN-9037 landed
`listTaskRecommendations`, so it blocks every PR in the repo, not just the one that hit it.
Recorded rather than rewired, because this is the false-positive shape the escape hatch exists
for. The guard catches a callee silently falling back to a LEGACY COLUMN LITERAL when a caller
omits the lane; `listTaskRecommendationsImpl` falls back to
`resolveProjectColumnsForRoles(store, ["complete"])`, which reads the board's own lanes. Real
callers already pass a resolved set — the dashboard route resolves `completeColumns` before
calling — so the fallback only serves the pass-through wrapper. Resolving again in the wrapper
would duplicate that query on every call for no behavioural difference.
The reason lives at the call site as well as in the baseline, since a bare count in a JSON file
is exactly the kind of entry that later reads as unexplained debt.
Baseline diff verified to be a single added entry (store.ts: 1) — nothing else raised or lowered.
Verified: check:lane-wiring exits 0, core typecheck clean, eslint clean, FNXC date check clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Triage announced specification completion before its finally block marked the
plan work item terminal, so the Plan Review seeder saw its own still-running
predecessor as an "active continuation", bailed, and the discarded result
silently stranded the card until FN-8592 self-healing re-seeded it ~10 minutes
later (529 occurrences in 18 days).
- seedStrandedPlanReviewContinuation gains retirePredecessorId: idle check
excludes the named predecessor, then retires it and installs the successor in
ONE transaction under the task lock; a bailed seed mutates nothing.
- triage threads planningWorkItemId through PlanningHandoffReport; the runtime
reaction passes it as retirePredecessorId.
- reactToSpecificationComplete consumes the seed result: typed quiet parks
(incl. new "no-pre-release-plan-review"), bounded retries with a fresh
task/IR snapshot per attempt (mid-retry pause/needs-replan honored), loud
warning naming self-healing on exhaustion.
- Tests: PG both-orderings/no-mutation-on-bail/cross-task cases, direct engine
seeder handoff cases, reaction retry/park/pause/replan cases.
- docs/solutions: new planning-handoff-race writeup; graph-entry-contract doc
reclassifies the FN-8592 sweep as backstop-only.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
