Playbooks 07 and 08: answer the review (no lab, plain words, checks on the forge, issue 1941)

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

@@ -155,15 +155,15 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
 7. **Write fixtures from the shape the other side writes, never from memory** (2026-10-18: a watchman's tests
    mirrored a build key the controller never writes, and every test passed): copy a value from the writer's code or
    from the live bus, and name where it came from.
-8. **Answer three questions in the milestone file** (`.work/<slug>/milestone.md`; research 071, issue 1921), written by the
+8. **Answer three questions in the milestone file** (`.work/<slug>/milestone.md`; research 071, issue 1941), written by the
    lead from this template before any agent starts. Each answer is a fact found, not a hope:
    ```
    Lifetime of what the work creates (research 071, a):
    - <bucket key or stream> | written by <module> | deleted by <module> on <event>, or time to live <duration>
    (one line for every key-value bucket key and stream the work creates or starts writing; "none created" if none)
-   Rehearsal of the switch-over (b):
-   - <the lab, or one node first: which node, what is read there before the rest>
-   - or: the operator chose no rehearsal on <date>; what that risks: <one sentence>
+   Trying the switch-over on one node first (b):
+   - <which node goes first, and what is read there before the rest>
+   - or: the operator chose no try on one node first, on <date>; what that risks: <one sentence>
    Integration level before the pull requests (c):
    - <the tries that run it, per repository; a group try if issue 1921 has delivered one>
    - what no try covers: <the parts of the group that meet only in the merge check>
@@ -234,11 +234,6 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
 4. **Every new integration test is read against the code it drives and against its try.** Fixing agents only compile it, and its one run before the review is the try (step 1), which shows whether it passed but not whether it proves what it says. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first two runs, on a fixture and then on a fault of the change; reading it against the code after the first failure found another fault, which would have failed a run too. The reviewer also checks that each new integration test enters through the same path the live trigger takes, not through a state it writes by hand: on 2026-10-17 milestone 4's test saved its delivery plan directly, so it skipped the cut from a batch that every live plan takes, and it passed while the backup step never ran (issue 1086).
 5. **The reviewer reads the answers and the new commits**, and approves or reports again (step 7 says what a round
    may ask). After round 3 the lead stops and brings the operator what is left, with a recommendation.
-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 rehearsal answer and checks it was done as
-   written or that the operator's choice is recorded; it reads the integration-level answer against the tries named
-   in the pull request. A missing answer, or a key or stream the diff creates that the answer omits, is a change asked.
 6. **The reviewer reads every acceptance criterion against its test**: each criterion has a test at its level
    that would fail without the change, and no test proves less than its criterion says. A criterion missing
    for a case the issue's done-when needs is written onto the issue (step 0, item 5) and is a finding; a test
@@ -250,6 +245,11 @@ 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).
+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
+   written or that the operator's choice is recorded; it reads the integration-level answer against the tries named
+   in the pull request. A missing answer, or a key or stream the diff creates that the answer omits, is a change asked.
 7. **A finding outside the issues' done-when and their acceptance criteria is never a change asked, in any round.** More hardening, a
    further case, a nicer form: the reviewer opens it with `issue-tracker.open` and names the number in its
    report, and the round does not wait for it. What a round asks is only what makes the change wrong against
@@ -583,6 +583,8 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
 - A running milestone's file holds the three answers of step 0 item 8 (`cat .work/<slug>/milestone.md`), and the
   review report says it read them (step 2, item 6a): a bucket key or stream in the diff (`git diff main --
   | grep -i 'bucket\|stream'`) that the lifetime answer omits is the failure of that item (research 071).
+- A pull request merged by hand in a temporary mode names, in its description on the forge (`gitea.gitea_get_pull_request`), a try with
+  tests `.` for each repository of the group; one without is the step 3 rule skipped.
 - A milestone that adds or changes a module whose pull request has no integration test that starts the module
   whole is the failure of the check step's fourth item.
 - A bed run from `.work/<slug>/mesh-lab` that fails naming a `.work/<slug>/<repo>/…` path it cannot find is a

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

@@ -125,7 +125,7 @@ reading itself and uses one subagent only for the review.
 - A small fix has one pull request with one or few commits naming its issue, opened after its review: a pull
   request with many heads is a fix reviewed after its pull request was opened.
 - A pull request merged by hand in a temporary mode names a try with tests `.` at its head in its description
-  (`mesh-delivery.show`); one without is the step skipped.
+  on the forge (`gitea.gitea_get_pull_request`); one without is the step skipped.
 - Its issue moves to `resolved` within the hour its delivery plan ends.
 - A pull request with no review record at its head (the Approve's ask says so first), a fix to a module's
   running pushed with no integration test of the module whole, or a review report

00-META/process/playbooks.html

@@ -465,7 +465,7 @@ const P = [
  {n:"07",name:"Features",kind:"build",c:"--build",
   trig:"Work that changes code across issues or repositories, too large for a small fix.",
   who:"A lead (larger model), one fixing agent per repository (smaller), one reviewer (larger).",
-  steps:["Prepare: name the branch, make the worktrees, settle every question.","Write one context file per repository.","Write the findings and acceptance criteria into each issue.","Survey every other reader and writer of each changed value. (new)","Answer three questions in the milestone file: who deletes each new key and stream, how the switch-over is rehearsed, how the integration level runs before the pull requests. The review checks them. (new)","List every part the change reaches; copy fixtures from the real writer.","Develop: one agent per repository, one commit per issue.","A test fails first on behaviour, not on compiling. (new)","Bring each branch up to the trunk, push, and try it. (new)","Review all of it with the tries' results; at most 3 rounds.","Push the reviewed heads; try again only what changed.","A merge by hand in a temporary mode first runs a try with tests \".\" and names it in the pull request. (new)","Open one pull request per repository, together, with Reviewed-by and Pushed-by.","The operator's Approve on Telegram; the group merges in one pass.","Follow the delivery plan to done; resolve the issues; clean up.","When the builder cannot deliver its own fix: revert, a build by a session's call, a registration at the terminal, copies kept outside the store. (new)"],
+  steps:["Prepare: name the branch, make the worktrees, settle every question.","Write one context file per repository.","Write the findings and acceptance criteria into each issue.","Survey every other reader and writer of each changed value. (new)","Answer three questions in the milestone file: who deletes each new key and stream, how the switch-over is tried on one node first, how the integration level runs before the pull requests. The review checks them. (new)","List every part the change reaches; copy fixtures from the real writer.","Develop: one agent per repository, one commit per issue.","A test fails first on behaviour, not on compiling. (new)","Bring each branch up to the trunk, push, and try it. (new)","Review all of it with the tries' results; at most 3 rounds.","Push the reviewed heads; try again only what changed.","A merge by hand in a temporary mode first runs a try with tests \".\" and names it in the pull request. (new)","Open one pull request per repository, together, with Reviewed-by and Pushed-by.","The operator's Approve on Telegram; the group merges in one pass.","Follow the delivery plan to done; resolve the issues; clean up.","When the builder cannot deliver its own fix: revert, a build by a session's call, a registration at the terminal, copies kept outside the store. (new)"],
   prod:"One pull request per repository, one delivery plan, resolved issues, no branch or worktree left.",
   next:"02 (when it ships)",bounds:"Prepare 15 min · 30 min per issue · review 15 min, ≤ 3 rounds · one try and one check",
   prev:["Pull requests as scratchpads","Context bought again and again","Review rounds spent on what a run would show"],