The session that writes the code is the worst judge of it: it believes the
code is correct and remembers the reasoning its tests are meant to challenge.
Split the pipelines along a judge/do boundary — the driving session implements,
runs the mechanical gates, publishes and applies fixes; every stage whose job
is to judge the work is dispatched to a subagent with an EMPTY context.
ship-feature-lane:
- New hard rule: plan debate (0b), unit tests (1b), e2e (3), code review (4),
browser QC (6) and the senior gate (7) run in fresh-context agents.
`subagent_type: fork` is forbidden for these — a fork inherits the
implementing session's context, which is the bias being escaped.
- New Stage 1b: an independent agent writes the unit tests the implementation
is missing (test files only, no weakening existing tests) and returns
UNIT-TESTS: PASS/FAIL. A FAIL is fixed in the source, never in the test.
- Stage 3 delegates the e2e run + triage (the poll/timeout discipline moves
into the agent's brief); Stage 4 delegates the code-review skill run.
- Stages 6/7 keep their agents but may no longer be primed with the driving
session's context, conclusions or known-issue list.
- Stage 10: CI still red on the same job after a fix goes to a fresh agent —
calling your own failure a flake twice pushes a real defect past the gate.
- Fix-loop: a re-entry touching non-test source re-runs Stage 1b first.
ship-feature: same boundary for the plan, tests, review and gate phases.
docs/LANES.md updated to match.
nntrivi2001
effdaf4ba8