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

form.ts: refuse an empty/degenerate fields array on update (route guard)

DoneOwner · backendt_a75572de

Unlocks 1Destination editing: wire Form builder into edit mode

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

**form.ts: refuse an empty/degenerate fields array on update (route guard)** · done

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

## Unlocks 1

- Destination editing: wire Form builder into edit mode

## The brief on file

BACKEND SESSION — apps/api carve-out of w_51581e7d. Filed by the Android session 2026-08-06; Android owns apps/android only and must not edit apps/api.

THE BUG: `PUT /api/form/{hash}` accepts `fields: []` and deletes every question on the form, returning 200 OK. The whole validation surface is one line — `if (Array.isArray(payload.fields)) formUpdates.fields = payload.fields;` (apps/api/tactile-api/src/routes/form.ts:300, verified 2026-08-06). There is no non-empty check, no per-entry validation, and no "did the caller mean this" gate.

It is the ONLY one of the three collection-bearing destination routes with no protection at all:
- menu.ts:483-490 refuses `sections: []` outright with "to remove every section, delete the destination instead."
- contact.ts:767-772 400s when `fields` contained no usable entries.
- form.ts — nothing.

Against a database with pitr_enabled=false and ZERO stored backups, a client bug that sends `fields: []` once destroys every question on that form permanently. There is no undo and nothing to restore from.

THE FIX: mirror menu's shape. Refuse an empty array with a message that names the alternative, e.g. "fields must be a non-empty array — to remove every question, delete the destination instead." Decide deliberately whether a MALFORMED array (entries missing `id`/`type`/`label`) should also 400 rather than being stored verbatim as JSONB — today `fields` is written with zero per-entry validation, which is a smaller but related hole.

TEST TEMPLATE: apps/api/tactile-api/tests/routes/destructive-replace-ordering.test.ts. Hold it to that file's standard — restore the pre-fix handler and PROVE the new test fails against it. A guard test that passes on both the broken and fixed code is worse than none.

WHY IT IS BLOCKING RATHER THAN NICE-TO-HAVE: Android's form editor is copy-only precisely because of this. FormUpdateRequest (apps/android/.../data/model/destination/DestinationEditModels.kt) has no `fields` key at all, so the client is structurally incapable of sending one — that is the current mitigation and it is client-side only. A question editor cannot be built on any surface until this guard lands, because the client should not be the last thing standing between a user and an empty form. iOS and web will hit the same wall.

Related and separate: t_ff155928 (contact.ts parseFieldsInput silently drops unreadable entries). Same class of bug, different route, already filed.

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

form.ts: refuse an empty/degenerate fields array on update (route guard)