Task Delegation

---
name: task-delegation
description: Use when the operator explicitly asks for delegation, subagents, parallel agents, or when an AI Developer has independent T-task slices that can safely run in parallel. Do NOT use for simple edits, immediate blocking work, deploy commands, production side effects, or Product Owner code-writing.
source_inspiration: conceptual-only
license_status: clean-room-original
fusebase_flow_version: 3.1
risk_level: high
invocation: automatic
expected_outputs:
  - delegation brief in chat or handoff
  - subtask ownership table
  - integration / verification notes in gate or deploy report
related_workflows:
  - greenlight-implement.md
  - architect-escalation.md
  - verification-gate.md
hook_dependencies:
  - none
---

# Task Delegation

> **Style:** Mode-B-lite. Role-aware subtask delegation without weakening Fusebase Flow ownership, verification, or role boundaries.

## Purpose

Coordinate bounded work across multiple agents when the host environment supports subagents. Delegation is a speed tool, not an authority transfer: the self-attested main role remains accountable for scope, integration, verification, and final reporting.

## When to invoke

- Operator explicitly asks for delegation, subagents, parallel agents, or parallel work.
- AI Developer has independent implementation/test slices with disjoint write scopes.
- Product Owner needs read-only investigation, option comparison, or artifact review that can run in parallel.
- Architect escalation needs independent read-only probes over distinct subsystems.

## Do not invoke when

- The task is simple enough to finish directly.
- The next critical-path step depends on the subtask result; do that locally.
- The work requires operator interaction or a decision while the subagent is running.
- The work touches deploy commands, production side effects, approval artifacts, secrets, or live-user credentials.
- Product Owner would be delegating production code edits.
- Write scopes overlap or cannot be clearly owned.
- The host has no subagent/delegation tool; use normal `docs/tmp/handoff/` Flow instead.

## Required inputs

| Input | Where it lives | If missing |
|---|---|---|
| Self-attested role | current session | Stop; role defines allowed delegation |
| Source task / objective | `tasks.md`, `verification-gate.md`, handoff, or operator prompt | Stop; delegation needs bounded scope |
| Ownership boundary | file paths, modules, or read-only question | Keep work local until boundary is clear |
| Relevant artifacts | spec, decisions, tasks, gate, files, skills | Pass only what the subtask needs |
| CLI edition map, for Fusebase Apps work | `docs/fusebase-cli-edition.md` | Pass the relevant CLI provider skill names in the brief |
| Verification expectation | tests, checks, evidence, or requested answer shape | Add before delegating |
| Integration owner | main session | Main session always owns final integration |

## Procedure

### 1. Decide whether delegation is allowed

| Role | Allowed delegation | Forbidden delegation |
|---|---|---|
| Product Owner | Read-only repo investigation; compare options; review gate/deploy reports; draft doc-only alternatives | Production code edits; deploy execution; decision locking without operator |
| Architect escalation | Read-only subsystem probes; risk comparison; migration/constraint investigation | Production code edits; locked decisions |
| AI Developer | Bounded implementation/test slices under a T-task; focused bug investigation; non-overlapping test repair; test-only UI automation with clear evidence requirements | Deploy command; production side effects; overlapping writes; locked-decision changes |
| Deploy phase | Read-only failure triage while main session owns deploy state | Running deploy, rollback, secret handling, live smoke with credentials |

If the requested delegation is forbidden, refuse under `role-discipline` and offer a compliant alternative.

### 2. Keep the critical path local

Before spawning any subtask, name the immediate local action. Delegate only sidecar work that can progress while the main session continues non-overlapping work. Do not delegate the task that blocks your next action.

### 3. Write a delegation brief

Every delegated task gets a brief with:

| Field | Required content |
|---|---|
| Objective | one bounded outcome |
| Role boundary | read-only / code-edit / test-only |
| Ownership | exact files, modules, or question |
| Inputs | relevant artifacts and skill paths already loaded |
| Forbidden actions | no revert of others' edits; no deploy; no secrets; no broad cleanup |
| Domain skills | relevant CLI provider skill names from `docs/fusebase-cli-edition.md`, if the task touches Fusebase Apps runtime/domain behavior |
| Output format | the **Delegated return shape** (§5): verdict · SHAs · deltas · artifact pointers · residual risk, within the §5 **return budget** |
| Return budget | ≤80 lines **and** ≤6,000 characters (§5); name the sanctioned durable artifact any overflow goes to |
| Verification | expected tests/checks/evidence |

