Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›Web›Web → app handoff·12 in this wave

Approve: Web → app handoffTo do · blocker Register the deep-link scheme on iOSTo do Set up iOS Universal Links for the handoff pathsTo do Set up Android App Links for the handoff pathsTo do Build the deep-link routing layerTo do Design the handoff experienceTo do Build the desktop handoffTo do Build the mobile-web handoffTo do Handle the not-installed case gracefullyTo do Build the return path after programmingTo do Make the capability boundary honest in the web UITo do Verify the handoff end to endTo do

Wave

Web → app handoff

Web can't write NFC tags, so programming a physical tag has to hand off cleanly to the native app. Deep-link infrastructure may not exist at all — verify before building on it.

TacTile › Launch TacTile › Web › Web → app handoff

0/12 done12 open1 open blocker

Selected taskclear

Build the deep-link routing layer

To doOwner · Vivt_c33ad345

Viv — Build a real routing layer that parses an incoming link and navigates to the right screen with the right state, on both iOS and Android. Done when: tactile:// and https://tactile.to/handoff/* links (plus Android App Link equivalents) resolve to the correct screen with destination/type state pre-loaded, on both platforms, without disturbing existing auth-callback handling. File: apps/ios/TacTileConnect/System/App/TacTileConnectApp.swift, apps/android/app/src/main/java/com/tactile/app/MainActivity.kt.

Waiting on 3 · 3 still openRegister the deep-link scheme on iOS Set up iOS Universal Links for the handoff paths Set up Android App Links for the handoff paths

Unlocks 5Build the desktop handoff Build the mobile-web handoff Handle the not-installed case gracefully Build the return path after programming Approve: Web → app handoff

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 the deep-link routing layer** · to do

Viv — Build a real routing layer that parses an incoming link and navigates to the right screen with the right state, on both iOS and Android. Done when: tactile:// and https://tactile.to/handoff/* links (plus Android App Link equivalents) resolve to the correct screen with destination/type state pre-loaded, on both platforms, without disturbing existing auth-callback handling. File: apps/ios/TacTileConnect/System/App/TacTileConnectApp.swift, apps/android/app/src/main/java/com/tactile/app/MainActivity.kt.

Where it sits: TacTile › Launch TacTile › Web › Web → app handoff

## Waiting on 3

- Register the deep-link scheme on iOS — to do
- Set up iOS Universal Links for the handoff paths — to do
- Set up Android App Links for the handoff paths — to do

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

## Unlocks 5

- Build the desktop handoff
- Build the mobile-web handoff
- Handle the not-installed case gracefully
- Build the return path after programming
- Approve: Web → app handoff

## The brief on file

No deep-link routing layer exists on either platform today — this is new infrastructure, not an extension of something existing. iOS: onOpenURL (TacTileConnectApp.swift:49 and :82) unconditionally forwards every URL to AuthService.handleURL with zero dispatch by host/path. Android: MainActivity.kt + AuthDeepLinkHandler.kt only handle the /auth/callback case; there's no generic router. Build a router on each platform that inspects the incoming URL (scheme tactile://, or https://tactile.to/handoff/... once Universal Links / App Links are wired) and either (a) routes to AuthService/AuthDeepLinkHandler unchanged for auth paths, or (b) navigates to the right in-app screen with parsed query state for everything else (starting with the AI cards' destination/new?type=X pattern and the new web→app handoff route). IMPORTANT — this is the same root-cause fix as an existing tracked task: "Fix unregistered tactile:// URL scheme breaking every AI card 'Open in editor' handoff" (t_eb0959b9). That task is about the AI cards specifically bouncing out to Safari; this routing layer is what actually makes those "Open in editor" buttons and the new NFC handoff both work once the scheme/Universal Links/App Links are registered. Coordinate with whoever picks up t_eb0959b9 rather than building two routers. Done when both the AI-card self-links and the new handoff links land on the correct screen with state.

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

Web → app handoff

Build the deep-link routing layer