Playbooks 07 and 08: is the coast clear? Hold a push while a release branch in flight shares its files; the glossary's release branch

The operator, 2026-10-16: the file module waited for feature 57's release branch, which changes four of the
same controller files.

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

@@ -121,9 +121,32 @@ never into the running one, unless it blocks the running one.
    report, and the round does not wait for it. What a round asks is only what makes the change wrong against
    its issues and its decisions.
 
+## Is the coast clear?
+
+Before the push of phase 3 (and of a small fix, playbook [08](08-small-fixes.md) step 5), the lead checks, for every
+repository the change touches, whether a **release branch** is in flight there: a branch other than `main` that
+collects a feature's merged work to bring it into `main` as one delivery.
+
+1. **Look for one.** A pull request into `main` whose head is a release branch (`gitea.gitea_open_pulls`), a
+   release branch holding merged work that `main` does not have yet (`git log origin/main..origin/<branch>`), or
+   a delivery plan of that release branch still running (`mesh-controller.plans`).
+2. **Compare the files.** `git diff --name-only origin/main...origin/<release branch>` against the files the
+   change touches.
+3. **Overlap: hold.** If the release branch touches a file the change touches, nothing is pushed into that repository
+   until the release branch's delivery plan is done. Then the feature branch is brought up to the new `main`, the unit
+   tests run again, and the push follows. The hold is on the wait list (its bound: the release branch's delivery plan),
+   and is said to the operator with what the change waits for.
+4. **No overlap: go on.** A release branch in another repository, or one that shares no file with the change, does not
+   hold it; its merge joins the merge window as any other (ADR 0276).
+
+Merging beside a release branch still in flight would make its lead resolve someone else's conflicts in the
+middle of it, and could send part of the change with its delivery (2026-10-16: the file module's
+controller part touched four files feature 57's release branch also changed).
+
 ## Phase 3 — Check (no review)
 
-1. **Push every feature branch and open one pull request per repository, together.** The integration tests
+1. **Push every feature branch and open one pull request per repository, together, once the coast is clear**
+   (above). The integration tests
    run only in the merge check (the operator, 2026-10-16), never before. Pull requests in two or
    more repositories that share the branch name are one delivery group (ADR 0239 §2).
    Where a session pushes through the forge tool `gitea_commit` (one commit on the forge's current base), the
@@ -178,6 +201,7 @@ on, with when it started and its bound.
 | the review | 15 minutes a round | ask the reviewer; stop at round 3 |
 | a merge check | 15 minutes | read the build queue (`mesh-controller.queue`) and the check's log |
 | the ready mark | 15 minutes after the acceptance is shown | the reviewer marks it, or the lead does |
+| a release branch in flight that shares files | its delivery plan done | report it every ten minutes; bring the branch up to `main` after |
 | a merge after ready | 5 minutes after the checks pass | read `mesh-delivery.show` for the delivery |
 | a delivery plan | its class's budget (`mesh-delivery.times`), at most 30 minutes | read `mesh-controller.plans`, then `mesh-delivery.stalled` |
 
@@ -242,6 +266,8 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
   review rules; `issue-tracker.list` with `flag: abandoned` lists issues left in `fixing` with nobody on them.
 - A pull request reviewed and green but not marked ready for more than 15 minutes is a lead that did not
   mark it.
+- A pull request opened into a repository whose release branch was in flight and shared a file with it is the failure of
+  *Is the coast clear?*; the lead's report names the check it made before the push.
 - A step that adds or changes a module marked ready with no integration test that starts the module whole is
   the failure of phase 3's fourth step.
 - A bed run from `.work/<slug>/mesh-lab` that fails naming a `.work/<slug>/<repo>/…` path it cannot find is a

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

@@ -35,7 +35,9 @@ one delivery**. Everything before the push is local and fast.
    done-when is opened as an issue of its own, never asked as a change). The reviewer's findings go back to the same agent that wrote the fix, continued by
    its id, so the fix keeps its context. A playbook or design edit of a few lines may skip the reviewer: the
    operator's word on the pull request is its review, and the lead marks it ready on that word.
-5. **Push once and open the pull request.** The forge's merge check runs the integration tests, the only
+5. **Push once and open the pull request, once the coast is clear** (playbook [07](07-feature-branches.md), *Is
+   the coast clear?*: no release branch in flight in the repository that shares a file with the fix). The forge's merge
+   check runs the integration tests, the only
    place they run (the operator, 2026-10-16). A failed check
    goes back to the same agent with the failure, and the reviewer reads only the change it makes.
 6. **The reviewer marks it ready at once** (for an edit that skipped the reviewer, the lead, on the