Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›iOS›iOS QA — Core surfaces·40 in this wave

Approve: iOS QA — Core surfacesTo do · blocker Unblock QA: QR Studio crashes on open — reproduce on current main, fix, hand Kaitlynn a buildBlocked Unblock QA: decide launchpad-first Family + Group creation (holds 4 blocked QA tasks)To do SHIP LOOP TODAY: merge the green build candidates to main, redeploy web, produce debug builds for KaitlynnDone QA: DashboardDone QA: Canvas boardDone QA: Canvas node detail sheetBlocked QA: Canvas merge-into-group + group members popoverDone QA: Assets tab mainDone QA: Group launchpadDone QA: Family launchpad (Pro-gated)Blocked QA: Family detail + family canvasBlocked QA: New group + new/edit family sheetsBlocked QA: Family asset pickerBlocked QA: Analytics — Deep Dive tabDone QA: Analytics — Compare tabDone QA: Analytics — Real-time tab (Pro-gated)Done QA: Analytics — Map tab + full screenBlocked QA: Analytics — Goals tab (Pro-gated)Done QA: Analytics — Dashboards tab (Pro-gated)Blocked QA: Analytics — pickers and sheetsBlocked QA: AI agent panelDone QA: AI sessions drawer + approvals inboxTo do QA: Auth flow — all 9 statesDone QA: System sheets — all 6Blocked QA: QR & NFC hubBlocked QA: QR generator + customizerBlocked QA: QR logo/background croppersBlocked QA: QR manage launchpadDone QA: Link a QR code pickerBlocked QA: Program NFC tag flowBlocked QA: NFC manage tag launchpadDone QA: ConnectCard editorDone FIX: AI sessions drawer + approvals inbox [iOS] — in the approvals side bar when i hit X or approve i get an error…Done FIX: Program NFC tag flow [iOS] — the program NFC pop up for "choose how to program this tag" options…Done FIX: AI sessions drawer + approvals inbox [iOS] — when i asked it to make a qr code it did but when i hit the approve…To do QA: Compare says "No NFC or QR scans" for a destination only opened by link (iPhone)Blocked QA: A Free account's Dashboard has no "Couldn’t load your families" message (iPhone)Blocked QA: Dashboards — Compare to a custom range (iPhone)Blocked QA: QR Studio shows no readability grade until its check finishes (iPhone)Blocked

Wave

iOS QA — Core surfaces

Page-by-page human sign-off on the main app surfaces. Owner Kaitlynn, gate Matthew.

TacTile › Launch TacTile › iOS › iOS QA — Core surfaces

17/40 done23 open1 open blocker

Selected taskclear

QA: System sheets — all 6

BlockedOwner · Kaitlynnt_d563d8a8

Unlocks 1Approve: iOS QA — Core surfaces

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

**QA: System sheets — all 6** · blocked

Where it sits: TacTile › Launch TacTile › iOS › iOS QA — Core surfaces

## Unlocks 1

- Approve: iOS QA — Core surfaces

## The brief on file

[2026-10-08 · Viv] WAITING ON MATTHEW — supersedes any earlier block below
DECISION: Merge #722 (SupabaseClient config race) and #727 (No Internet sheet, noInternet only for v1.0), then cut TestFlight build 1.1 (7) at the Mac?
RECOMMEND: Yes: both pass every check that runs (verify fails only on the sanctioned rotation step, your 30 Sep merge rule, which also skips two API-only steps that an iOS diff does not touch) and merge clean against main; noInternet-only is the right v1.0 scope because the other five sheets have no trigger in the app.
IF YES, NEXT: Viv marks both ready (1 min); you squash-merge both (2 min). After the App Store Connect agreement and QA group (iPad block), Viv runs fastlane ios beta on your Mac; you click Always Allow on the codesign prompt and answer export compliance No (the rest is about 30 min of unattended build and upload). Viv adds 1.1 (7) to the QA group and flips the four cards to todo once it is in her TestFlight. Kaitlynn the same day: QR generator (t_b653cafd), croppers (t_063a2a3f), QR & NFC hub (t_1e7f6462), then the airplane-mode No Internet check (t_d563d8a8, about 10 min).
COST IF YES: About 5 minutes of yours plus about 30 minutes of unattended build and upload, $0. #722 fixes a real crash-class race but is not proven to be the QR Studio crash, so the QR cards can still fail on a device; if the app closes she sends you the crash log.
COST IF NO: Each card holds 20 open tasks downstream, 13 of them Kaitlynn's; t_1e7f6462 can still run on build 6 with step 4 skipped.
SAFE TO ASSUME: Nothing deploys on merge; the other five system sheets get logged as "not hooked up yet, expected".

