Playbooks 07 and 08 name the try by the checker's seat: mesh-delivery-checker.try replaces mesh-controller.try (ADR 0547 §10, issue 774)

00-META/process/07-feature-branches.md

@@ -206,7 +206,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
 - **Nothing is pushed and no pull request is opened in this step, and there is no try** (ADR 0548; the operator,
   2026-10-26: "every release should only run 1 check or 1 try"). When every issue is committed, the lead brings each
   feature branch up to the current trunk (fetch by name, then merge) and the review reads the local commits. Never call
-  `mesh-controller.try` or `mesh-delivery-checker.checker_try`; one is run only when the operator asks for it. A reviewer
+  `mesh-delivery-checker.try` or `mesh-delivery-checker.checker_try`; one is run only when the operator asks for it. A reviewer
   or a session that wants the code on the forge may push a branch that has no pull request: it runs nothing. Never land
   on a red check: read the result, then land in a separate step.
 - **The fixing agent's brief** (the lead gives it with the context file): name your issue in every step and
@@ -310,7 +310,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    processing power"). The integration tests run once, in the checker's merge check on the merge with the trunk's head, at the unit
    and the integration level, through the build module of the repository's language and by that language's convention
    (ADR 0445, ADR 0529); the check waits on the language's check stream until a build node has a free slot
-   (ADR 0525 §1). **No try:** never call `mesh-controller.try` or `mesh-delivery-checker.checker_try`, except when the
+   (ADR 0525 §1). **No try:** never call `mesh-delivery-checker.try` or `mesh-delivery-checker.checker_try`, except when the
    operator asks for one. While developing, no `go test -tags integration` run of a whole module or level, and no store or bus started
    by hand on the machine (the operator, 2026-10-18).
    **Before a group's single push, the integration tests that exercise the change are run locally against an embedded
@@ -661,7 +661,7 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
 - **One release, one check** (ADR 0548): `gitea.gitea_get_pull_request` shows each pull request created after its
   review record's time, and `mesh-delivery.show` shows one check per head and, for a group, one head per member; a pull
   request that existed before its review approved it, a second head with no failed check before it, or a check of a
-  head asked more than once, is this rule skipped. A call of `mesh-controller.try` or `checker_try` that the operator
+  head asked more than once, is this rule skipped. A call of `mesh-delivery-checker.try` or `checker_try` that the operator
   did not ask for shows in the checker's asks and is the same breach.
 - A milestone that adds or changes a module whose pull request has no integration test that starts the module
   whole is the failure of the check step's fourth item.

00-META/process/08-small-fixes.md

@@ -52,7 +52,7 @@ processing power"). Everything before the push is local and fast, and no try is
    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,
    `go test ./...` at the root). The integration tests are compiled (`go vet -tags integration ./...`) and not run:
-   nothing is pushed, no pull request is opened and no try (`mesh-controller.try`, `mesh-delivery-checker.checker_try`) is called, unless the operator asks for
+   nothing is pushed, no pull request is opened and no try (`mesh-delivery-checker.try`, `mesh-delivery-checker.checker_try`) is called, unless the operator asks for
    one. A single integration test may be run locally against an embedded bus when it is the fastest way to find a cause;
    before the push, the integration tests that exercise the change are run that way, by name
    (playbook 07 step 3), and the pull request names them and their results. A test fixture writes state in the form its real
@@ -141,7 +141,7 @@ reading itself and uses one subagent only for the review.
 - A pull request merged by hand in a temporary mode names the verdict of its one check in its description
   on the forge (`gitea.gitea_get_pull_request`); one without is the step skipped.
 - One fix, one check (ADR 0548): a pull request that existed before its review approved the head, or a head whose check was
-  asked more than once with no new reviewed head, is steps 4 and 5 skipped; so is a `mesh-controller.try` the operator did not ask for.
+  asked more than once with no new reviewed head, is steps 4 and 5 skipped; so is a `mesh-delivery-checker.try` the operator did not ask for.
 - Its issue moves to `resolved` within the hour the view says its source revision `delivered`.
 - A pull request with no review record at its head (the Approve's ask says so first), a fix to a module's
   running pushed with no integration test of the module whole, or a review report