Skip to content

Miwarang Senpi Delegate v0.2.0

Latest

Choose a tag to compare

@itokun99 itokun99 released this 20 Oct 11:09

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 /miwarang command 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 as omo-tmux-dag.
  • New top-level dagWatch config key: false disables the bridge; { category, pollSeconds, timeoutMinutes } overrides the watcher's category route (default quick) and its bounds (default 30 s poll, 60 min watch).
  • The miwarang_delegate background 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_wait or miwarang_cancel reports it.

Verification

  • bun test: 135 → 162 passing tests, 0 failures across 6 files (test/watch.test.js added, plus new dag watch bridge and progress surfaces suites).
  • 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 showed miwarang: 1 active · run_22721626 0s on start, cleared itself after the run record flipped to completed, and /miwarang reported 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", …) → kernel tool.workflow({ action: "start" }), returning a dag_<uuid> run id). A direct ctx.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, and dagWatch: false each keep the delegation working (details.dagWatch carries { error } or is absent).
  • config.example.json validates against validateConfig with the new dagWatch key present.