Choosing Graph

---
name: choosing-graph
description: Use at the start of Straw Boss work, and when its coordination shape changes.
---

## Coordination graphs

Default to single-loop and state nothing; state the graph only when it is fan-out or orchestrator-worker. Use the first matching case:

- **single-loop** — one bounded task carried by one agent, including coordination of one dispatch.
- **sub-agent fan-out/fan-in** — independent work branches run in subagents and their caller integrates the results. Work needing the target app's own harness uses an app-rooted dispatch.
- **orchestrator-worker** — multiple app-rooted workers coordinated through status events, including capped batches and dependency plans.

An independent review is a checkpoint, so it does not change the graph.

Only `orchestrator-worker` writes `~/.straw-boss/plans/<slug>/plan.json`, through [boss-say](../boss-say/SKILL.md#plan-and-schedule).
The other graphs create no Straw Boss plan or repo-local spec.
A dispatch's instruction, contract, and status under `~/.straw-boss/dispatch/` are lifecycle records, archived at wrap-up.
The app's own development artifacts follow its local workflow.

## Reality anchors

The main agent names the anchor and checkpoint; the worker and user choose the verification method inside that anchor.

- **testing** — default for programming changes. Use the smallest check that can go red before the change and reaches the changed code. The repo-wide suite, lint, and type check belong to the shared checkpoint or the pre-merge run below, not to each task.
- **pseudo-human** — a browser or computer operates the real interface, with screenshots and measurements as evidence.
- **human** — the user operates or judges the delivered artifact. Ask about pseudo-human only when the user's risk judgment is unresolved.
- **adversarial-review** — a fresh-context agent challenges the result against the requirement and evidence references. Use this for read-only work with no credible executable or operable checkpoint.

Naming the anchor settles where its checkpoint runs.
Tasks that share one anchor and one checkpoint take a single checkpoint dispatch over the whole group.
A repo-wide command returns the same verdict for every task touching that app, so the suite, lint, and type check run once over the integrated result: at the group's checkpoint, or before merge for a lone task.
A task whose checkpoint is distinct, or plainly cheaper exercised in place, carries its own.

For frontend human or pseudo-human checkpoints, assign a reachable address through [shared-resource coordination](../dispatching-work/references/shared-resource-coordination.md#ports) before dispatch.

## Review checkpoint

Review one coherent programming change-set once, after implementation and primary verification.
When naming the anchor, the main agent assigns a fresh-context reviewer to a change-set that touches a shared contract, authorization or permission data, or a migration, because author self-review has missed correctness findings there; any other change-set takes its disposition from the author's read of its own diff against the brief.
Correctness and contract findings return to the work loop, and nits receive an explicit disposition.

A shared checkpoint belongs to the main agent and runs as a checkpoint task, as [boss-say](../boss-say/SKILL.md#plan-and-schedule) describes.

The lifecycle owner confirms the completion reference and records the review disposition against it.
Reuse an existing disposition for the same change-set. After fixes, the same reviewer re-checks only the P0/P1 fix diff, once; the author disposes of P2 and below.
A task carrying its own checkpoint reaches it through [wrap-up](../dispatching-work/SKILL.md#wrap-up); current-agent work through [shipping-task](../shipping-task/SKILL.md#complete-the-lifecycle).

**Complete when:** graph, anchor, and checkpoint are established; a completed programming change has its confirmed reference and review disposition.