Answer A-304: the checker puts a phase's asks at once and holds no step

Try 4 and 5 ran their steps one at a time because the checker waited on each ask before putting the next. Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
2026-11-12 21:35:48 +01:00
parent a70316b512
commit a0147f94af
1 changed files with 5 additions and 0 deletions
@@ -485,3 +485,8 @@ the principle that settles it, cited as "design 47 G A-n".
  matches what the watchman writes), the view takes it at run time from the holder FollowSeat follows, through one
  accessor of the SDK's process reader; no code names the assigner's module. *Corrected 2026-11-12: it first named the
  reach history's bucket names as real buckets too, for kept entries' sake; the view's kept reach holds no bucket name.*
 - **A-304** (ADR 0525 §4, A-284, A-285; principles 7 and 1; the operator's yes, 2026-11-12) The checker holds no
  step: within each of its two phases (every module that is not TypeScript, then the TypeScript modules after
  `groupPackages`) it puts every ask of the phase on the check stream at once and then waits for all of them, so the
  build nodes pull them at their own capacity; a declined ask is put again as today, and the phase's verdict is judged
  in the same order as before, whatever order the asks end in.