2026-10-19 13:30:10 +00:00
1 changed files with 16 additions and 0 deletions
@@ -195,6 +195,13 @@ never into the running one, unless it blocks the running one.
   that would fail without the change, and no test proves less than its criterion says. A criterion missing
   for a case the issue's done-when needs is written onto the issue (step 0, item 5) and is a finding; a test
   missing for a criterion is a finding.
+   **A rule keyed on a property is checked against everything else on the mesh that has it.** When a change
+   decides by a property the bus or the store gives (a stream's retention, a folder's name, an account's kind),
+   the reviewer lists what else already has that property, live, and asks what the rule does to it. On
+   2026-10-19 release 1 of feature mail-sender made a work-queue stream's dead letters drop-only by the bus's
+   work-queue retention; three review rounds passed it, and only its try showed that every seat's work stream has
+   that retention too, so dead asks across the mesh would no longer have been delivered again (issue 1178, fixed
+   before its pull request by a mark only a declared module work queue carries).
 7. **A finding outside the issues' done-when and their acceptance criteria is never a change asked, in any round.** More hardening, a
   further case, a nicer form: the reviewer opens it with `issue-tracker.open` and names the number in its
   report, and the round does not wait for it. What a round asks is only what makes the change wrong against
@@ -236,6 +243,11 @@ never into the running one, unless it blocks the running one.
   carries an integration test that starts the module whole, its process against the real bus and store, and
   shows the milestone's acceptance sentence; the forge's checks run it (ADR 0391 §1, §6). Unit tests alone are not
   that proof; the mesh has no end-to-end tests yet, and the lab is not used (the operator, 2026-10-16).
+   **A new manifest word's test goes through the push that meets it first, not only the verb that fills it.**
+   On 2026-10-19 release 1 of feature mail-sender tested a process's own bus account through `module issue`
+   alone; the first push after mesh-mail declared the process composed a random 40-character stand-in for the
+   account file before anyone issued it, and the process crash-looped until the account was issued and pushed by
+   hand (issue 1226).
 5. **The operator's Approve is asked as soon as the checks pass** (ADR 0421). Nobody marks, labels, comments or
   rechecks: mesh-delivery asks the Approve on Telegram, the channel that proves who answered today (ADR 0398 §3;
   an Approve at the terminal is issue 953), once both checks passed, for a delivery group once for all its
@@ -303,6 +315,10 @@ It loops `mesh_wait` on the event families of what it watches (`mesh-delivery.tr
 a minute. After every answer or timeout it reads the state from the verb that owns it (`mesh-delivery.show`,
 `mesh-controller.plans`, `knowledge-base.get`), because an event only wakes it (ADR 0367). It finishes, and so wakes
 the lead, when the state changes or the wait passes its bound. The lead never sleeps or polls by hand to wait.
+**A watcher watches one wait and ends with it.** It is never re-pointed at the next pull request or plan: on
+2026-10-19 one watcher sent on to three pull requests in turn missed that the third's checks had passed at 04:58,
+and the lead told the operator for 15 minutes that they were still running. The next wait gets a fresh watcher,
+and before a report the watcher reads the owning verb once more and says only what it says now.

 **Every ten minutes (the operator, 2026-10-17), every two minutes while a delivery plan runs, and at once when something lands, stops or
 needs the operator,** the lead reports, in one of the two layouts below (the operator, 2026-10-16: an overview