@mmerterden/multi-agent-pipeline 20.17.1 → 20.18.0

package/pipeline/skills/shared/external/ios-iphone-duo/references/api-map.md

@@ -0,0 +1,212 @@
+# iPhone Duo API map
+
+Every API this skill relies on, grouped by job, with the iOS version that
+introduced it. *(27.1 beta)* marks symbols documented as beta in the iOS 27.1
+SDK; their names and behaviour may change before release.
+
+## Contents
+
+1. Size, screen and shape
+2. Reserved regions
+3. Arrangements
+4. Vertical bars
+5. Sheets
+6. Hinge
+7. Scenes and accessories
+
+## 1. Size, screen and shape
+
+| Job | SwiftUI | UIKit | iOS |
+|---|---|---|---|
+| Size class | `horizontalSizeClass`, `verticalSizeClass` environment | trait collection size classes | 13 |
+| Space actually available | `GeometryReader`, `onGeometryChange(for:of:action:)` | `view.bounds`, `viewDidLayoutSubviews`, `layoutSubviews` | 13 / 16 |
+| Display scale | `displayScale` environment | `traitCollection.displayScale` | 13 / 8 |
+| A window for a scene | | `UIWindow(windowScene:)` | 13 |
+| The scene's screen, if truly needed | | `view.window?.windowScene?.screen` | 13 |
+| Choose among layouts | `ViewThatFits`, `AnyLayout` | | 16 |
+| Size relative to container | `containerRelativeFrame(_:alignment:)` | Auto Layout | 17 |
+| Corners concentric with the device | `ConcentricRectangle` | `UICornerConfiguration`, `UIView.cornerConfiguration` | 26 |
+
+`UIScreen.main` is deprecated as of iOS 26. Apple's guidance is to base layout
+on the scene or containing view's bounds and on size classes, and not to use
+`userInterfaceIdiom` or `UIInterfaceOrientation` for layout decisions.
+
+## 2. Reserved regions
+
+| Job | SwiftUI | UIKit |
+|---|---|---|
+| Region type | `ReservedRegion` *(27.1 beta)* | `UIView.ReservedRegion` *(27.1 beta)* |
+| Query | `GeometryProxy.reservedRegions(kind:options:layoutDirectionBehavior:)` *(27.1 beta)* | `UIView.reservedRegions(kind:options:)` *(27.1 beta)* |
+| Kinds | `.division` (fold), `.occlusion` (cameras) | same |
+| Options | `.includeInactive` | same |
+| Properties | `frame` (includes margins), `margins`, `isActive`, `kind`, `id` | `frame`, `margins`, `isActive`, `kind` (no `id`) |
+
+```swift
+struct FoldAwareGrid<Content: View>: View {
+    @ViewBuilder var content: (_ columns: Int) -> Content
+
+    var body: some View {
+        GeometryReader { proxy in
+            let hasFold = !proxy.reservedRegions(kind: .division, options: .includeInactive).isEmpty
+            let base = proxy.size.width > proxy.size.height ? 3 : 2
+            content(hasFold && base.isMultiple(of: 2) == false ? base + 1 : base)
+        }
+    }
+}
+```
+
+Notes:
+
+- The query returns regions that intersect the view whether active or not.
+  Filter `isActive` when positioning for the current pose.
+- `frame` already contains `margins`, the clearance kept for interactive
+  content. Avoiding `frame` is enough for controls; inset `frame` by
+  `margins` when full-bleed media may run up to the bare hardware area.
+- SwiftUI mirrors region frames for right-to-left by default
+  (`layoutDirectionBehavior: .mirrors`), so a custom `Layout` can compare them
+  with subview frames directly. Pass `.fixed` for the physical frames.
+- System containers (split views, lists, scroll views, sheets, alerts, menus)
+  already avoid reserved regions; custom views and custom layouts are the
+  ones that need this API.
+
+## 3. Arrangements
+
+| Job | SwiftUI | UIKit |
+|---|---|---|
+| Container | `ArrangementView(primary:secondary:)` *(27.1 beta)* | `UIArrangementViewController` *(27.1 beta)* |
+| Choose style | `.arrangementViewStyle(.split)` / `.overlay` / `.automatic` | `updateArrangement(_:animated:)` with `UISplitArrangement` / `UIOverlayArrangement` |
+| Limit axes | `.split.axes(.vertical)`, `.overlay.axes(...)` | `axes(_:)` on the arrangement |
+| Assign content | the two view builders | `setViewController(_:for:animated:)` with `.primary` / `.secondary` |
+| Split sizing | `splitArrangementLayoutRatio(_:)`, `splitArrangementLayoutSize(...)`, `splitArrangementFixedLayoutSize(...)` | `UISplitArrangement.Dimension` |
+| Overlay details | `overlayArrangementEdge(_:)`, `overlayArrangementZIndex` environment | `state(for:)` |
+
+```swift
+ArrangementView {
+    NowPlayingView()
+} secondary: {
+    LyricsView()
+}
+.arrangementViewStyle(.split)
+
+ArrangementView {
+    PlayerControls()
+} secondary: {
+    VideoSurface()
+}
+.arrangementViewStyle(.overlay)
+```
+
+The automatic style resolves to split. Split goes side by side when wider than
+tall and stacks when taller than wide; overlay layers primary over secondary
+when closed or fully open and places them on either side of the fold when
+partially open (primary trailing or bottom, secondary leading or top).
+
+Placement rules: navigation containers go around an arrangement, never inside
+it; an arrangement does not go inside `NavigationSplitView`, `List`,
+`ScrollView` or another container that could make part of it unreachable.
+
+## 4. Vertical bars
+
+| Job | SwiftUI | UIKit | iOS |
+|---|---|---|---|
+| Bars that can go vertical | `.toolbar` on `NavigationStack` / `NavigationSplitView` | items on a view controller in a navigation controller | |
+| Custom Back or Close | `ToolbarItem(placement: .cancellationAction)` | `leadingItemGroups` | 14 / 16 |
+| Prominent action | `topBarPinnedTrailing` | `pinnedTrailingGroup` | 27 / 16 |
+| Group items | `ToolbarItemGroup` | `UIBarButtonItemGroup` | 14 |
+| Title plus symbol | `Label` | `UIBarButtonItem` title and image | |
+| Overflow order | `visibilityPriority(_:)`, `ToolbarItemVisibilityPriority` (`.automatic`, `.low`, `.high`, `init(higherThan:)`, `init(lowerThan:)`) | `visibilityPriority`, `UIBarButtonItemVisibilityPriority` | 27 |
+| Put items in overflow | `ToolbarOverflowMenu` | `additionalOverflowItems` | 27 / 16 |
+| Keep an item horizontal | `axisBehavior(_:)` with `ToolbarItemAxisBehavior` (`.automatic`, `.horizontalOnly`, `.verticalPreferred`) | `axisBehavior`, `UIBarButtonItem.AxisBehavior` | *(27.1 beta)* |
+| Tab bar versus toolbar when tight | `toolbarVerticalCompressionBehavior(_:)` (`.automatic`, `.prefersTabBar`, `.prefersToolbarItems`) | `UIVerticalBarCompressionBehavior` | *(27.1 beta)* |
+| Opt a screen out | `toolbarVerticalBehavior(.disabled)` | `preferredVerticalBarBehavior`, `setNeedsUpdateOfVerticalBarConfiguration()` | *(27.1 beta)* |
+| Which edge the bar prefers | `toolbarVerticalEdge` environment (`HorizontalEdge?`) | `verticalBarEdge` trait (`UIVerticalBarEdge`) | *(27.1 beta)* |
+| Image under the bar | `backgroundExtensionEffect()` | `UIBackgroundExtensionView` | 26 |
+
+```swift
+NavigationStack {
+    EditorView()
+        .toolbar {
+            ToolbarItem(placement: .cancellationAction) {
+                Button("Close", systemImage: "xmark") { dismiss() }
+            }
+            ToolbarItem(placement: .topBarPinnedTrailing) {
+                Button("Done", systemImage: "checkmark") { save() }
+            }
+            ToolbarItemGroup {
+                Button("Bold", systemImage: "bold") { toggleBold() }
+                Button("Italic", systemImage: "italic") { toggleItalic() }
+            }
+            .visibilityPriority(.low)
+        }
+}
+```
+
+How items are shown: vertically with their icon; horizontally with icon or
+title (icon preferred); in overflow with both. An item with only a title or a
+custom view is never placed vertically.
+
+Contexts that choose differently: inspectors keep horizontal bars; a split
+view uses horizontal bars for sidebar and content columns and vertical bars
+for the detail column; sheets on the outer display go vertical by default.
+
+`toolbarVerticalBehavior` is resolved per container: the top view of a
+`NavigationStack`, the selected tab of a `TabView`, the trailing column of a
+`NavigationSplitView`. To hide bars rather than change their axis, use
+`toolbarVisibility(_:for:)`.
+
+`toolbarVerticalEdge` reports the preferred edge even when no vertical bar is
+currently visible, and nil where the system never uses one:
+
+```swift
+@Environment(\.toolbarVerticalEdge) private var barEdge
+
+FloatingPalette()
+    .frame(maxWidth: .infinity, alignment: barEdge == .leading ? .leading : .trailing)
+```
+
+## 5. Sheets
+
+On the inner display, sheets use horizontal toolbars when centred or leading
+and vertical ones when trailing. Choose placement with
+`presentationPlacement(_:)` (iOS 27) or `UISheetPresentationController.preferredPlacement`
+(iOS 27). On the outer display, a sheet with a single action can opt out of the
+vertical bar with `toolbarVerticalBehavior(.disabled)`.
+
+## 6. Hinge
+
+| | SwiftUI *(27.1 beta)* | UIKit *(27.1 beta)* |
+|---|---|---|
+| Observe | `onHingeChange(isEnabled:_:)`, old and new `DeviceHingeContext` | `UIHingeInteraction(updateHandler:)`, `(interaction, update)` |
+| Hinge value | `DeviceHingeContext.hinge: DeviceHinge?` | `Update.hinge: UIHinge?` |
+| Angle | `angle: Angle` | `angle: CGFloat`, radians |
+| Status | `DeviceHinge.Status` struct: `.closed`, `.partiallyOpen`, `.fullyOpen` | `UIHinge.Status` enum: same plus `.unknown` |
+
+```swift
+@State private var hingeStatus: DeviceHinge.Status?
+
+var body: some View {
+    Canvas3DView(tilted: hingeStatus == .partiallyOpen)
+        .onHingeChange { _, new in
+            hingeStatus = new.hinge?.status
+        }
+}
+```
+
+- `hinge` is nil where there is no hinge; treat that as the normal phone case.
+- The UIKit handler runs with the initial state, on changes, and when the
+  interaction moves between hierarchies. It escapes, so capture weakly.
+- Status comes from angle and orientation together; do not rebuild it from
+  angle thresholds. Update rate and precision are system policy.
+- Use the hinge for interactions and effects. Layout belongs to reserved
+  regions, arrangements and size classes.
+
+## 7. Scenes and accessories
+
+- `sceneAccessory(content:)` (iOS 27) and UIKit's scene accessory
+  registration (`registerSceneAccessory(_:)`) attach content to another
+  display, for example a camera capture accessory on the outer display while
+  the app runs on the inner one. See Apple's article on registering a camera
+  capture accessory on iPhone Duo.
+- New windows depend on what the current display allows. Prefer
+  `UIWindowScene.ActivationAction` for "open in new window" menu items, and
+  handle a failed scene request instead of assuming success.

