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

Video quota prune deletes R2 media before the DB rows, and both callers swallow the failure

DoneOwner · Vivt_c80e7372Blocker

When someone with many video destinations uploads another, the app deletes old ones — and if that half-fails it leaves live destinations whose video files are gone, with no error reported anywhere.

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

**Video quota prune deletes R2 media before the DB rows, and both callers swallow the failure** · done · blocker

When someone with many video destinations uploads another, the app deletes old ones — and if that half-fails it leaves live destinations whose video files are gone, with no error reported anywhere.

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

## The brief on file

DONE, MERGED AND DEPLOYED 2026-08-03. PR #193 merged as a682739a; tactile-api version 2886b315 live on api.tactile.to. Verified on main by content.

THE LAST KNOWN INSTANCE of the destroys-before-it-is-safe class, and the only one that had already fired — videos.ts:187 records it destroying 13OJU6GI3 on 2026-08-01, which survived only because the delete hit the staging bucket while the objects live in prod.

FIXED: pruneVideoActionsForOwner now deletes the destinations rows FIRST, then the R2 objects.
  row delete fails    -> nothing removed at all; destinations still work and still hold their media
  object delete fails -> rows already gone, so leftovers are unreferenced bytes — storage to reclaim, not a broken destination
Nothing forced the old order: every key was already read into `rows` by the lookup above. That is what separates it from destinations.ts's delete path, which genuinely must go R2-first and documents that plus writes an audit row.

THE TWO SWALLOWING CALL SITES ARE ANNOTATED, NOT CHANGED, and the reasoning matters for whoever revisits this: with rows deleted first, a failed prune destroys nothing, so continuing hides nothing — the upload proceeds to its own quota check and the retry prune gets a second attempt. Before the reorder those same catch blocks hid a half-completed destruction behind a 200, which is what made them a bug rather than a style choice. verify:destructive-order requires a reason on the annotation and refuses a bare one.

BASELINE RATCHETED 4 -> 1. Only triggers.ts::deleteTrigger remains (t_926c8a5f).

TESTS: 2, validated against the old ordering — restore it and both fail while it still typechecks. Full suite 462/462. pruneVideoActionsForOwner is now exported for tests; it is only reachable through a multipart upload by an owner already at quota, which is too much setup to drive from a route test and too important to leave uncovered.

TWO MOCK BUGS WORTH REMEMBERING, because each produced a passing-looking test that exercised nothing:
  - a null body on the count probe, which threw before the ordering was reached
  - `url.includes("count")` — which matches `owner_account_id`, present in EVERY url — so the row fetch was answered with the count response and the prune quietly found nothing to delete

DEPLOY NOTE: shell state does NOT persist between tool calls, so `export CLOUDFLARE_API_TOKEN=...` and `npx wrangler deploy` must be in the SAME command or the deploy fails with a misleading "You don't have 'containers:write'" — which reads like a token-scope problem and is not one.

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

Video quota prune deletes R2 media before the DB rows, and both callers swallow the failure