Adds platform-level protection against agent self-resonance loops: when
an assignee agent posts CONSECUTIVE_AGENT_COMMENT_CAP (3) comments in a
row on the same issue with no human or other-agent reply in between, the
route now automatically:

1. Sets the issue to `blocked` (which also clears checkoutRunId,
   executionRunId, and related lock fields via the existing update path).
2. Posts a system-authored comment tagging the CTO for manual review.
3. Suppresses the assignee wake for that comment, preventing the next
   loop iteration.

Guards: skips on closed issues, reopened-by-comment flows, and comments
from non-assignees. Includes 6 unit tests covering cap trigger, streak
reset by human/other-agent, closed-issue bypass, and non-assignee bypass.

Guardrails 1 (self-comment wake suppression via selfComment check) and 3
(blocked-issue dependency suppression) were already implemented at the
scheduler/route layer; documented in FUL-2207 issue comment.

Co-Authored-By: Paperclip <[email protected]>

Three targeted fixes to break the board-user-comment → agent-wake
infinite loop on blocked issues:

1. Remove `blocked` from `shouldImplicitlyMoveCommentedIssueToTodo` so
   a plain board comment no longer silently promotes blocked → todo.
   Only formally-closed issues are eligible for implicit reopen.

2. Add `isBlockedWithoutReopen` guard to the POST /comments wake path
   and set `issue.status === "blocked"` in the PATCH route skipWake
   check. Comments on blocked issues no longer fire `issue_commented`
   wakes; `issue_blockers_resolved` and explicit reopen paths are
   unaffected.

3. Add `ne(issues.status, "blocked")` to the checkout WHERE clause and
   a 422 error when `current.status === "blocked"`, preventing any
   agent from silently promoting a status-blocked issue to `in_progress`
   by passing `expectedStatuses: ["todo","blocked",...]`.

Tests: updated existing blocked-issue reopen tests to expect the new
behaviour; added skipWake route test and a service-level checkout
rejection test for status-only-blocked issues.

Parent incident: FUL-2230

Co-Authored-By: Paperclip <[email protected]>

…adapter_failed (FUL-2341)

When issuesSvc.checkout throws HTTP 422 because the issue status is blocked,
the outer catch was classifying the run as adapter_failed, pushing the agent
into error state. This is a platform misclassification — a blocked checkout
is a known gate condition, equivalent to unresolved blockedByIssueIds.

Add isCheckoutBlockedError helper (matches 422 "Issue is blocked*") and handle
it in the executeRun checkout catch block by calling
cancelQueuedRunForBlockedDependencies + finalizeAgentStatus("cancelled").
The run now records errorCode=issue_dependencies_blocked / status=cancelled,
and the agent transitions to idle rather than error.

This fixes the phantom-blocked scenario: issues with status=blocked but empty
blockedByIssueIds pass through the claimQueuedRun dependency check (count=0)
and shouldAutoCheckoutIssueForWake returns true, but checkout throws 422.

Co-Authored-By: Paperclip <[email protected]>

…kout_blocked

When a blocking issue transitions to done, automatically move any dependent
issues with status=blocked to todo (instead of only waking the assigned agent).
Logs an issue.auto_unblocked activity note recording which blocker resolved the
issue. Non-blocked dependents (in_progress, in_review, todo) are unaffected —
only the status wake is sent. Regression tests cover: single blocker resolves →
auto-transition; non-blocked dependent → no status change; remaining blockers
→ no action.

Fixes: FUL-2358

Co-Authored-By: Paperclip <[email protected]>

…ing execution stage exists

When all blockers on a blocked issue resolve, check the dependent's
executionState. If a review stage is pending (status="pending"), restore
to in_review so the waiting reviewer is re-engaged. Otherwise fall back
to todo as before. Also include executionState in listWakeableBlockedDependents
query results to support the routing decision.

Regression coverage: adds the validation-child-done scenario (blocked
dependent with pending review stage → blocker resolves → back to in_review).

Fixes: FUL-2358 (board comment 847dabac)

Co-Authored-By: Paperclip <[email protected]>

…point limits (FUL-2371)

- Add global Express middleware in app.ts that logs a structured WARN for
  any request exceeding 500 ms, including method, path, statusCode,
  durationMs, and X-Paperclip-Run-Id header value
- Middleware is registered immediately after httpLogger so it covers all
  API routes; uses the existing server logger (not console.log)
- Document server-side limitBytes cap on log-streaming endpoints:
  default 256 KB, hard ceiling 1 MB enforced via readRunLogLimitBytes
- Relax Cache-Control on GET /heartbeat-runs/:runId/log from no-cache,no-store
  to no-cache: the offset-based polling protocol already prevents stale reads,
  and no-store is unnecessarily aggressive for this endpoint

