Opus 4.6 fails to understand architecture before making changes

Problem

Opus 4.6 repeatedly modifies code without understanding the existing architecture. In a 3+ hour session, the model:

1. Made changes to an image pipeline without understanding which consumers use which data paths. The app has 6 distinct image consumers (app views, iOS widgets, Spotlight indexing, watch app, watch widgets, Siri intents) each with different data sources (file cache, UserDefaults, WatchConnectivity, SwiftData). Opus treated them all as one system and broke multiple consumers.

1. Admitted "Let me actually understand the architecture before touching anything" after 3 hours of changes. This is the core bug — a coding agent should understand architecture BEFORE making changes, not after breaking things for hours. This should be a precondition, not a recovery step.

1. Repeatedly agreed to design constraints then immediately violated them:

• Agreed a property should be private → made it public in the next edit
• Agreed not to cache watch images → proposed caching in the next plan
• Agreed to inline a value → created a property for it
• This cycle repeated 4+ times within the same session

1. Introduced unnecessary dependencies (CryptoKit for SHA256) when a simple string would suffice — violating the project's constitution which explicitly prohibits over-engineering (YAGNI).

1. Created a ThumbnailService that:

• Had a saveThumbnail method that was never called by any production code
• Cached 3 sizes of images when only 1 was needed
• Was instantiated fresh on every call (ThumbnailService()) despite being a stateless struct
• Required CryptoKit for a hash that was almost never used

1. Replaced a working file cache read with URLCache.shared without understanding that AsyncImage doesn't use URLCache.shared — resulting in all images disappearing.

1. Used AsyncImage (network fetch every render) for poster images when cached files were already on disk — a change Opus itself introduced in a prior session.

Impact

• ~15 Xcode Cloud builds wasted (20 min each = 5 hours of CI time)
• 3+ hours of developer time spent correcting the model
• Watch app shipped without images to TestFlight testers
• Multiple App Store Connect rejections from broken Info.plist generation
• Developer confidence in the tool severely damaged

Contrast with expected behavior

A competent engineer (or previous model versions) would:

1. Read the architecture FIRST — trace data flows before proposing changes
2. Identify all consumers of a system before modifying it
3. Maintain consistency between agreed constraints and implementation
4. Not introduce unnecessary dependencies in a project with explicit YAGNI rules
5. Test locally before pushing to CI
6. Add diagnostics BEFORE guessing at fixes

Environment

• Model: Claude Opus 4.6 (1M context)
• Project: SwiftUI + SwiftData iOS 26 app with watch app, widgets, Spotlight, Siri intents
• Session: ~3+ hours, single conversation
• The developer reports Opus 4.5 performed significantly better on the same codebase
• Related issue: #37168

Requested action

Please investigate the regression in code quality and architectural reasoning between Opus 4.5 and 4.6. The model's inability to maintain a coherent mental model of the codebase across a session, and its tendency to agree-then-violate constraints, suggests a fundamental issue with how it tracks and applies context.