Sonnet floor for persona reviewers + honest review-preferences semantics

plugins/compound-engineering/skills/ce-review/SKILL.md

@@ -377,11 +377,11 @@ Pass the resulting path list to the `project-standards` persona inside a `<stand
 
 #### Model tiering
 
-Persona sub-agents do focused, scoped work and should use cheaper/faster models to reduce cost and latency. The orchestrator itself stays on the default (most capable) model.
+Reviewing is judgment work, and a reviewer that returns shallow or malformed findings costs more than the model tier saves -- dropped findings, re-review rounds, false confidence. The floor for judgment work is a mid-tier model, not the cheapest one.
 
-Use the platform's cheapest capable model for all persona and CE sub-agents. In Claude Code, pass `model: "haiku"` in the Agent tool call. On other platforms, use the equivalent fast/cheap tier (e.g., `gpt-4o-mini` in Codex). If the platform has no model override mechanism or the available model names are unknown, omit the model parameter and let agents inherit the default -- a working review on the parent model is better than a broken dispatch from an unrecognized model name.
+When an orchestrator persona defines `agent-model:` in its frontmatter, that value wins -- pass it as `model:` on every persona and CE sub-agent dispatch. Otherwise, pass `model: "sonnet"` in Claude Code (or the equivalent mid-tier on other platforms). If the platform has no model override mechanism or the available model names are unknown, omit the model parameter and let agents inherit the default -- a working review on the parent model is better than a broken dispatch from an unrecognized model name.
 
-CE always-on agents (agent-native-reviewer, learnings-researcher) and CE conditional agents (schema-drift-detector, deployment-verification-agent) also use the cheaper model tier since they perform scoped, focused work.
+The cheapest tier (`haiku` in Claude Code) is reserved for mechanical, spec-driven sub-tasks -- file searches, concrete summarization -- not for persona reviewers, whose whole job is judgment.
 
 The orchestrator (this skill) stays on the default model because it handles intent discovery, reviewer selection, finding merge/dedup, and synthesis -- tasks that benefit from stronger reasoning.
 

plugins/compound-engineering/skills/ce-run/SKILL.md

@@ -78,14 +78,9 @@ For each phase in the `phases` list from frontmatter:
 
 ## Step 6: Review preferences
 
-When invoking `/ce:review`, pass the orchestrator's `review-preferences` and `synthesis` configuration as context:
+When invoking `/ce:review`, pass the orchestrator's `review-preferences` and `synthesis` configuration as context. The orchestrator's own definitions govern their semantics — common keys include a reviewer `team`, a `max-reviewers` cap, a `reviewer-model` floor, and `synthesis.lens` (passed to the synthesis pass to shape how findings are weighted).
 
-- **min-reviewers** — Minimum number of reviewers to spawn
-- **require-categories** — Categories that must be represented (warn if no reviewer available)
-- **prefer-categories** — Categories to include if available
-- **synthesis.lens** — Pass this to the synthesis reviewer to shape how findings are weighted
-
-These preferences guide reviewer selection but don't override the existing ce:review selection logic — they add constraints on top of it.
+When the orchestrator declares `roster: replace`, its team SUBSTITUTES for ce:review's default reviewer selection (keeping only the pipeline anchors the orchestrator names) — never spawn both rosters. Without `roster: replace`, preferences add constraints on top of ce:review's own selection, still respecting any `max-reviewers` cap. Running the orchestrator's roster on top of the default set is how review phases have ballooned past a dozen concurrent agents.
 
 ## Step 7: Model selection