Bring the branches up to the trunk before the try, and say the try at step 1's end runs the integration tests (review round 1)

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

@@ -148,10 +148,10 @@ never into the running one, unless it blocks the running one.
   its helper alone, and dropping the field from the request passed every test); `gofmt`, `go vet` and the whole unit suite stay green. **The tests are written from the issue's
   acceptance criteria**: one test or more per criterion at the level it names, each test's comment citing
   the criterion it proves by its label (`// 1118/AC2`), and no criterion left without its test; an integration criterion is a test
-  that compiles and waits for the check step. The integration tests (those that start a store, a bus or a
-  process) wait for the check step, where `mesh-controller.try` runs them first.
-- **No pull request is opened in this step. When every issue is committed, the lead pushes each feature branch
-  and tries it** (`mesh-controller.try`, as step 3 item 1 says), so the review reads the integration tests' real
+  that compiles and waits for the try at this step's end. The integration tests (those that start a store, a bus
+  or a process) are run first by that try, and again by the forge's merge check.
+- **No pull request is opened in this step. When every issue is committed, the lead brings each feature branch up
+  to the current trunk (fetch by name, then merge), pushes it and tries it** (`mesh-controller.try`, as step 3 item 1 says), so the review reads the integration tests' real
   results and judges none by reasoning (2026-10-19: a reviewer reasoned that a warning goes out at once, the
   router holds it 30 s, and the try after the review found it). A failed try goes back to the same fixing agent
   with its whole log, read as step 3 item 3 says, before the review starts. Never land on a red check: run the
@@ -162,7 +162,7 @@ never into the running one, unless it blocks the running one.
   is a numbered migration and the consolidated schema; Go only unless the context file says otherwise; never
   move another issue; **never run an integration test on the machine** (no `go test -tags integration`, no `merge-check.sh`,
   no store or bus started by hand): compile them with `go vet -tags integration ./...` and leave the running to
-  the check step, where `mesh-controller.try` runs them on the pushed branch. On 2026-10-17 three fixing agents ran them anyway, one for minutes on end, because the
+  the lead's try at the end of this step, where `mesh-controller.try` runs them on the pushed branch. On 2026-10-17 three fixing agents ran them anyway, one for minutes on end, because the
   brief only said they wait for the check (the operator). Report back in under 150 words: commits, tests added and that they failed first, the
   check results, anything you stopped on.
 - **An agent that finds the code differs from its context file stops and reports** (file:line); the lead
@@ -177,8 +177,8 @@ never into the running one, unless it blocks the running one.
 
 ## Step 2 — Review (one reviewer, larger model; at most 3 rounds, about 15 minutes)
 
-1. **Bring every feature branch up to the current trunk** (fetch by name, then merge), so the reviewed tree is
-   the tree that is pushed.
+1. **The reviewed tree is the tree that was tried**: every feature branch was brought up to the current trunk
+   before its push and try (step 1). A trunk that moved since is merged only in step 3, with that head tried again.
 2. **One reviewer reads every repository's local commits** together, against the context files and the
    decisions. **It is one agent, kept for the whole release** like the fixing agents: the lead continues it by
    its id for every later round, for the extra cycle after a failed check (step 3) and for its review record, so it