Merge pull request 'ADR 0254: correct what the fix covers after its review (progressive insight, issue 318)' (#210) from insight/0254-every-module-of-a-failed-send-gets-a-verdict into main

02-DECISIONS/0254-a-wait-for-a-persons-new-login-is-not-a-gates-failure-and-each-module-of-a-send-keeps-its-own-pass.md

@@ -97,6 +97,10 @@ anyway, since the unit that cannot run is what the gate names first.
    the machine's own manager, a unit in another account's manager, a unit whose manager is not said, an
    account *not in the group* or not read) is judged as before, and the module is not yet healthy. A
    resource still starting is not yet healthy, as before.
+
+   > **Narrowed — 2026-10-08.** Read with the dated correction under "What the gate cannot tell" in the
+   > consequences: only a move whose build puts an account in a group its previous build did not is
+   > excused, and what that costs while a login stays owed.
 2. **The gate passes a module that waits for a person, and carries the wait.** The reading counts as a
    pass. The verdict says the wait ("… and it waits for a person: relogin needed on the laptop: …"), in the
    plan, in the gate's record and in each carried build's verdict. Nothing is put back for it, so the group
@@ -119,6 +123,10 @@ anyway, since the unit that cannot run is what the gate names first.
    own", it is not put back, and the walk's note names it. What was found wanting is put back as ADR
    0236 §3 says, and the walk stops as ADR 0236 says.
 
+   > **Completed — 2026-10-08.** Read with the dated correction under "A failed send keeps the passes" in
+   > the consequences: a module found broken is put back at once, every module of a failed send leaves it
+   > with a verdict, and what that costs.
+
 ## Consequences
 
 - **Issue 318's walk passes.** The laptop's send passes after its three judgings, the lighting module's
@@ -137,6 +145,22 @@ anyway, since the unit that cannot run is what the gate names first.
   next machines. A unit that fails for a reason of its own is therefore said only after the login, as the
   module's own condition. A build that passed its gate is not put back by a later condition; a newer
   build or a person's push is the way.
+
+  > **Progressive insight — 2026-10-08.** This consequence described the first build of the fix
+  > (mesh-controller PR #142), and its review found it too wide. It said that while the relogin is pending
+  > every later build of the module is excused, and that the walk carries each of them on. Since
+  > mesh-controller PR #146 the wait excuses **only a move that puts an account in a group its previous
+  > build did not**. The controller reads that from the two builds' manifests, which it keeps, not from
+  > when the machine says the wait began: that time lives in the node-engine's memory, and its restart, a
+  > change of its words or a clock's skew would move it.
+  >
+  > **The cost, accepted:** while a login stays owed, a later build of the same module adds no group,
+  > so its wait is not excused. It fails at the gate's bound and is put back, and its walk holds the other
+  > walks behind it as issue 318 described, until the operator logs in again. The module's
+  > `relogin-needed` condition says what to do the whole time. And that later build stays marked failed at
+  > its gate after the login: the login does not bring it back. A newer build, or a person's push, is the
+  > way (ADR 0236 §3). The decision stands. What changed is what it covers.
+
 - **A failed send keeps the passes of its healthy modules only after the settle time, in the walk path.**
   In the walk of the builds waiting for a gate, a module that was healthy for the passes asked, at least
   the settle time after the send, keeps its pass when another module of the send fails. What still
@@ -145,6 +169,21 @@ anyway, since the unit that cannot run is what the gate names first.
   where the module the gate is kept on and the modules of its tier sent with it record no pass when the
   send fails. Those are left as before: on the machine, with no verdict, so other walks still wait for
   them. A walk that fails still stops, and the next one still waits for a person's release (ADR 0236).
+
+  > **Progressive insight — 2026-10-08.** The two gaps named above were closed by mesh-controller PR
+  > #146, from the review of the fix. A module found broken is marked failed and **put back at once**, in
+  > the judging that found it, so that no resend declares again a build a witness has just reverted. The
+  > send goes on judging the other modules: its verdict, failed, waits until each of them has its own, or
+  > until the gate's bound. A fault before the settle time no longer strands the modules beside it. **The
+  > cost:** putting a module back is a send to the machine, and the modules beside it may read not yet
+  > healthy while it applies, which starts their count of passes again. Late in the bound, that can push
+  > them past it, and they are put back with the send. In a plan's own tier path, the
+  > module the gate is kept on keeps its pass when it passed on its own, as the others of its tier already
+  > did. At the verdict, every module of a failed send has one: a pass if it passed on its own, otherwise it
+  > is put back with what failed. A pass is counted only the gate's spacing after the one before. Each
+  > carried build's verdict carries only its own wait. A provider waiting for a login lists the consumers
+  > held under it, and is urgent while any is. The decision stands: one verdict per send, and each module
+  > keeps its own pass.
 - **The gate's record grows three fields**: the per-module counts, the waits, and the modules that kept a
   pass. A plan written before them reads as having none.
 - **Rollout order**: the node-engine first, so that units name their account; then the controller.

03-DESIGN/01-to-be/48-a-module-says-how-it-is-healthy.md

@@ -168,13 +168,18 @@ account that is *relogin needed* (ADR 0252), and units of that module failing in
 that same account, read **waits for a person**: the build did what it should, and the operator has one
 step left. The reading counts as a pass and is carried in the verdict; nothing is put back for it, so the
 account group the build added stays. Anything else unhealthy of the module beside it is judged as above.
+Only a move that puts an account in a group its previous build did not is excused, as the controller reads
+it from the two builds' manifests. A later build sent while the login is still owed is judged as above, and
+fails at the bound until the operator logs in again.
 The node-engine names the account on every resource that runs in an account's own manager, which is how
 the controller tells such a unit from one that is broken.
 
 **Each module of a send keeps its own pass** (ADR 0254). A send is still judged as one, with one verdict.
 The gate also counts, per module, the judgings in a row that found it healthy or waiting for a person;
 when the send fails, a module whose count reached the passes asked keeps a pass, said "on its own", and is
-neither put back nor left as a move no gate has seen for every other walk to wait on.
+neither put back nor left as a move no gate has seen for every other walk to wait on. A module found broken
+is marked failed and put back at once, and the send's verdict waits until the modules beside it have their
+own, or the bound, so every module of a failed send leaves it with a verdict: its own pass, or put back.
 
 ## 6. A provider down is said once