Have only the indexer read manifests, and settle the four prepare items that contradicted each other

The operator's rule is that the indexer alone uses manifests to build the catalog graph, so every other part's
read of a manifest becomes a read of the catalog half. Lead-47's rulings settle the finding layout as a seat
contract with generated writers, process-builds as a node-engine seat verb, a grants-for read on mesh-grants for
widens, and aside on node-backup.

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

00-META/glossary.md

@@ -596,7 +596,8 @@ controller (the planner, the rollout) until release 6 of ADR 0429; from each rel
   change, are triggers that rebuild, never waits; a verb edge on a cycle is left out (ADR 0603 §1, §2, ADR 0614); from research 085's milestone an acting part's edge is a wait within
   its step (ADR 0656). From milestone G's delivery it is kept once per **watched branch**, and its edges run between
   **artifact references**, of six kinds, the reverse order holding when something goes away (ADR 0666 §6, §14).
-  Nothing stores the order. Not the **assignment graph**, computed from it.
+  Nothing stores the order. Only the indexer reads the manifests; every other part reads the catalog graph (the operator,
+  2026-11-11; design 47 G §442). Not the **assignment graph**, computed from it.
   *Not:* ~~build graph~~
 - **assignment graph** — the module versions placed on nodes at one revision, with the edges between versions that
   its inputs give: provisioning, contribution, and the acting parts' versions that are to act on each entry. The

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

@@ -273,7 +273,7 @@ source revision is derived from the keys: every **want** equals its module's **f
   delivery it runs the composition step, and writes a want only from a revision whose every `required` pipeline step
   passed, on the watched branch a placement chose (ADR 0666 §9, §17).
 - **The node agent**, the node-engine's own process, follows its node's wants, **composes each wanted module for
-  its own node** with the composition of `mesh-delivery-sdk` from the manifest by digest, the module's resolved values from
+  its own node** with the composition of `mesh-delivery-sdk` from the catalog graph's entry of the build (from milestone G; before it, the manifest by digest), the module's resolved values from
   mesh-config, its secrets and bus credential asked of the vault sealed to the node's key, its licences and what
   its providers contribute, applies one module at a time and only what differs from what runs, backs up a data
   module first, and writes its haves with the fingerprint and the digest of the composition it runs (ADR 0547 §2,
@@ -724,7 +724,7 @@ From its delivery, a check is this:
   issue 482). A trunk move asks no check but a carry, which runs only what the move changed (ADR 0548 §5).
 - **The composition check is the assigner's.** Whether the machines still compose with a change is checked by
   the part that owns what each machine should run. The assigner reads the modules, fingerprints and manifests
-  the indexer holds and the builds the builder holds; the machines, their roles, assignments and settings, and
+  the indexer holds (from milestone G, the catalog half alone: design 47 G §442) and the builds the builder holds; the machines, their roles, assignments and settings, and
   the grants and credentials it reads from the grants part's state and the vault's accounts, and the rest from the buckets it
   names in its manifest's `reads` (ADR 0237 §1, ADR 0408 §3, ADR 0547 §4). It clones no repository but at most the change's
   own, and
@@ -1060,7 +1060,7 @@ backup holder backs up nothing, and the have says so.
 *ADR 0360 §8, §9, ADR 0377, ADR 0429 §4, §6, ADR 0539 §9, §14 to §16, ADR 0546 §5, §6, ADR 0547 §2 to §9, ADR 0549, ADR 0555.*
 
 - **Each node composes its own.** For each want `want.<node>.<module>` the node agent composes that module for
-  its own node with the composition of `mesh-delivery-sdk` from the manifest by digest the indexer wrote, the module's resolved
+  its own node with the composition of `mesh-delivery-sdk` from the catalog graph's entry of the build, from milestone G (before it, the manifest by digest the indexer wrote), the module's resolved
   values read from mesh-config's resolved state filtered to its node, its secrets and bus credential asked of the
   vault sealed to the node's key (ADR 0349 §11), its licences, and what its providers contribute; and the node's
   own composition (adoption, firewall openings, accounts, the resolver, identities and groups) from the same
@@ -1074,8 +1074,9 @@ backup holder backs up nothing, and the have says so.
     assigner's credential alone on an approved proposal and said by `assignments-changed` (ADR 0567, ADR 0641);
   - **the node records**, each in its node's own have key `<node>.node`, written by that node alone and heard as
     the key's change (ADR 0555 §3);
