ADR 0083: the cascade compares against what was last sent, not a snapshot

02-DECISIONS/0083-one-push-leaves-the-mesh-consistent.md

@@ -23,15 +23,22 @@ changed — or **report** — a push says "now push the provider" and leaves the
 
 ## Decision
 
-A push finishes what it starts: after composing and sending the named node, the controller
-recomputes what every machine should be, and any machine whose declaration changed *because of
-this push* is sent its declaration too — by name, in the push's own output, converging over a
-bounded number of rounds (a cascaded send may itself mint).
+A push finishes what it starts: after composing and sending the named node, the controller flushes
+every *other* machine that is now behind — whose declaration differs from what it was last sent —
+by name, in the push's own output, converging over a bounded number of rounds (a flushed send may
+itself mint).
 
-"Changed because of this push" is a comparison, not a guess: the digest of what each machine
-should be is captured before the named compose and recomputed after. Machines that were already
-behind for unrelated reasons are not swept in — that remains `push --behind`, the explicit
-whole-mesh reconcile.
+Behind is measured against what a machine was last *sent*, not against a before/after snapshot of
+this push. The mint that makes a provider behind happens when the consumer is assigned or its
+account issued — before `push` runs at all — so by push time the provider already differs from
+what it holds, with no in-command delta to detect. The only durable signal is "what it should be"
+versus "what it last received", which is the same comparison `push --behind` already makes.
+
+A machine behind for an unrelated reason is flushed by this too, and that is correct rather than a
+cost: a named push that knew a machine was behind and left it so would be the very silence this
+decision removes. The narrower reading — flush only what this push provably changed — was
+rejected because it cannot see a mint that a prior command performed, which is precisely the 057
+case.
 
 Reporting alone was rejected because it converts a derived fact the controller already holds into
 an operator obligation, and an obligation enforced by nothing is issue 057 restated. The
@@ -43,10 +50,10 @@ merely saying so would make "push succeeded" mean less than it says.
 - One push is sufficient for a cross-node consumer: the provider's grants arrive from the same
   act that minted the provision. The undocumented rule "push the provider node too" ceases to
   exist rather than becoming documentation.
-- A named push may deliver to machines the operator did not name. This is bounded to machines
-  whose declarations this push changed, and every one is named in the output — never silent.
-- The blast radius question from the issue is answered by the comparison: nothing is recomposed
-  into delivery except what the named compose provably changed.
+- A named push delivers to every machine that is behind, not only the one named — each named in
+  the output, never silent. `push --behind` remains the way to reconcile the mesh without naming
+  a node; a named push now carries the same guarantee for the machines its work touched and any
+  others already waiting.
 - How this is checked: the built-store-cross-node bed registers a cross-node consumer, pushes
   only the consumer's node, and asserts the provider minted its vhost — the workaround push is
   removed, so a regression fails the bed.