Write the operator's answer on an Approve before G, and answer round 3's leftovers of the third batch

The operator made an old Approve that pull request's approval step, decided by the
registration's policy, so §510's carried act and §608's merge wait go; round 3 of
the third batch has no fourth round, so its findings are answered here (§543 to §550).

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

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

@@ -62,7 +62,7 @@ reason. What a question of another kind leaves open waits for the operator and i
 
 ## The review of §456 to §479, round 1
 
-- §483 **Main's step keys stay readable while main's askers run.** (§600, §601) A build seat's holder of G keys a step whose ask
+- §483 **Main's step keys stay readable while main's askers run.** (§600, §601, §544) A build seat's holder of G keys a step whose ask
   came on main's subject `mesh.seat.<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
@@ -106,7 +106,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   (review round 1, running and testing 5, health and events 3). How it is checked: whole (runner), with a fixture's
   small cap a step ends and is said, `full` is said and a start refused, and on `room` the entry is appended and the
   start taken.
-- §487 **The forge module learns a commit's fingerprint from every step end.** §475's `seen.<commit>.<module>` is
+- §487 **The forge module learns a commit's fingerprint from every step end.** (§548) §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
@@ -197,7 +197,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   `branch-unprotected` stands (§17) raises none either. Why: the watchman already times each take-in wait (develop
   question on §12). How it is checked: whole (watchman), a head behind a pending revision raises nothing for 60
   minutes, then `take-in-waits`.
-- §498 **A wait names its clock and its kind.** (§534, §608) `meshwants.Wait`, the runner's wait body and the node-engine seat's
+- §498 **A wait names its clock and its kind.** (§534, §608, §542) `meshwants.Wait`, the runner's wait body and the node-engine seat's
   gain `clock-from` (the time the bound counts from, §266, §269) beside `bound`, and `step`, one of the acting steps
   of §203 or `put`, `delivery`, `kept-build`, `backup`; a put's wait (main file, *A put without hold that stands*)
   is `step: put` with the node, the module and `fingerprint`; a dependent's delivery wait (§376) is `step: delivery`
@@ -274,7 +274,7 @@ reason. What a question of another kind leaves open waits for the operator and i
   Why: one message per move, the pull request where there is one (develop questions FB1, FB2 and FB7). How it is
   checked: whole (bridge), an admitted push writes `pushed`, a merge `merged`, and a move of an unprotected branch
   writes nothing.
-- §510 **A merge the switch carries is performed.** (§608) A `merges` key the old bridge had not performed, an Approve the
+- §510 **A merge the switch carries is performed.** (§608, §542) A `merges` key the old bridge had not performed, an Approve the
   operator gave before G, becomes an act (§169) that the bridge performs through `merge-pull`, judged as every merge;
   while `merge-pull` refuses it for missing registrations (§95) the act stays unanswered and is performed again on
   `registration-changed`. No other merge act is made after G (§167). Why: §169 drops nothing the operator approved

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

@@ -27,7 +27,9 @@ decisions:
 One file of milestone G's part of [design 47](../47-delivery-from-commit-to-delivered.md); the part opens at
 [G.md](G.md). Its design lines are numbered across every file of the part and cited as "design 47 G §n".
 
-*§522 is the operator's answer of 2026-11-11 at 12:11 CET at lead-47's terminal. Every other line answers a question
+*§522 and §542 are the operator's answers of 2026-11-11 at 12:11 and 12:33 CET at lead-47's terminal. §543 to §550
+answer what the four reviewers found in round 3 of [G-13](G-13-review-round-3.md) (§600 to §609), which has no round
+of its own after it. Every other line answers a question
 develop met after [G-11](G-11-develop-answers-review.md), of internal form only (playbook 07, step 0b), each the
 design's choice with its reason. What a question of another kind leaves open waits for the operator and is said in the
 line. Questions that an earlier line already answers have no line here: develop reads that line.*
