fix(kanban): keep initial blocked holds sticky

[joshuadow]

Summary

• Treat tasks created with initial_status="blocked" as operator-controlled sticky holds by emitting a blocked event at creation time.
• Add regression coverage proving recompute/dispatch dry-run does not promote initially blocked pilot cards.
• Preserve existing transient/circuit-breaker blocked-task recovery behavior through existing recompute tests.

Why

dispatch_once(..., dry_run=True) runs the same promotion sweep used by the live dispatcher. A task created directly in blocked had no blocked event, so the sticky-block guard treated it like a recoverable transient block and promoted it to ready. For controlled Kanban pilots, that made dry-run preflight able to mutate a blocked hold into spawnable work before explicit unblock.

Validation

• scripts/run_tests.sh tests/hermes_cli/test_kanban_blocked_sticky.py tests/hermes_cli/test_kanban_db.py tests/hermes_cli/test_kanban_default_assignee.py tests/hermes_cli/test_kanban_per_profile_cap.py
  • Result: 237 tests passed, 0 failed.
• Isolated runtime repro after the fix:
  • before: blocked
  • after dry-run dispatch: blocked
  • promoted: 0
  • spawned: []
  • events remained created, blocked
• git diff --check
  • Result: clean.

Risk

Low. The change only adds an event for explicit initial blocked task creation. Existing worker/operator block semantics already use this event shape, and existing circuit-breaker recovery tests still pass.

[liuhao1024]

Verification: blocked hold sticky behavior

LGTM — the fix is clean and well-scoped. Creating an explicit blocked event with source: "initial_status" correctly distinguishes operator-controlled holds from transient circuit-breaker blocks. The two tests cover the key invariants:

1. recompute_ready leaves the task blocked until explicit unblock
2. dispatch_once(dry_run=True) does not emit a real promoted event or mutate the status

This prevents a real race condition where a dispatch dry-run could leak a promoted event into the live gateway before the operator finishes their preflight.

[teknium1]

Thanks for the focused regression fix. The premise remains valid on current main: create_task() writes status="blocked" for initial_status="blocked" at hermes_cli/kanban_db.py:2585, but records only created at hermes_cli/kanban_db.py:2670. _has_sticky_block() therefore returns false without a blocked event (hermes_cli/kanban_db.py:3273-3279), and recompute_ready() promotes the task (hermes_cli/kanban_db.py:3324-3364). dispatch_once() invokes that promotion sweep at hermes_cli/kanban_db.py:7309.

The PR's event insertion aligns exactly with the established sticky-block contract, while its two tests cover direct recomputation and the dispatcher dry-run path. No correctness or completeness issue was identified in the changed lines.

Automated hermes-sweeper review.