-  - **the manifests**, the indexer's `modules.<module>` and its manifests by digest, or the digest the composing
-    node's want names where it runs another build; the private network's manifest is its holder `mesh-wireguard`'s
+  - **the manifests**, until milestone G the indexer's `modules.<module>` and its manifests by digest, or the digest the composing
+    node's want names where it runs another build; from milestone G the catalog graph's entries of the catalog half,
+    the indexer being the only part that reads a manifest (design 47 G §442); the private network's manifest is its holder `mesh-wireguard`'s
     own (ADR 0636 §4);
   - **the config values**, mesh-config's resolved state, the composing node's slice alone for a node agent; a module
     in the settings form (its manifest declares no config, so mesh-config holds none for it) has its values in the
@@ -1699,7 +1700,7 @@ Each change ADR 0656 makes in an earlier record, and its test:
     and act once the view is back, clearing it; the node-engine waits only for the catalog half; a candidate's heads
     are read by the indexer's candidate pass and by no running part (whole).
 48. **A process reports its handed build** (ADR 0639 §7). A part started while its node's want differs from what runs
-    reports the build it was started with, and `node_process_builds` reads it (whole, node-engine).
+    reports the build it was started with, and the node-engine seat's verb `process-builds` reads it (whole, node-engine).
 49. **The forge bridge reads a group from the gate's verb** (ADR 0633 §4, §5). The forge bridge sets the group on each
     merged message and publishes a group's end again from the seat `mesh-delivery`'s verb `groups`, and its account
     holds no read of the gate's `merges` state, so a read of it is refused (whole, forge bridge).

03-DESIGN/01-to-be/47-milestones/G-1-pipelines-registration-and-steps.md

@@ -372,7 +372,7 @@ check and deliver milestone G itself (ADR 0667 §2); each of them says so in a l
   program's cycle rule goes with the checker.
 - §50 **A format's reader first.** A format a running reader cannot read is preceded by its reader, an edge of kind 4 on
   every watched branch (ADR 0666 §14): the indexer's manifest validator for a new field of a seat definition or a
-  manifest, and on each node the node-engine that reads a manifest's new fields before any manifest that writes them
+  manifest, and on each node the node-engine that reads a catalog graph entry's new fields before any manifest that writes them
   (ADR 0667 §4).
 - §51 **How it is checked.** Unit (indexer's graph): a chain per artifact where modules would cycle; two programs needing
   each other's new verb are one step; two artifacts each needing the other's new package to build are refused, naming

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

@@ -55,9 +55,9 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
   event, read within its call's bound or its consumer's lag, so its expiry is not a removal of kept data that ADR 0595
   §4 holds to a person's word (the design's choice; 7 days is a guess at the longest a consumer lags, read from the
   fill tools once G runs). A full sent store is the bus module's `full` and its condition (ADR 0595 §6), and the sender
-  then refuses the large reply or event loudly, naming the store. The grants part derives from the manifests a standing grant to read them: the
+  then refuses the large reply or event loudly, naming the store. The grants part derives from the catalog graph (§442), never from a manifest, a standing grant to read them: the
   callers its seat definition names for the verbs it serves, and the consumers whose `consumes` declare its events;
-  no other module may read them (ADR 0666 §16). The grant follows the manifests, so it is written when they change,
+  no other module may read them (ADR 0666 §16). The grant follows the catalog graph, so it is written at each `catalog-revision` that changes it,
   never per object. A consumer's reader of
   the form is delivered before its producer writes it, an edge of kind 4.
 - §60 **Its tools come with the package.** The package serves each module that imports it `<module>_state_objects` (the
@@ -129,7 +129,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
   registration*; issue 1966, note 157).
 - §71 **A widening is said, never refused.** A change that alters any part serving a step (the runner, step detection, the
   lint rule, a build seat's test runner, the composer), or widens an acting rule, a grant or a credential, says so in
-  its `pipeline-ended`, its field `widens` naming each. The running runner computes it, from the sources of the change
+  its `pipeline-ended`, its field `widens` naming each. The running runner computes it, the serving parts from the seat list by fingerprint and the grants through the seat `mesh-grants`' verb `grants-for` (§441), from the sources of the change
   against those of the watched branch, never the runner built from the change, so a change cannot hide its own
   widening; nothing refuses it for that (ADR 0666 §23, the operator, 2026-11-10). The teller passes `widens` on to every
   channel, as it does `recovery-merged`. This is what replaces ADR 0656 §8's naming in the Approve ask.
@@ -275,7 +275,7 @@ step keys and the builder's build log, against the checker's last week (test 99)
   them; the manifest validator for the manifests' new words (`version`, §368; a `*` emitter in `consumes`, §386; the
   finding stream an observer declares, §383, §387) and the grants part that makes a `*` entry's durable consumers
   (§386), before the keeper's or any observer's manifest using them; on each node the node-engine that reads `form`
