Playbooks 07 and 08: open a dependent pull request only after delivery, fold a follow-up into the unapproved one, search every instance of a fault kind

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

@@ -261,6 +261,12 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    further case, a nicer form: the reviewer opens it with `issue-tracker.open` and names the number in its
    report, and the round does not wait for it. What a round asks is only what makes the change wrong against
    its issues, their acceptance criteria and its decisions.
+7a. **At the second instance of a fault kind in a review, the developer searches for every instance and names each in the
+   report.** On 2026-10-25 a "busy, return at once" guard that dropped a newer request was found in three places,
+   one review after another. The developer writes the kind in one line, searches the repository (`git grep`) for
+   its shape, fixes every hit in one change and lists each file and line in the report. How it is checked: a
+   report to the second round naming a kind and one place only, followed by a third round on the same kind, is
+   this rule skipped.
 8. **A timer that writes state, or a rule fixed in code that overrides what a person sets, makes the change
    wrong.** The mesh is NATS-native: a part says what happened as an event and acts on events; nothing polls
    and rewrites state on an interval, and a policy the operator can change is a setting the module declares,
@@ -349,6 +355,16 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    the Approve and the merge, and wakes the lead. Beyond that
    Approve, the operator's word is waited for only when the milestone changes what the operator sees, removes
    data, or needs a step only the operator's terminal can take; the lead says which before the milestone starts.
+   **A pull request that depends on an earlier one is opened only once the earlier one is delivered**, its build
+   running on every machine it should reach, not merely merged. A note in the description is no safeguard: the
+   operator's Approve merges whatever is asked. On 2026-10-25 a second change merged before the first was delivered
+   and machines lost modules. How it is checked: `mesh-delivery.deliveries` shows the earlier change's source
+   revision `delivered` before the later pull request exists (`gitea.gitea_get_pull_request`, its creation time);
+   a later one older than that is this rule skipped.
+   **A reviewed follow-up to a change the operator has not yet approved is folded into that pull request** (its head
+   moved to include it): one Approve, one delivery. The old Approve ask closes itself on the new head and the new
+   head is asked once its checks pass. How it is checked: a follow-up that sits in a second pull request while the
+   first still waits shows in `gitea.gitea_list_pull_requests` as two open pull requests of one lead.
 
 **One exception: a catalogue change that uses a new manifest word.** The catalogue's merge check reads
 manifests with the controller the mesh runs, so the controller's pull request is merged and delivered first;

00-META/process/08-small-fixes.md

@@ -76,6 +76,13 @@ one delivery**. Everything before the try is local and fast.
    integration test starting the module whole against the real bus and store, run by `mesh-controller.try` and the checker's merge check
    (ADR 0391 §1, §6); unit tests alone are not that proof, and the lab is not used. The operator's word is waited for only when the fix changes what the operator sees, removes data,
    or needs the operator's terminal.
+   **A fix that depends on another pull request opens only once that one is delivered**, not merely merged (a note
+   in the description does not hold it back: the Approve merges whatever is asked; 2026-10-25, machines lost modules
+   when a second change merged first). **A reviewed follow-up to a fix still waiting for the Approve is folded into
+   that pull request** (head moved): one Approve, one delivery. Both are checked as playbook
+   [07](07-feature-branches.md) step 3 says.
+   **At the second instance of a fault kind found in a review, the developer searches for every instance** and names
+   each in the report (playbook [07](07-feature-branches.md) step 2, item 7a).
 7. **Follow its delivery to done**: a watcher waits on the status view's events (`mesh-delivery-view.moving`,
    `.settled`, `.stuck` and `.delivered`) and reads the view's `assigner_wants` and `node_haves` after each wake, as
    playbook [07](07-feature-branches.md) step 4 says; the delivery is done when the view says `delivered` for its