[2026-10-08 · Viv] Status note, status unchanged (blocked). PR: #727 (draft, r28/ios-no-internet-sheet). CI after the 8 Oct re-run (head 8d572be1, 4 files, +320 -2: project.pbxproj, RootView.swift, new ConnectivityMonitor.swift, new ConnectivityMonitorTests.swift; still DRAFT, not merged, nothing pushed): build & test, swift-parity, semgrep, dep-scan, static-firewall, changes and playwright all PASS. playwright was cancelled on 5 Oct after 24m34s waiting for a runner (the playwright-e2e-supabase concurrency group displaced it) and never ran; re-run alone on 8 Oct it passed (job 113641246344, 10m02s, finished 19:41 PDT). verify was re-run too (job 113643845369, 8m51s) and fails on exactly one step, 'Secrets rotation audit' (pnpm verify:secrets-rotation): the inherited red, the same step main fails at 4f2c1d6b (runs 37650755658 and 37807701401), covered by Matthew's 30 Sep rule in t_2d37e7fb. The first verify attempt on 5 Oct showed the same single red while the host was saturated; on this re-run it was again the only failing step even with host load 250. Merge simulation against origin/main 4f2c1d6b is clean. THE MERGE IS MATTHEW'S (gh pr ready 727, then his squash merge); I did not mark it ready. Merging touches no web or API code, so nothing deploys. Compile proof by name: ConnectivityMonitor.swift appears 4 times and ConnectivityMonitorTests.swift 4 times in the PR's project.pbxproj. SCOPE CALL STILL OPEN (Matthew): the PR wires noInternet only; the other five sheets (serverError, scanFailed, scanPermissions, actionNotFound, loading) have no trigger, and the standing recommendation is to ship noInternet only for v1.0. The build: she only gets #727 in TestFlight 1.1 (7) or later (the same build as #722 if both merge first). That needs Matthew to accept the App Store Connect agreement (403 on 5 Oct), run fastlane ios beta from apps/ios at the Mac, answer export compliance, and put the build in an internal TestFlight group that has her in it. Status stays blocked until she has it; then I flip it to todo.
WHAT SHE CHECKS THE DAY THE BUILD REACHES HER TESTFLIGHT (about 10 minutes, on her iPhone; a Wi-Fi iPad works too): Airplane Mode on, wait about 5 seconds, the sheet 'No Internet Connection' shows; Airplane Mode off, it closes by itself; Airplane Mode on again and swipe the sheet away while offline, it must not come back; an on/off blip under 2 seconds must show nothing. She marks the card pass for the No Internet sheet with the note 'other five not hooked up yet, expected' (the brief says so). Unverified by design, so her run is the first real test: the real NWPathMonitor on a device (the simulator shares the host network), the sheet over onboarding or sign-in, and a screen that already has its own sheet up.

[2026-10-05 · fixer] PARKED: path to this screen added in https://github.com/TacTile-dev/TacTile/pull/727; flip to todo once that ships to her build.

