choosing-graph

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. 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 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 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; current-agent work through shipping-task.

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