From 4e822c56a0f94d6846fdf47a5c74ca34e1513877 Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 16 Oct 2026 10:12:44 +0200 Subject: [PATCH] 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 | 9 ++++++--- 00-META/process/08-small-fixes.md | 10 ++++++++-- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 018c22d5..276091f4 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -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//mesh-lab` that fails naming a `.work///…` path it cannot find is a missing sibling worktree, not a mesh fault. diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index 22f83bc0..40640e5a 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -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 `, 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 `, 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.