/delegate-issue

name: delegate-issue
description: Delegate well-scoped coding issues to a SWE-AF node as a cheap sub-harness via implement_issue, then collect and merge the returned branches. Use when the user asks to offload, delegate, or fan out scoped tasks to SWE-AF / swe-planner / swe-fast, or when several independent, fully-specified changes could run in parallel without burning main-harness tokens.

Delegate scoped issues to SWE-AF

You are the main harness. SWE-AF is the sub-harness: it implements one fully-scoped issue per call on an isolated branch, using cheap models, and hands the branch back. You keep planning, merging, review, and CI.

When to delegate (and when not to)

Delegate an issue only when ALL of these hold:

• The change is **fully specified**: you can name the files, the behavior, and

the acceptance criteria without the sub-harness needing to plan anything.

• It is **independent** of your other in-flight edits (no shared files with

another delegation or with your own uncommitted work).

• The repo is reachable by the SWE-AF node (same machine or shared volume) and

has at least one commit.

Do NOT delegate: vague feature requests (use `swe-planner.build` instead), changes to files you are editing yourself right now, or anything whose spec you'd have to guess. Garbage spec in → garbage branch out.

Preflight (once per session)

# Control plane up and the node registered?
curl -s ${AGENTFIELD_SERVER:-http://localhost:8080}/api/v1/nodes | grep -o '"swe-[a-z-]*"' | sort -u

Pick the node (`swe-planner`, `swe-fast`, or the `-go` twins — the `implement_issue` surface is identical). If an `X-API-Key` is configured for the control plane, add `-H "X-API-Key: $AGENTFIELD_API_KEY"` to every curl.

Compose the issue

Write the spec from YOUR context — the whole point is that the sub-harness skips planning. Required: `title`, `description`. Strongly recommended: `acceptance_criteria` (verifier checks these), `files_to_modify` / `files_to_create`, `testing_strategy`. Set `needs_deeper_qa: true` only for risky/interface-heavy changes (doubles the review cost per iteration).

Commit (or at least be aware of) your local state first: the issue branch is created from the **committed** base, so your uncommitted edits are invisible to it.

Fire the delegation (async, never sync)

curl -s -X POST ${AGENTFIELD_SERVER:-http://localhost:8080}/api/v1/execute/async/swe-planner.implement_issue \
  -H "Content-Type: application/json" \
  -d @issue.json

with `issue.json` shaped like:

{
  "input": {
    "issue": {
      "title": "...",
      "description": "...",
      "acceptance_criteria": ["..."],
      "files_to_modify": ["..."],
      "testing_strategy": "..."
    },
    "repo_path": "/abs/path/to/checkout",
    "base_branch": "main",
    "config": { "models": { "default": "haiku" } }
  }
}

Capture `execution_id` from the 202 response. Track every in-flight delegation in your todo list (one item per execution_id).

**Cap fan-out at 3 concurrent delegations per repo** unless the user explicitly asks for more — each one is a paid multi-agent run, and an unbounded loop of delegations is a surprise bill. Never re-fire a delegation just because it is slow; poll it.

Track progress

# Terminal status + result
curl -s $SERVER/api/v1/executions/<execution_id>
# Live agent notes (what the coder/reviewer are doing)
curl -s $SERVER/api/v1/executions/<execution_id>/notes

Poll on a backoff (30–60s is plenty; a typical issue lands in 10–30 min). Batch-check several: `POST /api/v1/executions/batch-status` with `{"execution_ids": [...]}`.

Collect the result

The execution's `result` is an IssueBuildResult:

• `success: true` → `branch` holds the implementation

(`issue/<build_id>-<slug>`). Review the diff yourself (`git diff main...<branch>`), run YOUR test gate, then merge: `git merge --no-ff <branch>` (or cherry-pick), and delete the branch.

• `success: false` with a `branch` → partial work was salvaged. Triage:

read `verification` / `debt_items` / `error_message`, then either fix forward on the branch yourself, re-delegate with a sharpened spec, or drop the branch (`git branch -D`).

• `success: false` with `branch: ""` → nothing usable was produced; the

sub-harness already cleaned up. Sharpen the spec before retrying — do not retry verbatim.

After merging all accepted branches, run the project's full test suite once yourself before reporting done. The sub-harness verifier is a per-issue check, not your integration gate.