ZeroClaw
ZeroClaw adds DAG execution before it adds a stop button
ZeroClaw proposes sequential and parallel DAG plan execution while operators report that running SOP jobs have no cancellation path and a global concurrency ceiling silently overrides per-SOP limits. The cluster exposes orchestration ambition arriving ahead of control-plane clarity.
zeroclaw-labs/zeroclaw PR #9554 is the inspected primary source: “feat(tools): add dag_plan_execute tool for sequential and parallel planning.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- zeroclaw-labs/zeroclaw PR #9554 was created 2026-07-30T05:55:42Z and was open at inspection; its title is “feat(tools): add dag_plan_execute tool for sequential and parallel planning.” - zeroclaw-labs/zeroclaw issue #9425 was created 2026-07-27T03:28:00Z and was open at inspection; its title is “[Bug]: Running SOP jobs have no operator cancellation path.” - zeroclaw-labs/zeroclaw issue #9902 was created 2026-08-10T21:56:14Z and was open at inspection; its title is “[Bug]: sop.max_concurrent_total silently overrides per-SOP max_concurrent, is undocumented, and the capacity refusal never names it.” - The repository reported 32552 stars, 733 open issues, default branch master, and last push 2026-08-10T21:55:28Z. - The latest tagged-release baseline checked was v0.8.4 published 2026-08-02T21:00:00Z.
What changed
zeroclaw-labs/zeroclaw PR #9554 reports: Summary **What changed and why:** Add DagPlanExecuteTool enabling agents to create and execute multi-step task plans modeled as DAGs. Supports sequential ordering when tasks depend on each other, parallel execution where the dependency graph allows, template-based task definitions with variable substitution ($prev.task.output), cycle detection with clear error messages, and configurable max node limits. **How:** A new tool in zeroclaw-tools that accepts a JSON plan definition with nodes (tasks), dependencies, and optional templates. Uses JoinSet for parallel task execution and maintains a RwLock >> reference to resolve tool names at execution time. **Scope boundary:** Tool implementation only. Does not modify the agent loop, orchestrator, or tool registration system. **Blast radius:** Additive only — new file in zeroclaw-tools plus module registration in lib.rs. Testing Tool unit tests covering: sequential execution, parallel execution, template variable substitution, cycle detection, unknown tool handling, max node overflow. Security & Privacy Impact New permissions/capabilities: No. New external network calls: No. Secrets handling changed: No. Compatibility Backward compatible: **Yes** — additive feature. Rust/MSRV changed: No.
zeroclaw-labs/zeroclaw issue #9425 reports: Affected component web dashboard Severity S1 - workflow blocked Current behavior The web dashboard can list running SOP jobs and open their live run detail/overlay, but it provides no Stop or Cancel action for an actively running SOP. Approve and Deny are only shown while a run is waiting at an approval gate or paused checkpoint. They do not provide an operator control for a run whose status is running. Restarting the daemon is not a workaround: when SOP run persistence is enabled, the active run is rehydrated after restart and starts/resumes again. This leaves an operator with no safe way through the UI to terminate a runaway, stuck, or no-longer-wanted SOP job. The runtime already has an engine-level SopEngine::cancel_run(run_id) primitive, but the active-run dashboard/RPC/gateway surface does not expose a general authenticated cancellation operation. Expected behavior The Runs list and run-detail UI should offer a Stop action for every non-terminal SOP run where cancellation is valid. Stopping a run should: call an authenticated SOP cancellation endpoint keyed by the exact run ID; transition and durably
zeroclaw-labs/zeroclaw issue #9902 reports: Affected component runtime/daemon Severity S2 - degraded behavior Current behavior sop.max_concurrent_total (default **4**) caps every SOP, but it is effectively undiscoverable: it appears **nowhere in the docs book** (rg max_concurrent_total docs/ -> no hits), while the per-SOP max_concurrent is documented in sop/syntax.md with its own table row; it is **not returned by /api/sops**, which does return per-SOP max_concurrent, so the dashboard shows the number that is not binding; zeroclaw sop show prints Max concurrent: 16 — the SOP's declared value — while the engine admits 4; zeroclaw config set sop.max_concurrent_total returns Error: Unknown property, so the documented way to set config does not reach it (hand-editing config.toml does work); the capacity refusal, deferred_at_capacity, does not say **which** limit was hit or what its value is, even though the engine has both numbers at the point of refusal (engine.rs passes self.config.max_concurrent_total into the admission check). Expected behavior Any one of these would have prevented hours of misdiagnosis: document max_concurrent_total alongside max_concurrent, noting that it is a global ceiling the per-SOP value cannot exceed; include it in
Why it matters
Parallel execution multiplies the cost of missing cancellation and opaque capacity rules. A planner that can fan out work must also explain why work cannot start and give an operator a bounded way to stop it. The operator test is whether visible output, retained state and authority still describe the same event after retries, background work or restart.
Current
The primary record was open when captured on 2026-08-11. The tagged-release baseline was v0.8.4 published 2026-08-02T21:00:00Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/zeroclaw-labs/zeroclaw/pull/9554. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/issues/9425 and https://github.com/zeroclaw-labs/zeroclaw/issues/9902. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Ship cancellation and named capacity diagnostics with DAG execution, persist run ownership, and make global versus per-plan limits visible before dispatch. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.