-  and `catch-up` before any manifest writing them. The running checker's validator makes G's own check, so the reading
+  and `catch-up` from the catalog graph before any manifest writing them. The manifest validator the running checker asks for G's own check is the indexer's, so the reading
   of these words goes in the reader release of §340, whether or not that validator already takes one of them.
 - §90 **The stream maker first** (ADR 0667 §5): the grants part, which makes each kept seat stream and its durable
   consumers, before the parts that hear a kept stream.
@@ -341,7 +341,7 @@ step keys and the builder's build log, against the checker's last week (test 99)
 | §121 The six kinds derived from existing words, `needs` per artifact only where nothing says it | one form of each fact (ADR 0656 §6); the catalog entry's `needs` already exists from G |
 | §122 The cycle rule in the indexer's graph | the graph is the indexer's, and the checking program goes with the checker |
 | §123 The builder's seat `mesh-builds` and its event `package-published` | the record has the builder say the publication as an event of its seat (ADR 0666 §15); its waits move only when a later change gives the seat its verbs |
-| §124 Each state's object store `<state>-objects` through mesh-sdk's small package, sent objects readable by a standing grant derived from the manifests, and the package's two tools | one object store per state, granted to its owner; the sender's declared callers and consumers read what it sends (ADR 0666 §16); only its users import it, so nothing else is rebuilt |
+| §124 Each state's object store `<state>-objects` through mesh-sdk's small package, sent objects readable by a standing grant derived from the catalog graph, and the package's two tools | one object store per state, granted to its owner; the sender's declared callers and consumers read what it sends (ADR 0666 §16); only its users import it, so nothing else is rebuilt |
 | §125 The `run` ask published by the runner's account and the indexer's; the verb `run` called by the sessions and the operator only | the steps and the validation run code from the change, in the sandbox only, and each asker reads only its own step keys (ADR 0363 §2); a run publishes tagged packages, so nothing else may ask one |
 | §126 The checker's step `check` becomes `pipeline`; `kept` starts empty | the runner is an acting part in the checker's place (ADR 0666 §19); a step's result is taken only from its seat holder (ADR 0666 §21), so no verdict of the checker's is taken in, at the cost of one round of every module's tests |
 | §127 The field `callers` in a seat definition replaces the holders' trusted `callers`, a missing field admitting the holder roles and the operator only | the record makes the definition the grants part's one source (ADR 0666 §20); a field left out must open nothing |

03-DESIGN/01-to-be/47-milestones/G-4-revision-view-and-steps.md

@@ -105,8 +105,8 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
   indexer's whole-module test, started with a definition on a contracts trunk that no event announced, the first
   manifest claiming that seat is judged with it.
 - §199 **Who holds a seat is applied by one rule, from what each node runs.** The node-engine and the grants part decide a
-  seat's pass by mesh-sdk's `SeatsToPassOn` (ADR 0660 §3), reading the manifest of the build each assignment runs
-  (ADR 0660 §2). What each node runs is heard, never asked: each part keeps it from the node-engine seat's events
+  seat's pass by mesh-sdk's `SeatsToPassOn` (ADR 0660 §3), reading the catalog graph's entry of the build each assignment
+  runs, never a manifest (ADR 0660 §2; §442). What each node runs is heard, never asked: each part keeps it from the node-engine seat's events
   `running.<node>.<module>` (*What each step says*), through a durable consumer of its own declared in its `consumes`,
   so a pass is decided with no call to a node that may be away. The seat's stream keeps the last message per subject
   with no age limit, so the last `running` of every module on every node stays on it however long ago it was said,
