From 298e68c71fd2f2139ba5f2202dde7503d59cc801 Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 11 Nov 2026 12:08:39 +0100 Subject: [PATCH] =?UTF-8?q?Write=20the=20operator's=20noon=20answers,=20th?= =?UTF-8?q?e=20review=20of=20=C2=A7456=20to=20=C2=A7479,=20and=20develop's?= =?UTF-8?q?=20next=20answers=20into=20milestone=20G?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The operator answered who may drop a build seat's steps, whose name a step key carries, and that a review in G refuses no one for authorship. The four reviewers' musts on G-10 are answered as design lines, and develop's next questions of internal form (the watchman's, builder's, indexer's, forge bridge's, assigner's, view's, bus module's, keeper's and node-engine's) in the new part file G-11 (§480 to §515); the teller's words wait for the operator. Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ --- .../47-delivery-from-commit-to-delivered.md | 5 +- .../G-1-pipelines-registration-and-steps.md | 10 +- .../47-milestones/G-10-develop-answers.md | 46 ++- .../G-11-develop-answers-review.md | 321 ++++++++++++++++++ .../G-2-pipelines-sizes-checks-and-tools.md | 14 +- .../G-3-delivery-record-and-graphs.md | 8 +- .../G-4-revision-view-and-steps.md | 4 +- .../G-5-acting-parts-check-and-kept-data.md | 6 +- .../47-milestones/G-6-verbs-and-retires.md | 2 +- .../01-to-be/47-milestones/G-7-answers.md | 14 +- .../G-8-findings-heard-as-events.md | 2 +- .../47-milestones/G-9-prepare-answers.md | 14 +- 03-DESIGN/01-to-be/47-milestones/G.md | 3 +- 13 files changed, 382 insertions(+), 67 deletions(-) create mode 100644 03-DESIGN/01-to-be/47-milestones/G-11-develop-answers-review.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 3fac9931..784118cc 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 @@ -1875,7 +1875,7 @@ The failure paths: definition names no `callers` admits only the holder roles and the operator; a change adding a new `invokes` of `node-packet-filter.remove`, a verb whose callers are `invokers`, names that grant in its `pipeline-ended`'s `widens` (whole, runner and grants part). -86. **An author's own review** is refused; a reviewer's passes the step (whole, runner). +86. **A review records its caller**: in G a review refuses no one for authorship and its result names the caller the bus proved (design 47 G §482; whole, runner). 87. **A step seat with no holder** ends its pipeline failed, naming the seat, within five minutes (whole, runner). 88. **A runner stopped mid-step** takes its pipelines up again from its kept state when it starts, a replaced holder and its successor never both write one pipeline key (compare-and-set), and a new runner's failing build leaves the @@ -2210,8 +2210,7 @@ B0's own choices, each checked by the rows of *How it is checked* below: meanwhile, and the verb, if built, gates nothing (ADR 0659 §2, §3). - **A session's merge of a recovery fix** is decided: an ordinary merge through its pipeline, named a recovery by its author (ADR 0666 §26; *A recovery fix is an ordinary merge*). The verb this design sketched for it is not built. -- **How the runner knows a review's caller is the commit's author.** ADR 0666 §22 refuses a review from the commit's - author; the forge names the author by its forge account and the runtime proves the caller's bus account, and no +- **How the runner knows a review's caller is the commit's author.** In G a review refuses no one for authorship and records the caller the bus proved (design 47 G §482, the operator, 2026-11-11). ADR 0666 §22 refuses a review from the commit's author; the forge names the author by its forge account and the runtime proves the caller's bus account, and no record binds the two. Until one does, code review is never a `required` step: `register` and `policy` refuse it (*A module's registration*); issue 1966 tracks it (note 157). - What a process started by a node-engine that hands no fingerprint does beyond saying `own build unknown`, for a part diff --git a/03-DESIGN/01-to-be/47-milestones/G-1-pipelines-registration-and-steps.md b/03-DESIGN/01-to-be/47-milestones/G-1-pipelines-registration-and-steps.md index 9fed6f7e..89341c2d 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-1-pipelines-registration-and-steps.md +++ b/03-DESIGN/01-to-be/47-milestones/G-1-pipelines-registration-and-steps.md @@ -92,7 +92,7 @@ check and deliver milestone G itself (ADR 0667 §2); each of them says so in a l list when it is removed (*How milestone G itself is checked and delivered*). A registration holds no foundation value. How it is checked: a unit test of the manifest validator refuses a template in the manifest of every part on its list, the runner's included, and judges every other part's manifest as any part's. -- §7 **No part fixes a name: a guideline the code review reads.** Every branch, repository and module name a part +- §7 **No part fixes a name: a guideline the code review reads.** (§507) Every branch, repository and module name a part needs is read from the registrations and the catalog graph, never fixed in its code. This is a guideline, not a step: the code review reads it, and no lint step scans for names (the operator, 2026-11-11 about 00:05 CET: the scan was a flaky check; where guidelines live is research 087's). It departs from ADR 0666 §5's refusal by the lint step, by the operator's choice, @@ -129,14 +129,14 @@ check and deliver milestone G itself (ADR 0667 §2); each of them says so in a l ### Watched branches and the catalog graph per branch -- §11 **Only a watched branch starts a pipeline.** The forge bridge hears every commit of every watched branch the +- §11 **Only a watched branch starts a pipeline.** (§509) The forge bridge hears every commit of every watched branch the registrations name, through the seat `git`'s event `branch-moved` (a branch's new head, from the forge's push webhook, which a merge and an admitted push alike say), and takes the commit from the forge's own record by the seat's verb `branch`, never from the event's body (ADR 0666 §6). One event for every way a branch moves, because a merge is not the only one. `branch-moved` is kept on the seat's stream `SEAT_git_branch-moved`, which the bridge hears through a durable consumer, so a move said while the bridge is down is heard when it starts; at its start it also reads each watched branch's head the same way. -- §12 **A head with no pipeline is a finding.** A watched branch's head that starts no pipeline within five minutes is the +- §12 **A head with no pipeline is a finding.** (§497) A watched branch's head that starts no pipeline within five minutes is the watchman's finding `pipeline-stands`, naming the branch and its head, raised by the condition keeper (ADR 0564 §2), unless it waits as progress not owed: a member of a gathered group is governed by ADR 0633 §5's 30-minute bound, and a merge behind a pending revision of the same branch by its 60-minute bound (ADR 0666 §24). The finding clears on the @@ -163,7 +163,7 @@ check and deliver milestone G itself (ADR 0667 §2); each of them says so in a l (ADR 0666 §6, §26). A revision on the branch the indexer's own placement chose is taken in only by the indexer it names (ADR 0633 §1). This validation is no pipeline step and waits on no pipeline, so every delivering pipeline runs on a revision already taken in. -- §17 **A branch whose protection was removed starts nothing.** On every `branch-moved` the forge bridge reads the +- §17 **A branch whose protection was removed starts nothing.** (§497, §509) On every `branch-moved` the forge bridge reads the branch's protection again; a move of a watched branch whose protection was removed starts no delivering pipeline, and the forge bridge writes the finding `branch-unprotected`, naming the branch, which the condition keeper raises and clears once the protection is back (ADR 0666 §6). @@ -302,7 +302,7 @@ check and deliver milestone G itself (ADR 0667 §2); each of them says so in a l policies: it refuses a head when any run at its build-input fingerprint failed a step a policy marks `required`, and merges a head whose `required` steps passed or that has no run yet, a failed `optional` or a `bypass` step refusing nothing; it never waits for a run and never asks an Approve (ADR 0666 §11). The forge keeps only its branch protection. -- §39 **Judged from its own state, never by a call.** The holder of the seat `git` consumes the runner's `step-ended` +- §39 **Judged from its own state, never by a call.** (§487) The holder of the seat `git` consumes the runner's `step-ended` through a durable consumer of its own and keeps, in its own state `failed-steps`, each failed `required` step by module and build-input fingerprint, with the commits it was seen at and the run that failed it, until none of those commits is a watched branch's head or the head an open pull request names (*The runner's kept data*); so a head 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 fb2785e2..95c73828 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 @@ -32,8 +32,7 @@ function's input, a helper's API, a contract field's name or shape, a package's the design writer, from the design and its records, read by the four reviewers by architectural domain in one round, and told to the operator in one line each; every other question goes to the operator (playbook 07, step 0b). §456 to §458 are the operator's answers of 2026-11-11 at the terminal; §459 to §467 answer questions of that internal form, -each the design's choice with its reason, §468 to §479 those of the runner's, the build's, the indexer's, the contracts' and the forge's developers the same way. What §463 and -§467 leave about callers waits for the operator and is said there.* +each the design's choice with its reason, §468 to §479 those of the runner's, the build's, the indexer's, the contracts' and the forge's developers the same way. §480 and §481 answer what §463 and §467 left to the operator, and [G-11](G-11-develop-answers-review.md) the review of these lines.* - §456 **A verb that names no `class` is a `read`, and nothing refuses one.** A verb whose definition names no `class` takes the default of `read` (§391), whether it is on main or G adds it: the seat-definition reader, the seat @@ -43,7 +42,7 @@ each the design's choice with its reason, §468 to §479 those of the runner's, operator, 2026-11-11 at the terminal (develop question D-12): a refusal would be "hard-coded logic for no good reason". How it is checked: unit (definition reader), a row where a verb G adds with no `class` takes `read`'s callers; unit (seat generator), a definition with a verb naming no `class` is generated. -- §457 **The put session's wire form.** §345's put session runs on the subject `.put.`. +- §457 **The put session's wire form.** (§489, §490) §345's put session runs on the subject `.put.`. Each chunk is one message whose body is the value's raw bytes, at most half the bus's maximum payload as the connection reads it from the server, with the header `Mesh-Put-Seq` (a decimal from 1, one more each chunk) and, on the last chunk alone, `Mesh-Put-Last: true`. The tool runner answers each chunk with `{seq}`, the sequence it took, @@ -86,7 +85,7 @@ each the design's choice with its reason, §468 to §479 those of the runner's, silent. This amends §425: the replacing event is optional, `open` always given. Why: an ask with no replacing event must still stop when its asker closed it (§351; develop question D-15). How it is checked: unit (kept-call form), a key `open` answers closed is not asked again, a replaced one is not, and an `open` error is logged and asked again. -- §461 **mesh-sdk's finding writer.** The writer is mesh-sdk's `go/views` writer and its TypeScript twin, mesh-sdk's +- §461 **mesh-sdk's finding writer.** (§485, §503) The writer is mesh-sdk's `go/views` writer and its TypeScript twin, mesh-sdk's `src/views`, exported from its index as `views`, the same functions in both (§452). An observer makes it with: the binding of its own state `findings`, its bus connection, and the subjects of `finding-written`, `finding-cleared`, `findings-stated` and `findings-asked`, which the generated `mesh-conditions` contract's subject functions make from @@ -116,7 +115,7 @@ each the design's choice with its reason, §468 to §479 those of the runner's, questions D-16 and C15), every observer stating through one writer. How it is checked: unit (writer, both languages), the acts above each say their event with §439's fields, an ask naming another module is not answered, an error of `observe` says no set; §383's and §384's checks. -- §462 **Where the bus state calls and their capabilities land.** The calls' names and shapes are in mesh-sdk's +- §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 @@ -126,7 +125,7 @@ each the design's choice with its reason, §468 to §479 those of the runner's, answers (ADR 0595 §9) and the shapes alone are shared, so a module importing the calls rebuilds nothing of the tool runner's (develop question D-17). How it is checked: unit (tool runner), its table of families names each new call under its capability; unit (`buscalls`), each request and answer read. -- §463 **The input of the build seats' `steps`.** `steps` takes `artifact`, the key of `detected-steps` (§414), and +- §463 **The input of the build seats' `steps`.** (§480) `steps` takes `artifact`, the key of `detected-steps` (§414), and `fetch` to detect the artifact's steps, `again` (yes or no) to detect again, or `drop` (yes) with `why` (a non-empty text) to delete the key; `fetch` is required unless `drop` is given, and `why` with `drop`. A drop answers `dropped`, the artifact, or `error`, and is written in the hand-act log of the seat `mesh-hand-acts` with the caller the bus @@ -134,9 +133,7 @@ each the design's choice with its reason, §468 to §479 those of the runner's, `mesh-delivery-contracts`' part `build-step`, for the three build seats. It is not the verb `drop` of §338, which drops asks. This completes §326. Why: the design's choice (develop question D-18). How it is checked: unit (`build-step` contract), a `drop` without `why` and an ask without `fetch` or `drop` refused; whole (Go build - module), a drop deletes the key and is in the hand-act log with its caller. Who may call `steps` with `drop` waits - for the operator: §326 has a drop on a person's word while §338 names the runner and the indexer as `steps`' - callers; the contract and the build modules are built to this line meanwhile. + module), a drop deletes the key and is in the hand-act log with its caller. Its callers are §480's. - §464 **The delivery SDK's two step packages, and where the build modules' shared code goes.** In `modules/mesh-delivery-sdk` (after §427's move), `buildstep` holds what every delivery part reads of a step: the step ask of a pipeline and its end, `step-ended` (§24), and the kept-artifact judgement of §271, as develop built them; @@ -172,16 +169,13 @@ each the design's choice with its reason, §468 to §479 those of the runner's, key, and the indexer read no other part's state (ADR 0596 §2; develop question BLD13). How it is checked: unit (`build-step` contract), both fields read; whole (Go build module, builder, indexer), a released version's kind-1 and kind-3 entries carry the digests the build named. -- §467 **A step key starts with its asker.** The build seats' state `steps` (in `node-build-go`, `node-build-node` - and `node-build-image`) keys a step `..`: `` the ask's `asker` (`checker`, `runner`, - `indexer`, `assigner`, `builder`), `` the node that runs it, `` the ask's id, so §206's read grant of each - asker is its own prefix and each holder writes only its node's keys. Keys of the old form `.`, written before G, are read by no - tool of G's and go by the state's own two-day age, as on main; nothing is removed by hand. This amends the three +- §467 **A step key starts with its asker.** (§481, §483, §484) The build seats' state `steps` (in `node-build-go`, `node-build-node` + and `node-build-image`) keys a step `..`: `` the asker the bus proves (§481: `runner`, `indexer`, `assigner`, `builder`), `` the node that runs it, `` the ask's id, so §206's read grant of each + asker is its own prefix and each holder writes only its node's keys. Keys of main's form `.` are §483's and §484's. This amends the three seats' `steps` key form on main. Why: §206 and §125 decide that each asker reads only its own step keys (ADR 0363 §2); the key's form is what makes that grant a fixed prefix (develop question BLD14). How it is checked: the seats' - fixtures; whole (Go build module), a step of each asker keyed under its name. Whether the `` must be the account the bus proves published the ask, rather than the ask's - field, waits for the operator, since it decides who can have a step key written under another asker's name. -- §468 **The runner's health check is its tool `runner_health`.** §76's check, run outside the process, is of kind + fixtures; whole (Go build module), a step of each asker keyed under its name. +- §468 **The runner's health check is its tool `runner_health`.** (§495) §76's check, run outside the process, is of kind `tool` (ADR 0240) and names the runner's own tool `runner_health`, named as the runner's other tools are (`runner_release`, `runner_catch_up`); it answers as every `tool` health check answers, healthy when the runner answers `show` and each durable consumer §76 names is less than five minutes behind, and otherwise naming each one @@ -195,7 +189,7 @@ each the design's choice with its reason, §468 to §479 those of the runner's, trusting the owner's own count; the field is the one the `objects` section has (develop question Q-RN2). How it is checked: unit (manifest reader), `max-mib` on a state read and a value out of the objects section's bounds refused; whole (runner), a write past a fixture's small cap says `full`. -- §470 **The step log is an old `logs` section, kept 100 days.** The runner's `step-log` is declared in its manifest +- §470 **The step log is an old `logs` section, kept 100 days.** (§486) The runner's `step-log` is declared in its manifest as an old `logs` section, with `max-age-days` 100 and `max-mib` 128, and is written and read onward by sequence through mesh-sdk's kept log (its `Read` from a sequence), as §330 reads it; the seat `mesh-pipeline-runner`'s definition keeps listing it, keyed by ``. A log already takes an age up to 3650 days and refuses no @@ -204,17 +198,17 @@ each the design's choice with its reason, §468 to §479 those of the runner's, log onward by sequence, which is what a kept log is, and the log section declares the age and cap §85 names with no new word (develop questions Q-RN3 and Q-RN6). How it is checked: the catalog's validation at G's heads accepts the runner's manifest; whole (runner), as §330. -- §471 **A second reader release carries §469's word.** The reader release of §340 and §409 is merged; a second +- §471 **A second reader release carries §469's word.** (§494) The reader release of §340 and §409 is merged; a second release of mesh-sdk's manifest reader, reading `max-mib` on an old `state` section, is merged ahead of G's check in the same way, so the running checker's validator reads the runner's manifest (§340). Why: readers first (ADR 0667 §4); the running checker makes G's own check (ADR 0667 §2). How it is checked: unit rows in the release for the word; G's check reads the runner's manifest. -- §472 **The toolchain part's digest.** Each build module states, in its `toolchains` key of each language beside +- §472 **The toolchain part's digest.** (§492) Each build module states, in its `toolchains` key of each language beside the version and the recipe, `digest`: the `sha256:` digest of the language's toolchain program as it runs it, the program of the module that provides that language's toolchain (for Go, the module providing `go-toolchain`), never the build module's own program. A build's ToolchainUsed carries its node's (§466). The builder's `toolchain-agreed` carries `digests`, each digest the nodes reporting the agreed version report, with those nodes, in place of §376's - one digest; it is said only when the agreed version changes (ADR 0584 §1), and kind 3 is stale (§441) when the + one digest; it is said only when the agreed version changes (ADR 0584 §1), and kind 3 is stale (§375) when the agreed version differs from the one the release recorded, so a digest that differs between nodes of one version rebuilds nothing and is only recorded. This amends §376 and §441 for kind 3. Why: ADR 0584 agrees a version, not a digest, and a rebuild of every module of a language on a difference no record judges would spend the build @@ -237,7 +231,7 @@ each the design's choice with its reason, §468 to §479 those of the runner's, event". Why: ADR 0363 §5 stays in force for what §386 does not take over, and a refusal would end what a module hears with no answer of the operator's (develop question IX21). How it is checked: unit (manifest validator), `*.usage.*` accepted as the shared form; the grants part's table test makes no per-module consumer for it. -- §475 **The forge module learns a head's fingerprint from every `step-ended`.** The state `failed-steps` of §39 gains +- §475 **The forge module learns a head's fingerprint from every `step-ended`.** (§487) The state `failed-steps` of §39 gains a second key form, `seen..`, holding the build-input fingerprint the runs named for that commit and module, written from every `step-ended` of any outcome whose commit is then a watched branch's head or the head an open pull request names, and deleted by §135's rule; and each failure entry's commits take every commit a @@ -247,21 +241,21 @@ each the design's choice with its reason, §468 to §479 those of the runner's, `step-ended` names one commit and fingerprint at a time (develop questions GIT7 and GIT8). How it is checked: whole (forge module), a head that passed, then another commit at its fingerprint failed a `required` step, is refused; its `seen` key goes when the pull request closes. -- §476 **`take-in.taken`'s body and its type.** The indexer's own `take-in.taken` carries, beside what it carries on +- §476 **`take-in.taken`'s body and its type.** (§493) The indexer's own `take-in.taken` carries, beside what it carries on main, `branch` (the watched branch), `source` (the source revision taken in) and `entries`, one `{module, commit, fingerprint}` per module of that revision. Its body is defined in the seat `mesh-catalog`'s definition, in its section `bodies` (§439, §454), so the generated contract carries the type the indexer writes and the runner reads, and neither imports the other (§333). Why: a body said on a module's own stream and read by others is a `bodies` entry (§439), never a client's hand-written type (develop question Q-RN4). How it is checked: unit (seat generator), the type generated; whole (runner), a pipeline started from a fixture `take-in.taken`. -- §477 **A sent store's cap.** The bus module plans each `_sent-objects` with a cap of 256 MiB, and a +- §477 **A sent store's cap.** (§495) The bus module plans each `_sent-objects` with a cap of 256 MiB, and a foundation part's old `objects` section `sent-objects` names `max-mib` 256; a send refused at the cap fails its reply or event loudly, naming the store, as §181 has a full store refuse. This completes §59's "the objects template's", which has no default. Why: an object sent is transport kept 7 days (§59), most modules send none, and the largest value the design moves whole is §345's hundred times the message limit, which 256 MiB holds twice (develop question Q-RN5). How it is checked: unit (bus module's plan), every planned sent store has its cap; whole (mesh-sdk), a send past a fixture's cap fails naming the store. -- §478 **`reserved` takes a package's name.** The seat `mesh-builds`' verb `reserved` takes either `module` or `name` +- §478 **`reserved` takes a package's name.** (§491, §504) The seat `mesh-builds`' verb `reserved` takes either `module` or `name` (a package's or an image's name in its ecosystem: the Go module path, the npm name, the image name), with `version`; given `name`, the builder finds the module from the catalog half's entries, whose packages carry each name (§348, §412), and answers as for `module`, the artifacts with their digests. A registry holder asks it with the @@ -271,7 +265,7 @@ each the design's choice with its reason, §468 to §479 those of the runner's, its own fact (ADR 0596 §2) (develop questions GIT12 and REG1). How it is checked: unit (`mesh-builds` contract), `reserved` with `name` read; whole (builder, registry holder), a Go publish named by its module path is checked against the module's reservation, and an unknown name refused. -- §479 **A branch's catalog view is named with its branch.** In mesh-sdk's `go/views` reader and process reader, a +- §479 **A branch's catalog view is named with its branch.** (§495) In mesh-sdk's `go/views` reader and process reader, a first view of a per-branch state is named `..`, the branch escaped as a key's name is (§73), so `mesh-catalog.catalog-revisions.` names one view per watched branch, a part reads several in one reader, and `_first_views` lists one row per branch (§358, §365). A view of a state that is not per branch keeps 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 new file mode 100644 index 00000000..1bbb6dca --- /dev/null +++ b/03-DESIGN/01-to-be/47-milestones/G-11-develop-answers-review.md @@ -0,0 +1,321 @@ +--- +layer: to-be +status: in-progress +design: 47 +milestone: G +updated: 2026-11-11 +decisions: + - "ADR 0667" + - "ADR 0668" + - "ADR 0666" + - "ADR 0660" + - "ADR 0656" + - "ADR 0633" + - "ADR 0603" + - "ADR 0596" + - "ADR 0595" + - "ADR 0584" + - "ADR 0579" + - "ADR 0564" + - "ADR 0563" + - "ADR 0363" + - "ADR 0240" +--- + +# 47, milestone G: the operator's answers of 2026-11-11 noon, the review of §456 to §479, and develop's next questions + +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". + +*§480 to §482 are the operator's answers of 2026-11-11 about 11:50 CET at lead-47's terminal. §483 to §495 answer +what the four reviewers by architectural domain found in round 1 of [G-10](G-10-develop-answers.md) (§456 to §479). +§496 on answer develop's next questions of internal form (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.* + +## The operator's answers + +- §480 **Who may drop a build seat's detected steps.** The build seats' `steps` with `drop` (§463) is called by the + runner and the indexer, as §338 has `steps`, and by the operator and agent sessions; every drop is written in the + hand-act log of the seat `mesh-hand-acts` with the caller the bus proved. The log is written first: a drop whose + log write fails deletes nothing and answers `error`, naming the log. This amends §338 and completes §463. Why: the + operator, 2026-11-11 at the terminal: §326 has a drop happen on a person's word. How it is checked: whole (Go + build module), a drop by a session is in the hand-act log with its caller and deletes the key; a drop by any other + account is refused by the bus; with the hand-act log refusing, nothing is deleted. +- §481 **A step key's asker is the account the bus proves.** The `` of a step key `..` (§467) + is the account the bus proves sent the ask, never a field of the ask. An ask is published on + `mesh.seat..accept..`, the asker's name the last token, and the grants part grants each asker of + §338 publish on its own name alone, so the subject the holder took the ask from names the asker; an ask's own + `asker` field, where one is sent, is not read. Each build seat's holder on a node is granted writes only of that + node's keys, `..` (and main's `.`, §483). The seat's stream takes + `mesh.seat..accept.>`. This amends §467 and §206. Why: the operator, 2026-11-11 at the terminal; the name in + the subject is how the bus proves who published (ADR 0363 §2). How it is checked: whole (grants part, Go build + module), an ask published under another asker's name is refused by the bus; a step of each asker is keyed under + its name; a holder's write of another node's key is refused. +- §482 **In G a code review refuses nothing on authorship.** The runner's `review` takes a review's result from any + of its callers (§394), refuses none for being the commit's author, and records with the result the caller the bus + proved, in the step's result, `step-ended` and `show`. Code review is never a `required` step in G: `register` and + `policy` refuse it, as §2 says. This amends §70, §72, §394, test 86 ("an author's own review is refused") and the + verb table's `review` row, and answers the runner's question of who the author of a commit the runner makes is: no + line of G reads a commit's author. Why: the operator, 2026-11-11 at the terminal (develop question RN13); no record + binds a forge account to a bus identity (*What is not decided here*). How it is checked: whole (runner), a review + by a session passes an `optional` review step and its result names the proven caller; `policy` naming code review + `required` is refused, naming why. + +## The review of §456 to §479, round 1 + +- §483 **Main's step keys stay readable while main's askers run.** 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 + under its name, and the holders of the three build seats are delivered before it by a served-verb edge (kind 6) + the delivery plan derives from the asker's manifest naming the accepted kind (`step`, `run`) as it derives one from + `invokes`; an ask under a name that reaches a holder of before G waits on the work queue, whose consumer of before + G takes only main's subject, and is said by `build-capacity-waits` after 60 minutes. The checker asks on main's + subject until it goes (§97). main's subject and its key form are served until the first change after the checker + is removed and no builder of before G runs, as §372 has `builder_versions`. Why: a reader is delivered first (ADR + 0667 §4), and a step key is the answer its asker reads (review round 1, running and testing 2, security and upgrade + 1). How it is checked: whole (Go build module of G, builder of main), main's builder's build is answered under + `.`; whole (runner of G), its steps are keyed under `runner.`; the delivery plan of G names the edge from + each build seat's holders to the runner, the indexer and the assigner. +- §484 **Every reader of a step key moves to one parser.** The delivery SDK's `buildstep.ParseStepKey` reads both + forms, `..` and main's `.` (answering no asker), and its readers move to it in G's + change: the builder's `buildrun/steps.go` and `internal/build/stuck.go` (its own `builder.` keys and main's form), + the delivery SDK's `buildrun/stale.go`, the status view's `usage.go`, and each build module's read tools, which + list every key of the state, main's form included, until the state's two-day age takes them. The checker's + `bounded.go` stays as on main, since the checker asks on main's subject (§483). The watchman's `mirror.go`, which + read the build modules' `steps` (ADR 0596 §2 forbids it), goes: the watchman times a running ask from the build + seat's `step-progress` (§496). A key either form does not parse is written in the reader's journal naming it, + never passed over in silence. Why: one key form, read once (review round 1, health and events 1). How it is + checked: unit (`buildstep`), both forms parsed and a third refused; whole (runner, Go build module, watchman), a + step under `runner.` whose worker stops raises `pipeline-stands` within five minutes. +- §485 **mesh-sdk's finding writer runs one act at a time, and recovers.** The writer of §461 runs its acts, `write`, + `clear` and a statement, one at a time in the order they are asked (in Go behind one lock, in TypeScript on one + chain of promises), so a statement never deletes a key a `write` made meanwhile. It makes its consumer of + `findings-asked` before its start statement. When the bus connection is made again, it makes the consumer again, + from the newest ask, and states its findings again. When `observe` answers an error, the writer calls it again + once a minute until a set is said, each error in the journal. `clear` of a key that does not exist deletes nothing + and says `finding-cleared`, so a keeper holding the finding clears it. This completes §461. Why: §384 has the + keeper's view rebuilt from statements alone, so a statement that races a write, a consumer lost at a restart of + the bus or one error at start would leave a finding wrong until the next ask (review round 1, running and testing + 3 and 4, health and events 2). How it is checked: unit (writer, both languages), a `write` during a statement is + kept; after a reconnect an ask is answered and the findings are stated again; an `observe` failing at start then + answering says its set within a minute. +- §486 **A full step log is said and refuses no step's end.** The runner's `step-log` (§470) joins the stores of §366: + its fill in `show` and `kept`, `filling` past 80 %, `full` when the bus refuses an append (ADR 0595 §3), `room` + below 70 %. A step's end is written in `pipelines` and said as `step-ended` before its log entry is appended, so a + refused append ends no step: the runner keeps the entry in that pipeline's key as `unlogged`, starts no new pipeline + while the log is full (§366), and appends the kept entries in their order on `room`, from which §330's ageing reads + them. Why: a full store is said and refuses loudly (§181), and a step's result is the pipeline's, not the log's + (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 + 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 + 30 days after the last `step-ended` that wrote it. `merge-pull` judges a head that has a `seen` key by it; a head + with none was named by no run, and merges, its pipeline after the merge judging it (§29), so `merge-pull` refuses + nothing it did not refuse before. `git_failed_steps` answers the `seen` keys too, a commit's fingerprints with + `commit`, and `git_failed_steps_drop` drops a `seen` key, with why. The kept-data row of `failed-steps` counts them: + one key of about 0.2 KiB per commit and module a run named, an estimated 500 a day, under 3 MiB at 30 days. This + amends §475 and §135. Why: §39 judges a head by any run at its fingerprint (review round 1, running and testing 1, + seams and tools 3). How it is checked: whole (forge module), a run on request of a commit fails a `required` step, + a pull request opened at that commit is refused, naming the step; a head that no run named merges; a later commit + of the same content is refused too. +- §488 **A call family G adds has its own capability word.** The tool runner states, beside `ledger-calls` and + `bus-state-calls`, `ledger-upkeep-calls` (§462's `mesh/ledger.fill` and `mesh/ledger.remove`), `sent-objects-calls` + (`mesh/objects.sent-get`) and `put-sessions` (§457's put and get sessions), each only once it answers that family. + mesh-sdk's bundle reads the words its node's tool runner states when it connects, and a call of a family whose word + is not stated fails at once, naming the word and the node, never a timeout. A module whose G build makes such a + call names the tool runner's module in its `needs` (kind 4), so on each node it is delivered after G's tool runner. + This amends §408 ("no capability word is added") and §462. Why: an older tool runner states the old words and does + not answer the new calls (ADR 0595 §9; review round 1, security and upgrade 2). How it is checked: unit (tool + runner), each word stated with its family; whole (mesh-sdk), against a tool runner that does not state + `put-sessions` a large put fails naming it; the delivery plan of G orders the modules after the tool runner. +- §489 **Who publishes on a put or get session.** On `.put.` only the module's own + account publishes the chunks and only the tool runner of its node answers them; on `.get.` only the tool runner publishes the chunks and only the module's account answers. The grants part grants them + so, as it grants a module's call subject today (ADR 0363 §2). Why: §457's subjects lie under a subject the module + already owns, so the grant follows the record (review round 1, security and upgrade 3). How it is checked: whole + (grants part, tool runner), a chunk published by another module's account is refused by the bus. +- §490 **The get side of a session.** A get of a value over the limit (§457) runs so: the bundle subscribes to + `.get.` before it makes the call; the tool runner's answer to the call is + `{chunked: , size, digest}`, the value's `sha256:` digest; the tool runner then publishes each chunk as a + request on that subject, with `Mesh-Put-Seq` and, on the last, `Mesh-Put-Last: true`, and the bundle answers each + with `{seq}` or `{error}`, the next sent only after a `{seq}`; the bundle checks the whole against `digest`. A get + not completed within the call's bound fails, naming the object. This completes §457. Why: one form both ways + (review round 1, seams and tools 2). How it is checked: whole (mesh-sdk, tool runner), a value of a hundred times + the limit is got back whole and its digest checked; a chunk lost fails the get naming the object. +- §491 **A package's name belongs to one module.** The manifest validator refuses a revision in which two modules' + entries carry the same package name in one ecosystem, naming both. `reserved` by `name` (§478) answers `error` when + more than one entry carries the name, naming them. Why: a name read as a module must name one (review round 1, + security and upgrade 4). How it is checked: unit (manifest validator), two modules naming one Go module path + refused; unit (builder), a name two entries carry answered `error`. +- §492 **The builder hears the toolchains as an event.** Each build seat says `toolchain-reported` on + `mesh.seat..event.toolchain-reported.` (`node`, `language`, `version`, `recipe`, `digest`), declared + in the three build seats' definitions in `mesh-delivery-contracts`, at its start and each time its `toolchains` key + of a language changes; the builder agrees the version from these events through a durable consumer of its own, and + its manifest's `reads` of the build modules' `toolchains` go. `digest` is the digest of the program of the + provision the build module requires for that language's toolchain, never the build module's own. This amends §472. + Why: ADR 0596 §2 (review round 1, seams and tools 1). How it is checked: whole (builder, Go build module), a changed + toolchain is agreed from the event; the builder's account holds no read of a build module's state. +- §493 **What `take-in.taken` and `take-in.pending` carry, from every source.** A take-in by hand + (`indexer_take_in_pending`) and a revert, which is an ordinary merge, say `take-in.taken` with `entries` as any + take-in does, and start pipelines; a hand drop (`indexer_drop_pending`) says it with `dropped` and no `entries`, + and starts nothing. A `take-in.taken` with no `entries`, such as one said before G and read again, starts nothing + and is written in the runner's journal. `take-in.pending` carries `branch` beside its fields on main, and both + bodies are in the seat `mesh-catalog`'s `bodies`; the watchman and the runner read the generated types. This + completes §476. Why: §476 named one source (review round 1, health and events 4; security and upgrade's note). + How it is checked: unit (runner), a `take-in.taken` with `dropped`, and one with no `entries`, start nothing; whole + (indexer), a hand take-in's event carries the entries. +- §494 **The second reader release carries the node-engine's claim and reaches the grants part.** §471's release, + merged and delivered before G's merge, carries `max-mib` on an old `state` section (§469) and the validator's rule + of §508; the grants part, which reads manifests through that reader to make the buckets, is rebuilt with it by the + release's publish (kind 1), so the runner's manifest is read by every part that takes it in. Why: readers first + (ADR 0667 §4; review round 1, security and upgrade's note). How it is checked: G's check reads the runner's and the + node-engine's manifests; whole (grants part), the runner's `pipelines` bucket has its cap. +- §495 **Small corrections from the review.** §472's "kind 3 is stale (§441)" reads §375. §472's `toolchain-agreed` carries its digests as they stood when the version was agreed; a digest that changes later at that version is read from `toolchain-reported` (§492) and starts nothing. A sent store already over its cap when §477's + cap is planned keeps no cap until its seven-day age brings it under, the bus module's plan naming it with its fill + meanwhile; a sent store is planned only for a module §344 names, and the plan refuses caps whose sum passes the + bus's storage limit, naming the sum. §468's "behind" is the age of the oldest message the consumer has not + acknowledged. §479's view of a branch with no revision yet is ready and empty, as `revision` answers `none yet`, and + raises no `view-waits`; its `view-waits` names the view `..`. A build seat's read tool lists + the keys of both forms (§484). The seat generator sits in the delivery SDK as a tool run at build time by the + contracts modules, imported by no running module, so no running part depends on the delivery SDK through it + (§464). How it is checked: §475's test takes a commit named by a later run's step; §465's case of the artifact + store not answering fails the step naming the member; the rest as each line it corrects. + +## Develop's next questions + +- §496 **A running step says its progress.** The holder of a build seat says `step-progress` on + `mesh.seat..event.step-progress.` (`asker`, `ask`, `phase`: `fetch`, `build`, `run` or `report`, and + `at`) once a minute while it runs an ask, declared in the three build seats' definitions and kept on the seat's + stream for a day; the assigner says the same on `mesh-wants` for a composition step. `step-started` gains `ask`. + The watchman's five minutes (§75) run from a step's `step-started` or its latest `step-progress`, so a step that + runs longer but says its progress raises nothing; it times every ask of a build seat so, a builder's included, and + raises for it what its mirror raised on main. Why: §75 times owed progress, never run length, and names no event + for it (develop question WM1). How it is checked: whole (watchman, Go build module), a 20-minute step saying its + progress raises nothing, and one whose holder stops raises `pipeline-stands` within five minutes. +- §497 **The watchman knows a pending revision from `take-in.pending`.** A watched branch's head is behind a pending + revision (§12) while the watchman holds an open take-in wait whose `take-in.pending` names that branch (§493); its + head is then governed by `take-in-waits`' 60-minute bound and raises no `pipeline-stands`. A head on a branch whose + `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.** `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` + with `part` the dependency, its version and `machines`. `assigner_puts` answers each put with its node, module, + fingerprint, `held`, since and bound, from which the watchman seeds. Why: one wait form, told apart by `step` + (develop questions WM6 and WM10). How it is checked: unit (contracts), each field read; whole (watchman), a put's + wait raises `put-stands` and a pipeline's wait raises nothing for it. +- §499 **The node-engine says a kept build's wait, and its version is read from the catalog.** A node-engine of G + waiting for a kept build says `wait-held` on its seat with `step: kept-build`, `node` the build node, and why + (`node away` or `build no longer kept`), and `wait-ended` when it applies; its have's value carries the same as + `waits`. The watchman takes the keeping node from the builder's `build.ended` (§379), never its done key. Each + machine's node-engine version, named by `delivery-waits` and `kept-build-waits`, is the version of the catalog + entry (`entry`, §443) whose fingerprint `running..` names, or that fingerprint when no + entry answers. Why: ADR 0596 §2 (develop questions WM4 and WM5). How it is checked: whole (watchman, node-engine), + a kept build's node away raises `kept-build-waits` after 60 minutes naming the node-engine's version. +- §500 **The manifest findings from the indexer's events.** From G the watchman raises `manifest-refused` from the + indexer's `manifest-refused`, and `manifest-outgrown` from its `manifest-accepted`, which gains `problems`, what a + stricter validator finds in a manifest it still accepts (ADR 0579 §1), cleared by a `manifest-accepted` with none; it + seeds both from the indexer's `verdicts`. `manifest-waits` is no longer written: every revision is judged by the + validator built from its own heads (§16), so its validator knows every field, and a reader that does not is a + reader edge said by its own wait (§94). Why: the indexer's `modules` goes (§196; develop question WM9). How it is + checked: whole (watchman, indexer), an outgrown manifest raises `manifest-outgrown` and its mending clears it. +- §501 **`watchman_views` answers per part and view.** It answers, per module and node, each first view the part + names: the view (`.`, or with its branch, §479), `ready` or `waiting` with since when, and how far + behind (revisions not applied, and the age of the newest applied), read from each part's `_first_views` + tool through the tool runner and from the `view-waits` findings the keeper holds. Why: §83's row names the sources, + not the form (develop question WM8). How it is checked: whole (watchman), a part waiting for its view is answered + `waiting` with its since. +- §502 **A record is tied to its source revision's entries.** The watchman ties a delivery record to the entries of + its source revision's `take-in.taken` (§493), and leaves `record-open` unwritten for a record only while one of + those entries is held by a wait that raised `acting-part-late`, or a store that holds it says `full`; a record whose + revision is not taken in is covered by `take-in-waits`. `record-opened` gains nothing. Why: §148 judges a record by + its own entries, never every record at once (develop question WM7). How it is checked: whole (watchman), a record + of two entries, one held by `acting-part-late` and one not, raises `record-open` at 24 hours. +- §503 **The finding writer is mesh-sdk's, in Go and TypeScript, built in G.** The writer every observer uses is + §461's and §485's, built in G in mesh-sdk's `go/views` and `src/views` (exported as `views`), by mesh-sdk's + developer; the TypeScript one is built in G, since the forge module and the registry holders are observers in + TypeScript. `meshconditionsclient/findings` goes (§461). Why: develop questions GIT14, REG2 and WM11. How it is + checked: §461's. +- §504 **The builder maps a package's name as §478 does.** Every builder answer asked by a package's name in its + ecosystem, `builder_versions` and the registry holders' check of a publish by name, version and digest included, + finds the entry carrying that name (§478, §491) and the artifact whose package it is, `:`, and + answers for that artifact. Why: one mapping, the builder's own fact (develop question BL7). How it is checked: unit + (builder), a Go module path and an npm name each answered for their artifact. +- §505 **A manifest `version` that is not `MAJOR.MINOR` reserves nothing.** A build of a module whose catalog entry's + `version` is not `MAJOR.MINOR` (a manifest from before G, `"1"`) reserves no version and is built and delivered as a + build without a version (§371, §458), the builder writing it in its journal naming the module; at G's heads the + validator refuses such a manifest (§411). Why: such an entry is only read from a revision before G (develop + question of the builder). How it is checked: unit (builder), an entry of version `"1"` reserves nothing. +- §506 **The entry carries its manifest's digest.** The catalog graph entry gains `manifest-digest`, the `sha256:` + digest of the manifest's bytes as the forge answered them, set by the indexer at take-in (in `EntryInputs`) and + never computed again from the manifest whole, whose encoding may differ; the module's value and §445's + `manifests` key are that digest. Why: the bytes, not the map, are what the node-engines before G read (develop + question IX16). How it is checked: unit (indexer), the entry's digest is the digest of the bytes read. +- §507 **The watched branches before the first registrations.** Every reader of a trunk's source revision reads, per + watched branch the registrations name, `source.` through the gate's verb `source`; before the first + registrations (§95, §353), the watched branches are the branches the gate's `source` answers, which G's switch + carries in from `source.main` as the branch `main`, read from the key and never fixed in code (§7). The assigner's + trunk-only want, the status view and the forge bridge read so, and the bridge watches the same branches. Why: §7, + and one source of the branches for every reader (develop questions Q18 and VW0, and the bridge's FB9). How it is + checked: whole (assigner, bridge), before the first registrations a want is written from `source.main`, and no + part's code holds `main`. +- §508 **The node-engine claims its seat as one module.** The seat `node-engine`'s definition in mesh-contracts no + longer marks it held by the engine; the manifest validator accepts one module of a revision claiming it and + refuses a second, naming both, in place of refusing every claim, and §494's release carries the rule. The + node-engine's guard reads the holder from the seat list (§364). Why: §364 has the node-engine's manifest claim the + seat (ADR 0563 §1), and the mark and the rule refused it (develop question on §364). How it is checked: unit + (manifest validator), one claim accepted and two refused; unit (definition), no mark. +- §509 **What the forge bridge writes on `forge`.** For each move of a watched branch, after reading the commit by + `git.branch` (§11), the bridge writes one message: `merged` when the forge names the commit a pull request's + merge, with that pull request, as on main; `pushed` when it names none, with the repository, the branch, the + commit and the head before; the indexer takes both in alike. For a move of a branch whose protection was removed + (§17) it writes nothing and says `branch-unprotected`; the next move after the protection is back is written as any. + 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.** 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 + (develop question on §167 and §169). How it is checked: whole (gate, bridge), a carried merge lands once after the + first registrations. +- §511 **The assigner's `written` key.** §352's key holds the newest passed `pipeline-ended` heard for that module and + watched branch, its source revision and end count, and `written`, whether its wants were written; a newer end + replaces it by compare-and-set, and the wants are written from it once they can be. Why: a restart loses no end heard + and not yet used (develop question on §352). How it is checked: whole (assigner), an end heard, then a restart, + writes its wants. +- §512 **The status view's tiers from the difference.** A tier's module is `{module, build, version, after, waits, + left-out}`: `build` the fingerprint, `after` the modules it is ordered after, each with the edge's kind (§378), + from `difference`; a wait is `{owner, step, node, on, bound, since, words}`: the seat holding it, its `step` + (§498), what it waits on, from the owners' `wait-held` and their read tools, and a pending revision from + `indexer_pending` with `owner: mesh-catalog`, `step: take-in`. The view's manifest drops its `reads` of the + teller's `answers` and the gate's `asks` and `source`: the Approve per merge goes (§431), its reach is the + catalog half's (§196) and its source `source-moved` (§507). A dependent's delivery wait is read from the assigner's + `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.** 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 + `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. +- §514 **The teller tells through `notify`, on every channel.** For `widens` (§71, §335), `recovery-merged` (§81) + and a `forge-made` record (§170) the teller calls the seat `operator-channel`'s verb `notify`, named in its + manifest's `invokes`, with `every-channel: true`, which the router sends on every channel's `send`, as design 46 + announces a break-glass act. The words are the operator's to approve and wait for them (develop questions TL1 to + TL3). How it is checked: whole (teller, router), each of the three reaches every channel once. +- §515 **The condition keeper's sources are its consumers' bindings.** The keeper learns that the grants part made a + source module's durable consumer (§386) from the seat `mesh-broker`'s binding of that consumer to the keeper (§399), + heard as its event and read by `list` at the keeper's start, and asks `findings-asked` naming the module on it. At a + start with no kept sources and no first view of the catalog half, its sources are the modules its consumers' + bindings name, so no list of observers is fixed in its code (§7); the catalog half then adds and removes sources + (§365, §388). Why: the binding is the fact that the consumer exists (develop question COND2). How it is checked: + whole (keeper, grants part), a module declaring the finding events is asked once its binding is said; started with + the catalog's holder stopped and no kept sources, the keeper hears every bound observer. 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 96701744..567428d0 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.** Each state asked by the template `state` gets its object store +- §58 **One object store per state, granted to its owner.** (§513) 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 @@ -123,8 +123,8 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli - §69 **A step's result from its holder only.** The runner takes a step's result only from the bus account of that step's seat holder, naming the commit and the build-input fingerprint; a result from another account, or naming another commit or fingerprint, is refused and said (ADR 0666 §21). -- §70 **A review gates, once it can.** A code review's result is taken through the verb `review` from the reviewer's bus - account and refused from the commit's author, so a review gates where a policy says `required` (ADR 0666 §22, which +- §70 **A review gates, once it can.** (§482) A code review's result is taken through the verb `review` from the reviewer's bus + account, and in G refused from no one for authorship, recording the caller the bus proved (§482); a review is to gate where a policy says `required` once a record binds the accounts (ADR 0666 §22, which changes ADR 0659 §2). Until a record binds each forge account to its bus identity no policy may say it (*A module's registration*; issue 1966, note 157). - §71 **A widening is said, never refused.** A change that alters any part serving a step (the runner, step detection, the @@ -133,7 +133,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli against those of the watched branch, never the runner built from the change, so a change cannot hide its own widening; nothing refuses it for that (ADR 0666 §23, the operator, 2026-11-10). The teller passes `widens` on to every channel, as it does `recovery-merged`. This is what replaces ADR 0656 §8's naming in the Approve ask. -- §72 **How it is checked.** Whole (runner, grants part): a forged step result and an author's own review are refused; a +- §72 **How it is checked.** (§482) Whole (runner, grants part): a forged step result is refused and a review records its proven caller; a caller not in a verb's `callers`, and any caller but the holder roles and the operator of a verb with no `callers`, are refused by the bus; a change widening a grant, and one altering the Go build module's test runner, each name it in `widens`, computed by the running runner, and are delivered. Tests 85 and 86. @@ -155,7 +155,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli - §74 **What a session hears after its merge.** Between its `merge-pull` and the delivery, a session waits with `mesh_wait` on the runner's `pipeline-started` and `pipeline-ended` of its module, branch and commit, and then on the status view's `delivered` of the source revision; a failed head reaches it as `pipeline-failed` (*What holds a delivery*). -- §75 **Nothing stands still unseen.** The watchman times each step's owed progress from `wait-held` and `step-started`, +- §75 **Nothing stands still unseen.** (§496) The watchman times each step's owed progress from `wait-held` and `step-started`, never by run length; a step or a watched branch's head standing still five minutes is its finding `pipeline-stands`, raised by the condition keeper and cleared on the step's end, or for a head on its `pipeline-started` (ADR 0564 §2, §4). A step waiting on a person is said as waiting on that person (ADR 0283), never as a stall; a group waiting for @@ -240,7 +240,7 @@ and an estimated 2 mesh-sdk publishes a day, each rebuilding about 120 artifacts | the indexer | `registrations` and its stream `registration-history` | old `state` and `streams` sections | the life of the mesh, never derived again | 64 MiB (*A module's registration*) | | the indexer | catalog graph revisions, per watched branch | objects in the old form (ADR 0619 §2) | while a record pins it or it is its branch's current | 512 MiB, as *Two graphs, one source of truth*; a second watched branch on a few modules adds a few MiB | | the gate | `source`: one key per watched branch | its old `state` section, as today | 64 revisions of each key; a branch's key deleted when `registration-changed` says the last registration watching it unwatched it (`unwatch`) | a few KiB | -| the forge module | `failed-steps`: failed `required` steps by module and fingerprint, with the commits each was seen at | state | an entry deleted once none of its commits is a watched branch's head or the head an open pull request names, judged on each `branch-moved` and each pull request's close | the template's 64 MiB; an estimated 50 failed steps a day of about 0.5 KiB, most gone within days, is under 1 MiB | +| the forge module | `failed-steps`: failed `required` steps by module and fingerprint, with the commits each was seen at, and the `seen` keys of §487 | state | an entry deleted once none of its commits is a watched branch's head or the head an open pull request names, judged on each `branch-moved` and each pull request's close | the template's 64 MiB; an estimated 50 failed steps a day of about 0.5 KiB, most gone within days, is under 1 MiB; the `seen` keys under 3 MiB (§487) | | every module that imports the object store package | `-objects` beside each state | objects | an object no key names, its key deleted or its value replaced, until `_state_objects_drop` on a person's word (ADR 0595 §4, ADR 0666 §16) | the template's; nothing reserved until written | | every sender of the new form, and a foundation part by its old `objects` section | `_sent-objects` (`sent-objects`) | objects, planned by the bus module with no manifest field | 7 days, transport (*Any size*) | the objects template's cap; full is the bus module's `full` | | the grants part, for each seat event a definition keeps | `SEAT__`, among them `SEAT_mesh-pipeline-runner_*`, `SEAT__step-ended`, `SEAT_git_branch-moved`, `SEAT_mesh-builds_package-published` and `SEAT_mesh-catalog_registration-changed` | a stream the grants part makes with its durable consumers | the seat definition's age (`keep`), 90 days unless the definition names less | the seat definition's cap (`keep`) | @@ -290,7 +290,7 @@ step keys and the builder's build log, against the checker's last week (test 99) - §94 **A node-engine of the version before applies what it can read** (ADR 0667 §9): it applies every want whose manifests use no field it does not read, and a want that uses one waits, by the reader edge above, for the new node-engine on that node. -- §95 **The new assigner and the new merge switch on the first registrations** (ADR 0667 §10). The new assigner, which +- §95 **The new assigner and the new merge switch on the first registrations** (§507) (ADR 0667 §10). The new assigner, which writes a want only from a passed pipeline, is delivered before the forge module's new `merge-pull`, which asks no Approve, and before the runner: an edge of kind 4 from `mesh-delivery-assigner` to each, declared in their manifests' `needs` since nothing else says it (the design's choice: without it a merge made with no Approve could reach the old 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 b4ecce4d..4ce2f5e9 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 @@ -71,7 +71,7 @@ ADR 0656. - §147 **It ends when every present node runs its entries**, and the gate says `record-ended` on the seat `mesh-delivery` with the record's milestone and its nodes away. It names the nodes away, each with since when, and ends without waiting for them, as a node away holds nothing (ADR 0603 §7). -- §148 **A record open too long is a finding.** The watchman writes the finding `record-open` for a record still open 24 +- §148 **A record open too long is a finding.** (§502) The watchman writes the finding `record-open` for a record still open 24 hours after its merge (a delivery of the whole mesh takes under an hour, so a day means something stands still) and clears it on `record-ended`; the condition keeper raises it (ADR 0564 §2). The finding names the entries still held or failed, read from the record's own events. It is written only while no other condition covers the record: while @@ -184,7 +184,7 @@ checker's `mesh/check` from a watch of the checker's state `owed`: reads of anot forge call's time, and short beside the check's hour. - §166 **A group's merges follow one another, until G's delivery.** The gate says a group's next `merge-pull` only once the previous member's merged message is heard (ADR 0441 §5), so a member the forge refuses holds the rest, and none is merged ahead. -- §167 **From G's delivery the gate owes no merge, and the checker nothing.** A session calls `merge-pull` itself (ADR 0666 +- §167 **From G's delivery the gate owes no merge, and the checker nothing.** (§510) A session calls `merge-pull` itself (ADR 0666 §11), and a group's members land one by one, the group ending when every member has (*Groups*); the checker's `owed` goes with the checker, and the runner owes the forge nothing, a pipeline's result living on the bus. The gate still owes the delivery's view, a comment and the note's line, performed by the forge bridge as above. @@ -194,7 +194,7 @@ 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.** At the new gate's start (*The switch carries today's state in, once*) every key +- §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 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: @@ -343,7 +343,7 @@ Findings 11). How each is kept, read and retained is this design's choice under ### A change's graph difference is its delivery -- §186 **The difference names everything a plan named.** For a change (a pull request's heads, a delivery group's +- §186 **The difference names everything a plan named.** (§512) For a change (a pull request's heads, a delivery group's heads, or a merge), the indexer gives its catalog graph and the assigner its assignment graph. Compared with the current revision, the difference names the new versions, the moved edges, the touched nodes and the order, read off the edges, and no plan is stored (ADR 0656). The assigner serves it by the seat `mesh-wants`'s verb `difference`, 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 28ab75b1..6ce9f057 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 @@ -59,7 +59,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli them). From G's delivery a running part acts on a revision of a watched branch as on a trunk revision, and a candidate's view is read only by a run on request's steps, the grants part's `grants-for` (§441) and the indexer's candidate pass (ADR 0666 §6, §18). -- §196 **Every other reader of which modules exist reads the catalog half, in the same milestone.** From milestone G the +- §196 **Every other reader of which modules exist reads the catalog half, in the same milestone.** (§500) From milestone G the indexer declares no state `modules` and serves neither its tool `indexer_read_modules` nor a view of it (*Reverted*, above), so every module that learns from it which modules exist moves in milestone G, not after: the watchman (its manifest findings), the status view (`view_reach`), the forge module (which repositories its account writes), the @@ -173,7 +173,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli change of mesh-sdk's runtime, which rebuilds every module once (ADR 0656, Consequences), and one of the node-engine; the order between them is the composing step's wait of the node-engine (*Order without a person*, below), so a module whose runtime reads the value is composed only by a node-engine that hands it. -- §206 **The build seat's ask that runs a program in the sandbox.** The checker asks the seat `node-build-go` for an ask +- §206 **The build seat's ask that runs a program in the sandbox.** (§481, §483) 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), asked of the seat `mesh-delivery-checker`'s verb `input` and diff --git a/03-DESIGN/01-to-be/47-milestones/G-5-acting-parts-check-and-kept-data.md b/03-DESIGN/01-to-be/47-milestones/G-5-acting-parts-check-and-kept-data.md index 7a924046..7f899b12 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-5-acting-parts-check-and-kept-data.md +++ b/03-DESIGN/01-to-be/47-milestones/G-5-acting-parts-check-and-kept-data.md @@ -58,7 +58,7 @@ names go, since every new acting part needed code changes elsewhere (research 08 - §265 **The rule becomes edges between versions.** In the assignment graph the assigner gives an edge from the acting part's version to each version its rule names, and no part names another module in its code to order by (ADR 0656). -- §266 **Within a revision the new version acts first, a wait with a bound.** The entries an acting part acts on wait for +- §266 **Within a revision the new version acts first, a wait with a bound.** (§498) The entries an acting part acts on wait for its new version in its own step, with the bound its rule's `bound` gives (ADR 0656), the part's own as ADR 0603 §8 has every wait. A bound's clock starts when the new version's build is done, as the builder's `build.ended` of that version says, its time carried in `wait-held` as `clock-from`, not when the wait begins, so a slow @@ -79,7 +79,7 @@ names go, since every new acting part needed code changes elsewhere (research 08 own want first and every other want once it runs the new one, so an old node-engine never composes a module it cannot read. The clock of that node's bound starts when the node is present and its node-engine's want is written, so a node asleep raises nothing while away. -- §269 **A failed or late new version holds its modules, and a condition names it.** When the new version fails, or its +- §269 **A failed or late new version holds its modules, and a condition names it.** (§498) When the new version fails, or its wait passes its bound, the entries waiting for it stay held, the modules stay on their running builds, and the watchman writes the finding `acting-part-late` naming the acting part, its step and since when, and the condition keeper raises it (ADR 0564 §2). The holder says `wait-held` at the start of the wait, carrying the acting part's new @@ -97,7 +97,7 @@ names go, since every new acting part needed code changes elsewhere (research 08 what its new version is built from or needs (a base, a package, a provider) is acted on by its running version, never waited for: the running build module builds the shared contracts and the registry holder, then the new build module builds the rest, so ADR 0614 §6's cycle through them stays allowed, now for that reason. -- §271 **The artifact store's holder takes its own new build even when its seat is the one broken.** A build module +- §271 **The artifact store's holder takes its own new build even when its seat is the one broken.** (§499) A build module stores the artifacts it builds through the seat `oci-artifact-registry`, so the holder of that seat is in its own build's path: its new build needs the store it replaces. As every holder's own inputs are (above), that store is acted on by the running holder: the running holder stores its new build, and only diff --git a/03-DESIGN/01-to-be/47-milestones/G-6-verbs-and-retires.md b/03-DESIGN/01-to-be/47-milestones/G-6-verbs-and-retires.md index 45ceb2c4..aa43ef48 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-6-verbs-and-retires.md +++ b/03-DESIGN/01-to-be/47-milestones/G-6-verbs-and-retires.md @@ -59,7 +59,7 @@ of each verb (ADR 0666 §7, §20, §25): | `run` | the run on request of one or more members, each a module at a named commit; delivers nothing | the sessions (the agents' bus identities the tool runner proves) and the operator, nothing else | | `start` | a delivering pipeline for a watched branch's head, by hand | the operator, the healers | | `show`, `list`, `stands`, `why-carried`, `kept` | one pipeline whole with its step log; the pipelines and runs of a module, a branch or a commit; what stands still; where a result was carried from; the kept results | any person, an agent session, the healers | -| `review` | a code review's result for a commit and fingerprint | sessions; refused from the commit's author (§394) | +| `review` | a code review's result for a commit and fingerprint | sessions; refused from no one for authorship in G, its proven caller recorded (§394, §482) | | `rerun`, `accept`, `cancel`, `ask-again` | one step again; a failed `optional` step accepted with why; a pipeline ended, its asks dropped; a declined `approval` asked again | the operator, the healers (`accept` and `ask-again` the operator; §391, §394) | §307 **The seat `mesh-catalog`** gains, from milestone G's delivery, `register`, `policy`, `watch`, `unwatch` and 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 f9a5c1a3..5cf04515 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 @@ -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.** An accepted kind of a work queue carries `callers` as a verb does, and the grants part +- §338 **Callers on accepted kinds.** (§480, §481) 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 @@ -245,13 +245,13 @@ record it follows from, and replaces the builder's own choice where one was made - §351 **One rule for asking again.** mesh-sdk's kept-call form (ADR 0668 §7) asks an ask again only while it is open and not replaced, and every asker and every hand ask-again tool uses it. How it is checked: unit (mesh-sdk), a replaced ask is not asked again. -- §352 **The assigner's newer-revision check reads its own state.** The check adds no field to the want (*Composing waits per +- §352 **The assigner's newer-revision check reads its own state.** (§511) The check adds no field to the want (*Composing waits per node*): the assigner keeps in its old `state` section `written` one key per module and watched branch, the source revision and end count it last wrote that module's wants from, compares a new `pipeline-ended` with it by compare-and-set, and deletes the key when `registration-changed` says the branch is no longer watched; its tool `assigner_written` reads it. How it is checked: whole (assigner), an older revision ending after a newer one writes nothing, and a later end of the same revision writes. -- §353 **The assigner follows the registrations.** `mesh-delivery-contracts`' client `meshcatalogclient` carries a typed +- §353 **The assigner follows the registrations.** (§507) `mesh-delivery-contracts`' client `meshcatalogclient` carries a typed follower of `registrations`, a first view then `registration-changed`, built on `go/views`; the assigner and the forge module's merge switch on its first registrations (ADR 0667 §10). How it is checked: whole (assigner), it keeps the trunk-only want until the first `registration-changed`. @@ -299,7 +299,7 @@ record it follows from, and replaces the builder's own choice where one was made ### The condition keeper and the node-engine -- §364 **The node-engine claims its seat.** The node-engine's manifest claims the node seat `node-engine` (ADR 0563), and +- §364 **The node-engine claims its seat.** (§508) The node-engine's manifest claims the node seat `node-engine` (ADR 0563), and the indexer and the node-engine's own guard read its holder from the seat list, keeping no module name. How it is checked: the code review reads that neither fixes a module name (§7). - §365 **The condition keeper finds its sources in the catalog.** The catalog graph entry carries the events each @@ -325,7 +325,7 @@ record it follows from, and replaces the builder's own choice where one was made ### From round 1 of the review by architectural domain (2026-11-10) -- §366 **The runner's stores say their fill.** *A store filling is said before it is full* holds for the runner's +- §366 **The runner's stores say their fill.** (§486) *A store filling is said before it is full* holds for the runner's `pipelines`, `step-outputs` and `kept`: it says their fill in `show` and `kept`, `filling` past 80 % and `room` below 70 % on its seat, and `full` at the cap, when it starts no new pipeline, says each start it refused, and takes them up on `room`; nothing is dropped to make room. Why: the runner joins the stores of *Two graphs, one source of truth* @@ -376,7 +376,7 @@ record it follows from, and replaces the builder's own choice where one was made releases a version; a build of another watched branch reserves none, publishes no version and is delivered by its build, its fingerprint, as every want names one. Why: the operator, 2026-11-10. How it is checked: whole (builder), a `beta` build reserves nothing and is delivered. -- §372 **The catalog's versions start from what is published.** At the new indexer's first start, `versions` is filled +- §372 **The catalog's versions start from what is published.** (§504) At the new indexer's first start, `versions` is filled once, as released, for each module from the highest `published` version over every artifact of the module that the builder's state `versions` held (for mesh-sdk the higher of Go's `v0.1.14` and npm's `0.1.18`, so `0.1.18`), read by `builder_versions` as a kept call (ADR 0668 §1, §2), which the indexer's manifest names in its `invokes` @@ -451,7 +451,7 @@ record it follows from, and replaces the builder's own choice where one was made hand, for one dependency or all. A restart or a missed event so leaves nothing behind. Why: the operator, 2026-11-10 (issue 1961's "outdated"); `runner_catch_up` replaces the indexer's hand tool, which would have had to say another part's event (the design's choice, round 2 of the review by architectural domain, 2026-11-10). How it is checked: test 105. -- §376 **A stale edge rebuilds on its event; a delivery is waited for mesh-wide.** The rebuilds start on two events +- §376 **A stale edge rebuilds on its event; a delivery is waited for mesh-wide.** (§498, §512) The rebuilds start on two events the runner consumes: kind 1 on `package-published` (§53), and kind 3 on `toolchain-agreed`, which the builder says on its seat `mesh-builds` when the agreed toolchain of a language changes (ADR 0584 §1), naming the language, the version and the toolchain part's digests (§472); for each, the runner asks `outdated` for that dependency and starts a pipeline for each dependent behind. `version-released` starts no rebuild. No other edge rebuilds or delivers anything diff --git a/03-DESIGN/01-to-be/47-milestones/G-8-findings-heard-as-events.md b/03-DESIGN/01-to-be/47-milestones/G-8-findings-heard-as-events.md index 12c9393e..07ec37b0 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-8-findings-heard-as-events.md +++ b/03-DESIGN/01-to-be/47-milestones/G-8-findings-heard-as-events.md @@ -132,7 +132,7 @@ record says so in its Why. Round 3 of the review by architectural domain (2026-1 observer whose stream is missing says nothing the keeper hears; the list is read from main on 2026-11-11 and the rule is the design's choice. How it is checked: unit (manifest validator), a manifest with `findings` and no finding stream refused; the catalog's validation at G's heads refuses none of these manifests. -- §388 **The keeper keeps its sources in its own state, and raises its own findings itself.** The keeper keeps its +- §388 **The keeper keeps its sources in its own state, and raises its own findings itself.** (§515) The keeper keeps its list of sources (each module whose catalog entry declares the finding stream, with the nodes it heard and each observer's last stated set and open asks) in its own state `findings-views`, in the form of its `conditions`, one key per observer and node, deleted when the module leaves the catalog (§365) or the node (§365). At its start it applies 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 2f37770f..93f8a643 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 @@ -59,9 +59,9 @@ line says so.* on main, written in §392's forms, or their class's default where the table names none (§447), and that table goes from the node-engine's code: the definition is the one source (§68). Why: the design's choice (Q-H8). How it is checked: unit (definition reader), each of the eleven names its callers; the code review finds no callers table in the node-engine. -- §394 **The callers of G's new trusted acts.** `mesh-catalog`'s `register`, `policy`, `watch` and `unwatch`, and +- §394 **The callers of G's new trusted acts.** (§482) `mesh-catalog`'s `register`, `policy`, `watch` and `unwatch`, and `mesh-delivery`'s `recovery`, are of class `act`: the operator and sessions; `registrations` is a `read`. - `mesh-pipeline-runner`'s `review` is called by sessions, and refused from the change's author (§70); its `accept` by + `mesh-pipeline-runner`'s `review` is called by sessions, refusing none for authorship in G (§482); its `accept` by the operator alone, which amends §30's "a person". `operator-channel`'s `ask-again` is a seat verb, its callers the operator and the healers (§83, §40). Why: the operator, 2026-11-11 02:56 CET on Telegram, "As proposed" (S4, S10, C18, D2, D3, D4). How it is checked: whole (indexer, runner, operator-channel), a call from any other caller is @@ -91,7 +91,7 @@ line says so.* - §398 **The step `place` is `mesh-wants`'.** The step `place` is declared in the definition of the seat `mesh-wants`, where §260's table has the assigner's placing waits. Why: the design's choice (Q6). How it is checked: the seat's fixtures. -- §399 **A binding names its objects and its sent store.** The binding of a state, as the seat `mesh-broker` answers +- §399 **A binding names its objects and its sent store.** (§513) The binding of a state, as the seat `mesh-broker` answers it, gains `objects`, the bus name of its `-objects` (§58), and a module's sent store is a binding entry `sent-objects` (§59), so a module learns both names from its bindings. The binding is one form wherever the seat answers it: in its events and in `list`'s answer, from which the grants part takes its first view of every binding @@ -144,7 +144,7 @@ line says so.* `objects` section as its states are (§176, §194). Why: the design's choice (S14, D17, Q-T3, S13, Q-T4, Q-T5). How it is checked: unit (`go/stateobjects`), an old section and a template store each take a large value; whole (tool runner), a large reply read back. -- §408 **The ledger's calls.** The ledger's fill and removal calls are in mesh-sdk's `buscalls`, under the existing +- §408 **The ledger's calls.** (§488) The ledger's fill and removal calls are in mesh-sdk's `buscalls`, under the existing `ledger` calls (§155, §159, §181); no capability word `ledger-fill` is added; their names and capability are §462's. Why: the design's choice (S15, Q-T6). How it is checked: the code review. - §409 **The reader release reads every new form G writes** (and §471's second release, one more word). The reader release of §340 reads every new definition @@ -160,7 +160,7 @@ line says so.* ### Versions -- §411 **`version` replaces the old field, and `series` goes.** Every manifest's top-level `version` takes the +- §411 **`version` replaces the old field, and `series` goes.** (§505) Every manifest's top-level `version` takes the `MAJOR.MINOR` of §368 in the same change, replacing today's `"1"`, and each artifact's `series` goes, refused by the manifest validator; a contracts module's version is `0.1` unless §372's fill gives higher. Why: one version per module (§52, §374; Q15, S1, Q-H3, D14). How it is checked: unit (manifest validator), `series` refused. @@ -257,7 +257,7 @@ line says so.* kept, writes nothing for a repository it has no key of, and raises `call-unanswered` after five minutes. Why: the design's choice (C12, D18). How it is checked: whole (gate), `source` answers before any registration, and with the forge stopped it serves its kept keys and says `call-unanswered`. -- §431 **The fate of the gate's other parts.** From G's delivery the gate's `asks` go with the Approve per merge; +- §431 **The fate of the gate's other parts.** (§512) From G's delivery the gate's `asks` go with the Approve per merge; `deliveries`, `show`, `groups` and `stalled` are answered from the delivery records; `checks` and `settle` go with the merge states, and the five verbs of release 6 leave the definition; the events `group` and `merged` go, while `transition` stays; their readers move: the knowledge base's delivery overview (what `knowledge-base.progress` @@ -333,7 +333,7 @@ line says so.* ### From the review of step 0b (2026-11-11) -- §443 **The catalog graph's entry carries the manifest, and is kept while a build names it.** Each catalog graph +- §443 **The catalog graph's entry carries the manifest, and is kept while a build names it.** (§506) Each catalog graph entry carries the validated manifest whole beside the fields §174 names, kept as an object of the indexer's old `objects` section by its digest (§179), so no size limit applies to it. The indexer keeps an entry while a kept revision lists it, or a want (heard by `mesh-wants`' `wanted`) or a running build (heard by the node-engine seat's diff --git a/03-DESIGN/01-to-be/47-milestones/G.md b/03-DESIGN/01-to-be/47-milestones/G.md index dc3684fb..d57662f8 100644 --- a/03-DESIGN/01-to-be/47-milestones/G.md +++ b/03-DESIGN/01-to-be/47-milestones/G.md @@ -87,4 +87,5 @@ The part is ten files, each read whole, its design lines numbered across them: - [G-7-answers](G-7-answers.md): the answers to the builders', the reviewers' and the operator's questions (§322 to §382). - [G-8-findings-heard-as-events](G-8-findings-heard-as-events.md): the operator's answers of 2026-11-11, findings heard as events (§383 to §390). - [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 on). +- [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 on).