Run one reconciler pass of the standing milestone-loop — the turn procedure each `/work-on-milestone` firing invokes. Use when a loop firing (or the owner directly) needs to move the focused milestone one bounded step toward "merged, or waiting on the owner or on blockers." Checks the kill switch, probes rig capability, launches the milestone-loop workflow, and surfaces anything needing the owner. To START the loop on a milestone rather than run a single pass, use work-on-milestone.
Drive a whole milestone to done with the standing loop — resolve the milestone, set the goal, and register the recurring reconciler that runs passes until every issue is merged or parked. Use when the owner says "work on <milestone>", "start the loop on <milestone>", "close out <milestone>", or wants the loop running without hand-typing a /loop invocation. Also the place to stop or re-target a running milestone driver.
Take one ticket end-to-end in the current session with the owner present — the interactive counterpart to the standing loop. Use when they say "work on issue N", "let's do this ticket", "pick up X and I'll answer questions as you go", or want to drive a single issue to a PR now. Same workflow, same composed stages, same verifier as the loop — but questions come inline instead of parking.
Render the milestone-loop's current picture into one status board — what it's acting on, what's waiting on the owner (oldest first), what it's watching, recent outcomes, and spend. Use when asked "what's the loop doing", "loop status", "what's waiting on me", or before deciding whether to nudge or pause the loop. Read-only — it reports, it never acts.
Architecture-first entry point — recon the current code with the relevant domain experts, then produce a design brief for the owner (mermaid diagram, trade-offs, decisions taken, and an explicit decisions-for-owner list) posted to the issue. Use before building anything engine-zone, when a feature needs a shape decided, or when the owner asks to "design X first" or "draft the approach for this issue". Nothing builds until they approve in a comment.
Write a brand-new processor from source and submit it into a running StreamLib node as a fresh instance, optionally wiring its ports to existing processors in one transactional step, then confirm it landed and is producing. Use when adding a new stage to a live pipeline during development — a new filter, sink, or generator — without restarting the app. Wraps `streamlib submit` then `graph` + `tap` to confirm.
Freeze a verifiable record of a running StreamLib node — a live graph snapshot, N tapped bags from one or more channels on disk, and a bounded log excerpt — into a directory for a PR, an issue, or a before/after comparison. Use when you need durable proof that a pipeline is running and producing, or to capture the "before" and "after" around a hot-swap. Wraps `streamlib graph`, `streamlib tap`, and `streamlib logs` with shell redirection.
Enumerate the live StreamLib runtimes reachable over their control plane so you can pick a target before running any other control verb. Use when you need to know which running nodes exist — after `cargo run`-ing an example app in a worktree, when a control verb errors that zero or more-than-one node is live, or any time you must resolve a `runtime_id` / `control_url` to drive. Wraps `streamlib nodes` only.