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

Menu update wipes every section/item/price on any mid-rebuild failure

DoneOwner · Vivt_cfda0be6Blocker

Saving an edited menu deletes the whole menu first and rebuilds it. If anything fails partway, the menu is gone and there is no backup to restore it from.

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

**Menu update wipes every section/item/price on any mid-rebuild failure** · done · blocker

Saving an edited menu deletes the whole menu first and rebuilds it. If anything fails partway, the menu is gone and there is no backup to restore it from.

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

## The brief on file

DONE, MERGED AND DEPLOYED TO PRODUCTION 2026-08-03.

PR #190 merged as 8faf6de1. tactile-api deployed — version b79e19bc, live on api.tactile.to. Verified the fix is on main by CONTENT (git show origin/main:...), not by trusting the commit message — see the note at the bottom of this entry for why that distinction earned its place.

WHAT SHIPPED. menu.ts no longer deletes every section before rebuilding. It captures the existing section ids, builds the new sections alongside them, and removes the old set by id=in.(...) only once the rebuild fully succeeds. Because the rebuild can still fail halfway, all five of its failure exits route through abortRebuild(), which deletes exactly the sections that request created — otherwise the menu would end up showing its original sections plus a truncated copy.

  rebuild fails      -> partial build removed, ORIGINAL menu untouched
  final delete fails -> menu lists both copies; visible, fixed by saving again

THEN AN ADVERSARIAL REVIEW FOUND THREE MORE THINGS, ALL FIXED IN THE SAME PR. Worth reading, because two were in my own fix:

1. `sections: []` STILL WIPED THE WHOLE MENU. This is the one destruction path insert-before-delete cannot close, because the caller asks for it — an empty replacement deleted every section, CASCADEd through items/variations/modifier groups/modifiers, and returned 200. createMenuAction already refused it (:174) and so does link_hub's update; THIS ROUTE WAS THE ONLY ONE OF THE THREE THAT ACCEPTED IT. A client whose menu draft collapses to empty after a failed content load sends exactly that payload. Now a 400, refused before any read or write.
2. A THROWN fetch skipped the rollback entirely. abortRebuild only ran on the `!res.ok` branches, so a reset connection or an eviction mid-await stranded a half-built duplicate. createMenuAction already wrapped its inserts; the update path now matches.
3. A comment I wrote was wrong — it claimed the rollback "never strands a section it created", which is false for the `!sectionId` branch where the POST may commit while the response carries no id. Corrected to name the gap rather than assert something untrue.

Also added an `id` tiebreak to the public read ordering: during the window both sets exist with the same ordinals, and `order=ordinal` alone let the planner interleave them arbitrarily. Old rows have lower ids, so a viewer catching the window now sees the outgoing menu followed by the incoming one.

TESTS: 16, and they were checked against origin/main's code rather than merely observed to pass — 14 of the 16 fail against it while it still typechecks cleanly. Full tactile-api suite 451/451.

THREE OF MY OWN TESTS WERE INITIALLY FALSE GREENS and this is the part worth carrying forward. The "leaves the previous menu intact" cases searched the delete URL for the original section ids — but the old code deleted by destination_hash and never named them, so all three passed against the exact code they existed to catch. Only running them against the old implementation exposed it. Any future fix in this class must be validated the same way.

Post-deploy smoke: /api/health 200; PATCH /api/menu/<x> 401 (gate fires before anything destructive); menu/contact/link-hub content routes 404. CI did not run — Actions billing wall (t_412e17f7).

STILL OPEN, from the same review: t_ff155928 (contact's parser silently drops unreadable field entries then deletes them — different bug class), plus concurrency, 500-semantics, the latent modifier-groups gap, and the PostgREST row cap. All detailed on t_ff155928.

DEPLOY NOTE: `npx wrangler deploy` fails with "You need 'containers:write'" and re-logging in does not help. Use the 1Password token — full recipe on t_bac8915a.

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

Menu update wipes every section/item/price on any mid-rebuild failure