claudecode-omc 5.6.6 → 5.6.8

package/.local/skills/swift-concurrency-expert/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: swift-concurrency-expert
+description: Swift Concurrency review and remediation for Swift 6.2+. Use when asked to review Swift Concurrency usage, improve concurrency compliance, or fix Swift concurrency compiler errors in a feature or file. Concrete actions include adding Sendable conformance, applying @MainActor annotations, resolving actor isolation warnings, fixing data race diagnostics, and migrating completion handlers to async/await.
+---
+
+# Swift Concurrency Expert
+
+## Overview
+
+Review and fix Swift Concurrency issues in Swift 6.2+ codebases by applying actor isolation, Sendable safety, and modern concurrency patterns with minimal behavior changes.
+
+## Workflow
+
+### 1. Triage the issue
+
+- Capture the exact compiler diagnostics and the offending symbol(s).
+- Check project concurrency settings: Swift language version (6.2+), strict concurrency level, and whether approachable concurrency (default actor isolation / main-actor-by-default) is enabled.
+- Identify the current actor context (`@MainActor`, `actor`, `nonisolated`) and whether a default actor isolation mode is enabled.
+- Confirm whether the code is UI-bound or intended to run off the main actor.
+
+### 2. Apply the smallest safe fix
+
+Prefer edits that preserve existing behavior while satisfying data-race safety.
+
+Common fixes:
+- **UI-bound types**: annotate the type or relevant members with `@MainActor`.
+- **Protocol conformance on main actor types**: make the conformance isolated (e.g., `extension Foo: @MainActor SomeProtocol`).
+- **Global/static state**: protect with `@MainActor` or move into an actor.
+- **Background work**: move expensive work into a `@concurrent` async function on a `nonisolated` type or use an `actor` to guard mutable state.
+- **Sendable errors**: prefer immutable/value types; add `Sendable` conformance only when correct; avoid `@unchecked Sendable` unless you can prove thread safety.
+
+### 3. Verify the fix
+
+- Rebuild and confirm all concurrency diagnostics are resolved with no new warnings introduced.
+- Run the test suite to check for regressions — concurrency changes can introduce subtle runtime issues even when the build is clean.
+- If the fix surfaces new warnings, treat each one as a fresh triage (return to step 1) and resolve iteratively until the build is clean and tests pass.
+
+### Examples
+
+**UI-bound type — adding `@MainActor`**
+
+```swift
+// Before: data-race warning because ViewModel is accessed from the main thread
+// but has no actor isolation
+class ViewModel: ObservableObject {
+    @Published var title: String = ""
+    func load() { title = "Loaded" }
+}
+
+// After: annotate the whole type so all stored state and methods are
+// automatically isolated to the main actor
+@MainActor
+class ViewModel: ObservableObject {
+    @Published var title: String = ""
+    func load() { title = "Loaded" }
+}
+```
+
+**Protocol conformance isolation**
+
+```swift
+// Before: compiler error — SomeProtocol method is nonisolated but the
+// conforming type is @MainActor
+@MainActor
+class Foo: SomeProtocol {
+    func protocolMethod() { /* accesses main-actor state */ }
+}
+
+// After: scope the conformance to @MainActor so the requirement is
+// satisfied inside the correct isolation context
+@MainActor
+extension Foo: SomeProtocol {
+    func protocolMethod() { /* safely accesses main-actor state */ }
+}
+```
+
+**Background work with `@concurrent`**
+
+```swift
+// Before: expensive computation blocks the main actor
+@MainActor
+func processData(_ input: [Int]) -> [Int] {
+    input.map { heavyTransform($0) }   // runs on main thread
+}
+
+// After: hop off the main actor for the heavy work, then return the result
+// The caller awaits the result and stays on its own actor
+nonisolated func processData(_ input: [Int]) async -> [Int] {
+    await Task.detached(priority: .userInitiated) {
+        input.map { heavyTransform($0) }
+    }.value
+}
+
+// Or, using a @concurrent async function (Swift 6.2+):
+@concurrent
+func processData(_ input: [Int]) async -> [Int] {
+    input.map { heavyTransform($0) }
+}
+```
+
+## Reference material
+
+- See `references/swift-6-2-concurrency.md` for Swift 6.2 changes, patterns, and examples.
+- See `references/approachable-concurrency.md` when the project is opted into approachable concurrency mode.
+- See `references/swiftui-concurrency-tour-wwdc.md` for SwiftUI-specific concurrency guidance.

