Skip to main content
<Monitor> is an autonomous sibling workflow, not the interactive oneshot monitor UI. For live transcript, steer, restart, and attachment-scoped narration, see Watching and steering a oneshot.

Notes

Each beat is a durable <Timer>, one classifier <Task>, and a <DecisionTable> that routes the classified condition to a handler. Beat 0 skips the timer so the monitor looks immediately. The loop exits when the watched run reaches a terminal status, or after maxChecks beats, which is not a failure. <DecisionTable> is the router rather than <ClassifyAndRoute> because a monitor has exactly one subject and needs first-match, one-handler-wins semantics. <ClassifyAndRoute> classifies many items and fans every category out in <Parallel>, which is a different problem. The healthOutput schema must carry condition, runStatus, and ownerActive; targetNodeId, evidence, and summary are read when present. ownerActive must only be true when the recorded runtime-owner pid is live and its heartbeat is fresh. It is targetNodeId rather than nodeId because nodeId, runId, and iteration are reserved output columns. Ownerless stalled and wedged-node runs heal without a human by default. When ownerActive is true, both escalate instead of racing the live owner. Every other condition escalates through a durable human request. Add a condition to autoHeal to grant broader authority: adding runaway-loop swaps its handler from “escalate” to “cancel the run”, which is destructive and therefore never a default. handlers replaces any element outright, and mapping one to null makes that condition a no-op. healthy contributes no rule to the table at all, so a healthy run routes to nothing. Observing and continuing to watch is the correct outcome, not a gap. The prompt shipped with the component tells the agent what healthy and unhealthy look like, what evidence to gather before acting, what it may do autonomously, and when it must escalate instead of guessing. It also binds the agent to reading run state through smthrs/gateway-client or the public CLI, never the store. It is available as monitorPrompt() and as an MDX prompt component shipped beside the source, so a monitor file can import and extend it. Most monitors are declared as files rather than composed by hand. See Monitor workflows for the .smithers/monitor/<workflowId>.tsx layout, auto-discovery, the --monitor and --no-monitor flags, and the run lifecycle.

Source

The <Monitor> implementation and the files it imports, straight from the package source. This section is generated; edit the source, not this block.