For code-edit subtasks, tell the worker: "You are not alone in the codebase. Do not revert or overwrite other concurrent edits; adapt to them."

**Turn-completion rule (every delegated session — binding):** a delegated session's deliverable must be COMPLETE within its turn. A delegated session cannot self-resume: when its turn ends, its context dies and nothing comes back. If the work requires waiting (ticks, agent runs, external processes), either poll with bounded sleeps INSIDE the turn until the result exists, or restructure the task as record-then-read (`flow-skills/smoke-testing` § Verification cost discipline). NEVER end the turn with "running in background — I'll resume when it completes" — you won't, and the orchestrator may trust the false completion.

**Progress ledger (every delegated session — binding):** write durable facts into the artifacts you already owe AS THEY OCCUR — the deploy hash the moment the deploy lands, probe/evidence rows as each one runs, the report skeleton first and rows as earned — never everything-at-the-end. Sessions die mid-work (provider limits, machine restarts); end-loaded reporting loses everything that wasn't yet written. **Successor contract:** a successor session resumes from records — read the ledger first, resume from the last durable fact, never redo verified steps; the delegating prompt for a successor states this explicitly (verify-from-records).

**Delegated-session liveness (zero-trust — binding on the DELEGATOR):** after dispatch, poll the delegate's PROGRESS on a fixed cadence (~60–90s) — new commits / advancing SHA, process activity, output-file byte growth — never passively await a completion ping. **A missing ping is evidence of neither completion nor death**; only observed progress (or its absence past the expected interval) decides. A delegate that dies on a **transient provider rate-limit is a dispatch failure, not the slice's verdict** — never record it as `FAILED-<reason>` or `BLOCKED-AT-<gate>`, because the work was never attempted. Re-dispatch a minimal **"try again"** to the SAME agent id (it keeps its context — do not respawn, do not re-send the brief); if it reports the limit again, retry only inside the **bounded delegate-retry envelope** — max **3** attempts / **5 minutes** total, labeled ~60s → ~90s → ~120s backoff, one progress read per interval (canonical: `flow-skills/liveness-discipline` § Bounded delegate-retry envelope) — then judge the work on what it produced. On exhaustion of either bound: STOP retrying, read the progress ledger, re-brief a successor with verify-from-records, or return `BLOCKED-AT-delegate-no-start` — never `FAILED-<reason>`. This is a discipline, not a gate — a hang is undetectable by construction, so Flow ships **no** blocking check and **no** "watchdog applied" attestation hook for it (FR-27). Protocol home: `flow-skills/liveness-discipline` § Zero-trust sub-agent liveness.

**Blocked-return rule:** when the remaining wait is UNBOUNDED (human approval gate, external event with no bounded ETA) — which neither in-turn polling nor record-then-read can span — the prescribed return is an explicit `BLOCKED-AT-<gate>` verdict + what cleared looks like + a pointer to where reality is recorded, so the orchestrator re-dispatches when the gate clears. Never fake-complete; never burn an open watch on an unbounded wait.

**Delegation contract push block** — inline this in every delegating prompt (push, not pull; workers do not load skills):

> Your deliverable must be COMPLETE within this turn — you cannot self-resume; poll in-turn (bounded) or read durable records, never end with "I'll resume when…". Write durable facts into your owed artifacts AS THEY OCCUR (skeleton first, rows as earned), never everything-at-the-end. If you hit an unbounded wait (human gate, no-ETA event), return `BLOCKED-AT-<gate>` + a pointer to where reality is recorded. Return per the delegated return shape: verdict · SHAs · deltas · artifact pointers — never re-paste a body an artifact already holds; state-change claims cite the ground-truth check performed (surface read + what it showed). **Chat-return budget: ≤80 lines and ≤6,000 characters. Longer → write a sanctioned durable artifact and return its path; commit only when the owning workflow requires it.**