Co-Authored-By: Paperclip <[email protected]>

…adapter.execute() (FUL-2374)

The late-detection path added in 55b3a8c catches blocked checkout at
issuesSvc.checkout() time, after the run has already been transitioned
to running status. The board identified the remaining control-flow leak:
adapter.execute() is never called for the blocked run itself, but the
finally block still fires startNextQueuedRunForAgent, and any
post-success pipeline (e.g. handleSuccessfulRunHandoff) from a
concurrent run could bleed adapter calls into the next test.

Add early detection in claimQueuedRun: when unresolvedBlockerCount=0
(no formal blockedByIssueIds) but the issue status is blocked, cancel
the run immediately with errorCode=issue_dependencies_blocked and return
null. executeRun returns at the null-claim guard, before
activeRunExecutions.add() and before the try/finally block, so
adapter.execute() is structurally unreachable for the phantom-blocked
run.

Fix afterEach mock-reset timing in the dependency-scheduling test: the
old code reset mockAdapterExecute before waiting for background runs to
idle, so any corrective handoff run created by a test's success-path
pipeline (handleSuccessfulRunHandoff) executed after the reset and
incremented the call count going into the next test. Moving the reset
to after the idle-poll loop—and adding a 200 ms initial settle to
prevent the poll from declaring idle before the handoff run appears in
the DB—eliminates the cross-test bleed and makes the zero-call
assertion reliable.

Co-Authored-By: Paperclip <[email protected]>

…ckers complete

listWakeableBlockedDependents filtered out candidates with a null
assigneeAgentId, so blocked issues with no assignee were never
auto-transitioned when their blockers resolved (FUL-2381 / FUL-2389).

Remove the assigneeAgentId guard from the status-filter so all
blocked-and-fully-resolved dependents are auto-transitioned to todo
regardless of whether they have an assignee. The addWakeup call is now
guarded by a null-check so wakeups are only sent when an assignee exists.

Adds a regression test for the unassigned-dependent path.

Co-Authored-By: Paperclip <[email protected]>

…, wiring

- Migration 0087: adds compacted_at to heartbeat_runs, creates instance_retention_config table
- HeartbeatCompactionService: NULLs result_json/stdout_excerpt/stderr_excerpt/context_snapshot
  for succeeded runs older than configured threshold (default 72h), batched in groups of 100;
  also NULLs adapter.invoke event payloads for compacted runs
- Admin API: GET/PATCH /api/admin/retention-config (instance-admin only)
- app.ts: wires startHeartbeatCompaction and startPluginLogRetention (was never called) at startup

Fixes FUL-2363 / FUL-2323 (557 MB DB bloat from indefinitely-retained TOAST).

Co-Authored-By: Paperclip <[email protected]>

…2489)

- Add `is_router` boolean column to agents table (migration 0089)
- Add `assertRouterAgentPatchAllowed` middleware: router agents may PATCH
  assigneeAgentId, blockedByIssueIds, and status (blocked/in_progress/todo only)
- Enforce board-assignment preservation: cannot reassign board-user-owned issues
- Audit log: records `issue.router_agent_cross_patch` with isRouter marker
- Ship migration 0088 (privileged_human_gate) alongside this change
- DB already migrated; TODD agent (369da996) already has is_router=true

Pending: server restart required to load new middleware into running instance.

Co-Authored-By: Paperclip <[email protected]>

…oard view

List view was fetching all issues unfiltered then applying status filters
client-side. With large datasets (200+ issues mostly done/cancelled), the
first server page returned very few matching issues while the rest were
filtered away client-side — producing the "one issue visible / scroll to
load more" symptom.

Board view already fired per-status server queries (boardIssueQueries).
This adds an equivalent listIssueQueries path that activates when viewMode
is "list" and explicit statuses are selected. Results are merged and passed
through the same applyIssueFilters path as before.

- Adds ISSUE_LIST_STATUS_RESULT_LIMIT = 200 (matching board cap)
- listIssues replaces the issues prop as the filter source when active
- canLoadMoreIssues and the load-more sentinel suppress server pagination
  when list-mode status queries own the data
- Shows a cap notice ("up to 200 per status") mirroring the board notice

Co-Authored-By: Paperclip <[email protected]>

…(FUL-2490)

Two missing pieces from the isRouter permission model (FUL-2489):

1. Add `isRouter: z.boolean().optional()` to createAgentSchema (and
   through partial(), to updateAgentSchema). Without this the validator
   strips the field from POST /api/agents and PATCH /api/agents/:id
   bodies before they reach the service, so isRouter could never be
   set via the public API.

2. Rename the audit-log detail key from `isRouter: true` to
   `routingCorrection: true` in the issue.router_agent_cross_patch
   activity entry, matching the AC in FUL-2490.

Co-Authored-By: Paperclip <[email protected]>