00-META/glossary.md

@@ -1337,7 +1337,10 @@ Not a domain of the mesh but of the way it is built, listed because its words me
   *Not:* ~~context file~~ (hq)
 - **design question** — what a milestone's builder would have to choose because its milestone part does not say it:
   a field, a key, a bound, an owner, a caller, an event, a fate for what exists. It is asked of the operator, and its
-  answer is written into the design before any code builds it (playbook 02); nobody else answers it. A milestone's
+  answer is written into the design before any code builds it (playbook 02); nobody else answers it, save one of
+  internal form only (changing nothing the operator sees, no permission and no data kept or removed: a wire form, a
+  function's input, a contract field's shape, a package's place), which the design writer answers as a design line
+  read by the reviewers by architectural domain (playbook 07, step 0). A milestone's
   design is **complete** when no design question of it is open (playbook 07, *Design complete*).
   *Not:* ~~open point~~ (hq)
 - **issue** — a question about the mesh that someone must answer, numbered and tracked by the issue tracker, which

00-META/process/02-graduation.md

@@ -192,7 +192,11 @@ be built (the cycle test reads only a design's main file today).
 ## Answering a design question
 
 A design question (playbook [07](07-feature-branches.md), step 0) is answered by the operator and by nobody else:
-not by the lead, the preparer, a developer or a reviewer, however technical it is. The lead asks it as the
+not by the lead, the preparer, a developer or a reviewer, however technical it is. The one exception is a question
+of internal form only (playbook 07, step 0, *Who answers a design question*; the operator, 2026-11-11): changing
+nothing the operator sees, nobody's permissions and no data kept or removed, it is answered by `hq-design-writer` as
+a design line of the milestone part with its reason, under the record it follows from, read in item 3's round, and
+told to the operator in one line. The lead asks it as the
 instruction on asking says, one question per ask, with what the milestone part says, what it leaves open, where it
 was met (file:line) and a recommendation. Then:
 
@@ -210,8 +214,9 @@ was met (file:line) and a recommendation. Then:
    part at that branch's head.
 
 How it is checked: every design question in the milestone file names the hq commit that answers it; a design line
-added during a milestone with no operator's answer or record behind it is a finding of the review by
-architectural domain.
+added during a milestone with no operator's answer or record behind it, other than an answer of internal form only
+that touches nothing the operator sees, no permission and no data, is a finding of the review by architectural
+domain.
 
 ## Amending an existing design
 

00-META/process/07-feature-branches.md

@@ -54,8 +54,8 @@ A small fix (one repository, one issue, about an hour of work) follows
   and the code; a developer refused an event the design names; and an audit found seven rulings against the records
   or the design (among them a store kept twice and a copy of another part's data) and 29 questions the design never
   answered, all found in develop. The design is now the only input to the prepare and to develop, the prepare's only
-  output is where each design line lands and what the design does not answer, nobody but the operator answers that,
-  and develop starts only when it is all answered (step 0b, *Design complete*).
+  output is where each design line lands and what the design does not answer, the operator answers that (or, for a
+  question of internal form only, the design writer, step 0), and develop starts only when it is all answered (step 0b, *Design complete*).
 - **A module proven only after it reached the machines.** The mail modules were delivered with unit tests
   only, then failed live three times (issues 859, 865, 868) and took five more hours of fixes.
 
@@ -68,7 +68,7 @@ opened **once**, after the review, and **one check** (ADR 0548). It runs in five
 | Step | What happens | Bound |
 |---|---|---|
 | 0. Prepare | from the milestone part alone: where each design line lands in code, what exists there today and what relies on it, as one build map per repository; and every design question, the design's silences, listed | 15 minutes, longer when what exists is large: code never starts on an incomplete answer |
-| 0b. Design complete | the operator answers every design question; each answer is written into the milestone part (playbook 02) and its build map rows added | until the list is empty: develop never starts before |
+| 0b. Design complete | every design question is answered, by the operator or, for one of internal form only, by `hq-design-writer` (step 0); each answer is written into the milestone part (playbook 02) and its build map rows added | until the list is empty: develop never starts before |
 | 1. Develop | one fixing agent per repository builds every design line of its build map locally, each commit citing the lines it builds, the whole unit suite before every commit, the integration tests compiled, and once per head it reports those of the packages it touched and their importers run against an embedded bus (below); nothing is pushed | the milestone's issues, 30 minutes each |
 | 2. Review | one reviewer reads all of it, the local commits, judging the integration tests by reading them against the code; reports go both ways; at most 3 rounds | 15 minutes |
 | 3. Check | push the reviewed heads once and open the pull requests together; the checker's one check runs the integration tests; no further review unless the check fails | one check run |
@@ -137,16 +137,23 @@ are held where they are decided: the reviewers by architectural domain judge the
 - **The prepare's only output** is one build map per repository (item 4) and the list of design questions
   (item 10). It writes no findings of its own, no recommendations into the build map and no rulings, and no file of
   the milestone holds a statement of how something should be.
-- **Nobody but the operator answers a design question**, however technical: not the lead, not the preparer, not a
-  developer or a reviewer, and not a lead of another session. The lead's part is the process: who works on what, on
-  which model, the waits and the reports, and asking the operator.
+- **Who answers a design question** (the operator, 2026-11-11). A question that changes nothing the operator sees,
+  nobody's permissions (who may call, publish or read what) and no data kept or removed (an internal wire form, a
+  function's input, a helper's API, a contract field's name or shape, a package's place) is a question of internal
+  form only: `hq-design-writer` answers it as a design line from the design and its records, with its reason, the four
+  reviewers by architectural domain read it in one round, and the lead tells the operator each such answer in one
+  line. Every other design question is the operator's, however technical: not the lead's, the preparer's, a
+  developer's or a reviewer's, nor a lead's of another session; one that seems internal but touches who may call,
+  what the operator sees or data is the operator's. The lead's part is the process: who works on what, on which
+  model, the waits and the reports, and asking the operator.
 - **One milestone has one lead.** A session that held part of the work hands its branches and heads to the lead and
   stops; between sessions travel heads, commits, design questions and the hq commits that answer them, never an
   instruction on how to build.
 
 How it is checked: every subtask in a build map and every commit of the milestone cites the design lines it builds
 ("design NN M §n"), and the review finds code that cites none (step 2, item 2a); the milestone's files hold no
-rulings (`grep -n -i 'ruling' .work/<slug>/*.md` finds none); a question answered by anyone but the operator is a
+rulings (`grep -n -i 'ruling' .work/<slug>/*.md` finds none); a question answered by anyone but the operator, other than one of
+internal form only answered by `hq-design-writer` in a design line the reviewers by architectural domain read, is a
 breach the lead names at the next report.
 
 1. **Name the feature once:** `feat/<slug>`, the same branch name in every repository it touches (but see the
@@ -289,10 +296,13 @@ Develop starts only when the milestone's design questions are all answered, each
 2026-11-10: a question the design does not answer stops that part, goes to the operator, and its answer goes into
 the design before the code).
 
-1. **The lead asks the operator each question**, one per ask, as playbook [02](02-graduation.md), *Answering a design
-   question*, says, and adds each ask to its wait list. The lead answers none and passes on no answer of its own.
+1. **The lead sorts each question and asks the operator's.** A question of internal form only (step 0, *Who answers
+   a design question*) goes to `hq-design-writer` in its handover; every other one the lead asks the operator, one per
+   ask, as playbook [02](02-graduation.md), *Answering a design question*, says, and adds each ask to its wait list.
+   The lead answers none and passes on no answer of its own; a question the writer finds is not of internal form only
+   it hands back for the operator.
 2. **Each answer is written into the milestone part** by `hq-design-writer` on hq's branch of the milestone, as a
-   design line (or, outside every record's question, after its decision record), and the four reviewers by
+   design line (the operator's citing the operator and the date, the writer's own giving its reason) (or, outside every record's question, after its decision record), and the four reviewers by
    architectural domain read the amended part in one round.
 3. **The preparer adds the new lines to the build maps** (item 4) and the question's entry names the hq commit that
    answers it.
@@ -302,7 +312,8 @@ the design before the code).
 **A question met later stops only its part.** A developer or the reviewer who meets a question the milestone part
 does not answer stops the subtasks that need the answer, says the question to the lead with the design line and
 file:line, and goes on with the subtasks that do not; the lead adds it to the list and asks it as above, and the
-stopped subtasks resume from the hq commit that answers it. Nobody builds around it, guesses it or builds both ways.
+stopped subtasks resume from the hq commit that answers it; one of internal form only goes to `hq-design-writer` as
+item 1 says. Nobody builds around it, guesses it or builds both ways.
 **A decision accepted while the milestone is built** that changes its part stops the subtasks of the lines it changes
 until the part is amended (playbook [02](02-graduation.md)) and their build map rows are redone; code written before
 the design was complete joins the milestone only where each of its commits builds a design line of the complete part,

00-META/process/08-small-fixes.md

@@ -47,7 +47,10 @@ processing power"). Everything before the push is local and fast, and no try is
    makes the code do what its issue and its design already say needs nothing more. Anything no design line gives is
    a **design question**: the session asks the operator, one question with its recommendation, and the answer is
    written into the design (playbook [02](02-graduation.md), *Answering a design question*) before any code builds
-   it; neither the session nor the lead answers it. A handover to the developer quotes the design lines and never
+   it; neither the session nor the lead answers it. A question of internal form only (playbook
+   [07](07-feature-branches.md), step 0, *Who answers a design question*) is answered instead by `hq-design-writer`
+   as a design line, read by the four reviewers by architectural domain in one round, and told to the operator in
+   one line. A handover to the developer quotes the design lines and never
    decides a placement itself (2026-11-04: a class placed in mesh-sdk by a lead's handover, against that section,
    passed review and its check). A fix that turns out to need a second repository, or more than about an hour,
    stops here and becomes a feature; one that needs a design question answered stays a small fix. **The session's own model (the larger) then writes the issue's acceptance

00-META/process/playbooks.html

@@ -282,7 +282,7 @@ code{font:12.5px ui-monospace,monospace;background:var(--soft);padding:1px 5px;b
     <h3>Step 0 · what the lead writes before any agent starts</h3>
     <ul style="margin:6px 0;padding-left:20px;font-size:14px">
       <li><span class="tag new">new</span>The milestone part of the design is the only input: the prepare maps each design line onto code (a build map per repository, each row citing its line) and lists every design question, what the design does not answer. It writes no findings or rulings of its own.</li>
-      <li><span class="tag new">new</span>Design complete: the operator answers each question, the answer is written into the milestone part, and only then does develop start. Nobody else answers one.</li>
+      <li><span class="tag new">new</span>Design complete: the operator answers each question, or the design writer one of internal form only (no change to what the operator sees, no permission, no data kept or removed), read by the reviewers by architectural domain; the answer is written into the milestone part, and only then does develop start. Nobody else answers one.</li>
       <li><span class="tag new">new</span>What exists today, read from the code and the live mesh, never from memory: every effect of a part removed or moved (bus writes, files, credentials, plans, processes, calls answered), every reader relying on each, what happens to each after the change and its test. It opens each build map; no code before it is complete, and the review refuses work without it.</li>
       <li><span class="tag new">new</span>Subtasks ordered so a user starts from the commit that adds its contract; one writer per file; one placement of the siblings for every agent.</li>
       <li>Into each issue: every file and test it touches (file:line), how it is checked and delivered, a group's merge order.</li>
@@ -475,7 +475,7 @@ const P = [
  {n:"07",name:"Features",kind:"build",c:"--build",
   trig:"Work that changes code across issues or repositories, too large for a small fix.",
   who:"A lead (larger model), one fixing agent per repository (smaller), one reviewer (larger).",
-  steps:["Prepare: name the branch, make the worktrees, read the milestone part and the design's main file whole. (new)","Every agent is one of hq's definitions (mesh-preparer, mesh-developer, mesh-code-reviewer, mesh-watcher); the lead writes only the handover. (new)","The prepare's only output: a build map per repository, each row a design line and where it lands, and the design questions. No rulings. (new)","Design complete: the operator answers every question, each written into the milestone part; then develop. (new)","Read what exists today from the code and the live mesh: every effect of what is removed or moved, every reader of each, what happens to each and its test. No code before it is complete; the review refuses work without it. (new)","The build map opens with what exists today; subtasks ordered contract first, one writer per file.","Write the findings and acceptance criteria into each issue.","Survey every other reader and writer of each changed value. (new)","Answer three questions in the milestone file: who deletes each new key and stream, how the switch-over is tried on one node first, what the one check does not cover. The review checks them. (new)","List every part the change reaches; copy fixtures from the real writer.","Develop: one agent per repository, one commit per subtask, each citing its design lines; a question stops only its subtask. (new)","A test fails first on behaviour, not on compiling. (new)","Bring each branch up to the trunk; nothing is pushed, no try runs. (new)","Review all of it against the design lines, code no line asks for a finding, reading the integration tests against the code; at most 3 rounds; the report answers the state-and-seams and mesh-agnostic questions. (new)","A group pins the group's own mesh-sdk head in every member. (new)","Push the reviewed heads once and read each forge head against the reviewed commit; no draft pull request, no fix round on an open one. (new)","Open one pull request per repository, together, with Reviewed-by and Pushed-by; the one check runs. A failed check is read, fixed, reviewed, pushed once more. (new)","The operator's Approve on Telegram; the group merges in one pass.","Follow the delivery in the status view (moving, settled, stuck, delivered) to done; resolve the issues; clean up. (new)","When the builder cannot deliver its own fix: revert, a build by a session's call, a registration at the terminal, copies kept outside the store; a broken controller is put back by a want the operator writes, a hand build by mesh-hand-compose and a want. (new)"],
+  steps:["Prepare: name the branch, make the worktrees, read the milestone part and the design's main file whole. (new)","Every agent is one of hq's definitions (mesh-preparer, mesh-developer, mesh-code-reviewer, mesh-watcher); the lead writes only the handover. (new)","The prepare's only output: a build map per repository, each row a design line and where it lands, and the design questions. No rulings. (new)","Design complete: the operator answers every question (the design writer one of internal form only), each written into the milestone part; then develop. (new)","Read what exists today from the code and the live mesh: every effect of what is removed or moved, every reader of each, what happens to each and its test. No code before it is complete; the review refuses work without it. (new)","The build map opens with what exists today; subtasks ordered contract first, one writer per file.","Write the findings and acceptance criteria into each issue.","Survey every other reader and writer of each changed value. (new)","Answer three questions in the milestone file: who deletes each new key and stream, how the switch-over is tried on one node first, what the one check does not cover. The review checks them. (new)","List every part the change reaches; copy fixtures from the real writer.","Develop: one agent per repository, one commit per subtask, each citing its design lines; a question stops only its subtask. (new)","A test fails first on behaviour, not on compiling. (new)","Bring each branch up to the trunk; nothing is pushed, no try runs. (new)","Review all of it against the design lines, code no line asks for a finding, reading the integration tests against the code; at most 3 rounds; the report answers the state-and-seams and mesh-agnostic questions. (new)","A group pins the group's own mesh-sdk head in every member. (new)","Push the reviewed heads once and read each forge head against the reviewed commit; no draft pull request, no fix round on an open one. (new)","Open one pull request per repository, together, with Reviewed-by and Pushed-by; the one check runs. A failed check is read, fixed, reviewed, pushed once more. (new)","The operator's Approve on Telegram; the group merges in one pass.","Follow the delivery in the status view (moving, settled, stuck, delivered) to done; resolve the issues; clean up. (new)","When the builder cannot deliver its own fix: revert, a build by a session's call, a registration at the terminal, copies kept outside the store; a broken controller is put back by a want the operator writes, a hand build by mesh-hand-compose and a want. (new)"],
   prod:"One pull request per repository, one source revision delivered, resolved issues, no branch or worktree left.",
   next:"02 (when it ships)",bounds:"Prepare 15 min · 30 min per issue · review 15 min, ≤ 3 rounds · one check, pushed once",
   prev:["Pull requests as scratchpads","Context bought again and again","A change built on what was remembered, not on what runs","Review rounds spent on what a run would show","A node agent's bus reads, proven only by review"],
@@ -483,7 +483,7 @@ const P = [
  {n:"08",name:"Small fixes",kind:"build",c:"--build",
   trig:"One issue in one repository, about an hour of work.",
   who:"The session, with one reviewer on the larger model.",
-  steps:["Read the issue, the design lines it builds and the code; a design question goes to the operator and into the design before code. (new)","Read what exists in the fix's area today, briefly: every reader of what the fix changes. (new)","Write the acceptance criteria.","Move the issue to fixing.","Build on fix/<issue>-<slug> in its own worktree.","A test that fails today first, on behaviour. (new)","Nothing is pushed and no try runs before the review. (new)","One review of the local commit.","Push the reviewed head once; only then open the pull request. (new)","The operator's Approve; the merge; the delivery, followed in the status view. (new)","Prove the fix live and resolve the same hour.","During a milestone: ride in its delivery group, unless broken for the operator now. (new)"],
+  steps:["Read the issue, the design lines it builds and the code; a design question goes to the operator (one of internal form only to the design writer) and into the design before code. (new)","Read what exists in the fix's area today, briefly: every reader of what the fix changes. (new)","Write the acceptance criteria.","Move the issue to fixing.","Build on fix/<issue>-<slug> in its own worktree.","A test that fails today first, on behaviour. (new)","Nothing is pushed and no try runs before the review. (new)","One review of the local commit.","Push the reviewed head once; only then open the pull request. (new)","The operator's Approve; the merge; the delivery, followed in the status view. (new)","Prove the fix live and resolve the same hour.","During a milestone: ride in its delivery group, unless broken for the operator now. (new)"],
   prod:"One pull request, one delivery, a resolved issue.",
   next:"—",bounds:"About an hour · one review, one push, one check",
   prev:["A fix reviewed after its pull request opened","A long part run twice","A fix waiting on someone else's delivery","Ten SDK merges and eight controller merges in a day, one per fix"],

03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md

@@ -1491,7 +1491,7 @@ way is written down before the switch (ADR 0526, which ADR 0522 §6 asked of R4g
    names it and its node composes it (ADR 0547 §2).
 2. **A build by a session's call.** A session calls the build module's fetch and build tools on one named build node (for Go, a fetch and then
    a build with publishing on); the build module pushes the artifact to the artifact store and answers its reference, as it does for the
-   builder (ADR 0526 §2, ADR 0525 §8). `mesh-pack`, in mesh-sdk, builds and packs a Go bundle with the Go build module's recipe, so a hand
+   builder (ADR 0526 §2, ADR 0525 §8). `mesh-pack`, in mesh-sdk (from milestone G in `mesh-delivery-sdk`, G §464), builds and packs a Go bundle with the Go build module's recipe, so a hand
    build has the build module's form; with the same Go version it has the build module's digest (ADR 0526 §5).
 3. **A registration by reference, at the controller's terminal only.** The operator names the module, its repository, its path and each
    artifact's reference at the controller's terminal, and the controller registers it with no builder key, recording the act with its why;
@@ -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

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,12 +302,12 @@ 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
   merges while the runner is down, judged on what it already heard (ADR 0666 §11, ADR 0596). A head's fingerprints are
-  those its runs named for its commit; a step that failed at that fingerprint in any run, a group's or another commit's
+  those its runs named for its commit (kept as §475 says); a step that failed at that fingerprint in any run, a group's or another commit's
   of the same content included, refuses it, unless a later run of that same step at that fingerprint, asked again by
   the operator or the healers (the runner's `rerun`), passed: that pass clears the failure from `failed-steps` (ADR 0666
   §11). The runner's `step-ended` says that the step was a rerun and the caller the runtime proved, and the forge module

03-DESIGN/01-to-be/47-milestones/G-10-develop-answers.md

@@ -0,0 +1,275 @@
+---
+layer: to-be
+status: in-progress
+design: 47
+milestone: G
+updated: 2026-11-11
+decisions:
+  - "ADR 0667"
+  - "ADR 0668"
+  - "ADR 0666"
+  - "ADR 0660"
+  - "ADR 0635"
+  - "ADR 0625"
+  - "ADR 0596"
+  - "ADR 0595"
+  - "ADR 0584"
+  - "ADR 0564"
+  - "ADR 0363"
+  - "ADR 0240"
+---
+
+# 47, milestone G: the answers to develop's second batch of 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".
+
+## From develop, the second batch (2026-11-11)
+
+*The operator, 2026-11-11 about 11:15 CET at lead-47's terminal: a design question that changes nothing the operator
+sees, nobody's permissions (who may call, publish or read what) and no data kept or removed (an internal wire form, a
+function's input, a helper's API, a contract field's name or shape, a package's place) is answered as a design line by
+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. §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
+  generator and the manifest validator refuse no verb for naming no `class`, and the validator says the default each
+  verb took, as §391 has it. The verbs whose class this design names (§394, §405, §422, §446, §447) name it in their
+  definitions. This amends §391, its "a verb G adds must name its `class`" and its check's refusing row. Why: the
+  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.** (§489, §490) §345's put session runs on the subject `<bundle call subject>.put.<call id>`.
+  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,
+  or `{error}`, and the bundle sends the next chunk only after a `{seq}`; the tool runner's answer to the last chunk is
+  the call's answer. A chunk whose `Mesh-Put-Seq` is not one more than the last taken is answered `{error}` naming
+  both, and the put is dropped as one not sealed (§345). A get of a value over the limit (§407) runs the same form on
+  `<bundle call subject>.get.<call id>`, the tool runner sending the chunks with the same headers and the bundle
+  answering each. Why: the operator, 2026-11-11 at the terminal (develop question D-13); the out-of-order refusal and
+  the get's mirror are the design's choice, one form both ways. How it is checked: whole (mesh-sdk, tool runner), as
+  §345, and a chunk sent out of order fails the put naming both sequences; unit (tool runner), a chunk over half the
+  maximum payload refused.
+- §458 **How each artifact carries its version.** An image is tagged with the version `MAJOR.MINOR.PATCH` and labelled
+  `org.opencontainers.image.version` with it; a Go program is linked with `-ldflags -X main.meshVersion=<version>`
+  beside the existing `-X main.builtFor`; a Node program reads its version from its package.json `version`, which is
+  the version (§370). A build that carries no version (§371, §373) stamps none: the Go variable stays empty, and the
+  image and the package.json keep what they carry today. This completes §370's "its tag and label" and "reads it as
+  its own version". Why: the operator, 2026-11-11 at the terminal (develop question D-19); a build without a version
+  is §371's and §373's. How it is checked: whole (Go, TypeScript and image build modules), a built image's tag and
+  label, a Go program's `main.meshVersion` and a Node program's own version are the reserved version.
+- §459 **`SeatsToPassOn`'s input.** mesh-sdk's `catalogue.SeatsToPassOn` takes the holdings on record, the
+  assignments (each a node, a module and its placement's watched branch), what the caller heard of each node and
+  module from the node-engine seat's `running` (a fingerprint, `stopped`, or nothing heard since its consumer began),
+  and a reader of entries the caller passes over its own view of the catalog half, which answers an entry by its
+  fingerprint (§443) and a module's entry on a watched branch's newest revision. The function resolves each
+  assignment's entry itself: by the heard fingerprint; with nothing heard, the module's entry on its placement's
+  branch, §199's one fallback, which no caller applies; a `stopped` module claims nothing on that node (§404). Where
+  the reader answers no entry for an assignment, no seat that assignment could claim passes and the holder on record
+  stays, as ADR 0660 §1 has it with no single claimant, and the answer says it, naming the node, the module and the
+  fingerprint. It answers the passes and what it says, as ADR 0660 §3. The function reads no bus. This amends §199
+  and §404. Why: ADR 0660 §3 has one rule both parts apply, and §199 the fallback in that one function; with the
+  entry read through a reader each part passes, the node-engine and the grants part feed it from their own views
+  (ADR 0596 §2), and the function stays a pure rule (develop question D-14). How it is checked: unit
+  (`SeatsToPassOn`), a table with a row per case: a heard fingerprint, nothing heard (the branch's entry taken), a
+  `stopped` holder passing no seat, and an entry not answered keeping the holder on record and saying it.
+- §460 **An asker says whether its key is still open.** mesh-sdk's kept-call form takes, beside the ask's key, a
+  function `open` the asker passes, which reads the asker's own state and answers whether that key is still open, and,
+  where one exists, the event that replaces the ask; it asks again only while `open` answers yes and no replacing
+  event was heard. An error of `open` is written in the asker's journal naming the key, and the form asks again: a
+  kept call is one the callee takes once by a key (ADR 0668 §2), so asking again is safe, and not asking would be
+  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.** (§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
+  the observer's module name and node (§452, §383), so the writer names no seat and no module; and the observer's
+  `observe` function. Its acts:
+  - `write`, a finding: writes the key `<scope>.<id>.<kind>` in `findings`, keeping the key's `since` where it
+    exists (§384), and says `finding-written` only when what the finding says changed (§383).
+  - `clear`, a finding's `scope`, `id` and `kind` and `why`: deletes the key and says `finding-cleared`.
+  - Every event is published awaiting the bus's acknowledgement, sent again for one minute when unacknowledged, then
+    written in the observer's journal as an error naming the finding (§383).
+  - `observe` is a function the observer passes, which answers the findings it observes now and its pending keys
+    (each with its `since` and its bound), or an error. The writer calls it at its start and on each ask, writes each
+    stated finding's key, deletes each key neither stated nor pending, and says `findings-stated` (§384), putting a
+    set larger than one bus message in the observer's sent store (§59, §407). An error of `observe` is written in the
+    journal and no set is said, so the keeper's `findings-unstated` follows (§390).
+  - The asks: the writer makes a consumer of its own on `findings-asked` that delivers only the asks published after
+    it is made, the statement at start answering any before (§390), and answers an ask that names no `module` or
+    names its own.
+  - Between the seat's contract and the writer pass only the subjects: an observer calls the generated
+    `mesh-conditions` contract's subject functions and hands their strings to the writer. mesh-contracts' bucket
+    adapter `meshconditionsclient/findings` goes in G, its callers in mesh-delivery making mesh-sdk's writer instead
+    in the same change; a client package of `mesh-conditions` keeps only what two callers would each write beside the
+    contract (ADR 0625 §4). A client package of any seat, `meshwatchdogsclient` among them, is an artifact of its
+    contracts module, as every package that module publishes is, so `go-meshwatchdogsclient` is one of the health and
+    repair contracts module's artifacts.
+  Why: §383, §384 and §390 decide the events and their order; the writer's form is the design's choice (develop
+  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.** (§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
+  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
+  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`.** (§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
+  proved for the call (never a field of the input), the artifact and `why`. It is defined once, in
+  `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. 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;
+  `steprun` (§420) holds what only the build modules run: the step run and the fetch and release (§327), the
+  regenerate-and-compare step and its out-of-step answer, and the per-node CPU share as `steprun/buildcpu`. The seat
+  generator moves with them, as the package `seatgen` of `mesh-delivery-sdk` with its command `cmd/seatgen`, and the
+  command `mesh-pack` as `cmd/mesh-pack` there. So all of mesh-build-go's `buildstep` Go module leaves mesh-catalog,
+  the TypeScript and image build modules import only the delivery SDK, and the delivery SDK requires nothing of
+  mesh-catalog. This amends §327's "a build-step package" and the main file's "`mesh-pack`, in mesh-sdk". Why: code
+  the build modules share is the delivery SDK's (ADR 0635 §4; §327), a module importing another module's package is a
+  seam no mesh path carries, and mesh-sdk takes only the runtime every module uses (ADR 0625 §9), which a generator is
+  not; `buildstep` stays light for the parts that only read the step's contract (develop questions D-20 and SD1). How
+  it is checked: a search of mesh-catalog finds no `buildstep`, `seatgen`, `buildcpu` or `mesh-pack` under
+  mesh-build-go; the delivery SDK's go.mod requires no mesh-catalog module; §327's search.
+- §465 **A group run's build ask names each package member's build, and the build module reads it from the store.**
+  The ask's `fetch` (the part `build-step`'s Fetch) gains `builds`: a list of `{package, module, artifact, digest}`,
+  one per package member of §373, `package` the name in its ecosystem (the Go module path, the npm name), `module` and
+  `artifact` the member's catalog names and `digest` its build's `sha256:` digest; a package `builds` names is named in
+  neither `packages` nor `package`. The build module reads each from the artifact store through the provision it
+  already requires, `artifact-store`, at the reference it stores at,
+  `artifact-store://<module>/<artifact>/blobs/<digest>`, checks the bytes against the digest and lays them as §373
+  says. No registry seat gains a verb, and no grant changes: the store is read as every machine reads it. This
+  completes §373. Why: the digest is the builder's own fact (§373) and the store is addressed by digest already
+  (develop question BLD12). How it is checked: test 103; unit (`build-step` contract), `builds` read; whole (Go build
+  module), a fetched build whose bytes do not match its digest fails the step naming the member.
+- §466 **A build names what it resolved.** Each built artifact of the build answer (BuiltArtifact, in the step's
+  result) gains `resolved`, a list of `{package, version, digest}`, one per mesh package the build resolved (one
+  that the catalog graph entry's packages name, the edges of kind 1), `digest` the `sha256:` digest of the package's
+  bytes as the build fetched them; ToolchainUsed gains `digest`, the building node's digest of its toolchain program
+  (§472), kind 3's entry, never the build module's own program. The builder carries both, per artifact,
+  in `package-published` as `resolved` and `toolchain`, from which the indexer writes §374's entries of kinds 1 and 3.
+  This completes §374. Why: §374 has the build module name each dependency with its version and digest in its step
+  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.** (§481, §483, §484) The build seats' state `steps` (in `node-build-go`, `node-build-node`
+  and `node-build-image`) keys a step `<asker>.<node>.<id>`: `<asker>` the asker the bus proves (§481: `runner`, `indexer`, `assigner`, `builder`), `<node>` the node that runs it, `<id>` 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 `<node>.<id>` 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. 
+- §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
+  behind. It is called as every module's health tool is, with no caller added. Why: the design's choice (develop
+  question Q-RN1); one prefix per module's tools. How it is checked: §79's check; the runner's manifest names it.
+- §469 **An old `state` section declares its cap.** An old `state` section's entry takes `max-mib`, as its old
+  `objects` section's does, and mesh-sdk's `buscompose` makes the bucket with that many MiB as its maximum size; an
+  entry naming none has no cap, as on main, so no bucket of today changes. The runner's `pipelines` names 256 and its
+  `kept` 128 (§85); a write the bus refuses at the cap is said as the runner's `full` (§181), its read tools answering
+  each fill against the cap (§83). Why: §85's caps are the bus's, so a full store refuses loudly (§181) rather than
+  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.** (§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 `<pipeline>`. A log already takes an age up to 3650 days and refuses no
+  entry it holds, so the design's 100 days stand, and mesh-sdk's bound on a stream's age (30 days) and the indexer's
+  rule that repeats it stay as on main. This amends §85's "old `streams` section" for `step-log`. Why: §330 reads the
+  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.** (§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.** (§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 (§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
+  capacity for nothing (develop question BL8). How it is checked: unit (build-step contract), `digest` read; whole
+  (builder), a change of the agreed version says `toolchain-agreed` with the digests and a differing digest at one
+  version says nothing.
+- §473 **The builder takes a candidate's heads from its revision view.** In place of the gate's `source` history,
+  which it reads today to find the trunk heads a candidate's base revision names, the builder takes each build's
+  commits from the catalog half of the revision view the build is for (§348), by `mesh-catalog`'s `revision`; a G
+  pipeline builds a commit as it is, so the builder asks no merge onto a base and sets no `base` in a fetch. Its watch
+  of the gate's `source` and the `reads` of it in its manifest go in the same change (§431). Why: ADR 0596 §2; one
+  source of a revision's commits (develop questions BL15 and BL9). How it is checked: the builder's account holds no
+  read of the gate's state; whole (builder), a run on request builds the commits its revision view names.
+- §474 **A `*` entry before an event no contract defines keeps its meaning on main.** §386's form, one durable
+  consumer on each declaring module's stream, is taken only for `*.<event>` where `<event>` is defined by a seat's
+  definition or a contract in mesh-sdk; any other `*` entry the validator accepts on main, such as `model-usage`'s
+  `*.usage.*`, keeps its meaning of ADR 0363 §5, the shared stream EVENTS and never a module's own stream, and is
+  accepted as on main; `*.>` and `*` in part of an emitter's name stay refused. G's change does not rewrite
+  `model-usage`'s `consumes`, so it hears what it hears today. This amends §386's "it refuses `*` before any other
+  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`.** (§487) The state `failed-steps` of §39 gains
+  a second key form, `seen.<commit>.<module>`, 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
+  later `step-ended` names at its module and fingerprint. `merge-pull` reads a head's fingerprint from its `seen`
+  key, so a head whose runs all ended before another commit of the same content failed is refused, as §39 says. This
+  completes §39 and §135. Why: §39 decides the refusal and that it is judged from the module's own state, and
+  `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.** (§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.** (§495) The bus module plans each `<module>_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.** (§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
+  name, version and digest its publish carries, so it reads no catalog and its publish gains no field; a name no entry
+  carries is answered `error`, naming it, and the holder refuses the publish (§381). Its callers stay §381's. This
+  completes §381. Why: the builder already reads each package's name from the catalog half (§348), so the mapping is
+  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.** (§495) In mesh-sdk's `go/views` reader and process reader, a
+  first view of a per-branch state is named `<owner>.<state>.<branch>`, the branch escaped as a key's name is (§73),
+  so `mesh-catalog.catalog-revisions.<branch>` names one view per watched branch, a part reads several in one reader,
+  and `<module>_first_views` lists one row per branch (§358, §365). A view of a state that is not per branch keeps
+  its name `<owner>.<state>`. Why: the condition keeper reads every watched branch's newest revision (§365), and the
+  state's keys are `<branch>.<revision>` already (§343) (develop question CT10). How it is checked: unit (`go/views`),
+  two branches' views of one state in one reader, each its own row; whole (keeper), a module watched only on a
+  second branch is a source.

03-DESIGN/01-to-be/47-milestones/G-11-develop-answers-review.md

@@ -0,0 +1,316 @@
+---
+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.** (§600) The `<asker>` of a step key `<asker>.<node>.<id>` (§467)
+  is the account the bus proves sent the ask, never a field of the ask. An ask is published on
+  `mesh.seat.<seat>.accept.<queue>.<asker>` (§600), 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, `<asker>.<node>.<id>` (and main's `<node>.<id>`, §483). The stream's subjects are §600's. 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.** (§600, §601) A build seat's holder of G keys a step whose ask
+  came on main's subject `mesh.seat.<seat>.accept.<kind>`, with no asker's name, as main does, `<node>.<id>`, 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 `<node>.<id>` 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 `invokes` of the queue (§601); an ask under a name that reaches a holder of before G waits on the work queue, until the grants part's worker filters both forms (§600, §601), 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
+  `<node>.<id>`; 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, `<asker>.<node>.<id>` and main's `<node>.<id>` (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.** (§609) 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.** (§606) 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.<commit>.<module>` 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.** (§605) 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. On each node a module is delivered after G's tool runner by §605's edge.
+  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 `<bundle call subject>.put.<call id>` only the module's own
+  account publishes the chunks and only the tool runner of its node answers them; on `<bundle call subject>.get.<call
+  id>` 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
+  `<bundle call subject>.get.<call id>` before it makes the call; the tool runner's answer to the call is
+  `{chunked: <count>, 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.** (§604) Each build seat says `toolchain-reported` on
+  `mesh.seat.<seat>.event.toolchain-reported.<node>` (`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 `<owner>.<state>.<branch>`. 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.** (§601 to §603) The holder of a build seat says `step-progress` on
+  `mesh.seat.<seat>.event.step-progress.<node>` (`asker`, `ask`, `phase`: `fetch`, `build`, `run` or `report`, and
+  `at`) once a minute while it runs an ask, declared as §603 says; 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.** (§608) `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.** (§609) 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.<node>.<node-engine's module>` 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.** (§609) It answers, per module and node, each first view the part
+  names: the view (`<owner>.<state>`, 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 `<module>_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, `<module>:<artifact>`, 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.** (§609) 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.<branch>` 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.** (§609) 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.** (§608) 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.** (§607) The bus module plans each
+  `<state>-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.

03-DESIGN/01-to-be/47-milestones/G-13-review-round-3.md

@@ -0,0 +1,124 @@
+---
+layer: to-be
+status: in-progress
+design: 47
+milestone: G
+updated: 2026-11-11
+decisions:
+  - "ADR 0667"
+  - "ADR 0666"
+  - "ADR 0656"
+  - "ADR 0603"
+  - "ADR 0596"
+  - "ADR 0595"
+  - "ADR 0584"
+  - "ADR 0564"
+  - "ADR 0536"
+  - "ADR 0525"
+  - "ADR 0436"
+  - "ADR 0363"
+---
+
+# 47, milestone G: the review of §480 to §515, rounds 2 and 3
+
+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"; this file
+takes §600 on, since §516 on are those of batch 4's file G-12.
+
+*These lines answer what the four reviewers by architectural domain found in round 2 of
+[G-11](G-11-develop-answers-review.md) (§480 to §515), the last round. Each is the design's choice with its reason.*
+
+- §600 **A build seat's asks: subjects, workers and grants.** A build seat (`node-build-go`, `node-build-node`,
+  `node-build-image`) keeps its three queues of main, `delivery`, `check` and `recheck` (ADR 0525 §4, ADR 0536 §4), on
+  its one work-queue stream. An ask is published on `mesh.seat.<seat>.accept.<queue>.<asker>`, `<queue>` one of the
+  three, `<asker>` the asker's name; the ask's kind (`step`, `run`, a build) stays in its body, as on main. The
+  stream takes, per queue, main's `mesh.seat.<seat>.accept.<queue>` and `mesh.seat.<seat>.accept.<queue>.*`, which
+  overlap no other queue's. Its workers stay the grants part's, one per queue (`SEAT_<SEAT>_<QUEUE>_worker`, as on
+  main), each filtered to both of its queue's subjects, so one consumer per queue takes an ask in either form and
+  every node's holder pulls it, as ADR 0436 §6 has one consumer. The grants part grants publish on
+  `accept.<queue>.<asker>` to that asker's account alone, each asker by the queues §338 gives it, and on main's
+  `accept.<queue>` to the checker's and the builder's accounts alone, until §483's removal. This amends §481's
+  subject and its "the seat's stream takes `accept.>`". Why: one stream refuses overlapping subjects and a work
+  queue has one consumer per filter (review round 2, security and upgrade 1 and 3, running and testing 1). How it is
+  checked: unit (grants part), each queue's worker filters both subjects and each asker's grant is its own name;
+  whole (grants part, Go build module), an ask under `runner` is taken and answered, and the runner's account
+  publishing on main's `accept.check` is refused.
+- §601 **The order of G's rollout for the build seats.** The holders of the three build seats are delivered first,
+  then the grants part, whose workers then filter both forms (§600), then every asker of G (the runner, the indexer,
+  the assigner, the builder) and the watchman. Until every node's holder of a build seat is of G the grants part's
+  worker keeps main's one filter, so a holder of before G never takes a named ask, whose key it would write in main's
+  form. Each order is a served-verb edge (kind 6) the delivery plan derives: an asker names each queue it publishes
+  to in its manifest's `invokes` as `<seat>.accept.<queue>`, which the manifest validator checks against the seat's
+  definition, and the edge runs from that seat's holders to the grants part and from the grants part to the asker;
+  the watchman's `consumes` of the build seats' `step-progress` (§496) gives the edge from those holders to it, as an
+  event G adds. A holder is counted delivered once `version-delivered` (§376) says every present machine placing it
+  runs it. A revert runs the same edges backward (ADR 0656 §4). Until the watchman hears a holder's `step-progress`,
+  it times that holder's ask from its `ask-taken` (§602), and a body of before G with no `step` or `clock-from`
+  (§498) is timed from its own `at` with no step's own finding. This amends §483's "whose consumer of before G takes
+  only main's subject" and its edge's source. Why: one consumer is shared by every node's holder, so the filter moves
+  only once every holder reads both forms (review round 2, security and upgrade 2 and 4, seams and tools 2, health
+  and events 2). How it is checked: unit (delivery plan), the edges from `invokes` and `consumes` are derived and G's
+  plan names them; whole (grants part, Go build module, runner), a rollout with one holder of before G keeps main's
+  filter, and the runner's ask is answered once every holder is of G.
+- §602 **An ask outside a pipeline has a start and an end.** A build seat's holder says `ask-taken` (`asker`, `ask`,
+  `node`, `at`) on `mesh.seat.<seat>.event.ask-taken.<node>` when it takes any ask, and `step-ended` when it ends any
+  ask, whatever its asker (§24's event, the asker in its body); a reader of `step-ended` takes only its own asks by
+  their ids. The watchman times every ask from `ask-taken` and its `step-progress` (§496), and ends the clock on
+  `step-ended`. A runner's step that stands raises `pipeline-stands` (§75); any other ask that stands raises
+  `stuck`, naming the seat, the asker, the ask and the node, as main's mirror does. This completes §496. Why: only the
+  runner says `step-started` (review round 2, health and events 1). How it is checked: whole (watchman, Go build
+  module), a builder's build whose holder stops raises `stuck` within five minutes and one that ends raises nothing.
+- §603 **Where `step-progress` and `ask-taken` go.** Both are seat events and go on the stream that carries the seat's
+  events, at that stream's own age; no stream is added and no event's age changes. `step-progress` and `ask-taken`
+  are declared in the three build seats' definitions in `mesh-delivery-contracts`, and `step-progress` in
+  `mesh-wants`' definition for a composition step. This amends §496's "kept on the seat's stream for a day". Why:
+  a build seat's own stream is its asks' work queue (review round 2, running and testing 4, seams and tools' note).
+  How it is checked: unit (definitions), each event declared.
+- §604 **The builder keeps the toolchains it heard.** The builder writes each `toolchain-reported` (§492) in a state of
+  its own, `toolchains-heard`, one key `<node>.<language>` holding the version, the recipe, the digest and when it
+  was said, and agrees the version from those keys, read back at its start, so a restart needs no node to report
+  again. Its manifest `consumes` the three build seats' `toolchain-reported`; its tool `builder_toolchains` lists the
+  keys; a key is deleted when the node leaves the catalog's placements (§365's reason). Why: a durable consumer does
+  not deliver an acknowledged event again (review round 2, seams and tools 1). How it is checked: whole (builder), a
+  restarted builder agrees the same version with no new report.
+- §605 **The order after G's tool runner is derived from the package a build resolved.** A package's artifact in a
+  manifest takes `calls`, the capability words (§488) its code calls of the tool runner; mesh-sdk's Go and npm
+  packages name `ledger-upkeep-calls`, `sent-objects-calls` and `put-sessions` from G. For each module whose build
+  resolved a version of such a package (§466's `resolved`), the delivery plan derives a served-word edge (kind 6) to
+  the tool runner stating those words on each node, so no manifest names the tool runner's module. mesh-sdk's
+  bundle reads the stated words again each time the tool runner of its node starts. §494's release reads `calls`.
+  This amends §488's `needs`. Why: the bundle makes a session whenever a value is large, so only the package knows
+  (review round 2, seams and tools 3, running and testing's note). How it is checked: unit (delivery plan), a module
+  built on G's mesh-sdk is ordered after the tool runner on each node; unit (manifest validator), `calls` read.
+- §606 **A step's end and its unlogged entry are one write.** The runner writes a step's end in `pipelines` with the
+  entry as `unlogged` in the same compare-and-set, appends it to `step-log`, then clears it; at its start it appends
+  every `unlogged` entry of its pipelines, in order. It reads the log's fill again at each step's end, at its start,
+  and once a minute while the log is `full`, so the entries the bus ages out say `room` with no step ending. Its tool
+  `runner_unlogged` lists the unlogged entries and `runner_unlogged_append` appends them by hand, written in the
+  hand-act log. This amends §486. Why: a stop between the two writes lost the entry, and only the bus's age frees a
+  full log (review round 2, running and testing 2, health and events 3, seams and tools' note). How it is checked:
+  whole (runner), a runner stopped after a step's end appends its entry at start; a full log whose oldest entries age
+  out says `room` with no step ending.
+- §607 **A state's objects store has the state's size.** Each `<state>-objects` (§58) is planned with the state
+  template's size, 64 MiB, unless the state's `requires` names `objects-max-mib`; the sent stores keep §477's 256
+  MiB. An estimated 150 states across about 120 modules give about 9.4 GiB of caps. Whether the bus counts a cap
+  against its storage limit before anything is written is measured in G's check (the bus module's whole test reads
+  the account's reserved storage after its plan); if it does, the plan refuses caps whose sum passes the limit,
+  naming the sum, as §495 has it for sent stores. A write refused at a cap names that store, `<state>-objects` of
+  its owner. This amends §513 and leaves §58's "reserves nothing" to that measurement. Why: §58 names the template's
+  size (review round 2, running and testing 3). How it is checked: unit (bus module's plan), each objects store's cap;
+  whole (bus module), the reserved storage read after the plan.
+- §608 **A carried merge that waits is a timed wait.** A merge act carried by the switch (§510) waiting for the first
+  registrations is said by the gate as `wait-held` with `step: merge` (added to §498's list), naming the pull request
+  and the head the Approve named, bounded at 60 minutes; past it the watchman writes `merge-waits`, which the
+  condition keeper raises and `wait-ended` clears. It merges only the head the Approve named: a pull request moved
+  since is refused, said as the delivery's `transition` with the why `head moved`. This amends §510. Why: an Approve
+  the operator gave must not wait unseen (review round 2, health and events 4, security and upgrade's note). How it is
+  checked: whole (gate, watchman), a carried merge waiting 60 minutes raises `merge-waits`; a moved head is refused.
+- §609 **Smaller corrections from round 2.** An entry taken in before G carries as `manifest-digest` the digest its
+  module value held (§506). §508's check adds a revision moving the `node-engine` claim to another module, accepted
+  and said in the catalog's `catalog-revision`. `watchman_views` (§501) answers from the keeper's `view-waits` alone,
+  so a ready view is not listed and the watchman calls no part's tool. §485's reconnect case is a whole test of
+  mesh-sdk, and `observe` must not call `write`, since the writer runs one act at a time. A node-engine of before G says
+  no wait for a kept build; that is accepted, `kept-build-waits` naming its version (§499). The kept-data row of
+  `step-log` reads an old `logs` section (§470). How it is checked: as the lines it corrects.

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, `<state>-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
@@ -50,7 +50,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
 - §59 **An object sent is readable by the modules it is for.** A reply's or an event's object is written to the sender's
   **sent store**, `<module>_sent-objects`: the bus module plans it, with no manifest field, for every module of the new
   form that serves a verb or emits an event, and a foundation part declares it as an old `objects` section
-  `sent-objects` (ADR 0619 §2). Its cap is the objects template's (ADR 0595 §3), and it keeps an object 7 days, after
+  `sent-objects` (ADR 0619 §2). Its cap is the objects template's (ADR 0595 §3), 256 MiB (§477), and it keeps an object 7 days, after
   which the bus expires it. That age is transport, not kept data: an object sent exists only to carry one reply or one
   event, read within its call's bound or its consumer's lag, so its expiry is not a removal of kept data that ADR 0595
   §4 holds to a person's word (the design's choice; 7 days is a guess at the longest a consumer lags, read from the
@@ -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,13 +155,14 @@ 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
   its members, and a merge behind a pending revision, are governed by their own bounds (ADR 0666 §24). At its start the
   watchman seeds its open waits from the runner's `stands`, as it seeds `take-in-waits` from `indexer_pending`.
-- §76 **The runner's own health.** Its manifest declares its health check, run outside its process (ADR 0240): the runner
+- §76 **The runner's own health.** Its manifest declares its health check, run outside its process (ADR 0240; its tool
+  `runner_health`, §468): the runner
   answers `show`, and its durable consumers of `step-ended`, `take-in.taken`, `package-published`, `toolchain-agreed`
   and `decided` are
   each less than five minutes behind; a failed check names which.
@@ -213,7 +214,7 @@ each tool answers its whole-module test's case, every store's read answers its f
 ### The runner's kept data, and the build capacity
 
 §85 Each kept form names its section or template, its retention and its cap; a state template fixes its own size (ADR 0595
-§3), up to 64 MiB. The numbers are estimates, to be read from the fill tools once G runs: an estimated 20 merges a day
+§3), up to 64 MiB, and an old `state` section names its cap in `max-mib` (§469); the step log is an old `logs` section (§470). The numbers are estimates, to be read from the fill tools once G runs: an estimated 20 merges a day
 (as *The delivery record*), each starting a pipeline for about 3 modules of its repository whose fingerprint it changes,
 and an estimated 2 mesh-sdk publishes a day, each rebuilding about 120 artifacts and starting about 120 pipelines: about
 300 pipelines a day, of about 6 steps each.
@@ -221,7 +222,7 @@ and an estimated 2 mesh-sdk publishes a day, each rebuilding about 120 artifacts
 | Part | Kept data | Section or template | Retention | Cap and growth |
 |---|---|---|---|---|
 | the runner | `pipelines`: one key per pipeline, keyed by watched branch, source revision and module, its steps, statuses, outcomes, fingerprints, test counts and end count | old `state` section | a pipeline that ended passed on a watched branch, 90 days after its end; any other (failed, superseded, cancelled, a run on request's), 7 days after its end; always while it is its branch's newest for its module; deleted by the runner (§330) | 256 MiB; about 300 pipelines a day of about 4 KiB is at most about 105 MiB at 90 days, under half the cap |
-| the runner | `step-log`: one entry per step's start and end, its output, its pipeline and the `kept` digests it wrote or carried, by name | old `streams` section | by its age, 100 days, ten days past the longest retention it ages (§330) | 128 MiB; about 3,600 entries a day of about 0.2 KiB is about 70 MiB at 100 days |
+| the runner | `step-log`: one entry per step's start and end, its output, its pipeline and the `kept` digests it wrote or carried, by name | old `logs` section (§470) | by its age, 100 days, ten days past the longest retention it ages (§330) | 128 MiB; about 3,600 entries a day of about 0.2 KiB is about 70 MiB at 100 days |
 | the runner | `step-outputs`: a lint or test step's output | old `objects` section | 7 days | 1 GiB; about 1,200 steps run a day (the rest carried) of about 50 KiB is about 420 MiB at 7 days |
 | the runner | `kept`: a package's passing result per level, by digest, with `last-read`, written by each carry that reads it | old `state` section | 30 days after `last-read` | 128 MiB; a publish changes the digest of about 1,000 importing packages at two levels, so about 4,000 entries a day of about 0.3 KiB, about 36 MiB at 30 days |
 | the indexer | `versions`: one key per module and version, its artifacts' digests, the source revision and its edge entries (§349, §374) | old `state` section | a module's newest 100 versions, never its highest of a `MAJOR.MINOR`; the indexer deletes the older at each release | 64 MiB; about 120 modules of 100 versions at about 3 KiB is about 35 MiB; at the cap it records no release and says `full`, as *A store filling is said before it is full* |
@@ -239,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 | `<state>-objects` beside each state | objects | an object no key names, its key deleted or its value replaced, until `<module>_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 | `<module>_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_<seat>_<event>`, among them `SEAT_mesh-pipeline-runner_*`, `SEAT_<build 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`) |
@@ -289,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

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`,

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
@@ -117,7 +117,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
   manifest of it"), read by digest from the catalog half; the builder's done key is not needed, since the event names
   the digest it would give. A node that has said no `running` for a module since the part's consumer began counts by
   the catalog graph's entry of the module on its placement's branch, as ADR 0660 §2 has it where the running build cannot be read, and both parts apply that same
-  fallback in the one function (ADR 0660 §3). Never another node's have key, its want or the assignment half (ADR 0596
+  fallback in the one function (ADR 0660 §3), whose input is §459's. Never another node's have key, its want or the assignment half (ADR 0596
   §2; *Each part acts on its own entries*). The design's choice under ADR 0660 §2: the node that runs a build says what
   it runs, and an event kept by a durable consumer answers when that node is away. How it is checked: test 56.
 - §200 **A part with no view says it waits.** It names the revision it has no view for, acts on nothing new, and keeps
@@ -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
@@ -181,7 +181,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
   build module's step key named by the ask's id (ADR 0525 §6). It is an accepted ask of the seat, not a request verb, because it is a
   long job pulled where there is capacity, never a call to a named node. Only the checker's account may publish `run`,
   and from G's delivery the runner's and the indexer's (its validation before take-in), each under its own name.
-  Every step key of a `run` ask starts with the asker's name (`checker.<ask id>`), so the checker's read grant is fixed
+  Every step key of a `run` ask starts with the asker's name (`checker.<ask id>`; its whole form is §467's), so the checker's read grant is fixed
   in advance to its own prefix and never follows ask ids one by one (ADR 0363 §2); no other part can have a program run
   or read its verdict. From milestone G the seat definition of `node-build-go` in `mesh-delivery-contracts` names it; B0
   brings the ask with its types in mesh-sdk's `go/delivery` and the grants check asks have today (*The bootstrap

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

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

03-DESIGN/01-to-be/47-milestones/G-7-answers.md

@@ -64,7 +64,7 @@ record it follows from, and replaces the builder's own choice where one was made
 - §326 **A build seat keeps its `steps` answer.** The build module keeps each artifact's detected steps in its state
   `detected-steps` (§414), from the template `state`, one key per artifact holding the answer for that artifact's newest build-input
   fingerprint, replaced when a newer fingerprint is detected and by `steps` with `again`; a key whose artifact no
-  longer exists is dropped by `steps` with `drop`, on a person's word, written in the hand-act log. With one key per
+  longer exists is dropped by `steps` with `drop`, on a person's word, written in the hand-act log (its input §463's). With one key per
   artifact (about 120) the state needs no aging and no read time. Why: ADR 0666 §25 asks a tool for "the steps
   detected for an artifact and detect again", which a reply computed anew each time would not need; a build module is
   no foundation part, so the template form (ADR 0666 §4). How it is checked: whole (Go build module), `steps` answers
@@ -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
@@ -208,15 +208,15 @@ record it follows from, and replaces the builder's own choice where one was made
 - §345 **A large value reaches the tool runner in chunks.** A bundle's put of a value over the bus's per-message limit is
   sent to the tool runner as a put session on the bundle's call subject, named by the call's id, in chunks under that
   limit, in order, each answered by the tool runner before the next is sent, and written as one object through the
-  object store's own chunking; a put not sealed within the call's bound is dropped by the tool runner and its call
+  object store's own chunking, its wire form §457's; a put not sealed within the call's bound is dropped by the tool runner and its call
   fails, naming the object. No value is split over objects. Only modules that import the object store package are
   rebuilt for it. Why: one object per value (ADR 0666 §16), through the tool runner (ADR 0595 §9). How it is checked:
   whole (mesh-sdk), a value of a hundred times the limit is read back whole, and a put stopped half way fails naming
   the object and leaves none.
 - §346 **One object store package.** The assigner's and the indexer's object store code is mesh-sdk's small object store
   package, with no copy in either. Why: ADR 0595 §9. How it is checked: a search finds no second copy.
-- §347 **Reading sent objects is a bus state call.** mesh-sdk lists the call that reads a sent object under its existing
-  bus state capability. Why: ADR 0595 §9 puts the calls in that package. How it is checked: the package's table test.
+- §347 **Reading sent objects is a bus state call.** mesh-sdk's `buscalls` names the call that reads a sent object, and
+  the tool runner lists it under its existing bus state capability (§462, which amends this line). Why: ADR 0595 §9 puts the calls in that package. How it is checked: the package's table test.
 - §348 **The builder reads the catalog through its seat.** The builder reads the registrations' watched branches through
   `mesh-catalog`'s `registrations` and `registration-changed`, the released versions it numbers from through
   `versions` and `version-released`, keeping no list of versions of its own, and a build seat's holder from the seat list; the
@@ -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`.
@@ -280,7 +280,7 @@ record it follows from, and replaces the builder's own choice where one was made
   resolves to, wherever that requirement carries values the consumer contributes. How it is checked: unit
   (assignment graph), each step of the order and a hold.
 - §358 **The catalog's shared view takes a branch.** The client's view of the catalog half is per watched branch, named by
-  its caller. How it is checked: unit (client), two branches give two views.
+  its caller (§479). How it is checked: unit (client), two branches give two views.
 - §359 **`difference` names its revisions.** `difference` with none of `from`, `to` and `group` is refused, naming the
   missing argument. How it is checked: a unit row.
 - §360 **An approved ask binds the placement.** What an approved ask binds to includes the placement's watched branch and
@@ -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*
@@ -363,7 +363,8 @@ record it follows from, and replaces the builder's own choice where one was made
   builder started before the fill reserves nothing until `versions-filled`.
 - §370 **The version reaches every artifact's build.** The build seat's ask carries the version, and the build module
   passes it to the artifact's build as the build argument `MESH_VERSION`: a Go package is tagged `vMAJOR.MINOR.PATCH`,
-  an npm package's version is it, an image carries it as its tag and label, and a program reads it as its own version.
+  an npm package's version is it, an image carries it as its tag and label, and a program reads it as its own version,
+  each in §458's form.
   A Go package's version is its tag: this departs from ADR 0573 §2, which has a Go package's version be its trunk
   commit, by the operator's choice of 2026-11-10, and a later research brings that record in line. The git tag
   (`go/vMAJOR.MINOR.PATCH`, design 51) is written by the builder only on the catalog's `version-released`, through the
@@ -375,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`
@@ -395,7 +396,7 @@ record it follows from, and replaces the builder's own choice where one was made
 - §373 **A group's run on request publishes no version.** A run on request of a group builds each member that
   depends on a package member against that member's build by its digest. The builder's build ask for such a member
   carries each package member's build digest, which the builder takes from its own `build.ended` of that member's
-  build, its own fact (ADR 0596 §2); the build module fetches that build from the store by the digest, checks the
+  build, its own fact (ADR 0596 §2), in the field of §465; the build module fetches that build from the store by the digest, checks the
   fetched bytes against it, and lays it in the build's workspace as the module that package names (a Go workspace's
   replacement, a TypeScript local package), so nothing is fetched by a version, and no version is reserved, numbered
   or published for the run. A dependent whose package member's build is not done waits, said as the builder's
@@ -412,7 +413,8 @@ record it follows from, and replaces the builder's own choice where one was made
   makes the dependent stale or only orders it (§378), the manifest word it came from, the part it points to, and what
   the edge depended on:
   - kind 1 (an imported package) and kind 3 (the build toolchain): the dependency's version and the digest of the part,
-    as the build used them. The build module names each dependency it resolved, version and digest, in its step key,
+    as the build used them. The build module names each dependency it resolved, version and digest, in its step key
+    (§466's fields),
     and the builder carries them in each artifact's `package-published`, so the indexer reads no other part's state
     (ADR 0596). Kind 3 points at the toolchain part the agreed toolchain names (ADR 0584 §1), never at the build
     module's own program.
@@ -436,7 +438,7 @@ record it follows from, and replaces the builder's own choice where one was made
 - §375 **One query finds every edge behind, by the part's digest.** The seat `mesh-catalog`'s verb `outdated`, with
   the indexer's tool `indexer_outdated`, answers every entry that is behind: for kind 1, the recorded digest differs
   from the part's digest in the dependency's newest released version (for a build of another branch, its newest build
-  on that branch); for kind 3, it differs from the toolchain part of the builder's newest `toolchain-agreed`; for kinds
+  on that branch); for kind 3, it differs from the toolchain part of the builder's newest `toolchain-agreed` (its version, §472); for kinds
   2 and 4, it differs from the dependency's newest `version-delivered`; for kind 5, the newest version of the acting
   part has not acted for the dependent's current build; for kind 6, the delivered version no longer serves the verb or
   word. A dependency's newer version that left the part's digest as it was makes nothing behind, so nothing is done
@@ -449,10 +451,9 @@ 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 digest; for each, the runner asks `outdated` for that dependency and starts a
+  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
   again. A dependent's new version that a change orders after its dependency's new version by kind 2, 4 or 6 is wanted
   only once that dependency's version is delivered to every machine that places it and is present. The assigner judges
@@ -502,7 +503,7 @@ record it follows from, and replaces the builder's own choice where one was made
   and 6), and whether it is behind now (§375). Its callers are any person, an agent session and the healers. Why: the operator, 2026-11-10 about 22:30 to 23:00 CET. How it is checked: whole (indexer), a fixture module's
   edges are answered from both ends with their newest release's record.
 - §381 **A registry holder checks a publish against the reservation.** From G's delivery the holder of a registry
-  seat asks the seat `mesh-builds`' verb `reserved` (§369), in place of `builder_versions`, whether the module, the
+  seat asks the seat `mesh-builds`' verb `reserved` (§369, by name, §478), in place of `builder_versions`, whether the module, the
   version and the artifact's digest are reserved, and refuses loudly otherwise (ADR 0605 §4); a version the catalog
   already holds released for that digest is answered as held and stores nothing. Why: ADR 0605 §4 has the holder
   refuse a version the builder did not give, and the builder's list goes (§372); the design's choice, round 2 of the review by architectural domain, 2026-11-10.

03-DESIGN/01-to-be/47-milestones/G-8-findings-heard-as-events.md

@@ -101,7 +101,7 @@ record says so in its Why. Round 3 of the review by architectural domain (2026-1
   `*.<event>` takes the event `<event>` from every module whose manifest declares it, and is the one generic form for
   hearing an event that many modules say; the keeper's `*.finding-written`, `*.finding-cleared` and
   `*.findings-stated` are the first. The manifest validator takes `*` only as the whole emitter, and only before an
-  event that a seat's definition or a contract in mesh-sdk defines, with its fields (for the finding events, the seat `mesh-conditions`' definition, §439); it refuses `*` before any other event, `*.>`, and `*` in part of an emitter's name. The grants part,
+  event that a seat's definition or a contract in mesh-sdk defines, with its fields (for the finding events, the seat `mesh-conditions`' definition, §439); it refuses `*.>` and `*` in part of an emitter's name, and a `*` entry before any other event keeps its meaning on main (§474). The grants part,
   from the catalog graph as it derives every grant (§59, §442), makes on each declaring module's stream one durable consumer
   for the consumer, named `<machine>_<module>` as ADR 0363 §5 names one, with its grants to read and acknowledge it and
   its membership's word to bind it; it drops that consumer when the module no longer declares the event, and makes one
@@ -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

03-DESIGN/01-to-be/47-milestones/G-9-prepare-answers.md

@@ -43,12 +43,12 @@ line says so.*
   `invokers`, `persons` and `sessions`; an `act` (a new act that changes what the mesh does: registers, sets a policy,
   watches or unwatches a branch, recovers, restores) takes `operator` and `sessions`; a `warrant` (a verb that runs on
   the operator's warrant) takes `operator` and carries the approval mark; `accept` is the operator's alone (§394). A
-  verb on main that names no class is a `read`, so every verb open today stays open; a verb G adds must name its
-  `class`, and the definition reader refuses one that does not. A verb that names `callers` keeps them, so no verb is
+  verb that names no class, on main or added by G, is a `read`, so every verb open today stays open, and nothing
+  refuses a verb for naming no class (§456). A verb that names `callers` keeps them, so no verb is
   closed by §68 for lack of a list; §68, §127 and §306 point here. Why: ADR 0666 §20 makes the definition the one source
   of caller limits; the operator asked on 2026-11-11 why caller questions kept coming, and answered them as one rule
   (Q1, S3, C3, D2's reads, Q18). How it is checked: unit (seat-definition reader), a table test with one row per class,
-  a row for a verb with `callers` of its own, and a row refusing a verb G adds without `class`; unit (manifest
+  a row for a verb with `callers` of its own, and a row where a verb G adds without `class` takes `read`'s (§456); unit (manifest
   validator), the default each verb took is said.
 - §392 **A caller entry names its kind of name.** In `callers`, a holder role is written `seat:<seat>` and a module
   `module:<module>`, beside `operator`, `healers`, `persons`, `sessions`, `invokers` and `holder:<seat>@same-node`
@@ -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 `<state>-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
@@ -111,7 +111,7 @@ line says so.*
 - §404 **The node-engine's events' bodies.** `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
   `stopped: true` and no fingerprint (§365), and mesh-sdk's `SeatsToPassOn` counts such a module as not running on that
-  node. Why: the design's choice (Q17). How it is checked: the seat's fixtures; unit (`SeatsToPassOn`), a row where a
+  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.
 
 ### Kept data on the bus, restore points and the reader release
@@ -144,10 +144,10 @@ 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
-  `ledger` calls (§155, §159, §181); no capability word `ledger-fill` is added. Why: the design's choice (S15, Q-T6).
+- §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.** The reader release of §340 reads every new definition
+- §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
   form and manifest word G writes: `callers`, `class`, `keep`, `subject`, `acts`, the step `pipeline`, `on`
   `kind:image`, `version`, the `*` emitter, an observer's finding stream, and an artifact's `needs`; `check` stays
   beside `pipeline` until the checker is removed (§97, §203). Why: readers first (ADR 0667 §4; S2, S18). How it is
@@ -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.
@@ -202,7 +202,7 @@ line says so.*
   check, made by the running checker (§340), counts by the same rule. Why: the test budget per module (S16, D6). How it
   is checked: `pipeline-ended`'s counts; unit (runner), a module over budget is named `over-budget`.
 - §420 **A run on request's key, and the step-run package.** A run on request is keyed by the run's id under its named
-  branch (§54, §64, §85); the step-run code is the delivery SDK's package `sdk/steprun`, and the runner's
+  branch (§54, §64, §85); the step-run code is the delivery SDK's package `sdk/steprun` (§464 says what it holds), and the runner's
   client sits beside the other seats' clients; the runner's kept data layouts are the seat's `states` (§27, §306). Why:
   the design's choice (D16, D8, D10). How it is checked: whole (runner), two runs of one commit are two pipelines.
 
@@ -227,7 +227,8 @@ line says so.*
   `<module>_first_views` (§205); each tools bundle's composed environment carries its module's fingerprint. Why: the
   design's choice (S12, Q-T7). How it is checked: whole (tool runner), a bundle reads its fingerprint.
 - §425 **A kept call asks again what its asker names.** An asker passes the kept-call form the ask's key and the event
-  that replaces it, and the form asks again only while that key is open and no replacing event was heard (§351). Why:
+  that replaces it, and the form asks again only while that key is open and no replacing event was heard (§351);
+  §460 has the asker pass `open`, the replacing event being optional. Why:
   the design's choice (S11). How it is checked: unit (kept-call form).
 - §426 **The tool runner keeps no waits list.** §74's session waits use `mesh_wait` on any event (ADR 0670), and
   `gitea.forge.status` goes (§133). Why: ADR 0670 (Q-T2). How it is checked: the tool runner's manifest has no waits.
@@ -256,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`
@@ -332,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

03-DESIGN/01-to-be/47-milestones/G.md

@@ -76,7 +76,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 nine files, each read whole, its design lines numbered across them:
+The part is ten 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.
@@ -86,4 +86,7 @@ The part is nine files, each read whole, its design lines numbered across them:
 - [G-6-verbs-and-retires](G-6-verbs-and-retires.md): the verbs G adds and what retires.
 - [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 (§391 on).
+- [G-9-prepare-answers](G-9-prepare-answers.md): the answers to the questions of G's final prepare and develop's first questions (§391 to §455).
+- [G-10-develop-answers](G-10-develop-answers.md): the answers to develop's second batch of questions, the operator's and those of internal form only (§456 to §479).
+- [G-11-develop-answers-review](G-11-develop-answers-review.md): the operator's answers of 2026-11-11 noon, the review of §456 to §479, and develop's next questions (§480 to §515).
+- [G-13-review-round-3](G-13-review-round-3.md): the review of §480 to §515, rounds 2 and 3 (§600 on).