Answer the last review round of milestone G's third batch, in G-13 from §600

The four reviewers' round-2 findings are answered as design lines: the build seats' accept subjects, workers and
grants and the rollout's order as one seam, an ask's start and end outside a pipeline, the builder's heard
toolchains, the tool runner's order from the package a build resolved, the step log's single write, the objects
stores' caps and a carried merge's wait.

Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ

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

@@ -41,13 +41,12 @@ reason. What a question of another kind leaves open waits for the operator and i
   operator, 2026-11-11 at the terminal: §326 has a drop happen on a person's word. How it is checked: whole (Go
   build module), a drop by a session is in the hand-act log with its caller and deletes the key; a drop by any other
   account is refused by the bus; with the hand-act log refusing, nothing is deleted.
-- §481 **A step key's asker is the account the bus proves.** The `<asker>` of a step key `<asker>.<node>.<id>` (§467)
+- §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.<kind>.<asker>`, the asker's name the last token, and the grants part grants each asker of
+  `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 seat's stream takes
-  `mesh.seat.<seat>.accept.>`. This amends §467 and §206. Why: the operator, 2026-11-11 at the terminal; the name in
+  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.
@@ -63,14 +62,12 @@ reason. What a question of another kind leaves open waits for the operator and i
 
 ## The review of §456 to §479, round 1
 
-- §483 **Main's step keys stay readable while main's askers run.** A build seat's holder of G keys a step whose ask
+- §483 **Main's step keys stay readable while main's askers run.** (§600, §601) 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 manifest naming the accepted kind (`step`, `run`) as it derives one from
-  `invokes`; an ask under a name that reaches a holder of before G waits on the work queue, whose consumer of before
-  G takes only main's subject, and is said by `build-capacity-waits` after 60 minutes. The checker asks on main's
+  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
@@ -88,7 +85,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   never passed over in silence. Why: one key form, read once (review round 1, health and events 1). How it is
   checked: unit (`buildstep`), both forms parsed and a third refused; whole (runner, Go build module, watchman), a
   step under `runner.` whose worker stops raises `pipeline-stands` within five minutes.
-- §485 **mesh-sdk's finding writer runs one act at a time, and recovers.** The writer of §461 runs its acts, `write`,
+- §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,
@@ -100,7 +97,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   3 and 4, health and events 2). How it is checked: unit (writer, both languages), a `write` during a statement is
   kept; after a reconnect an ask is answered and the findings are stated again; an `observe` failing at start then
   answering says its set within a minute.
-- §486 **A full step log is said and refuses no step's end.** The runner's `step-log` (§470) joins the stores of §366:
+- §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
@@ -122,12 +119,11 @@ reason. What a question of another kind leaves open waits for the operator and i
   seams and tools 3). How it is checked: whole (forge module), a run on request of a commit fails a `required` step,
   a pull request opened at that commit is refused, naming the step; a head that no run named merges; a later commit
   of the same content is refused too.
-- §488 **A call family G adds has its own capability word.** The tool runner states, beside `ledger-calls` and
+- §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. A module whose G build makes such a
-  call names the tool runner's module in its `needs` (kind 4), so on each node it is delivered after G's tool runner.
+  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
@@ -151,7 +147,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   more than one entry carries the name, naming them. Why: a name read as a module must name one (review round 1,
   security and upgrade 4). How it is checked: unit (manifest validator), two modules naming one Go module path
   refused; unit (builder), a name two entries carry answered `error`.
-- §492 **The builder hears the toolchains as an event.** Each build seat says `toolchain-reported` on
+- §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
@@ -187,10 +183,9 @@ reason. What a question of another kind leaves open waits for the operator and i
 
 ## Develop's next questions
 
-- §496 **A running step says its progress.** The holder of a build seat says `step-progress` on
+- §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 in the three build seats' definitions and kept on the seat's
-  stream for a day; the assigner says the same on `mesh-wants` for a composition step. `step-started` gains `ask`.
+  `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
@@ -202,7 +197,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   `branch-unprotected` stands (§17) raises none either. Why: the watchman already times each take-in wait (develop
   question on §12). How it is checked: whole (watchman), a head behind a pending revision raises nothing for 60
   minutes, then `take-in-waits`.
-- §498 **A wait names its clock and its kind.** `meshwants.Wait`, the runner's wait body and the node-engine seat's
+- §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`
@@ -210,7 +205,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   fingerprint, `held`, since and bound, from which the watchman seeds. Why: one wait form, told apart by `step`
   (develop questions WM6 and WM10). How it is checked: unit (contracts), each field read; whole (watchman), a put's
   wait raises `put-stands` and a pipeline's wait raises nothing for it.
-- §499 **The node-engine says a kept build's wait, and its version is read from the catalog.** A node-engine of G
+- §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
@@ -225,7 +220,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   validator built from its own heads (§16), so its validator knows every field, and a reader that does not is a
   reader edge said by its own wait (§94). Why: the indexer's `modules` goes (§196; develop question WM9). How it is
   checked: whole (watchman, indexer), an outgrown manifest raises `manifest-outgrown` and its mending clears it.
-- §501 **`watchman_views` answers per part and view.** It answers, per module and node, each first view the part
+- §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,
@@ -252,7 +247,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   build without a version (§371, §458), the builder writing it in its journal naming the module; at G's heads the
   validator refuses such a manifest (§411). Why: such an entry is only read from a revision before G (develop
   question of the builder). How it is checked: unit (builder), an entry of version `"1"` reserves nothing.
-- §506 **The entry carries its manifest's digest.** The catalog graph entry gains `manifest-digest`, the `sha256:`
+- §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
@@ -265,7 +260,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   and one source of the branches for every reader (develop questions Q18 and VW0, and the bridge's FB9). How it is
   checked: whole (assigner, bridge), before the first registrations a want is written from `source.main`, and no
   part's code holds `main`.
-- §508 **The node-engine claims its seat as one module.** The seat `node-engine`'s definition in mesh-contracts no
+- §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
@@ -279,7 +274,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   Why: one message per move, the pull request where there is one (develop questions FB1, FB2 and FB7). How it is
   checked: whole (bridge), an admitted push writes `pushed`, a merge `merged`, and a move of an unprotected branch
   writes nothing.
-- §510 **A merge the switch carries is performed.** A `merges` key the old bridge had not performed, an Approve the
+- §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
@@ -300,7 +295,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   `wait-held` with `step: delivery` (§498) and `version-delivered`'s machines away. Why: §186 has the tiers worked out
   from the difference and the owners' waits (develop questions VW2, VW3 and on §431). How it is checked: test 45; test
   106 for the delivery wait.
-- §513 **A state's objects store has a cap of 256 MiB, and the binding is mesh-sdk's.** The bus module plans each
+- §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

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

@@ -222,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* |

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

@@ -88,4 +88,5 @@ The part is ten files, each read whole, its design lines numbered across them:
 - [G-8-findings-heard-as-events](G-8-findings-heard-as-events.md): the operator's answers of 2026-11-11, findings heard as events (§383 to §390).
 - [G-9-prepare-answers](G-9-prepare-answers.md): the answers to the questions of G's final prepare and develop's first questions (§391 to §455).
 - [G-10-develop-answers](G-10-develop-answers.md): the answers to develop's second batch of questions, the operator's and those of internal form only (§456 to §479).
-- [G-11-develop-answers-review](G-11-develop-answers-review.md): the operator's answers of 2026-11-11 noon, the review of §456 to §479, and develop's next questions (§480 on).
+- [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).