Playbooks 07, 08 and the overview name what runs: the checker's try and status, hq's Go tests, the stream backlog, and the way to deliver without the builder (issue 1888)

2026-10-23 15:17:30 +02:00
parent 99fa8f0f09
commit c8ccbfe35f
4 changed files with 55 additions and 27 deletions
@@ -38,7 +38,7 @@ one delivery**. Everything before the try is local and fast.
   decision stays a small fix. **The session's own model (the larger) then writes the issue's acceptance
   criteria** as playbook [07](07-feature-branches.md) step 0 item 5 says: each one sentence, given, when, then,
   naming the level of the test that proves it, as an `issue-tracker.note` headed `Acceptance criteria`. A
-   playbook or design edit has none: its check is `sh merge-check.sh`.
+   playbook or design edit has none: its check is `go test ./...` at hq's root, which runs the four checks (ADR 0527).
 2. **Move the issue to `fixing`** with `by` as who@node.
 3. **Build on a local branch** `fix/<issue>-<slug>`, in a worktree of its own branched from `main`, never in
   the repository's own clone, which stays on `main` (playbook [07](07-feature-branches.md), step 0, item 2). Write the
@@ -50,7 +50,7 @@ one delivery**. Everything before the try is local and fast.
   caught only by the review); read `git show --stat` before pushing.
   The tests are written from the acceptance criteria, at least one per criterion at its level, each citing the
   criterion it proves by its label (`<issue>/AC<n>`, playbook 07 step 0 item 5). Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq,
-   `sh merge-check.sh`). Then push the branch and run `mesh-controller.try` on it, so the review reads the
+   `go test ./...` at the root). Then push the branch and run `mesh-controller.try` on it, so the review reads the
   integration tests' real results; a failed try goes back to the same agent before the review.
 4. **One review of the commit and its try** (a reviewer that did not write it, larger
   model; at most 3 rounds, as playbook 07; from round 2 only what is wrong; it reads each acceptance criterion
@@ -60,13 +60,13 @@ one delivery**. Everything before the try is local and fast.
   operator's Approve of its merge is its review, and the review record says so.
 5. **Push the reviewed head, try it again if the review changed it, and open the pull request.** The trunk is what runs and nothing holds merged work back
   (ADR 0401), so a fix waits for no other change's delivery. `mesh-controller.try` on the pushed branch runs
-   the integration tests, and the pull request is opened only when the head's last try passed; the forge's merge check runs
+   the integration tests, and the pull request is opened only when the head's last try passed; the checker's merge check runs
   them again as the gate (playbook [07](07-feature-branches.md) step 3). They are never run on the machine. A
   failed try or check goes back to the same agent with the failure, and the reviewer reads only the change it makes.
 6. **The pull request's description carries the review record** (`Reviewed-by: <who@node> at <full sha>`,
   playbook [07](07-feature-branches.md) step 3) and the session that pushed it (`Pushed-by: <who@node>`, ADR 0505 §5), and mesh-delivery asks the operator's Approve as soon as its
   checks pass and merges the approved head (ADR 0421); nobody marks, labels, comments or rechecks. 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 `mesh-controller.try` and the forge's checks
+   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.
 7. **Follow its delivery plan to done** (`mesh-controller.plans` with `wait` and `until: done`), prove the fix on
@@ -99,9 +99,9 @@ code.
 | Waiting on | Bound | Past the bound |
 |---|---|---|
 | building the fix | 1 hour | it is a feature: stop and plan it under playbook 07 |
-| a slot for the try | 30 minutes | `mesh-controller.try` holds at most four tries and refuses a fifth without queueing it: a watcher asks again every minute; past the bound, read `mesh-controller.queue` |
+| the try | 30 minutes | a try is a check ask on the language's check stream and waits behind the asks before it for a build node's free slot (ADR 0525); past the bound, read the stream's backlog and the age of its oldest ask in the delivery view |
 | the review | 15 minutes | ask the reviewer where it stands |
-| the merge check | 15 minutes | read `mesh-controller.queue` and the check's log |
+| the merge check | 15 minutes | read `mesh-delivery.show`, the check's log and the check stream's backlog in the delivery view |
 | the Approve's ask | 5 minutes after both checks pass | read `mesh-delivery.show`: an ask not raised is a fault, said to the operator |
 | the merge after the Approve | 5 minutes | read `mesh-delivery.show` for the delivery |
 | the delivery plan | its class's budget (`mesh-delivery.times`), at most 30 minutes | read `mesh-controller.plans`, then `mesh-delivery.stalled` |