Problem

The kanban dispatcher's recompute_ready() promoted parentless blocked tasks back to ready on every tick because all([]) is True (vacuous truth). This defeated the circuit breaker: a task would crash, get auto-blocked (gave_up event), then immediately be promoted back, have its consecutive_failures counter reset to 0, and the cycle repeats forever.

Crash loop trace

gave_up → promote → claim → spawn → crash → gave_up → promote → ...

Observed in production: 509 crashes on a single task, 8,343 gave_up events, 500+ zombie processes created every 60 seconds. Each task with consecutive_failures reset to 1 on every cycle because gave_up trips at failure_limit=1 (protocol violations / systemic failures), then recompute_ready immediately promotes and resets the counter.

Root cause

In recompute_ready() (kanban_db.py line ~2125):

1. blocked tasks are considered for promotion (correct for dependent tasks whose parent just completed)
2. _has_sticky_block() correctly skips worker-initiated kanban_block calls, but circuit-breaker blocks (gave_up event, non-sticky) pass through
3. For parentless tasks: parents = conn.execute("SELECT ... FROM task_links WHERE child_id = ?", (task_id,)).fetchall() returns [], and all([]) == True — vacuous truth promotes them
4. Line 2135-2139 resets consecutive_failures = 0 on promotion, so the breaker never accumulates

Fix

Two changes:

1. Vacuous-truth guard (primary fix)

recompute_ready() now skips promotion of parentless blocked tasks. A task with no parents has no dependency to wait for; promoting it only re-queues a deterministic crash. These tasks stay blocked until an operator runs kanban_unblock (e.g. after fixing the underlying issue: bad API key, missing skill, auth error).

has_parents = len(parents) > 0
if all(p["status"] in ("done", "archived") for p in parents):
    if cur_status == "blocked":
        if has_parents:
            # Original behavior: promote and reset counters
        else:
            # New: skip parentless blocked tasks entirely
            continue

2. Failure-counter reset guard (belt-and-suspenders)

When a blocked task with parents is promoted (because a parent just completed), consecutive_failures is still reset to 0 — the conditions that caused the failure may have changed. This preserves the original auto-recovery semantics (#40c1decb3) for tasks with a legitimate dependency chain.

What's NOT changed

• Parentless todo tasks still promote to ready normally (the guard only applies to blocked → ready transitions)
• Parented blocked tasks still auto-recover when their parent completes
• Worker-initiated kanban_block stays sticky (the kanban: dispatcher auto-promotes blocked task → respawn worker → protocol_violation loop #28712 guard is untouched)
• kanban_unblock still works — operators can manually unblock parentless tasks after fixing the underlying issue

Testing

• 8 new tests in test_kanban_crash_loop.py covering all combinations:
  • Parentless circuit-breaker block stays blocked (×5 iterations, ×10 dispatch ticks)
  • Parentless task with manual kanban_block stays blocked (sticky + vacuous)
  • Parented blocked task with done parent auto-promotes (existing semantics preserved)
  • Parented blocked task with incomplete parent stays blocked
  • Parentless blocked task failure counter not reset
  • Unblocked parentless task becomes ready (operator can still recover)
  • Parentless todo task promotes normally (guard only affects blocked)
• 1 updated test in test_kanban_blocked_sticky.py:
  • test_unblock_clears_sticky_state_and_lets_block_recover now uses a task with parents to match the new semantics
• All 557 existing kanban tests pass (159 in test_kanban_db.py, 6 in test_kanban_blocked_sticky.py, plus others)