Read a hand push's plan first, and assign a new module to one machine first, from the night's build-module faults

00-META/process/07-feature-branches.md

@@ -299,6 +299,20 @@ the merge's plan started first, the chosen Retry was refused and nobody asked it
 never tells the operator to answer a Retry while an Approve is open, and reads the failed plan again after the
 answer: a Retry refused is asked again once the other plan ends.
 
+**A push by hand is read from its plan first.** `mesh-controller.push` sends a machine everything it is owed, not
+only what the lead changed: on 2026-10-21 a push of the control node to tell the bus of two new accounts also moved
+mail's module to a build its upgrade policy holds for a person's word, and recreated one of its containers. Before
+every push by hand, the lead reads `mesh-controller.plan` with `diff` for that machine, and for the machine holding
+the bus when a push issues accounts, and pushes only when the plan names what the lead means to change.
+
+**A new module's first assignment is its first real composition.** The merge gate composes every machine as it is
+assigned, so a module that no machine runs yet is composed by no check: on 2026-10-21 the build modules' first
+assignment found two faults no merge check could see (issue 1537, a template the controller filled for a value the
+forge serves only later; issue 1542, the node-engine refusing the module's own `.ssh`). So a new module is assigned
+to one machine first, its plan read before the push and its apply read after it (`mesh-controller.node`: the
+answer, and `status` for a failed resource), and taken back at once when that machine cannot compose or apply, so
+the machine keeps applying everything else; the other machines follow once it runs there.
+
 ## Models
 
 | Who | Model | Why |