@@ -115,7 +115,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
   digest of the build's manifest, which is the indexer's manifest of that build (ADR 0660 §2's "the indexer's
   manifest of it"), read by digest from the catalog half; the builder's done key is not needed, since the event names
   the digest it would give. A node that has said no `running` for a module since the part's consumer began counts by
-  the trunk's manifest, as ADR 0660 §2 has it where the running build cannot be read, and both parts apply that same
+  the catalog graph's entry of the module on its placement's branch, as ADR 0660 §2 has it where the running build cannot be read, and both parts apply that same
   fallback in the one function (ADR 0660 §3). Never another node's have key, its want or the assignment half (ADR 0596
   §2; *Each part acts on its own entries*). The design's choice under ADR 0660 §2: the node that runs a build says what
   it runs, and an event kept by a durable consumer answers when that node is away. How it is checked: test 56.
@@ -241,11 +241,11 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
 | §242 An Approve given held while its heads stand (issue 1972) | the operator approved those heads; a check of them asked again changes nothing they approved (ADR 0441 §1, ADR 0548 §8) |
 | §243 The milestone events on a subject of their own | a waiter on one member's pull request otherwise wakes on every member's |
 | §244 The issue tracker's link kinds to a decision and a research effort, and the knowledge base's link from a decision to its milestone | the trace from research to the running build is then links all the way, with no text match (research 085, Findings 7; ADR 0493 §4) |
-| §245 The view's state read and asked again by mesh-sdk's `go/views` tools `<module>_first_views` and `<module>_first_view_again`, which gain the revision a part holds and what it waits for; the typed first view and the following of each half in the seats' client packages `meshcatalogclient` and `meshwantsclient`, built on `go/views`; the finding `view-waits` after five minutes; and `node_process_builds` | every part's view and every process's own build is read and steered by a tool; `go/views` already follows an owner's events durably and serves those two tools, so a second follower or a second pair of tools would be two forms of one thing; a view tool typed by the two seats would make mesh-sdk import contracts (ADR 0635 §4), so the typed half sits in the seats' client packages (ADR 0625 §4); a part waiting for the view is raised on the bound the seat list's readers keep |
+| §245 The view's state read and asked again by mesh-sdk's `go/views` tools `<module>_first_views` and `<module>_first_view_again`, which gain the revision a part holds and what it waits for; the typed first view and the following of each half in the seats' client packages `meshcatalogclient` and `meshwantsclient`, built on `go/views`; the finding `view-waits` after five minutes; and the node-engine seat's verb `process-builds` (§440) | every part's view and every process's own build is read and steered by a tool; `go/views` already follows an owner's events durably and serves those two tools, so a second follower or a second pair of tools would be two forms of one thing; a view tool typed by the two seats would make mesh-sdk import contracts (ADR 0635 §4), so the typed half sits in the seats' client packages (ADR 0625 §4); a part waiting for the view is raised on the bound the seat list's readers keep |
 | §246 The seat list's reader and its two tools wired once by mesh-sdk's runtime | ADR 0636 §7 puts them in the runtime bundle; four hand-wired copies would each learn `acts` apart |
 | §247 The trunk's heads from the catalog half, and nothing read of the gate by the checker | ADR 0596 §2; with the hold and turns removed nothing of the gate is left for the checker to read |
 | §248 The indexer reads every contracts trunk's definitions at its start, before it judges | a definition merged while it was down is never judged against a list that lacks it (ADR 0636 §1) |
