spike(framework): define portable model intent per SDLC step

Start by reading the two agent files, tool-paths.md, tools.md, and the related issues #585, #592, and #654 to map existing model and tool behavior. Done means a maintainer-approved design that assigns vendor-neutral tiers to every shipped SDLC step, supports project and user bindings, defines tool fallbacks and notices, and preserves current behavior when unconfigured.

Problem

The framework already judges which steps need reasoning and which do not, but that judgement is not written anywhere usable. It survives in exactly two files — plugins/aidd-dev/agents/checker.md (L4, model: opus) and plugins/aidd-dev/agents/executor.md (L4, model: sonnet) — and nowhere else. Every other step is silent.

So today a user spends a top-tier model writing a commit message, or runs a critical review on a small one, without knowing it happened and without a way to correct it. The two agents that do carry a model hardcode a vendor name, so a user without access to that model cannot follow the intent at all.

Nothing states, for a given step, what kind of thinking it deserves. Nothing lets a user map that to the models they actually pay for.

Scope

• Express, per SDLC step, the tier of intelligence the step deserves: high for reasoning (brainstorm, plan, review), middle for producing code, low for mechanical work (commit, pull request, execution). Tiers are roles, not vendor names.
• Let a project, and a person within it, bind each tier to the concrete models they actually have. The framework never picks the concrete model.
• Carry that intent through to the tool wherever the tool can receive a model choice, so the tier is honored and not merely documented.
• Degrade without breaking where the tool cannot receive it. Codex CLI drops model even on agents, and no tool accepts a model on a skill.
• Make the intent visible to the user: which tier a step expects, and when their setup cannot supply it. A silent fallback is a failure of this need.
• Ship the step-to-tier judgement as a framework default that holds for everyone, adjustable by exception rather than redeclared in full by each project.
• Leave an unconfigured install behaving exactly as it does today.

Acceptance criteria

• For any SDLC step the framework ships, a reader can find out which tier it expects, and that answer names no vendor and no concrete model.
• Two projects with different model access can each state their own three tiers, and neither has to edit anything the framework ships.
• Two people on the same project can end up on different concrete models for the same step, without either changing what the project committed.
• On a tool that accepts a model choice, running a step uses the model that project bound to that step's tier, verifiable from the tool's own session record.
• On a tool that cannot receive a model choice, the same step runs to completion and reports nothing broken.
• When a setup cannot supply the tier a step expects, the user sees a notice; nothing falls back silently.
• With nothing configured, every step behaves exactly as it does today.

Prior art in this repo

• plugins/aidd-dev/agents/checker.md (L4) and plugins/aidd-dev/agents/executor.md (L4) — the high/middle split already exists, hardcoded to opus / sonnet, agents only.
• plugins/aidd-context/skills/06-agent-generate/references/tool-paths.md (L21–27) — per-tool frontmatter support: Claude Code, Cursor, OpenCode and Copilot accept model; Codex CLI drops it. Same file (L19) holds the canonical-then-emit-what-the-tool-accepts pattern, which this should reuse rather than duplicate.
• No SKILL.md in the repo carries a model field, and no tool accepts one at skill level — which is why the steps this issue is about cannot be handled the way agents are.
• plugins/aidd-context/skills/02-project-memory/references/tools.md — the five supported tools and their detection signals.
• #585 — .aidd/config.yml host-neutral project policy, already carrying a project → user → plugin-defaults precedence. A candidate home for the binding, not a decided one.
• #592 — project agents materialized into tool trees; a candidate carrier for the intent, not a decision here.
• #654 — price table keyed by model; a tier-to-model binding is what makes those figures attributable to a step.

Out of scope

• Choosing where the tier-to-model binding is stored, and in what format. .aidd/config.yml (#585) is one candidate among others; picking one is a design step, not part of stating this need.
• Choosing what carries the intent to the tool — project memory, agent materialization (#592), or something else. Deliberately undecided here.
• Whether project memory generation should seed the binding, or whether that is a separate action.
• Whether the exception adjustment works per step or only per tier.
• Rewriting the two hardcoded vendor names in aidd-dev/agents/. A consequence of whatever mechanism is chosen, not a deliverable of this issue.
• Any cost measurement. The saving is assumed here, not quantified; measurement lives with #654, #629 and #297.
• Adding a model field to skills. No tool supports it.

Relations

Proposed, needs maintainer confirmation — model selection is not in #584's stated scope, so the parent claim is a suggestion, not a fact.

Nothing blocks this issue. Stating the need does not wait on any other ticket; only a chosen design would, and no design is chosen here.