Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›Backend & Infrastructure›Backend API·33 in this wave

Approve: Backend APITo do · blocker Implement /api/profile or remove routeDone Implement /api/uploadDone Implement destination analyticsDone Add upload size limits and file validationDone Define the API versioning strategyDone Verify all 14 destination content read endpointsDone Verify the five existing destination update endpoints workIn progress Fix the stale SENTRY_RELEASE on tactile-apiDone iOS decodes payment_destinations as an array — a latent whole-list decode failureTo do Add staging.tactile.to to the API CORS allowlistDone Emit CardSchema (not bare ActionPreview) from the 12 non-QR tool preview generatorsDone pnpm verify is red on main, and CI hides 9 more failures by excluding three test filesDone EMIT LEG: send method:\"link\" from the clients, or the Link bucket stays at zeroTo do POST /api/events/open is documented public+unauth but 401s anonymouslyDone Staging has no RATE_LIMIT_DO binding — both rate limiters fail open thereDone Mask the Wi-Fi password before it reaches agent proposal cards (blocks WifiCard)Done link_hub.ts has the identical partial-drop hole contact.ts just hadDone Add /health endpointDone Replace link-click placeholder zeroDone Verify documents/gallery/audio routes completeDone Add structured logging via pino-compatible APIIn progress Add request-id middlewareDone Add Sentry to WorkersDone Verify the four completed Backend API items in productionIn progress Build update endpoint for menu destinationsDone Build update endpoint for link_hub destinationsDone Build update endpoint for payment destinationsDone Build update endpoint for wifi destinationsDone Build update endpoint for bluetooth destinationsDone Build update endpoint for action destinationsDone Build the webhook MCP module (tools/webhook.ts) — Matthew chose SHIP over cutDone Derive per-type opIds for destination.create/edit so Website + Gallery cards can renderDone

Wave

Backend API

The long pole — Auth, Billing, Email, Custom Domains and Edge Functions all wait on this gate.

TacTile › Launch TacTile › Backend & Infrastructure › Backend API

27/33 done6 open1 open blocker

Selected taskclear

Mask the Wi-Fi password before it reaches agent proposal cards (blocks WifiCard)

DoneOwner · ait_897e6579

buildCardFields flattens every tool input key with no redaction, so wifi.create's plaintext password renders on the proposal card AND persists in the stored pending-action preview. Matthew decided 2026-08-06: mask server-side, then wire the card.

No dependencies in this wave — nothing gates it, and nothing waits on it.

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

**Mask the Wi-Fi password before it reaches agent proposal cards (blocks WifiCard)** · done

buildCardFields flattens every tool input key with no redaction, so wifi.create's plaintext password renders on the proposal card AND persists in the stored pending-action preview. Matthew decided 2026-08-06: mask server-side, then wire the card.

Where it sits: TacTile › Launch TacTile › Backend &amp; Infrastructure › Backend API

## The brief on file

HANDOFF FROM THE iOS SESSION 2026-08-06. Scoped to packages/** — iOS does not touch it.
MATTHEW DECIDED THIS 2026-08-06: mask SERVER-SIDE, then wire WifiCard. The alternatives (filter
client-side on iOS, or accept plaintext) were considered and rejected.

THE EXPOSURE. `buildCardFields` (packages/card-schema/src/index.ts:431-444) iterates every key of the
tool input and stringifies it — the only thing it skips is underscore-prefixed keys. `wifi.create`
carries a plaintext `password`, so today it becomes a visible CardField on the proposal card.

TWO SURFACES, AND THE SECOND IS THE ONE THAT MATTERS MORE:
 1. Display — the password renders on the agent card in the chat transcript.
 2. AT REST — the whole preview object is persisted with the pending action
    (`preview: entry.preview ?? {}`, packages/agent-core/src/pendingActions.ts:52). So the plaintext
    password is written to the pending-actions store and stays there. Masking only the display would
    leave that untouched, which is why the client-side option was rejected: it treats the symptom.
Mask at the point the field is BUILT, so neither surface ever sees it.

WHY IT IS LIVE NOW RATHER THAN THEORETICAL: PR #226's fail-closed wrap (preview.ts:160-161) means
wifi.create — a wired handler with no APPROVAL_REGISTRY entry — now produces a generic CardSchema
proposal instead of nothing. Before #226 no card fired for it at all. This is a new exposure created
by that change, not an old one.

TWO WAYS TO DO IT, either is fine:
 a. Key-based redaction inside `buildCardFields` — skip or mask keys matching password / secret / pin /
    token / api_key. Fixes every current and future tool at once, including bluetooth's `pin`, which
    has the identical problem and is worth covering in the same pass.
 b. A bespoke wifi generator in toolPreviews.ts that emits the fields it wants and omits the password.
    Narrower, and leaves the generic path exposed for the next tool that carries a secret.
Recommend (a), with (b) later if wifi wants a nicer card.

RESPECT THE THREE-STATE SEMANTICS. The iOS wifi EDITOR treats the password as keep / replace / clear,
because `wifi.ts` nulls a stored password when it receives a blank one. Whatever masking lands must not
turn "keep" into "clear" if a masked value is ever echoed back into a tweak or re-submit path. Masking
for DISPLAY must not become masking for TRANSPORT.

DONE WHEN: no plaintext password (or bluetooth pin) appears in a CardSchema field or in a persisted
pending-action preview; a test asserts it for wifi.create; pnpm verify green including
verify:swift-parity.

BLOCKS: t_8a9c2cd3 (iOS WifiCard wiring), which is otherwise ready — the iOS pattern is proven and
shipped for two cards in PR #229. iOS will wire WifiCard as soon as this lands.

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

Backend API

Mask the Wi-Fi password before it reaches agent proposal cards (blocks WifiCard)