Playbook 07: name a pull request's own issues as 'issue <n>', and no other

mesh-delivery reads a pull request's issues from the words 'issue <n>' in its description; okioki #9 listed its own bare and named two follow-ups that way, and the Approve's ask named the follow-ups.
2026-10-21 14:05:28 +02:00
parent ab3ac686dc
commit c770bc1c50
1 changed files with 5 additions and 0 deletions
@@ -234,6 +234,11 @@ never into the running one, unless it blocks the running one.
   `Reviewed-by: <who@node> at <full sha>` (the issue 1022 note gives its form). mesh-delivery reads it at every new
   head and puts it in the Approve's ask; a missing line, or one naming another commit, is said first in the ask.
   It is never a gate.
+   **The description names its issues as `issue <n>`, and only its own** (2026-10-21: okioki #9 listed its four
+   issues bare, `Issues: 1608, 1646, …`, and named two follow-ups as `issue 1654` and `issues 1665`, so mesh-delivery
+   carried the two follow-ups as the pull request's issues and the Approve's ask named them): mesh-delivery takes a
+   pull request's issues from the words `issue <n>` in its description, so write `issue 1608, issue 1646`, and name a
+   follow-up or another milestone's issue in words, not by `issue <n>`.
   **A catalogue pull request that removes a module, or a subject a module names, is also judged by the
   controller's unit tests against the catalogue's branch**, because those tests read the catalogue and no check
   of the catalogue runs them: on 2026-10-20 mesh-catalog #381 removed the old delivery module, and every