Adopt the model-family standard (name a family, never pin a version) in petry-projects/.github #1208

Adopt the maintainer-approved standard from Ideas Discussion #1199 across the org-wide petry-projects/.github repo: workflows suggest a Claude model family (opus, sonnet, haiku) and never hard-code a version id such as claude-opus-4-6. A resolver/CLI maps family -> current model id, so upgrades roll out through the normal release channels instead of leaving stale pins across the fleet. Today the BMAD Business Analyst (feature-ideation) still runs the pinned claude-opus-4-6, two Opus generations behind.

Allowed exceptions (each marked inline with # model-pin-ok: <reason>): the resolver itself; price data keyed by real ids; recorded data (fixtures, eval sets, baselines); a fixed eval judge (must stay pinned so A/B stays comparable). An operator-supplied full-id override (workflow input or Actions variable) stays allowed - only defaults in code must name a family.

Scope (source-of-truth files in this repo): the Model selection standard in standards/agent-standards.md (cross-linked from standards/ci-standards.md); the model input default in .github/workflows/feature-ideation-reusable.yml; the three model-pin statements in standards/ci-standards.md section 9; the stub-template comments in standards/workflows/feature-ideation.yml; a new model-version-pin lint; and the release of the reusable change via its channel tag. Synced copies in consumer repos are NOT hand-edited - they arrive through standards sync.

Success metrics (initiative-level):

• Zero claude-(opus|sonnet|haiku|fable)-[0-9] version pins remain outside # model-pin-ok: exceptions - the new lint is green.
• Time-to-upgrade on a new Opus release drops from a manual multi-file edit to <= 1 week (a single claude-code-action version/tag bump), measured from Anthropic release to first run on the new model.
• No regression in adversarial-pass depth of feature-ideation output after the model change (qualitative review of proposal/objection quality vs the prior Opus 4.6 baseline).
• Per-run cost stays within 2x the current baseline.
• Fleet consistency: the same alias resolves to the same model across repos on the direct Anthropic API (spot-check resolved model ids in run logs).

Cost cap / budget bound: feature-ideation runs must stay within ~2x the documented ~$2-3 Opus 4.6 baseline (ci-standards.md section 9) - an effective ceiling of ~$6/run. If a future Opus breaches it, operators pin back with an explicit id via the model input or ANTHROPIC_DEFAULT_OPUS_MODEL rather than editing the default. This initiative is a docs/config/lint change; it does not itself dispatch the token-spending feature-ideation workflow.

Source: Ideas Discussion #1199 (maintainer decision 2026-09-29).

Untracked prerequisites

• Sibling implementation & lint for petry-projects/.github-private is [Phase 3] Standard: name a model family, never pin a model version — replace every hard-coded Claude model id and lint for it .github-private#1979 under epic Opus 5.5 engine upgrade: price it, non-regression-validate it, canary the deep tier, then refresh the fallback chains .github-private#1895 - the Phase 3 lint story here MUST align its claude-(opus|sonnet|haiku|fable)-[0-9] regex and exception skip-list with that implementation. This is cross-repo, so it cannot be a GitHub blocked_by edge.
• The Phase 4 release of the feature-ideation-reusable.yml change goes through the Release Manager's channel-tag (v1) process; tags are never hand-moved (idea AC feat: add Structured Logging and CQRS standards #6).
• The 'time-to-upgrade <= 1 week' success metric depends on the pinned claude-code-action version staying current: the family->id alias table ships compiled per action release, so Dependabot/version bumps of claude-code-action must keep pace for the opus alias to resolve to the newest Opus (enhancement comment risk Add coding standards & principles section to AGENTS.md #3).

Planned from idea discussion #1199 by the BMAD Scrum Master initiative-planner. Inert until a maintainer adds initiative:auto.