diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 5ee7eb9f..fb925e22 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -124,7 +124,8 @@ never into the running one, unless it blocks the running one. ## Phase 3 — Check (no review) 1. **Push every feature branch and try it before any pull request.** `mesh-controller.try` with the - repository and the branch runs the merge check in the check's own toolchain; a branch that fails goes back + repository and the branch runs the merge check on the builder, in the check's own toolchain, never + locally (ADR 0391 §4); a branch that fails goes back to its fixing agent, and nothing is opened until every branch passes. A local run never stands in for it: the check's containers carry other tools than the nodes. 2. **Open one pull request per repository, together.** Pull requests in two or @@ -135,11 +136,10 @@ never into the running one, unless it blocks the running one. second review: phase 2 reviewed this tree. 4. **A check that fails** goes back to the reviewer with the failure, for **one more cycle** of phase 2 with the same fixing agents; then push once again. -5. **Prove the step's acceptance before it is marked ready.** A step that adds or changes a module runs that - module whole (its process against a real bus and store) on the cheapest bed that can show the step's - acceptance sentence, as playbook [01](01-research.md) says for research: a test that starts the built module - against a throwaway bus and store. Unit tests alone are not that proof. The lab is not used for this while - its runs are too slow (the operator, 2026-10-16). +5. **The step's acceptance is proven before it is marked ready.** A step that adds or changes a module + carries an integration test that starts the module whole, its process against the real bus and store, and + shows the step's acceptance sentence; the forge's checks run it (ADR 0391 §1, §6). Unit tests alone are not + that proof, and no lab run is (ADR 0391 §5: end to end only on the operator's ask). 6. **The reviewer marks each pull request ready as soon as the acceptance is shown** (`mesh/ready` and a comment `ready at `, the head it approved); mesh-delivery merges it when its checks pass (ADR 0364). The operator's word is waited for only when the step changes what the operator sees, removes @@ -247,7 +247,7 @@ issues in `fixing` that nobody works on reads to the operator as stuck work. - 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 named in the lead's report, is + changes a module marked ready with no integration test that starts the module whole, 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 75f7bda9..65670057 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -43,9 +43,9 @@ one delivery**. Everything before the push is local and fast. 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** (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 throwaway bus and store, never the lab for now) 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, + mesh-delivery merges it when its checks pass. A fix to a module that changes how it runs carries an + integration test starting the module whole against the real bus and store, run by the forge's checks + (ADR 0391 §1, §6); unit tests alone, or a lab run, are not that proof. The operator's word is waited for only when the fix changes what the operator sees, removes data, or needs the operator's terminal. 7. **Follow its delivery plan to done** (`mesh-controller.plans` with `wait` and `until: done`), prove the fix on the mesh (the symptom gone, measured), and resolve the issue with `located-in` and `fixed-by` the same hour. @@ -77,7 +77,7 @@ reading itself and uses one subagent only for the review. 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 + for more than 15 minutes, a fix to a module's running marked ready with no integration test 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.