fix(kanban): classify zero-turn clean exits as route failures and reap before classifying

[haumanto]

What breaks: a worker that exits rc=0 having made no tool call at all, the shape a routing or credential failure takes before the model ever runs, is booked as a protocol violation and counted against the protocol-violation streak. With the common per-task max_retries=1 that single misclassification blocks the card.

Repro: a card whose worker dies with zero heartbeats is closed as crashed with pid <n> not alive and counted against _PROTOCOL_VIOLATION_FAILURE_LIMIT.

Fix, three parts: _classify_dead_worker takes the closing run's last heartbeat and elapsed time and classifies a clean exit with no heartbeat past the crash grace as route_failure; _reclaim_dead_workers reaps the zombie before classifying so a child exiting between the two calls is classified from its real exit status; route failures do not consume the protocol-violation streak and carry their own budget of two trailing failures before the breaker trips.

Adjacent work: #107886 classifies 429/quota exits as capacity_failure in the same function. Ours is the zero-turn rc=0 case; the labels stay distinct and the ordering between the two branches is explicit.

Tests: five invariant tests, each failing on the base commit, including the ordering classification, streak non-consumption, and the breaker payload.

[gaoanze888]

The reap-before-classify ordering and separation from the protocol-violation streak are sensible, but the exact head 87f00c0d5820342710523b43a138b6b295ec28bc currently fails a required cross-platform test gate.

test_reap_ordering_classifies_real_exit_status_not_unknown unconditionally executes POSIX true and reads Linux-only /proc/<pid>/stat without a Linux-only marker. On macOS the focused run is 4 passed, 1 failed, because /proc is absent and the asserted zombie state remains None. Mark this test Linux-only under the repository convention, or replace the /proc dependency with a portable synchronization/exit-status fixture. git diff --check also reports a new blank line at EOF in the same test file.

Two contract gaps should be clarified and tested:

• Route failures use a fixed limit of two rather than the task's max_retries; therefore a task configured with max_retries=1 still gets two route attempts. If this independent budget is intentional, document the override explicitly and test it.
• Current tests inject a wait status; add a lightweight real worker/CLI path showing the key premise that a routing/credential failure exits rc=0 without a turn-start heartbeat.

Please also update the English/Chinese Kanban event documentation for the new public route_failure event and the fact that route failures do not reset/consume the protocol-violation streak. Ruff is clean.

[haumanto]

All four points are answered in three new commits on the branch: c73c55f860c, 05f17c2fd1a, ec6f603fff.

1. Linux-only marker. test_reap_ordering_classifies_real_exit_status_not_unknown now carries @pytest.mark.linux_only, matching the repository's own convention (I checked where the marker is registered and which existing tests use it before applying it). A macOS run is not possible in this environment, so that half of the fix rests on the marker rather than on an observed skip.
2. Blank line at EOF. The test file now ends with a single newline; git diff --check is clean.
3. Route-failure budget. Kept the fixed budget of two and made the override explicit in the source: a task's max_retries governs its own agent work, which says nothing about how many times to route, so a task configured with max_retries=1 still gets exactly two route attempts. test_route_failure_budget_ignores_task_max_retries pins that, with the reasoning in its docstring.
4. Real exit path. Added test_route_failure_classified_from_real_worker_exit, which spawns a genuine process instead of injecting a wait status and drives the module's own reap/classify path, so the rc=0-without-heartbeat premise is exercised end to end. No CLI harness was needed for it.

Each new test fails when its corresponding fix is reverted, and the focused selection is green (scripts/run_tests.sh tests/hermes_cli/test_kanban_core_functionality.py -k "route_failure or reap_ordering": 7 passed).

Thanks for the careful review. The Windows probe and process-identity points you raised on the respawn-guard PR are being handled in that branch separately.

[haumanto]

Docs ask is addressed in 0423fbd5d4281dd840e848e1a57c161554d3d5b4 (appended commit, no rebase): the English kanban reference and its Chinese translation now document the route-failure classification, its own budget of two route attempts independent of the task's max_retries, the gave_up payload fields route_failures and route_failure_limit, and that a route failure neither consumes nor resets the protocol-violation streak.

One accuracy note so the docs match the code: the marker is not a new event name in task_events. It is the run-metadata key route_failure: true carried by the crashed payload (exit_signal: "heartbeat_null", reap_status: "observed"), so the reference describes it on that row instead of adding a route_failure row that no event emits.

[haumanto]

Correction to my previous comment, and thank you for the phrasing that was right all along.

A route failure does emit its own task_events kind. _classify_dead_worker_exit builds the dead-worker record with event_kind="route_failure" and _append_event inserts that kind verbatim, so the run produces a route_failure event and no crashed event; its run outcome is still crashed. My earlier claim that no event of that name exists was wrong, and the docs had the marker attached to the wrong row.

Both the English reference and its Chinese translation are corrected in 76093f7a0f0a4909427f8a76d45b38c0226c4cab: a route_failure row now carries the payload the code actually emits (pid, claimer, exit_code, exit_signal, elapsed, route_failure, reap_status), the route_failure? / exit_signal? keys are gone from the crashed row, and the gave_up row keeps route_failures and route_failure_limit. The budget of two, its independence from the task's max_retries, and the fact that these runs neither consume nor reset the protocol-violation streak are unchanged.