Merge main into feat/r4g-finish (#472)

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

@@ -155,7 +155,22 @@ 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. **Move the issues to `fixing`**, `by` naming the feature's agent for that repository.
+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)
+   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>
+   ```
+   A key or stream with no one who deletes it and no time to live is a leak and is settled before work starts. Until
+   issue 1921 gives a group try, answer (c) with the single-repository tries and say so.
+9. **Move the issues to `fixing`**, `by` naming the feature's agent for that repository.
 
 ## Step 1 — Develop (one fixing agent per repository, smaller model)
 
@@ -230,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
@@ -258,6 +278,10 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    by hand on the machine (the operator, 2026-10-18); after a failed try, a local run of the whole level is the guideline
    in step 1's brief. Pull requests in two or
    more repositories that share the branch name are one delivery group (ADR 0239 §2).
+   **A temporary mode that merges by hand** (the lead merges because the normal Approve and merge path is not
+   running): before it asks the merge, the lead runs the full integration level with nothing kept, a try with tests
+   `.` for each repository of the group, and names those tries (ids and verdicts) in the pull request's description.
+   A merge asked without them is a step skipped (research 071).
    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. **A large change is pushed by a pusher agent** on the smaller
    model: `gitea_commit` patches of about 30 KB each, a file copied from another path sent as a copy (`copy_from`)
@@ -556,6 +580,11 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
 - Every review record of a release names one reviewer (`mesh-delivery.show`, the review record), and the lead's
   save point names one reviewer id per release; a second reviewer within one release is a reviewer not kept
   (issue 1042). A pull request whose ask says it has no review record at its head is a record not written.
+- 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

@@ -66,6 +66,10 @@ one delivery**. Everything before the try is local and fast.
    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, before the next try.
+   **A temporary mode that merges by hand** (the lead merges because the normal Approve and merge path is not
+   running): before it asks the merge, the lead runs the full integration level with nothing kept, `mesh-controller.try`
+   with tests `.`, and names that try (id and verdict) in the pull request's description (research 071; playbook
+   [07](07-feature-branches.md) step 3).
 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
@@ -120,6 +124,8 @@ 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
+  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)","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.","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"],