2026-11-11 12:14:42 +00:00
6 changed files with 123 additions and 19 deletions
@@ -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
@@ -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).
@@ -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
@@ -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
@@ -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
@@ -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).