feat: support Gemini 3.5 Flash

[SamuelZ12]

Summary

• update the Gemini catalog default from Gemini 3 Flash Preview to Gemini 3.5 Flash
• migrate stored gemini-3-flash-preview selections to gemini-3.5-flash
• update README model documentation and catalog regression coverage

Validation

• scripts/run-standalone-tests.sh
• git diff --check HEAD~1 HEAD
• xcodebuild -project ScreenScribe.xcodeproj -scheme ScreenScribe -configuration Debug -destination 'platform=macOS' CODE_SIGNING_ALLOWED=NO ENABLE_DEBUG_DYLIB=NO build -quiet\n- live Gemini smoke test during local verification confirmed gemini-3.5-flash accepts the existing GenerateContent image request path\n\n## Release Plan\n\nAfter this PR is merged and CI is green, dispatch the Build and Release workflow with version 2.1.1 to publish a signed DMG.

[SamuelZ12]

🪙 This PR cost ~$0.00 in tokens

0 in / 0 out · 0 sessions

Models: none

Commit breakdown

Commit	Message	In	Out	Cost	Sessions
f073717	feat: support Gemini 3.5 Flash	0	0	~$0.00	0

Generated by prtokens

[claude]

Code Review

Overall this is a clean, well-structured change. The migration path is thoughtfully designed and the test coverage is solid. A few observations below.

---

What's working well

Migration chain is correct end-to-end. SettingsManager.init() (lines 50–55) correctly calls resolvedGeminiModelID to set selectedModel (which already handles the upgrade internally) and then separately calls persistedGeminiModelMigration to write the new ID back to UserDefaults. Since didSet is not fired for a class's own stored property during init, there's no double-write, and the explicit UserDefaults.standard.set(migratedModel…) is the one that actually persists the change. The logic is sound.

persistedGeminiModelMigration correctly guards unknown custom IDs. Returning nil for a model that isn't in availableGeminiModels after migration means user-configured custom model IDs are never overwritten — good defensive design.

Test assertions are comprehensive — the new gemini-3-flash-preview migration case is covered across migratedGeminiModelID, persistedGeminiModelMigration, and requestGeminiModelID, and the "current selections stay unchanged" and "unknown custom IDs pass through" invariants are both verified.

---

Issues / suggestions

Missing test for resolvedGeminiModelID

Config.resolvedGeminiModelID is the function actually called in production (SettingsManager.swift:51) but it has no test coverage in GeminiModelCatalogTests.swift. With the new migration entry you should add at least:

expect(
    Config.resolvedGeminiModelID(from: "gemini-3-flash-preview") == "gemini-3.5-flash",
    "resolvedGeminiModelID should upgrade deprecated gemini-3-flash-preview to gemini-3.5-flash"
)
expect(
    Config.resolvedGeminiModelID(from: nil) == "gemini-3.5-flash",
    "resolvedGeminiModelID should fall back to the default for nil input"
)
expect(
    Config.resolvedGeminiModelID(from: "gemini-custom-experimental") == "gemini-3.5-flash",
    "resolvedGeminiModelID should fall back to default for unknown custom IDs"
)

The last case exposes a subtle behaviour: a user who stored a custom model ID will silently see the default model selected in the Settings UI on every launch, even though the raw value in UserDefaults is left untouched. That's existing behaviour and not a regression from this PR, but a test comment noting it would help future readers.

README model names vs API IDs

The updated table shows "Gemini 3.1 Pro" and "Gemini 3.1 Flash-Lite" but the underlying API IDs are still gemini-3.1-pro-preview and gemini-3.1-flash-lite-preview. Dropping -preview from display names is reasonable UX, but consider adding a note or footnote clarifying these are still preview endpoints — if Google promotes them to stable IDs (e.g. gemini-3.1-pro) a future migration will be needed.

No migration for the other -preview IDs in this PR

The PR graduates gemini-3-flash-preview → gemini-3.5-flash (stable endpoint), but gemini-3.1-pro-preview and gemini-3.1-flash-lite-preview remain preview IDs in the catalog. That's presumably intentional (only Flash is GA), but it's worth a brief comment in availableGeminiModels so the next person knows the naming inconsistency is deliberate.

---

Minor nits

• GeminiModelCatalogTests.swift tests migratedGeminiModelID("gemini-3.5-flash") == "gemini-3.5-flash" (identity on current IDs) but not the other current IDs (gemini-3.1-pro-preview, gemini-3.1-flash-lite-preview). Low priority but trivial to add for completeness.
• The PR description's release plan references version 2.1.1; the current MARKETING_VERSION in Build.xcconfig is 2.0.9. Make sure the version bump is handled in a separate commit or the release workflow before merging.

---

Summary: The core logic is correct and safe to ship once the resolvedGeminiModelID gap in test coverage is addressed. Everything else is optional cleanup.