@@ -348,6 +350,108 @@ line. Questions that an earlier line already answers have no line here: develop
   12:11 CET at lead-47's terminal, approved the words as the design writer proposed them. How it is checked: unit
   (teller), each of the three said in these words with its fields filled; whole (teller, router), as §514.
 
+- §542 **An Approve given before G is that pull request's approval step.** The operator, 2026-11-11 12:33 CET at
+  lead-47's terminal: approval is a step whose status each module's registration sets, never a gate of its own, so
+  an Approve given before G counts, once G is delivered, as that pull request's `approval` step and nothing else is
+  special. At G's switch the gate says, for each `merges` key the old bridge had not performed, `approval-carried` on
+  `mesh.seat.mesh-delivery.event.approval-carried` (`repository`, `pull`, `commit` the head the Approve named,
+  `approver` the operator, `at`), declared in the seat's definition, and deletes the key once the bus acknowledges
+  it. The runner keeps each in its old `state` section `pipelines` as `carried-approval.<repository>.<pull>`,
+  holding the commit, and takes it as the result `passed`, caller the operator, of the `approval` step of the first
+  pipeline or run at that commit, then deletes it; it deletes it unused when the seat `git` says the pull request
+  `pull-closed` or `pull-merged`. Where the module's policy makes `approval` `required`, a pull request whose head
+  moved after the Approve asks a new approval, as any step whose input changed does (an `approval` step is never
+  carried, ADR 0666 §8); where it is `optional` or `bypass`, the carried Approve holds nothing. The merge itself is
+  any merge (`merge-pull`, ADR 0666 §11): the bridge performs no carried act, the gate says no `wait-held` with
+  `step: merge`, and the watchman writes no `merge-waits`. Every `wait-held` the runner says for an `approval` step
+  has its `wait-ended`, said when the step ends in any of §24's outcomes (`passed`, `declined`, `superseded`,
+  `cancelled`, `not asked`) or its pipeline is superseded or cancelled, so no approval wait stands without an end.
+  This replaces §510 and §608, and `merge` leaves §498's list. Why: the operator's answer ("you're mixing in step and
+  approval gates, this should be configurable"); the event, the key and the deletion are the design's (round 3,
+  health and events' R7). How it is checked: whole (gate, runner), a carried Approve of a head passes that head's
+  `approval` step with the operator as caller; with `approval` `required`, a head moved after the Approve asks a new
+  approval; a pull request closed deletes its carried key; every `approval` wait-held in the whole test has its
+  `wait-ended`; the code review finds no `merge-waits`.
+
+## Round 3 of the review of §480 to §515
+
+- §543 **A build seat's holder refuses a kind its asker may not ask.** Callers stay per accepted kind (§338), and the
+  builder joins them as the one caller, beside the checker until §483's removal, of the kind `build`, as §601 has it
+  ask under its name. The grants part grants each asker publish on `mesh.seat.<seat>.accept.<queue>.<asker>` (§600)
+  for every queue of the seat on which a kind it is a caller of is taken, and the holder, which takes the asker from
+  the subject (§481), refuses an ask whose body names a kind that asker is not a caller of, answering `error` naming
+  the kind and the asker, and ends it with `step-ended` `failed`. This amends §338 and §600. Why: §600 puts the queue
+  in the subject and the kind in the body, so a subject's grant alone cannot hold a caller to its kinds (round 3,
+  security and upgrade, seams and tools: R1). How it is checked: unit (Go build module), a `step` published from the
+  indexer's account is answered `error` naming `step` and `indexer`; unit (grants part), each asker's grants are the
+  queues of its kinds.
+- §544 **Named asks have a worker of their own.** For each queue the grants part makes, beside main's worker
+  `SEAT_<SEAT>_<QUEUE>_worker` filtered to main's `mesh.seat.<seat>.accept.<queue>` alone, a second worker
+  `SEAT_<SEAT>_<QUEUE>_named_worker` filtered to `mesh.seat.<seat>.accept.<queue>.*`; the two filters do not overlap,
+  so the work-queue stream takes both. Only a holder of G pulls the named worker, and a holder of before G knows only
+  main's, so no filter is ever switched and a holder of before G that comes back from away (a laptop) after the grants
+  part runs takes no named ask. This replaces §601's "until every node's holder of a build seat is of G the grants
+  part's worker keeps main's one filter", and with it the edge from the seats' holders to the grants part, which no
+  manifest fact gives: the order is the asker's `invokes` of `<seat>.accept.<queue>` (kind 6, from the seat's holders
+  to the asker, §601), and the grants, written for a catalog revision before any want of it (*A credential and a
+  composition before the want*), exist before the asker runs. A named ask waits on its worker while no holder of G
+  runs, said by `build-capacity-waits` after 60 minutes, which corrects §483's "waits on the work queue, whose
+  consumer of before G takes only main's subject". At a revert, which reverts the askers before the grants part (ADR
+  0656 §4), the grants part of G, when it no longer hears any asker of G, purges the subjects
+  `accept.<queue>.*` of the stream and deletes the named workers, saying each in its journal; an ask is transport,
+  not kept data (as §59 has a sent object). Why: one consumer per filter, and a filter that never moves cannot be
+  pulled by a holder that does not read it (round 3, R2, the security reviewer's form). How it is checked: whole
+  (grants part, Go build module), a holder of before G started after the grants part of G takes main's asks and no
+  named one; a revert leaves no named worker and no named ask.
+- §545 **The tool runner's artifact declares the words it states.** The artifact entry of the tool runner's manifest
+  takes `states`, the capability words (§488) it states; the manifest validator refuses a package artifact's `calls`
+  word (§605) that no artifact of the revision `states`, naming the word, and the delivery plan's edge of §605 runs to
+  the module whose artifact `states` that word, so no manifest names the tool runner's module. A bundle is started by
+  the tool runner on its channel and ends with it, so a restart of the tool runner restarts its bundles, and each
+  reads the stated words at its own start; no event is heard and nothing polls. This amends §605's "each time the
+  tool runner of its node starts". Why: the words are stated only at run time, and the plan needs them in a manifest
+  (round 3, seams and tools: R3). How it is checked: unit (manifest validator), a `calls` word nothing `states`
+  refused; unit (delivery plan), the edge to the module stating the word.
+- §546 **When the builder forgets a node's toolchain.** The builder deletes its `toolchains-heard` key
+  `<node>.<language>` (§604) when the node-engine seat's `running.<node>.<module>` says `stopped` (§365) for the
+  module whose catalog graph entry claims the build seat of that language (its `acts` rule `build` with `on` naming
+  it, §535), heard through the durable consumer it already has of that seat's `running`; never on a placement, which
+  is the seat `mesh-module-assigner`'s state. The state is an old `state` section of the builder, a foundation part,
+  one key per node and language, about 12 keys of about 0.3 KiB each, capped at 1 MiB, so it adds no objects store
+  to §607's count (§58 plans one only for a state of the template); `builder_toolchains` reads it and
+  `builder_toolchains_drop` deletes one key, with why, written in the hand-act log of the seat `mesh-hand-acts`; a
+  holder says the key again at its start and on each change (§492). This amends §604's "when the node leaves the
+  catalog's placements". Why: the builder reads no other module's state (ADR 0596 §2; round 3, seams and tools: R4).
+  How it is checked: whole (builder), a build module stopped on a node deletes that node's key, and the drop tool
+  deletes one key and logs it.
+- §547 **The sum of the bus's caps is read against its limit.** The bus module reads the bus's storage limit from the
+  server's account information at its start and at each plan, sums the cap of every entry it plans (states, objects
+  stores, sent stores, streams, logs) and of every old section the catalog graph's entries declare, and shows both in
+  its `list` and its read tool. A plan whose sum passes the limit is refused, naming the sum and the limit, said as
+  its `refused` (ADR 0595 §6), whether or not the server reserves a cap at creation. When G's check measures that the
+  server reserves a cap when a store is made (§607), each `<state>-objects` is planned with 16 MiB instead of 64 MiB
+  (about 2.4 GiB for 150 states), a state needing more naming `objects-max-mib`. This amends §607. Why: the limit is a
+  fact of the server, read rather than written in the design, and a sum over it fails loudly (round 3, running and
+  testing: R5). How it is checked: whole (bus module), a fixture server with a small limit refuses a plan past it,
+  naming the sum; the sum and limit are in `list`.
+- §548 **The forge module writes `seen` only from the runner's steps.** §487's `seen.<commit>.<module>` is written
+  only from a `step-ended` whose asker is `runner`; the `step-ended` of any other ask (§602) carries `asker`, `ask`,
+  `node`, `outcome` and `at` and nothing of a pipeline, and the forge module writes nothing from it. This amends §487.
+  Why: since §602 every ask says `step-ended`, and a builder's build is no run of a commit (round 3, health and
+  events: R6). How it is checked: unit (forge module), a builder's failed build writes no `seen`; whole (watchman), a
+  `stuck` raised for an ask clears on its late `step-ended`.
+- §549 **Smaller corrections from round 3.** At its start the runner appends an `unlogged` entry (§606) only after
+  reading back its `step-log`'s last entry of that pipeline and step, and skips it when that entry is already
+  logged, so a stop between the append and the clear appends nothing twice. `step-progress` and `ask-taken` (§603)
+  name no `keep` and go on EVENTS, kept 7 days (§396). `runner_unlogged_append` is of class `act` and takes §391's
+  default callers. §58 is planned with the cap §607 and §547 give. How it is checked: whole (runner), a runner
+  stopped between the append and the clear logs the entry once; the rest as the lines they correct.
+- §550 **A publication's pipeline keeps the version.** The runner's pipeline value gains `version`, the version
+  `package-published` names, for a pipeline the runner started from a publication or from `outdated` (§334), and
+  none for any other; `show` answers it. This completes §334's "the version in the pipeline's state". Why: the
+  runner's contract had no field for it (develop's note on §334). How it is checked: unit (runner's contract), the
+  field read; whole (runner), a publish's pipeline shows its version.
+
 ## Questions an earlier line answers
 
 These write nothing new; develop reads the line named.
@@ -355,8 +459,8 @@ These write nothing new; develop reads the line named.
 - The tool runner's fallback of local commit 1015b38 for a foundation part's bundle goes: §407 binds that bundle to
   its old `objects` section, and a binding that is missing fails loudly (ADR 0595 §1) (Q-T5, T-11).
 - The re-read tool's callers of `seatlist.Part` are §204's for every part, the assigner's own list going (AS19).
-- The bus module's cap of a state's objects store and the binding's `objects` and `sent-objects` are §513's (NATS1,
-  §399).
+- The bus module's cap of a state's objects store is §513's as §607 and §547 amend it, and the binding's `objects`
+  and `sent-objects` are §513's (NATS1, §399).
 - The contracts' `Hold` is §194's view, the newest assignment half and the catalog half it names; the candidate's
   whole-half reader is §195's and §441's, read by a run on request's steps, `grants-for` and the indexer's candidate
   pass (contracts).

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

@@ -28,7 +28,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12.
 *These lines answer what the four reviewers by architectural domain found in round 2 of
 [G-11](G-11-develop-answers-review.md) (§480 to §515), the last round. Each is the design's choice with its reason.*
 
-- §600 **A build seat's asks: subjects, workers and grants.** A build seat (`node-build-go`, `node-build-node`,
+- §600 **A build seat's asks: subjects, workers and grants.** (§543, §544) A build seat (`node-build-go`, `node-build-node`,
   `node-build-image`) keeps its three queues of main, `delivery`, `check` and `recheck` (ADR 0525 §4, ADR 0536 §4), on
   its one work-queue stream. An ask is published on `mesh.seat.<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
@@ -43,7 +43,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12.
   checked: unit (grants part), each queue's worker filters both subjects and each asker's grant is its own name;
   whole (grants part, Go build module), an ask under `runner` is taken and answered, and the runner's account
   publishing on main's `accept.check` is refused.
-- §601 **The order of G's rollout for the build seats.** The holders of the three build seats are delivered first,
+- §601 **The order of G's rollout for the build seats.** (§544) The holders of the three build seats are delivered first,
   then the grants part, whose workers then filter both forms (§600), then every asker of G (the runner, the indexer,
   the assigner, the builder) and the watchman. Until every node's holder of a build seat is of G the grants part's
   worker keeps main's one filter, so a holder of before G never takes a named ask, whose key it would write in main's
@@ -68,20 +68,20 @@ takes §600 on, since §516 on are those of batch 4's file G-12.
   `stuck`, naming the seat, the asker, the ask and the node, as main's mirror does. This completes §496. Why: only the
   runner says `step-started` (review round 2, health and events 1). How it is checked: whole (watchman, Go build
   module), a builder's build whose holder stops raises `stuck` within five minutes and one that ends raises nothing.
-- §603 **Where `step-progress` and `ask-taken` go.** Both are seat events and go on the stream that carries the seat's
+- §603 **Where `step-progress` and `ask-taken` go.** (§549) Both are seat events and go on the stream that carries the seat's
   events, at that stream's own age; no stream is added and no event's age changes. `step-progress` and `ask-taken`
   are declared in the three build seats' definitions in `mesh-delivery-contracts`, and `step-progress` in
   `mesh-wants`' definition for a composition step. This amends §496's "kept on the seat's stream for a day". Why:
   a build seat's own stream is its asks' work queue (review round 2, running and testing 4, seams and tools' note).
   How it is checked: unit (definitions), each event declared.
-- §604 **The builder keeps the toolchains it heard.** The builder writes each `toolchain-reported` (§492) in a state of
+- §604 **The builder keeps the toolchains it heard.** (§546) The builder writes each `toolchain-reported` (§492) in a state of
   its own, `toolchains-heard`, one key `<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
