Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›iOS›iOS — Destination editing·17 in this wave

Wave

iOS — Destination editing

Only THREE of 14 destination types actually persist an edit today — website, notes, document. Menu opens a real editor whose save is a no-op stub, so it dismisses as though it worked and silently discards the change. The remaining 10 show "Editing coming soon." Cost split matters here: gallery, video, audio and contact editors ALREADY EXIST and only need a router case wired, while payment, link hub, form, wifi, bluetooth and action must be built from scratch. Six of them also need a backend update endpoint that does not exist yet.

TacTile › Launch TacTile › iOS › iOS — Destination editing

13/17 done4 open1 open blocker

Selected taskclear

Two form decoders are silently broken by convertFromSnakeCase

DoneOwner · ait_3a26e777

fetchFormSchema silently drops 7 fields and most settings; listSubmissions throws on every form that has a submission. Both latent today.

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

**Two form decoders are silently broken by convertFromSnakeCase** · done

fetchFormSchema silently drops 7 fields and most settings; listSubmissions throws on every form that has a submission. Both latent today.

Where it sits: TacTile › Launch TacTile › iOS › iOS — Destination editing

## The brief on file

FIXED 2026-08-05 (iOS session) — PR #223, commit dae22174. Open only until that PR merges.

BOTH METHODS NOW DECODE CORRECTLY. fetchFormSchema and listSubmissions read bytes via
apiClient.request and decode with a PLAIN JSONDecoder, matching what loadFormContent
(FormActionContent.swift:141) already did.

DIRECTION CHOSEN, and why the other one would have been a bug: the task offered (a) drop
.convertFromSnakeCase for these calls or (b) delete the explicit CodingKeys. (b) is WRONG.
FormSchemaDTO / FormSettingsDTO / FormSubmissionDTO are `Codable` — the same structs are the POST and
PUT bodies, encoded through a bare JSONEncoder with no key strategy. Removing their CodingKeys would
make every form WRITE emit camelCase the API rejects, and it would fail silently rather than at
compile time. Only the read side was broken, so only the read side changed. There is now a test
asserting the encode path still emits snake_case, specifically so nobody applies (b) later.

THE FAMILY SWEEP THE TASK ASKED FOR IS DONE, AND THE ANSWER IS "NOT A FAMILY".
I enumerated all 19 response types decoded through getJSON and checked each for explicit CodingKeys.
Every other one — WifiContentResponse, ContactContentResponse, QRCodeAPIResponse, MenuContentResponse
and the rest — declares NO CodingKeys and correctly relies on the strategy. The snake_case CodingKeys
found elsewhere in System/Networking sit on Encodable REQUEST types (WifiUpdateRequest and friends),
where the bare encoder makes them correct.
So the codebase convention is sound and the form DTOs are the sole anomaly, because they are the only
types serving BOTH directions. That is the durable takeaway: the hazard is a `Codable` DTO used for
both read and write, not snake_case CodingKeys per se.

TESTS ADDED — Features/Destinations/Tests/FormSchemaDecodingTests.swift, wired into
TacTileConnectTests (4 refs in project.pbxproj):
 - every snake_case field survives the read (the seven that were being dropped, plus nested settings)
 - a submission row decodes with submitted_at (the case that used to throw)
 - the strategy decoder DEMONSTRABLY loses button_label and throws on the submission row — this pins
   the diagnosis so the two reads do not get "simplified" back onto getJSON
 - the encode path still emits snake_case

VERIFIED: full TacTileConnectTests target → 170 tests, 0 failures, ** TEST SUCCEEDED ** (166 before).

ONE THING NOT FIXED, worth its own task if anyone cares: TacTileAPIClient.requestJSON catches the
underlying DecodingError and rethrows TacTileAPIError.invalidResponse (:35-37). That is why a decode
mismatch this specific never produced a usable log line, and it will hide the next one just as well.
Left alone because it is a shared networking seam and changing what it throws touches every caller.

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

iOS — Destination editing

Two form decoders are silently broken by convertFromSnakeCase