Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›iOS›iOS QA — Settings·21 in this wave

Wave

iOS QA — Settings

Settings is one category with 20 distinct live pages — one sign-off per page, iPhone only. Note two of them (Change Email, Change Password) live in the Onboarding folder despite being Settings screens, so they are easy to miss. iPad verification moved to the separate iOS QA — iPad wave.

TacTile › Launch TacTile › iOS › iOS QA — Settings

9/21 done12 open1 open blocker

Selected taskclear

QA: Notifications settings

To doOwner · Caitlint_18bfc491

Unlocks 1Approve: iOS QA — Settings

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: Notifications settings** · to do

Where it sits: TacTile › Launch TacTile › iOS › iOS QA — Settings

## Unlocks 1

- Approve: iOS QA — Settings

## The brief on file

RE-POINTED AT THE CLIENT 2026-09-01 — the original "server-side, do not touch the client" diagnosis is REFUTED by telemetry. Persisted Workers Logs over Caitlin's exact QA window: her device made 7 POSTs to /api/settings/notifications, six returned 200/ok, one outcome=canceled (client killed it mid-flight); ZERO [settings.notifications.post] errors in 20h; the DB row's updated_at matches her last POST to the millisecond. Reproduced 200s as both ben and quinn on prod AND staging. The server saved every write it received.

THE REAL DEFECT IS iOS-SIDE, two evidenced mechanisms in apps/ios/TacTileConnect/Features/Settings/ (fix in the next iOS wave):
1. NotificationsViewModel.saveDebounced() cancels the per-field task even when past its 500ms sleep and mid-POST → URLError(.cancelled) lands in the generic catch → "Couldn't save that change. Try again." + revert — while the save actually SUCCEEDED server-side (the measured canceled request is this path, live). The UI lies in both directions: reverts a saved value and reports failure.
2. A screen-open GET followed by zero POSTs is consistent with NotificationsService.makeRequest throwing .notSignedIn (token retrieval/refresh) before network I/O — same generic toast for any throw.
Fix shape: don't cancel an in-flight POST past the debounce (or treat .cancelled as retry-silently/ignore), reconcile UI state from the response, and split the error copy for auth-vs-network. Files: ViewModels/NotificationsViewModel.swift (saveDebounced/save), Services/NotificationsService.swift (makeRequest).

Context: deployed worker bb3d1845 is byte-identical to main for settings.ts, so no deploy dependency for this task.

## 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 — Settings

QA: Notifications settings