diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 881958aa..9c9eab50 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -261,12 +261,6 @@ issue whether it is being fixed in between, after the delivery, or waits, and on 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 its issues, their acceptance criteria and its decisions. -7a. **At the second instance of a fault kind in a review, the developer searches for every instance and names each in the - report.** On 2026-10-25 a "busy, return at once" guard that dropped a newer request was found in three places, - one review after another. The developer writes the kind in one line, searches the repository (`git grep`) for - its shape, fixes every hit in one change and lists each file and line in the report. How it is checked: a - report to the second round naming a kind and one place only, followed by a third round on the same kind, is - this rule skipped. 8. **A timer that writes state, or a rule fixed in code that overrides what a person sets, makes the change wrong.** The mesh is NATS-native: a part says what happened as an event and acts on events; nothing polls and rewrites state on an interval, and a policy the operator can change is a setting the module declares, @@ -275,6 +269,12 @@ issue whether it is being fixed in between, after the delivery, or waits, and on One with no answer is a change asked. On 2026-10-23 the forge module's loop rewrote every repository's branch protection every ten minutes from rules in its code and undid the operator's changes at the forge (issue 1903). +9. **At the second instance of a fault kind in a review, the developer searches for every instance and names each in the + report.** On 2026-10-25 a "busy, return at once" guard that dropped a newer request was found in three places, + one review after another. The developer writes the kind in one line, searches the repository (`git grep`) for + its shape, fixes every hit in one change and lists each file and line in the report. How it is checked: a + report to the second round naming a kind and one place only, followed by a third round on the same kind, is + this rule skipped. ## Step 3 — Check (no review) @@ -355,12 +355,12 @@ issue whether it is being fixed in between, after the delivery, or waits, and on the Approve and the merge, and wakes the lead. Beyond that Approve, the operator's word is waited for only when the milestone changes what the operator sees, removes data, or needs a step only the operator's terminal can take; the lead says which before the milestone starts. - **A pull request that depends on an earlier one is opened only once the earlier one is delivered**, its build + **A pull request that depends on an earlier one outside its delivery group is opened only once the earlier one is delivered**, its build running on every machine it should reach, not merely merged. A note in the description is no safeguard: the operator's Approve merges whatever is asked. On 2026-10-25 a second change merged before the first was delivered and machines lost modules. How it is checked: `mesh-delivery.deliveries` shows the earlier change's source revision `delivered` before the later pull request exists (`gitea.gitea_get_pull_request`, its creation time); - a later one older than that is this rule skipped. + a later one older than that is this rule skipped. Members of one delivery group are the exception: they open together, with one check, one Approve and one merge in one pass (item 1). **A reviewed follow-up to a change the operator has not yet approved is folded into that pull request** (its head moved to include it): one Approve, one delivery. The old Approve ask closes itself on the new head and the new head is asked once its checks pass. How it is checked: a follow-up that sits in a second pull request while the diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index ef7cf818..4811b340 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -76,13 +76,13 @@ one delivery**. Everything before the try is local and fast. integration test starting the module whole against the real bus and store, run by `mesh-controller.try` and the checker's merge check (ADR 0391 §1, §6); unit tests alone are not that proof, and the lab is not used. The operator's word is waited for only when the fix changes what the operator sees, removes data, or needs the operator's terminal. - **A fix that depends on another pull request opens only once that one is delivered**, not merely merged (a note + **A fix that depends on another pull request outside its delivery group opens only once that one is delivered**, not merely merged (members of one group open together, as playbook 07 step 3 item 1 says) (a note in the description does not hold it back: the Approve merges whatever is asked; 2026-10-25, machines lost modules when a second change merged first). **A reviewed follow-up to a fix still waiting for the Approve is folded into that pull request** (head moved): one Approve, one delivery. Both are checked as playbook [07](07-feature-branches.md) step 3 says. **At the second instance of a fault kind found in a review, the developer searches for every instance** and names - each in the report (playbook [07](07-feature-branches.md) step 2, item 7a). + each in the report (playbook [07](07-feature-branches.md) step 2, item 9). 7. **Follow its delivery to done**: a watcher waits on the status view's events (`mesh-delivery-view.moving`, `.settled`, `.stuck` and `.delivered`) and reads the view's `assigner_wants` and `node_haves` after each wake, as playbook [07](07-feature-branches.md) step 4 says; the delivery is done when the view says `delivered` for its