Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

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

Wave

Android — Destinations build

CORRECTED 2026-09-22 — THE EDITING CLAIM IN THE OLD GOAL IS FALSE. Verified in code, not inferred. The old goal read: "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." ALL FOURTEEN KINDS ARE EDITABLE ON ANDROID TODAY. DestinationLaunchpadViewModel.canEdit() (apps/android/.../ui/destinations/launchpad/DestinationLaunchpadViewModel.kt:242-256) returns true for WEBSITE, NOTES, WIFI, BLUETOOTH, PAYMENT, LINK_HUB, ACTION, DOCUMENT, VIDEO, AUDIO, CONTACT, MENU, FORM and GALLERY. startEdit() has a real branch for each, and the ViewModel carries per-kind editor state (wifi security coercion, gallery span baselines, document metadata, and so on). The "Editing this destination type is coming soon." string at :457 survives only as the `else ->` fallback of an exhaustive when, which no kind reaches. CREATION was already comprehensively built (~20 builders across all 8 categories), which the old goal did say. TWO STALE ARTEFACTS IN THE SAME FILE, both worth fixing rather than re-deriving: 1. The class KDoc at :133-137 still says "per-type content edit (website URL / note body in this chunk — other types report 'coming soon', matching the iOS editor router's own fallback)". That sits FOUR LINES above the allowlist that disproves it. Filed as its own row. 2. DestinationLaunchpadScreen.kt:463 renders `if (viewModel.canEdit(record.type)) "Edit" else "Edit (coming soon)"`. The else arm is now unreachable for every kind; harmless, but it is the visible half of the same stale claim. WHAT IS ACTUALLY LEFT IN THIS WAVE (all backend or human QA, none of it Android UI): · t_409f79aa — pin the destination-scoping predicate on collection writes (static scan over routes/). · t_40aa2a6c — visibility-gate's owner exception has no test; deleting it keeps the suite green. · t_506b6cdc — form.ts writes `fields` entries to JSONB with zero per-entry validation. · t_4533c0a4 — round-20 adversarial residue: clientKey collapses IPv4-mapped IPs; 2 of 3 clients bypass the resend meter. · t_c9a11962 — verify:secrets-rotation red (Matthew's, do not touch). · t_5f908809 / t_7dd95798 / t_985a671e — human QA sign-offs for Kaitlynn, not agent work. t_985a671e carries a hazard that must reach the QA script: the Android build in ~/TacTile-dev/TacTile-android points at staging-api, which reads and writes the PRODUCTION Supabase project. There is no staging database, pitr_enabled is false, and there are zero stored backups.

TacTile › Launch TacTile › Android › Android — Destinations build

41/45 done4 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