refactor(types): canonicalize shared provider settings identifiers

[WebMad]

Summary

• replace raw discriminator literals in shared provider settings schemas with providerIdentifiers
• use computed canonical identifier keys in modelIdKeysByProvider
• canonicalize keys and repeated id values in MODELS_BY_PROVIDER
• derive provider exclusions from typeof providerIdentifiers.<provider>
• add regression coverage that keeps provider-indexed settings aligned with the canonical registry

Implements item 1 from #944 (comment).

Test plan

• pnpm exec vitest run src/__tests__/provider-settings.test.ts src/__tests__/provider-identifiers.test.ts from packages/types
• pnpm exec eslint src/provider-settings.ts src/__tests__/provider-identifiers.test.ts --max-warnings=0 from packages/types
• pnpm run check-types from packages/types
• repository commit/push hooks, including workspace lint and type checking

Summary by CodeRabbit

• Bug Fixes

  • Improved consistency of provider identification across model settings and provider-specific configurations.
  • Ensured provider mappings use canonical identifiers, reducing the risk of mismatched or invalid model associations.

• Tests

  • Added coverage to verify provider identifiers remain aligned across supported model configurations.
  • Confirmed designated providers are correctly handled in model ID mappings.

[coderabbitai]

Warning

Review limit reached

@WebMad, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 48 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 01681801-78cd-4586-9655-4d310a9e0861

📥 Commits

Reviewing files that changed from the base of the PR and between fe11b3b and 9819602.

📒 Files selected for processing (2)

• packages/types/src/__tests__/provider-identifiers.test.ts
• packages/types/src/provider-settings.ts

📝 Walkthrough

Walkthrough

The change replaces hard-coded provider identifiers in provider settings and model mappings with providerIdentifiers constants. Tests now verify alignment between canonical identifiers, provider-indexed model settings, and model collection provider IDs.

Changes

Provider identifier consistency

Layer / File(s)	Summary
Canonical provider settings and model mappings packages/types/src/provider-settings.ts	Provider-specific schemas, modelIdKeysByProvider, and MODELS_BY_PROVIDER now use providerIdentifiers constants. Provider entries and exclusions remain unchanged.
Provider mapping consistency validation packages/types/src/__tests__/provider-identifiers.test.ts	Tests verify canonical provider keys, excluded providers, and matching provider IDs in MODELS_BY_PROVIDER entries.

Estimated code review effort: 2 (Simple) | ~15 minutes

Possibly related PRs

• Zoo-Code-Org/Zoo-Code#793: Refactors related provider settings and mappings.
• Zoo-Code-Org/Zoo-Code#952: Establishes canonical providerIdentifiers used by this change.
• Zoo-Code-Org/Zoo-Code#1022: Uses the same canonical identifiers in extension-side provider comparisons.

Suggested labels: awaiting-review

Suggested reviewers: taltas, edelauna

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the canonicalization of shared provider settings identifiers.
Description check	✅ Passed	The description explains the implementation and test procedure, but it omits the template headings and pre-submission checklist.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[edelauna]

Nice! Had some implementation comments to help clean up this section while we're touching it.

[edelauna]

Since every discriminator here now comes from providerIdentifiers rather than an inline literal, a typo (e.g. picking the wrong registry key) would compile fine and only 32 of the 34 branches are unparsed by any test in the repo — only openaiCodex and kimi-code get a round-trip through providerSettingsSchemaDiscriminated. Worth adding a loop over Object.values(providerIdentifiers) that asserts safeParse succeeds for each?

[edelauna]

The keys here are type-checked against TypicalProvider, but the values (ModelIdKey) aren't constrained to the right provider — e.g. nothing would catch anthropic pointing at "openRouterModelId". This map now drives form validation in webview-ui/src/utils/validate.ts:218. Is there a test that pins each provider to its expected key?

[edelauna]

Could use a one-line comment on why these three are excluded (openai is the custom provider, geminiCli/fakeAi have no model list) — it's not obvious from the type alone and the surrounding blocks explain their groupings.