.claude/agents/mesh-preparer.md

@@ -23,7 +23,9 @@ proves each; the order of the subtasks (a subtask that uses a contract, type, ve
 adds starts from that subtask's commit; contracts and packages first) and one writer per file; the section `What
 exists today` with its three answers, every search written as run; the design line that places each new exported
 type, field, constant, package or module; the one placement of the siblings every agent uses, as the running checker
-places them; the test budget. Code: read the repositories at `origin/main` (`git fetch`, `git show`, `git grep`),
+places them; the test budget. Compare each seat contract the milestone adds or changes (its fields, subjects,
+callers and kinds, as on main) with the design lines that name that seat, field by field: every difference is a
+design question. Code: read the repositories at `origin/main` (`git fetch`, `git show`, `git grep`),
 never a working tree; the live mesh through its tools.
 
 **Everything the design does not say is a design question, never your answer.** A reader or an effect with no fate,

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

@@ -186,6 +186,10 @@ breach the lead names at the next report.
       design line gives a fate is a design question. For every new exported type, field, constant, package or module,
       the answer names the design line that places it (the milestone part's, or the design section *Where a seat's
       code goes*): where new code goes is always the design's, never the lead's own choice.
+      **A seat's contract is a design line's form too.** For each seat contract the milestone adds or changes, the
+      answer compares what the contract on main says (its fields, subjects, callers and kinds) with the design lines
+      that name that seat, field by field; every difference is a design question (item 10), answered before develop
+      (2026-11-10: a seat contract and an event's subject that differed from the design surfaced only in develop).
    Code starts only when the three answers are complete for every repository: no fixing agent starts on a build map
    without them, and an effect found later is the prepare step missed, written into the answer and its issue before the
    fix. In the days up to 2026-11-02 the controller was taken apart without this answer: jobs nobody had named (making
@@ -533,7 +537,12 @@ an answer no hq commit holds, is a finding of the review (step 2, item 2a).
    build), each of which a run as the checker places things would have shown before the first push. How it is
    checked: the pull request's description names the placement, the node-engine commit and the manifest validator run used
    locally; a check that fails on a placement the local run did not use is named by the lead at the next report.
-2. **The checker's merge check runs the integration tests once, as the gate** (its one status, `mesh/check`). No
+2. **The checker's merge check runs the integration tests once, as the gate** (its one status, `mesh/check`).
+   **A merge with no verdict is unchecked, never passed.** Until the pipeline runner replaces the checker, the
+   checker drops a check still running when its pull request merges (met twice on 2026-11-10): the lead reads the
+   check's verdict (`mesh-delivery.show`) after every merge, and a merged change whose check has none is reported to
+   the operator as merged unchecked, with what its local runs covered, never as passed. How it is checked: a report
+   that says a merged change passed is read against its verdict in `mesh-delivery.show`. No
    second review: step 2 reviewed this tree.
 3. **A check that fails** goes back to the same reviewer, continued by its id, with the failure, for **one more cycle** of step 2 with
    the same fixing agents; then push **once** again (the one more push of ADR 0548). The check is **read, never re-asked to see if it passes**: a

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

@@ -84,7 +84,9 @@ processing power"). Everything before the push is local and fast, and no try is
 5. **Push the reviewed head once and open the pull request, only after the review approves.** The trunk is what runs and nothing holds merged work back
    (ADR 0401), so a fix waits for no other change's delivery. No pull request, draft or not, exists before the review
    approves the head, and no fix round is pushed to an open pull request: every push to an open pull request asks a new
-   check. The checker's merge check runs the unit and the integration level once, as the gate (playbook [07](07-feature-branches.md) step 3); the pushed head is read from the forge first, as playbook 07 step 3 item 1 says.
+   check. The checker's merge check runs the unit and the integration level once, as the gate (playbook [07](07-feature-branches.md) step 3); the pushed head is read from the forge first, as playbook 07 step 3 item 1 says. A merge whose check has no verdict
+   (the checker drops a check still running at the merge) is reported to the operator as merged unchecked, never as
+   passed (playbook 07 step 3 item 2).
    A failed check is read from its whole log (never re-asked to see if it passes), then the repository's whole integration level
    is run locally (`go test -tags integration -count=1 ./...` in each module) so every failure shows at once, where a verdict
    names only the first (issue 1921); the failures go back to the same agent, fixed in one change, the reviewer reads only the change