Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›iOS›iOS — Destination viewers·10 in this wave

Approve: iOS destination viewersTo do · blocker Fix form destinations showing the contact viewerDone Build dedicated link hub viewerDone Build dedicated payment viewerDone Build dedicated action viewerDone Sign off: the eight dedicated destination viewersTo do Fix Video destination viewer — DestinationViewerScreen passes no content argumentDone Contact preview loses fax identity, extra addresses, notes and every preserved fieldTo do Build dedicated wifi viewerDone Build dedicated bluetooth viewerDone

Wave

iOS — Destination viewers

6 of 14 types show a wrong or generic viewer. Form shows the contact viewer — a straight bug.

TacTile › Launch TacTile › iOS › iOS — Destination viewers

7/10 done3 open1 open blocker

Selected taskclear

Build dedicated action viewer

DoneOwner · Vivt_29b67e82

Unlocks 1Approve: iOS destination viewers

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

**Build dedicated action viewer** · done

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

## Unlocks 1

- Approve: iOS destination viewers

## The brief on file

DONE 2026-07-30 (Viv) — PR #165, commit 322e6112. ActionViewer covers all EIGHT subtypes in
one view: phone, sms, email, facetime, location, url, calendar, webhook. Note the count — an
earlier brief in this project said seven and omitted "url".

Previously .action mapped to LaunchpadActionType.link and rendered WebsiteActionViewer.

WEBHOOK SAFETY IS DOUBLE-GUARDED and was verified independently in review: the viewer CANNOT
fire a webhook. A webhook is a side-effecting request and previewing a destination must never
trigger it — the viewer displays the target and explains what it would do.

Cannot fabricate content — no placeholder path in any state.

ONE REAL DEFECT FIXED DURING INTEGRATION: .task(id:) keyed only on reloadToken and not on
actionId, so a reused view whose destination changed would keep showing the PREVIOUS
destination's content. Now keys on a composite taskKey, matching all four sibling viewers,
which document that exact hazard in their own comments. That is the kind of bug that only
shows up when a customer taps quickly between two destinations.

Clean build from fresh derived data. 4 pbxproj references (was 0 — never compiled).

## 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 viewers

Build dedicated action viewer