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.
  *