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)

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

@@ -112,9 +112,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
+4. **The reviewer reads the answers and the new commits**, and approves or reports again (step 5 says what a round
-   asks changes only for a finding that makes the feature wrong; smaller points become issues of their own.
+   may ask). After round 3 the lead stops and brings the operator what is left, with a recommendation.
-   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
@@ -179,6 +178,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` |
 
@@ -243,6 +243,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.
 

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

@@ -33,14 +33,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,
@@ -74,3 +75,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.