Skip to main content

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 and runStatus; targetNodeId, evidence, and summary are read when present. It is targetNodeId rather than nodeId because nodeId, runId, and iteration are reserved output columns. Only stalled and wedged-node heal without a human by default, because resuming a run and retrying a node are both idempotent and reversible. 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 smithers-orchestrator/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.