From e41dbeef4ae79c5695be593fa6835fcd11e18485 Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 11 Nov 2026 12:40:58 +0100 Subject: [PATCH] Write the operator's answer on an Approve before G, and answer round 3's leftovers of the third batch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The operator made an old Approve that pull request's approval step, decided by the registration's policy, so §510's carried act and §608's merge wait go; round 3 of the third batch has no fourth round, so its findings are answered here (§543 to §550). Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ --- .../G-11-develop-answers-review.md | 8 +- .../G-12-develop-answers-fourth.md | 110 +++++++++++++++++- .../47-milestones/G-13-review-round-3.md | 16 +-- .../G-2-pipelines-sizes-checks-and-tools.md | 2 +- .../01-to-be/47-milestones/G-7-answers.md | 4 +- 03-DESIGN/01-to-be/47-milestones/G.md | 2 +- 6 files changed, 123 insertions(+), 19 deletions(-) diff --git a/03-DESIGN/01-to-be/47-milestones/G-11-develop-answers-review.md b/03-DESIGN/01-to-be/47-milestones/G-11-develop-answers-review.md index ea8162af..bd707d82 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-11-develop-answers-review.md +++ b/03-DESIGN/01-to-be/47-milestones/G-11-develop-answers-review.md @@ -62,7 +62,7 @@ reason. What a question of another kind leaves open waits for the operator and i ## The review of §456 to §479, round 1 -- §483 **Main's step keys stay readable while main's askers run.** (§600, §601) A build seat's holder of G keys a step whose ask +- §483 **Main's step keys stay readable while main's askers run.** (§600, §601, §544) A build seat's holder of G keys a step whose ask came on main's subject `mesh.seat..accept.`, with no asker's name, as main does, `.`, and a step whose ask names its asker as §481 says; so a builder or checker of before G, which asks on main's subject, finds its answer under `.` through the rollout one node first and after a revert. Every asker of G asks @@ -106,7 +106,7 @@ reason. What a question of another kind leaves open waits for the operator and i (review round 1, running and testing 5, health and events 3). How it is checked: whole (runner), with a fixture's small cap a step ends and is said, `full` is said and a start refused, and on `room` the entry is appended and the start taken. -- §487 **The forge module learns a commit's fingerprint from every step end.** §475's `seen..` is +- §487 **The forge module learns a commit's fingerprint from every step end.** (§548) §475's `seen..` is written from every `step-ended`, whatever its commit, a run on request's included, so a commit that failed in a run on request before its pull request was opened is known at its merge. A `seen` key is deleted by §135's rule once its commit has been a watched branch's head or the head an open pull request names and is neither, and otherwise @@ -197,7 +197,7 @@ reason. What a question of another kind leaves open waits for the operator and i `branch-unprotected` stands (§17) raises none either. Why: the watchman already times each take-in wait (develop question on §12). How it is checked: whole (watchman), a head behind a pending revision raises nothing for 60 minutes, then `take-in-waits`. -- §498 **A wait names its clock and its kind.** (§534, §608) `meshwants.Wait`, the runner's wait body and the node-engine seat's +- §498 **A wait names its clock and its kind.** (§534, §608, §542) `meshwants.Wait`, the runner's wait body and the node-engine seat's gain `clock-from` (the time the bound counts from, §266, §269) beside `bound`, and `step`, one of the acting steps of §203 or `put`, `delivery`, `kept-build`, `backup`; a put's wait (main file, *A put without hold that stands*) is `step: put` with the node, the module and `fingerprint`; a dependent's delivery wait (§376) is `step: delivery` @@ -274,7 +274,7 @@ reason. What a question of another kind leaves open waits for the operator and i Why: one message per move, the pull request where there is one (develop questions FB1, FB2 and FB7). How it is checked: whole (bridge), an admitted push writes `pushed`, a merge `merged`, and a move of an unprotected branch writes nothing. -- §510 **A merge the switch carries is performed.** (§608) A `merges` key the old bridge had not performed, an Approve the +- §510 **A merge the switch carries is performed.** (§608, §542) A `merges` key the old bridge had not performed, an Approve the operator gave before G, becomes an act (§169) that the bridge performs through `merge-pull`, judged as every merge; while `merge-pull` refuses it for missing registrations (§95) the act stays unanswered and is performed again on `registration-changed`. No other merge act is made after G (§167). Why: §169 drops nothing the operator approved diff --git a/03-DESIGN/01-to-be/47-milestones/G-12-develop-answers-fourth.md b/03-DESIGN/01-to-be/47-milestones/G-12-develop-answers-fourth.md index 0ad1d984..b5860422 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-12-develop-answers-fourth.md +++ b/03-DESIGN/01-to-be/47-milestones/G-12-develop-answers-fourth.md @@ -27,7 +27,9 @@ decisions: One file of milestone G's part of [design 47](../47-delivery-from-commit-to-delivered.md); the part opens at [G.md](G.md). Its design lines are numbered across every file of the part and cited as "design 47 G §n". -*§522 is the operator's answer of 2026-11-11 at 12:11 CET at lead-47's terminal. Every other line answers a question +*§522 and §542 are the operator's answers of 2026-11-11 at 12:11 and 12:33 CET at lead-47's terminal. §543 to §550 +answer what the four reviewers found in round 3 of [G-13](G-13-review-round-3.md) (§600 to §609), which has no round +of its own after it. Every other line answers a question develop met after [G-11](G-11-develop-answers-review.md), of internal form only (playbook 07, step 0b), each the design's choice with its reason. What a question of another kind leaves open waits for the operator and is said in the line. Questions that an earlier line already answers have no line here: develop reads that line.* @@ -348,6 +350,108 @@ line. Questions that an earlier line already answers have no line here: develop 12:11 CET at lead-47's terminal, approved the words as the design writer proposed them. How it is checked: unit (teller), each of the three said in these words with its fields filled; whole (teller, router), as §514. +- §542 **An Approve given before G is that pull request's approval step.** The operator, 2026-11-11 12:33 CET at + lead-47's terminal: approval is a step whose status each module's registration sets, never a gate of its own, so + an Approve given before G counts, once G is delivered, as that pull request's `approval` step and nothing else is + special. At G's switch the gate says, for each `merges` key the old bridge had not performed, `approval-carried` on + `mesh.seat.mesh-delivery.event.approval-carried` (`repository`, `pull`, `commit` the head the Approve named, + `approver` the operator, `at`), declared in the seat's definition, and deletes the key once the bus acknowledges + it. The runner keeps each in its old `state` section `pipelines` as `carried-approval..`, + holding the commit, and takes it as the result `passed`, caller the operator, of the `approval` step of the first + pipeline or run at that commit, then deletes it; it deletes it unused when the seat `git` says the pull request + `pull-closed` or `pull-merged`. Where the module's policy makes `approval` `required`, a pull request whose head + moved after the Approve asks a new approval, as any step whose input changed does (an `approval` step is never + carried, ADR 0666 §8); where it is `optional` or `bypass`, the carried Approve holds nothing. The merge itself is + any merge (`merge-pull`, ADR 0666 §11): the bridge performs no carried act, the gate says no `wait-held` with + `step: merge`, and the watchman writes no `merge-waits`. Every `wait-held` the runner says for an `approval` step + has its `wait-ended`, said when the step ends in any of §24's outcomes (`passed`, `declined`, `superseded`, + `cancelled`, `not asked`) or its pipeline is superseded or cancelled, so no approval wait stands without an end. + This replaces §510 and §608, and `merge` leaves §498's list. Why: the operator's answer ("you're mixing in step and + approval gates, this should be configurable"); the event, the key and the deletion are the design's (round 3, + health and events' R7). How it is checked: whole (gate, runner), a carried Approve of a head passes that head's + `approval` step with the operator as caller; with `approval` `required`, a head moved after the Approve asks a new + approval; a pull request closed deletes its carried key; every `approval` wait-held in the whole test has its + `wait-ended`; the code review finds no `merge-waits`. + +## Round 3 of the review of §480 to §515 + +- §543 **A build seat's holder refuses a kind its asker may not ask.** Callers stay per accepted kind (§338), and the + builder joins them as the one caller, beside the checker until §483's removal, of the kind `build`, as §601 has it + ask under its name. The grants part grants each asker publish on `mesh.seat..accept..` (§600) + for every queue of the seat on which a kind it is a caller of is taken, and the holder, which takes the asker from + the subject (§481), refuses an ask whose body names a kind that asker is not a caller of, answering `error` naming + the kind and the asker, and ends it with `step-ended` `failed`. This amends §338 and §600. Why: §600 puts the queue + in the subject and the kind in the body, so a subject's grant alone cannot hold a caller to its kinds (round 3, + security and upgrade, seams and tools: R1). How it is checked: unit (Go build module), a `step` published from the + indexer's account is answered `error` naming `step` and `indexer`; unit (grants part), each asker's grants are the + queues of its kinds. +- §544 **Named asks have a worker of their own.** For each queue the grants part makes, beside main's worker + `SEAT___worker` filtered to main's `mesh.seat..accept.` alone, a second worker + `SEAT___named_worker` filtered to `mesh.seat..accept..*`; the two filters do not overlap, + so the work-queue stream takes both. Only a holder of G pulls the named worker, and a holder of before G knows only + main's, so no filter is ever switched and a holder of before G that comes back from away (a laptop) after the grants + part runs takes no named ask. This replaces §601's "until every node's holder of a build seat is of G the grants + part's worker keeps main's one filter", and with it the edge from the seats' holders to the grants part, which no + manifest fact gives: the order is the asker's `invokes` of `.accept.` (kind 6, from the seat's holders + to the asker, §601), and the grants, written for a catalog revision before any want of it (*A credential and a + composition before the want*), exist before the asker runs. A named ask waits on its worker while no holder of G + runs, said by `build-capacity-waits` after 60 minutes, which corrects §483's "waits on the work queue, whose + consumer of before G takes only main's subject". At a revert, which reverts the askers before the grants part (ADR + 0656 §4), the grants part of G, when it no longer hears any asker of G, purges the subjects + `accept..*` of the stream and deletes the named workers, saying each in its journal; an ask is transport, + not kept data (as §59 has a sent object). Why: one consumer per filter, and a filter that never moves cannot be + pulled by a holder that does not read it (round 3, R2, the security reviewer's form). How it is checked: whole + (grants part, Go build module), a holder of before G started after the grants part of G takes main's asks and no + named one; a revert leaves no named worker and no named ask. +- §545 **The tool runner's artifact declares the words it states.** The artifact entry of the tool runner's manifest + takes `states`, the capability words (§488) it states; the manifest validator refuses a package artifact's `calls` + word (§605) that no artifact of the revision `states`, naming the word, and the delivery plan's edge of §605 runs to + the module whose artifact `states` that word, so no manifest names the tool runner's module. A bundle is started by + the tool runner on its channel and ends with it, so a restart of the tool runner restarts its bundles, and each + reads the stated words at its own start; no event is heard and nothing polls. This amends §605's "each time the + tool runner of its node starts". Why: the words are stated only at run time, and the plan needs them in a manifest + (round 3, seams and tools: R3). How it is checked: unit (manifest validator), a `calls` word nothing `states` + refused; unit (delivery plan), the edge to the module stating the word. +- §546 **When the builder forgets a node's toolchain.** The builder deletes its `toolchains-heard` key + `.` (§604) when the node-engine seat's `running..` says `stopped` (§365) for the + module whose catalog graph entry claims the build seat of that language (its `acts` rule `build` with `on` naming + it, §535), heard through the durable consumer it already has of that seat's `running`; never on a placement, which + is the seat `mesh-module-assigner`'s state. The state is an old `state` section of the builder, a foundation part, + one key per node and language, about 12 keys of about 0.3 KiB each, capped at 1 MiB, so it adds no objects store + to §607's count (§58 plans one only for a state of the template); `builder_toolchains` reads it and + `builder_toolchains_drop` deletes one key, with why, written in the hand-act log of the seat `mesh-hand-acts`; a + holder says the key again at its start and on each change (§492). This amends §604's "when the node leaves the + catalog's placements". Why: the builder reads no other module's state (ADR 0596 §2; round 3, seams and tools: R4). + How it is checked: whole (builder), a build module stopped on a node deletes that node's key, and the drop tool + deletes one key and logs it. +- §547 **The sum of the bus's caps is read against its limit.** The bus module reads the bus's storage limit from the + server's account information at its start and at each plan, sums the cap of every entry it plans (states, objects + stores, sent stores, streams, logs) and of every old section the catalog graph's entries declare, and shows both in + its `list` and its read tool. A plan whose sum passes the limit is refused, naming the sum and the limit, said as + its `refused` (ADR 0595 §6), whether or not the server reserves a cap at creation. When G's check measures that the + server reserves a cap when a store is made (§607), each `-objects` is planned with 16 MiB instead of 64 MiB + (about 2.4 GiB for 150 states), a state needing more naming `objects-max-mib`. This amends §607. Why: the limit is a + fact of the server, read rather than written in the design, and a sum over it fails loudly (round 3, running and + testing: R5). How it is checked: whole (bus module), a fixture server with a small limit refuses a plan past it, + naming the sum; the sum and limit are in `list`. +- §548 **The forge module writes `seen` only from the runner's steps.** §487's `seen..` is written + only from a `step-ended` whose asker is `runner`; the `step-ended` of any other ask (§602) carries `asker`, `ask`, + `node`, `outcome` and `at` and nothing of a pipeline, and the forge module writes nothing from it. This amends §487. + Why: since §602 every ask says `step-ended`, and a builder's build is no run of a commit (round 3, health and + events: R6). How it is checked: unit (forge module), a builder's failed build writes no `seen`; whole (watchman), a + `stuck` raised for an ask clears on its late `step-ended`. +- §549 **Smaller corrections from round 3.** At its start the runner appends an `unlogged` entry (§606) only after + reading back its `step-log`'s last entry of that pipeline and step, and skips it when that entry is already + logged, so a stop between the append and the clear appends nothing twice. `step-progress` and `ask-taken` (§603) + name no `keep` and go on EVENTS, kept 7 days (§396). `runner_unlogged_append` is of class `act` and takes §391's + default callers. §58 is planned with the cap §607 and §547 give. How it is checked: whole (runner), a runner + stopped between the append and the clear logs the entry once; the rest as the lines they correct. +- §550 **A publication's pipeline keeps the version.** The runner's pipeline value gains `version`, the version + `package-published` names, for a pipeline the runner started from a publication or from `outdated` (§334), and + none for any other; `show` answers it. This completes §334's "the version in the pipeline's state". Why: the + runner's contract had no field for it (develop's note on §334). How it is checked: unit (runner's contract), the + field read; whole (runner), a publish's pipeline shows its version. + ## Questions an earlier line answers These write nothing new; develop reads the line named. @@ -355,8 +459,8 @@ These write nothing new; develop reads the line named. - The tool runner's fallback of local commit 1015b38 for a foundation part's bundle goes: §407 binds that bundle to its old `objects` section, and a binding that is missing fails loudly (ADR 0595 §1) (Q-T5, T-11). - The re-read tool's callers of `seatlist.Part` are §204's for every part, the assigner's own list going (AS19). -- The bus module's cap of a state's objects store and the binding's `objects` and `sent-objects` are §513's (NATS1, - §399). +- The bus module's cap of a state's objects store is §513's as §607 and §547 amend it, and the binding's `objects` + and `sent-objects` are §513's (NATS1, §399). - The contracts' `Hold` is §194's view, the newest assignment half and the catalog half it names; the candidate's whole-half reader is §195's and §441's, read by a run on request's steps, `grants-for` and the indexer's candidate pass (contracts). diff --git a/03-DESIGN/01-to-be/47-milestones/G-13-review-round-3.md b/03-DESIGN/01-to-be/47-milestones/G-13-review-round-3.md index b1d0995d..1df54617 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-13-review-round-3.md +++ b/03-DESIGN/01-to-be/47-milestones/G-13-review-round-3.md @@ -28,7 +28,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12. *These lines answer what the four reviewers by architectural domain found in round 2 of [G-11](G-11-develop-answers-review.md) (§480 to §515), the last round. Each is the design's choice with its reason.* -- §600 **A build seat's asks: subjects, workers and grants.** A build seat (`node-build-go`, `node-build-node`, +- §600 **A build seat's asks: subjects, workers and grants.** (§543, §544) A build seat (`node-build-go`, `node-build-node`, `node-build-image`) keeps its three queues of main, `delivery`, `check` and `recheck` (ADR 0525 §4, ADR 0536 §4), on its one work-queue stream. An ask is published on `mesh.seat..accept..`, `` one of the three, `` the asker's name; the ask's kind (`step`, `run`, a build) stays in its body, as on main. The @@ -43,7 +43,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12. checked: unit (grants part), each queue's worker filters both subjects and each asker's grant is its own name; whole (grants part, Go build module), an ask under `runner` is taken and answered, and the runner's account publishing on main's `accept.check` is refused. -- §601 **The order of G's rollout for the build seats.** The holders of the three build seats are delivered first, +- §601 **The order of G's rollout for the build seats.** (§544) The holders of the three build seats are delivered first, then the grants part, whose workers then filter both forms (§600), then every asker of G (the runner, the indexer, the assigner, the builder) and the watchman. Until every node's holder of a build seat is of G the grants part's worker keeps main's one filter, so a holder of before G never takes a named ask, whose key it would write in main's @@ -68,20 +68,20 @@ takes §600 on, since §516 on are those of batch 4's file G-12. `stuck`, naming the seat, the asker, the ask and the node, as main's mirror does. This completes §496. Why: only the runner says `step-started` (review round 2, health and events 1). How it is checked: whole (watchman, Go build module), a builder's build whose holder stops raises `stuck` within five minutes and one that ends raises nothing. -- §603 **Where `step-progress` and `ask-taken` go.** Both are seat events and go on the stream that carries the seat's +- §603 **Where `step-progress` and `ask-taken` go.** (§549) Both are seat events and go on the stream that carries the seat's events, at that stream's own age; no stream is added and no event's age changes. `step-progress` and `ask-taken` are declared in the three build seats' definitions in `mesh-delivery-contracts`, and `step-progress` in `mesh-wants`' definition for a composition step. This amends §496's "kept on the seat's stream for a day". Why: a build seat's own stream is its asks' work queue (review round 2, running and testing 4, seams and tools' note). How it is checked: unit (definitions), each event declared. -- §604 **The builder keeps the toolchains it heard.** The builder writes each `toolchain-reported` (§492) in a state of +- §604 **The builder keeps the toolchains it heard.** (§546) The builder writes each `toolchain-reported` (§492) in a state of its own, `toolchains-heard`, one key `.` holding the version, the recipe, the digest and when it was said, and agrees the version from those keys, read back at its start, so a restart needs no node to report again. Its manifest `consumes` the three build seats' `toolchain-reported`; its tool `builder_toolchains` lists the keys; a key is deleted when the node leaves the catalog's placements (§365's reason). Why: a durable consumer does not deliver an acknowledged event again (review round 2, seams and tools 1). How it is checked: whole (builder), a restarted builder agrees the same version with no new report. -- §605 **The order after G's tool runner is derived from the package a build resolved.** A package's artifact in a +- §605 **The order after G's tool runner is derived from the package a build resolved.** (§545) A package's artifact in a manifest takes `calls`, the capability words (§488) its code calls of the tool runner; mesh-sdk's Go and npm packages name `ledger-upkeep-calls`, `sent-objects-calls` and `put-sessions` from G. For each module whose build resolved a version of such a package (§466's `resolved`), the delivery plan derives a served-word edge (kind 6) to @@ -90,7 +90,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12. This amends §488's `needs`. Why: the bundle makes a session whenever a value is large, so only the package knows (review round 2, seams and tools 3, running and testing's note). How it is checked: unit (delivery plan), a module built on G's mesh-sdk is ordered after the tool runner on each node; unit (manifest validator), `calls` read. -- §606 **A step's end and its unlogged entry are one write.** The runner writes a step's end in `pipelines` with the +- §606 **A step's end and its unlogged entry are one write.** (§549) The runner writes a step's end in `pipelines` with the entry as `unlogged` in the same compare-and-set, appends it to `step-log`, then clears it; at its start it appends every `unlogged` entry of its pipelines, in order. It reads the log's fill again at each step's end, at its start, and once a minute while the log is `full`, so the entries the bus ages out say `room` with no step ending. Its tool @@ -99,7 +99,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12. full log (review round 2, running and testing 2, health and events 3, seams and tools' note). How it is checked: whole (runner), a runner stopped after a step's end appends its entry at start; a full log whose oldest entries age out says `room` with no step ending. -- §607 **A state's objects store has the state's size.** Each `-objects` (§58) is planned with the state +- §607 **A state's objects store has the state's size.** (§547) Each `-objects` (§58) is planned with the state template's size, 64 MiB, unless the state's `requires` names `objects-max-mib`; the sent stores keep §477's 256 MiB. An estimated 150 states across about 120 modules give about 9.4 GiB of caps. Whether the bus counts a cap against its storage limit before anything is written is measured in G's check (the bus module's whole test reads @@ -108,7 +108,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12. its owner. This amends §513 and leaves §58's "reserves nothing" to that measurement. Why: §58 names the template's size (review round 2, running and testing 3). How it is checked: unit (bus module's plan), each objects store's cap; whole (bus module), the reserved storage read after the plan. -- §608 **A carried merge that waits is a timed wait.** A merge act carried by the switch (§510) waiting for the first +- §608 **A carried merge that waits is a timed wait.** (§542) A merge act carried by the switch (§510) waiting for the first registrations is said by the gate as `wait-held` with `step: merge` (added to §498's list), naming the pull request and the head the Approve named, bounded at 60 minutes; past it the watchman writes `merge-waits`, which the condition keeper raises and `wait-ended` clears. It merges only the head the Approve named: a pull request moved diff --git a/03-DESIGN/01-to-be/47-milestones/G-2-pipelines-sizes-checks-and-tools.md b/03-DESIGN/01-to-be/47-milestones/G-2-pipelines-sizes-checks-and-tools.md index c8f6b8aa..59f768e6 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-2-pipelines-sizes-checks-and-tools.md +++ b/03-DESIGN/01-to-be/47-milestones/G-2-pipelines-sizes-checks-and-tools.md @@ -41,7 +41,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli compare-and-set; the object it replaced stays, as one whose key was deleted does, listed as `key gone` since no key names it, and only the drop tool removes either, on a person's word: the mesh removes kept data only through `drop` and `recreate`, each on a person's word (ADR 0595 §4; ADR 0666 §16). -- §58 **One object store per state, granted to its owner.** (§513) Each state asked by the template `state` gets its object store +- §58 **One object store per state, granted to its owner.** (§513, §549) Each state asked by the template `state` gets its object store beside it, `-objects`, a template form of ADR 0595 that the bus module provides and the grants part grants to the state's owner alone (ADR 0666 §16); a foundation part's large values go in an old `objects` section of its own. Its size is the template's (ADR 0595 §3). An object store holds no space until a value is written to it, so the many diff --git a/03-DESIGN/01-to-be/47-milestones/G-7-answers.md b/03-DESIGN/01-to-be/47-milestones/G-7-answers.md index 37b8d268..92fde3cb 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-7-answers.md +++ b/03-DESIGN/01-to-be/47-milestones/G-7-answers.md @@ -124,7 +124,7 @@ record it follows from, and replaces the builder's own choice where one was made `take-in.taken` (ADR 0666 §13), which ADR 0596 §1 lets any module subscribe to; the indexer's name stands in that manifest only, never in the runner's code. Why: ADR 0666 §13, in force, names that event. How it is checked: the code review reads that no module name stands in the runner's code (§7). -- §334 **A publication's pipelines and their key.** `package-published` carries the package's artifact reference +- §334 **A publication's pipelines and their key.** (§550) `package-published` carries the package's artifact reference (`:`, from the catalog entry), its version and digest, the watched branch and the source revision its build was made from. The runner asks `outdated` for that package on that branch and starts a pipeline for each dependent `outdated` names behind (§53), keyed by that branch, that source revision and the dependent module, the version in the pipeline's state; a `take-in.taken` of the same revision and module is the @@ -165,7 +165,7 @@ record it follows from, and replaces the builder's own choice where one was made and restore a module's kept data on the bus name `holder:node-backup@same-node`. Why: only that holder takes them (*A backup before the apply: kept data on the bus*). How it is checked: a call from another node's `node-backup` holder is refused by the bus. -- §338 **Callers on accepted kinds.** (§480, §481) An accepted kind of a work queue carries `callers` as a verb does, and the grants part +- §338 **Callers on accepted kinds.** (§480, §481, §543) An accepted kind of a work queue carries `callers` as a verb does, and the grants part grants publish on its subject to them alone: the build seats' `step` the runner; `run` the runner, the indexer and the assigner, and the checker until its entry is removed with its buckets and bus account (ADR 0667 §12); `mesh-wants`'s `step` the runner. Verbs: `steps` the runner and the indexer (its seed); `drop` the runner and the builder; both diff --git a/03-DESIGN/01-to-be/47-milestones/G.md b/03-DESIGN/01-to-be/47-milestones/G.md index 246bce2b..fd39d942 100644 --- a/03-DESIGN/01-to-be/47-milestones/G.md +++ b/03-DESIGN/01-to-be/47-milestones/G.md @@ -89,5 +89,5 @@ The part is thirteen files, each read whole, its design lines numbered across th - [G-9-prepare-answers](G-9-prepare-answers.md): the answers to the questions of G's final prepare and develop's first questions (§391 to §455). - [G-10-develop-answers](G-10-develop-answers.md): the answers to develop's second batch of questions, the operator's and those of internal form only (§456 to §479). - [G-11-develop-answers-review](G-11-develop-answers-review.md): the operator's answers of 2026-11-11 noon, the review of §456 to §479, and develop's next questions (§480 to §515). -- [G-12-develop-answers-fourth](G-12-develop-answers-fourth.md): the operator's words of 2026-11-11 and develop's fourth batch of questions (§516 to §541). +- [G-12-develop-answers-fourth](G-12-develop-answers-fourth.md): the operator's words of 2026-11-11 and develop's fourth batch of questions (§516 to §550). - [G-13-review-round-3](G-13-review-round-3.md): the review of §480 to §515, rounds 2 and 3 (§600 on).