package/pipeline/skills/shared/external/ios-iphone-duo/references/fixed-assumptions.md

@@ -0,0 +1,202 @@
+# Fixed assumptions: grep list and replacements
+
+Run these from the repository root. Every hit is a candidate, not a verdict:
+read the surrounding code, decide whether it affects layout, and confirm on
+the iPhone Duo simulator. Exclude vendored and generated code from the count.
+
+## Contents
+
+1. The search
+2. Orientation
+3. The screen
+4. Cached sizes
+5. Idiom and size class
+6. Device sizes and thresholds
+7. Insets
+8. Bars
+9. Media
+10. Life cycle, legacy guides and the keyboard
+11. Recording the result
+
+## 1. The search
+
+```bash
+rg -n --type swift \
+  -e 'UIScreen\.main' \
+  -e 'UIScreen\.screens' \
+  -e 'UIDevice\.current\.orientation' \
+  -e 'interfaceOrientation' \
+  -e 'statusBarOrientation' \
+  -e 'userInterfaceIdiom' \
+  -e 'horizontalSizeClass\s*==\s*\.regular' \
+  -e 'UIWindow\(frame:' \
+  -e 'safeAreaInsets\.(left|right|top|bottom)\s*\*\s*2' \
+  -e '(width|height)\s*(==|>=|<=|>|<)\s*(320|375|390|393|402|414|428|430|440)\b' \
+  -e 'UIToolbar\(|UINavigationBar\(|UITabBar\(' \
+  -e 'scaleAspectFill|contentMode:\s*\.fill' \
+  -e 'topLayoutGuide|bottomLayoutGuide' \
+  -e 'keyboardWillShowNotification|keyboardFrameEndUserInfoKey' \
+  -e 'applicationDidBecomeActive|applicationWillResignActive|applicationDidEnterBackground|applicationWillEnterForeground' \
+  .
+```
+
+The scene manifest lives in Info.plist, which the Swift search does not read:
+
+```bash
+rg -l 'UIApplicationSceneManifest' -g '*.plist' . || echo "no scene manifest"
+```
+
+Add Objective-C (`--type objc`) and storyboards (`-g '*.storyboard'` for
+fixed-size constraints) when the project has them.
+
+## 2. Orientation
+
+Hits: `UIDevice.current.orientation`, `interfaceOrientation` (including
+`windowScene.effectiveGeometry.interfaceOrientation`), `statusBarOrientation`.
+
+Why: on a foldable device orientation no longer says whether the app is wide
+or tall, and Apple's guidance is not to use `UIInterfaceOrientation` for
+layout decisions.
+
+Replace: compare the width and height of the space you have, `view.bounds` in
+a view controller, `bounds` of the superview in a view, the size from
+`GeometryReader` or `onGeometryChange` in SwiftUI. Keep orientation only for
+things that are about the device's physical attitude (camera capture
+rotation), not about layout.
+
+## 3. The screen
+
+Hits: `UIScreen.main` (deprecated in iOS 26), `UIScreen.screens`,
+`UIWindow(frame: UIScreen.main.bounds)`.
+
+| Instead of | Use |
+|---|---|
+| `UIScreen.main.bounds` | `view.bounds`, `window.bounds`, `GeometryReader`, `onGeometryChange` |
+| `UIScreen.main.scale` | `traitCollection.displayScale`, `@Environment(\.displayScale)` |
+| `UIWindow(frame: UIScreen.main.bounds)` | `UIWindow(windowScene:)` |
+| A stored `UIScreen` | `view.window?.windowScene?.screen`, read when needed |
+
+## 4. Cached sizes
+
+Hard to grep; look for sizes stored in properties at `viewDidLoad`,
+`viewIsAppearing`, `init`, `onAppear`, or a `GeometryReader` value copied into
+`@State` once.
+
+Why: folding and unfolding resizes the app during a session. A size read at
+launch is wrong after the first fold.
+
+Replace: do size-dependent layout in `viewDidLayoutSubviews` or
+`layoutSubviews`; use `viewWillTransition(to:with:)` for work tied to the
+change itself; in SwiftUI derive layout from the current geometry every time,
+or keep it current with `onGeometryChange`.
+
+## 5. Idiom and size class
+
+Hits: `userInterfaceIdiom == .pad`, `horizontalSizeClass == .regular` used to
+mean "iPad", and code that assumes iPhone is always compact.
+
+Why: the inner display is regular width on an iPhone. An iPad-only layout
+branch now runs on a phone, and a "phone means compact" branch never expects
+regular.
+
+Replace: branch on size class and available space only. Check both
+directions: code that fires on regular, and code that assumes compact.
+
+## 6. Device sizes and thresholds
+
+Hits: comparisons with known iPhone widths or heights, device lookup tables,
+"if width > 390" breakpoints.
+
+Why: no table contains this device, and Split View produces sizes no device
+has.
+
+Replace: size classes (compact for the outer display, regular for the inner),
+`ViewThatFits`, `containerRelativeFrame`, proportional and intrinsic sizing.
+
+## 7. Insets
+
+Hits: `safeAreaInsets.left * 2`, `width - 2 * inset`, `insets.left` used for
+both sides, padding that mirrors one edge onto the other.
+
+Why: side-mounted bars make safe areas and layout margins asymmetric, and the
+heavy side depends on pose and Split View position.
+
+Replace: inset each edge by its own value, or constrain to the safe area
+layout guide and layout margins and let the system resolve each edge.
+
+## 8. Bars
+
+Hits: `UIToolbar(`, `UINavigationBar(`, `UITabBar(` created by hand, or a
+SwiftUI `HStack` styled as a bar pinned to the top or bottom.
+
+Why: only bars provided by navigation containers take part in vertical
+placement. A custom bar stays where it is and collides with the system's
+vertical controls.
+
+Replace: toolbar items on `NavigationStack` / `NavigationSplitView` with
+`.toolbar`, or on a view controller inside a navigation controller; `TabView`
+or `UITabBarController` for tabs.
+
+## 9. Media
+
+Hits: `scaleAspectFill`, `.aspectRatio(contentMode: .fill)` on hero images
+and video.
+
+Why: wider displays crop more of the image and can lose the subject.
+
+Replace: choose fill or fit from the current size or aspect ratio, crop around
+a focal point, and extend backgrounds under bars with
+`backgroundExtensionEffect()` rather than stretching the image.
+
+## 10. Life cycle, legacy guides and the keyboard
+
+**Scene life cycle.** Hits: the four `application...` foreground and background
+callbacks doing real work in the app delegate, no `UIApplicationSceneManifest`
+in Info.plist, no `UIWindowSceneDelegate`.
+
+Why: from iOS 27, an app built with the latest SDK that has not adopted the
+scene-based life cycle fails to launch. The system also delivers foreground and
+background per scene, so app-level callbacks miss what happens to one window
+of several.
+
+Replace: a scene manifest and a scene delegate that creates the window with
+`UIWindow(windowScene:)`, and the per-window work moved to the scene callbacks
+(`sceneDidBecomeActive`, `sceneWillResignActive`, `sceneDidEnterBackground`,
+`sceneWillEnterForeground`). Work that runs once per process stays in
+`application(_:didFinishLaunchingWithOptions:)`. Supporting several windows is
+a separate, optional step.
+
+**Legacy layout guides.** Hits: `topLayoutGuide`, `bottomLayoutGuide`, and
+constants standing in for the status bar or navigation bar height.
+
+Why: those guides are deprecated and know nothing about side insets; a fixed
+bar height is wrong as soon as a bar moves or the status bar changes.
+
+Replace: `safeAreaLayoutGuide` and layout margins.
+
+**The keyboard.** Hits: frames computed from `keyboardFrameEndUserInfoKey` in
+a `keyboardWillShowNotification` handler.
+
+Why: a screen-space keyboard frame needs converting into the window by hand,
+and frame arithmetic misses the cases a resized window creates.
+
+Replace: constraints to `view.keyboardLayoutGuide` (iOS 15); SwiftUI already
+avoids the keyboard through the safe area.
+
+**Stored insets.** Hits: a safe-area inset copied into a property at load
+time.
+
+Why: insets change with pose, bar placement and Split View position.
+
+Replace: read them where layout happens, and react in
+`viewSafeAreaInsetsDidChange()` / `safeAreaInsetsDidChange()`.
+
+**Before replacing, classify.** An idiom or orientation check is a defect
+only when it stands in for available space. A check for a genuine capability of
+the device, or an orientation lock for a camera or game, stays.
+
+## 11. Recording the result
+
+For each hit, record `file:line`, the category, keep or fix, and for fixes the
+replacement. Separate "confirmed on the simulator" from "found in code only".
+Pose-dependent behaviour is not proven until it has been seen running.

