Say in to-be 47 what ADR 0323 leaves as it is, and give to-be 45's revision its own paragraph

The review asked that the trunk-less verdicts, mesh-delivery's trunk head, the
refuse-ask race and the lost check's recheck be said, and found the revision
spliced mid-paragraph.

03-DESIGN/01-to-be/45-a-core-that-cannot-fail-silently.md

@@ -672,7 +672,12 @@ R310). A repository with none has "no repository
 check defined", a success where the branch does not require `mesh/repo-check` and a failure for a person
 where it does. **A note is never a warning on a required status**: the forge combines `warning` as a
 failure, so a note — a wide rebuild, a problem already so on the base — is a success that says it, and only
-what a person must decide fails (issue 293; checked by the forge module's status tests). 
+what a person must decide fails (issue 293; checked by the forge module's status tests). The
+check's result is the commit's **delivery plan** — the build plan, the deploy plan machine by machine with
+what is not an ordinary send, and the verdict — posted on the pull request. The plan is one object with
+a state machine, kept, followed by the release and written to the commit as a note; which parts are built
+is Phase 5's.
+
 Revision, ADR 0323 (2026-10-12). **The gate judges what merging makes, not the head.** The build seat takes
 the trunk the pull request merges into, its head at that moment as the check's **trunk commit**, and makes in
 its own clone the merge of the head into it, as the forge's default merge would; both layers judge that
@@ -684,11 +689,7 @@ trunk moves, the forge's holder puts both statuses of every open pull request in
 the reason and runs nothing; the merge tool refuses a verdict whose trunk commit is not the trunk's head,
 asks that head's check once, says how long the last check of the repository took, and never merges by
 itself (checked by the builder's `TestReplay341`, replayed as R341, and the forge module's `trunk` and
-`guard` tests). The
-check's result is the commit's **delivery plan** — the build plan, the deploy plan machine by machine with
-what is not an ordinary send, and the verdict — posted on the pull request. The plan is one object with
-a state machine, kept, followed by the release and written to the commit as a note; which parts are built
-is Phase 5's.
+`guard` tests).
 
 **The replays.** mesh-lab carries a scripted scenario for each core incident, asserting the rule's
 outcome, run on every merge to mesh-controller, `mesh-host` and mesh-tools:

03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md

@@ -100,6 +100,22 @@ of date. Nothing is asked for it: a recheck, a new head or the merge tool asks t
 an older trunk is kept and shown and does not count, and the rows reach a fixed point. Checked by
 mesh-delivery's `TestATrunkMoveSendsAReadyDeliveryBackToProposed` and the table's own walk.
 
+What this leaves as it is, said so nobody reads more into it:
+
+- **mesh-delivery's trunk head is the last merge it heard** into that trunk while the delivery was open. A push
+  to the trunk that is not a merge it hears does not move it; the forge's holder, which reads the branch, and
+  the merge tool, which compares commits when asked, still catch it.
+- **A verdict that names no trunk commit**, from a build seat older than ADR 0323, counts in mesh-delivery as it
+  did: such a delivery stays `ready`. The forge reads the same verdict out of date once its trunk moves, and the
+  merge tool refuses it and asks the check. The two agree once the head is judged again.
+- **A verdict no build judges** (a change that touches no module, in a repository with no `merge-check.sh` or
+  not the mesh's) names the base branch's head the forge announced with the head as its trunk commit.
+- **In a busy repository the merge tool can refuse, ask, and refuse again**: another merge may move the trunk
+  while the asked check runs, and the new verdict is then out of date too. Each refusal asks once more; the
+  merge goes through once a check finishes before the next merge.
+- **A check that was asked and never answers** is listed by `stalled` an hour after the ask, and is asked again
+  with `mesh-delivery.recheck`, which the merge tool's refusal names.
+
 The transitions are those of ADR 0239 decision 2, ADR 0270 and ADR 0323. A delivery that is
 merged while not `ready` goes to `held`. Its check did not pass, and only a person decides that it goes on. A
 delivery merged with no walk answering it within ten minutes is held too, with the true reason, and listed by