dsh-task-queue

In a DSH and Hermes collaboration system, multiple governance actions such as approval, review, and reset often compete for the same agent execution resources. Without a unified queue, concurrent writes, task starvation, and state drift are almost inevitable. dsh-task-queue fills exactly this coordination gap: it designates queue.json as the single source of truth that every plugin agrees on, giving each action a well-defined position in the pipeline and a deterministic dequeue order.

The core mechanism revolves around a three-tier priority ladder — reset (highest) > approve > review. A lease-and-claim model guarantees that only one consumer processes any given task at a time; a priority-aging scheme ensures lower-tier tasks are never starved indefinitely; and the .hermes-busy atomic mutex lock is shared across all tiers to eliminate race conditions. On the Hermes side, a per-minute cron job combined with a monitor gate drives dequeue and execution, routing results back by sessionId with fail-closed semantics throughout.

If you are maintaining a DSH governance workflow, using Hermes as the execution backend, and have multiple application-layer plugins — approval flows, review pipelines, agent resets — that must be serialized fairly and in order, dsh-task-queue is the queue hub you wire them into. It strips concurrency control, priority scheduling, and failure containment out of business logic so your plugins can focus on what they do best.