openclaw - 💡(How to fix) Fix Add native control-plane task starter for repo-backed ACP workflows [1 participants]

Problem

DishPics now has a documented control-plane workflow for implementation tasks, but the startup path is still split awkwardly across:

• repo-local shell prep (.claw/scripts/start-control-plane-task.sh)
• manual/OpenClaw-tool ACP session spawn
• manual registry update with returned session id

That means startup is still partly procedural and partly memory-dependent.

We attempted to make the shell wrapper also spawn ACP directly, but that was the wrong shape. ACP spawn is already a first-class OpenClaw capability and should not be reimplemented ad hoc in shell/client glue.

Desired outcome

Provide a native OpenClaw task starter path that can perform all of these as one canonical operation:

1. prepare repo task state
2. spawn ACP session in the correct worktree
3. record the session id in the repo task registry
4. return/report canonical startup facts

Proposed shape

Conceptual command/API:

openclaw tasks start --repo DishPics --task-id 36 --title "Fix history identity and persistence contract" --type bugfix

or an equivalent tool/helper callable from the assistant layer.

Required behavior

Phase A — prepare repo state

• create/update structured task spec
• create canonical branch (e.g. baomeow/[taskid] unless overridden)
• create dedicated worktree
• render task prompt into that worktree

Phase B — spawn ACP session natively

• call the same ACP/runtime path used by sessions_spawn(runtime="acp")
• pass the task prompt and worktree cwd
• return childSessionKey / runId

Phase C — record session

• update repo task registry with sessionId
• mark session reachable
• append startup notes
• report startup facts in structured form

Structured output contract

A successfully started task should return at least:

• taskId
• branch
• worktreePath
• promptPath
• sessionId
• optional runId
• status

Important guardrail

A task should not be considered truly started unless sessionId exists.

Current repo/task flows often treat worktree creation as “running”, but operationally that is incomplete. We either need:

• a distinct prepared status, or
• a strict invariant that running with sessionId = null is not actually started.

Why this matters

Without a native starter, assistants can drift into:

• direct agent runs without worktrees
• worktrees without tracked sessions
• inconsistent startup reporting
• partial adherence to the control plane

The native starter removes that ambiguity and turns startup into one enforceable path.

Suggested implementation direction

Short term:

• provide a helper/command that bridges repo prep + native ACP spawn + registry update

Long term:

• make it reusable for other repos with repo-local orchestration layers, not just DishPics

Reference

Design note written here:

• /home/jfranz/.openclaw/workspace/products/dishpics/control-plane-starter-design.md