@mmerterden/multi-agent-pipeline 16.18.0 → 16.19.0

package/pipeline/skills/shared/external/swiftui-performance-audit/references/optimizing-swiftui-performance-instruments.md

@@ -0,0 +1,29 @@
+# Optimizing SwiftUI Performance with Instruments (Summary)
+
+Context: WWDC session introducing the next-generation SwiftUI Instrument in Instruments 26 and how to diagnose SwiftUI-specific bottlenecks.
+
+## Key takeaways
+
+- Profile SwiftUI issues with the SwiftUI template (SwiftUI instrument + Time Profiler + Hangs/Hitches).
+- Long view body updates are a common bottleneck; use "Long View Body Updates" to identify slow bodies.
+- Set inspection range on a long update and correlate with Time Profiler to find expensive frames.
+- Keep work out of `body`: move formatting, sorting, image decoding, and other expensive work into cached or precomputed paths.
+- Use Cause & Effect Graph to diagnose *why* updates occur; SwiftUI is declarative, so backtraces are often unhelpful.
+- Avoid broad dependencies that trigger many updates (e.g., `@Observable` arrays or global environment reads).
+- Prefer granular view models and scoped state so only the affected view updates.
+- Environment values update checks still cost time; avoid placing fast-changing values (timers, geometry) in environment.
+- Profile early and often during feature development to catch regressions.
+
+## Suggested workflow (condensed)
+
+1. Record a trace in Release mode using the SwiftUI template.
+2. Inspect "Long View Body Updates" and "Other Long Updates."
+3. Zoom into a long update, then inspect Time Profiler for hot frames.
+4. Fix slow body work by moving heavy logic into precomputed/cache paths.
+5. Use Cause & Effect Graph to identify unintended update fan-out.
+6. Re-record and compare the update counts and hitch frequency.
+
+## Example patterns from the session
+
+- Caching formatted distance strings in a location manager instead of computing in `body`.
+- Replacing a dependency on a global favorites array with per-item view models to reduce update fan-out.

package/pipeline/skills/shared/external/swiftui-performance-audit/references/profiling-intake.md

@@ -0,0 +1,44 @@
+# Profiling intake and collection checklist
+
+## Intent
+
+Use this checklist when code review alone cannot explain the SwiftUI performance issue and you need runtime evidence from the user.
+
+## Ask for first
+
+- Exact symptom: CPU spike, dropped frames, memory growth, hangs, or excessive view updates.
+- Exact interaction: scrolling, typing, initial load, navigation push/pop, animation, sheet presentation, or background refresh.
+- Target device and OS version.
+- Whether the issue was reproduced on a real device or only in Simulator.
+- Build configuration: Debug or Release.
+- Whether the user already has a baseline or before/after comparison.
+
+## Default profiling request
+
+Ask the user to:
+- Run the app in a Release build when possible.
+- Use the SwiftUI Instruments template.
+- Reproduce the exact problematic interaction only long enough to capture the issue.
+- Capture the SwiftUI timeline and Time Profiler together.
+- Export the trace or provide screenshots of the key SwiftUI lanes and the Time Profiler call tree.
+
+## Ask for these artifacts
+
+- Trace export or screenshots of the relevant SwiftUI lanes
+- Time Profiler call tree screenshot or export
+- Device/OS/build configuration
+- A short note describing what action was happening at the time of the capture
+- If memory is involved, the memory graph or Allocations data if available
+
+## When to ask for more
+
+- Ask for a second capture if the first run mixes multiple interactions.
+- Ask for a before/after pair if the user has already tried a fix.
+- Ask for a device capture if the issue only appears in Simulator or if scrolling smoothness matters.
+
+## Common traps
+
+- Debug builds can distort SwiftUI timing and allocation behavior.
+- Simulator traces can miss device-only rendering or memory issues.
+- Mixed interactions in one capture make attribution harder.
+- Screenshots without the reproduction note are much harder to interpret.

package/pipeline/skills/shared/external/swiftui-performance-audit/references/report-template.md

