From da828c147a4839d3849457c1564c372e92a1feea Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 6 Nov 2026 23:51:01 +0100 Subject: [PATCH] Design 47's B0 takes in round 1's rulings: the input asked of the checker's verb, the cycle rule the program's MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A build module reading the checker's state broke ADR 0596 §2, and no record names the cycle rule as an exception to ADR 0656 §5; the code now follows both, and so does the design, with the answer's bound that the build module now enforces. Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i --- .../47-delivery-from-commit-to-delivered.md | 35 ++++++++++--------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md b/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md index 8009492c..a92741b5 100644 --- a/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md +++ b/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md @@ -729,9 +729,9 @@ ADR 0656 leaves how each part is built to this design, under issue 1921; these f - **The build seat's ask that runs a program in the sandbox.** The checker asks the seat `node-build-go` for an ask `run` on the build seats' `check` stream: one whole job on one node (ADR 0525 §3), which fetches the named heads, builds the named program at them, runs it in the run step (ADR 0448 §2) with the input the ask names by its sha256 in - the asker's own state (the checker's `inputs`, a day, read by the build module through its manifest's `reads`), laid - as a file, and writes the program's exit and its answer, carried whole, on the build module's step key named by the - ask's id (ADR 0525 §6). It is an accepted ask of the seat, not a request verb, because it is a + the asker's own state (the checker's `inputs`, a day), asked of the seat `mesh-delivery-checker`'s verb `input` and + checked against that digest, laid as a file, and writes the program's exit and its answer, carried whole, on the + build module's step key named by the ask's id (ADR 0525 §6). It is an accepted ask of the seat, not a request verb, because it is a long job pulled where there is capacity, never a call to a named node. Only the checker's account may publish `run`. Every step key of a `run` ask starts with the asker's name (`checker.`), so the checker's read grant is fixed in advance to its own prefix and never follows ask ids one by one (ADR 0363 §2); no other part can have a program run @@ -2429,8 +2429,8 @@ order inside one milestone, for this one case (ADR 0644). 2026-11-06; B0 builds its hand-over and decides nothing new about it. - **Every check runs it, one path.** A lone pull request is a group of one, and a verdict carried after a move of a trunk or a sibling (*A move of the trunk carries every verdict*) is judged by the checking program too, on the same - path as a new check; the running checker's own rules decide no check's outcome after B0's delivery, with the two - exceptions below. The program is built at the commit of the change's mesh-delivery member's head when it has one, + path as a new check; the running checker's own rules decide no check's outcome after B0's delivery, with the one + exception below. The program is built at the commit of the change's mesh-delivery member's head when it has one, else at mesh-delivery's trunk as the check reads it (after a move of that trunk, the new trunk), as the manifest validator is chosen today, and it reads every member's head as pushed. It is built once per build: a build is kept under the program's repository, commit, directory and package, the toolchain and the mesh package versions asked, so @@ -2438,10 +2438,11 @@ order inside one milestone, for this one case (ADR 0644). under a change with no mesh-delivery member asks one. Why: a group-only program would leave the running rules judging every lone pull request and every carry, two paths of which one is the old form kept; and a carried verdict must say what a check of the same heads would say (ADR 0548 §1, §5). -- **Two exceptions, until milestone G.** The module graph's cycle rule (ADR 0603 §2) stays in the running checker: - its facts are the whole manifests of the trunk with the change's laid over them, which exceed the input's bound of - 256 KiB, and milestone G's first tier builds the checker from the change's heads with it (ADR 0656 §5). And a - checking program that cannot be asked, built or run, or answers no verdict, fails the check naming it, as ADR 0656 +- **The module graph's cycle rule is the program's.** The running checker gathers the edges of the change's module + graph and of the trunk's, each edge's two modules and its kind (a base, an awaited provision, a kept verb edge), never + the whole manifests, and the checking program refuses a cycle by the rule ADR 0603 §2 decides, as ADR 0656 §5 has + every check after B0 judged (the whole catalog's graph is about 50 edges, a few KiB of the input's bound). +- **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. @@ -2474,13 +2475,13 @@ B0's own choices, each checked by the rows of *How it is checked* below: | 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 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, the ask names the state, the digest and the size, and the Go build module reads it through its manifest's `reads` and refuses an input whose bytes do not match. 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 | 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, kept as a compose ask's manifests are kept in the indexer's state, and the build module reads it as it already reads the checker's `kept` and the indexer's `manifests`: a `reads` of today's form, which moves to the owner's tool or event with those readers (ADR 0596 §2, §3); 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 | +| 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 | | The `run` ask goes on the check stream under the grants check asks have today; the publish grant fixed to the checker's account and the step keys under the asker's name (*What ADR 0656 leaves to this design*) come with milestone G | B0 opens nothing a compose ask does not already allow, since any publisher of check asks can have a composer built and run at a commit today, and ADR 0644 limits B0 to what the running checker must run | | The checking program's input carries its version, and a program that does not read the version it is given fails the check, naming the version | B0's checker runs milestone G's checking programs, G's own check first, so G's checking program reads the form B0 writes; that is the form, not an old one kept, and G adds the revision view to it | - **Its tools.** The checker's read of a check names the checking program's build that judged it: its fingerprint and the heads it was built from, and the seat list it made with what it left out; `checker_inputs` lists the inputs the - checker keeps, each digest with its size, and reads one whole. The build module's step tools read a `run` ask's step, + checker keeps, each digest with its size, and reads one whole, and the seat's verb `input` answers one by its digest. The build module's step tools read a `run` ask's step, its answer included, as they read every step, and `build_go_kept` and `build_go_kept_drop` read and drop its kept programs. Asking a check again stays the checker's existing ask-again. - **What it costs.** One more check, Approve and delivery before milestone G; milestone G then has one check, on its own @@ -2500,11 +2501,12 @@ B0's own choices, each checked by the rows of *How it is checked* below: a carried verdict are each judged by the checking program, and the check's read names it; a fixture group whose heads add a seat has that seat in the list both validators and the composer receive; a checking program that does not build, or builds and does not answer, fails the check naming it, and a seat list it cannot make fails the check with no - verdict asked of it; a change whose module graph has a cycle is refused by the running checker, naming the cycle; a fixture build module that drops a `run` ask is put again + verdict asked of it; a change whose module graph has a cycle is refused by the checking program from the gathered + edges, naming the cycle, and one whose trunk has the same cycle is only noted; a fixture build module that drops a `run` ask is put again after 5 minutes and fails the check after 10, naming the missing job; an input over its bound fails before the ask, naming its size; and the check's read names the checking program's build, heads and seat list. In the build module's - tests: a `run` ask on a real bus is answered on its step key, its input read from the checker's `inputs` and one - whose bytes do not match its digest refused, a program that dials out fails, an ask with a job it + tests: a `run` ask on a real bus is answered on its step key, its input asked of a checker answering the verb + `input` and bytes that are not the input named refused, an answer over 256 KiB failing the step, a program that dials out fails, an ask with a job it does not know is answered refused naming the job, a compose request's `seats` reaches the program whole, and `build_go_kept` lists kept programs, `build_go_kept_drop` drops one saying what it removed, and the sweep removes one unused for 30 days (unit). Live, B0's own check passes on the running checker, naming any module composed from its @@ -2554,8 +2556,9 @@ program's input rides in bus messages unmeasured. Each is answered by a row of B and the one milestone after it*), with the review's note that every check runs the checking program, a lone pull request and a carried verdict included. Its review by architectural domain is still to come. The first round of B0's code review found that this section did not say what was built: the input in the checker's own state and the answer -on the step key, the cycle rule and the wording of a failed program's verdict as the two exceptions until milestone G, -and where a carried verdict's program is built; each is now written as built, with its reason. +on the step key, the wording of a failed program's verdict as an exception until milestone G, and where a carried +verdict's program is built; each is now written as built, with its reason. The lead's rulings on that round then moved +the input onto the checker's verb `input` (ADR 0596 §2) and the cycle rule into the checking program (ADR 0656 §5). Left as notes on issue 1921, not in this amendment: a conformance check that a changed layout raises its `form`; the size and retention of restore points and set-aside data; who may call `restore` for bus data and which manifest grants