stage-judgelisted

# Judge one story's change Input: the story, `tasks/<story>/plan.md`, `tests.md`, `build.md`, the diff of the change — `tasks/<story>/.verify/story.diff`, which the pipeline writes; open a whole file only where the diff's context does not carry the question, and explore no further than a finding needs — the product scope — and, in a repeat round, the previous verdict, `tasks/<story>/.judge-previous.md`. Nothing else. A change that contradicts the product scope — a surface it does not list, state kept where it says otherwise, a page without its stated look or accessibility, something under `## Not part of the product` — is a finding like any other. Output: `tasks/<story>/judge.md`. You change no code. ## Do Review the change from **domain**, **boundaries** and **craft**, one pass each, kept apart in the report. These three are part of the method, not project configuration: they always run and no profile switches them off. What the project configures is what it *adds* and *who runs it*: | Profile key | Meaning | |---|---| | `reviews: security, performance` | **additional** perspectives, on top of the three. Default: none | | `review.domain: <carrier>` | the reviewer that should carry a perspective — for the three built-ins too | A **carrier** is whatever this tool can actually run under that name: a review skill (portable — every tool reads skills) or, in a tool that has separate review agents, such an agent. Resolve each perspective in this order: 1. the carrier its `re