model-ladderlisted

Condensed binding of Part 2 of the edition committed in this repo. On any conflict, the edition text wins; load it with `bash "${CLAUDE_PLUGIN_ROOT}/scripts/part.sh" 2`, or read Part 2 in the edition file committed at the repo root. The ladder is stated as capability tiers; model names are bindings that churn, held in one table the edition's Changelog updates per edition. - **Planning tier** does the deciding: architecture, spec design, steering changes. **Execution tier** does the typing: code, edits, tests, Git. **Escalation tier** is the strongest model the harness offers, reserved for the moments that earn it. - Default binding: `opusplan`. The planning tier runs in plan mode (deep reasoning, read-only), the execution tier in execution mode. Plan mode is read-only, so the planner decides and the executor types; that is fine, because the quality that matters in planning is the deciding. - Escalate the Builder when it loops: a bug that survives two fix attempts, or a fix that spawns new failures, moves the build session one tier up. Do not keep feeding the loop; escalation is cheaper than the churn, and far cheaper than a wrong fix that ships. - Heavyweight planning (session zero, a major spec revision, a steering change) runs a dedicated session on the escalation tier, so the whole session reasons at full strength. - De-escalate after the escalated session closes its spec or fix: the next ordinary session returns to `opusplan`. - Roles bind to art