@@ -0,0 +1,47 @@
+# Audit output template
+
+## Intent
+
+Use this structure when reporting SwiftUI performance findings so the user can quickly see the symptom, evidence, likely cause, and next validation step.
+
+## Template
+
+```markdown
+## Summary
+
+[One short paragraph on the most likely bottleneck and whether the conclusion is code-backed or trace-backed.]
+
+## Findings
+
+1. [Issue title]
+   - Symptom: [what the user sees]
+   - Likely cause: [root cause]
+   - Evidence: [code reference or profiling evidence]
+   - Fix: [specific change]
+   - Validation: [what to measure after the fix]
+
+2. [Issue title]
+   - Symptom: ...
+   - Likely cause: ...
+   - Evidence: ...
+   - Fix: ...
+   - Validation: ...
+
+## Metrics
+
+| Metric | Before | After | Notes |
+| --- | --- | --- | --- |
+| CPU | [value] | [value] | [note] |
+| Frame drops / hitching | [value] | [value] | [note] |
+| Memory peak | [value] | [value] | [note] |
+
+## Next step
+
+[One concrete next action: apply a fix, capture a better trace, or validate on device.]
+```
+
+## Notes
+
+- Order findings by impact, not by file order.
+- Say explicitly when a conclusion is still a hypothesis.
+- If no metrics are available, omit the table and say what should be measured next.

package/pipeline/skills/shared/external/swiftui-performance-audit/references/understanding-hangs-in-your-app.md

@@ -0,0 +1,33 @@
+# Understanding Hangs in Your App (Summary)
+
+Context: Apple guidance on identifying hangs caused by long-running main-thread work and understanding the main run loop.
+
+## Key concepts
+
+- A hang is a noticeable delay in a discrete interaction (typically >100 ms).
+- Hangs almost always come from long-running work on the main thread.
+- The main run loop processes UI events, timers, and main-queue work sequentially.
+
+## Main-thread work stages
+
+- Event delivery to the correct view/handler.
+- Your code: state updates, data fetch, UI changes.
+- Core Animation commit to the render server.
+
+## Why the main run loop matters
+
+- Only the main thread can update UI safely.
+- The run loop is the foundation that executes main-queue work.
+- If the run loop is busy, it can't handle new events; this causes hangs.
+
+## Diagnosing hangs
+
+- Observe the main run loop's busy periods: healthy loops sleep most of the time.
+- Hang detection typically flags busy periods >250 ms.
+- The Hangs instrument can be configured to lower thresholds.
+
+## Practical takeaways
+
+- Keep main-thread work short; offload heavy work from event handlers.
+- Avoid long-running tasks on the main dispatch queue or main actor.
+- Use run loop behavior as a proxy for user-perceived responsiveness.

package/pipeline/skills/shared/external/swiftui-performance-audit/references/understanding-improving-swiftui-performance.md

@@ -0,0 +1,52 @@
+# Understanding and Improving SwiftUI Performance (Summary)
+
+Context: Apple guidance on diagnosing SwiftUI performance with Instruments and applying design patterns to reduce long or frequent updates.
+
+## Core concepts
+
+- SwiftUI is declarative; view updates are driven by state, environment, and observable data dependencies.
+- View bodies must compute quickly to meet frame deadlines; slow or frequent updates lead to hitches.
+- Instruments is the primary tool to find long-running updates and excessive update frequency.
+
+## Instruments workflow
+
+1. Profile via Product > Profile.
+2. Choose the SwiftUI template and record.
+3. Exercise the target interaction.
+4. Stop recording and inspect the SwiftUI track + Time Profiler.
+
+## SwiftUI timeline lanes
+
+- Update Groups: overview of time SwiftUI spends calculating updates.
+- Long View Body Updates: orange >500us, red >1000us.
+- Long Platform View Updates: AppKit/UIKit hosting in SwiftUI.
+- Other Long Updates: geometry/text/layout and other SwiftUI work.
+- Hitches: frame misses where UI wasn't ready in time.
+
+## Diagnose long view body updates
+
+- Expand the SwiftUI track; inspect module-specific subtracks.
+- Set Inspection Range and correlate with Time Profiler.
+- Use call tree or flame graph to identify expensive frames.
+- Repeat the update to gather enough samples for analysis.
+- Filter to a specific update (Show Calls Made by `MySwiftUIView.body`).
+
+## Diagnose frequent updates
+
+- Use Update Groups to find long active groups without long updates.
+- Set inspection range on the group and analyze update counts.
+- Use Cause graph ("Show Causes") to see what triggers updates.
+- Compare causes with expected data flow; prioritize the highest-frequency causes.
+
+## Remediation patterns
+
+- Move expensive work out of `body` and cache results.
+- Use `Observable()` macro to scope dependencies to properties actually read.
+- Avoid broad dependencies that fan out updates to many views.
+- Reduce layout churn; isolate state-dependent subtrees from layout readers.
+- Avoid storing closures that capture parent state; precompute child views.
+- Gate frequent updates (e.g., geometry changes) by thresholds.
+
+## Verification
+
+- Re-record after changes to confirm reduced update counts and fewer hitches.