**No inherited auto-load.** A delegated sub-agent session does **not** inherit the orchestrator's auto-loaded skills or the always-on FR-24 digest — `session_start` does not fire for it. The anti-reread exemption in `communication` / `role-discipline` therefore does not apply to a worker: it reads them (or the delegating prompt inlines what it needs). Never tell a worker "the skill is already loaded".

**Mandatory (code-writing / implementation slices):** the delegating prompt MUST inline the comment-policy **Delegation push block** from `flow-skills/comment-policy/SKILL.md` (push, not pull — sub-agents do not reliably auto-load skills, so don't just tell the worker to "load comment-policy"). Read-only / triage delegation is exempt (no code is written).

For frontend/design subtasks, add:

| Field | Required content |
|---|---|
| Product identity | who the UI is for and what problem it solves |
| Selected direction | decision/spec reference; no new direction after lock |
| Surface map | routes, screens, workflows, components, or prompts in scope |
| Data contract | entities, fields, states, API/helper names and signatures if known |
| Stack conventions | project-local frontend rules or skill/doc paths, if applicable |
| Stable selectors | selector strategy for interactive and meaningful dynamic elements |
| Trust-critical flows | save/send/auth/purchase/primary actions that must be real |
| Creative freedom boundary | what the worker may decide, and what is fixed by spec/decision |
| Forbidden inventions | no new routes, entities, modules, workflows, or fake primary flows beyond scope |

For test-only UI automation subtasks, add:

| Field | Required content |
|---|---|
| User flow | one journey only: route, start state, primary action, expected result |
| Viewport | desktop/mobile dimensions or "project default" |
| Locators | stable selectors or accessible locators to use; no brittle style/layout selectors |
| Test data | unique values to create, existing records allowed, cleanup expectations |
| Auth/session | synthetic account, test account, live-user workflow, or no-auth |
| Diagnostics | browser-visible evidence plus backend/log/API surface to inspect |
| Side effects | external services touched; sandbox/test-mode requirement or forbidden |
| Output | screenshots/log excerpts/evidence paths and PASS/FAIL rationale |

### 4. Parallelize only independent slices

Use parallel delegation only when all are true:

- Each subtask has a distinct write set or is read-only.
- Results can be integrated in any order.
- Failure of one subtask will not corrupt another subtask's work.
- The main session can do useful non-overlapping work while subtasks run.

### 5. Integrate, verify, and report

The main session must:

1. Read each returned result.
2. Inspect changed files or evidence before trusting the result.
3. Resolve conflicts without reverting unrelated user or subagent changes.
4. Run the relevant verification gate commands.
5. Record delegated work in the gate/deploy report when it affected implementation or evidence.

### Delegated return shape

For **delegated returns only** — gate reports keep PASS/FAIL; spec Status values remain DRAFT/DONE/BLOCKED (or ABORTED after an investigated no-work outcome), while scope-lock is recorded only as `decisions.md` **Lock status: LOCKED**, never `Status: LOCKED`.

| Field | Content |
|---|---|
| Verdict | `DONE` \| `BLOCKED-AT-<gate>` (+ what cleared looks like + state pointer) \| `FAILED-<reason>` |
| Commits | per-task SHAs (when code was written) |
| Deltas | counts only: tests before/after, files changed, findings N |
| Artifacts | POINTERS (paths) to reports/evidence — never re-paste a body an artifact already holds (FR-23/FR-26) |
| Residual risk | one line, or `None` |

**Return budget (binding):** ≤80 lines **and** ≤6,000 characters. Longer → write a sanctioned durable artifact and return its path; commit only when the owning workflow requires it. Both limits bind together — one 32,000-character line satisfies a line-only cap and still costs the orchestrator the full read. A read-only PO/Architect delegate and a concurrent investigation write to `docs/tmp/` (or the artifact the owning workflow names) without committing.

**Exempt from the budget (AC13):** the canonical **gate report** (`templates/gate-report.md`, contracted at `templates/handoff-implement.md` § Gate report contract) and the canonical **deploy report** (`templates/deploy-report.md`, contracted at `templates/handoff-deploy.md` § Deploy report contract). Evidence completeness outranks the cap at the gate — never truncate a gate or deploy report to fit.

**Ground-truth rule:** any claim that system state changed (launched / registered / deployed / completed) names the verification performed — the system surface read and what it showed. An attempted action or an observed look-alike artifact is not evidence; a false "launched" built from those can survive for hours.

Subagent output is evidence, not proof. Fusebase Flow success still requires the normal gate, smoke, security, and deploy checks.

## Output artifacts

| Artifact | Path or location | Mode |
|---|---|---|
| Delegation brief | chat or task-local handoff section | Mode A / Mode-B-lite |
| Ownership table | chat, `tasks.md`, or handoff | Mode B when persisted |
| Integration notes | gate report / deploy report | Mode B |
| Follow-up ticket | `docs/backlog/<slug>/README.md` | Mode B |

## Failure cases

| Failure mode | Detection | Response |
|---|---|---|
| Overlapping write scopes | same file/module assigned twice | Stop; merge subtasks or serialize them |
| Subtask blocks next action | main session waits immediately | Do it locally next time; delegation was misapplied |
| Product Owner delegated code edits | PO output includes production code patch | Reject result; route through AI Developer handoff |
| Worker changed out-of-scope files | changed files exceed ownership | Review manually; revert only the worker-owned out-of-scope changes if needed, never user changes |
| Worker skipped verification | no commands/evidence reported | Main session runs checks before claiming success |
| Test-only subtask uses vague browser plan | no route, locator, test data, auth plan, or expected result | Reject result; rerun with a complete test brief |
| Test subtask relies on shared state | asserts exact counts or empty state without creating/isolating data | Revise test data setup before accepting evidence |
| Frontend worker invents product scope | new route/entity/workflow not in brief | Reject or park as backlog; do not merge silently |
| Primary UI flow is fake | click/save/auth path has placeholder behavior | Mark incomplete; implement real behavior or revise scope |
| Deploy side effect delegated | subtask attempts deploy/rollback/approval artifact | Stop; deploy phase main session owns side effects |
| Delegate died on a transient provider limit | return names a rate/session limit, or the session ends with no progress | Not a verdict — re-dispatch "try again" to the same agent id; on a repeat limit retry only inside the bounded delegate-retry envelope (max 3 attempts / 5 min, then successor-or-`BLOCKED-AT-delegate-no-start`) |
| No completion ping | nothing came back by the expected interval | Poll progress (commits/process/file growth); absence of a ping is not a result either way |

## Escalation path

- If the work cannot be made independent, run it serially in the main session.
- If Product Owner needs implementation work, draft or amend the AI Developer handoff.
- If a delegated result contradicts locked decisions, stop and return to Product Owner.
- If repeated delegation failures occur, add a problem-catalog entry and tighten task boundaries.

## Anti-patterns

- Do not delegate because the task feels large; delegate because slices are independent.
- Do not delegate read-only searches that a quick `rg` can answer locally.
- Do not delegate vague work like "fix the feature" without file ownership.
- Do not delegate vague testing like "check the UI"; define the exact route, user flow, locators, data, auth plan, diagnostics, and evidence.
- Do not run multiple agents against the same files at the same time.
- Do not treat subagent output as final without main-session verification.
- Do not delegate frontend work with only a file path; include the product identity, surface map, data contract, selector strategy, stack conventions if applicable, and trust-critical flows.
- Do not delegate deploy commands, rollback, approval artifacts, or secret handling.
- Do not use popup / clickable menu tools to coordinate delegation decisions; ask in chat text per FR-19.
- Do not turn a delegate's provider-limit death into a task verdict, and do not respawn a fresh agent for it — re-dispatch "try again" to the same agent id, retrying only inside the bounded delegate-retry envelope (max 3 attempts / 5 min; `liveness-discipline`) — never unbounded.
- Do not passively background-and-wait on a delegate, and do not add a blocking gate or a "watchdog applied" attestation hook to compensate — poll progress instead (FR-27: a hang is undetectable by construction).

## Clean-room note

Original Fusebase Flow content. Derived from operator-provided capability requirements and generalized into repo-local workflow discipline; no third-party code, prompts, skill files, or hook scripts are copied. See `docs/source-map.md`.