-| §249 Another node's running build kept from the node-engine seat's `running` events by a durable consumer, the event carrying the fingerprint and the manifest's digest, the trunk's manifest for a node that said nothing | ADR 0660 §2 reads the manifest of the build each node runs; an event kept by a durable consumer answers while a node is away, where a call would wait on it; one fallback in the one function keeps the two parts agreed (ADR 0660 §3) |
+| §249 Another node's running build kept from the node-engine seat's `running` events by a durable consumer, the event carrying the fingerprint and the manifest's digest, the catalog graph's entry for a node that said nothing | ADR 0660 §2 reads the manifest of the build each node runs; an event kept by a durable consumer answers while a node is away, where a call would wait on it; one fallback in the one function keeps the two parts agreed (ADR 0660 §3) |
 | §250 What the gate and the checker owe the forge said as the event `owed` per repository and pull request, each act safe to repeat at the forge, each outcome said as `owed.ended` and recorded, an unanswered act said again at the gate's start and stalled after 15 minutes | ADR 0596 §1, §2 end the watches of the gate's and the checker's keys; an act safe to repeat cannot be lost between the act and its record, where an id recorded first could; an outcome said and recorded leaves no act unseen |
 | §251 A merge made at the forge opens a `forge-made` delivery record | its trace and outcomes are kept like every delivery's, and no later merge waits behind a merge the gate never heard |
 | §252 Every delivery part and the gate reach the forge only through the seat `git`'s verbs and events, the act verbs granted by the holder's trusted `callers` to the forge bridge alone, a failed read answered as an error | the delivery parts name no other module (ADR 0656 §1, acceptance test 27); the forge's answers are typed in the seat's contract instead of guessed in each caller; the bridge stays the one part that acts on the forge; an error read as an empty answer would hide a forge down |
@@ -319,8 +319,8 @@ what it heard and how far it is behind, and `<module>_first_view_again`, granted
 read the view again now. `go/views` stays seat-neutral, naming no seat and no seat's type (ADR 0635 §4); the typed
 first view of each half and the following of its events are the seats' client packages, `meshcatalogclient` for
 `mesh-catalog` and `meshwantsclient` for `mesh-wants`, each built on `go/views` (ADR 0625 §4), so no part follows the
-view by a follower of its own. A tool
-of the node-engine, `node_process_builds`, reads the build each process was started with. The tools answer the four
+view by a follower of its own. The node-engine's seat
+verb `process-builds` (§440) reads the build each process was started with. The tools answer the four
 lines every module's tools answer (design 26), so that every state these parts keep is read and every act they do is
 steered by a tool.
 

03-DESIGN/01-to-be/47-milestones/G-6-verbs-and-retires.md

@@ -77,7 +77,7 @@ each step says*.
 
 §309 **The seat `node-engine`**'s event `running.<node>.<module>` carries, from research 085's milestone, the module, its
 fingerprint and the digest of its build's manifest, so the node-engine of another node and the grants part decide a
-seat's pass from it (ADR 0660 §2; *Who holds a seat is applied by one rule*). No verb is added.
+seat's pass from the catalog graph's entry of that build (ADR 0660 §2; *Who holds a seat is applied by one rule*). No verb is added.
 
 §310 **The seat `git`.** The seat `git` (design 26, *The git seat*), of the Delivery domain, defined in
 `mesh-delivery-contracts`, holds no verb today, and the delivery parts and the gate reach the forge by naming the forge

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

@@ -43,8 +43,7 @@ record says so in its Why. Round 3 of the review by architectural domain (2026-1
   `since` (§437); `finding-cleared` carries `scope`, `id`, `kind`, `at`
   and `why`. The observer and the node are the subject's alone: the grants part grants each module's account publish
   on its own stream's subjects of its own node's segment only, the keeper takes both from the subject, and it refuses
-  an event whose body names another observer or node, said in its journal. mesh-sdk's finding writer (`go/views`'
-  `FindingWriter`) says them for every part, after the key it writes in the part's own state `findings`, which stays
+  an event whose body names another observer or node, said in its journal. The writer generated from the seat `mesh-conditions`' definition (§439) says them for every part, after the key it writes in the part's own state `findings`, which stays
   the owner's and is read only by the owner's read tool; a publish the bus does not acknowledge is sent again for one
   minute, then written in the part's journal as an error naming the finding, and the next statement covers it. The
   keeper takes a finding only from a source of its own list (§388) and raises or changes a condition on