package/pipeline/skills/shared/external/swiftui-ui-patterns/references/app-wiring.md

@@ -0,0 +1,201 @@
+# App wiring and dependency graph
+
+## Intent
+
+Show how to wire the app shell (TabView + NavigationStack + sheets) and install a global dependency graph (environment objects, services, streaming clients, SwiftData ModelContainer) in one place.
+
+## Recommended structure
+
+1) Root view sets up tabs, per-tab routers, and sheets.
+2) A dedicated view modifier installs global dependencies and lifecycle tasks (auth state, streaming watchers, push tokens, data containers).
+3) Feature views pull only what they need from the environment; feature-specific state stays local.
+
+## Dependency selection
+
+- Use `@Environment` for app-level services, shared clients, theme/configuration, and values that many descendants genuinely need.
+- Prefer initializer injection for feature-local dependencies and models. Do not move a dependency into the environment just to avoid passing one or two arguments.
+- Keep mutable feature state out of the environment unless it is intentionally shared across broad parts of the app.
+- Use `@EnvironmentObject` only as a legacy fallback or when the project already standardizes on it for a truly shared object.
+
+## Root shell example (generic)
+
+```swift
+@MainActor
+struct AppView: View {
+  @State private var selectedTab: AppTab = .home
+  @State private var tabRouter = TabRouter()
+
+  var body: some View {
+    TabView(selection: $selectedTab) {
+      ForEach(AppTab.allCases) { tab in
+        let router = tabRouter.router(for: tab)
+        NavigationStack(path: tabRouter.binding(for: tab)) {
+          tab.makeContentView()
+        }
+        .withSheetDestinations(sheet: Binding(
+          get: { router.presentedSheet },
+          set: { router.presentedSheet = $0 }
+        ))
+        .environment(router)
+        .tabItem { tab.label }
+        .tag(tab)
+      }
+    }
+    .withAppDependencyGraph()
+  }
+}
+```
+
+Minimal `AppTab` example:
+
+```swift
+@MainActor
+enum AppTab: Identifiable, Hashable, CaseIterable {
+  case home, notifications, settings
+  var id: String { String(describing: self) }
+
+  @ViewBuilder
+  func makeContentView() -> some View {
+    switch self {
+    case .home: HomeView()
+    case .notifications: NotificationsView()
+    case .settings: SettingsView()
+    }
+  }
+
+  @ViewBuilder
+  var label: some View {
+    switch self {
+    case .home: Label("Home", systemImage: "house")
+    case .notifications: Label("Notifications", systemImage: "bell")
+    case .settings: Label("Settings", systemImage: "gear")
+    }
+  }
+}
+```
+
+Router skeleton:
+
+```swift
+@MainActor
+@Observable
+final class RouterPath {
+  var path: [Route] = []
+  var presentedSheet: SheetDestination?
+}
+
+enum Route: Hashable {
+  case detail(id: String)
+}
+```
+
+## Dependency graph modifier (generic)
+
+Use a single modifier to install environment objects and handle lifecycle hooks when the active account/client changes. This keeps wiring consistent and avoids forgetting a dependency in call sites.
+
+```swift
+extension View {
+  func withAppDependencyGraph(
+    accountManager: AccountManager = .shared,
+    currentAccount: CurrentAccount = .shared,
+    currentInstance: CurrentInstance = .shared,
+    userPreferences: UserPreferences = .shared,
+    theme: Theme = .shared,
+    watcher: StreamWatcher = .shared,
+    pushNotifications: PushNotificationsService = .shared,
+    intentService: AppIntentService = .shared,
+    quickLook: QuickLook = .shared,
+    toastCenter: ToastCenter = .shared,
+    namespace: Namespace.ID? = nil,
+    isSupporter: Bool = false
+  ) -> some View {
+    environment(accountManager)
+      .environment(accountManager.currentClient)
+      .environment(quickLook)
+      .environment(currentAccount)
+      .environment(currentInstance)
+      .environment(userPreferences)
+      .environment(theme)
+      .environment(watcher)
+      .environment(pushNotifications)
+      .environment(intentService)
+      .environment(toastCenter)
+      .environment(\.isSupporter, isSupporter)
+      .task(id: accountManager.currentClient.id) {
+        let client = accountManager.currentClient
+        if let namespace { quickLook.namespace = namespace }
+        currentAccount.setClient(client: client)
+        currentInstance.setClient(client: client)
+        userPreferences.setClient(client: client)
+        await currentInstance.fetchCurrentInstance()
+        watcher.setClient(client: client, instanceStreamingURL: currentInstance.instance?.streamingURL)
+        if client.isAuth {
+          watcher.watch(streams: [.user, .direct])
+        } else {
+          watcher.stopWatching()
+        }
+      }
+      .task(id: accountManager.pushAccounts.map(\.token)) {
+        pushNotifications.tokens = accountManager.pushAccounts.map(\.token)
+      }
+  }
+}
+```
+
+Notes:
+- The `.task(id:)` hooks respond to account/client changes, re-seeding services and watcher state.
+- Keep the modifier focused on global wiring; feature-specific state stays within features.
+- Adjust types (AccountManager, StreamWatcher, etc.) to match your project.
+
+## SwiftData / ModelContainer
+
+Install your `ModelContainer` at the root so all feature views share the same store. Keep the list minimal to the models that need persistence.
+
+```swift
+extension View {
+  func withModelContainer() -> some View {
+    modelContainer(for: [Draft.self, LocalTimeline.self, TagGroup.self])
+  }
+}
+```
+
+Why: a single container avoids duplicated stores per sheet or tab and keeps data consistent.
+
+## Sheet routing (enum-driven)
+
+Centralize sheets with a small enum and a helper modifier.
+
+```swift
+enum SheetDestination: Identifiable {
+  case composer
+  case settings
+  var id: String { String(describing: self) }
+}
+
+extension View {
+  func withSheetDestinations(sheet: Binding<SheetDestination?>) -> some View {
+    sheet(item: sheet) { destination in
+      switch destination {
+      case .composer:
+        ComposerView().withEnvironments()
+      case .settings:
+        SettingsView().withEnvironments()
+      }
+    }
+  }
+}
+```
+
+Why: enum-driven sheets keep presentation centralized and testable; adding a new sheet means adding one enum case and one switch branch.
+
+## When to use
+
+- Apps with multiple packages/modules that share environment objects and services.
+- Apps that need to react to account/client changes and rewire streaming/push safely.
+- Any app that wants consistent TabView + NavigationStack + sheet wiring without repeating environment setup.
+
+## Caveats
+
+- Keep the dependency modifier slim; do not put feature state or heavy logic there.
+- Ensure `.task(id:)` work is lightweight or cancelled appropriately; long-running work belongs in services.
+- If unauthenticated clients exist, gate streaming/watch calls to avoid reconnect spam.

