Playbooks 07 and 08: say the local run after a failed try as a guideline, not a rule (the operator)

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

@@ -187,11 +187,11 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
   move another issue; **never run an integration test on the machine** (no `go test -tags integration`,
   no store or bus started by hand): compile them with `go vet -tags integration ./...` and leave the running to
   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). **One exception: a failed try or check.** Then the whole
-  integration level of that repository is run locally at once (`go test -tags integration -count=1 ./...` in each module),
-  by the lead or by the fixing agent on the lead's word, before any further try: a verdict names only the first failed test
-  (issue 1921), and on 2026-10-23 R4g's faults surfaced one per try until a local run listed them all in a minute (the
-  operator: "if it fails, you should run it locally"). Report back in under 150 words: commits, tests added and that they failed first, the
+  brief only said they wait for the check (the operator). After a failed try or check it
+  usually pays to run that repository's whole integration level locally (`go test -tags integration -count=1 ./...` in each
+  module), by the lead or by the fixing agent on the lead's word, before another try: a verdict names only the first failed
+  test (issue 1921), and on 2026-10-23 R4g's faults surfaced one per try until a local run listed them all in a minute (a
+  guideline, 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
   settles it, updates the context file, and continues the agent.

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

@@ -61,11 +61,11 @@ one delivery**. Everything before the try is local and fast.
 5. **Push the reviewed head, try it again if the review changed it, 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. `mesh-controller.try` on the pushed branch runs
    the integration tests, and the pull request is opened only when the head's last try passed; the checker's merge check runs
-   them again as the gate (playbook [07](07-feature-branches.md) step 3). **A failed try or check is run locally at once:** the
-   repository's whole integration level, `go test -tags integration -count=1 ./...` in each module, once, before anything
-   else, because a verdict names only the first failed test (issue 1921) and a try per fault costs a round each (the
-   operator, 2026-10-23: "if it fails, you should run it locally"). Every failure it shows goes back to the same agent
-   with the failure, fixed in one change, and the reviewer reads only the change it makes; then one try.
+   them again as the gate (playbook [07](07-feature-branches.md) step 3). A failed try or check is best run locally
+   first: the repository's whole integration level (`go test -tags integration -count=1 ./...` in each module) shows every
+   failure at once, where a verdict names only the first (issue 1921) and a try per fault costs a round each (a guideline,
+   the operator, 2026-10-23). The failures go back to the same agent, fixed in one change where they can be, and the
+   reviewer reads only the change it makes; then one try.
 6. **The pull request's description carries the review record** (`Reviewed-by: <who@node> at <full sha>`,
    playbook [07](07-feature-branches.md) step 3) and the session that pushed it (`Pushed-by: <who@node>`, ADR 0505 §5), and mesh-delivery asks the operator's Approve as soon as its
    checks pass and merges the approved head (ADR 0421); nobody marks, labels, comments or rechecks. A fix to a module that changes how it runs carries an