WHAT THE PR DOES: draft PR #727 (base main, branch r28/ios-no-internet-sheet, commit 8d572be1). New ConnectivityMonitor (NWPathMonitor behind a 3s debounce) plus RootView presenting SystemSheet.noInternet when the device has been offline for 3s and clearing it on recovery. Wires 1 of the 6 sheets. The other five are untouched.
VERIFIED: 16 unit tests green on the iPhone 17 Pro simulator (xcodebuild test -only-testing:TacTileConnectTests/ConnectivityMonitorTests); pnpm verify:swift-test-coverage and verify:swift-source-coverage green. On the simulator, with the path forced to .unsatisfied by a temporary local probe (not committed), the No Internet Connection sheet presented about 3s later over the signed-in dashboard, and swiping it down closed it and it did not re-present.
NOT VERIFIED: a real airplane-mode toggle on a device (the simulator shares the host network, so the real NWPathMonitor could not be driven); the sheet over the onboarding/sign-in screen (presenter exists, not exercised); behaviour while a child screen already has its own sheet or full-screen cover up (SwiftUI defers the second presenter; the verdict is cleared if the network returns first). Kaitlynn's brief below is the first real-radio test.
TO UNPARK: merge #727 and wait until it is in a build she can install, then set status=todo. Her card is titled "all 6": pass it for noInternet only and record the other five as expected-skip until the decision below lands, or ask Matthew to split the card.

