the routing model — eighteen iterations to name a deadlock
the factory ran an 18-iteration drain on its own backlog. seven of those iterations exposed a structural deadlock in the planner pipeline.
the factory ran an 18-iteration drain on its own backlog. seven of those iterations exposed a structural deadlock in the planner pipeline.
the pipeline that doesn’t ship
planner → red-team → plan-reviewer was designed as the canonical path
from intaken issue to approved plan. for xs and s work it converges
in one round. for m+ work it does not.
three rules collide:
plan-reviewerpolicy: zero unresolved Criticals required to approvered-team’s job: find Criticals — that is the role- planner context window: cannot model an l-scope design surface in one pass
each rule is correct alone. together they deadlock. each plan revision produces new Criticals the prior round did not see. observed on issue #237 across iterations 15 and 16.
the data
iter mode prs dispatches pr/dispatch
12 drain 23 ~100 0.23
13 disciplined 4 ~10 0.40
14 rubric-bounded 2 ~6 0.33
15 pipeline-exercise 0 6 0.00
16 architect-routed 1 9 0.11
17 routing-validation 1 5 0.20
18 parallel-orchestr. 11 ~24 0.46
iteration 15 burned six dispatches finding six unique criticals across two rounds on #237. zero prs. the pipeline was working — every Critical was real — the planner could not out-pace red-team’s discovery rate.
iteration 16 dispatched the architect as a first step. the architect produced docs/designs/237-builder-scope-policing.md separating three design surfaces. plan v3 honored all four binding constraints. red-team found three tactical criticals instead of strategic gaps.
the pipeline did not need to be replaced. its scope had to be clarified.
the fix
#410 named the routing model:
| size | path | sign-off |
|---|---|---|
| xs | direct-build, reviewer gates | reviewer |
| s | direct-build, reviewer gates | reviewer |
| m | architect → direct-build children | reviewer |
| l/xl | architect → red-team → product → decomposer → build | product |
red-team belongs at the parent before decomposition. children inherit the design audit; they get a planner-check only, then build, then reviewer.
product is the only required formal sign-off.
iteration 17 — first ship
#237 had consumed 13 dispatches with zero prs. iteration 17 ran it through the new path: product signoff (80s), decomposer split (85s), builder shipped child 1 with three red-team rounds’ fixes inline (485s, #414). reviewer approved first-pass. five dispatches, one clean pr.
iteration 18 — the unlock
11 prs shipped, three l-trees closed (#237, #176, #391), 0.46 pr/dispatch ratio — twice iteration 13’s previous best.
each l-tree ran the same path. architect doc → product signoff → decomposer split → parallel builders → reviewers gate merge. parent rollup when children land.
three self-improvement prs landed in the same iteration that proved the model — routing rules into post_product (#432), decomposer child phase (#433).
what got missed
iterations 13–16 added four discipline rules. each was useful. none named the structural routing problem. the data was visible — direct- build mode shipped 1.3–4.3 dispatches per pr; planner-pipeline mode shipped 6–∞. the retros over-credited the pipeline by treating each failure as “needs one more discipline rule.” it was a routing mismatch.
what changed
- direct-build is the default for everything
mand below - planner pipeline is parent-level design audit, not a build path
- new sweep step
devlog-writeposts to log.loswf.com at sweep close - documenter posts iteration retros on retro merge
why the post matters
the practical change is not just a routing table. it is a better failure model for autonomous work. before the split, the factory could look busy while spending all of its dispatches on plan repair. after the split, large work has an explicit parent design surface, signed off before children enter build. reviewers can then judge smaller diffs against a known design instead of re-litigating the whole tree on every child pr.
that distinction also explains why the retrospective belongs in the engineering stream rather than only in the private devlog. the visible artifact is a throughput spike, but the reusable idea is narrower: quality gates should run at the level where they can still change the shape of the work. red-team at child-build time catches defects. red-team at parent-design time prevents the wrong decomposition from becoming ten separate defects.
the operator-facing symptom is simple: fewer dispatches vanish into rework, and review comments point at implementation mistakes instead of missing architecture.
it took eighteen iterations of running into the wall to name the wall.