Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›Android›Android — Destinations build·43 in this wave

Wave

Android — Destinations build

Destination creation, viewers, and post-create editing. Creation is comprehensively built (~20 real builders across all 8 categories) despite stale in-code comments claiming otherwise. Editing is the real gap: only website and notes are editable post-create — 11 of 13 types show "Editing coming soon," mirroring iOS's destination-editing gap almost exactly.

TacTile › Launch TacTile › Android › Android — Destinations build

35/43 done8 open1 open blocker

Selected taskclear

Profile save wiped every profile field — fixed and deployed

DoneOwner · Vivt_7eb06121

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

**Profile save wiped every profile field — fixed and deployed** · done

Where it sits: TacTile › Launch TacTile › Android › Android — Destinations build

## The brief on file

DONE, MERGED AND DEPLOYED 2026-08-03. PR #191 merged as 99ed3d0d; tactile-api version a33a09d4 live on api.tactile.to. Verified on main by content, not by commit message.

Filed retroactively so the record exists — this was found mid-sweep and fixed in one pass, so it never had a task of its own.

THE FIFTH INSTANCE of the destructive-replace class, and the first found by LOOKING rather than by tripping over it. profile.ts carried BOTH shapes contact.ts fixed on 2026-07-29 — same table concept, same helper name (parseFieldsInput), same full-replace contract — and was simply never updated alongside it.

1. DELETE-THEN-INSERT ON EVERY SAVE. Deleted all profile_fields then inserted the replacements; a failed insert left the profile with none, unrecoverably. And it was not a rare branch: the shipped iOS client sends the `fields` part unconditionally ("We always send it (even if empty) on update" — ActionContentService.swift), so a save that only changed the bio or swapped a photo took the destructive path. profile_fields is TEMPLATE data — a profile mints many contact destinations over time — so the loss is wider than one card.

2. PARSE FAILURE READ AS "DELETE EVERYTHING". parseFieldsInput returned [] for a falsy value, an empty string, unparseable JSON and a non-array, while fields_provided was true whenever the part was merely PRESENT. An empty-string `fields` part — what a naive form serialiser emits for a valueless key — arrived as "provided, and empty", deleted every field, and returned 200. Worth noting iOS's own comment reasons that sending empty is "harmless" because the CREATE path treats empty and missing alike. True of create, false of update. That mismatch was the bug.

FIXED: parser now returns undefined / [] / [...] as three distinct answers; fields_provided derives from what it could READ, not from presence; dropped-entry count added and the update 400s if any were dropped (otherwise a partially-unreadable array inserts what parsed and deletes the rest — silent partial loss reported as success). Replace captures ids, inserts, deletes by id=in.(...). Create path unchanged.

Verified against the live catalog first: profile_fields.id is bigint NOT NULL, idx_profile_fields_profile is non-unique, so both sets coexist safely during the window.

TESTS: 9 added to tests/routes/destructive-replace-ordering.test.ts, validated against origin/main's route — 8 of 9 fail there while it still typechecks cleanly. The 9th is the metadata-only gate, unchanged, so passing on both is correct. Full suite 460/460 including the 16 pre-existing profile tests.

THE CLASS IS NOT CLOSED. Still open: t_c80e7372 (videos prune) and triggers.ts::deleteTrigger. And 24 route files plus apps/workers, apps/web server actions and apps/runs-engine were never audited. The answer to that is t_1c8645b0 — build verify:destructive-order, whose prototype found videos.ts unprompted and led to this fix. That check, not more hand-searching, is what prevents a sixth.

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

Android — Destinations build

Profile save wiped every profile field — fixed and deployed