Show the report's issues as a tree, and keep the agent's brief, the red-check rule and the forge-commit check, in playbook 07

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

@@ -75,7 +75,14 @@ never into the running one, unless it blocks the running one.
 - **Unit tests only.** Each issue's first test fails before its change and passes after; `gofmt`, `go vet`
   and the repository's unit tests stay green. The integration tests (`merge-check.sh` with the store and the
   bus) wait for phase 3.
-- **Nothing is pushed** and no pull request is opened in this phase.
+- **Nothing is pushed** and no pull request is opened in this phase. Never land on a red check: run the
+  checks, read the result, then land in a separate step.
+- **The fixing agent's brief** (the lead gives it with the context file): name your issue in every step and
+  message ("issue 805: landing in mesh-catalog"); reach the mesh only through the mesh MCP server, never ssh;
+  never push, open, merge or close a pull request; never write to a store's database by hand, a schema change
+  is a numbered migration and the consolidated schema; Go only unless the context file says otherwise; never
+  move another issue. 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
   settles it, updates the context file, and continues the agent.
 - **Two repositories that depend on each other** keep their order in the context files: the reader before the
@@ -103,6 +110,8 @@ never into the running one, unless it blocks the running one.
 
 1. **Push every feature branch and open one pull request per repository, together.** 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
+   reviewer first confirms that commit's tree equals the reviewed one.
 2. **The forge's merge checks run the integration tests once** (`mesh/merge-gate`, `mesh/repo-check`). No
    second review: phase 2 reviewed this tree.
 3. **A check that fails** goes back to the reviewer with the failure, for **one more cycle** of phase 2 with
@@ -152,17 +161,20 @@ on, with when it started and its bound.
 one of the two layouts below. Times are local and absolute; every number has its unit and its bound or
 baseline; an issue is named by its number and a few words, never by its number alone.
 
-**The full layout** (in the session):
+**The full layout** (in the session), the issues as a tree: grouped by repository, each issue under the one it
+waits for, marked ✓ landed, ▶ fixing, ⏸ waiting, ✗ stopped:
 
 ```
 Feature <slug> · step <n> of <m> · phase <name>, <minutes used> of <bound> min
 Issues: <landed> of <total> landed · <fixing> fixing · <waiting> waiting
 
-| Issue | What | Repository | State | Since | Bound |
-|---|---|---|---|---|---|
-| 652 | assignments on the bus | mesh-controller | landed | 14:02 | |
-| 736 | placement words leave the layers | mesh-controller | fixing, 23 min | 13:51 | 30 min |
-| 751 | config keys named | mesh-catalog | waits for 736 | 13:40 | |
+mesh-controller (agent: fixing, 2 of 3 landed)
+├── ✓ 652  assignments on the bus                      landed 14:02
+├── ▶ 736  placement words leave the layers            fixing since 13:51, 23 of 30 min
+│   └── ⏸ 751  config keys named (mesh-catalog)        waits for 736
+└── ✓ 654  a file names its template                   landed 13:20
+mesh-catalog (agent: waiting)
+└── ⏸ 751  (above, under 736)
 
 Past its bound: <the wait, how long, what is being done> — or "none"
 Needs you: <one line per question, with my recommendation> — or "nothing"