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 5e0f6050..8009492c 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 @@ -728,9 +728,10 @@ ADR 0656 leaves how each part is built to this design, under issue 1921; these f below), so a module whose runtime reads the value is composed only by a node-engine that hands it. - **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 digest in the - build seat's objects, laid as a file, and writes the program's exit, and its output by digest, 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 + 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 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 @@ -2427,13 +2428,23 @@ order inside one milestone, for this one case (ADR 0644). it, and reads no file of the heads itself. The seat list is the one ADR 0636 §4 decides, with its insight of 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, built at the - heads the carry merged onto the new trunk; the running checker's own rules judge no check after B0's delivery. The - program is built at the change's mesh-delivery member's head when it has one, else at mesh-delivery's trunk, as the - manifest validator is chosen today, and once per build: a trunk move that leaves the checking program unchanged asks - no new build. 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). + 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, + 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 + a move of another trunk that moves no mesh package version asks no new build, and a move of mesh-delivery's trunk + 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 + §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. - **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 @@ -2460,16 +2471,17 @@ 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, 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 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) and its answer (the seat list, the verdict) go by reference, by digest in the build seat's objects as a compose ask carries its manifests, and each referenced object is bounded by the bus's value limit of 256 KiB, the one this design already uses, an input over it refused before the ask, naming its size | a group's facts grow with its members, and an ask or a step key 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 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 `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. The build module's step tools read a - `run` ask's step as they read every step, and `build_go_kept` and `build_go_kept_drop` read and drop its kept + 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, + 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 checking program (ADR 0644, Consequences), and every check costs one more ask in the build seat, within the @@ -2487,10 +2499,12 @@ B0's own choices, each checked by the rows of *How it is checked* below: checker change alters a rule is judged by its own checking program, which has no bus account; a lone pull request and 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; a fixture build module that drops a `run` ask is put again + 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 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, 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 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 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 @@ -2538,7 +2552,10 @@ The amendment for milestone B0 (2026-11-06) carries the review of seams and tool approve on three findings: a `run` ask an old build module drops is silent, the kept programs have no tool, and the program's input rides in bus messages unmeasured. Each is answered by a row of B0's choices (*The bootstrap delivery, 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. +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. 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