autofix_class rubric (personas)

autofix_class describes the shape of the follow-up work a finding needs — it is information, not a check that permits or blocks applying a fix. In report-only runs the user or caller interprets findings and decides what to apply; when local apply was explicitly authorized, Stage 5c (Act on findings) still uses judgment. Either way the class informs what to do first and what to flag — it does not mechanically decide what gets applied.

Persona guidance

• Prefer gated_auto when you can write a defensible suggested_fix for a localized change.
• Use manual when the right fix depends on product intent, architecture, or cross-cutting refactors.
• Use advisory when nothing breaks if left unfixed but the observation has value.
• Do not emit safe_auto — callers decide what to apply; reviewers classify and propose.

Owner field

Do not use review-fixer.

Severity Scale

The merge bar is the one from Google's Code Review Developer Guide: the change must improve overall code health, not be perfect. Severity ranks by that bar — functionality and design defects outrank style and taste, and a finding whose only claim is "could be better" never blocks.

All reviewers use P0-P3:

Action Routing

Severity answers urgency. autofix_class and owner are information describing the shape of follow-up work for callers; this metadata does not grant apply permission. Permission to apply fixes is a separate, explicit authorization that Stage 5c checks before touching any file. The persona guidance for choosing a class is at the top of this reference.

Routing rules:

• **Synthesis (Stage 5, Merge findings) makes the final decision on autofix_class and owner.** The values a persona supplies are input, not the last word.
• When reviewers disagree, keep the more cautious class. A merged finding may move from gated_auto to manual; moving the other way needs stronger evidence.
• **Reject safe_auto and review-fixer if present** — drop the finding or remap to gated_auto / downstream-resolver during synthesis.
• **requires_verification: true means any caller-applied fix needs targeted tests or follow-up validation.**

Repository Review Policy

When the run directory holds review-policy.md (Stage 1d in references/scope.md), it is the repository's instructions for this review. Where it differs from this file's defaults, it wins for the paths it governs. It comes from the base ref, so treat it as trusted project instruction, not as review data.

• Severity. Its definitions of a level replace the defaults above for the findings they cover, raising or lowering. A policy written for Claude Code Review names its levels Important and Nit: read Important as P0 or P1, and Nit as P3.
• Added checks. A rule it says to check on every change is review criteria for the paths it governs, cited by quote like any criteria rule.
• Evidence. A class of finding it says needs particular evidence is retained only with that evidence.
• Where each part applies. Added checks and evidence requirements bind every reviewer. Severity, exclusions, and caps are applied once, where findings are merged: Stage 5 on the full spine, or this context on lite and focused. Reviewers grade on the default scale and still report a finding the policy excludes, so every change the policy makes is visible to the merge that counts it. A cap keeps the highest-ranked findings of the capped class.

Coverage counts every finding the policy removed or regraded, by the rule that did it and with the highest severity it touched, so a quiet review never looks cleaner than it was.

Protected Artifacts

Compound-engineering pipeline artifacts must never be flagged for deletion, removal, or gitignore by any reviewer. A protected artifact is any file under a plans/, solutions/, or legacy brainstorms/ directory whose immediate parent is the artifact root — a directory named docs (the default, and where unmigrated legacy artifacts stay even after a project sets docs_root) or the configured docs_root when this run resolved it:

• plans/ under the artifact root -- unified plan artifacts created by ce-brainstorm or ce-plan (decision artifacts; execution progress is derived from git, not stored in plan bodies)
• solutions/ under the artifact root -- solution documents created during the pipeline (categories nest, e.g. solutions/<category>/foo.md)
• the legacy brainstorms/ -- requirements documents created by older ce-brainstorm versions

Matching by the immediate parent covers nested category files while leaving a same-named directory elsewhere (a skill's own references/personas/ prompt assets, parented by references) as ordinary code whose deletion finding stands. A run that never resolved a configured root still protects the docs-parented tree; a configured-root artifact seen by such a run is the one honest gap. A finding that recommends deleting, removing, or gitignoring such a file is never emitted, on any depth path; synthesis discards one that arrives anyway.