@mmerterden/multi-agent-pipeline 20.17.1 → 20.17.2

package/pipeline/skills/shared/external/ios-haptics/references/core-haptics.md

@@ -0,0 +1,215 @@
+# Core Haptics
+
+For patterns the feedback generators cannot express: shaped intensity and
+sharpness, several events in sequence, haptics synchronised with audio, or a
+pattern that changes while it plays (a drag that strengthens with distance).
+
+## Contents
+
+1. Engine lifecycle
+2. Events and parameters
+3. Playing a pattern
+4. Parameter curves and dynamic parameters
+5. Advanced players
+6. AHAP files
+7. Pitfalls
+
+## 1. Engine lifecycle
+
+Check support, create the engine once for the screen or feature, set both
+handlers before starting, and stop it when it is no longer needed.
+
+```swift
+import CoreHaptics
+import OSLog
+
+@MainActor
+final class PatternPlayer {
+    private var engine: CHHapticEngine?
+    private let logger = Logger(subsystem: "app.haptics", category: "engine")
+
+    var supportsHaptics: Bool {
+        CHHapticEngine.capabilitiesForHardware().supportsHaptics
+    }
+
+    func start() throws {
+        guard supportsHaptics, engine == nil else { return }
+        let engine = try CHHapticEngine()
+        engine.stoppedHandler = { @Sendable [logger] reason in
+            logger.info("Haptic engine stopped: \(reason.rawValue)")
+        }
+        engine.resetHandler = { @Sendable [weak self] in
+            Task { @MainActor in
+                try? self?.engine?.start()
+            }
+        }
+        try engine.start()
+        self.engine = engine
+    }
+
+    func stop() {
+        engine?.stop()
+        engine = nil
+    }
+}
+```
+
+- **Stopped handler**: runs when something outside the app stops the engine
+  (an audio interruption such as a call, or the app moving to the
+  background). It is not called for your own `stop`. Restart before the next
+  pattern.
+- **Reset handler**: runs after the haptic server recovers from a failure.
+  Restart the engine, re-register custom audio resources, and recreate any
+  players you held; old players are invalid.
+- Do not assume the handlers run on the main thread; hop to the main actor
+  before touching main-actor state.
+- **Power**: stop the engine when the screen stops playing patterns, or set
+  `isAutoShutdownEnabled = true` to let the engine stop itself after about two
+  minutes idle and start on demand.
+- `playsHapticsOnly` makes the engine ignore audio events; `isMutedForHaptics`
+  and `isMutedForAudio` mute one channel.
+- The engine is not a singleton. Several can exist; each behaves independently.
+
+## 2. Events and parameters
+
+| Event type | Feels like |
+|---|---|
+| `.hapticTransient` | A short tap or impulse |
+| `.hapticContinuous` | A sustained vibration for a `duration` |
+| `.audioContinuous` | A sustained generated tone |
+| `.audioCustom` | An audio file registered with `registerAudioResource(_:options:)` |
+
+Event parameters (`CHHapticEvent.ParameterID`), normalised 0 to 1, where 0
+and 1 map to the minimum and maximum the hardware supports:
+
+- `.hapticIntensity`: strength.
+- `.hapticSharpness`: soft and round (low) to crisp and mechanical (high).
+- `.attackTime`, `.decayTime`, `.releaseTime`, `.sustained`: envelope of a
+  continuous event.
+- Audio: `.audioVolume`, `.audioPitch`, `.audioPan`, `.audioBrightness`.
+
+Match intensity and sharpness to the visual: a crisp snap is short and sharp,
+a soft landing is lower in both.
+
+## 3. Playing a pattern
+
+```swift
+func playTap(on engine: CHHapticEngine) throws {
+    let tap = CHHapticEvent(
+        eventType: .hapticTransient,
+        parameters: [
+            CHHapticEventParameter(parameterID: .hapticIntensity, value: 0.9),
+            CHHapticEventParameter(parameterID: .hapticSharpness, value: 0.7)
+        ],
+        relativeTime: 0
+    )
+    let pattern = try CHHapticPattern(events: [tap], parameters: [])
+    let player = try engine.makePlayer(with: pattern)
+    try player.start(atTime: CHHapticTimeImmediate)
+}
+```
+
+A player (`CHHapticPatternPlayer`) can `start(atTime:)`, `stop(atTime:)`,
+`cancel()`, `sendParameters(_:atTime:)` and `scheduleParameterCurve(_:atTime:)`.
+
+## 4. Parameter curves and dynamic parameters
+
+**Curves** schedule a change over time inside the pattern; values move
+linearly between control points.
+
+```swift
+let rumble = CHHapticEvent(
+    eventType: .hapticContinuous,
+    parameters: [
+        CHHapticEventParameter(parameterID: .hapticIntensity, value: 0.3),
+        CHHapticEventParameter(parameterID: .hapticSharpness, value: 0.2)
+    ],
+    relativeTime: 0,
+    duration: 1.0
+)
+let swell = CHHapticParameterCurve(
+    parameterID: .hapticIntensityControl,
+    controlPoints: [
+        .init(relativeTime: 0, value: 0.3),
+        .init(relativeTime: 0.5, value: 0.7),
+        .init(relativeTime: 1.0, value: 1.0)
+    ],
+    relativeTime: 0
+)
+let pattern = try CHHapticPattern(events: [rumble], parameterCurves: [swell])
+```
+
+**Dynamic parameters** (`CHHapticDynamicParameter`) change the whole pattern
+right now, from live input: send them with `sendParameters(_:atTime:)` as a
+drag moves. They use the `...Control` IDs (`.hapticIntensityControl`,
+`.hapticSharpnessControl`, envelope and audio controls), which scale the
+event values rather than replace them.
+
+## 5. Advanced players
+
+`makeAdvancedPlayer(with:)` returns a `CHHapticAdvancedPatternPlayer`, which
+adds `loopEnabled` and `loopEnd`, `pause(atTime:)`, `resume(atTime:)`,
+`seek(toOffset:)`, `playbackRate` and a `completionHandler`. Use it for looping
+or scrubbing; a plain player is enough for one-shot patterns.
+
+## 6. AHAP files
+
+AHAP (Apple Haptic and Audio Pattern) is a JSON file holding one pattern.
+Ship it as a bundle resource and load it at run time, so designers can tune
+the feel without a rebuild.
+
+```json
+{
+  "Version": 1.0,
+  "Pattern": [
+    {
+      "Event": {
+        "Time": 0.0,
+        "EventType": "HapticTransient",
+        "EventParameters": [
+          { "ParameterID": "HapticIntensity", "ParameterValue": 0.9 },
+          { "ParameterID": "HapticSharpness", "ParameterValue": 0.6 }
+        ]
+      }
+    },
+    {
+      "Event": {
+        "Time": 0.12,
+        "EventType": "HapticContinuous",
+        "EventDuration": 0.3,
+        "EventParameters": [
+          { "ParameterID": "HapticIntensity", "ParameterValue": 0.5 }
+        ]
+      }
+    }
+  ]
+}
+```
+
+- Top-level keys are only `Version` and `Pattern`; `Pattern` is an array of
+  entries, each an `Event`, a `Parameter` (dynamic parameter) or a
+  `ParameterCurve`.
+- Missing keys take defaults, out-of-range values are clamped, unknown keys
+  are ignored.
+- Play directly with `engine.playPattern(from: url)`, or build a pattern with
+  `CHHapticPattern(contentsOf:)` (iOS 16) to make a player you can control.
+
+```swift
+func playCheckout(on engine: CHHapticEngine) throws {
+    guard let url = Bundle.main.url(forResource: "checkout", withExtension: "ahap") else { return }
+    try engine.playPattern(from: url)
+}
+```
+
+## 7. Pitfalls
+
+- Starting an engine on a device without haptics: check capabilities first and
+  fall back to visual or audio feedback.
+- Playing after an interruption without restarting: handle the stopped
+  handler, restart lazily before the next pattern.
+- Keeping players across a reset: recreate them in the reset handler.
+- Leaving the engine running on a screen that no longer plays haptics: it
+  costs power.
+- Long continuous patterns in an app: they dilute meaning and tire the hand.
+- Haptics during camera, microphone or motion capture: they can disturb the
+  capture.

