Say once how every part reads the catalog half per watched branch, so develop builds one form

Design 47 G §614 answers develop's D-5 and D-12 ahead of the rest of
batch 7: the reader through meshcatalogclient on the part's one views
reader, the branches from the registrations or the gate's source, the
manifest entries each part declares, an older build's entry asked once by
fingerprint, a none-yet branch read as empty, the first pass after every
first view, and a dropped branch's findings cleared.

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

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

@@ -0,0 +1,85 @@
+---
+layer: to-be
+status: in-progress
+design: 47
+milestone: G
+updated: 2026-11-11
+decisions:
+  - "ADR 0673"
+  - "ADR 0672"
+  - "ADR 0668"
+  - "ADR 0667"
+  - "ADR 0666"
+  - "ADR 0660"
+  - "ADR 0656"
+  - "ADR 0626"
+  - "ADR 0619"
+  - "ADR 0618"
+  - "ADR 0596"
+  - "ADR 0595"
+  - "ADR 0579"
+  - "ADR 0573"
+  - "ADR 0448"
+  - "ADR 0429"
+  - "ADR 0363"
+  - "ADR 0286"
+  - "ADR 0283"
+  - "ADR 0259"
+---
+
+# 47, milestone G: develop's seventh batch, the operator's answers of 15:14 to 15:42 CET, and the refreshed build maps
+
+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".
+
+*§610 to §673 will answer lead-47's seventh batch of 2026-11-11: the operator's answers of 2026-11-11 between 15:14 and
+15:42 CET at lead-47's terminal (§610 to §613, and §588 in G-16), the design questions of the six refreshed build
+maps, and develop's D-1 to D-12. Each other line is of internal form only, within what the records and the lines it
+cites decide. A line of another file that one of these corrects is corrected in that line (§15, §423, §515, §528,
+§570, §584, §585, §588, and design 34 every-event §11, §19, §35); here only what is new. A question one line answers
+for several build maps is answered once, and the maps' names for it are given in brackets.*
+
+*This commit carries §614 alone, ahead of the rest of the batch, so that develop can build from it.*
+
+## Reading the catalog half, every part alike
+
+- §614 **How a part reads the catalog half per watched branch, once for every part.** (§196, §199, §443, §459, §479,
+  §507, §521, §530, §532, §556; ADR 0656 §6, ADR 0596) Every part that reads the catalog half (a bundle or a process)
+  reads it so, and no part builds its own:
+  - **The reader.** Through `meshcatalogclient`, the client of the seat `mesh-catalog` in mesh-delivery's contracts
+    (ADR 0573 §1), wired on the one `go/views` reader the part already has: the bundle reader for a bundle, the process
+    reader (`views.ProcessReader`) for a process. Each watched branch is a view of that reader named
+    `mesh-catalog.catalog-revisions.<branch>` (§479), routed by §521, and the part's pass reads the views through that
+    reader alone.
+  - **The branches.** `meshcatalogclient` follows the branches itself, as mesh-delivery's code shared by every
+    reader of the seat: the registrations' watched branches, read by `registrations` at the start and followed by
+    `registration-changed` (§532); before the first registrations, the branches the gate's `source` answers, read at
+    the start and followed by the gate's `source-moved` (§507), which it stops following at the first
+    `registration-changed`. mesh-sdk's `go/views` adopts and drops the views (§532) and holds no seat's verb.
+  - **The manifest entries every such part declares.** In `consumes`: `mesh-catalog.catalog-revision`,
+    `mesh-catalog.registration-changed` and `mesh-delivery.source-moved`. In `invokes`:
+    `seat:mesh-catalog.revision` (with the field `none-yet`, §617), `seat:mesh-catalog.registrations`,
+    `seat:mesh-delivery.source`, and `seat:mesh-catalog.entry` for a part that reads an entry by its fingerprint.
+  - **An older build's entry.** A part that resolves an entry by fingerprint (§459's reader, the node-engine's want,
+    §421) keeps beside its views the entries by fingerprint it asked of `mesh-catalog.entry`. When it hears a
+    `running` or a `wanted` naming a fingerprint that no branch's newest revision lists and it does not hold, it asks
+    `entry` once, as a kept call (ADR 0668 §1), and keeps the answer; it removes one when no `running` or `wanted` it
+    holds names that fingerprint any more. The reader it passes to a pure function (§459) answers from the views and
+    those entries alone, and reads no bus; an entry not yet answered is answered as none, which §459 says.
+  - **A branch at `none yet`.** A view whose `revision` answered `none-yet` (§530) is ready and empty: the reader's
+    answer for that branch lists no entry.
+  - **The first pass.** A part acts on nothing until every branch it follows has its first view, `none-yet`
+    counting as one; until then `<module>_first_views` says each branch `waiting` and its health says it waits (§200,
+    §556). After its first views it acts on what it holds, and a view behind is read again by §196.
+  - **A dropped branch.** When `go/views` drops a branch's view (§532), it clears, through the part's writer (§639),
+    every finding that view raised (`first-view-unanswered`, `view-waits`, `view-unsaid`, `view-too-large`), says the
+    drop and each cleared finding in the part's log, and removes the view's row of `<module>_first_views` [D-12].
+
+  This is the one form for every reader of which modules exist and of the catalog graph's entries: the tool runner
+  (its owner of the assigner's views, §616, and its branches, [mesh-tools Q-R12]), the grants part [D-5], the
+  readers of §594, the node-engine (§421) and the Go build module (§615); and it answers mesh-sdk's question on
+  §532. Why: the same question came from five build maps, each about to build its own form (develop's D-5). How it
+  is checked: unit (`meshcatalogclient`), a branch added by `registration-changed` and one by `source-moved` before
+  the first registrations are followed, an entry asked once on a `running` of an unlisted fingerprint and dropped
+  when nothing names it, a `none-yet` branch read as empty; whole (grants part, tool runner), a part started with one
+  branch at `none-yet` acts once every first view is in; a dropped branch's findings are cleared.

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

@@ -82,7 +82,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 sixteen files, each read whole, its design lines numbered across them:
+The part is seventeen 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.
@@ -100,3 +100,6 @@ The part is sixteen files, each read whole, its design lines numbered across the
 - [G-14-recovery-module-and-review](G-14-recovery-module-and-review.md): the recovery module, the operator's answer of 2026-11-11 12:55 CET, and the review of §516 to §553 (§554 to §559).
 - [G-15-develop-answers-fifth](G-15-develop-answers-fifth.md): develop's fifth batch, round 3's notes on §516 to §559, the knowledge base's review of the recovery module's record, and the operator's answers of 2026-11-11 about 14:05, 14:15 and 14:30 CET (§560 to §586).
 - [G-16-develop-answers-sixth](G-16-develop-answers-sixth.md): develop's sixth batch: the ledger's upkeep calls, the builder's publishes again and its read of a module's builds, one event of a node's capabilities, the object stores' caps, the gate's merge path from G's delivery, and the readers of a module's manifest (§587 to §594).
+- [G-17-develop-answers-seventh](G-17-develop-answers-seventh.md): develop's seventh batch: the operator's answers of 2026-11-11 15:14 to 15:42 CET (callers by class, the five parts' findings, the forge and image registry's other entries, the gate's kept data), how every part reads the catalog half per watched branch, and the refreshed build maps' questions (§610 to §673).
+
+Design 34's milestone [every-event](../34-milestones/every-event.md) and design 46's milestone [7-approval-mark](../46-milestones/7-approval-mark.md) ship in milestone G's release, built in its repositories beside G's lines (lead-47, 2026-11-11 15:30 CET); where one of their lines and a line of G differ, G's later line holds and the other is corrected in place (§624 to §626).