Playbooks 07 and 08: prove a module whole on a throwaway bus and store, not in the lab while its runs are too slow (the operator, 2026-10-16)

2026-10-16 10:13:38 +02:00
parent b1106a9908
commit 36e11f3dbd
2 changed files with 5 additions and 4 deletions
@@ -135,8 +135,9 @@ never into the running one, unless it blocks the running one.
   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; the lab when only machines can.
-   Unit tests alone are not that proof.
+   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).
 6. **The reviewer marks each pull request ready as soon as the acceptance is shown** (`mesh/ready` and a
   comment `ready at <full sha>`, 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
@@ -244,7 +245,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 (or lab run) named in the lead's report, is
+  changes a module marked ready with no run of the module whole 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.
@@ -43,7 +43,7 @@ one delivery**. Everything before the push is local and fast.
 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
+   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,
   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