package/pipeline/skills/shared/external/ios-iphone-duo/NOTICE.md

@@ -0,0 +1,53 @@
+# Notice: ideas from iphone-duo-skills
+
+The `ios-iphone-duo` skill is original writing for this repository. Its
+structure and several ideas were informed by a third-party skill set; no text
+was copied from it. Technical facts are taken from Apple's developer
+documentation and Human Interface Guidelines, which the skill links.
+
+## Upstream
+
+- Repository: https://github.com/mirzaaghazadeh/iphone-duo-skills
+- License: MIT (text below)
+
+## Ideas used
+
+- Organising readiness work as a hunt for fixed assumptions (orientation,
+  screen, cached sizes, idiom, device sizes, symmetric insets, hand-built
+  bars), each paired with its replacement.
+- A pose-to-pattern view of layout and a design review checklist for
+  foldable layouts.
+- Treating hinge data as input for effects and reserved regions or
+  arrangements as the tools for layout.
+
+## Trademarks
+
+Apple, iPhone, iPhone Duo, iOS, Xcode, SwiftUI and UIKit are trademarks of
+Apple Inc. This skill is not affiliated with, endorsed by or sponsored by
+Apple Inc.
+
+## License (MIT)
+
+```
+MIT License
+
+Copyright (c) 2026 Navid Mirzaaghazadeh
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```