+- §605 **The order after G's tool runner is derived from the package a build resolved.** (§545) A package's artifact in a
   manifest takes `calls`, the capability words (§488) its code calls of the tool runner; mesh-sdk's Go and npm
   packages name `ledger-upkeep-calls`, `sent-objects-calls` and `put-sessions` from G. For each module whose build
   resolved a version of such a package (§466's `resolved`), the delivery plan derives a served-word edge (kind 6) to
@@ -90,7 +90,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12.
   This amends §488's `needs`. Why: the bundle makes a session whenever a value is large, so only the package knows
   (review round 2, seams and tools 3, running and testing's note). How it is checked: unit (delivery plan), a module
   built on G's mesh-sdk is ordered after the tool runner on each node; unit (manifest validator), `calls` read.
-- §606 **A step's end and its unlogged entry are one write.** The runner writes a step's end in `pipelines` with the
+- §606 **A step's end and its unlogged entry are one write.** (§549) The runner writes a step's end in `pipelines` with the
   entry as `unlogged` in the same compare-and-set, appends it to `step-log`, then clears it; at its start it appends
   every `unlogged` entry of its pipelines, in order. It reads the log's fill again at each step's end, at its start,
   and once a minute while the log is `full`, so the entries the bus ages out say `room` with no step ending. Its tool
@@ -99,7 +99,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12.
   full log (review round 2, running and testing 2, health and events 3, seams and tools' note). How it is checked:
   whole (runner), a runner stopped after a step's end appends its entry at start; a full log whose oldest entries age
   out says `room` with no step ending.
-- §607 **A state's objects store has the state's size.** Each `<state>-objects` (§58) is planned with the state
+- §607 **A state's objects store has the state's size.** (§547) 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
@@ -108,7 +108,7 @@ takes §600 on, since §516 on are those of batch 4's file G-12.
   its owner. This amends §513 and leaves §58's "reserves nothing" to that measurement. Why: §58 names the template's
   size (review round 2, running and testing 3). How it is checked: unit (bus module's plan), each objects store's cap;
   whole (bus module), the reserved storage read after the plan.
-- §608 **A carried merge that waits is a timed wait.** A merge act carried by the switch (§510) waiting for the first
+- §608 **A carried merge that waits is a timed wait.** (§542) A merge act carried by the switch (§510) waiting for the first
   registrations is said by the gate as `wait-held` with `step: merge` (added to §498's list), naming the pull request
   and the head the Approve named, bounded at 60 minutes; past it the watchman writes `merge-waits`, which the
   condition keeper raises and `wait-ended` clears. It merges only the head the Approve named: a pull request moved

03-DESIGN/01-to-be/47-milestones/G-2-pipelines-sizes-checks-and-tools.md

@@ -41,7 +41,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
   compare-and-set; the object it replaced stays, as one whose key was deleted does, listed as `key gone` since no key
   names it, and only the drop tool removes either, on a person's word: the mesh removes kept data only through `drop`
   and `recreate`, each on a person's word (ADR 0595 §4; ADR 0666 §16).
-- §58 **One object store per state, granted to its owner.** (§513) Each state asked by the template `state` gets its object store
+- §58 **One object store per state, granted to its owner.** (§513, §549) Each state asked by the template `state` gets its object store
   beside it, `<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

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

@@ -124,7 +124,7 @@ record it follows from, and replaces the builder's own choice where one was made
   `take-in.taken` (ADR 0666 §13), which ADR 0596 §1 lets any module subscribe to; the indexer's name stands in that
   manifest only, never in the runner's code. Why: ADR 0666 §13, in force, names that event. How it is checked: the code review
   reads that no module name stands in the runner's code (§7).
-- §334 **A publication's pipelines and their key.** `package-published` carries the package's artifact reference
+- §334 **A publication's pipelines and their key.** (§550) `package-published` carries the package's artifact reference
   (`<module>:<artifact>`, from the catalog entry), its version and digest, the watched branch and the source revision
   its build was made from. The runner asks `outdated` for that package on that branch and starts a pipeline for each
   dependent `outdated` names behind (§53), keyed by that branch, that source revision and the dependent module, the version in the pipeline's state; a `take-in.taken` of the same revision and module is the
@@ -165,7 +165,7 @@ record it follows from, and replaces the builder's own choice where one was made
   and restore a module's kept data on the bus name `holder:node-backup@same-node`. Why: only that holder takes them
   (*A backup before the apply: kept data on the bus*). How it is checked: a call from another node's `node-backup`
   holder is refused by the bus.
-- §338 **Callers on accepted kinds.** (§480, §481) An accepted kind of a work queue carries `callers` as a verb does, and the grants part
+- §338 **Callers on accepted kinds.** (§480, §481, §543) An accepted kind of a work queue carries `callers` as a verb does, and the grants part
   grants publish on its subject to them alone: the build seats' `step` the runner; `run` the runner, the indexer and
   the assigner, and the checker until its entry is removed with its buckets and bus account (ADR 0667 §12); `mesh-wants`'s
   `step` the runner. Verbs: `steps` the runner and the indexer (its seed); `drop` the runner and the builder; both

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

@@ -89,5 +89,5 @@ The part is thirteen files, each read whole, its design lines numbered across th
 - [G-9-prepare-answers](G-9-prepare-answers.md): the answers to the questions of G's final prepare and develop's first questions (§391 to §455).
 - [G-10-develop-answers](G-10-develop-answers.md): the answers to develop's second batch of questions, the operator's and those of internal form only (§456 to §479).
 - [G-11-develop-answers-review](G-11-develop-answers-review.md): the operator's answers of 2026-11-11 noon, the review of §456 to §479, and develop's next questions (§480 to §515).
-- [G-12-develop-answers-fourth](G-12-develop-answers-fourth.md): the operator's words of 2026-11-11 and develop's fourth batch of questions (§516 to §541).
+- [G-12-develop-answers-fourth](G-12-develop-answers-fourth.md): the operator's words of 2026-11-11 and develop's fourth batch of questions (§516 to §550).
 - [G-13-review-round-3](G-13-review-round-3.md): the review of §480 to §515, rounds 2 and 3 (§600 on).