streamlib

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.

Resolve exactly one running StreamLib node and health-check it with a live `graph` round-trip, then pin its `--url` / `--node` so every following control verb targets the same node. Use at the start of a session against a running app — after `discover-running-nodes`, or whenever you are about to inspect, tap, submit, replace, connect, or capture and need a confirmed target locked in. Wraps `streamlib nodes` then `streamlib graph`.

Swap an existing processor's source registration in a running StreamLib node without restarting the app, rewire ports if the port shape changed, and confirm the new behavior on live data. Use when you have edited a processor's source and want the change reflected in a running pipeline during development. Wraps `streamlib replace` (type-level), with `submit` / `connect` / `remove` as needed, then `graph` + `tap` to confirm.

Dump a running StreamLib node's live processor graph — processors, ports, links, channel names, states, and metrics — as JSON, to use as ground truth before mutating or tapping it. Use when you need the current topology of a running app: to find a channel name for `tap-live-channel`, to learn the exact port names before a `connect`, to confirm a `submit`/`replace` landed, or to diff before/after a hot-swap. Wraps `streamlib graph`.

Attach a read-only tap to one named channel of a running StreamLib node and collect a bounded sample of raw bags to confirm data is actually flowing. Use to answer "are frames/samples really moving through this link?" — after inspecting the graph, to verify a `submit`/`connect` produced live output, or to spot-check behavior before and after a `hot-swap-live-processor`. Wraps `streamlib tap`.

Stop a running StreamLib node cleanly by signaling its host process, then confirm its `runtime_id` is gone from the registry so the worktree's camera/GPU/port claim is released. Use when done driving a node — to free a `/dev/videoN` camera for another consumer, release the GPU, or clear a control port before starting a fresh run. Wraps `streamlib nodes` (to read the pid, then to confirm removal) plus an OS signal to the process — there is no `streamlib stop` verb.

The live end-to-end verification for changes that touch GPU / camera / display / codec. Use when a change needs a real pipeline run (a plain Bash call can't — the rig-brake blocks it), when the owner asks to verify a change on the rig, or when a PR claims E2E evidence that needs auditing. Primary LOOP-RUN mode — the loop runs the pipeline itself via the dangerouslyDisableSandbox bypass, captures the window, and audits it (log gates, PNG content, PSNR); falls back to the owner-terminal command-block handshake only when the rig is unavailable.

File a well-shaped GitHub issue from a short intent — pick the right form (feature / bug / research), fill its sections, infer kind/zone/milestone, and set native dependency edges. Use when the owner says "file this", "open an issue for X", "log that bug", or when discussion surfaces a trackable task. Never files an umbrella issue — decomposes into self-contained issues with real blocked-by edges.

Capture a verification video from the vivid virtual camera through the streamlib processor pipeline and send to Telegram. Use when the user asks for a verification video, test video, or wants to confirm the encode pipeline works.