Rewrite design 47 from research 055's decisions: hotfix, feature and epic from the trunk, delivery on the bus

ADR 0401-0408 graduate research 055: no release branch, two more ordering
rules, the composed check as each member's gate, a backup before the send,
installed toolchains, events and work queues on the bus, the merge window
as keys, and one chain kept on the bus alone. Design 47 is rewritten from
them (one design per thing); the glossary takes hotfix, feature, toolchain,
milestone and epic and retires release branch; design 18 loses the
toolchain image; playbooks 07 and 08 drop the release-branch wait.

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

@@ -121,32 +121,10 @@ 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, once the coast is clear**
-   (above). The integration tests
+1. **Push every feature branch and open one pull request per repository, together.**
+   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
@@ -202,7 +180,6 @@ 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` |
 
@@ -270,8 +247,6 @@ 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

@@ -39,8 +39,8 @@ 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, 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
+5. **Push once and open the pull request.** The trunk is what runs and nothing holds merged work back
+   (ADR 0401), so a fix waits for no other change's delivery. 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.