Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›iOS›iOS — iPad adaptation·14 in this wave

Approve: iOS iPad adaptationTo do · blocker Audit every screen on iPad and record what breaksDone Adapt Dashboard for iPadTo do Adapt Canvas for iPadTo do Adapt Settings for iPadTo do Adapt destination creation funnel for iPadTo do Adapt destination builders for iPadTo do iPad punch-list row 7 is FIXED BUT UNPROVEN — and it gates the iPad releaseDone iPad: three whole surfaces have no adaptation row — Analytics, Assets, and the Destination LaunchpadTo do Handle NFC-unavailable messaging on iPadTo do Adapt destination viewers for iPadTo do Adapt QR generator + croppers for iPadTo do Adapt ConnectCard editor for iPadTo do Adapt AI agent panel for iPadTo do

Wave

iOS — iPad adaptation

CORRECTED 2026-08-07 (iOS session, PR #252) — the framing below was misleading in a way that explains two deferrals. THE APP WAS iPHONE-ONLY. `TARGETED_DEVICE_FAMILY = 1` in both the project-level and app-target build configs, Debug and Release. On iPad it ran in COMPATIBILITY MODE — a letterboxed, phone-shaped window that was never given iPad geometry. So "only 2 of ~57 screens have real iPad layout" understated it: ZERO screens rendered at iPad size in a shipping build. And critically, `horizontalSizeClass` is `.compact` in compatibility mode while `.readableWidth` gates on `.regular` — so ALL ~37 existing call sites were no-ops on iPad. The adaptation infrastructure was real, correct, and entirely dead. Split View and Slide Over were unavailable, so every multitasking bug was unreachable too. Nothing in this wave could have been OBSERVED by anyone before that flip, which is a fair explanation for why a surface this large stayed untouched. FLIPPED TO "1,2" IN PR #252, and verified by building for and launching on an iPad Pro 13" simulator: the app now fills the window natively (2064x2752, no letterbox), and the Dashboard's existing cap renders correctly. RELEASE CONSEQUENCE — needs Matthew's awareness before any submission: the app now appears on iPad in the App Store and will need iPad screenshots. It should NOT ship to iPad until the `broken` band of the punch list is cleared. The flip makes the work visible and testable; it does not make the app iPad-ready. If that ordering is wrong for the release plan, that commit is the one to revert. THE PUNCH LIST IS docs/proposals/ios-ipad-adaptation.md — 72 rows from a 6-auditor sweep, deduplicated and severity-normalised to the FUNCTIONAL bar (nothing broken or unusable; polish is the agreed fast-follow), ordered broken → risky → gap and within each by traffic. It ports the three failure modes from the Android tablet audit into SwiftUI terms. TWO THINGS WORTH CARRYING FORWARD: 1. Mode 2 (a correct width cap with the page background painted INSIDE it) is not present anywhere today — all 37 call sites get the order right. It is purely a hazard of FIXING the rows: four screens are called out where the obvious one-line fix would introduce it. 2. The Android doc's closing instruction — "None of the three is visible in code review. Take the screenshot." — paid off immediately. The first iPad screenshot produced two findings no static auditor could see: the weekly-scans chart rendering as seven thin rules, and the NFC SIM debug pill occluding the Dashboard tab label. Screenshot every screen you touch. REMAINING: the rows themselves. The four highest-traffic flows (Dashboard, Destinations list + launchpad, Create flow, agent panel) are the intended start, and every fix is now verifiable on a real iPad window rather than guessed at.

TacTile › Launch TacTile › iOS › iOS — iPad adaptation

2/14 done12 open1 open blocker

Selected taskclear

iPad: three whole surfaces have no adaptation row — Analytics, Assets, and the Destination Launchpad

To doOwner · ait_af4f383f

No dependencies in this wave — nothing gates it, and nothing waits on it.

Show the prompt

You are Viv, the agent for the TacTile lane of Command.

Open the lane and work there:

```bash
cd ~/Command/tactile && claude
```

Read that lane's CLAUDE.md and lane.json before you touch anything — they
carry your identity, your scope, and the hazards specific to this lane.
Read state from the hub (https://internal.tactile.to) or ask. Never guess at it.

## The task

**iPad: three whole surfaces have no adaptation row — Analytics, Assets, and the Destination Launchpad** · to do

Where it sits: TacTile › Launch TacTile › iOS › iOS — iPad adaptation

## The brief on file

CORRECTED 2026-08-09 — the first version of this row carried TWO premises that source disproves. Both are fixed below. Read this version, not any quotation of the old one.

THE GAP IS REAL: this wave has thirteen rows and none names Analytics, Assets, or the Destination Launchpad, while all three are on the punch list and all three are unfixed. Verified: `grep -c readableWidth` returns 0 for AnalyticsKitMapScreen.swift, DashTileGrid.swift, AnalyticsKitGoalsScreen.swift, AssetsHostView.swift, DestinationLaunchpad.swift and DestinationHistoryView.swift. The infrastructure already exists — `ReadableWidth` and `.readableWidth()` live in System/UI/PlatformAdaptive.swift:83-120 and 36 other files use them. This is applying a proven modifier, not building one.

**CORRECTION 1 — DO NOT START WITH ASSETS. Row 74 is not a hazard.**
The original said a 430pt sidebar leaves ~77pt of detail pane at ~507pt half-width multitasking. It cannot: BOTH hosts gate the two-pane on `geo.size.width > 980`, so at 507pt the split does not render at all and there is no detail pane to squeeze. The 77 came from 507−430 computed as if it did. Minimum firing width is >980, which leaves ≥549pt. The punch list itself hedged this — "worth confirming the collapse actually fires before treating it as broken" — and it does fire, correctly. Row 74 is a **cosmetic 208pt inconsistency** (430 vs Analytics' 222 on the same device), not a multitasking hazard.

**START WITH THE DESTINATION LAUNCHPAD instead** (rows 24, 25, 28). It is uncapped at full window width AND it is what fills the ~936pt Assets detail pane, so it is two surfaces for one fix. Three primary 56pt capsules become ~1270pt pills; the description editor is a 1270×96 slab.

**CORRECTION 2 — DO NOT PRESCRIBE `.wide` (980) FOR ANALYTICS.**
The original did. It is INERT in portrait: the two-pane detail column is window − 222 − 1, so a 13" iPad gives ~1143 in landscape (binds) but ~801 in portrait (does not bind — while the two-pane still fires, because 1024 > 980). A cap that cannot bind is the exact defect this project has already lost a round to, and `AnalyticsHostView.swift:111-122` documents that in its own words. **Use `.standard` (760)** — which is what the three Analytics sub-pages the host caps successfully already use.

That I wrote a non-binding cap into a row whose whole purpose is fixing non-binding caps is worth keeping visible rather than quietly deleting.

**ROW 75** (the Assets detail pane has no toolbar) is a design call, not an adaptation fix. Split it out rather than bundling it.

**PROOF — the iPad lesson from rows 7 and 18 applies and will save a wasted round.** XCUITest reports a frame CLAMPED into the window, so an assertion on a raw position or a container height cannot discriminate: with the bug the element stays inside the window and looks fine. Row 7 was finally proven with a RATIO (sheet height ÷ window height, preserved across rotation, self-calibrating so it needs no device size). For a width cap the equivalent is content width ÷ window width, asserted **strictly narrower than the window** — `assertCapped` originally asserted only `w <= cap`, which is green both ways on a fixture already at or below the cap.

MUTATION, per surface: remove the cap you just added; the assertion must go red. If it stays green you are measuring something clamped — redesign and say so. Do not report a surface done on a green test.

SIMULATOR: resolve the UDID EXPLICITLY — three devices share the "iPad Pro 13-inch (M5)" name and they run iOS 26.4, 26.5 and 27.0, on which `isHittable` behaves differently. All three were Shutdown at filing. Shut down and re-boot between runs; rotation state persists into the next test. Do not disturb a simulator another session booted.

## How to work this

- Do the work, don't just plan it. If the fix is obvious and safe, make it.
- Surface anything needing Matthew's sign-off instead of deciding it yourself.
- Short replies. Lead with the answer, then stop.
- Finish by saying what changed, what you verified, and what you'd do next.

To doIn progressDoneBlockedPick a wave on the left · tap a task to expand it

Lanes

iOS — iPad adaptation

iPad: three whole surfaces have no adaptation row — Analytics, Assets, and the Destination Launchpad