From 0cdd66f945f7cc444d76723ec1c00fa5c5adfd08 Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 11 Nov 2026 15:23:04 +0100 Subject: [PATCH] Answer milestone G's sixth develop batch in design 47 so develop builds without choosing MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Eight questions met in the join and develop after batch 5 are written as lines §587 to §594 of a new part G-16, each of internal form within the records and lines it cites: the ledger's upkeep calls' shapes, publishing again every unpublished reserved version, a whole read of a module's build keys, one event of a node's capabilities (manifest-reads-changed, ADR 0618 §4, ADR 0673 §2), the object stores' caps, the gate's merge path from G's delivery, the gate's dropped Approve-per-merge reads, and the manifest readers on the catalog graph entry. §568 now cites ADR 0673 in place of "number to come". The automatic publish on a registry holder's running is left to the operator: no record decides it. Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ --- .../47-delivery-from-commit-to-delivered.md | 1 + .../47-milestones/G-10-develop-answers.md | 4 +- .../G-11-develop-answers-review.md | 5 +- .../G-15-develop-answers-fifth.md | 25 +-- .../G-16-develop-answers-sixth.md | 186 ++++++++++++++++++ .../G-3-delivery-record-and-graphs.md | 21 +- .../G-4-revision-view-and-steps.md | 6 +- .../47-milestones/G-9-prepare-answers.md | 3 +- 03-DESIGN/01-to-be/47-milestones/G.md | 4 +- 9 files changed, 220 insertions(+), 35 deletions(-) create mode 100644 03-DESIGN/01-to-be/47-milestones/G-16-develop-answers-sixth.md 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 cedccf88..d5c35129 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 @@ -4,6 +4,7 @@ status: in-progress code: [mesh-controller, mesh-catalog modules/mesh-delivery-gate, mesh-catalog modules/gitea, mesh-delivery, mesh-host, mesh-sdk, mesh-vault, mesh-contracts, mesh-tools, mesh-networking, hq 00-META/checks] updated: 2026-11-11 decisions: + - "ADR 0673" - "ADR 0667" - "ADR 0666" - "ADR 0664" diff --git a/03-DESIGN/01-to-be/47-milestones/G-10-develop-answers.md b/03-DESIGN/01-to-be/47-milestones/G-10-develop-answers.md index 256f9aaf..f4756403 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-10-develop-answers.md +++ b/03-DESIGN/01-to-be/47-milestones/G-10-develop-answers.md @@ -117,8 +117,8 @@ each the design's choice with its reason, §468 to §479 those of the runner's, says no set; §383's and §384's checks. - §462 **Where the bus state calls and their capabilities land.** (§488) The calls' names and shapes are in mesh-sdk's `go/buscalls`, which holds only those (its package's own rule): §408's ledger calls are `mesh/ledger.fill` (one - ledger's fill against its cap, as `buscalls.Fill`) and `mesh/ledger.remove` (one instance removed with its - operations and its snapshot, §155), and §407's `mesh/objects.sent-get`. The capability each belongs to is listed + ledger's history's fill against its cap, as `buscalls.Fill`, §587) and `mesh/ledger.remove` (one instance removed with its + operations and its snapshot, §155, its request and answer §587's), and §407's `mesh/objects.sent-get`. The capability each belongs to is listed where the capabilities are today, in the tool runner in mesh-tools (its families of calls per capability): the two ledger calls under `ledger-calls`, `mesh/objects.sent-get` under `bus-state-calls`. mesh-sdk gains no capability list. This amends §347 ("mesh-sdk lists") and §408. Why: the tool runner states the capabilities of the calls it 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 bd707d82..7b951f1b 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 @@ -295,9 +295,8 @@ reason. What a question of another kind leaves open waits for the operator and i `wait-held` with `step: delivery` (§498) and `version-delivered`'s machines away. Why: §186 has the tiers worked out from the difference and the owners' waits (develop questions VW2, VW3 and on §431). How it is checked: test 45; test 106 for the delivery wait. -- §513 **A state's objects store has a cap of 256 MiB, and the binding is mesh-sdk's.** (§607) The bus module plans each - `-objects` (§58) with a cap of 256 MiB, as a sent store (§477), unless the state's `requires` names - `objects-max-mib`. The binding's `objects` and `sent-objects` (§399) are fields of mesh-sdk's +- §513 **A state's objects store has a cap, and the binding is mesh-sdk's.** (§607, §547, §591: the cap is §591's) The bus module plans each + `-objects` (§58) with the cap §591 names, unless the state's `requires` names `objects-max-mib`. The binding's `objects` and `sent-objects` (§399) are fields of mesh-sdk's `membership.BusBinding`, built in mesh-sdk. Why: the objects template has no default (develop questions NATS1 and on §399). How it is checked: unit (bus module's plan), each planned objects store has its cap; unit (membership), both fields read. diff --git a/03-DESIGN/01-to-be/47-milestones/G-15-develop-answers-fifth.md b/03-DESIGN/01-to-be/47-milestones/G-15-develop-answers-fifth.md index 88b9ad61..ce4fcb0d 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-15-develop-answers-fifth.md +++ b/03-DESIGN/01-to-be/47-milestones/G-15-develop-answers-fifth.md @@ -5,8 +5,10 @@ design: 47 milestone: G updated: 2026-11-11 decisions: + - "ADR 0673" - "ADR 0672" - "ADR 0668" + - "ADR 0618" - "ADR 0667" - "ADR 0666" - "ADR 0664" @@ -247,7 +249,7 @@ form only. A note that corrects a line of G-12 or G-14 is written in that line; ## The builder - §568 **A transport fault in the builder's own read ends no build key, and a key's error says which kind of fault it - is.** (ADR 0664 §1 to §3, ADR 0668 §1 to §3; issue 1612, met again 2026-11-11) + is.** (ADR 0664 §1 to §3, ADR 0668 §1 to §3, ADR 0673 §1 to §4; issue 1612, met again 2026-11-11) - **The builder's own reads.** The builder's reads of the build seats' state `steps` (its own step keys, §467, §481) are kept calls (ADR 0668 §1, §2). A read that meets a transport fault, of ADR 0664 §1's classes or the read's own deadline, changes nothing the builder holds and writes no build key. The builder's watch of `steps` @@ -261,12 +263,13 @@ form only. A note that corrects a line of G-12 or G-14 is written in that line; build's own words) and never opens `transport fault:`. The builder's read tools show the error whole, so a reader tells a passing cause from a real one without the journal. - **What builds such a key again.** The operator, 2026-11-11 about 14:15 CET at lead-47's terminal, decided by the - record of the builder's retry (number to come), which changes ADR 0664 §3: a key whose error opens `transport + record of the builder's retry, ADR 0673 §1 to §3, which changes ADR 0664 §3: a key whose error opens `transport fault:` is built again, once, as a new revision of the key (ADR 0429 §18), on the first event after its failure - that says its cause passed. Two events say so: the node-engine seat's `running..` saying `running` - for a module whose catalog graph entry claims the build seat the failed step ran on (§546), on any node; and the - node-engine's `manifest-reads-changed` of the node the failed step ran on (ADR 0668 §4), which it says when that - node is heard again. The builder hears both through its consumers of the node-engine seat, read as §556 has it. + that says its cause passed. Two events say so (ADR 0673 §2): the node-engine seat's `running..` + saying `running` for a module whose catalog graph entry claims the build seat the failed step ran on (§546), on + any node; and the node-engine seat's `manifest-reads-changed` of the node the failed step ran on with `why` + `returned` (ADR 0618 §4, ADR 0668 §4; §590), which it says when that node is heard again after being away. One + saying `why` `started` builds nothing again. The builder hears both through its consumers of the node-engine seat, read as §556 has it. It builds a key again at most once per event heard, and only while the key's newest revision is that failure, so one event starts one revision. A revision that fails again on a transport fault is said as every failed key is, its error opening `transport fault:` again, and waits for the next such event. The builder's manifest `consumes` @@ -280,18 +283,16 @@ form only. A note that corrects a line of G-12 or G-14 is written in that line; *Leave it*, a decline or the ask's expiry leaves the key failed until `builder_build_again` or a new fingerprint. The failure stays said throughout. A key failed for any other cause is never built again on these events. `builder_build_again` (ADR 0668 §5) and the builder's next start build it - again too, as before. The builder's read tool of a key names the event that built its newest revision again, - `event-builds`, and the open ask. - - **Before develop.** These lines rest on the record of the builder's retry, which changes ADR 0664 §3 (in force); - it is accepted before G's builder is built from them, and its number replaces "number to come" here. + again too, as before. The builder's read tool of a key, `builder_build` (§589), names the event that built its + newest revision again, `event-builds`, and the open ask. Why: a read the builder made met `no responders` and failed a key, which then stayed failed for about 45 minutes (issue 1612, 2026-11-11), against ADR 0664 §3 (a key is not written failed while its step runs on); the retry on an event is the operator's answer. How it is checked: unit (builder), a `no responders` read of `steps` leaves the key `building` and the next revision ends it; a third-run transport fault's key error opens `transport fault: no responders`, and a compile error's does not; a `running` of a holder of that build seat builds the key again once, - and a second `running` while the new revision builds starts nothing; a node's `manifest-reads-changed` builds again - a key failed on that node; a key failed on a compile error is not built again on either event; after three failed + and a second `running` while the new revision builds starts nothing; a node's `manifest-reads-changed` with `why` + `returned` builds again a key failed on that node, and one with `why` `started` does not; a key failed on a compile error is not built again on either event; after three failed event-started revisions the fourth event asks the operator once and builds nothing, and *Build once more* builds one. diff --git a/03-DESIGN/01-to-be/47-milestones/G-16-develop-answers-sixth.md b/03-DESIGN/01-to-be/47-milestones/G-16-develop-answers-sixth.md new file mode 100644 index 00000000..32f46a1a --- /dev/null +++ b/03-DESIGN/01-to-be/47-milestones/G-16-develop-answers-sixth.md @@ -0,0 +1,186 @@ +--- +layer: to-be +status: in-progress +design: 47 +milestone: G +updated: 2026-11-11 +decisions: + - "ADR 0673" + - "ADR 0672" + - "ADR 0668" + - "ADR 0667" + - "ADR 0666" + - "ADR 0664" + - "ADR 0656" + - "ADR 0618" + - "ADR 0615" + - "ADR 0614" + - "ADR 0597" + - "ADR 0596" + - "ADR 0595" + - "ADR 0441" + - "ADR 0429" +--- + +# 47, milestone G: develop's sixth batch + +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". + +*§587 to §594 answer develop's sixth batch (lead-47's input of 2026-11-11, met in the join and develop after §560 to +§586). Each is of internal form only, within what the records and the lines it cites decide; §588 leaves one question +to the operator, said in it. A line of another file that one of them corrects is corrected in that line (§169, §170, +§171, §177, §226, §404, §462, §513, §568, and the event table of G-4); here only what is new.* + +## The ledger's upkeep calls + +- §587 **`mesh/ledger.fill` answers the history's fill, and `mesh/ledger.remove` has a request and an answer of its + own.** (§408, §462, §488, §155; ADR 0597 §1, §8, §10, §13) Both calls are in mesh-sdk's `go/buscalls`, as the + constants `LedgerFill` (`mesh/ledger.fill`) and `LedgerRemove` (`mesh/ledger.remove`), under the capability word + `ledger-upkeep-calls` (§488), served by the tool runner for the calling module's own ledgers alone, as every call of + the package is. + - **The fill.** The request is `LedgerRequest`, `{ledger}`, the ledger's local name in `requires`. The answer is + `buscalls.Fill` of the ledger's history alone: its messages, its bytes and the ledger's `cap` in bytes. The + history holds every operation and each instance's snapshot subject (ADR 0597 §1, §8), and the ledger's cap is + its history's (design 25's template row for a ledger, its state and index buckets being states), so neither the + fullest of the parts nor their sum is answered. A full state bucket is said by `apply`'s `state_behind` (ADR 0597 + §6), not by this call. The gate's `filling`, `full` and `room` (§181) and `gate_records` (§159) judge this answer + against the 768 MiB of §155. + - **The removal.** The request is `LedgerRemoveRequest`, `{ledger, instance}`. The tool runner removes the + instance's operations and its snapshot from the history (by the instance's subjects), its key in the state bucket + and its keys in every declared index, and answers `LedgerRemoved`, `{instance, operations, bytes}`: the number of + operations removed and the bytes the history held less after the removal. An instance the ledger does not hold + answers `operations` 0 and `bytes` 0, so a removal said twice changes nothing. `Applied` gains no field: a + removal is no operation of the history and has no author. Only the owner's bundle calls it, through its tool + runner (ADR 0597 §13 leaves any other caller to the design, and the design names none); the gate calls it for a + record past its retention (§154). + + This amends §462's "as `buscalls.Fill`" and its removal, which named no shape. Why: one cap, the history's, is + the ledger's, and a removal is not an operation (develop questions on §462 and §408, join of the tool runner). How + it is checked: unit (`buscalls`), each request and answer read; unit (tool runner), a fill answers the history's + bytes against the cap with snapshots counted, a removal answers the operations it removed, and a removal of an + unknown instance answers 0; whole (gate), a record past its retention is removed and the next fill is lower. + +## The builder's publishes and its reads + +- §588 **`builder_publish_again` publishes again every reserved version left unpublished, one module at a time.** + (§52, §369, §381; *Tools are how a module is spoken to*) The builder's tool `builder_publish_again` (class `act`, + its callers and its writing in the hand-act log as they are) takes `module` + and `version`, each optional, and `why`: + - **With both**, it publishes again that reserved version's missing artifacts, as §52 has it. + - **With `module` alone**, it publishes again each reserved version of that module whose artifacts are not all + published: at most one per `MAJOR.MINOR`, since §369 keeps one key per module and `MAJOR.MINOR` and a + superseded build's version is never released. + - **With neither**, it does so for every module whose reserved version the finding `version-unreleased` names + (§369), one module after another, the newest key first. + - **Its bound.** A publish sends the artifacts the build stored, by their digests, to the holder of the registry + seat of their kind, and builds nothing, so it takes no build capacity. An artifact no store holds is not built + by this tool: the tool names it, and its build key is built again by `builder_build_again`. The builder sends one + publish at a time to each registry seat holder, each bounded by §369's 10 minutes. The tool answers at once with + the versions it started, and each outcome is said as `package-published`, or left in `version-unreleased` with + the holder's words. + + Why: §369 gave the tool one version, and a recovery of a registry holder away for hours left many (lead-47 in the + registry recovery, issue 1966 note 206). How it is checked: whole (builder, with a fake registry holder), a holder + that refused three modules' publishes, then answers: one call with neither argument publishes the three, one at a + time, and clears their `version-unreleased`; an artifact no store holds is named and not built. + + **Left to the operator:** whether the builder also publishes these again by itself, on the node-engine seat's + `running` of a module whose catalog graph entry claims a registry seat (as ADR 0673 §1 to §3 builds a key again on + a build seat holder's `running`), once per event heard. No record decides an automatic publish: ADR 0673 covers + build keys only. It changes what the operator sees (findings that clear themselves) and what the registries keep. + Lead-47 asks it; until it is answered, G's builder publishes again only on this tool. +- §589 **`builder_build` answers a module's build keys whole.** (§348, §568, §575; *one-question-one-tool*) The + builder's tool `builder_build` (class `read`) takes `module` and, optional, `fingerprint`. With `fingerprint`, it + answers that key whole; with `module` alone, the module's build keys newest first, at most 20, each with its + `fingerprint` whole (the build-input fingerprint as the catalog graph entry carries it, never cut), `state` + (`queued`, `building`, `done` or `failed`), the key's revision and since when, the step and its node, the error + whole, `event-builds` and the open ask (§568), and `newest: ` for each watched branch whose newest catalog + graph entry of the module names that fingerprint, read from the builder's own view of the catalog half (§348). A + module none of whose keys the newest entry names says so, naming the entry's fingerprint. Beside it, + `builder_builds_since` gains `module`, which narrows its answer to that module's builds, and `builder_stuck` + answers each key's fingerprint whole. Which node wants which fingerprint is the assigner's to answer, through the + seat `mesh-wants`, never the builder's (ADR 0596); the words of a want's hold (§575) may shorten a fingerprint for + reading, while every field named `fingerprint` in a tool's answer is whole. Why: no read answered a module's + wanted build whole in one call (lead-47, issue 1966). How it is checked: unit (builder), `builder_build` by module + answers its keys with whole fingerprints and marks the one the newest entry names; `builder_builds_since` with + `module` answers that module's builds alone. + +## A node's capabilities, said once + +- §590 **One event says a node's capabilities: `manifest-reads-changed`.** (§177, §226, §404; ADR 0618 §3, §4, ADR + 0673 §2, ADR 0614 §4) The node-engine seat's event `manifest-reads-changed`, on + `mesh.seat.node-engine.event.manifest-reads-changed.`, published only by that node's node-engine (ADR 0363 + §2), is the one event of a node's stated capabilities. It carries, as the seat's definition already has it, + `node`, `manifest-reads` (every capability the engine states now, whole), `at`, and `why`: `started` when the + engine started or what it states changed, `returned` when its node is heard again after being away (ADR 0673 §2). + G adds no event `capabilities-changed`: §177, §226, §404 and G-4's event table name `manifest-reads-changed` in + its place. + - **The assigner** consumes it, asks the seat's `manifest-reads` of that node again (ADR 0618 §3, §4), and makes a + new assignment graph revision only when the capabilities answered differ from those its newest revision placed + on, so a `returned` that changes nothing makes no revision. + - **The builder** consumes it as ADR 0618 §4 and §568 have it, and builds a key again only on `returned`. + + Why: two events of one fact, one decided (ADR 0618 §4) and one the design's (§226), are a second source of the + same fact, and ADR 0673 §2 builds on the decided one's `why` (lead-47, on ADR 0673). How it is checked: unit + (assigner), a `started` with new capabilities makes a revision and a `returned` with the same ones makes none; + the code review finds no `capabilities-changed` in any module or seat definition at G's heads. + +## The bus's object stores + +- §591 **Which cap governs which object store.** (§58, §477, §513, §547, §607) The bus module plans: + - **each `-objects`** with 16 MiB, unless the state's `requires` names `objects-max-mib` (§547, which + replaced §607's 64 MiB, which replaced §513's 256 MiB); + - **each `_sent-objects`** with 256 MiB (§477, kept by §607); + - **a foundation part's old `objects` section** with the `max-mib` it declares, `sent-objects` 256 (§477). + + No store is planned with 1024 MiB; the bus module's earlier commit that did is changed to these. Every one of + them counts in §547's sum against the account's limit. Why: three lines in sequence named three caps for one + store (develop question NATS1, join of the bus module). How it is checked: unit (bus module's plan), a table of the + three kinds with their caps, and a state naming `objects-max-mib` planned at that size. + +## The gate from G's delivery + +- §592 **The gate's merge path from G's delivery, whole.** (§97, §150, §151, §156, §162, §164, §166, §167, §169, + §542; ADR 0666 §10, §11, ADR 0596) The gate makes no merge and hands none to the forge: + - **Who merges.** A session merges through the seat `git`'s `merge-pull` (ADR 0666 §11). The gate calls no + `merge-pull`, its manifest `invokes` none, and it says no `owed` act `merge`: `owed`'s acts are the delivery's + view, a comment and the note's line (§167). The merge as an owed act is not built. + - **How the gate learns a merge.** From the indexer's `take-in.taken`, one record per source revision of a + watched branch the indexer takes in, a group's members in one (§151). The gate does not consume the forge + bridge's `merged` and `pushed` messages on its stream `forge` (§509); those are the indexer's. It consumes from + that stream only `owed.ended` (§164), through a durable consumer its manifest's `consumes` declares and its + binding names, so the gate's code names no module: the forge bridge's module name leaves the gate's code. + - **A group.** Its members land one by one (*Groups*), its end the runner's `group-ended` (§431); §166's order of a + group's merges ends at G's delivery. + - **What was owed at the switch.** Each `owed` key the old bridge had not performed becomes an act (§169). Each + `merges` key it had not performed is said once as `approval-carried` (§542) and becomes no act. The gate writes + `merges` no more (§156) and reads it no more, and keeps it until §97's removal (§542). + - **The approval.** No Approve is asked per merge (§150); an `approval` step's answer is the runner's (ADR 0666 + §10, §542). + + This replaces the merge parts of §169 and §171, and §170 from G's delivery. Why: the join kept the old hand-off + (`merges`, the bridge's messages, the bridge named in code) beside the owed acts, and the lines were spread over + four places (join of the gate). How it is checked: unit (gate's manifest), no `invokes` of `merge-pull` and no + `consumes` of `merged` or `pushed`; the code review finds no module name of the forge bridge in the gate's code + and no act `merge`; whole (gate, bridge), a merge made through `merge-pull` opens one record from `take-in.taken`, + and a `merges` key at the switch is said `approval-carried` and performed by nobody. +- §593 **The gate hears neither the teller's answers nor the view's reach.** (§150, §431, §512) The gate's reads of + the teller's `answered` and the status view's `reached`, and its calls of `teller_answers` and `view_reach`, served + the Approve per merge, which goes at G's delivery (§150, §431): the gate's `asks` go with it. So the gate's + manifest declares neither event in `consumes` nor either tool in `invokes`, and its code calls neither; the commit + that added those calls is undone. `view_reach` stays the status view's own read tool, answered from the catalog + half (§196, test 61). Why: §431's "by their events" named the readers that stay, and the gate is not one of them + (join of the gate). How it is checked: unit (gate's manifest), neither event nor tool named. + +## Readers of a module's manifest + +- §594 **The readers take a module's manifest from its catalog graph entry.** (§196, §421, §443, §445; ADR 0656 §6, + ADR 0615 §1) The holders of `mesh-config`, `mesh-provisioner` and `mesh-self-check`, and the claude-code module, + read a module's manifest from the catalog graph entry that carries it whole (§443), taken through + `meshcatalogclient`'s view of the catalog half, which follows each watched branch's newest `catalog-revision` and + asks `revision` again on a gap (§196). None reads a manifest by digest from the indexer, its state `manifests` or + its tools: `manifests` is kept only for node-engines from before G (§445). Why: test 61's "no call of the indexer + by name" holds for every reader of which modules exist, and the entry carries the manifest (join of these readers, + RDR1 to RDR4). How it is checked: test 61, a row for each of the four readers; the code review finds no read of + `manifests` in them. diff --git a/03-DESIGN/01-to-be/47-milestones/G-3-delivery-record-and-graphs.md b/03-DESIGN/01-to-be/47-milestones/G-3-delivery-record-and-graphs.md index 4ce2f5e9..5b7718ea 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-3-delivery-record-and-graphs.md +++ b/03-DESIGN/01-to-be/47-milestones/G-3-delivery-record-and-graphs.md @@ -194,12 +194,12 @@ checker's `mesh/check` from a watch of the checker's state `owed`: reads of anot consumer's backlog: the last event applied, the events waiting, the age of the oldest), `bridge_owed_again` (perform one id again now) and `bridge_owed_drop` (drop one id with its reason, written in the hand-act log of the seat `mesh-hand-acts`, and said as `owed.ended` with the outcome `dropped`). -- §169 **The switch carries what is owed.** (§510) At the new gate's start (*The switch carries today's state in, once*) every key - of `owed` and `merges` the old bridge has not performed becomes an act of its record, with an id made of the key and +- §169 **The switch carries what is owed.** (§542, §592) At the new gate's start (*The switch carries today's state in, once*) every key + of `owed` the old bridge has not performed becomes an act of its record, with an id made of the key and its revision; the new bridge counts as performed every id whose key and revision the old bridge's own bookkeeping - names, so nothing is done twice and nothing dropped. A merge handed to the forge during the switch is such an act: - its merged message finds the record holding it, so it opens no `forge-made` record. -- §170 **A merge made at the forge has a record too.** A merge the forge reports for which no record holds a `merge-pull` + names, so nothing is done twice and nothing dropped. A key of `merges` becomes no act: §542 says it as + `approval-carried`, and §592 has the whole merge path from G's delivery. +- §170 **A merge made at the forge has a record too, until G's delivery** (from it, §151 and §592). A merge the forge reports for which no record holds a `merge-pull` of that pull request at that head (a person merged it in the forge's own page, as on 2026-11-07 and 11-09) is taken in like any other merge (*Taken in by the indexer it names*), and the gate opens a delivery record for it, marked `forge-made`, with no Approve, so its trace and its outcomes on the nodes are kept like every delivery's and no @@ -211,11 +211,8 @@ checker's `mesh/check` from a watch of the checker's state `owed`: reads of anot restart and the forge holds it once (the comment and the note by their id); an act said twice is performed once; an undecodable act is said `undecodable`; `bridge_owed`, `bridge_owed_again` and `bridge_owed_drop` answer, the drop writing the hand-act log; its account cannot read the gate's or the checker's state. In the gate's: an act left - unanswered is said again at the gate's start under its id and listed by `stalled` after 15 minutes; a group's second - `merge-pull` is said only after the first member's merged message; the switch with a merge handed and not yet - merged makes no `forge-made` record; a merged message with no record's merge opens a `forge-made` record, said as - `transition` with why `forge-made`, and a later merge in the same repository is taken in behind it. Acceptance - tests 53 and 51. + unanswered is said again at the gate's start under its id and listed by `stalled` after 15 minutes; the merge path + of G's gate is checked as §592 says. Acceptance tests 53 and 51. ## The state table, from milestone G's delivery @@ -271,8 +268,8 @@ Findings 11). How each is kept, read and retained is this design's choice under - §177 **A revision is made by a merge, and also with no merge.** The indexer makes a catalog graph revision when it takes a source revision in. The assigner makes an assignment graph revision on each new catalog graph revision, on the seat `mesh-module-assigner`'s event `assignments-changed` (ADR 0567 §5, ADR 0641), and on the node-engine seat's event - `capabilities-changed`, which a node-engine says when the capabilities it states in its node record change - (ADR 0614 §4), so the assigner follows an event and never reads a node record across the seam (ADR 0596). A + `manifest-reads-changed`, which a node-engine says when the capabilities it states change and when its node returns + (ADR 0614 §4, ADR 0618 §3, §4; §590), so the assigner follows an event and never reads a node record across the seam (ADR 0596). A placement change is traced like a merge. At its first start with no revision kept, the indexer takes in the head the gate's source names for every repository by its catch-up path and keeps that as revision 1, and its verb `revision` answers that it waits until then (lead-47's ruling in G's prepare: a first start has no merge to make a revision). diff --git a/03-DESIGN/01-to-be/47-milestones/G-4-revision-view-and-steps.md b/03-DESIGN/01-to-be/47-milestones/G-4-revision-view-and-steps.md index f69a6cd9..d76a980a 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-4-revision-view-and-steps.md +++ b/03-DESIGN/01-to-be/47-milestones/G-4-revision-view-and-steps.md @@ -223,7 +223,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli | §223 The verbs `revision`, `entry` and `difference` on the two seats | each half of the view, and the difference, is served by its one owner through its seat, never read from its state | | §224 The node-engine reads its want and the catalog half, never the assignment half | the want is the one record a node reads; the assignment half would have each node read every node's placements | | §225 Composing waits per node, held by the assigner, with no new field in the want: a node's node-engine want first, its other wants once its new node-engine runs | a node away holds only itself (ADR 0603 §7); an old node-engine reads its want as it is, so it is reached with no form it cannot read | -| §226 Capability changes said as the node-engine seat's event `capabilities-changed` | the assigner follows an event instead of reading node records across the seam (ADR 0596) | +| §226 Capability changes said as the node-engine seat's event `manifest-reads-changed` (ADR 0618 §4; §590) | the assigner follows an event instead of reading node records across the seam (ADR 0596) | | §227 The step events, their fields and their subjects, with the node in the subject of every event a node publishes | every outcome reaches the delivery record as the event of the part that did it (research 085, Findings 7), and a node's account can be granted only its own node's subjects (ADR 0363 §2) | | §228 A first tier of only the changed acting parts, bounded at 20 minutes, its verdict telling `waiting for a build node` from `did not build` | an ordinary change pays nothing more; a bound turns a build that never ends into a named failure, and the two words tell the operator which act frees it | | §229 The build seat's ask `run`, published only by the checker's account, its step keys starting with the asker's name | the program is a long job pulled where capacity is, run in the sandbox every check already uses (ADR 0448 §2), and no other part can have a program run or read its verdict | @@ -284,7 +284,7 @@ say another runs a build (ADR 0363 §2); the gate's events are granted to the ga | an entry checked | `checked` | `mesh-delivery-checker`, the checker | `mesh.seat.mesh-delivery-checker.event.checked` | the seat's definition in `mesh-delivery-contracts` | | an entry wanted | `wanted` | `mesh-wants`, the assigner | `mesh.seat.mesh-wants.event.wanted` | the seat's definition in `mesh-delivery-contracts` (ADR 0641 §2) | | an entry composed, and running healthy | `composed`, `running` | `node-engine`, the node-engine on each node | `mesh.seat.node-engine.event.composed.`, `.running..`, the latter on a stream kept last per subject with no age limit | the seat's definition in `mesh-contracts` | -| a node's capabilities changed | `capabilities-changed` | `node-engine`, the node-engine on that node | `mesh.seat.node-engine.event.capabilities-changed.` | the same | +| a node's capabilities changed, or its node returned | `manifest-reads-changed` (ADR 0618 §4; §590) | `node-engine`, the node-engine on that node | `mesh.seat.node-engine.event.manifest-reads-changed.` | the same | | a wait held, and ended | `wait-held` (step, acting part, its version, the entry, since when, its bound), `wait-ended` (the same, and how: ran, released) | each holder: `mesh-wants` for the assigner (placing, wanting and composing), `mesh-grants` for the grants part, the builder's own stream | `mesh.seat..event.wait-held`, `.wait-ended`; `mesh.stream.mesh-delivery-builder.event.wait-held`, `.wait-ended` | each seat's definition; the builder's manifest | | a store filling, full, and back below its cap | `filling`, `full`, `room` | `mesh-catalog`, `mesh-wants`, `mesh-delivery` | `mesh.seat..event.filling`, `.full`, `.room` | each seat's definition | | a record pins or frees a revision; a candidate's heads replaced; a record ended | `pinned`, `freed`, `heads-replaced`, `record-ended` | `mesh-delivery`, the gate | `mesh.seat.mesh-delivery.event.` | the seat's definition in `mesh-delivery-contracts` | @@ -336,7 +336,7 @@ two records pin stays until both free it; one neither pinned nor current is remo was stopped is applied after its restart; a candidate's graphs are dropped on `heads-replaced`; a store past 80 % says `filling` and raises `store-filling`, and a full one says `full` and refuses its next revision naming itself; for a candidate's heads both `revision` verbs answer, the assigner's half named by its own revision and naming its inputs; a -placement change with no merge, and a `capabilities-changed`, each give a new assignment half on the same catalog half, +placement change with no merge, and a `manifest-reads-changed` that changes what a node states (§590), each give a new assignment half on the same catalog half, whose difference moves only the module concerned, and a part takes that pair as its view; after its first view a part acts on a seat event without asking a verb again; a running part does not act on a candidate's view; a pull request that adds a seat and a module using it is validated by the indexer's candidate pass and checked by the checker with diff --git a/03-DESIGN/01-to-be/47-milestones/G-9-prepare-answers.md b/03-DESIGN/01-to-be/47-milestones/G-9-prepare-answers.md index 8f006242..e9c83a4c 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-9-prepare-answers.md +++ b/03-DESIGN/01-to-be/47-milestones/G-9-prepare-answers.md @@ -108,8 +108,7 @@ line says so.* (Q13). How it is checked: whole (indexer), `unwatch` of a placed branch refused. - §403 **A held-back ask.** A held-back ask (§83, design 46 §6) is answered in `asks` with the state `held-back` and the field `held-since`, and no field `behind`. Why: the design's choice (Q14). How it is checked: the seat's fixtures. -- §404 **The node-engine's events' bodies.** (§520) `capabilities-changed` carries the node record's stated capabilities whole - and `at`; `composed` the module, the fingerprint and the composition's digest; `running` with `stopped` carries +- §404 **The node-engine's events' bodies.** (§520) `manifest-reads-changed` carries what §590 says; `composed` the module, the fingerprint and the composition's digest; `running` with `stopped` carries `stopped: true` and no fingerprint (§365), and mesh-sdk's `SeatsToPassOn` counts such a module as not running on that node, its input being §459's. Why: the design's choice (Q17). How it is checked: the seat's fixtures; unit (`SeatsToPassOn`), a row where a `stopped` holder passes no seat. diff --git a/03-DESIGN/01-to-be/47-milestones/G.md b/03-DESIGN/01-to-be/47-milestones/G.md index 852bc05b..fe094033 100644 --- a/03-DESIGN/01-to-be/47-milestones/G.md +++ b/03-DESIGN/01-to-be/47-milestones/G.md @@ -6,6 +6,7 @@ milestone: G updated: 2026-11-11 decisions: - "ADR 0500" + - "ADR 0673" - "ADR 0672" - "ADR 0436" - "ADR 0670" @@ -81,7 +82,7 @@ file on 2026-11-10, and is cited as "design 47 G §n". A sentence that holds a d stayed in the main file, and G builds what it says from G's delivery. A section named in italics is in this part, or, when it is not here, in the main file. -The part is fifteen files, each read whole, its design lines numbered across them: +The part is sixteen files, each read whole, its design lines numbered across them: - [G-1-pipelines-registration-and-steps](G-1-pipelines-registration-and-steps.md): pipelines per module: registration, watched branches, steps and policy, what holds a delivery, approval, groups, dependencies, a publish. - [G-2-pipelines-sizes-checks-and-tools](G-2-pipelines-sizes-checks-and-tools.md): pipelines per module: any size, the pipeline makes the check, who may say what, health, recovery, tools, kept data, how G itself is delivered, the choices under ADR 0666 and ADR 0667. @@ -98,3 +99,4 @@ The part is fifteen files, each read whole, its design lines numbered across the - [G-13-review-round-3](G-13-review-round-3.md): the review of §480 to §515, rounds 2 and 3 (§600 on). - [G-14-recovery-module-and-review](G-14-recovery-module-and-review.md): the recovery module, the operator's answer of 2026-11-11 12:55 CET, and the review of §516 to §553 (§554 to §559). - [G-15-develop-answers-fifth](G-15-develop-answers-fifth.md): develop's fifth batch, round 3's notes on §516 to §559, the knowledge base's review of the recovery module's record, and the operator's answers of 2026-11-11 about 14:05, 14:15 and 14:30 CET (§560 to §586). +- [G-16-develop-answers-sixth](G-16-develop-answers-sixth.md): develop's sixth batch: the ledger's upkeep calls, the builder's publishes again and its read of a module's builds, one event of a node's capabilities, the object stores' caps, the gate's merge path from G's delivery, and the readers of a module's manifest (§587 to §594).