DECISION (Matthew): triggers for the other five system sheets (serverError, scanFailed, scanPermissions, actionNotFound, loading)
Decision: for v1.0, wire the other five (each needs a defined trigger), or ship noInternet only and make the rest inline states or delete them?
Recommend: ship noInternet only for v1.0 (PR #727) and decide the rest per screen after launch review. Suggested homes: scanFailed and scanPermissions as inline states inside the NFC/QR scan flows where the failure happens; actionNotFound on the viewer; serverError only after a rule exists for which statuses count (suggest 5xx after a retry, never 4xx).
Cost-if-yes: roughly 4-5 more small PRs and a product call per screen, each touching a live flow (scan, viewer, API client), with the risk of sheets popping over flows that work. Spends launch-week time on screens the launch does not depend on. (Estimate, not measured.)
Cost-if-no: scan failures, denied permissions and 404 destinations keep falling back to each screen's own behaviour (silence or stale cache), which is today's behaviour; five built-but-unreachable views stay in the dev catalog as dead code. If the answer is "inline, not sheets", delete those five views and their UIVCatalog entries and close this card.

[FOR KAITLYNN]
WHAT THIS IS
When your phone has no internet, the app should now tell you with a message that slides up over the screen: "No Internet Connection". This is the first of the six system screens to be hooked up. The other five (Server Error, Scan Failed, Permissions Needed, Destination Not Found, Loading) are still not hooked up on purpose, so you can't make them appear. Don't try to trigger those.

HOW TO GET THERE
1. Open the app on your iPhone, signed in, on any screen. The Dashboard is fine.
2. Turn on Airplane Mode (swipe down from the top-right corner and tap the airplane). If Wi-Fi comes back on by itself, turn Wi-Fi off too.
3. Leave the app open and don't touch anything for about 5 seconds.

WHAT TO CHECK
1. After a few seconds a white sheet slides up with a crossed-out Wi-Fi symbol, the words "No Internet Connection", and underneath "Please check your connection and try again."
2. Turn Airplane Mode off again. Within a few seconds the sheet should close by itself and you should be right back where you were.
3. Turn Airplane Mode on again and wait for the sheet. This time swipe the sheet down to close it. It should stay closed and not pop back up while you are still offline.
4. Turn Airplane Mode off, then on again, and wait. The sheet should show again.
5. Quick blip: turn Airplane Mode on and off again within about 2 seconds. No sheet should appear.

PASS IF
The sheet shows up within about 5 to 10 seconds of going offline, closes by itself when the connection comes back, and does not appear on a quick blip. Mark this card pass for the No Internet screen and add a note: "other five screens not hooked up yet, expected".

FLAG IT IF
- No sheet after 10 seconds offline.
- The sheet appears while you do have internet.
- The sheet doesn't close after the connection comes back.
- It keeps flickering on and off.
- The wording is different from the above.
- Any of the OTHER five screens appears (Server Error, Scan Failed, Permissions Needed, Destination Not Found, Loading).
[/FOR KAITLYNN]

(Everything below is the pre-fix state. The old tester text under WHAT THIS IS is superseded by the Kaitlynn brief above once #727 ships.)

[2026-10-05 · triage] cause=unreachable: re-verified on origin/main 938b9a6c. `systemSheet` is declared at System/Navigation/RootView.swift:54 and read by the two `.sheet(item: $systemSheet)` at :89 and :137, and is never assigned anywhere in apps/ios (the only other hit is the dev catalog, Screens/UIVCatalog.swift:1075). None of the six SystemSheet cases (loading, noInternet, serverError, scanFailed, scanPermissions, actionNotFound, enum at RootView.swift:461) can ever present. Smallest safe wiring: connectivity only (NWPathMonitor observer in RootView setting `.noInternet` after the path has been unsatisfied for ~3s and clearing it on recovery); the other five need Matthew's trigger decisions (see the engineering notes). Not fixed here.

WHAT THIS IS
Six full-screen messages the app is supposed to show for specific problems — no internet connection, a server error, a failed scan, missing camera or scan permissions, a destination that can't be found, and a loading spinner.

HOW TO GET THERE
There is no way to trigger any of these six right now, on purpose or by accident — see below.

WHAT TO CHECK
None of these six screens can currently appear at all, for anyone, under any condition — it isn't a data problem, and you can't trigger one by going offline or scanning something broken. The app is simply never told to show them, so if you go offline expecting a "no connection" message, you won't get one; whatever screen you're on will just look stale or silent instead. This isn't something you can test by trying harder or a different way. Please mark this card as skipped rather than pass or fail, with a note that none of the six screens are wired up to anything yet.

FLAG IT IF
Nothing to flag here — there's genuinely nothing for you to check. If you ever do see one of these appear (a "No Internet Connection" message, a "Server Error" message, and so on), that's actually worth reporting, since it would mean something changed.

------------------------------------------------------------
Engineering notes and history below this line - background for whoever
fixes the screen, not instructions for the tester.
------------------------------------------------------------

Kaitlynn — verify all 6 system sheets on iPhone. File: System/Sheets/SystemSheetViews.swift, presented from System/Navigation/RootView.swift. iPhone only.

QA 2026-09-01 (Kaitlynn) — CANNOT BE TESTED. All six sheets are UNREACHABLE. Kaitlynn went offline expecting the no-internet sheet and got nothing; her guess was that the demo data was masking it. It is not the data — the screens cannot appear at all.

PROVEN BY GREP, not inferred. `systemSheet` appears exactly five times in the whole app:
  · RootView.swift:54  — `@State private var systemSheet: SystemSheet?`
  · RootView.swift:89  — `.sheet(item: $systemSheet)`
  · RootView.swift:137 — `.sheet(item: $systemSheet)`
  · Screens/UIVCatalog.swift:104, 902 — the internal screen catalog
There is NO assignment anywhere. The state is declared, read by two presenters, and never written, so it stays nil for the life of the app. AppLoadingView, NoInternetView, ServerErrorView, ScanFailedView, ScanPermissionsView and ActionNotFoundView are built, wired into RootView.sheetView(for:), and reachable only from the dev catalog.

Third instance of this pattern this session — see t_3d9d5b6b (Quick tutorial: complete screen, no entry point) and the Android QrListScreen finding (t_378d48ce). Worth treating as a class of defect rather than three separate tickets: screens get built, the host wiring never lands, and nothing catches it because the code compiles and the screens look done in a catalog.

WHAT THE USER GETS INSTEAD, and why this matters at launch: with no connectivity there is no explanation anywhere — each screen falls back to its own behaviour, which is stale cache or silence. AnalyticsAPIClient additionally caches GETs for 120s, so an offline user may see data that looks live. A customer whose scan fails, whose permissions are denied, or whose destination 404s currently gets no dedicated screen for any of it.

NEEDS A PRODUCT DECISION BEFORE WIRING, which is why this is blocked rather than fixed: each sheet needs a defined trigger — what counts as "no internet" (a reachability check, or the first failed request?), which HTTP statuses mean serverError versus a silent retry, whether actionNotFound belongs here or on the viewer, and whether these are sheets at all or should be inline states on the screens that fail. Wiring them to arbitrary conditions would be guessing at product behaviour.

## 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 QA — Core surfaces

QA: System sheets — all 6