package/.local/skills/swift-concurrency-expert/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Swift Concurrency Expert"
+  short_description: "Review and fix Swift concurrency"
+  default_prompt: "Use $swift-concurrency-expert to review this Swift code for concurrency issues and fix the relevant diagnostics."

package/.local/skills/swift-concurrency-expert/references/approachable-concurrency.md

@@ -0,0 +1,63 @@
+## Approachable Concurrency (Swift 6.2) - project mode quick guide
+
+Use this reference when the project has opted into the Swift 6.2 approachable
+concurrency settings (default actor isolation / main-actor-by-default).
+
+## Detect the mode
+
+Check Xcode build settings under "Swift Compiler - Concurrency":
+- Swift language version (must be 6.2+).
+- Default actor isolation / Main Actor by default.
+- Strict concurrency checking level (Complete/Targeted/Minimal).
+
+For SwiftPM, inspect Package.swift swiftSettings for the same flags.
+
+## Behavior changes to expect
+
+- Async functions stay on the caller's actor by default; they don't hop to a
+  global concurrent executor unless the implementation chooses to.
+- Main-actor-by-default reduces data race errors for UI-bound code and global
+  state, because mutable state is implicitly protected.
+- Protocol conformances can be isolated (e.g., `extension Foo: @MainActor Bar`).
+
+## How to apply fixes in this mode
+
+- Prefer minimal annotations; let main-actor-by-default do the work when the
+  code is UI-bound.
+- Use isolated conformances instead of forcing `nonisolated` workarounds.
+- Keep global or shared mutable state on the main actor unless there is a clear
+  performance need to offload it.
+
+## When to opt out or offload work
+
+- Use `@concurrent` on async functions that must run on the concurrent pool.
+- Make types or members `nonisolated` only when they are truly thread-safe and
+  used off the main actor.
+- Continue to respect Sendable boundaries when values cross actors or tasks.
+
+## Common pitfalls
+
+- `Task.detached` ignores inherited actor context; avoid it unless you truly
+  need to break isolation.
+- Main-actor-by-default can hide performance issues if CPU-heavy work stays on
+  the main actor; move that work into `@concurrent` async functions.
+
+## Keywords (from source cheat sheet)
+
+| Keyword | What it does |
+| --- | --- |
+| `async` | Function can pause |
+| `await` | Pause here until done |
+| `Task { }` | Start async work, inherits context |
+| `Task.detached { }` | Start async work, no inherited context |
+| `@MainActor` | Runs on main thread |
+| `actor` | Type with isolated mutable state |
+| `nonisolated` | Opts out of actor isolation |
+| `Sendable` | Safe to pass between isolation domains |
+| `@concurrent` | Always run on background (Swift 6.2+) |
+| `async let` | Start parallel work |
+| `TaskGroup` | Dynamic parallel work |
+
+## Source
+
+https://fuckingapproachableswiftconcurrency.com/en/

package/.local/skills/swift-concurrency-expert/references/swift-6-2-concurrency.md

