Design 47's B0 says the checker is delivered first and a failed seat list ends the check there (issue 1921, B0 review round 2)

Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i

03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md

@@ -2445,7 +2445,7 @@ order inside one milestone, for this one case (ADR 0644).
 - **One exception, until milestone G.** A checking program that cannot be asked, built or run, or answers no verdict, fails the check naming it, as ADR 0656
   §5 has it; the verdict's other failures are then worded by the running checker's rules, which word what the facts
   hold and never decide the outcome, because the program that would word them did not answer. A seat list the program
-  cannot make fails the check the same way, naming why, and the program is not asked for the verdict.
+  cannot make ends the check there, failed and naming why: no manifest validator, no module graph and no composition is asked, nor the program's verdict, and the verdict is worded by the running checker's rules.
 - **The checking program makes the seat list.** Its first answer in a check is the heads' one seat list: the seats the
   heads define, resolved, and each it left out with why. The check hands that list to the manifest validator at the
   heads, to the trunk's manifest validator of ADR 0633 §6, and to the composer at a node-engine member's head, in the
@@ -2472,7 +2472,7 @@ B0's own choices, each checked by the rows of *How it is checked* below:
 
 | Choice | Why |
 |---|---|
-| A `run` ask has a begin bound of 5 minutes per put (a setting of the checker, 5 minutes unless set), inside the first tier's 20 (*What ADR 0656 leaves to this design*): put once, put again after 5 minutes unbegun, and the check fails naming the missing job `run` after a second 5 minutes unbegun; a begun step keeps the first tier's bound | five minutes is long enough for a build node with a free slot to take an ask, and two puts still leave half the first tier's bound to the run itself; a build module on today's trunk drops an ask whose job it does not know from its work queue with a log line and writes no step key, so the checker would wait to its step bound in silence; the old build modules run beside the new checker until B0 reaches every build node, because `run` is a job inside the accepted kind `check`, not a served verb, and so no edge of the module graph orders the two. That gap of the build and delivery system is closed by milestone G's acting rule for the build step; in B0 it fails loudly instead |
+| A `run` ask has a begin bound of 5 minutes per put (a setting of the checker, 5 minutes unless set), inside the first tier's 20 (*What ADR 0656 leaves to this design*): put once, put again after 5 minutes unbegun, and the check fails naming the missing job `run` after a second 5 minutes unbegun; a begun step keeps the first tier's bound | five minutes is long enough for a build node with a free slot to take an ask, and two puts still leave half the first tier's bound to the run itself; a build module on today's trunk drops an ask whose job it does not know from its work queue with a log line and writes no step key, so the checker would wait to its step bound in silence; the build module's `invokes` of the checker's verb `input` orders the checker first, so the new checker runs beside the old build modules until the new one reaches every build node, and a build module that does not know `run` drops its ask. That gap of the build and delivery system is closed by milestone G's acting rule for the build step; in B0 it fails loudly instead |
 | A build module answers an ask whose job it does not know on its step key as refused, naming the job, never only in its log | the kind, not this instance: every ask a build module takes is answered, so no asker waits on an ask nobody will end |
 | The build module's kept checking programs and composers are read, dropped and swept: `build_go_kept` lists them (key, size, last use), `build_go_kept_drop` drops one and answers what it removed, and the sweep the build module's workspace cleaning runs removes one unused for 30 days; in milestone G a drop is written to the hand-act log with G's drop tools | the bound is not the workspace bound, because a workspace is held by one step while a kept program is reused by its key across checks, and 30 days keeps every program a check of the month's trunks asks again; with every check running the checking program, each merge into mesh-delivery or mesh-sdk adds one kept program per build node; a store nothing reads or empties fills the build node unseen, and a module's tools read all it holds and recover without help |
 | The program's input (the facts it judges, or the heads a seat list is asked of) goes by reference: the checker keeps it in its own state `inputs` under the sha256 of its exact bytes for a day, read by no other part; the ask names the verb that answers it, the digest and the size; the Go build module asks the seat `mesh-delivery-checker`'s verb `input` for that digest, over the bus, and refuses bytes that are not the input named. The build module declares the call in its manifest's `invokes`, so the module graph orders it after the checker (*Order without a person*), and the checker declares the verb in its `serves`. An input is bounded by the bus's value limit of 256 KiB, the one this design already uses, and one over it is refused before the ask, naming its size. The program's answer (the seat list, the verdict) is the last line of its output, carried whole on the step key with its exit, and an answer over the same 256 KiB fails the step, naming its size | a group's facts grow with its members, and an ask over the bus's size limits is lost or refused far from its cause; refused before asking, a group too large fails by name. The input is the checker's own kept data, so it lives in the checker's state and another module asks it of the checker's seat verb, never reading that state (ADR 0596 §2); a day outlives every check's step bound. The answer is small beside the facts, one seat list or one verdict, so it rides the step key as every step's answer does |