Merge pull request 'Playbooks 07 and 08 name the checker's try beside the controller's (issue 774, ADR 0561), rebased onto L2' (#495) from feat/774-vault-mints-l2 into main

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-controller.try`, `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-controller.try`, `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
@@ -403,6 +403,21 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    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
    first still waits shows in `gitea.gitea_list_pull_requests` as two open pull requests of one lead.
+6. **A member pins mesh-sdk only at a commit that is a pull request's head**, merged or open (2026-10-28: the check
+   refused a pin to a merge commit on main as "on no pull request", though its tree equalled the head's). How it is
+   checked: the check's pin step; a refusal "on no pull request" is this rule skipped.
+7. **Two groups that pin the same module's mesh-sdk conflict in `go.mod` and `go.sum`.** The group that merges
+   second merges main in and re-pins once, to a pull request head that holds both changes, after the first group
+   is merged and not before (a re-pin before makes the first group conflict). How it is checked: the check's merge
+   step; a group that conflicts after the first one merged is this rule skipped.
+8. **A group that adds a seat, a verb or a manifest field in mesh-sdk and uses it in a module's manifest in the
+   same group cannot pass its check** until the running assigner pins a mesh-sdk that defines it, because the
+   check composes with the running assigner's mesh-sdk (issue 1585). The assigner's pin ships first, as its own
+   release. How it is checked: the check's composition step; a composition refusing the new word in such a group
+   is this rule skipped.
+9. **A new head on an open pull request needs its `Reviewed-by` line at that head before the Approve is asked,
+   even for a pin-only commit.** How it is checked: the Approve's ask names the review record;
+   an ask whose line names another commit is this rule skipped.
 
 **One exception: a catalog change that uses a new manifest word.** The catalog's merge check reads
 manifests with the controller the mesh runs, so the controller's pull request is merged and delivered first;
@@ -661,7 +676,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-controller.try`, `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-controller.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-controller.try` or `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