Playbooks 07 and 08: checks for every new rule, the ready mark's bound in both, the lead marks an unreviewed edit (review round 1)

2026-10-16 10:14:25 +02:00
parent c5fa1de264
commit 4e822c56a0
2 changed files with 14 additions and 5 deletions
@@ -114,9 +114,8 @@ never into the running one, unless it blocks the running one.
   It says which round it is in ("round 1 of at most 3").
 3. **The report goes to the same fixing agents** that wrote the code, continued by their ids, so they fix
   with the context they already hold. Each answers the reviewer: what it changed, per finding, or why not.
-4. **The reviewer reads the answers and the new commits**, and approves or reports again. From round 2 it
-   asks changes only for a finding that makes the feature wrong; smaller points become issues of their own.
-   After round 3 the lead stops and brings the operator what is left, with a recommendation.
+4. **The reviewer reads the answers and the new commits**, and approves or reports again (step 5 says what a round
+   may ask). After round 3 the lead stops and brings the operator what is left, with a recommendation.
 5. **A finding outside the issues' done-when 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
@@ -181,6 +180,7 @@ on, with when it started and its bound.
 | a fixing agent's issue | 30 minutes | ask it where it stands; split or take over |
 | the review | 15 minutes a round | ask the reviewer; stop at round 3 |
 | a merge check | 15 minutes | read the build queue (`mesh-controller.queue`) and the check's log |
+| the ready mark | 15 minutes after the acceptance is shown | the reviewer marks it, or the lead does |
 | a merge after ready | 5 minutes after the checks pass | read `mesh-delivery.show` for the delivery |
 | a delivery plan | its class's budget (`mesh-delivery.times`), at most 30 minutes | read `mesh-controller.plans`, then `mesh-delivery.stalled` |

@@ -245,6 +245,9 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
  review rules; `issue-tracker.list` with `flag: abandoned` lists issues left in `fixing` with nobody on them.
 - A pull request reviewed and green but not marked ready for more than 15 minutes is a lead that did not
  mark it.
+- A pull request whose head has no passing `mesh-controller.try` before it was opened, or a step that adds or
+  changes a module marked ready with no run of the module whole (or lab run) named in the lead's report, is
+  the failure of phase 3's first and fifth steps.
 - A bed run from `.work/<slug>/mesh-lab` that fails naming a `.work/<slug>/<repo>/…` path it cannot find is a
  missing sibling worktree, not a mesh fault.

@@ -34,14 +34,15 @@ one delivery**. Everything before the push is local and fast.
   model; at most 3 rounds, as playbook 07; from round 2 only what is wrong; a finding outside the issue's
   done-when is opened as an issue of its own, never asked as a change). The reviewer's findings go back to the same agent that wrote the fix, continued by
   its id, so the fix keeps its context. A playbook or design edit of a few lines may skip the reviewer: the
-   operator's word on the pull request is its review.
+   operator's word on the pull request is its review, and the lead marks it ready on that word.
 5. **Push the branch, try it, then open the pull request.** `mesh-controller.try` with the repository and the
   branch runs the merge check in the check's own toolchain before any status is set; open the pull request
   only once it passes. A local run never stands in for it: the check's containers carry other tools than the
   nodes (a test that called util-linux `flock -E` passed on a node and failed on BusyBox's in the check). The
   forge's merge checks run the integration tests. A failed check
   goes back to the same agent with the failure, and the reviewer reads only the change it makes.
-6. **The reviewer marks it ready at once** (`mesh/ready` and `ready at <full sha>`, the head it approved);
+6. **The reviewer marks it ready at once** (for an edit that skipped the reviewer, the lead, on the
+   operator's word) (`mesh/ready` and `ready at <full sha>`, the head it approved);
   mesh-delivery merges it when its checks pass. A fix to a module proves the issue's done-when with the
   module running whole (its process against a real bus and store) before it is marked, not with unit tests
   alone. The operator's word is waited for only when the fix changes what the operator sees, removes data,
@@ -75,3 +76,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 push.
 - Its issue moves to `resolved` within the hour its delivery plan ends.
+- A pull request opened with no passing `mesh-controller.try` on its head, one reviewed and green but unmarked
+  for more than 15 minutes, a fix to a module marked ready with no run of the module whole, or a review report
+  asking a change outside the issue's done-when, is the failure of steps 4 to 6.
+- An issue in `fixing` with nobody on it shows in `issue-tracker.list` with `flag: abandoned`; a stopped fix
+  moves it back to `open` with its note.