adjust parallelism

src/routing.ts

@@ -72,11 +72,12 @@ new logic, explain the reachable scenario, cost and a simpler correct alternativ
 the user before delegating it, even where that skill's Escalation section would proceed
 without asking. In-scope bugfixes need no approval. Never waive correctness, security or data integrity for
 simplicity; if required protection is complex, explain why and ask how to proceed.
-Parallelize independent tasks with disjoint writes; serialize dependencies and shared files;
+Parallelize independent tasks with disjoint writes; serialize dependencies, shared files,
-do not redo completed work or investigation. Use fast-lo for missing facts; workers should not guess.
+and shared build/test state; do not redo completed work or investigation. Use fast-lo for
-Escalate on a concrete failure, uncertainty, risk, or long dependency chain; pass prior
+missing facts; workers should not guess. Escalate on a concrete failure, uncertainty, risk,
-findings and failures forward. Have good-lo review code changes by fast agents; send other
+or long dependency chain; pass prior findings and failures forward. Have good-lo review
-reviews and plans to good-hi (deep-hi if available) when risk or extent warrants.
+code changes by fast agents; send other reviews and plans to good-hi
+(deep-hi if available) when risk or extent warrants.
 Reconcile results and finish the whole request.
 Ask the user only for requirement-affecting decisions retrieval cannot answer.
 Delegate only to the listed workers; they cannot delegate further.

src/task-planning.md

@@ -26,7 +26,13 @@ Give each stage:
 - owned files
 - an acceptance check someone can observe
 
-Prefer parallel read-only work, and as few stages as the dependencies allow. A stage that only exists to hand off to the next one usually should be merged into it.
+Use as few stages as the dependencies allow. A stage that only exists to hand off to the next one usually should be merged into it.
+
+## Parallelism
+
+- Fan out read-only work: a few parallel lookups (about 3–5 at most), none where one lookup answers the question.
+- Run write stages in parallel only when independent. Settle any shared interface, type, or contract in an earlier stage so parallel writers do not make conflicting choices.
+- Workers sharing a checkout must not run builds, tests, or installs concurrently: limit their briefs to edits plus checks scoped to their own files, then run the full build and test once after the parallel stages join.
 
 ## Track
 
@@ -58,6 +64,6 @@ Request: "Add a `--json` flag to `report` and `export`, using one serializer."
 
 - Scope: fast-lo finds `src/format.ts` (existing formatters), `src/cli/report.ts`, `src/cli/export.ts`. Out of scope: other commands.
 - Stage 1 (good-lo, owns `src/format.ts`): add a JSON formatter beside the existing ones; check: a unit test round-trips a report.
-- Stage 2 (fast-hi, owns both CLI files, after 1): wire the flag in both commands; check: each prints valid JSON with `--json` and tests pass.
+- Stage 2 (fast-hi, owns both CLI files, after 1): wire the flag in both commands; check: each prints valid JSON with `--json`.
-- Stage 3 (good-lo, read-only, after 2): review stage 2's diff.
+- Stage 3 (good-lo, read-only, after 2): review stage 2's diff; a worker then runs the full build and tests.
 - Todos hold all three; if stage 2 fails, the revised brief includes the failing output.