Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›iOS›iOS — Destination editing·17 in this wave

Wave

iOS — Destination editing

Only THREE of 14 destination types actually persist an edit today — website, notes, document. Menu opens a real editor whose save is a no-op stub, so it dismisses as though it worked and silently discards the change. The remaining 10 show "Editing coming soon." Cost split matters here: gallery, video, audio and contact editors ALREADY EXIST and only need a router case wired, while payment, link hub, form, wifi, bluetooth and action must be built from scratch. Six of them also need a backend update endpoint that does not exist yet.

TacTile › Launch TacTile › iOS › iOS — Destination editing

13/17 done4 open1 open blocker

Selected taskclear

Approve: iOS destination editing

To doOwner · met_d997bb65Blocker

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

**Approve: iOS destination editing** · to do · blocker

Where it sits: TacTile › Launch TacTile › iOS › iOS — Destination editing

## Waiting on 13

- Build gallery destination editor — done
- Build contact / ConnectCard destination editor — done
- Build payment destination editor — done
- Build link hub destination editor — done
- Build form destination editor — done
- Build video destination editor — done
- Build audio destination editor — done
- Build wifi destination editor — done
- Build bluetooth destination editor — done
- Build action destination editor — done
- Fix menu editor save (currently a no-op stub) — done
- Sign off: the three working destination editors — to do
- Sign off: destination creation for all 14 types — to do

2 of those are still open. If one genuinely blocks this, say so and stop rather than working around it.

## The brief on file

UPDATED 2026-08-05 (iOS session) — the blocking defect this task told you to fix first is now FIXED and in review.

THE DEFECT IS RESOLVED: PR #223 (branch feature/ios, commit 57a1d275).
It WAS gating Edit at runtime — confirmed, not assumed. DestinationLaunchpad.isEditable read the stale set,
and its false branch did two things at DestinationLaunchpad.swift:551-554: relabelled the button
"Edit (coming soon)" AND replaced its action with an empty closure `{}`. So Edit was genuinely dead — not
degraded — for contact, payment, wifi, bluetooth, link hub, form, action, gallery, video and audio. Ten
editors, all built and merged across PRs #163/#166/#184/#185, that no user could open.

Nothing else was wrong: handleEditTapped is already type-agnostic, and loadContent returns .unsupported
rather than throwing for form/action, so those editors open fine once the gate lets go.
Fixed by making isEditableType an exhaustive switch with no `default`, so a 15th DestinationKind becomes a
compile error instead of another silently dead button. xcodebuild: ** BUILD SUCCEEDED **.

WHAT TO APPROVE: iOS destination editing for all 14 types — once #223 merges and Caitlin's device pass
(t_3c9ba08c) is done. NOTE the ten restored editors have never been exercised on a device, because until
#223 they were unreachable. A code-read approval is not enough here; the menu editor once dismissed as
though it had saved while silently discarding the edit, which no code read caught.

TWO PRODUCT DECISIONS STILL NEED YOUR CALL — both unchanged, neither affected by #223:

1. BLUETOOTH AUTO-PAIR — create and edit disagree, and the flag does nothing.
   BluetoothBuilderView.swift (lines 20/80/167) shows an auto-pair toggle and writes auto_pair on creation;
   the edit path drops it. No platform can honour auto-pair from a web/NFC handoff anyway. Decide: remove the
   toggle from create, or carry it through edit as a stored-but-inert field.

2. WI-FI "OPEN" SECURITY SILENTLY DESTROYS A STORED PASSWORD.
   Clearing the password field requires a destructive-role confirmation; flipping the security picker to
   "Open" does the identical damage server-side (wifi.ts:211) with no warning. Decide: treat the picker
   change as destructive (same confirmation), or preserve the password server-side and ignore it while
   security=open.

CONTEXT WORTH KNOWING BEFORE YOU APPROVE: pnpm verify is currently RED on origin/main — 8 failures across 3
vitest files, unrelated to iOS and unfixable from this lane (tracked as t_c86b1105). So "CI green" is not
available as an approval signal for this wave right now.

## 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 — Destination editing

Approve: iOS destination editing