Playbooks 07 and 08: an acceptance criterion is numbered and cited by its test as <issue>/AC<n>, so its check is a grep (review round 1)

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

@@ -104,8 +104,8 @@ never into the running one, unless it blocks the running one.
    criterion is proven live after the delivery and said so). Together they cover the issue's done-when and the
    cases its life passes through: on 2026-10-18 mesh-delivery's group life (a group of three, a member's own
    check, a close in a group, a second pull request at the same commit, a stop and a resend) had no criterion,
-   and each case was found by a failure on the live mesh. They are an `issue-tracker.note` headed
-   `Acceptance criteria`, a revision a new note that replaces the older one, until the tracker holds them as a
+   and each case was found by a failure on the live mesh. Each criterion is numbered in its note and cited as
+   `<issue>/AC<n>` (`1118/AC2`). They are an `issue-tracker.note` headed `Acceptance criteria`, a revision a new note that replaces the older one, until the tracker holds them as a
    field (issue 1118). A criterion the reviewer adds in step 2 is written onto the issue the same way.
    **The survey sizes each issue, and an issue sized over an hour is split before any agent starts** (the operator,
    2026-10-17), into issues of about 30 minutes each, one change each, in the order they land: the bound of a
@@ -123,8 +123,8 @@ never into the running one, unless it blocks the running one.
   every commit** (the operator, 2026-10-17), not only the tests of what changed: it takes under a second, and a
   change breaks tests in packages it never touched. Each issue's first test fails before its change and passes
   after; `gofmt`, `go vet` and the whole unit suite stay green. **The tests are written from the issue's
-  acceptance criteria**: one test or more per criterion at the level it names, each test's name or comment
-  naming the criterion it proves, and no criterion left without its test; an integration criterion is a test
+  acceptance criteria**: one test or more per criterion at the level it names, each test's comment citing
+  the criterion it proves by its label (`// 1118/AC2`), and no criterion left without its test; an integration criterion is a test
   that compiles and waits for the check step. The integration tests (`merge-check.sh` with the store and the
   bus) wait for the check step.
 - **Nothing is pushed** and no pull request is opened in this step. Never land on a red check: run the
@@ -359,8 +359,8 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
   it is checked and delivered, and for a group its merge order (`issue-tracker.get`); an issue moved to `fixing`
   without one is a prepare step skipped.
 - Every issue of a running milestone has a note headed `Acceptance criteria` before it moves to `fixing`
-  (`issue-tracker.get`), each criterion naming its test level, and every criterion is named by a test in the
-  pushed tree (`git grep` for its words or its number); an issue without them is a prepare step skipped, and a
+  (`issue-tracker.get`), each criterion naming its test level, and every criterion's label is cited by a test in the
+  pushed tree (`git grep -n '<issue>/AC<n>'`); an issue without them is a prepare step skipped, and a
   criterion no test names is a review that missed it (until issue 1118 makes the tracker refuse it).
 - Every fixing agent's report gives the whole unit suite's result and time; a report naming only some packages'
   tests is the whole-suite rule not kept.

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

@@ -36,8 +36,8 @@ one delivery**. Everything before the push is local and fast.
    the repository's own clone, which stays on `main` (playbook [07](07-feature-branches.md), step 0, item 2). Write the
    test that fails today first; make the change; keep `gofmt`, `go vet` and the repository's whole unit suite green
    before every commit (each test well under a second; never a merge check or a database locally: how-we-build §5, ADR 0391).
-   The tests are written from the acceptance criteria, at least one per criterion at its level, each naming the
-   criterion it proves. Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq,
+   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`).
 4. **One review of the local commit, before anything is pushed** (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
@@ -103,7 +103,8 @@ reading itself and uses one subagent only for the review.
   running pushed with no integration test of the module whole, or a review report
   asking a change outside the issue's done-when and acceptance criteria, is the failure of steps 4 to 6.
 - A fixed code issue shows a note headed `Acceptance criteria` (`issue-tracker.get`) older than its first
-  commit, and each criterion is named by a test in the pushed tree; one without is step 1 skipped.
+  commit, and each criterion's label is cited by a test in the pushed tree
+  (`git grep -n '<issue>/AC<n>'`); one without is step 1 skipped.
 - 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.
 - The repository's own clone says `main` (`git -C <clone> branch --show-current`); another branch there is a