@@ -0,0 +1,272 @@
+## Concurrent programming updates in Swift 6.2
+
+Concurrent programming is hard because sharing memory between multiple tasks is prone to mistakes that lead to unpredictable behavior.
+
+## Data-race safety
+
+ Data-race safety in Swift 6 prevents these mistakes at compile time, so you can write concurrent code without fear of introducing hard-to-debug runtime bugs. But in many cases, the most natural code to write is prone to data races, leading to compiler errors that you have to address. A class with mutable state, like this `PhotoProcessor` class, is safe as long as you don’t access it concurrently.
+
+```swift
+class PhotoProcessor {
+  func extractSticker(data: Data, with id: String?) async -> Sticker? {     }
+}
+
+@MainActor
+final class StickerModel {
+  let photoProcessor = PhotoProcessor()
+
+  func extractSticker(_ item: PhotosPickerItem) async throws -> Sticker? {
+    guard let data = try await item.loadTransferable(type: Data.self) else {
+      return nil
+    }
+
+    // Error: Sending 'self.photoProcessor' risks causing data races
+    // Sending main actor-isolated 'self.photoProcessor' to nonisolated instance method 'extractSticker(data:with:)'
+    // risks causing data races between nonisolated and main actor-isolated uses
+    return await photoProcessor.extractSticker(data: data, with: item.itemIdentifier)
+  }
+}
+```
+
+ It has an async method to extract a `Sticker` by computing the subject of the given image data. But if you try to call `extractSticker` from UI code on the main actor, you’ll get an error that the call risks causing data races. This is because there are several places in the language that offload work to the background implicitly, even if you never needed code to run in parallel.
+
+Swift 6.2 changes this philosophy to stay single threaded by default until you choose to introduce concurrency.
+
+```swift
+class PhotoProcessor {
+  func extractSticker(data: Data, with id: String?) async -> Sticker? {     }
+}
+
+@MainActor
+final class StickerModel {
+  let photoProcessor = PhotoProcessor()
+
+  func extractSticker(_ item: PhotosPickerItem) async throws -> Sticker? {
+    guard let data = try await item.loadTransferable(type: Data.self) else {
+      return nil
+    }
+
+    // No longer a data race error in Swift 6.2 because of Approachable Concurrency and default actor isolation
+    return await photoProcessor.extractSticker(data: data, with: item.itemIdentifier)
+  }
+}
+```
+
+The language changes in Swift 6.2 make the most natural code to write data race free by default. This provides a more approachable path to introducing concurrency in a project.
+
+When you choose to introduce concurrency because you want to run code in parallel, data-race safety will protect you.
+
+First, we've made it easier to call async functions on types with mutable state. Instead of eagerly offloading async functions that aren't tied to a specific actor, the function will continue to run on the actor it was called from. This eliminates data races because the values passed into the async function are never sent outside the actor. Async functions can still offload work in their implementation, but clients don’t have to worry about their mutable state.
+
+Next, we’ve made it easier to implement conformances on main actor types. Here I have a protocol called `Exportable`, and I’m trying to implement a conformance for my main actor `StickerModel` class. The export requirement doesn’t have actor isolation, so the language assumed that it could be called from off the main actor, and prevented `StickerModel` from using main actor state in its implementation.
+
+```swift
+protocol Exportable {
+  func export()
+}
+
+extension StickerModel: Exportable { // error: Conformance of 'StickerModel' to protocol 'Exportable' crosses into main actor-isolated code and can cause data races
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+Swift 6.2 supports these conformances. A conformance that needs main actor state is called an *isolated* conformance. This is safe because the compiler ensures a main actor conformance is only used on the main actor.
+
+```swift
+// Isolated conformances
+
+protocol Exportable {
+  func export()
+}
+
+extension StickerModel: @MainActor Exportable {
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+ I can create an `ImageExporter` type that adds a `StickerModel` to an array of any `Exportable` items as long as it stays on the main actor.
+
+```swift
+ // Isolated conformances
+
+@MainActor
+struct ImageExporter {
+  var items: [any Exportable]
+
+  mutating func add(_ item: StickerModel) {
+    items.append(item)
+  }
+
+  func exportAll() {
+    for item in items {
+      item.export()
+    }
+  }
+}
+```
+
+But if I allow `ImageExporter` to be used from anywhere, the compiler prevents adding `StickerModel` to the array because it isn’t safe to call export on `StickerModel` from outside the main actor.
+
+```swift
+// Isolated conformances
+
+nonisolated
+struct ImageExporter {
+  var items: [any Exportable]
+
+  mutating func add(_ item: StickerModel) {
+    items.append(item) // error: Main actor-isolated conformance of 'StickerModel' to 'Exportable' cannot be used in nonisolated context
+  }
+
+  func exportAll() {
+    for item in items {
+      item.export()
+    }
+  }
+}
+```
+
+With isolated conformances, you only have to solve data race safety issues when the code indicates that it uses the conformance concurrently.
+
+## Global State
+
+Global and static variables are prone to data races because they allow mutable state to be accessed from anywhere.
+
+```swift
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init() // error: Static property 'shared' is not concurrency-safe because non-'Sendable' type 'StickerLibrary' may have shared mutable state
+}
+```
+
+The most common way to protect global state is with the main actor.
+
+```swift
+final class StickerLibrary {
+  @MainActor
+  static let shared: StickerLibrary = .init()
+}
+```
+
+ And it’s common to annotate an entire class with the main actor to protect all of its mutable state, especially in a project that doesn’t have a lot of concurrent tasks.
+
+```swift
+@MainActor
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init()
+}
+```
+
+You can model a program that's entirely single-threaded by writing `@MainActor` on everything in your project.
+
+```swift
+@MainActor
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init()
+}
+
+@MainActor
+final class StickerModel {
+  let photoProcessor: PhotoProcessor
+
+  var selection: [PhotosPickerItem]
+}
+
+extension StickerModel: @MainActor Exportable {
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+To make it easier to model single-threaded code, we’ve introduced a mode to infer main actor by default.
+
+```swift
+// Mode to infer main actor by default in Swift 6.2
+
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init()
+}
+
+final class StickerModel {
+  let photoProcessor: PhotoProcessor
+
+  var selection: [PhotosPickerItem]
+}
+
+extension StickerModel: Exportable {
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+ This eliminates data-race safety errors about unsafe global and static variables, calls to other main actor functions like ones from the SDK, and more, because the main actor protects all mutable state by default. It also reduces concurrency annotations in code that’s mostly single-threaded. This mode is great for projects that do most of the work on the main actor, and concurrent code is encapsulated within specific types or files. It’s opt-in and it’s recommended for apps, scripts, and other executable targets.
+
+## Offloading work to the background
+
+Offloading work to the background is still important for performance, such as keeping apps responsive when performing CPU-intensive tasks.
+
+Let’s look at the implementation of the `extractSticker` method on `PhotoProcessor`.
+
+```swift
+// Explicitly offloading async work
+
+class PhotoProcessor {
+  var cachedStickers: [String: Sticker]
+
+  func extractSticker(data: Data, with id: String) async -> Sticker {
+      if let sticker = cachedStickers[id] {
+        return sticker
+      }
+
+      let sticker = await Self.extractSubject(from: data)
+      cachedStickers[id] = sticker
+      return sticker
+  }
+
+  // Offload expensive image processing using the @concurrent attribute.
+  @concurrent
+  static func extractSubject(from data: Data) async -> Sticker { }
+}
+```
+
+It first checks whether it already extracted a sticker for an image, so it can return the cached sticker immediately. If the sticker hasn’t been cached, it extracts the subject from the image data and creates a new sticker. The `extractSubject` method performs expensive image processing that I don’t want to block the main actor or any other actor.
+
+I can offload this work using the `@concurrent` attribute. `@concurrent` ensures that a function always runs on the concurrent thread pool, freeing up the actor to run other tasks at the same time.
+
+### An example
+
+Say you have a function called `process` that you would like to run on a background thread. To call that function on a background thread you need to:
+
+- make sure the structure or class is `nonisolated`
+- add the `@concurrent` attribute to the function you want to run in the background
+- add the keyword `async` to the function if it is not already asynchronous
+- and then add the keyword `await` to any callers
+
+Like this:
+
+```swift
+nonisolated struct PhotoProcessor {
+
+    @concurrent
+    func process(data: Data) async -> ProcessedPhoto? { ... }
+}
+
+// Callers with the added await
+processedPhotos[item.id] = await PhotoProcessor().process(data: data)
+```
+
+
+## Summary
+
+These language changes work together to make concurrency more approachable.
+
+You start by writing code that runs on the main actor by default, where there’s no risk of data races. When you start to use async functions, those functions run wherever they’re called from. There’s still no risk of data races because all of your code still runs on the main actor. When you’re ready to embrace concurrency to improve performance, it’s easy to offload specific code to the background to run in parallel.
+
+Some of these language changes are opt-in because they require changes in your project to adopt. You can find and enable all of the approachable concurrency language changes under the Swift Compiler - Concurrency section of Xcode build settings. You can also enable these features in a Swift package manifest file using the SwiftSettings API.
+
+ Swift 6.2 includes migration tooling to help you make the necessary code changes automatically. You can learn more about migration tooling at swift.org/migration.

package/.local/skills/swift-concurrency-expert/references/swiftui-concurrency-tour-wwdc.md

@@ -0,0 +1,33 @@
+# SwiftUI Concurrency Tour (Summary)
+
+Context: SwiftUI-focused concurrency overview covering actor isolation, Sendable closures, and how SwiftUI runs work off the main thread.
+
+## Main-actor default in SwiftUI
+
+- `View` is `@MainActor` isolated by default; members and `body` inherit isolation.
+- Swift 6.2 can infer `@MainActor` for all types in a module (new language mode).
+- This default simplifies UI code and aligns with UIKit/AppKit `@MainActor` APIs.
+
+## Where SwiftUI runs code off the main thread
+
+- SwiftUI may evaluate some view logic on background threads for performance.
+- Examples: `Shape` path generation, `Layout` methods, `visualEffect` closures, and `onGeometryChange` closures.
+- These APIs often require `Sendable` closures to reflect their runtime semantics.
+
+## Sendable closures and data-race safety
+
+- Accessing `@MainActor` state from a `Sendable` closure is unsafe and flagged by the compiler.
+- Prefer capturing value copies in the closure capture list (e.g., copy a `Bool`).
+- Avoid sending `self` into a sendable closure just to read a single property.
+
+## Structuring async work with SwiftUI
+
+- SwiftUI action callbacks are synchronous so UI updates (like loading states) can be immediate.
+- Use `Task` to bridge into async contexts; keep async bodies minimal.
+- Use state as the boundary: async work updates model/state; UI reacts synchronously.
+
+## Performance-driven concurrency
+
+- Offload expensive work from the main actor to avoid hitches.
+- Keep time-sensitive UI logic (animations, gesture responses) synchronous.
+- Separate UI code from long-running async work to improve responsiveness and testability.

package/.local/skills/swiftui-expert-skill/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: swiftui-expert-skill
+description: Use when writing, reviewing, or refactoring SwiftUI code for iOS or macOS, including state management, view composition, performance, Liquid Glass adoption, or Instruments `.trace` capture/analysis for hangs, hitches, CPU hotspots, or
+  excessive view updates.
+---
+
+# SwiftUI Expert Skill
+
+## Operating Rules
+
+- Consult `references/latest-apis.md` at the start of every task to avoid deprecated APIs
+- Prefer native SwiftUI APIs over UIKit/AppKit bridging unless bridging is necessary
+- Focus on correctness and performance; do not enforce specific architectures (MVVM, VIPER, etc.)
+- Encourage separating business logic from views for testability without mandating how
+- Follow Apple's Human Interface Guidelines and API design patterns
+- Only adopt Liquid Glass when explicitly requested by the user (see `references/liquid-glass.md`)
+- Present performance optimizations as suggestions, not requirements
+- Use `#available` gating with sensible fallbacks for version-specific APIs
+
+## Task Workflow
+
+### Review existing SwiftUI code
+- Read the code under review and identify which topics apply
+- Flag deprecated APIs (compare against `references/latest-apis.md`)
+- Run the Topic Router below for each relevant topic
+- Validate `#available` gating and fallback paths for iOS 26+ features
+
+### Improve existing SwiftUI code
+- Audit current implementation against the Topic Router topics
+- Replace deprecated APIs with modern equivalents from `references/latest-apis.md`
+- Refactor hot paths to reduce unnecessary state updates
+- Extract complex view bodies into separate subviews
+- Suggest image downsampling when `UIImage(data:)` is encountered (optional optimization, see `references/image-optimization.md`)
+
+### Implement new SwiftUI feature
+- Design data flow first: identify owned vs injected state
+- Structure views for optimal diffing (extract subviews early)
+- Apply correct animation patterns (implicit vs explicit, transitions)
+- Use `Button` for all tappable elements; add accessibility grouping and labels
+- Gate version-specific APIs with `#available` and provide fallbacks
+
+### Record a new Instruments trace
+Trigger when the user asks to "record a trace", "profile the app", "capture a session", etc. Full reference: `references/trace-recording.md`.
+
+1. **Confirm target** — attach to a running app, launch an app, or record all processes? If the user didn't say, ask. List connected devices when useful:
+   ```bash
+   python3 "${SKILL_DIR}/scripts/record_trace.py" --list-devices
+   ```
+2. **Pick a template based on target kind** — the `SwiftUI` template populates the SwiftUI lane on any **real device**: a physical iOS/iPadOS device **or the host Mac**. The only exception is the **iOS Simulator**, where the SwiftUI lane comes back empty — switch to `--template "Time Profiler"` in that case (still gives Time Profiler + Hangs + Animation Hitches). Always check `--list-devices`: `simulators` kind → `Time Profiler`; `devices` kind (real devices and the host Mac) → default `SwiftUI`. Full decision table in `references/trace-recording.md`.
+3. **Start the recording**. For agent-driven sessions where the user says "I'll tell you when I'm done", start in the background and use a stop-file:
+   ```bash
+   python3 "${SKILL_DIR}/scripts/record_trace.py" \
+       --device "<name|udid>" --attach "<AppName>" \
+       --stop-file /tmp/stop-trace --output ~/Desktop/session.trace
+   ```
+   For interactive sessions, just tell the user to press Ctrl+C when done.
+4. **Signal stop** — when the user says they've finished exercising the app, `touch /tmp/stop-trace`. The script cleanly SIGINTs xctrace and waits up to 60s for finalisation.
+5. **Analyse** the resulting trace (flow into the "Trace-driven improvement" workflow below).
+
+### Trace-driven improvement (Instruments `.trace` provided)
+Trigger whenever the user's request references a `.trace` file. A target SwiftUI source file is **optional** — if given, cite specific lines; if not, recommend where to look based on view names and symbols the trace already reveals.
+
+Full reference: `references/trace-analysis.md`. Summary of the composition pattern:
+
+1. **Scope the analysis.** Ask yourself: does the user want the whole trace, or a slice?
+   - "focus on X / after X / between X and Y / during X" → **resolve to a window first** (see step 2).
+   - No scoping cue → analyse the whole trace.
+2. **Resolve a window (only if the user scoped).** The parser exposes two discovery modes:
+   ```bash
+   # Find a log that marks the start/end of the region of interest:
+   python3 "${SKILL_DIR}/scripts/analyze_trace.py" --trace <path> \
+       --list-logs --log-message-contains "loaded feed" --log-limit 5
+   # Or list os_signpost intervals (paired begin/end), filterable by name:
+   python3 "${SKILL_DIR}/scripts/analyze_trace.py" --trace <path> \
+       --list-signposts --signpost-name-contains "ImageDecode"
+   ```
+   Both modes accept `--window START_MS:END_MS` to scope discovery. Pick the `time_ms` (for logs) or `start_ms`/`end_ms` (for signposts) that match the user's description. Build a window like `--window 10400:11700`.
+3. **Run the main analysis** (with or without `--window`):
+   ```bash
+   python3 "${SKILL_DIR}/scripts/analyze_trace.py" --trace <path> \
+       --json-only --top 10 [--window START_MS:END_MS]
+   ```
+4. **Interpret with `references/trace-analysis.md`** — key diagnostics:
+   - `main_running_coverage_pct` inside each correlation (<25% = blocked; ≥75% = CPU-bound).
+   - `swiftui-causes.top_sources` reveals *why* updates keep happening — high-edge-count sources like `UserDefaultObserver.send()` or wide `EnvironmentWriter` entries are structural invalidation bugs. Fixing one often collapses many downstream hot views.
+5. **When a specific view shows as expensive, ask who's invalidating it.** Use `--fanin-for "<view name>"` to get the ranked list of source nodes driving the updates.
+6. **Optionally ground in source.** If the user pointed at a file, read it and match view names / user-code symbols against identifiers there. If not, recommend which files to open based on the view names SwiftUI reported.
+7. **Return a prioritised plan.** Cite evidence (coverage %, hot symbol, overlapping view, log timestamp, cause-graph edges) and route each recommendation to a Topic Router reference.
+8. Only edit code if the user asked for edits.
+
+### Topic Router
+
+Consult the reference file for each topic relevant to the current task:
+
+| Topic | Reference |
+|-------|-----------|
+| State management | `references/state-management.md` |
+| View composition | `references/view-structure.md` |
+| Performance | `references/performance-patterns.md` |
+| Lists and ForEach | `references/list-patterns.md` |
+| Layout | `references/layout-best-practices.md` |
+| Sheets and navigation | `references/sheet-navigation-patterns.md` |
+| ScrollView | `references/scroll-patterns.md` |
+| Focus management | `references/focus-patterns.md` |
+| Animations (basics) | `references/animation-basics.md` |
+| Animations (transitions) | `references/animation-transitions.md` |
+| Animations (advanced) | `references/animation-advanced.md` |
+| Accessibility | `references/accessibility-patterns.md` |
+| Swift Charts | `references/charts.md` |
+| Charts accessibility | `references/charts-accessibility.md` |
+| Image optimization | `references/image-optimization.md` |
+| Liquid Glass (iOS 26+) | `references/liquid-glass.md` |
+| macOS scenes | `references/macos-scenes.md` |
+| macOS window styling | `references/macos-window-styling.md` |
+| macOS views | `references/macos-views.md` |
+| Text patterns | `references/text-patterns.md` |
+| Deprecated API lookup | `references/latest-apis.md` |
+| Instruments trace analysis | `references/trace-analysis.md` |
+| Instruments trace recording | `references/trace-recording.md` |
+
+## Correctness Checklist
+
+These are hard rules -- violations are always bugs:
+
+- [ ] `@State` properties are `private`
+- [ ] `@Binding` only where a child modifies parent state
+- [ ] Passed values never declared as `@State` or `@StateObject` (they ignore updates)
+- [ ] `@StateObject` for view-owned objects; `@ObservedObject` for injected
+- [ ] iOS 17+: `@State` with `@Observable`; `@Bindable` for injected observables needing bindings
+- [ ] `ForEach` uses stable identity (never `.indices` for dynamic content)
+- [ ] Constant number of views per `ForEach` element
+- [ ] `.animation(_:value:)` always includes the `value` parameter
+- [ ] `@FocusState` properties are `private`
+- [ ] No redundant `@FocusState` writes inside tap gesture handlers on `.focusable()` views
+- [ ] iOS 26+ APIs gated with `#available` and fallback provided
+- [ ] `import Charts` present in files using chart types
+
+## References
+
+- `references/latest-apis.md` -- **Read first for every task.** Deprecated-to-modern API transitions (iOS 15+ through iOS 26+)
+- `references/state-management.md` -- Property wrappers, data flow, `@Observable` migration
+- `references/view-structure.md` -- View extraction, container patterns, `@ViewBuilder`
+- `references/performance-patterns.md` -- Hot-path optimization, update control, `_logChanges()`
+- `references/list-patterns.md` -- ForEach identity, Table (iOS 16+), inline filtering pitfalls
+- `references/layout-best-practices.md` -- Layout patterns, GeometryReader alternatives
+- `references/accessibility-patterns.md` -- VoiceOver, Dynamic Type, grouping, traits
+- `references/animation-basics.md` -- Implicit/explicit animations, timing, performance
+- `references/animation-transitions.md` -- View transitions, `matchedGeometryEffect`, `Animatable`
+- `references/animation-advanced.md` -- Phase/keyframe animations (iOS 17+), `@Animatable` macro (iOS 26+)
+- `references/charts.md` -- Swift Charts marks, axes, selection, styling, Chart3D (iOS 26+)
+- `references/charts-accessibility.md` -- Charts VoiceOver, Audio Graph, fallback strategies
+- `references/sheet-navigation-patterns.md` -- Sheets, NavigationSplitView, Inspector
+- `references/scroll-patterns.md` -- ScrollViewReader, programmatic scrolling
+- `references/focus-patterns.md` -- Focus state, focusable views, focused values, default focus, common pitfalls
+- `references/image-optimization.md` -- AsyncImage, downsampling, caching
+- `references/liquid-glass.md` -- iOS 26+ Liquid Glass effects and fallback patterns
+- `references/macos-scenes.md` -- Settings, MenuBarExtra, WindowGroup, multi-window
+- `references/macos-window-styling.md` -- Toolbar styles, window sizing, Commands
+- `references/macos-views.md` -- HSplitView, Table, PasteButton, AppKit interop
+- `references/text-patterns.md` -- Text initializer selection, verbatim vs localized
+- `references/trace-analysis.md` -- Parse Instruments `.trace` files via `scripts/analyze_trace.py`; interpret main-thread coverage, high-severity SwiftUI updates, hitch narratives, and map findings back to source files
+- `references/trace-recording.md` -- Record a new trace via `scripts/record_trace.py`: attach to a running app, launch one fresh, or capture a manually-stopped session; supports stop-file for agent-driven flows