Repository navigation
Miwarang Senpi Delegate v0.2.0
Background delegations are now visible live: a session status line, a /miwarang view, and an automatic dag watch run rendered in /dag and any dag pane.
Included
- Session-visible progress for every background delegation: a TUI footer status line (
ctx.ui.setStatus) showing active runs with their runtime, plus the/miwarangcommand listing run id, state, elapsed time, target, and backend. - Automatic dag watch bridge: each background delegation starts a dag run whose single category-routed watcher node polls the delegated run (the command-backend run record, or
opencode api POST /api/experimental/session/<id>/wait) until it reaches a terminal state. The run renders in/dag, the TUI status widget, and dag panes such asomo-tmux-dag. - New top-level
dagWatchconfig key:falsedisables the bridge;{ category, pollSeconds, timeoutMinutes }overrides the watcher's category route (defaultquick) and its bounds (default 30 s poll, 60 min watch). - The
miwarang_delegatebackground result reports the watch run id (Dag watch: dag_…) or the reason the watch could not start; a bridge failure never fails the delegation. - The status line polls command run records every 15 seconds only while a command run is alive, then stops itself; opencode session state flips when
miwarang_waitormiwarang_cancelreports it.
Verification
bun test: 135 → 162 passing tests, 0 failures across 6 files (test/watch.test.jsadded, plus newdag watch bridgeandprogress surfacessuites).- On-disk proof (
.omo/evidence/2026-10-20-watch-bridge/proof-output.txt): real modules + real RunStore + the real 15 s poller — the status line showedmiwarang: 1 active · run_22721626 0son start, cleared itself after the run record flipped tocompleted, and/miwarangreported the completed run with target and backend. - Dag watch trigger verified live against the OMO dag engine: a watch run starts from inside the tool handler through the eval relay (
ctx.executeTool("eval", …)→ kerneltool.workflow({ action: "start" }), returning adag_<uuid>run id). A directctx.executeTool("workflow", …)is refused by the host ("Tool workflow not found"), which is why the bridge relays through eval. - Bridge degradation verified by tests: a host without
ctx.executeTool, a throwing relay, anddagWatch: falseeach keep the delegation working (details.dagWatchcarries{ error }or is absent). config.example.jsonvalidates againstvalidateConfigwith the newdagWatchkey present.