package/pipeline/skills/shared/external/swiftui-ui-patterns/references/async-state.md

@@ -0,0 +1,96 @@
+# Async state and task lifecycle
+
+## Intent
+
+Use this pattern when a view loads data, reacts to changing input, or coordinates async work that should follow the SwiftUI view lifecycle.
+
+## Core rules
+
+- Use `.task` for load-on-appear work that belongs to the view lifecycle.
+- Use `.task(id:)` when async work should restart for a changing input such as a query, selection, or identifier.
+- Treat cancellation as a normal path for view-driven tasks. Check `Task.isCancelled` in longer flows and avoid surfacing cancellation as a user-facing error.
+- Debounce or coalesce user-driven async work such as search before it fans out into repeated requests.
+- Keep UI-facing models and mutations main-actor-safe; do background work in services, then publish the result back to UI state.
+
+## Example: load on appear
+
+```swift
+struct DetailView: View {
+  let id: String
+  @State private var state: LoadState<Item> = .idle
+  @Environment(ItemClient.self) private var client
+
+  var body: some View {
+    content
+      .task {
+        await load()
+      }
+  }
+
+  @ViewBuilder
+  private var content: some View {
+    switch state {
+    case .idle, .loading:
+      ProgressView()
+    case .loaded(let item):
+      ItemContent(item: item)
+    case .failed(let error):
+      ErrorView(error: error)
+    }
+  }
+
+  private func load() async {
+    state = .loading
+    do {
+      state = .loaded(try await client.fetch(id: id))
+    } catch is CancellationError {
+      return
+    } catch {
+      state = .failed(error)
+    }
+  }
+}
+```
+
+## Example: restart on input change
+
+```swift
+struct SearchView: View {
+  @State private var query = ""
+  @State private var results: [ResultItem] = []
+  @Environment(SearchClient.self) private var client
+
+  var body: some View {
+    List(results) { item in
+      Text(item.title)
+    }
+    .searchable(text: $query)
+    .task(id: query) {
+      try? await Task.sleep(for: .milliseconds(250))
+      guard !Task.isCancelled, !query.isEmpty else {
+        results = []
+        return
+      }
+      do {
+        results = try await client.search(query)
+      } catch is CancellationError {
+        return
+      } catch {
+        results = []
+      }
+    }
+  }
+}
+```
+
+## When to move work out of the view
+
+- If the async flow spans multiple screens or must survive view dismissal, move it into a service or model.
+- If the view is mostly coordinating app-level lifecycle or account changes, wire it at the app shell in `app-wiring.md`.
+- If retry, caching, or offline policy becomes complex, keep the policy in the client/service and leave the view with simple state transitions.
+
+## Pitfalls
+
+- Do not start network work directly from `body`.
+- Do not ignore cancellation for searches, typeahead, or rapidly changing selections.
+- Avoid storing derived async state in multiple places when one source of truth is enough.