package/pipeline/skills/shared/external/ios-iphone-duo/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: ios-iphone-duo
+description: "Readiness for iPhone Duo, the foldable two-display iPhone on iOS 27.1: fixed-assumption hunting, asymmetric safe areas, reserved regions, ArrangementView, hinge changes, vertical bars and dual-pane patterns. Use when preparing, auditing or designing an app for iPhone Duo, the fold or vertical toolbars."
+metadata:
+  source: multi-agent-pipeline
+  date_added: "2026-10-08"
+---
+
+# iPhone Duo readiness
+
+iPhone Duo has a compact outer display and a large inner display, each with a
+front camera, joined by a hinge that can rest at any angle. Apple's framing is
+the one to keep: it is still an iPhone, and an app that already resizes well
+(iPad, Split View, iPhone Mirroring) is most of the way there. The work is
+removing every place the app assumes a fixed shape, then adopting a few new
+APIs where the fold or the vertical bars need them.
+
+**Beta status.** Everything marked *(27.1 beta)* below is documented as beta
+in the iOS 27.1 SDK and may change before release. Check availability before
+shipping code that depends on it, and gate it with `if #available`.
+
+## One rule behind every fix
+
+Do not ask "is this iPhone Duo?". Ask "how much space do I have, and what is
+reserved in it?". Branches on size class and available space are right on
+iPad, in Split View and on the next device too; a device check is right on one
+device and wrong everywhere else.
+
+## Step 1: build and run
+
+- Build with the latest Xcode. Apps built with Xcode 26 or earlier do not
+  extend under the status bar and camera on iPhone Duo.
+- Test in the iPhone Duo simulator from Device Hub: closed, open, partially
+  folded, rotated in each pose, and in Split View on both sides.
+- Walk every screen, sheet and popover. Note views that resize badly,
+  controls that land in the fold, sheets that sit awkwardly when folding, and
+  how bars move to the side.
+
+Layout bugs here depend on the pose. Reading code finds candidates; only
+running finds the bugs.
+
+## Step 2: hunt fixed assumptions
+
+Search the codebase with the patterns in `references/fixed-assumptions.md`.
+Each hit is a candidate defect with a known replacement:
+
+| Assumption | Why it breaks | Replace with |
+|---|---|---|
+| Orientation decides layout (`UIDevice.current.orientation`, `interfaceOrientation`) | Orientation no longer tells you the shape of your space | Compare the width and height you actually have |
+| `UIScreen.main` (deprecated in iOS 26) | Two displays make "the screen" ambiguous | View, window or scene bounds; `displayScale` from traits or environment |
+| Size read once and cached | Folding resizes the app mid-session | Lay out in `layoutSubviews` / `viewDidLayoutSubviews`, `GeometryReader`, `onGeometryChange` |
+| Regular width means iPad (`userInterfaceIdiom`, `horizontalSizeClass == .regular`) | The inner display is regular width on a phone | Size class and available space, never idiom |
+| Device size tables, width thresholds | No table contains this device | Size classes, container-relative sizing |
+| Symmetric insets (`insets.left * 2`) | Side-mounted bars make insets asymmetric | Each edge's inset on its own |
+| Hand-built `UIToolbar`, `UINavigationBar`, `UITabBar` | Only container-provided bars move to the side | Toolbar items on navigation containers |
+| Full-bleed fill media | Wider displays crop the subject | Choose fill or fit from size, set a focal point |
+
+## Step 3: let containers adapt
+
+Standard containers already handle sizes, the fold and the cameras:
+`NavigationSplitView` / `UISplitViewController` (collapses on the outer
+display, adapts column widths and margins to the fold), `TabView`,
+`NavigationStack`, `List`, `ScrollView`. Alerts, context menus and sheets move
+away from the fold by themselves. The more of the app sits in these, the less
+custom fold handling it needs.
+
+## Step 4: safe areas and reserved regions
+
+- Keep interactive and legible content inside the safe area; let backgrounds
+  run past it.
+- Treat every edge separately and test Split View on both sides, where bars
+  sit on the outer edge of each app.
+- Reserved regions describe space the hardware takes:
+  - **division**: the fold, active only while partially folded;
+  - **occlusion**: the outer camera (always) and the inner camera (only
+    while active).
+- Custom views read them with `GeometryProxy.reservedRegions(kind:options:layoutDirectionBehavior:)`
+  *(27.1 beta)* or `UIView.reservedRegions(kind:options:)` *(27.1 beta)*. The
+  query returns regions intersecting the view whether or not they are active,
+  so filter on `isActive` for current layout and use `.includeInactive` only
+  for stable decisions (for example an even column count on hardware that has
+  a fold). A region's `frame` already includes its `margins`.
+- Reserved region frames are physical; SwiftUI mirrors them for right-to-left
+  by default (`.mirrors`), which suits a custom `Layout`. Pass `.fixed` for
+  raw frames.
+
+Use the hinge for effects, and reserved regions or arrangements for layout.
+
+## Step 5: arrangements for two-view layouts
+
+`ArrangementView(primary:secondary:)` *(27.1 beta)*, and
+`UIArrangementViewController` in UIKit, lay out exactly two views and adapt
+to size, size class and the fold:
+
+- `.arrangementViewStyle(.split)` (the automatic default): side by side when
+  wider than tall, stacked when taller than wide, adjusted around the fold.
+  Natural replacement for an `HStack` or `VStack` of two panes.
+- `.arrangementViewStyle(.overlay)`: primary over secondary when flat or
+  closed, one on each side of the fold when partially open. Natural
+  replacement for a `ZStack` such as controls over video.
+- Constrain axes with `.split.axes(...)` or `.overlay.axes(...)`.
+
+Keep navigation containers outside an arrangement, and do not put an
+arrangement inside `NavigationSplitView`, `List` or `ScrollView`, where part
+of it can become unreachable.
+
+## Step 6: vertical bars
+
+On the outer display, and on the inner display in landscape, toolbars, tab
+bars and navigation controls move to the side. The inner display in portrait
+keeps horizontal bars.
+
+- Only container-provided bars participate: `.toolbar` on `NavigationStack` or
+  `NavigationSplitView`, items on a view controller in a navigation
+  controller.
+- Order: Back or Close at the top (`cancellationAction`, or `leadingItemGroups`
+  in UIKit), then prominent actions (`topBarPinnedTrailing`, iOS 27, or
+  `pinnedTrailingGroup`), then the rest in their groups (`ToolbarItemGroup`).
+- Give items both a title and a symbol (`Label`). Vertical placement uses the
+  icon; items with only a title or a custom view stay horizontal.
+- Overflow fills bottom to top; reorder with `visibilityPriority(_:)` (iOS 27),
+  add items straight to the menu with `ToolbarOverflowMenu` (iOS 27) or
+  `additionalOverflowItems`.
+- `axisBehavior(_:)` *(27.1 beta)* keeps an item horizontal-only.
+- `toolbarVerticalCompressionBehavior(_:)` *(27.1 beta)*: keep the tab bar
+  for navigation-heavy screens, prefer toolbar items for task screens.
+- `toolbarVerticalBehavior(.disabled)` *(27.1 beta)* or
+  `preferredVerticalBarBehavior` opts a screen out, for example a full-screen
+  player or a non-scrolling calculator. Make it a stable per-screen choice.
+- `toolbarVerticalEdge` *(27.1 beta)* environment value, `verticalBarEdge`
+  trait in UIKit: the edge the system prefers for a vertical bar, or nil
+  (`.unspecified` in UIKit) where none is used. Align custom floating controls with it.
+- Extend hero images under a vertical bar with `backgroundExtensionEffect()`
+  or `UIBackgroundExtensionView`.
+
+## Step 7: the hinge
+
+`onHingeChange(isEnabled:_:)` *(27.1 beta)* passes the old and new
+`DeviceHingeContext`; its `hinge` is nil on hardware without one.
+`DeviceHinge.status` is `.closed`, `.partiallyOpen` or `.fullyOpen` (a struct,
+so a `switch` needs `default`). UIKit's `UIHingeInteraction` reports a
+`UIHinge` whose `angle` is in radians and whose status adds `.unknown`. Prefer
+the status over angle thresholds; update rate and precision are system policy.
+
+API details, code and the UIKit side are in `references/api-map.md`.
+
+## Design: poses and panes
+
+Design to two size classes, compact (outer) and regular (inner), not to poses.
+Keep the same functions and state on both displays; the inner display may show
+one more level of the same hierarchy (list and detail side by side), not a
+different app. `references/poses-and-panes.md` has the pose-to-pattern table,
+dual-pane rules and the review checklist; `ios-design-review` runs the
+general visual review.
+
+## Reporting
+
+Report the Xcode and SDK the app builds with, each defect with `file:line`
+and the replacement, which screens were run in which poses, and what is still
+unverified (pose behaviour seen only in code, beta APIs not yet run).
+
+## References
+
+- `references/fixed-assumptions.md`: grep patterns and replacements.
+- `references/api-map.md`: every API by job, availability, beta marks, code.
+- `references/poses-and-panes.md`: poses, dual-pane rules, review checklist.
+- Preparing your app for iPhone Duo: https://developer.apple.com/documentation/technologyoverviews/preparing-your-app-for-iphone-duo
+- Designing for iPhone Duo (HIG): https://developer.apple.com/design/human-interface-guidelines/designing-for-iphone-duo
+- Get ready for iPhone Duo: https://developer.apple.com/iphone-duo/
+- `NOTICE.md`: attribution for ideas drawn from a third-party skill set.

