Write the outside-cause wait whole in G-19, so develop builds one mechanism

Round 1 of the review found §705 patched per finding: the commonest cause
(a machine down by its own network or silence) was missed, the keeper's
silence, the race between a check and its condition, the wait's ends, its
event fields, its finding's telling and its tools were unwritten. §706 now
says them once, following ADR 0677; §705 points to it. §707 gives the
writer's own finding-refused to each bundle's key part, with the statement's
bundle, in place of the G-15 edit, since G-15 is at its size cap. The
glossary's waiting call moves below the kept call's Not: line.

Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ

00-META/glossary.md

@@ -294,13 +294,13 @@ controller and the store; for module assignment, by the seat `mesh-module-assign
   state, naming the callee, the verb and since when, and none while the callee's machine is away (§3); and it calls
   again on the callee's event saying its answer changed (§4). mesh-sdk carries its form (§7). A call not marked is
   made once and its fault said.
+  *Not:* ~~retried call~~ (hq)
 - **waiting call** — a module's call of a marked verb that the verb's holder keeps whole, with the caller the bus
   proved and its ask, until the operator's answer: on the Approve the holder runs it once, and it says the call's end
   (ran, declined, expired or refused) on its seat's event `gated-ended` to that caller alone (ADR 0676 §2, §3). The
   caller calls once and may not mark it safe to repeat; only its wait for the end is kept. Unlike a kept call, it is
   never called again.
   *Not:* ~~gated call~~ (hq)
-  *Not:* ~~retried call~~ (hq)
 - **the deprecated broker** — the lavinmq module. It was the mesh's bus and is not any more. It keeps
   running as an **ordinary provider** of the `amqp` provision, for modules that need a message broker
   of their own the way something needs a database

03-DESIGN/01-to-be/47-milestones/G-15-develop-answers-fifth.md

@@ -530,7 +530,8 @@ form only. A note that corrects a line of G-12 or G-14 is written in that line;
 
 ## Observers with more than one bundle, and the forge module's forms
 
-- §580 **Each finding kind belongs to one bundle, and a statement covers only its own kinds.** (§383, §384, §485)
+- §580 **Each finding kind belongs to one bundle, and a statement covers only its own kinds.** (§383, §384, §485;
+  the writer's own kind `finding-refused` and the statement's `bundle`: §707)
   A module whose bundles write one state `findings` (the forge module has four: its TypeScript tools, its Go package
   registry, its forge and its agent token) gives each finding kind to exactly one bundle. That bundle's mesh-sdk
   writer is made with the kinds it owns, and refuses a `write` or a `clear` of any other kind, naming it. Each bundle
@@ -538,16 +539,10 @@ form only. A note that corrects a line of G-12 or G-14 is written in that line;
   findings. Its `findings-stated` carries `kinds`, the kinds it states, and the writer's statement deletes only keys of
   those kinds. The keeper sets its view of that observer, node and set of kinds from the statement, and clears only
   conditions of those kinds that the statement does not name. A statement with no `kinds` (a writer of a part with
-  one bundle) covers every kind, as before. One kind is the writer's own and every bundle's: `finding-refused`, the
+  one bundle) covers every kind, as before. Why: a statement that deletes every key it does not state would clear
-  finding mesh-sdk's writer itself writes when it refuses a malformed key (design 73 knowledge §1a), keyed within its
+  another bundle's findings (develop question of the forge module's developer, GIT14). How it is checked: unit
-  bundle's own key part as `module.<observer>.<bundle>.<asked-key>.finding-refused`. Each bundle's writer owns it
-  within that part only: it writes and clears only `finding-refused` keys of its own bundle, a statement of a bundle
-  (with `kinds` or without) covers the `finding-refused` keys of that bundle and never another's, and the keeper
-  clears from that statement only the `finding-refused` conditions of that bundle it does not name. Why: a statement that deletes every key it does not state would clear
-  another bundle's findings (develop question of the forge module's developer, GIT14). A writer's refusal is that bundle's fault, so it is kept and cleared within that bundle's key part, and no other bundle's statement can clear it (the review of design 73, HE-W2R2-2). How it is checked: unit
   (writer, both languages), a statement with `kinds` deletes no key of another kind, and a write of another kind is
-  refused; a statement of bundle A leaves bundle B's `finding-refused` key; whole (keeper), two bundles' statements on
+  refused; whole (keeper), two bundles' statements on one node each keep the other's conditions open.
-  one node each keep the other's conditions open, a `finding-refused` of the other bundle among them.
 - §581 **A `seen` key's 30 days are judged on each step end, with no timer.** (§487) The forge module writes `at` in
   each `seen` key's value, the time of the `step-ended` that wrote it. On each `step-ended` it handles, and at its
   start, it deletes the `seen` keys whose `at` is more than 30 days old, at most 100 for each event, the oldest first,

03-DESIGN/01-to-be/47-milestones/G-18-fix-round-six-seven.md

@@ -18,7 +18,6 @@ decisions:
   - "ADR 0619"
   - "ADR 0618"
   - "ADR 0596"
-  - "ADR 0564"
   - "ADR 0595"
   - "ADR 0579"
   - "ADR 0573"
@@ -29,7 +28,6 @@ decisions:
   - "ADR 0286"
   - "ADR 0283"
   - "ADR 0259"
-  - "ADR 0241"
 ---
 
 # 47, milestone G: the fix round of batches 6 and 7
@@ -41,7 +39,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
 2026-11-11): the approval mark once no verb names its callers (the operator's answer of about 16:10 CET, §610); the
 keeper's snapshots, with the operator's answer O-7 of 20:22 CET (§681); the recovery module's verbs, the entries the
 node-engine keeps and the grants part's first composition (§682 to §684); the gate before a marked verb's running
-(§677, the operator's O-8); develop's D-16 to D-49, of internal form only; and the operator's O-9 (§705). The rounds' other fixes are written in the lines they correct.*
+(§677, the operator's O-8); develop's D-16 to D-49, of internal form only; and the operator's O-9 (§705, written whole in §706). The rounds' other fixes are written in the lines they correct.*
 
 ## The approval mark, with no named callers
 
@@ -534,56 +532,5 @@ node-engine keeps and the grants part's first composition (§682 to §684); the
 ## The operator's O-9: a delivery waits on another machine's network
 
 - §705 **A machine whose network names an outside cause holds the delivery there as a wait, not a failure.** (ADR
-  0241 §13, §16 to §21, §25 to §27; ADR 0564 §2, §3, §13; ADR 0596; the main file's *A failure is held on the canary and fixed forward*; §498, §633) The operator,
+  0677) The operator's answer O-9 of 2026-11-11 about 21:05 CET; the line is written whole in §706 (G-19), which
-  2026-11-11 about 21:05 CET at lead-47's terminal (O-9): a delivered module's own failing health check is the
+  replaces what stood here.
-  delivery's; but while the machine's network statement names an outside cause, the delivery waits on that machine,
-  says from the start what it waits on, judges again once the cause clears and goes on by itself, and after 30
-  minutes asks the operator to go on or count it as failed. Where the assigner judges a node's health after a want
-  moves (the canary rule and its hold):
-  - **An outside cause.** The node-engine only states the machine's network in its health report (ADR 0241 §13);
-    the watchman raises the network findings from every machine's report together (ADR 0241 §16 to §21, observed by
-    the watchman under ADR 0564 §2), and the condition keeper holds them as conditions, never held while a module is
-    delivered (ADR 0564 §13 (e)). Two of them name an outside cause for a machine M: `machine.M.<owner>.rewritten`
-    (or `machine.M.rewritten` when the file is no module's), M being the condition's subject `machine`, whose
-    `<owner>` is a module the delivery did not move there, or none (ADR 0241 §17, §25); and `machine.<x>.unreachable`
-    for another machine `<x>` whose subject `also` lists M, the machines that cannot reach `<x>` (ADR 0241 §19 to §21,
-    §25). When a module the delivery moved fails its health check on M, the assigner reads M's open conditions through
-    the seat `mesh-conditions`' verb `conditions` with `scope` `machine` and `machine` M, which answers each condition
-    whose subject's `machine` is M or whose `also` lists M (ADR 0564 §3), a kept call in its `invokes` (ADR 0668 §1);
-    it never reads the watchman's `findings` nor the keeper's state (ADR 0596). With such a condition open, the
-    failing check is no failure: the assigner holds that move as a wait, said at once on `mesh-wants`' `wait-held`
-    with `step` `delivery`, `node` M and `on` `rewritten:<owner>` (`rewritten` alone for no owner) or
-    `unreachable:<x>`, and writes the finding `delivery-waits-outside` (scope `delivery`, id `<node>.<module>`),
-    naming the cause by its condition's key. The read is made at the judging and not kept from events, because the
-    keeper says no event when only a condition's `also` changes (it says `condition-changed` for its severity,
-    resolver, silence and words), so a copy kept from the events could miss M joining an `unreachable`.
-  - **It goes on by itself.** The assigner's durable consumer of the seat `mesh-conditions`' event
-    `condition-cleared` (`mesh-conditions.condition-cleared` in its `consumes`; ADR 0564 §3) hears the cause's key
-    cleared, and the assigner judges the module's health on M again, reading M's conditions again as above: healthy,
-    the delivery goes on, `wait-ended` with `how` `cleared`; failing with another outside cause open, the wait stands,
-    said again on `wait-held` with its new `on`, its bound still counted from its first start; failing with none, it
-    is the delivery's failure, held as the canary rule has it. A `condition-cleared` of a key no wait names is
-    dropped. At its start the assigner judges each wait it holds again the same way, so a clearing heard by no
-    instance is not lost.
-  - **The bound and the ask.** Past `outside-wait-minutes` (a setting, §633, 30 unless set) from the wait's start,
-    the assigner asks the operator through `operatorchannelclient`, `about` `<node>.<module>.<fingerprint>`, with
-    two options, Go on (the module counted healthy there, so the delivery goes on, `how` `go-on`) and Count as
-    failed (held as the canary rule has it, `how` `failed`); the ask names the cause and since when; the wait stands
-    until the answer or the cause clears, which ends the ask. The finding clears when the wait ends.
-  - **What stays the delivery's or the machine's.** A `machine.M.<owner>.rewritten` whose `<owner>` the delivery
-    moved is that module's failure (ADR 0241 §26). A machine's own `machine.M.network` holds the machine as a whole:
-    no want moves to it until its `condition-cleared` is heard (ADR 0241 §27).
-
-  Why: the operator's answer O-9; ADR 0241 §25 had the wait with no bound, which this gives one and an ask, resting on
-  the record of the outside-cause wait (number to come; its draft is with lead-47), which changes ADR 0241 §25 and
-  keeps §26 and §27. The condition ids are the watchman's on mesh-delivery's main (its node-health findings) and
-  ADR 0241 §16's. How it is checked, as cases of the assigner's whole test (a fixture keeper answering `conditions`
-  and saying `condition-cleared`): a `machine.<x>.unreachable` whose `also` lists the delivering machine turning a
-  failing check into a wait, said at once with `on` `unreachable:<x>`, ended `cleared` and the delivery going on
-  when its `condition-cleared` is heard; one whose `also` does not list it leaving the failure the delivery's; one
-  that fails once cleared, with no other cause open, held as a failure; a second cause open at the clearing keeping
-  the wait with its new `on`; a restart of the assigner during a wait judging it again; past the setting the ask, Go
-  on ending `go-on` and Count as failed ending `failed`; a `rewritten` naming a moved module failing at once; a
-  machine's own `network` moving no want to it; unit (grants part), the assigner granted the verb `conditions` and
-  the event `condition-cleared` and no read of the watchman's `findings`.
-

03-DESIGN/01-to-be/47-milestones/G-19-outside-wait-and-refusals.md

@@ -0,0 +1,159 @@
+---
+layer: to-be
+status: in-progress
+design: 47
+milestone: G
+updated: 2026-11-11
+decisions:
+  - "ADR 0677"
+  - "ADR 0668"
+  - "ADR 0603"
+  - "ADR 0596"
+  - "ADR 0564"
+  - "ADR 0539"
+  - "ADR 0429"
+  - "ADR 0241"
+---
+
+# 47, milestone G: a delivery's wait on an outside cause, and the writer's own refusals
+
+One file of milestone G's part of [design 47](../47-delivery-from-commit-to-delivered.md); the part opens at
+[G.md](G.md). Its design lines are numbered across every file of the part and cited as "design 47 G §n".
+
+*§706 and §707 come from the review by architectural domain of lead-47's batch 8 (round 1, 2026-11-11 about 21:20
+CET). §706 writes the operator's O-9 whole, once, in place of §705: what counts as an outside cause, when it is
+judged, every way the wait ends, its event, its finding and its tools. §707 amends §580 for the finding writer's own
+refusals.*
+
+## A delivery's wait on an outside cause
+
+- §706 **A failing check on a machine whose network names an outside cause is a wait that ends by itself, and asks
+  the operator after 30 minutes.** (ADR 0677 §1 to §4; ADR 0241 §11, §13, §16 to §21, §25 to §27; ADR 0564 §2, §3,
+  §13; ADR 0596; ADR 0429 §6; ADR 0539 §18; ADR 0668 §1; ADR 0603 §11; §276, §461, §498, §512, §633, §700) The
+  operator, 2026-11-11 about 21:05 CET at lead-47's terminal (O-9): a delivered module's own failing health check is
+  the delivery's; while the machine's network names an outside cause, the delivery waits on that machine, says from
+  the start what it waits on, judges again once the cause clears and goes on by itself, and after 30 minutes asks the
+  operator to go on or count it as failed. Where the assigner judges a node's health after a want moves (the canary
+  rule and its hold, ADR 0429 §6, ADR 0539 §18), for a module the delivery moved to a machine M:
+  - **Where the causes are said.** The node-engine only states M's network in its health report (ADR 0241 §13). The
+    watchman, holding `mesh-watchdogs`, raises the network findings from every machine's report together (ADR 0241
+    §16 to §21, observed by it under ADR 0564 §2), and the condition keeper, holding `mesh-conditions`, holds them as
+    conditions, never held while a module is delivered (ADR 0564 §13 (e)). The assigner hears them only through the
+    seat `mesh-conditions`: its verb `conditions` and its events `condition-raised`, `condition-changed` and
+    `condition-cleared` (ADR 0564 §3), named in its `invokes` and `consumes`; it never reads the watchman's `findings`
+    nor the keeper's state (ADR 0596).
+  - **What counts as an outside cause for M**, read from a condition's `key`, `raised` and subject (`machine`,
+    `also`), the key being the only source of an owner (a finding has no owner field):
+    - `machine.M.<owner>.rewritten`, or `machine.M.rewritten` (a file of no module), whose `<owner>`, the key's
+      part between M and `rewritten`, is no module the delivery moved to M (ADR 0241 §17, §25; ADR 0677 §1);
+    - `machine.<x>.unreachable` for another machine `<x>` whose `also` lists M, the machines whose failing parts
+      point at `<x>` (ADR 0241 §19, §21, §25; ADR 0677 §1);
+    - `machine.<x>.network` or `machine.<x>.silent` for another machine `<x>` whose `also` lists M: when `<x>` is
+      down on the record by its own network or its silence, the watchman raises no `unreachable` for it and holds
+      M's failures toward it under `<x>` (ADR 0241 §20, §21). The watchman (mesh-delivery's
+      mesh-delivery-watchman) therefore lists in `also` of those two findings the machines whose failing parts point
+      at `<x>`, as it lists them on `unreachable`; today it names them only in the `network` finding's summary and
+      not at all on `silent`. A change of `also` rewrites the finding (ADR 0564 §2).
+
+    No other condition is one. A `machine.M.<owner>.rewritten` whose `<owner>` the delivery moved to M is that
+    module's failure (ADR 0241 §26; ADR 0677 §3), and M's own `machine.M.network` holds M as a whole (below); neither
+    takes this wait.
+  - **When it is judged.** When a moved module's check fails on M, the assigner reads M's open conditions through
+    `conditions` with `scope` `machine` and `machine` M, which answers each condition whose subject's `machine` is M
+    or whose `also` lists M (ADR 0564 §3), as a kept call (ADR 0668 §1). It is read at each judging, never kept as a
+    copy from the events, since the keeper says no event when only a condition's `also` changes (it says
+    `condition-changed` for a severity, a resolver, a silence or its words). With an outside cause open, the move
+    waits. With none open, the assigner settles: it holds its judgement for `outside-settle-seconds` (a setting,
+    §633, 90 unless set) from the failing check, judging again on each `condition-raised` whose subject's `machine`
+    is M or whose `also` lists M, since the node-engine states the failing check and the network in one report while
+    the condition rises only after the watchman's two looks and the keeper's take-in; past it with still none, the
+    failure is the delivery's, held as the canary rule has it. The settle says no `wait-held`; `assigner_waits` shows
+    it as `settling` with its end.
+  - **When the keeper does not answer.** While the read of `conditions` is unanswered, the move waits `on`
+    `conditions-unread`, said and bounded as below, and is judged when the kept call is answered. A module that holds
+    `mesh-conditions` itself, as the assignments name, is judged with no read: its failing check is its delivery's
+    failure after the settle, since the keeper cannot answer for its own failing check.
+  - **The wait.** The assigner holds that move as a wait, says `wait-held` on `mesh-wants` with `step` `outside` (a
+    value added to §498's list, apart from a dependent's `step: delivery`), `node` M, `module`, `fingerprint`, `on`
+    (`rewritten:<owner>`, `rewritten` for no owner, `unreachable:<x>`, `network:<x>`, `silent:<x>` or
+    `conditions-unread`), `bound` (`outside-wait-minutes`, a setting, §633, 30 unless set) and `clock-from`, the
+    wait's first start. When the wait stands on another cause, it says `wait-held` again with the new `on` and the
+    same `clock-from`, so the bound is never restarted (ADR 0677 §2). It writes, through mesh-sdk's finding writer
+    (§461), the finding `delivery-waits-outside` (scope `delivery`, id `<node>.<module>`), severity `warning`, its
+    summary naming the module, M and the cause by its condition's key, its `needs` "Nothing for you to do.": a
+    warning that needs nothing is not sent (design 45, the router's *When*), so the operator's one message is the ask
+    at the bound. The watchman writes no `delivery-waits` for `step: outside`, so no second condition rises for it.
+  - **Judged again.** A waiting move is judged again, reading M's conditions as above, on: the `condition-cleared`
+    of its cause's key; each `condition-raised` or `condition-changed` whose subject's `machine` is M or whose
+    `also` lists M; each change of that module's have on M; the kept call answered, for `conditions-unread`; and the
+    assigner's start, for every wait it holds. A `condition-cleared` of a key no wait names is dropped. M leaving an
+    `also` with nothing else changing says no event: it is heard at the next of these, or at the ask.
+  - **How it ends**, each said on `wait-ended` with its `how`, the finding cleared at once:
+    - `healthy`: the module runs healthy on M, the cause open or not; the delivery goes on.
+    - `cleared`: judged again after its cause cleared, healthy; the delivery goes on.
+    - another outside cause open at a judging: no end; the wait stands with the new `on` (above).
+    - `own-failure`: judged again failing with no outside cause open, after the settle; it is the delivery's
+      failure, and only then does the canary rule hold it (ADR 0677 §1).
+    - `go-on` or `failed`: the operator's answer to the ask (below), or a release by hand with that `how`.
+    - `replaced`: a newer want of that module on M replaces the waited one; its own move is judged afresh, and an
+      open ask is ended.
+  - **The bound and the ask.** Past `outside-wait-minutes` from `clock-from`, the assigner asks the operator through
+    `operatorchannelclient`, `about` `<node>.<module>.<fingerprint>`, naming the cause and since when, with two
+    options: Go on (the module counts healthy there by the operator's word, and the delivery goes on, `how` `go-on`)
+    and Count as failed (held as the canary rule has it, `how` `failed`) (ADR 0677 §2). It reads the answer from the
+    router's record of the ask under its own name, on §700's path, never from the decided event's body nor a
+    caller's word. The wait's end ends the ask. An ask that ends unanswered is raised again at once while the wait
+    stands. `how` `go-on` is recorded as such, so a Go on is never read as a passed health check.
+  - **M's own network.** A machine whose own `machine.M.network` is open is held as a whole: no want moves to it
+    until its `condition-cleared` is heard (ADR 0241 §27; ADR 0677 §3). The assigner keeps that set from its
+    consumer of the three events and from a read of `conditions` with `scope` `machine` at its start; while that
+    read is unanswered, wants move as if none were held, since the keeper is itself delivered by wants moving, and a
+    failing check there meets the judging above.
+  - **Its tools** (§276's row *delivery on an outside cause*): `assigner_waits` reads each outside wait, settle
+    included, with its module, M, fingerprint, cause key, `on`, `clock-from`, `bound`, its ask's id and its state;
+    `assigner_release` takes one with `how` `go-on`, `failed` or `rejudge` (judge it again now) and a `why`, class
+    `act`, its default, and writes the hand-act log of the seat `mesh-hand-acts` first (ADR 0603 §11).
+
+  Why: the operator's answer O-9 and ADR 0677; the review's round 1 asked the mechanism once and whole: the watchman
+  holds a machine's failures toward a machine down on the record under that machine (ADR 0241 §20), so the
+  commonest cause, a hub silent or its own network open, is a `network` or `silent` finding and needs M in its
+  `also`; the keeper says no event for `also` alone, so the read at each judging is the truth, and the settle covers
+  a condition rising after the check it explains. How it is checked, as cases of the assigner's whole test (a
+  fixture keeper answering `conditions` and saying its three events): an `unreachable` whose `also` lists M turns a
+  failing check into a wait said at once with `on` `unreachable:<x>`, `bound` and `clock-from`, and ends `cleared`
+  on its clearing; one whose `also` does not list M leaves the failure the delivery's; a hub silent and a hub whose
+  own network is open, each listing M, each end in a wait; an `unreachable` cleared as the hub's `network` rises
+  keeps the wait with `on` `network:<x>` and the same `clock-from`; a condition raised 30 s after the failing check
+  turns it into a wait within the settle, and none within 90 s is held as the delivery's failure; a wait judged
+  again failing with no cause open ends `own-failure`; the keeper silent waits `on`
+  `conditions-unread` and is judged when it answers; the keeper's own module failing is its failure with no read;
+  the module turning healthy with the cause open ends `healthy`; a newer want ends `replaced` and its ask; a restart
+  of the assigner judges each wait again; past the bound the ask, Go on ending `go-on`, Count as failed ending
+  `failed`, an unanswered ask raised again; a `rewritten` naming a moved module fails at once; M's own `network`
+  moves no want to M; `assigner_release` with each `how`, each in the hand-act log; the finding
+  `delivery-waits-outside` written as a warning that needs nothing and cleared at the end, and no `delivery-waits`
+  for it. Whole (watchman): a machine silent, and one whose own network is open, while two machines fail toward it,
+  each list both in `also`. Unit (grants part): the assigner granted `conditions` and the three events, and no read
+  of the watchman's `findings`.
+
+## The writer's own refusals, in every bundle
+
+- §707 **`finding-refused` is the one kind every bundle's writer owns, within its own bundle's key part.** (§383,
+  §384, §437, §461, §580; design 73 knowledge §1, §1a) §580 gives each finding kind to one bundle. One kind is the
+  writer's own: mesh-sdk's finding writer refuses a key it cannot compose (a scope outside the seat
+  `mesh-conditions`' set, an empty id, a kind or `ref` holding a dot, as design 73 knowledge §1 has it) and writes in
+  its stead, in the observer's own state `findings`, the finding of kind `finding-refused` (design 73 knowledge §1a),
+  keyed `module.<observer>.<bundle>.<asked-key-escaped>.finding-refused`, `<bundle>` the bundle's artifact `name` in
+  the manifest's `build`, and the asked key escaped as a key's name is (§73). A module with one bundle has that
+  bundle's name there too, so the form has no exception. Every bundle's writer owns that kind within its own key
+  part only: it writes and clears only `finding-refused` keys of its own bundle. `findings-stated` (§384, §437)
+  gains `bundle`, of the same form, beside `kinds`; a statement of a bundle, with `kinds` or without, covers the
+  `finding-refused` keys of that bundle and never another's, and the keeper clears from it only the
+  `finding-refused` conditions of that bundle it does not name. Every bundle of a module writes the one state
+  `findings` under the module's one account, so the bus grant cannot tell bundles apart: mesh-sdk's writer, made
+  with its bundle's name, is what keeps each to its own key part. Why: a refusal is that bundle's own fault, so no
+  other bundle's statement may clear it (the review of design 73, HE-W2R2-2; review round 1 of batch 8). How it is
+  checked: unit (writer, both languages), a refused key written as `finding-refused` under its bundle's key part,
+  escaped; a statement of bundle A leaves bundle B's `finding-refused` key; a writer refusing to write or clear
+  another bundle's `finding-refused`; unit (contracts), `findings-stated`'s `bundle` read; whole (keeper), two
+  bundles' statements on one node each keep the other's `finding-refused` condition open.

03-DESIGN/01-to-be/47-milestones/G-5-acting-parts-check-and-kept-data.md

@@ -170,7 +170,8 @@ names go, since every new acting part needed code changes elsewhere (research 08
   | composing | the assigner, holding a node's other wants until its new node-engine runs there (*Composing waits per node*) | `assigner_waits` | `assigner_release` |
   | checking | the check's first tier | `checker_first_tier` | its ask-again (*The check on the change's own acting parts*) |
   | delivery of a dependency (kinds 2, 4 and 6), from G's delivery | the assigner, holding a dependent's new version until `version-delivered` of its dependency's (§376) | `assigner_waits` | `assigner_release` (want it now), and `assigner_delivered_again` |
-  | pipeline, from G's delivery | the runner, holding the pipelines its new version is to run until it runs healthy | `runner_waits` | `runner_release` (run them with the running runner) |
+  | delivery on an outside cause, from G's delivery (§706) | the assigner, holding a moved module's failing check on a machine whose network names an outside cause | `assigner_waits` | `assigner_release` with `how` `go-on`, `failed` or `rejudge` |
+| pipeline, from G's delivery | the runner, holding the pipelines its new version is to run until it runs healthy | `runner_waits` | `runner_release` (run them with the running runner) |
 
   Each release writes the hand-act log of the seat `mesh-hand-acts`, with who released and why.
 - §277 **How it is checked.** Whole (assigner): a fixture seat declaring a rule, with a fixture holder, gets its edges with

03-DESIGN/01-to-be/47-milestones/G.md

@@ -102,5 +102,6 @@ The part is eighteen files, each read whole, its design lines numbered across th
 - [G-16-develop-answers-sixth](G-16-develop-answers-sixth.md): develop's sixth batch: the ledger's upkeep calls, the builder's publishes again and its read of a module's builds, one event of a node's capabilities, the object stores' caps, the gate's merge path from G's delivery, and the readers of a module's manifest (§587 to §594).
 - [G-17-develop-answers-seventh](G-17-develop-answers-seventh.md): develop's seventh batch: the operator's answers of 2026-11-11 15:14 to 15:42 CET (callers by class, the five parts' findings, the forge and image registry's other entries, the gate's kept data), how every part reads the catalog half per watched branch, and the refreshed build maps' questions (§610 to §676).
 - [G-18-fix-round-six-seven](G-18-fix-round-six-seven.md): the fix round of §587 to §676: the approval mark once no verb names its callers, the keeper's snapshots, the recovery module's verbs, the node-engine's kept entries, the gate before a marked verb's running, develop's D-16 to D-49, and a delivery's wait on another machine's network (§677 to §705).
+- [G-19-outside-wait-and-refusals](G-19-outside-wait-and-refusals.md): a delivery's wait on an outside cause, written whole once (§706, in place of §705), and the finding writer's own refusals in every bundle (§707, amending §580).
 
 Design 34's milestone [every-event](../34-milestones/every-event.md) and design 46's milestone [7-approval-mark](../46-milestones/7-approval-mark.md) ship in milestone G's release, built in its repositories beside G's lines (lead-47, 2026-11-11 15:30 CET); where one of their lines and a line of G differ, G's later line holds and the other is corrected in place (§624 to §626).