hermes - 💡(How to fix) Fix Question: is there an on_kanban_tick (or equivalent) hook event?

What I'm trying to do I'm building a dispatcher cooperation hook that needs to run on every Kanban dispatcher tick, not on session lifecycle or tool-call boundaries. The hook scans a subset of cards (Phase 9.6 ci-fix cards in a watching lane), queries external state (gh pr checks), and promotes cards from watching → ready when external conditions change. The shape of the work is "give me a periodic invocation that fires whenever the dispatcher would otherwise be idle," not "give me a hook on something an LLM session did." What I checked in the existing docs The Hermes Bootstrap Protocol enumerates these hook events:

pre_llm_call pre_tool_call post_tool_call on_session_start on_session_end subagent_stop

All six are session-scoped or tool-call-scoped. None fires on a "dispatcher woke up and checked the board" boundary, which is the trigger I need. Three possibilities I see I'd like to know which is correct so I can finish the Phase 9.6 dispatcher hook. (a) There's an event I missed. Hermes exposes a dispatcher-tick event under a name I haven't found. Pointing me at it would unblock me immediately. (b) The event doesn't exist but should. The dispatcher already has a tick loop (driven by kanban.dispatch_interval_seconds); exposing a hook point on each tick would be a small surface change. If this is the right path, I'm happy to file a feature request and contribute the implementation. (c) The right pattern isn't a hook — it's a scripted-dispatch supplement. Provisioning §6.2.b documents a scripted dispatch path (cron / systemd timer / launchd plist that runs hermes kanban dispatch --max N periodically). I could write a separate periodic job that does the watching-lane scan and card-promotion work, independent of the gateway-embedded dispatcher's tick loop. This works but means two periodic processes are running against the same board — fine if they don't claim-race, but worth confirming. Why I think (b) might be the right answer The on_kanban_tick event would unlock a useful general pattern: "external-condition-driven card lifecycle." My case is CI status, but I can imagine others: cards that wait on a queue depth, a downstream service health check, a timer expiry. Each of these is a card whose ready transition depends on external state polled per dispatcher tick. Today the only way to express this is to spawn a worker that does the polling, which:

Burns priming cost per poll iteration (each fresh worker re-loads the spec, the comment thread, etc.) Counts against max_concurrent for work that's not really concurrent Makes the dispatcher's run-history view noisy (every poll is a "run" in the log)

An on_kanban_tick hook runs as a dispatcher-side shell script — no LLM invocation, no priming cost, no slot consumption — and the worker only spawns when the card has actually moved to ready. That's the right cost shape for this pattern. What I'd want from on_kanban_tick if it does exist (or should)

Trigger: fires once per dispatcher tick, regardless of whether any worker is spawned that tick. Input: JSON event on stdin, fields at least {board: <slug>, tick_iso: <timestamp>}. The board scope is essential — without it, a hook installed on board A would run for every tick on every board on the system. Output: standard hook output ({} for no-op, {"context": "..."} for context injection on the next worker spawn). Side effects via hermes CLI from inside the hook are the primary value. Timeout: generous (~30s) — gh calls aren't fast, and the alternative (blocking the dispatcher tick on a slow external service) is worse than missing a tick. Failure semantics: matches existing hooks. Non-zero exit logged, dispatcher tick continues. No retries.

If on_kanban_tick already exists with a different name or signature, the difference is fixable in my hook — I just need to know what to bind to. Workaround if neither (a) nor (b) If the answer is (c) — a scripted-dispatch supplement is the right pattern — I'd want to confirm:

Running a separate periodic process (cron / systemd timer) alongside the gateway-embedded dispatcher doesn't cause claim races on cards. The scripted process can call hermes kanban move / hermes kanban complete / hermes kanban comment without holding any dispatcher lock. The run-history view treats the scripted process's actions distinctly from worker actions (the audit trail wants to show "dispatcher hook moved card to ready" separately from "worker completed card").

If those three are clean, I can implement Phase 9.6 against scripted-dispatch supplements instead of a hook event, and revisit the hook event design later. Where this is coming from This is part of Hermes Bootstrap Protocol Phase 9.6 — a CI auto-fix card kind that watches PRs opened by the pr-author skill and runs bounded auto-fix attempts. The full design is in the protocol layer; this issue is the upstream half about which Hermes primitive to bind to. Happy to share the protocol-layer doc if it helps clarify the use case. Tagging this as a question rather than a feature request Posting as question first because if (a) is the answer I haven't surfaced an issue at all. If maintainer responses point to (b) or (c), I'm happy to convert to a feature request or close and proceed with the workaround.