From 152fedbd32fc8382e2ed6a1efb06f8c64f29de98 Mon Sep 17 00:00:00 2001 From: gsxdsm Date: Wed, 29 Jul 2026 23:34:30 -0700 Subject: [PATCH] record the detector audit: gridlock and stuck-task are keeps, with evidence (#2581) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Answering the review question *“does gridlock detection still have a job?”* — with evidence rather than assumption, and recording it so the question is not re-opened by someone reading the name. **No behaviour change.** Comments only. ## Gridlock detector — KEEP `GridlockEvent.reasons` is typed `"dependency" | "overlap"`. It detects **dependency deadlock** and **file-scope overlap deadlock** via the scheduler’s `pathsOverlap` / `filterPathsByIgnoreList`. That has nothing to do with limiters arbitrating against each other — two tasks can still block on a dependency cycle or a shared file scope no matter how many agents the operator allows. The hypothesis that gridlock ≈ competing limiters deadlocking was reasonable from the name, and wrong. ## Stuck-task detector — KEEP Detects a stuck **agent** — a live session repeating the same tool call, or emitting no activity signal — via tool fingerprints and inactivity windows. Orthogonal to how many agents may run: a single agent on an unlimited board can still wedge. ## Evidence Measured for both: **zero** references to `maxConcurrent` / `maxWorktrees` / `semaphore` / `capacity` / `slot`. Both are live and wired — gridlock via `project-engine.ts → notifier.notifyGridlock`, stuck-task via `in-process-runtime.ts`. The note lives in each file because the natural reading of “gridlock” is “limiters deadlocking”, and deleting a live detector on that reading would remove real coverage silently. Each note states the question a future cleanup should actually ask — *is dependency/overlap deadlock still possible?* — rather than *is capacity simpler now?* `pnpm lint` clean · engine `tsc` clean · `pnpm test:gate` green · detector suites **108/108**. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) --- packages/engine/src/gridlock-detector.ts | 22 ++++++++++++++++++++++ packages/engine/src/stuck-task-detector.ts | 13 +++++++++++++ 2 files changed, 35 insertions(+) diff --git a/packages/engine/src/gridlock-detector.ts b/packages/engine/src/gridlock-detector.ts index d141484f08..cc0589f3eb 100644 --- a/packages/engine/src/gridlock-detector.ts +++ b/packages/engine/src/gridlock-detector.ts @@ -1,3 +1,25 @@ +/* +FNXC:CapacityModel 2026-07-29-15:00 (capacity-simplification audit — KEEP, with evidence): +ASKED AND ANSWERED: does gridlock detection still have a job once capacity is two +numbers and the competing limiters are gone? + +YES. "Gridlock" here has nothing to do with limiters arbitrating against each other. +`GridlockEvent.reasons` is typed `"dependency" | "overlap"` — it detects DEPENDENCY +deadlock and FILE-SCOPE OVERLAP deadlock, using `pathsOverlap` / +`filterPathsByIgnoreList` from the scheduler. Neither is affected by removing the +cross-project cap, the spawn budgets, or the worktree gate: two tasks can still +block each other on a dependency cycle or a shared file scope no matter how many +agents the operator allows. + +Measured, not assumed: no CODE in this file references maxConcurrent, maxWorktrees, the shared +semaphore, or any slot/capacity accounting — the only occurrences of those words are in this note. +It is live and wired (project-engine.ts -> notifier.notifyGridlock). + +Recorded here because the natural reading of the NAME is "limiters deadlocking", and +deleting a live detector on that reading would remove real coverage silently. If a +future cleanup revisits this, the question to ask is whether dependency and overlap +deadlock are still possible — not whether capacity is simpler. +*/ import type { MissionStore, Task, TaskStore, WorkflowIr } from "@fusion/core"; import { resolveTaskLifecycleColumns } from "@fusion/core"; import { createLogger } from "./logger.js"; diff --git a/packages/engine/src/stuck-task-detector.ts b/packages/engine/src/stuck-task-detector.ts index 6de50d44d5..72029d86e6 100644 --- a/packages/engine/src/stuck-task-detector.ts +++ b/packages/engine/src/stuck-task-detector.ts @@ -1,3 +1,16 @@ +/* +FNXC:CapacityModel 2026-07-29-15:00 (capacity-simplification audit — KEEP, with evidence): +Audited alongside the gridlock detector while collapsing the capacity model. It is +NOT a capacity component and nothing here changes with the limiters. + +This detects a STUCK AGENT — a live session repeating the same tool call, or emitting +no activity signal — via tool fingerprints and inactivity windows. That is orthogonal +to how many agents are permitted to run: a single agent on an unlimited board can +still wedge. + +Measured, not assumed: zero references to maxConcurrent / maxWorktrees / semaphore / +capacity / slot in this file. Live and wired (in-process-runtime.ts). +*/ /** * Stuck Task Detector — monitors in-progress tasks for agent session stagnation. *