From 3b1278b3bcf743ee25cf3914416b9764de02a409 Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 4 Nov 2026 00:10:57 +0100 Subject: [PATCH] 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 --- .../01-to-be/32-what-a-module-declares.md | 25 ++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/03-DESIGN/01-to-be/32-what-a-module-declares.md b/03-DESIGN/01-to-be/32-what-a-module-declares.md index 6b2b1689..aca771d2 100644 --- a/03-DESIGN/01-to-be/32-what-a-module-declares.md +++ b/03-DESIGN/01-to-be/32-what-a-module-declares.md @@ -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,