choosing-graph · diff
git:20260910.6be81e4 to git:20260910.b01cff1
18 added, 28 removed. Audit A to A.
---
name: choosing-graph
- description: Use at the start of any straw-boss work, and again when the shape of the work changes.
+ description: Use at the start of Straw Boss work, and when its coordination shape changes.
---
- ## Overview
-
- Two choices, made before the first turn of real work and stated out loud: the **coordination graph** — how the agents on this task are wired — and the **reality anchor** — the contact with reality that proves the result. **The coordination graph is coordination too**, so a main agent fixes both when it dispatches and the anchor travels with the brief; a dispatched agent states its own for its own task and works inside the anchor it was handed.
-
- **The reality anchor is coordination; the method inside it is work.** The main agent names which anchor proves a task — testing, pseudo-human, human, or an independent agent's adversarial review — and arranges its checkpoint, including any shared resource that has to exist before the worker has anything to show.
-
- **Naming the anchor is not naming the tests.** The anchor fixes the category and its checkpoint; inside it the worker and the user choose the method — for testing, unit tests at the smallest credible seam that can go red before the change, escalated to integration or E2E when the target project's own conventions call for it. That split keeps the brief clear of the worker's own work definition.
-
- Both are stated, not asked. The human anchor carries the one user question described below.
-
## Coordination graphs
- Which graph applies follows from how the work actually runs.
-
- - **single-loop** — one agent carries uncomplicated work whose length is visible end to end. A coordinator driving one dispatch's lifecycle, or a worker using one coworker as a check, remains a single loop.
- - **sub-agent fan-out/fan-in** — a main agent or dispatched worker sends clear, converged branches to subagents and integrates their results. A subagent is an ephemeral agent-tool call for self-contained work that runs outside the target app's own harness; work needing that harness is a dispatch instead.
- - **orchestrator-worker** — the coordinator runs multiple app-rooted workers through status events. A dependency graph and a capped batch use this shape. It is the only graph that writes `~/.straw-boss/plans/<slug>/plan.json`; the other two carry no dispatch plan.
+ State the graph before work starts, using the first matching case:
- `orchestrator-worker` is settled ahead of the other two: more than one app-rooted worker under one coordination loop keeps that shape whatever else runs beside it.
+ - **orchestrator-worker** — multiple app-rooted workers coordinated through status events, including capped batches and dependency plans.
+ - **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.
+ - **single-loop** — one bounded task carried by one agent, including coordination of one dispatch.
- `single-loop` and `sub-agent fan-out/fan-in` create no `plan.json` and no repo-internal Straw Boss planning or spec document. An app-rooted dispatch still writes its own `~/.straw-boss/dispatch/<app>--<slug>.json` instruction and `.contract.md`; these are the dispatch's lifecycle record, archived once the dispatch wraps up.
+ An independent review is a checkpoint, so it does not change the graph. A dispatched agent states its own graph for its task.
- Between **single-loop** and **sub-agent fan-out/fan-in**, the deciding question is whether a branch of the work itself runs in a subagent: if one does, the shape is fan-out. The anchor's own check — including an independent review agent — is not a branch of the work and never changes 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
- - **testing** — the default. Unit tests cover the smallest credible seam that can go red before the change; the worker escalates to integration or E2E when the target project's own conventions call for it.
- - **pseudo-human** — a computer or browser drives the real interface and verifies a simple element by screenshot and measurement.
- - **human** — the user operates the real artifact and judges a new UI element, UX behaviour, or finished article. Ask whether their risk judgment prefers pseudo-human instead. Reading code or a document is review, not a human anchor.
- - **adversarial-review** — a fresh-context agent attacks the finished result against the requirement and evidence. It is the anchor when the other three offer no credible checkpoint, and accompanies an ordinary programming change as an independent check.
+ The main agent names the anchor and checkpoint; the worker and user choose the verification method inside that anchor.
- Review one coherent change-set with one adversarial review after implementation and primary verification. The reviewer examines the finished change-set directly. Correctness and contract findings return to the working loop; nits close with an explicit disposition. The lifecycle owner records the review once against the confirmed completion reference.
+ - **testing** — default for programming changes. Use the smallest credible seam that can go red before the change; escalate to integration or E2E according to the app's conventions.
+ - **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.
- For read-only work with no operable artifact or red test, adversarial-review is its anchor. The reviewer attacks the report's claims against its evidence references, so an audit or investigation has to carry them: the exact rule and implementation, file/line, test, log, command, or artifact are what this work's anchor attacks. A troubleshooting branch that lands a fix uses testing like any other change.
+ 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.
- ## The port a frontend anchor needs
+ ## Review checkpoint
- A frontend human or pseudo-human anchor needs a running address, so the main agent assigns the port at dispatch and the worker binds it. Claim and release mechanics live in `${CLAUDE_PLUGIN_ROOT}/skills/dispatching-work/references/shared-resource-coordination.md`.
+ Review one coherent programming change-set once, after implementation and primary verification. A fresh-context reviewer examines the finished change-set directly; correctness and contract findings return to the work loop, and nits receive an explicit disposition.
- **Verification:** the graph and anchor are named before work starts; `plan.json` exists only under orchestrator-worker; a frontend human or pseudo-human anchor carries an assigned port; the brief leaves the method to the worker; one coherent programming change-set receives one independently dispositioned review.
+ The lifecycle owner confirms the completion reference and records the review disposition against it. Reuse an existing disposition for the same change-set; changed code or unresolved findings reopen the relevant check. Dispatched work reaches this checkpoint 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.