package/pipeline/skills/shared/external/swiftui-ui-patterns/references/components-index.md

@@ -0,0 +1,46 @@
+# Components Index
+
+Use this file to find component and cross-cutting guidance. Each entry lists when to use it.
+
+## Available components
+
+- TabView: `references/tabview.md`  -  Use when building a tab-based app or any tabbed feature set.
+- NavigationStack: `references/navigationstack.md`  -  Use when you need push navigation and programmatic routing, especially per-tab history.
+- Sheets and presentation: `references/sheets.md`  -  Use for local item-driven sheets, centralized modal routing, and sheet-specific action patterns.
+- Form and Settings: `references/form.md`  -  Use for settings, grouped inputs, and structured data entry.
+- macOS Settings: `references/macos-settings.md`  -  Use when building a macOS Settings window with SwiftUI's Settings scene.
+- Split views and columns: `references/split-views.md`  -  Use for iPad/macOS multi-column layouts or custom secondary columns.
+- List and Section: `references/list.md`  -  Use for feed-style content and settings rows.
+- ScrollView and Lazy stacks: `references/scrollview.md`  -  Use for custom layouts, horizontal scrollers, or grids.
+- Scroll-reveal detail surfaces: `references/scroll-reveal.md`  -  Use when a detail screen reveals secondary content or actions as the user scrolls or swipes between full-screen sections.
+- Grids: `references/grids.md`  -  Use for icon pickers, media galleries, and tiled layouts.
+- Theming and dynamic type: `references/theming.md`  -  Use for app-wide theme tokens, colors, and type scaling.
+- Controls (toggles, pickers, sliders): `references/controls.md`  -  Use for settings controls and input selection.
+- Input toolbar (bottom anchored): `references/input-toolbar.md`  -  Use for chat/composer screens with a sticky input bar.
+- Top bar overlays (iOS 26+ and fallback): `references/top-bar.md`  -  Use for pinned selectors or pills above scroll content.
+- Overlay and toasts: `references/overlay.md`  -  Use for transient UI like banners or toasts.
+- Focus handling: `references/focus.md`  -  Use for chaining fields and keyboard focus management.
+- Searchable: `references/searchable.md`  -  Use for native search UI with scopes and async results.
+- Async images and media: `references/media.md`  -  Use for remote media, previews, and media viewers.
+- Haptics: `references/haptics.md`  -  Use for tactile feedback tied to key actions.
+- Matched transitions: `references/matched-transitions.md`  -  Use for smooth source-to-destination animations.
+- Deep links and URL routing: `references/deeplinks.md`  -  Use for in-app navigation from URLs.
+- Title menus: `references/title-menus.md`  -  Use for filter or context menus in the navigation title.
+- Menu bar commands: `references/menu-bar.md`  -  Use when adding or customizing macOS/iPadOS menu bar commands.
+- Loading & placeholders: `references/loading-placeholders.md`  -  Use for redacted skeletons, empty states, and loading UX.
+- Lightweight clients: `references/lightweight-clients.md`  -  Use for small, closure-based API clients injected into stores.
+
+## Cross-cutting references
+
+- App wiring and dependency graph: `references/app-wiring.md`  -  Use to wire the app shell, install shared dependencies, and decide what belongs in the environment.
+- Async state and task lifecycle: `references/async-state.md`  -  Use when a view loads data, reacts to changing input, or needs cancellation/debouncing guidance.
+- Previews: `references/previews.md`  -  Use when adding `#Preview`, fixtures, mock environments, or isolated preview setup.
+- Performance guardrails: `references/performance.md`  -  Use when a screen is large, scroll-heavy, frequently updated, or showing signs of avoidable re-renders.
+
+## Planned components (create files as needed)
+
+
+## Adding entries
+
+- Add the component file and link it here with a short "when to use" description.
+- Keep each component reference short and actionable.

