Design 32: answer the first review (the checker invokes renames and waits for it, retire's caller list and warrant, retired events, tests, the away node's window)

Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
2026-11-04 00:10:57 +01:00
parent 4710fd18c6
commit 3b1278b3bc
1 changed files with 22 additions and 3 deletions
@@ -515,7 +515,10 @@ value it holds under the old name to the new name in its own state, without the
 - **How long the old name is read** (the **rename window**): until every node-engine whose node has a want of the
  module reports applied a build of it that reads the new name. mesh-config hears the status view's `delivered`
  events and, at its start and on each, asks its `node_haves` for every node, away ones included, since `delivered`
-  counts only the nodes present (design 47); until then mesh-config answers both names. A node holding a window open
+  counts only the nodes present (design 47); until then mesh-config answers both names. A node away when the last
+  `delivered` was said should close its window when it returns, with no other delivery; the event that says its
+  return is not yet named, as for the old seat name (design 51), and until it is the window waits on the next
+  `delivered`, tracked on issue 1966. A node holding a window open
  for seven days is mesh-config's finding naming the node, cleared when the window closes; `config_rename_close`
  drops a node from a window by hand, recorded as a hand act.
 - **The checker asks the seat, never the module.** The seat `mesh-config` gains the optional verb `renames` (the
@@ -524,7 +527,11 @@ value it holds under the old name to the new name in its own state, without the
  naming the verb, and the checker then refuses `renamed-from` naming that; while a window is open, the same answer
  refuses dropping `renamed-from`, naming the nodes. A check that cannot ask fails, and says so. So no manifest uses
  `renamed-from` in the milestone that brings it, whose running mesh-config serves no `renames`; the first that does
-  is its live case. `config_renames` names, per rename, the nodes still holding the old name open.
+  is its live case. The checker declares `seat:mesh-config.renames` in its `invokes`, so by the served-verb edge
+  (ADR 0614 §2) its new build waits until a build of mesh-config that serves `renames` runs healthy; no cycle closes,
+  since mesh-config waits only on the indexer's `indexer_config_readers`. The "not served" answer is then met only by
+  the running checker in the milestone's own check, and after a revert. `config_renames` names, per rename, the nodes
+  still holding the old name open.
 - **A refused move** (the old name holds nothing, or a secret) is mesh-config's finding, from which the condition keeper
  raises the condition, cleared once the value moved or `renamed-from` left the trunk's manifest. **Tools of
  mesh-config**: `config_renames` (what moved, from which name, when), `config_rename_again` (move one value by hand
@@ -542,7 +549,11 @@ kept seven days) and asks the operator once, through the operator channel, wheth
 still read it until lately; it is removed only on the operator's Approve. **mesh-config holds no secret**, so the
 retiring flow and its one ask stay mesh-config's, and on the Approve it removes a value itself and retires a secret
 through the seat `mesh-vault`'s new optional verb `retire` (one module's own secret, by node, module and name), carrying
-the operator's warrant, which the vault checks (ADR 0259 §6) before it removes anything. An ask unanswered for seven
+the operator's warrant, which the vault checks (ADR 0259 §6) before it removes anything. The vault's caller list for
+`retire`, a trusted config value in ADR 0363's form, names the holder of the seat `mesh-config` alone, checked against
+the caller the tool runner proved; the warrant is bound to the node, module and name it was asked for, so it retires
+nothing else. mesh-config then emits `retired` on `config.events` (module, name, node, the ask), and the vault its own
+event that it removed the secret. An ask unanswered for seven
 days is asked once more, and then written as a finding, cleared by an answer, a cancel, or the value read again; a
 sleeping node holding a retirement open for seven days is a finding naming it. `config_retiring` lists what is
 retiring, since when, and its ask, and asks it again or cancels it.
@@ -553,6 +564,14 @@ declared in its old `state` and `streams` sections in this milestone, as the bui
 process, which is delivered in the same milestone. They move to bus state when each module next moves (ADR 0595 §11).
 `config-changed` stays on the shared events stream, unchanged, so its consumers do not move.

+**How the rename and the retiring are checked**, as cases of mesh-config's first whole-module integration test (C20,
+C24 below), of the checker's and of the vault's existing whole-module tests: the checker's ask of `renames` meeting a
+holder that does not serve it refuses `renamed-from` naming the verb, one meeting an open window refuses dropping
+`renamed-from` naming the nodes, and a check that cannot ask fails saying so; `retire` with the warrant removes the
+secret and emits both events, without it, with a warrant for another name, or from a caller not on the list it is
+refused; `config_rename_close` drops a node from a window and records the hand act; a window held seven days and a
+retirement held seven days each write their finding naming the node, cleared when it closes.
+
 ### The mesh delivery cases this design carries

 Research 081 listed the mesh delivery cases; these are the ones it handed to a design, each with its acceptance test,