Design pass: address the review

0113 — the plaintext claim was false under its own mechanism: handing a provider's answer to the
controller puts every secret on the broker and in the controller in the clear. The provider now seals
each secret field itself, to the consumer node's public key the mesh hands it, and the controller
carries sealed fields it cannot open. That is stricter than today, where the controller holds every
minted credential in the clear. Option 3 (plaintext to the controller) is recorded and rejected. The
foundation exception now covers root-secret rotation (0085) and forms like the broker admin's hash, so
no phase claims to remove the broker's bootstrap step. To-be 24 and 13 are named among what it amends.

27 — resolution is consistent with 0110: co-location and the only provider apply only where no seat
delivers the provision, so an unheld seat is refused even with one provider. The secret-field rule now
matches 0086 exactly (a declared env-file, never a container environment value). The seat placeholder
is the controller's, and the one module reading it moves to a host port. Contracts are held by the
controller and written down in phase 1, so they can be checked; every rule has a check. An operator's
secret is still the operator's, with the vault as custodian. Which seats a module holds is listed as
not settled.

0110 — the unheld-seat-with-one-provider case and the one-answer-for-everyone rule have checks; the
claim about moved manifests is corrected. 26 — the table governs and the code catches up, not the
reverse; scope and capacity agree with the glossary; moving a seat is described as it really is today.
0112 — aligned with 27, and lists 0049 and 26 among what it changes.

Issue 118 is renumbered 119: another branch took 118 first. 'Control-plane' is gone from 0110 and 0111.

03-DESIGN/01-to-be/26-the-seats.md

@@ -28,7 +28,7 @@ A seat has four properties, fixed by the mesh rather than by any module:
 | property | is |
 |---|---|
 | name | what a manifest claims, and what a person reads in the list |
-| scope | node, site or mesh: where there may be only one holder |
+| scope | node, site or mesh: where its capacity applies. Every seat in the set has a capacity of one, so one holder per scope. A bench, a seat with several holders, is a word the glossary keeps and no seat uses yet |
 | delivers | the provision its holder answers for, or nothing |
 | decision | the record that made it a seat |
 
@@ -63,8 +63,10 @@ argued for is an entry nobody can explain.
 | `the-showcase` | node | — | the showcase module |
 
 The controller holds this set in code, and a test asserts both its size and that every entry names
-the record that made it a seat. This document follows the code, not the reverse. If the two disagree,
-the test has been changed without this table, and the table is what is wrong.
+the record that made it a seat. **This table and [ADR 0110](../../02-DECISIONS/0110-a-seat-is-a-module-assignment-from-a-closed-set.md)
+govern, and code that disagrees is what is wrong.** The implementation in progress predates two
+things here: the `mesh-vault` seat, and the rule that `mesh-store` and `mesh-broker` deliver
+nothing. It is brought to this table before it merges.
 
 ## A seat that delivers a provision
 
@@ -89,14 +91,22 @@ one is the mesh's, and co-location answering first would let any second provider
 machine take over for that consumer, silently. So a second provider can run beside the holder and
 harm nothing. The forge holds
 `npm-package-registry`. An npm proxy may provide the same provision on another machine, and a module
-requiring an npm registry is still served by the forge, without anybody pinning it. Moving the role
-to the proxy is moving the seat: unassign the claim from one, assign it to the other, and every
-consumer follows.
+requiring an npm registry is still served by the forge, without anybody pinning it.
+
+**Moving the role is changing which module claims the seat, and today that is a definition change.**
+A claim is part of a module's definition, so the proxy's definition must claim the seat and the
+forge's must stop. The forge cannot simply be unassigned, because it holds `git` as well. Every
+consumer follows once the claim moves. Making *which* seats a module holds the assignment's choice,
+with the definition saying only which seats it *can* hold, is the consistent answer, and
+[27 — A module requires, the mesh resolves](27-a-module-requires-the-mesh-resolves.md) lists it as
+not yet settled.
 
 **What a consumer receives is a grant**, the same as for any provision: where the provider answers,
-what it serves, and a credential where one is minted. A consumer never reads the seat directly. The
-one exception is the controller itself, which reaches the store and the broker through a narrow
-seat placeholder because it made them before any module existed and cannot be their consumer.
+what it serves, and a credential. A consumer never reads the seat directly. The one exception is the
+controller itself, which reaches the store and the broker through a narrow seat placeholder,
+because it made them before any module existed and cannot be their consumer. One foundation module
+also reads it today, to find its own server's port. [27](27-a-module-requires-the-mesh-resolves.md)
+moves that to a host port requirement.
 
 ## A seat that delivers nothing