Issue 298 and ADR 0246: a seat's new verb is promised before it is required

Design 33 said a seat's verbs change additively, and section 3 made each
one a condition of holding, so a verb added in the controller and served
from the catalogue could land in neither order. It happened three times on
2026-10-07. Section 7 now says the three steps and how each is checked.

03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md

@@ -2,8 +2,9 @@
 layer: to-be
 status: implemented
 code: [mesh-controller, mesh-tools]
-updated: 2026-10-02
+updated: 2026-10-07
 decisions:
+  - 02-DECISIONS/0246-a-seats-new-verb-is-promised-before-it-is-required.md
   - 02-DECISIONS/0170-the-firewall-seat-serves-its-verbs.md
   - 02-DECISIONS/0179-the-intrusion-seat-serves-its-verbs-and-every-door-declares-its-jail.md
   - 02-DECISIONS/0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md
@@ -131,6 +132,24 @@ A seat's tools are an interface and change like one. Additive within a version.
 break a caller takes the version token the subject already has room for, and the two versions run side
 by side until nothing is bound to the old one.
 
+*Amended 2026-10-07 ([ADR 0246](../../02-DECISIONS/0246-a-seats-new-verb-is-promised-before-it-is-required.md),
+[issue 298](../../04-ISSUES/298-a-new-seat-verb-deadlocks-across-two-repositories/00-report.md)):*
+**additive takes two steps when the seat and its holder are in different repositories.** That is the
+case for every mesh seat whose holder is a catalogue module. §3 makes every promised verb a condition of
+holding, and a claim may name no verb the seat does not promise. So a verb added to the seat in the
+controller refuses today's holder, and a holder that serves it is refused by today's controller. Neither
+change can land first. An added verb therefore lands in three steps, each its own pull request:
+
+1. **The controller promises the verb as optional.** A holder that serves it is accepted, and one that
+   does not yet serve it still holds the seat. The mark comes from the seat as compiled, so a seat row
+   read back from the store keeps it.
+2. **Every holder serves it**, checked against a controller that already promises it.
+3. **The controller requires it.** The mark is removed, and the verb is a condition of holding like the
+   rest.
+
+A verb on a seat that nothing holds yet is required from the start. A change that breaks a caller is
+still a new version.
+
 ## How it is checked
 
 - **A holder missing a verb cannot take the seat.** One test per condition of holding, as the existing
@@ -142,6 +161,16 @@ by side until nothing is bound to the old one.
   answer equals what the seats declare — if it needed a module up, it would not be a read.
 - **Two nodes holding one node-scoped seat derive two addresses.** Checked by the same test as the rest
   of the subject table.
+- **An added verb lands in steps, and each step is checked (§7).** The controller's claim check refuses
+  a claim that serves a verb the seat does not promise, and a holder that misses a required verb. It runs
+  at registration, at handover, and in `module check`, which the catalogue's merge check runs over every
+  manifest with the controller the mesh runs. So a step out of order fails the pull request that took
+  it. That an optional verb stays optional when read back from the store is held by mesh-controller's
+  `TestAnOptionalVerbStaysOptionalInASetReadFromTheStore` (#114), and that a seat's row gains a verb's
+  new arguments by `TestASeatsVerbGainsTheArgumentsTheBinaryNames` (#114). Each added verb has its own
+  test that it is promised and not yet required: `TestTheDeliverySeatPromisesChecks` (#117) and
+  `TestFailedIsAnOptionalVerbOfTheServiceManager` (#114). **Not yet checked:** that step 3 happens. A
+  verb left optional binds no future holder ([issue 298](../../04-ISSUES/298-a-new-seat-verb-deadlocks-across-two-repositories/01-diagnosis.md)).
 
 ## What is built, 2026-09-30