Developer definition: the validator run as the checker does it (review round 1)

Built at mesh-delivery's trunk unless the change alters the validator; raw
manifests in the two cases change and trunk; every manifest whose verdict
differs is reported, an unchanged one included (ADR 0579 §2).

Issue 1585.

Claude-Session: https://claude.ai/code/session_01JG73KG7AfSdh6FP8VrBqCn

.claude/agents/mesh-code-reviewer.md

@@ -29,8 +29,9 @@ against the records, never limits on what you check: a ruling that contradicts a
   function where the repository is over budget, real sleeping;
 - vet or tests that fail: run `go vet ./...`, `go vet -tags integration ./...` and `go test ./...` in every
   touched module, as the running checker places siblings.
-- a changed `module.json` without the manifest validator's verdict from the developer, or with one that refuses
-  or holds it: the merge check would fail on it only after a full build.
+- a change to any `module.json` reported without the manifest validator's verdicts (every manifest whose verdict
+  differs between the change and the trunk), or with a manifest it refuses or holds: the merge check would fail
+  on it only after a full build.
 
 Anything else (hardening, a further case, a nicer form) is a note, never a round. Read only: no edits, no git
 write, no verb that writes, never ssh. Use a temporary directory under `/var/tmp`.

.claude/agents/mesh-developer.md

@@ -32,12 +32,15 @@ sleeping. Run `go vet ./...`, `go vet -tags integration ./...` and `go test ./..
 the running checker places siblings (playbook 07). Use a temporary directory under `/var/tmp` (TMPDIR). Before you
 report a head, also run the repository's own checks whole (in the catalog every `checks/*`): a head that passes its
 modules' tests can still break a check of the whole repository, such as a committed binary or an unannounced state.
-When the change touches any `module.json`, in any repository, run the manifest validator over every manifest of the
-mesh with the change's heads laid over the trunk, as the checker does: the program `cmd/mesh-judge` in the indexer's
-module, built from the change's head of mesh-delivery, given the request the checker's `judgeRequest` builds. A
-manifest the validator refuses or holds fails the merge check only after a full build, and the unit tests of the
-module that owns it do not run the validator; report each changed manifest's verdict with your heads. The reviewer
-asks for those verdicts, and a head reported without them is not reviewed.
+When the change touches any `module.json`, in any repository, run the manifest validator as the checker does: the
+program `cmd/mesh-judge` in the indexer's module, built at mesh-delivery's trunk, or at the change's mesh-delivery
+head when that head changes the validator itself (then the indexer's own manifest is also validated at the trunk).
+Give it raw manifests, not digests: the trunk's, with the change's laid over them, as the two cases `change` and
+`trunk` the checker's `judgeRequest` names, with the predefined key list when the change alters it. The merge check
+fails a changed manifest the validator refuses or holds, and also an unchanged one in which the change causes a
+problem the trunk case lacks; it says so only after a full build, and no module's unit tests run the validator.
+Report every manifest whose verdict differs between the two cases, with your heads. The reviewer asks for those
+verdicts, and a head reported without them is not reviewed.
 Start no agents of your own: the lead decides who works on what.
 
 **Stop at about two thirds of your context.** Commit what is done, write a section under your agent label at the