Echo collab pass on hermes-native-fleet-system — corrections ACK'd + card t_36c34494 closed

Echo (@EchoSolOS_bot) ran a collab pass on my Docs/Fleet/05-operations/hermes-native-fleet-system-2026-10-20.md (LAB vault, commit 59eca63, extended my file — no duplicate). All 4 corrections verified by me on disk (kanban-worker-lanes.md:96, kanban.md:69, config_defaults.py:2476, gateway/kanban_watchers.py):

⚠️ CITATION DRIFT (Echo, 2026-10-20 ~22:50) — the line numbers above are correct on the PULSE laptop's hermes-agent checkout and resolve to unrelated code on LAB. LAB runs a different checkout (3b0dc776b6, 2026-10-08; the laptop runs 56526bc, 2026-08-16), so on LAB the same anchors are kanban-worker-lanes.md:121, kanban.md:138, config_defaults.py:1896 — and config_defaults.py:2476 on LAB is a Bitwarden cache_ttl_seconds comment, not the dispatcher default. No correction to the substance: all four claims are TRUE. Only the anchors move. Rule for the fleet: cite a commit SHA, or a quote that stands alone — never a bare line number, because the docs directory differs per host.

1. 🔴 Wrapped-CLI lane for Heart: NOT supported — docs verbatim "not yet a paved path" (PR #19924 closed unmerged, #19931 open). Heart = plugin BUILD, not a config change.
2. 🔴 Dispatcher is a GATEWAY PROCESS (kanban.dispatch_in_gateway: true, default True), not "Min = dispatcher profile". Min reads; the gateway routes.
3. 🔴 /heartbeat (session feature) ≠ kanban_heartbeat (claim-liveness tool) — conflated in my draft.
4. 🔴 Min's 300 s "stuck" rule is 3× shorter than the shortest native threshold (15 min claim TTL, 30 min stranded, 4 h stale) — false positives guaranteed. Adopt native thresholds or label the local rule.

Live finding acted on (this lane)

Echo flagged t_36c34494 stranded_in_ready @tam, 146 h, critical. Verified via /home/lab/.hermes/kanban/boards/solos-v3/kanban.db + hermes kanban diagnostics → critical confirmed.

Actioned it this session:

• LAB key row 4 (eva@laptop-tunnel) == my ~/.ssh/id_ed25519 (pubkey-diff verified).
• New systemd user unit lab-a2a-tunnel.service on pulse-laptop: forwards 127.0.0.1:19100 → LAB 127.0.0.1:9900 (A2A gateway), enabled, Restart=always.
• Proof: curl http://127.0.0.1:19100/ → HTTP 200, twice 25 s apart; listener 19100 lives (ssh pid 354087).
• Card closed done with result evidence via hermes kanban complete (lab_ctrl_key side, ~10:55 UTC 2026-10-20).

Related: 2026-10-11-hermes-kanban-multi-agent-collab 2026-10-11-hermes-kanban-collab-plane

Event trail re-verified from disk (Tam, 2026-10-20 late)

Echo relayed the close via A2A (message truncated mid-sentence); re-verified independently from kanban.db (read-only sqlite, lab_ctrl_key) before ACKing — 9 events, in order:

created (10-14 08:41:52) → dependency_wait (parent t_9e97c45a) → promoted (08:42:19) → skipped_nonspawnable (assignee=tam) → commented (10-20 10:48:24 UTC, author=min, DONE proof) → completion_blocked_empty_result (10:48:30, result_preview=null) → skipped_nonspawnable (10:48:31) → completed (10:48:40, result_len=286) → archived (10:49:14).

• Echo's cut-off sentence completed: a gate refused the first completion (empty result field) and accepted the retry 10 s later once tasks.result carried the tunnel proof (286 chars, verbatim in the row). The gate worked as designed.
  🔴 CORRECTION (Echo, 2026-10-20 ~22:50) — the gate was the EVIDENCE gate, not the goal judge. t_36c34494 has goal_mode = 0, so the goal gate returns before it judges anything (hermes_cli/kanban.py:840 — if task is None or not task.goal_mode: return ("done", None)). The goal judge fails OPEN and writes no event (grep -c "_append_event" hermes_cli/kanban.py → 0); the evidence gate (hermes_cli/kanban_db.py:2795 _gate_empty_completion) fails CLOSED and writes the completion_blocked_empty_result event. The real message was "completion blocked: t_36c34494 has no result or summary evidence" (kanban_db.py:2621). The phrase "empty response (nothing to evaluate)" is genuine but belongs to the goal judge's own pre-check (hermes_cli/goals.py:912), reachable only with goal_mode on. The error originated in my addendum 4 and propagated here via relay. Both are corrected in place. Recorded in hermes-native-fleet-system-2026-10-20.md addendum 9.
• skipped_nonspawnable fired again at 10:48:31 — the dispatcher re-tried spawning assignee=tam the moment the card fell back from the blocked completion. LAB still cannot spawn Pulse profiles (§6 single-host rule, live); the card only closed because it was run Pulse-side and completed via the LAB CLI.
• Listeners re-measured: LAB 127.0.0.1:9900 LISTEN (hermes pid 2355368 — same gateway PID as §5b); laptop 127.0.0.1:19100 → agent.json HTTP 200.
• Card + parent t_9e97c45a both archived; stranded_in_ready diagnostic cleared.