package/pipeline/skills/shared/external/ios-iphone-duo/evals/evals.json

@@ -0,0 +1,50 @@
+{
+  "skill_name": "ios-iphone-duo",
+  "evals": [
+    {
+      "id": 0,
+      "name": "readiness-audit-plan",
+      "prompt": "We have a UIKit and SwiftUI mixed iPhone app. Leadership wants it ready for iPhone Duo. Give me an audit plan: what to search for in the code, what to replace it with, and how to verify. We currently use UIScreen.main.bounds in a dozen places, show our iPad layout when horizontalSizeClass is regular, and have a custom UIToolbar at the bottom of the editor.",
+      "expected_output": "Starts with building on the latest Xcode and running in the iPhone Duo simulator from Device Hub across closed, open, folded, rotated and Split View. Provides a grep list (UIScreen.main, orientation, userInterfaceIdiom, regular size class, device widths, symmetric insets, hand-built bars, fill media) with replacements: view or scene bounds and displayScale instead of UIScreen.main (deprecated in iOS 26), size class and available space instead of treating regular as iPad, container-provided toolbar items instead of the custom UIToolbar so bars can move vertical. Covers asymmetric safe areas and reserved regions, marks 27.1 APIs as beta, and reports file:line findings separating simulator-confirmed from code-only.",
+      "files": [],
+      "expectations": [
+        "Gives grep patterns including UIScreen.main and userInterfaceIdiom or orientation",
+        "Replaces UIScreen.main with view, window or scene bounds and notes its iOS 26 deprecation",
+        "Explains that regular width no longer means iPad because the inner display is regular",
+        "Replaces the custom UIToolbar with container-provided toolbar items for vertical bars",
+        "Mentions asymmetric safe area insets handled per edge",
+        "Requires verification in the iPhone Duo simulator across poses and Split View",
+        "Marks iOS 27.1 APIs such as ReservedRegion or ArrangementView as beta"
+      ]
+    },
+    {
+      "id": 1,
+      "name": "fold-aware-media-layout",
+      "prompt": "Our video app shows playback controls over the video in a ZStack. On the foldable iPhone, when it is half folded, we want video on top half and controls on the bottom half, and the controls must never sit in the fold. Which APIs should we use and how?",
+      "expected_output": "Recommends ArrangementView with the overlay style (iOS 27.1 beta), controls as primary and video as secondary, which layers them when flat or closed and splits them around the fold when partially open; optionally constrains axes. Keeps navigation containers outside and does not place the arrangement in a List or ScrollView. For any custom positioning, reads reserved regions of kind division from GeometryProxy, filters isActive, notes frame includes margins and SwiftUI mirrors frames for RTL by default. Uses onHingeChange only for effects, not layout.",
+      "files": [],
+      "expectations": [
+        "Uses ArrangementView with the overlay style",
+        "Explains overlay behaviour: layered when flat, split around the fold when partially open",
+        "Marks ArrangementView or reserved regions as iOS 27.1 beta",
+        "Mentions reserved regions of kind division with an isActive check for custom layout",
+        "Keeps navigation containers outside the arrangement or avoids List and ScrollView",
+        "Says the hinge API is for effects, not layout"
+      ]
+    },
+    {
+      "id": 2,
+      "name": "vertical-toolbar-design",
+      "prompt": "On the outer display our editor's toolbar moved to the side and half the buttons vanished, and our 'Save changes' text button stays at the top. How should we organise the toolbar for iPhone Duo?",
+      "expected_output": "Explains vertical bars on the outer display and inner landscape, with items needing a symbol and title (text-only items stay horizontal). Orders Back or Close at top via cancellationAction, prominent Done via topBarPinnedTrailing, then grouped items with ToolbarItemGroup; sets visibilityPriority so frequent and badged items stay visible; uses ToolbarOverflowMenu for extra actions instead of a custom menu; mentions axisBehavior and toolbarVerticalCompressionBehavior as 27.1 beta, and toolbarVerticalBehavior(.disabled) only for screens better served by horizontal bars.",
+      "files": [],
+      "expectations": [
+        "Says items need both a symbol and a title and that text-only items stay horizontal",
+        "Places Back or Close first with cancellationAction and a prominent action with topBarPinnedTrailing",
+        "Uses visibilityPriority to control what overflows",
+        "Uses ToolbarOverflowMenu or the system overflow instead of a custom menu",
+        "Treats disabling vertical bars as a rare, stable per-screen choice"
+      ]
+    }
+  ]
+}