@@ -102,9 +101,8 @@ record says so in its Why. Round 3 of the review by architectural domain (2026-1
   `*.<event>` takes the event `<event>` from every module whose manifest declares it, and is the one generic form for
   hearing an event that many modules say; the keeper's `*.finding-written`, `*.finding-cleared` and
   `*.findings-stated` are the first. The manifest validator takes `*` only as the whole emitter, and only before an
-  event that a seat's definition or a contract in mesh-sdk defines, with its fields (for the finding events, mesh-sdk's
-  finding writer); it refuses `*` before any other event, `*.>`, and `*` in part of an emitter's name. The grants part,
-  from the manifests as it derives every grant (§59), makes on each declaring module's stream one durable consumer
+  event that a seat's definition or a contract in mesh-sdk defines, with its fields (for the finding events, the seat `mesh-conditions`' definition, §439); it refuses `*` before any other event, `*.>`, and `*` in part of an emitter's name. The grants part,
+  from the catalog graph as it derives every grant (§59, §442), makes on each declaring module's stream one durable consumer
   for the consumer, named `<machine>_<module>` as ADR 0363 §5 names one, with its grants to read and acknowledge it and
   its membership's word to bind it; it drops that consumer when the module no longer declares the event, and makes one
   for a module that declares it later, with no change to the consumer's manifest. A `*` entry never reaches a

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

@@ -92,9 +92,9 @@ line says so.*
 - §400 **No new verb is optional.** A verb G adds is not `optional`: the order of its holder's delivery is §298's
   edges, and a claim refused meanwhile is a gap of the delivery system built within G (§93). Why: the design's choice
   (Q9). How it is checked: unit (definition reader), no verb G adds is marked `optional`.
-- §401 **The seat `mesh-grants` has no verbs in G.** Its definition carries its rule and its four events only; its
-  module's tools `grants_waits`, `grants_release`, `grants_callers` and `grants_why_refused` stay its own. Why: the
-  design's choice (Q12). How it is checked: the seat's fixtures.
+- §401 **The seat `mesh-grants` has one verb in G.** Its definition carries its rule, its four events and the read
+  `grants-for` (§441); its module's tools `grants_waits`, `grants_release`, `grants_callers` and `grants_why_refused` stay its own. Why: the
+  design's choice (Q12, amended by D15, §441). How it is checked: the seat's fixtures.
 - §402 **A placement's `build` is a fingerprint, and `unwatch` waits for the placements.** A placement's `build` names a
   fingerprint; `unwatch` refuses while a placement names the branch, naming the placement. Why: the design's choice
   (Q13). How it is checked: whole (indexer), `unwatch` of a placed branch refused.
@@ -110,11 +110,12 @@ line says so.*
   `restore-kept`, their callers `holder:node-backup@same-node` (§337); the seat `node-backup`'s `now` and `restore`
   gain `kept`, `form` and `fingerprint`, and say `ended.<module>` and `restored.<module>`, each keyed by the module, the
   kept data, its form and the fingerprint; listing and discarding stay node-backup's `backed-up` and `discard-aside`
