Opus 4.6 ignores well-known platform constraints (widget memory/performance)

Problem

Opus 4.6 repeatedly forgets or ignores well-known iOS platform constraints that any iOS developer would know. In this session, it:

1. Proposed that iOS widgets read full-size image data and resize on the fly. Widgets run in a severely constrained environment (~30MB memory limit). They must read pre-computed data from App Group shared storage. This is fundamental iOS knowledge — not an obscure edge case.

1. Had to be told this despite the codebase already implementing the correct pattern. The existing code writes pre-sized widget data to the App Group. Opus proposed replacing this with on-the-fly resizing, which would break widgets.

1. This is part of a broader pattern of ignoring platform constraints:

• Proposed synchronous network calls inside SwiftUI computed properties
• Used AsyncImage (network on every render) when cached files existed on disk
• Proposed CryptoKit for a filename hash when a simple string sufficed
• Repeatedly proposed changes that would violate the app's own constitution (YAGNI, no unnecessary abstractions)

Expected behavior

A coding agent working on iOS should have baseline knowledge of:

• Widget memory and performance constraints
• The App Group shared storage pattern for widgets
• That widgets read pre-computed data, not compute on the fly
• SwiftUI view body evaluation constraints (no blocking I/O)
• The difference between app process and extension process capabilities

These are not advanced topics — they are covered in Apple's introductory WidgetKit documentation and are standard practice for any iOS developer.

Context

• Related issues: #37168, #37174
• Model: Claude Opus 4.6 (1M context)
• Same session as the architecture and code quality issues
• The codebase already had the correct widget pattern implemented — the model proposed replacing it with a broken one