package/pipeline/skills/shared/external/ios-iphone-duo/evals/trigger-eval.json

@@ -0,0 +1,22 @@
+[
+  { "query": "Get our app ready for iPhone Duo", "should_trigger": true },
+  { "query": "How do we avoid putting buttons in the fold on the foldable iPhone?", "should_trigger": true },
+  { "query": "Our toolbar moves to the side on the outer display, how do we organise items?", "should_trigger": true },
+  { "query": "Replace UIScreen.main across the codebase for the two-display iPhone", "should_trigger": true },
+  { "query": "Use ArrangementView for a split between player and lyrics", "should_trigger": true },
+  { "query": "Read the hinge angle with onHingeChange", "should_trigger": true },
+  { "query": "Reserved regions for the inner front camera occlusion", "should_trigger": true },
+  { "query": "Design review of our app on the inner display of iPhone Duo in book pose", "should_trigger": true },
+  { "query": "We show the iPad layout when size class is regular, is that a problem on the foldable?", "should_trigger": true },
+  { "query": "What does toolbarVerticalEdge return and when should I use it?", "should_trigger": true },
+  { "query": "Make our iPad app support Stage Manager window resizing", "should_trigger": false },
+  { "query": "Build a NavigationSplitView for iPad with a sidebar", "should_trigger": false },
+  { "query": "Adapt our Android app to foldables with Jetpack WindowManager", "should_trigger": false },
+  { "query": "Support landscape orientation on iPhone 17", "should_trigger": false },
+  { "query": "Add Liquid Glass to the tab bar", "should_trigger": false },
+  { "query": "Design review of the checkout screen in dark mode", "should_trigger": false },
+  { "query": "Use the camera to capture photos with AVFoundation", "should_trigger": false },
+  { "query": "Show content on an external display with AirPlay", "should_trigger": false },
+  { "query": "Fix Auto Layout constraint warnings on rotation", "should_trigger": false },
+  { "query": "Make our tab bar minimize on scroll", "should_trigger": false }
+]