package/pipeline/skills/shared/external/ios-iphone-duo/references/poses-and-panes.md

@@ -0,0 +1,122 @@
+# Poses, panes and the design review
+
+Design guidance for iPhone Duo. The rules marked HIG come from Apple's
+Designing for iPhone Duo page; the pattern table is a recommendation built on
+those rules and on size classes, and should be adapted to the app's content.
+
+## Contents
+
+1. Poses
+2. Pose to pattern
+3. Using the inner display
+4. Dual-pane rules
+5. Controls on the side
+6. The fold
+7. Review checklist
+
+## 1. Poses
+
+People hold and set down iPhone Duo in several ways (HIG): closed, using the
+outer display; open flat on the inner display; partially folded like a book;
+placed on a surface; standing on its edges. Every pose can also be rotated,
+and Split View can put two apps side by side on the inner display.
+
+Supporting poses does not mean a custom layout per pose (HIG). A compact
+width layout for the outer display and a regular width layout for the inner
+display cover the fundamentals; the existing layout expands into the space.
+
+## 2. Pose to pattern
+
+| Pose | Size class | What usually works |
+|---|---|---|
+| Closed, outer display | compact width | The phone layout. Bars on the side free vertical space; content offset from the bar side |
+| Open, inner display, landscape | regular width | One more level of hierarchy: list and detail side by side, or content reflowed into columns. Bars stay on the side |
+| Open, inner display, portrait | regular width | Same hierarchy as landscape; horizontal bars return because vertical space is plentiful |
+| Partially folded (book) | regular width | A split that rebalances around the fold; even column counts in grids; nothing tappable in the curve |
+| On a surface, partly folded | regular width | Viewing on the upper part, touch on the lower, stable part; suits media and hands-free use |
+| Standing on edges | depends on orientation | Glanceable, hands-free content with few controls |
+| Split View | either, per half | Each app keeps its controls on its outer edge; the app must work at half width |
+
+The on-surface layout is optional and still has to offer every control the
+other poses offer.
+
+## 3. Using the inner display
+
+A stretched phone layout is the failure to avoid. Options, in rough order of
+cost:
+
+- **Split view**: `NavigationSplitView` shows list and detail together when
+  open and collapses to a stack when closed. The hierarchy is the same; the
+  inner display shows one more level of it (HIG). Mail shows the list or a
+  message when closed and both side by side when open.
+- **Reflow**: a single column becomes two columns when width allows
+  (`ViewThatFits`, `AnyLayout`, adaptive grids).
+- **Arrangement**: two related views (now playing and lyrics, controls and
+  video) in an `ArrangementView` that adapts to the fold.
+- **Sidebar tabs**: a sidebar-adaptable tab view for information-dense apps.
+
+## 4. Dual-pane rules
+
+- Same functions and state on both displays (HIG). Opening or closing the
+  device mid-task must not lose a selection, a scroll position or a draft.
+- Never tie a function to a pose (HIG). Everything reachable in one pose is
+  reachable in all of them, even if it moves into overflow.
+- The secondary pane depends on the primary: selecting in the list drives the
+  detail. When the device closes, the detail the person was reading should be
+  what they see, not the list.
+- Keep controls with the content they act on (HIG). Actions for the list sit
+  above the list pane, not in the side bar beside the detail.
+- Each pane keeps its own safe area and margins; do not let one pane's insets
+  bleed into the other.
+- Prefer containers that rebalance themselves around the fold over manual
+  positioning (HIG), and in grids prefer an even number of columns so content
+  divides cleanly.
+
+## 5. Controls on the side
+
+- Follow the system's vertical placement and do not override it without a
+  strong reason (HIG); it is one of the device's core patterns.
+- Top of the vertical axis: Back or Close, then prominent actions such as
+  Done; remaining items keep their original groupings (HIG).
+- Give every item a symbol and a title; keep text-only buttons to a minimum,
+  because text items stay in a horizontal bar (HIG).
+- Assign visibility priority so frequent actions and items with badges stay
+  visible longest (HIG).
+- Use the system overflow menu instead of a custom one; reserve the ellipsis
+  for overflow (HIG).
+- Content next to side controls is asymmetric. Offset content by the safe
+  area by default; centre on the full display only for immersive,
+  non-scrolling screens with nothing interactive under the controls; or let a
+  background span the full width while the scrollable, interactive content
+  stays inset (HIG).
+
+## 6. The fold
+
+- Keep interactive elements out of the folding region (HIG). System controls
+  are moved aside automatically; custom ones use reserved regions.
+- Move as little as possible as the device folds (HIG). Small adjustments
+  that keep elements visible beat controls that vanish or jump.
+- Scrolling content may pass through the fold; fixed text and controls
+  should not rest in it.
+
+## 7. Review checklist
+
+Use with `ios-design-review` for the general visual pass.
+
+1. Is anything interactive in the fold or under the side controls?
+2. Is any function or piece of state available in one pose but not another?
+3. Does state survive opening, closing and folding mid-task?
+4. Are there fixed widths or device breakpoints instead of size classes?
+5. Do toolbar items have symbols and titles, sensible priorities, and does the
+   overflow hold the right things?
+6. Does the inner display do better than stretching (split, reflow,
+   arrangement)?
+7. Is content offset from the side controls, deliberately centred, or mixed
+   with every control inside the inset area?
+8. Does the screen hold up in Split View on both sides, at half width?
+9. Do custom components reimplement fold avoidance the system components
+   would have provided?
+10. Are controls next to the content they affect?
+11. Do grids divide evenly around the fold?
+12. Which of the above were seen on the simulator, and which only reasoned
+    from design files or code?