Request: Allow selecting Opus 4.5 model in /model command

Problem

Opus 4.6 produces significantly worse code quality than previous versions. User requests ability to select Opus 4.5 as a fallback, or for the code quality regressions to be addressed.

Specific failures observed in a single session

1. Repeated constitutional violations

The project has a constitution.md with clear rules (YAGNI, no unnecessary types, lean idiomatic Swift). Opus 4.6 repeatedly violated these despite having them in context and memory:

• Introduced CryptoKit dependency for a SHA256 hash when a simple string would suffice
• Created a ThumbnailService class that wrapped trivial file I/O in unnecessary abstraction
• Cached 3 image sizes to disk when only 1 was needed
• Created ThumbnailSize enum used in one place

2. Agreeing to feedback then immediately doing the opposite

• Agreed cacheIdentifier should be private, then made it public in the next edit
• Agreed not to cache watch images, then proposed caching in the next plan
• Agreed to a design, then implemented something different
• This happened 4+ times in a single session

3. Inability to design from the consumer perspective

• Spent over an hour iterating on internal architecture (ThumbnailService refactors, URL vs Data, public vs private) instead of starting from the consumer need: show.poster returns an Image
• Required the user to guide the model step-by-step to the obvious solution
• When told "start from what the consumer needs," still proposed service objects and indirection

4. Fragile code duplication

• Scattered show.imdbID ?? show.title.lowercased()... across multiple files instead of keeping it in one place
• When told this was fragile, created a property. When told the property was unnecessary, removed it. When told the inline version was fragile, got stuck in a loop.

5. Basic coding errors

• Placed computed properties outside a struct (syntax error)
• Used let binding inside a SwiftUI @ViewBuilder which broke the result builder chain, causing the entire Settings section to not render
• Used AsyncImage (network fetch every render) instead of reading from an existing on-disk cache — introduced by Opus itself in a prior refactor
• Put version number display inside a conditional that only showed when data was present — the exact state being debugged was when data was absent
• Wrapped a List in a VStack on watchOS which made the entire view act as a button, preventing scrolling

6. Excessive guessing instead of building diagnostics

• Spent an hour guessing at WatchConnectivity issues instead of adding user-visible diagnostics to the Settings page
• Only added diagnostics after being told explicitly, which immediately revealed the actual problem
• All #if DEBUG logging was useless because the app was running via TestFlight (release builds)

7. Repeated failed attempts at the same fix

• Toggled SKIP_INSTALL between true/false across 4 commits without testing locally
• Only tested locally after being called out, which immediately showed the correct value

8. Poor confidence calibration

• Started at 90% confidence, dropped to 40%, then 20% as the user poked holes in each plan
• A competent engineer would have identified the issues before presenting the plan

Environment

• iOS 26 / watchOS 26 / Xcode 26 (production, not beta)
• SwiftUI + SwiftData + Swift 6.2
• XcodeGen for project generation
• Xcode Cloud for CI/CD

Expected behavior

The model should:

• Read and comply with project constitution/rules on first pass
• Design from consumer perspective without being told
• Not agree to constraints then immediately violate them
• Test changes before committing (especially for CI/CD pipeline changes)
• Add diagnostics early when debugging device-only issues
• Maintain consistent architecture decisions within a session

Model info

• Model: Claude Opus 4.6 (1M context)
• Session length: ~3 hours
• The user reports previous model versions (Opus 4.5) performed significantly better on the same codebase