fix(kanban): keep initial_status='blocked' tasks sticky

[Jeffgithub0029]

What

create_task(initial_status='blocked') is an explicit human parking decision, not a recoverable circuit-breaker failure. Until now it wrote tasks.status='blocked' without a blocked event row, so _has_sticky_block saw no sticky signal and the next dispatcher recompute_ready silently promoted the card to ready — after which it was dispatched to a worker that had nothing left to do.

This PR records a typed blocked event (kind: needs_input) at creation, making the initial parking decision sticky the same way a worker-initiated kanban_block is. unblock_task remains the only way out.

Scope (narrow by design)

• Only create_task gains an event emission. No block_kind mutation, no recompute_ready / reclaim_task changes.
• Consequently unblock → parent-completion, unblock → claim → reclaim, and circuit-breaker auto-recovery semantics are untouched (regression tests included).

Relationship to other PRs

• fix(kanban): emit blocked event when initial_status='blocked' so sticky-block guard fires #34735 covers the same initial-blocked bug and remains open; this PR is a deliberately minimal implementation with an extra unblock/reclaim lifecycle regression pair.
• The audited kanban update-body command that previously lived in this branch is now its own focused PR: feat(kanban): add audited update-body command #76765.
• The typed-gate / reclaim-preservation / legacy-repair behavior from the earlier combined branch was dropped per triage guidance; maintainers should pick the sticky-gate scope they want across fix(kanban): emit blocked event when initial_status='blocked' so sticky-block guard fires #34735 / fix(kanban): make --initial-status blocked sticky against recompute_ready #71977 / fix: keep initial blocked kanban tasks inert #35832 / fix(kanban): keep initial_status=blocked tasks blocked across recompute_ready #46565 / fix(kanban): keep create-time blocked tasks sticky #71147 / fix(kanban): keep initial blocked tasks sticky #69679 / fix: keep explicitly blocked Kanban tasks sticky #34756.

Tests

python -m pytest tests/hermes_cli/test_kanban_blocked_sticky.py -q
→ 5 passed (was 2 baseline + 3 new: initial-block sticky, unblock→ready, unblock→claim→reclaim→ready)

[alt-glitch]

This was generated by AI during triage.

Related: #34735 covers the initial-blocked event. This PR also adds the audited body-update operation and typed-gate/reclaim/legacy-repair behavior, so it is not a duplicate; maintainers should choose the desired sticky-gate scope.

[teknium1]

Thanks for the focused initial-blocked and audited body-update work. The initial-status premise is real on current main: create_task() records only created for an initially blocked task (hermes_cli/kanban_db.py:3254-3273), while _has_sticky_block() only recognizes blocked/unblocked events (hermes_cli/kanban_db.py:4126-4132).

Problems

• hermes_cli/kanban_db.py:4253 conflates historical block_kind with an active block. unblock_task() intentionally preserves that field (hermes_cli/kanban_db.py:5942-5951) but sends tasks with unfinished parents to todo; the new early continue prevents their normal later promotion.
• hermes_cli/kanban_db.py:4708 has the same conflation. A task explicitly unblocked, claimed, then manually reclaimed becomes blocked again merely because its historical block_kind remains. Current reclaim semantics are explicitly reset-to-ready (hermes_cli/kanban_db.py:4607-4616).

Suggested changes

• Limit the sticky fix to emitting the initial blocked event, or introduce separate active-gate state that unblock_task() clears while retaining loop history.
• Add the unblock/parent-completion and unblock/claim/reclaim regressions; document update-body in website/docs/reference/cli-commands.md.

Automated hermes-sweeper review.

[teknium1]

block_kind is intentionally preserved after unblock_task() as loop-history (hermes_cli/kanban_db.py:5942-5951). An explicitly unblocked task with an unfinished parent is therefore todo plus needs_input, and this guard prevents it from ever becoming ready after the parent completes. Gate on current sticky state, or store a separate active-gate marker that unblock clears.

[teknium1]

This treats retained loop-history as a current gate. After initial_status='blocked' -> unblock -> claim, block_kind remains needs_input by design, so a later operator reclaim changes an explicitly released task back to blocked. That contradicts reclaim's current reset-to-ready behavior; do not use historical block_kind alone here.

[Jeffgithub0029]

Thanks for the triage note — acting on the scope guidance.

Converged per your suggestion: this PR is now a deliberately minimal sticky-initial-block fix only. It records a typed blocked event (kind: needs_input) in create_task when initial_status='blocked', so _has_sticky_block fires and recompute_ready cannot silently promote a parked card. No block_kind mutation, no recompute_ready / reclaim_task changes — which avoids the unblock/parent-completion and unblock/claim/reclaim conflation issues the sweeper review flagged.

The audited update-body operation is now its own PR: #76765 (focused, with docs in cli-commands.md).

Reclaim/legacy-repair/typed-gate behavior dropped from this branch entirely. Since the sticky-gate space already has several open PRs (#34735, #71977, #35832, #46565, #71147, #69679, #34756), maintainers deciding the desired sticky-gate scope can use this PR as the minimal reference implementation; if #34735 or another is preferred, this one can be closed.

[Jeffgithub0029]

Closing this in favor of #34735, which already has maintainer attention (Kayhusk commented) and covers the same minimal fix (emit a blocked event at create_task so initial_status='blocked' is sticky). My implementation here converged to the same narrow shape; keeping both open adds noise in a space that already has 8+ overlapping PRs. The audited update-body command that originally lived on this branch is now its own PR (#76765) — that's the part with no competitors. Thanks for the triage guidance.