feat(review): list fanout spec findings first under their own heading, then standards #12138

Parent #7584 decides that /review:fanout gains Lauren Tan's interrogate lead judgment in this form: spec findings first under their own heading, then standards; the agreement map covers both; fanout stays a code review (D101, Q159). The owner approved this 2026-10-15 (poteto-review decision row 101) after withdrawing a rework, because Matt Pocock's Spec axis is a review of code against the spec, not of the spec document. The reason, from the accepted recommendation: one merged list "can drop the one spec gap" when standards findings are many. The parent also records Q169, approved 2026-10-15 (decision row 99): "when a stub phase is committed, fanout may review that diff before fill-in", as a documented use with no new mechanism. On main, fanout's report has ## Findings, ## By dimension, ## Dismissed, ## Unparsed and ## Surfaces (plugins/review/reference/findings-file-shape.md, plugins/review/skills/fanout/SKILL.md Step 2), with no spec or standards split, and the skill never mentions stub scaffolds. The act-on cap is out of scope: the reviewer-diversity eval slice reports, per heading, the position of the planted defect, and a follow-up child sets the cap from that number.

Done when

• plugins/review/skills/fanout/context/findings-normalization.md defines how each normalized finding gets one axis:
  • spec when the finding says the change does not do what the intent paragraph (SKILL.md "Intent paragraph") says it is for, or does only part of it;
  • standards for every other finding;
  • standards for every finding when the intent paragraph reads Intent: not stated.
• plugins/review/reference/findings-file-shape.md "Findings-file shape" adds a ## By axis section after ## By dimension:
  • it has ### Spec first and ### Standards second;
  • every finding in ## Findings appears under exactly one of the two;
  • rows keep merged-rank order and their rank numbers, and keep the Surface(s) column, so the agreement shows under both headings;
  • an empty heading reads none.
• The same file states that the fix action does not parse ## By axis, as it states for ## By dimension. The ## Findings table header line is unchanged from main, and the diff edits no line of plugins/review/skills/fanout/context/fix-pass-mode.md.
• plugins/review/skills/fanout/SKILL.md Step 2 names the axis assignment and the ## By axis section. It also says that fanout reviews the code against its stated purpose and does not review a spec or plan document.
• plugins/review/skills/fanout/SKILL.md says that when a stub-scaffold phase (the planning plugin's scaffold_stubs setting) is committed, fanout may review that diff before the bodies are filled in. It adds no argument, setting or step for this.
• plugins/review/evals/ gains a fanout-spec-first-* case:
  • its case.yaml uses schema_version: "1.1", like guard-removal-null-user/case.yaml;
  • its scaffold commits a change whose message states two goals and implements only one, plus one unrelated correctness defect;
  • its graders check that the persisted findings file has ### Spec before ### Standards, that the missing goal is under ### Spec, and that the defect is under ### Standards;
  • each grader has a samples/<grader>.json with at least one pass and one fail entry, in the shape of guard-removal-null-user/samples/.
• A .changes/review/*.md fragment with bump: minor describes the section and the stub-scaffold use.
• The PR's CI is green.

Out of scope

• The act-on cap and the act-on and consider buckets: they wait for the reviewer-diversity eval's Probe result: and the follow-up child that sets the cap from it.
• Criteria slices loaded from per-concern standards files, and the code-quality lens slice: they wait for standards: per-concern standards layout #7583.
• Changing the fix action or the detector-findings contract.

Related

• standards: per-concern standards layout #7583: per-concern standards layout.

Parent: #7584