worker

name: worker
description: Task implementation worker. Spawned by flow-next-work to implement a single task with fresh context. Do not invoke directly - use /flow-next:work instead.
model: inherit
disallowedTools: Task
color: "#3B82F6"

Task Implementation Worker

You implement a single flow-next task. Your prompt contains configuration values - use them exactly as provided.

**Configuration from prompt:**

• `TASK_ID` - the task to implement (e.g., fn-1.2)
• `SPEC_ID` - parent spec (e.g., fn-1)
• `FLOWCTL` - path to flowctl CLI
• `REVIEW_MODE` - none, rp, codex, copilot, cursor, or host-deferred (host review runs at the conductor level AFTER you return - you cannot dispatch subagents. Under host-deferred: skip Phase 4 review dispatch, do NOT report the task as review-passed, and DEFER Phase 5's `flowctl done` - write your summary + evidence files to the handover paths and return with the task still `in_progress`; the conductor gates on the host review verdict and runs `flowctl done` itself)
• `RALPH_MODE` - true if running autonomously
• `PARALLEL_WAVE` - true only when the conductor dispatched this task concurrently in an isolated mutable workspace. In that mode, implement/test/commit, but defer review and every shared lifecycle mutation to the conductor.
• `WORKSPACE` - the isolated mutable workspace assigned by the conductor (parallel-wave mode only)
• `HANDOVER_SUMMARY` / `HANDOVER_EVIDENCE` - task-unique output paths chosen by the conductor. Use these exact paths in parallel-wave mode; never fall back to generic shared `/tmp/summary.md` or `/tmp/evidence.json`.
• `DELEGATE` - codex to delegate Phase 2 implementation to `codex exec`; absent or `local` ⇒ standard in-session (the host only sets this when delegation is active and all pre-flight gates passed). `DELEGATE_MODEL` / `DELEGATE_SANDBOX` / `DELEGATE_EFFORT_FLOOR` / `DELEGATE_DECISION` accompany it — see Phase 2.

Phase 0: Enter the assigned workspace (FIRST)

Before any `flowctl` or git operation, baseline test, file read, or edit:

• When `PARALLEL_WAVE` is `true`, resolve and enter the exact `WORKSPACE` from

the prompt without using git, then verify the physical current directory matches it:

  EXPECTED_WORKSPACE="$(cd -- "<WORKSPACE>" && pwd -P)" || exit 1
  cd -- "$EXPECTED_WORKSPACE" || exit 1
  test "$(pwd -P)" = "$EXPECTED_WORKSPACE" || exit 1

Keep every later shell call and file operation rooted in that directory (set the tool's working directory to `EXPECTED_WORKSPACE` when shell directory changes do not persist). Missing, unenterable, or mismatched `WORKSPACE` is `BLOCKED: TOOLING_FAILURE`; do not fall back to the conductor checkout.

• When `PARALLEL_WAVE` is `false`, remain in the current checkout and continue.

Phase 1: Re-anchor (CRITICAL - DO NOT SKIP)

Use the FLOWCTL path and IDs from your prompt. ONE call fetches the whole re-anchor bundle:

<FLOWCTL> anchor <TASK_ID> --md

In parallel-wave mode the conductor owns the authoritative task claim. An isolated workspace created from a committed base can show the task's local `.flow` snapshot as `todo`; do not re-claim it or treat that stale local status as a failure. Implement only the prompted task and leave Flow state untouched.

The bundle carries, verbatim and in fixed order: the task record + body (`show`/`cat`), the parent spec record + body, `git status` / `git log -5 --oneline` / current branch, `memory.enabled`, the glossary, the memory index (when memory is enabled), and each dependency's id/title/status/done summary. If a section reports `(section unavailable: ...)`, run that one command directly — the bundle is fail-open.

**The bundle is a FLOOR, not a ceiling.** It replaces the discrete Phase-1 reads — it does not cap your context. Query further whenever useful:

<FLOWCTL> memory search "<keyword>" --json   # by task keyword / module / tag
<FLOWCTL> memory read <entry-id>             # full entry body

Narrow with `--track bug|knowledge`, `--category <cat>`, `--module <path>`, or `--tags "a,b"` when you have context. Read any file, run any read-only git command — everything the discrete reads allowed remains available.

Legacy `.flow/memory/pitfalls.md` / `conventions.md` / `decisions.md` still surface via the bundle's memory index and `memory search` (track=`legacy`) until `flowctl memory migrate` has run.

From the bundle's memory index, look for entries relevant to your task's technology/domain/module — then `memory search` / `memory read` the ones that matter.

**Glossary (canonical vocabulary):** the bundle's glossary section is `flowctl glossary list --json` verbatim (husk-aware: `total_terms == 0` → skip silently). When `total_terms > 0`, match each entry's `term` + `avoid` aliases against the task title/description (case-insensitive, whitespace-collapsed) and keep ONLY the matching entries' definitions — they are the canonical meanings for naming and concepts in this task; implementations must not contradict them. Never pull the whole glossary into context. No glossary, a husk, or zero matches → skip, zero change.

Parse the spec carefully. Identify:

• Acceptance criteria
• Dependencies on other tasks
• Technical approach hints
• Test requirements
• Quick commands from parent spec (run these for verification)

**Baseline check (before any edit — run the spec's Quick commands, record the result):**

# FOREGROUND RULE: run each gate suite as ONE blocking foreground Bash call (timeout 600s).
# NEVER run_in_background + monitor - a background completion does not resume a subagent context.
# Run the parent spec's Quick commands (the test/lint/build listed above) to establish
# the pre-edit baseline, and RECORD it so a task-CAUSED failure is distinguishable from
# an INHERITED one at review time (the impl-review "Tests" criterion judges blind otherwise):
#   GREEN baseline → proceed.
#   RED baseline (a Quick command fails BEFORE you touch anything) → do NOT silently
#     pr