/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.

Use the selected lifecycle authority: standalone uses the task flow below; Orca uses `references/orca-coordinator.md`. Do not infer Orca mode from the app being installed or open. A refusal from the selected authority is a blocker, not permission to switch state stores.

Dispatch

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

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.

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>'

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/DB or legacy task rows are unavailable, say so and track groups in WISH.md; preserve dependencies, file ownership, review, and validation. This fallback never bypasses a live claim conflict or an Orca authority refusal.

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. 4. Obtain the separate quality pass for security, maintainability, and performance. Its repair cap is one loop, separate from `B`. 5. Verify the group’s checks and actual diff. Use checks that can disprove the changed behavior; preserve repository-required aggregate gates. Shared runtime, schema, dependency, executable artifact, CI/release, broad-refactor, or uncertain-impact changes require the full gate and affected build/end-to-end checks. Validation is never zero. Reuse current applicable evidence; rerun for changed code, failures, or unresolved concerns. A passing full suite is valid; missing scope rationale alone is a write-up gap. 6. Only after SHIP and passing validation, the coordinator relays the verdict to the card and completes the group:

genie task comment <task-id> --worker orchestrator -- 'review: SHIP — <n> gaps; validation: <command> → pass'
genie task done <task-id>

Every review verdict in a fix loop is relayed the same way (`review: FIX-FIRST — <summary>`), and an exhausted loop or diagnosed route gets one `blocked: <cause> — <route>` comment.

Card conversation

The card timeline (`genie task report` / `genie task comment`) is the global task state: the one recor