-  (§302). Test 36's whole case lives in `mesh-host`. Why: the design's choice, one answer to three preparers (Q8, S9,
-  Q-H6, C19's verb names). How it is checked: test 36; a call of `snapshot-kept` from another node's `node-backup`
+  (§302), and so does `aside`, which sets a module's live kept data aside before a restore; `mesh-broker` serves
+  only `snapshot-kept` and `restore-kept`. Test 36's whole case lives in `mesh-host`. Why: the design's choice, one answer to three preparers (Q8, S9,
+  Q-H6, C19; lead-47's ruling, 2026-11-11). How it is checked: test 36; a call of `snapshot-kept` from another node's `node-backup`
   holder is refused by the bus.
 - §406 **A catch-up names its tool and arguments.** A restore point records the catch-up tool and its arguments whole
-  (§299), and the restored manifest grants that tool to `holder:node-engine@same-node`. Why: the design's choice (Q-H7).
+  (§299), and the restored module's catalog graph entry grants that tool to `holder:node-engine@same-node`. Why: the design's choice (Q-H7).
   How it is checked: whole (node-engine), a restore runs its recorded catch-up.
 - §407 **The object store package.** mesh-sdk's object store package is `go/stateobjects`; it also takes a foundation
   part's old `objects` section (§58, §346). A reply or event over the limit is made an object by that package through
@@ -179,7 +180,7 @@ line says so.*
 ### Readers, branches and the node-engine
 
 - §421 **The node-engine reads the catalog half for its branch.** The node-engine joins §196's readers: it reads the
-  manifests and verdicts of the modules it composes from the catalog half, of the branch each module's placement
+  catalog graph entries and verdicts of the modules it composes from the catalog half, never a manifest, of the branch each module's placement
   names, and the parts by digest from its want (§379); its reads of the indexer's and builder's states go. The tool
   runner follows every watched branch's newest `catalog-revision`, as §365. Why: ADR 0596 §2 (Q-H1, Q-H2, Q-T8). How it
   is checked: the node-engine's manifest reads no other module's state; test 61.
@@ -231,7 +232,7 @@ line says so.*
   replaced by its view of the catalog half (§344). Why: ADR 0596 §2 (C22). How it is checked: its manifest.
 - §434 **Findings name their owner and whom they wait on, and the keeper reads by events.** A finding of §33, §8 and
   §75 carries `owner` and `waiting-on`; the keeper's other reads are by events or verbs, and no homes rows are added.
-  Hand-written finding code in Go moves to mesh-sdk's `FindingWriter`. Why: the design's choice (C16, C17, C15's Go
+  Hand-written finding code in Go moves to the generated writer (§439). Why: the design's choice (C16, C17, C15's Go
   half). How it is checked: the code review; the keeper's manifest reads nothing.
 - §435 **`compose-candidate` goes with the checker.** The node-engine's verb `compose-candidate`, whose caller is the
   checker, is kept in G and removed in the change that removes the checker (§97), with the check's candidates. Why:
@@ -248,3 +249,32 @@ line says so.*
 - §438 **The record names every repository G builds.** Design 47's milestones row and frontmatter `code:` name
   mesh-tools and mesh-networking, and design 51's line on what a node-engine hears says it consumes the node-engine
   seat's `running` (§199). Why: the design's choice (Q-T1, Q-H11). How it is checked: the index test.
+
+### Lead-47's rulings on the four stopped items, and the operator's rule on manifests (2026-11-11)
+
+- §439 **The finding events' layout is a seat contract, and its writers are generated.** The bodies of
+  `finding-written`, `finding-cleared`, `findings-stated` and the finding's layout are defined in the seat
+  `mesh-conditions`' definition, beside `findings` and `findings-asked`; the seat generator (seatgen) generates the Go and
+  the TypeScript writers from it, so the forge module's TypeScript writer comes with it. mesh-sdk's `go/views` writer
+  takes the subject handed in by the seat's client and names no seat (§262). This amends §383 and §386. Why: lead-47's
+  ruling, 2026-11-11, on Q10, S6 and C15, one answer for the three. How it is checked: unit (seat generator), both
+  writers generated from the definition say the same bodies; whole (forge module), its writer says `finding-written`.
+- §440 **`process-builds` is a node-engine seat verb.** The read of the build each process was started with is the
+  seat `node-engine`'s verb `process-builds`, of class `read`, its callers by §391's default, since the node-engine
+  serves seat verbs and no module tools (§422). This amends §262 and test 48. Why: lead-47's ruling, 2026-11-11, on
+  Q11 and Q-H5. How it is checked: test 48; unit (definition reader), the verb's default callers.
+- §441 **The seat `mesh-grants` answers the grants a candidate composes.** The seat `mesh-grants` gains the read
+  `grants-for`: given a candidate change, the grants that the change's catalog graph composes, against the watched
+  branch's; its callers by §391's default. The running runner reads a change's grants for `widens` through it, and its
+  serving parts from the seat list by fingerprint (§71). This amends §401. Why: lead-47's ruling, 2026-11-11, on D15
+  and Q12. How it is checked: whole (grants part, runner), a change widening a grant names it in `widens` from
+  `grants-for`.
+- §442 **Only the indexer reads a manifest.** The indexer alone reads the manifests, to build the catalog graph; every
+  other part (the grants part, the condition keeper, the assigner, the runner, the tool runner, the node-engine, the
+  checks and the reviews) reads the catalog graph, the catalog half of the revision of the branch concerned (§196,
+  §421). This amends §50, §59, §89, §199, §249, §309, §386, §406 and §421, and the main file's node agent, its inputs
+  and the composition check. Why: the operator, 2026-11-11 about 03:05 CET at the terminal: "only the indexer uses the
+  manifest to build the module catalog". How it is checked: the catalog's validation finds no manifest read in any
+  module's code but the indexer's (code review), and the grants part's table test derives each grant from a catalog
+  graph fixture with no manifest.
+