package/pipeline/skills/shared/external/swiftui-ui-patterns/references/controls.md

@@ -0,0 +1,57 @@
+# Controls (Toggle, Slider, Picker)
+
+## Intent
+
+Use native controls for settings and configuration screens, keeping labels accessible and state bindings clear.
+
+## Core patterns
+
+- Bind controls directly to `@State`, `@Binding`, or `@AppStorage`.
+- Prefer `Toggle` for boolean preferences.
+- Use `Slider` for numeric ranges and show the current value in a label.
+- Use `Picker` for discrete choices; use `.pickerStyle(.segmented)` only for 2-4 options.
+- Keep labels visible and descriptive; avoid embedding buttons inside controls.
+
+## Example: toggles with sections
+
+```swift
+Form {
+  Section("Notifications") {
+    Toggle("Mentions", isOn: $preferences.notificationsMentionsEnabled)
+    Toggle("Follows", isOn: $preferences.notificationsFollowsEnabled)
+    Toggle("Boosts", isOn: $preferences.notificationsBoostsEnabled)
+  }
+}
+```
+
+## Example: slider with value text
+
+```swift
+Section("Font Size") {
+  Slider(value: $fontSizeScale, in: 0.5...1.5, step: 0.1)
+  Text("Scale: \(String(format: \"%.1f\", fontSizeScale))")
+    .font(.scaledBody)
+}
+```
+
+## Example: picker for enums
+
+```swift
+Picker("Default Visibility", selection: $visibility) {
+  ForEach(Visibility.allCases, id: \.self) { option in
+    Text(option.title).tag(option)
+  }
+}
+```
+
+## Design choices to keep
+
+- Group related controls in a `Form` section.
+- Use `.disabled(...)` to reflect locked or inherited settings.
+- Use `Label` inside toggles to combine icon + text when it adds clarity.
+
+## Pitfalls
+
+- Avoid `.pickerStyle(.segmented)` for large sets; use menu or inline styles instead.
+- Don't hide labels for sliders; always show context.
+- Avoid hard-coding colors for controls; use theme tint sparingly.

package/pipeline/skills/shared/external/swiftui-ui-patterns/references/deeplinks.md

@@ -0,0 +1,66 @@
+# Deep links and navigation
+
+## Intent
+
+Route external URLs into in-app destinations while falling back to system handling when needed.
+
+## Core patterns
+
+- Centralize URL handling in the router (`handle(url:)`, `handleDeepLink(url:)`).
+- Inject an `OpenURLAction` handler that delegates to the router.
+- Use `.onOpenURL` for app scheme links and convert them to web URLs if needed.
+- Let the router decide whether to navigate or open externally.
+
+## Example: router entry points
+
+```swift
+@MainActor
+final class RouterPath {
+  var path: [Route] = []
+  var urlHandler: ((URL) -> OpenURLAction.Result)?
+
+  func handle(url: URL) -> OpenURLAction.Result {
+    if isInternal(url) {
+      navigate(to: .status(id: url.lastPathComponent))
+      return .handled
+    }
+    return urlHandler?(url) ?? .systemAction
+  }
+
+  func handleDeepLink(url: URL) -> OpenURLAction.Result {
+    // Resolve federated URLs, then navigate.
+    navigate(to: .status(id: url.lastPathComponent))
+    return .handled
+  }
+}
+```
+
+## Example: attach to a root view
+
+```swift
+extension View {
+  func withLinkRouter(_ router: RouterPath) -> some View {
+    self
+      .environment(
+        \.openURL,
+        OpenURLAction { url in
+          router.handle(url: url)
+        }
+      )
+      .onOpenURL { url in
+        router.handleDeepLink(url: url)
+      }
+  }
+}
+```
+
+## Design choices to keep
+
+- Keep URL parsing and decision logic inside the router.
+- Avoid handling deep links in multiple places; one entry point is enough.
+- Always provide a fallback to `OpenURLAction` or `UIApplication.shared.open`.
+
+## Pitfalls
+
+- Don't assume the URL is internal; validate first.
+- Avoid blocking UI while resolving remote links; use `Task`.