Playbooks 07 and 08: lessons of 2026-10-28 (progress tree, report cadence, local integration run, group members, delivered, fixtures)

2026-10-28 11:10:26 +01:00
parent 2ea3368b76
commit d348256090
2 changed files with 25 additions and 4 deletions
@@ -263,6 +263,9 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
   work-queue retention; three review rounds passed it, and only its try showed that every seat's work stream has
   that retention too, so dead asks across the mesh would no longer have been delivered again (issue 1178, fixed
   before its pull request by a mark only a declared module work queue carries).
+   **A test fixture writes state in the form its real writer writes it** (for example a resolved config value with its
+   source, as the controller stores it); a fixture that agrees with the mistake proves the mistake. How it is checked:
+   the review asks it of every new fixture, and says which writer it compared with.
 6a. **The reviewer reads the milestone file's three answers** (step 0, item 8) against the change: it lists every bucket
   key and stream the diff creates or writes (search the diff for the bucket and stream names) and finds each in the
   lifetime answer with a deleter and event, or a time to live; it reads the switch-over answer and checks it was done as
@@ -298,6 +301,13 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
   (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
   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.
+   **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.
   **A group is one check.** Before the push, every member pins the group's own mesh-sdk head exactly (the checker refuses an
   older commit of the same branch), then all members are pushed and opened together, so the group's check runs once. A head the review replaces
   counts for nothing against a running check; say so, and ask no other until the new head is reviewed.
@@ -406,7 +416,10 @@ the source revision equals its fingerprint and every have its want). After each
 the view's wants page or its tools: `assigner_wants` and `assigner_want` (a want not yet at the newest fingerprint
 names, in `newest` and `rule`, the rule that holds it back, and its words say why), and `node_haves` (the node
 agent's haves: fingerprint, composition digest, phase and health). The delivery is done when the view says
-`delivered` for its source revision; then the lead resolves the feature's issues with `fixed-by` naming its pull
+`delivered` for its source revision; **"on the machines" from the delivery tools is not yet "delivered"**: the lead
+also reads what the nodes run (the view's haves per node) and the indexer's record of the module (its newest
+fingerprint) before saying a change is delivered. How it is checked: the report names each node's build.
+Then the lead resolves the feature's issues with `fixed-by` naming its pull
 requests, and removes what is left: no `feat/<slug>` branch and no `.work/<slug>` worktree survive.

 **What a merge moves is read before the operator is told.** A change to mesh-sdk rebuilds every module that takes
@@ -511,7 +524,7 @@ Approve, a Retry or a Release waits for them, it reads `operator-channel.asks` a
 on 2026-10-20 an ask was named to the operator that the router did not hold. A merge the gate passed but whose
 ask is not on the router is the fault of the Approve's wait in the table above.

-**Every ten minutes (the operator, 2026-10-17), every two minutes while a delivery moves (the view says modules `moving`), and at once when something lands, stops or
+**Every five minutes (the operator, 2026-10-17, ten then; five since 2026-10-26), every two minutes while a delivery moves (the view says modules `moving`), and at once when something lands, stops or
 needs the operator,** the lead reports, in one of the two layouts below (the operator, 2026-10-16: an overview
 of the issues, often). Times are local and absolute, from the clock (`date`), never guessed; 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.
@@ -543,6 +556,10 @@ 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
 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
@@ -53,7 +53,10 @@ processing power"). Everything before the push is local and fast, and no try is
   criterion it proves by its label (`<issue>/AC<n>`, playbook 07 step 0 item 5). Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq,
   `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.
+   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
+   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
   against its test, as playbook 07 step 2 item 6; a finding outside the issue's done-when and its acceptance
@@ -87,7 +90,8 @@ processing power"). Everything before the push is local and fast, and no try is
 7. **Follow its delivery to done**: a watcher waits on the status view's events (`mesh-delivery-view.moving`,
   `.settled`, `.stuck` and `.delivered`) and reads the view's `assigner_wants` and `node_haves` after each wake, as
   playbook [07](07-feature-branches.md) step 4 says; the delivery is done when the view says `delivered` for its
-   source revision. Then prove the fix on the mesh (the symptom gone, measured), and resolve the issue with
+   source revision, and the haves per node and the indexer's record of the module name the build (playbook 07 step 4;
+   "on the machines" alone is not "delivered"). Then prove the fix on the mesh (the symptom gone, measured), and resolve the issue with
   `located-in` and `fixed-by` the same hour.

 A fix that stops before its delivery moves its issue back to `open` with a note saying how far it got