Playbooks 07 and 08: the local integration run is the named tests that exercise the change; the report's tree is drawn from the verb

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

@@ -56,7 +56,7 @@ opened **once**, after the review, and **one check** (ADR 0548). It runs in five
 | Step | What happens | Bound |
 |---|---|---|
 | 0. Prepare | the lead settles the open questions and writes one context file per repository | 15 minutes |
-| 1. Develop | one fixing agent per repository builds every issue locally, the whole unit suite before every commit, the integration tests compiled; nothing is pushed | the milestone's issues, 30 minutes each |
+| 1. Develop | one fixing agent per repository builds every issue locally, the whole unit suite before every commit, the integration tests compiled (those that exercise the change are run by name before the push, step 3); nothing is pushed | the milestone's issues, 30 minutes each |
 | 2. Review | one reviewer reads all of it, the local commits, judging the integration tests by reading them against the code; reports go both ways; at most 3 rounds | 15 minutes |
 | 3. Check | push the reviewed heads once and open the pull requests together; the checker's one check runs the integration tests; no further review unless the check fails | one check run |
 | 4. Deliver | merge; the source revision moves, each module is built once and wanted on its nodes, its canary first | until the view says the source revision `delivered` |
@@ -201,8 +201,8 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
   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 is run by the pull request's one check. The integration tests (those that start a store, a bus
-  or a process) are compiled with `go vet -tags integration ./...` while developing and run by that check, nowhere
-  else.
+  or a process) are compiled with `go vet -tags integration ./...` while developing and run by that check; before the group's push only the tests that exercise the change are run by
+  name (step 3), nothing else.
 - **Nothing is pushed and no pull request is opened in this step, and there is no try** (ADR 0548; the operator,
   2026-10-26: "every release should only run 1 check or 1 try"). When every issue is committed, the lead brings each
   feature branch up to the current trunk (fetch by name, then merge) and the review reads the local commits. Never call
@@ -215,7 +215,8 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
   is a numbered migration and the consolidated schema; Go only unless the context file says otherwise; never
   move another issue; **leave the integration tests to the check** (no store or bus started by hand): compile them
   with `go vet -tags integration ./...`. A single integration test may be run locally against an embedded bus when
-  it is the fastest way to find a cause, said in the review report and the pull request. After a failed check it
+  it is the fastest way to find a cause, said in the review report and the pull request; before the group's push the
+  tests that exercise the change are run this way, by name (step 3). After a failed 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 the one more push: a verdict names only the first failed
   test (issue 1921), and on 2026-10-23 R4g's faults surfaced one per run until a local run listed them all in a minute (a
@@ -299,12 +300,14 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    and the integration level, through the build module of the repository's language and by that language's convention
    (ADR 0445, ADR 0529); the check waits on the language's check stream until a build node has a free slot
    (ADR 0525 §1). **No try:** never call `mesh-controller.try` or `mesh-delivery-checker.checker_try`, except when the
-   operator asks for one. While developing, no `go test -tags integration` run of a whole level, and no store or bus started
+   operator asks for one. While developing, no `go test -tags integration` run of a whole module or level, and no store or bus started
    by hand on the machine (the operator, 2026-10-18).
-   **Before a group's single push, every touched module's integration tests are run locally against an embedded bus**
-   (`go test -tags integration -count=1`), not only compiled with `go vet`; a change in how a node composes or applies
-   always does (2026-10-28: a compiled-only group failed in the one check on what a local run shows). How it is
-   checked: the pull request's description names the local integration results per module.
+   **Before a group's single push, the integration tests that exercise the change are run locally against an embedded
+   bus**, picked by name (`go test -tags integration -count=1 -run '<names>'`): the tests in the touched packages that
+   start the part whole, not a whole module's or level's integration run, and not only a compile with `go vet`; a
+   change in how a node composes or applies always has such a test (2026-10-28: a compiled-only group failed in the one
+   check on what a local run shows). How it is checked: the pull request's description names those tests and their
+   results.
    **While a group is being checked, nothing else is merged or pushed into a repository that is one of its members:**
    a moved main asks the group's check again. How it is checked: the lead's wait list names the group's members, and
    `mesh-delivery.show` shows one check per head.
@@ -556,16 +559,14 @@ Allowance: week <n> % (<+d> since the last report), session <n> %
 Next: <the next actions up to the delivery, in order>
 ```
 
-**The report starts with the tree of the verb, never a hand-drawn one**: one line per milestone in the five-minute
-report, the detailed tree about every thirty minutes. How it is checked: the report quotes the verb's read-at time.
 **Every report ends by scheduling the next** (a timer or a watcher set for five minutes ahead), so that agents'
 incoming reports never replace it. How it is checked: the operator sees a report at least every five minutes.
-**The tree is read, not assembled.** `knowledge-base.progress` with `of: "design <nn>"` answers the tree's
+**The report starts with the tree, drawn from the verb's answer and never by hand.** `knowledge-base.progress` with `of: "design <nn>"` answers the tree's
 milestones, issues, pull requests and held groups in one call, each with when it last moved: `detail: minimal` for the
 five-minute report, `detailed` about every thirty minutes and whenever something stops (issue 1947). What it cannot
 read for certain from the design's milestone table it says in `warnings`; the lead fixes the table, it does not
 correct the tree by hand. How it is checked: a report's tree that disagrees with the verb's answer of the same minute
-is a tree assembled by hand.
+is a tree assembled by hand, and a report that does not quote the verb's read-at time is the same.
 
 **The short layout** (on a channel such as Telegram, or when nothing changed but time):
 

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

@@ -54,8 +54,8 @@ processing power"). Everything before the push is local and fast, and no try is
    `go test ./...` at the root). The integration tests are compiled (`go vet -tags integration ./...`) and not run:
    nothing is pushed, no pull request is opened and no try (`mesh-controller.try`, `mesh-delivery-checker.checker_try`) is called, unless the operator asks for
    one. A single integration test may be run locally against an embedded bus when it is the fastest way to find a cause;
-   a change in how a node composes or applies runs its module's whole integration level that way before the push
-   (playbook 07 step 3), and the pull request names the results. A test fixture writes state in the form its real
+   before the push, the integration tests that exercise the change are run that way, by name
+   (playbook 07 step 3), and the pull request names them and their results. A test fixture writes state in the form its real
    writer writes it; the review asks it.
 4. **One review of the local commit** (a reviewer that did not write it, larger
    model; at most 3 rounds, as playbook 07; from round 2 only what is wrong; it reads each acceptance criterion