/work

name: work
description: "Execute an approved wish in dependency order with scoped workers, independent review, bounded repairs, and verified completion."
category: lifecycle
mutates: repo

Work

Read the wish and require persisted `APPROVED`, or `IN_PROGRESS` for a resume. The coordinator sets `IN_PROGRESS` before execution and owns task completion and review evidence. Documents remain the instruction source.

Dispatch

Derive ready waves from WISH.md’s Execution Strategy and per-group `depends-on`. A task DB row being `ready` does not prove its dependencies are met; the DAG lives in the document.

Order the work inside a group as tracer bullets: dispatch the thinnest slice that runs end to end first, then widen it. A slice that crosses every layer proves the interfaces exist and tells the next slice what it may assume, while layers finished separately prove nothing until the last one lands.

Delegate each independent group through the active runtime’s native surface, using the plan’s portable role and supported runtime configuration. Inherit the active model unless the user or an evidenced capacity diagnosis authorizes a change. If delegation is unavailable, report that limitation; do not pretend independent review occurred.

Give each worker its goal, deliverables, criteria, validation, dependencies, owned files, relevant context, and stop conditions. Include task identifiers when available. Keep doing independent coordination/integration work while workers run.

Parallel writers need disjoint file ownership or dedicated worktrees; otherwise sequence them. Shared-workspace workers do not change repo-level git state (`checkout`, `switch`, `reset`, `stash`, `rebase`) or commit: only the coordinator moves HEAD and arranges isolation. Reviewers remain read-only. Reuse or steer a live worker rather than spawning a duplicate. When the coordinator commits out of a shared or dirty checkout it commits the exact reviewed pathset and never a sweep of the whole tree, and it never discards, reverts or sets aside uncommitted work it did not write; `references/exact-path-commit.md` carries that procedure and its preservation gates.

Standalone claims

Before dispatch the coordinator writes the handoff onto the card; before mutation, including shared environment setup, the assigned worker claims its group; at handoff the worker posts exactly one report:

genie task comment <task-id> --worker orchestrator -- 'dispatch: <engineer> (<role>) — <wave>/<group>; scope: <boundary>'
genie task checkout <task-id> --worker <name>
# ... work, validate ...
genie task report <task-id> --worker <name> -- '<outcome>: <what changed, where>; <validation command → result>; Ruling: <decision> — <why> — <cost if wrong>'

Rich text and JSON leaving through a shell CLI — a card report or comment, a pull-request or issue body, a commit message — is payload, not syntax, so it travels through a file or standard input; a single-quoted argument carries only a body that holds no single quote. Never interpolate it into a double-quoted argument, where backticks, `$(…)` and quotes are still evaluated before the CLI ever sees the text, so the command that runs is not the one you wrote. Then read the stored body back from the card or the forge and compare it with the source: a zero exit proves the command ran, not that the text survived.

A losing claimant stands down. The report is the worker's one message on the card: `done`, `blocked: <reason>`, or `partial: <what is left>`, plus the validation outcome and every ruling taken on the user's behalf; it is not a second copy of the diff. Reclaiming a stale claim writes `genie task comment <task-id> --worker <name> -- 'reclaim: from <previous>, idle <duration> — <reason>'` before the new checkout. Keep setup claimed until validated; shared prerequisites belong to an explicit group. Do not reclaim another live worker’s claim merely because time has passed.

Rulings, not stalls

Stop and ask only for an irreversible or destructive action, a security-sensitive decision, a side effect outside the worktree, or a plan so broken that every path forward is a guess. Everything else is a ruling the worker takes and records as `Ruling: <what was decided> — <why> — <cost if wrong>`. Rulings ride the handoff report next to the outcome, because the decisions taken on the user's behalf are exactly what a reviewer needs and cannot reconstruct from the diff alone.

Each worker keeps a ledger of its run in its own working notes, built to survive a context reset. Its first line is the plan identity — wish slug, task id, and base SHA — so a ledger carried in from another plan is detected as foreign and discarded instead of resumed. Under it, one line per finished unit: `<group>: complete (commits <base7>..<head7>, review clean)`. Those lines are the only resumption authority; an unlogged unit is redone, never assumed.

Inspect `genie task list --wish <slug>` or `genie board --wish <slug>` as needed. If the CLI or its database is unavailable, say so and track groups in WISH.md; preserve dependencies, file ownership, review, and validation. This fallback never bypasses a live claim conflict.

Complete a group

1. Receive the worker’s result and inspect the changed scope and evidence. 2. Dispatch a different reviewer through `review` against the group’s criteria. Append returned evidence under `## Review Results`; reviewers do not edit the wish. 3. Route FIX-FIRST through `fix`, carrying its per-group budget `B` (default 2) and counters. An `overdesigned-plan` returns to planning; a user-approved simplification invalidates superseded evidence and requires fresh review. A review finding names a risk; it does not authorize a new subsystem. When closing one would cross into a risk domain this group never owned — a schema change, an authorization boundary, release machinery, a new dependency — stop the loop and take the choice back to the wish owner instead of widening the group.