From 6e90fa443ede3703efcfe2e2d60b92a5602c1fbc Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 10 Nov 2026 17:24:02 +0100 Subject: [PATCH] Compare seat contracts with the design in the prepare, and call a verdictless merge unchecked On 2026-11-10 a seat contract and an event's subject that differed from design 47 surfaced only in develop, and the checker twice dropped a check still running when its pull request merged. The prepare now compares every seat contract the milestone touches with its design lines, each difference a design question before develop; and a merged change with no verdict is reported as unchecked, never as passed. Claude-Session: https://claude.ai/code/session_01JG73KK8HD1gufnqyFxMFdW --- .claude/agents/mesh-preparer.md | 4 +++- 00-META/process/07-feature-branches.md | 11 ++++++++++- 00-META/process/08-small-fixes.md | 4 +++- 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/.claude/agents/mesh-preparer.md b/.claude/agents/mesh-preparer.md index 47bd4dd8..f63c3d25 100644 --- a/.claude/agents/mesh-preparer.md +++ b/.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, diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 8d6f4b9a..49cfa221 100644 --- a/00-META/process/07-feature-branches.md +++ b/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 diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index b212d3d6..59812c12 100644 --- a/00-META/process/08-small-fixes.md +++ b/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