Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›Web›Web — Public destination viewer·15 in this wave

Wave

Web — Public destination viewer

CORRECTED 2026-08-05 against the code — the original goal was flatly false and is preserved at the end for provenance. CURRENT STATE: apps/web/app/t/[hash]/route.ts dispatches ALL 14 canonical destination types. Coverage is mechanically gated in CI by check (b) of tests/unit/destination-type-parity.test.ts, which derives the type set from the Postgres enum on disk and fails if any type lacks a branch. The misleading contact-card fallback is gone: the contact path is guarded by `if (destType === "contact")` and the terminal branch returns unsupportedDestinationHtml() with a 404 for any unrecognized type. Nobody should re-implement a viewer. WHAT REMAINED, and its status after the feature/web session (2026-08-05): · DONE — deleted ~109 lines of unreachable code: handleVideoDestination and handleAudioDestination were shadowed by the 302 redirects to /v/[hash] and /a/[hash] that fire earlier in the dispatch, so neither function nor its orphan branch could ever run. · DONE — fixed a silent environment bug: every apps/web viewer route reads NEXT_PUBLIC_API_ORIGIN, but staging config set NEXT_PUBLIC_API_URL (apps/web-mobile's name) in THREE places — wrangler.jsonc, .env.staging.example and package.json's dev:staging. Nothing read it, so the STAGING viewer silently served PRODUCTION data. All three renamed. · DONE — wifi/bluetooth brought to iOS viewer parity per Matthew's 2026-08-05 call: per-credential copy buttons, password/PIN masked behind a reveal toggle (copy works while masked), monospaced values. Matches apps/ios .../Viewers/WifiViewer.swift + BluetoothViewer.swift. · HANDED TO BACKEND — https://staging.tactile.to is missing from STATIC_ALLOWED_ORIGINS in apps/api/tactile-api/src/utils/cors.ts, so the form's submit preflight gets a 403 from staging. Tracked as t_a615a44c in wave w_bbbef29e. · STILL OPEN — a real form submission has never been proven to store a row. Split out as t_557d52d9 (blocked on t_a615a44c). It is the only acceptance criterion in this wave never verified by anything but `tsc --noEmit`. VERIFIED-FALSE ORIGINAL GOAL (kept so nobody re-derives it): "app/t/[hash]/route.ts handles only 5 of 14 types. A customer scanning a live website, gallery, payment, video, audio, wifi, bluetooth, form, or link-hub tag hits a contact-card fallback that reads as 'this card link is no longer active.' The product silently fails for 9 of 14 types." — false as of commit b184285f.

TacTile › Launch TacTile › Web › Web — Public destination viewer

13/15 done2 open1 open blocker

Selected taskclear

Prove a form submit end-to-end against a live API

To doOwner · ait_557d52d9

The only acceptance criterion in this wave never verified by anything but tsc --noEmit. Blocked on the API CORS allowlist entry (t_a615a44c).

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

**Prove a form submit end-to-end against a live API** · to do

The only acceptance criterion in this wave never verified by anything but tsc --noEmit. Blocked on the API CORS allowlist entry (t_a615a44c).

Where it sits: TacTile › Launch TacTile › Web › Web — Public destination viewer

## The brief on file

BLOCKED ON SIGN-IN CREDENTIALS. Everything else this task needed is now done — see below, and pick it up from step 3.

PROGRESS 2026-08-06:
· CORS is no longer the blocker. t_a615a44c landed on main; verified live — an OPTIONS preflight to https://staging-api.tactile.to/api/form/<hash>/submit with Origin: https://staging.tactile.to returns 204, not the 403 that made this untestable.
· Branch rebased onto main and web DEPLOYED to staging (commit 57aa4858). The staging worker's bindings now show NEXT_PUBLIC_API_ORIGIN = https://staging-api.tactile.to, so staging web finally talks to the staging API rather than production.
· Along the way this uncovered and fixed a live PRODUCTION OUTAGE — sign-in and sign-up were dead on tactile.to. Tracked as t_657e1246. Staging is fixed and verified; production still needs the merge + deploy.

WHAT IS STILL BLOCKING: creating the throwaway form destination needs an authenticated session, and this session cannot get one.
· The 1Password credential flow returns {"status":"invalid","reason":"schema"} — not one of the documented failure modes (transport_error / not_connected / disabled_by_policy), so it was not retried in a loop.
· Reading auth.users to pick an owner_account_id was correctly refused as PII, and was not worked around.
· Creating the destination by raw SQL was rejected as an approach: destinations.owner_account_id is NOT NULL, and every id available without querying user data belongs to a real account. Attaching a test row to a customer is not acceptable.

SO THE ONE MISSING INPUT is an account to own the throwaway. Either sign in as Matthew in the browser, or have him supply his own account UUID.

STEPS FROM HERE (staging is already deployed and pointed correctly):
1. Sign in at https://staging.tactile.to/signin — VERIFIED WORKING as of 57aa4858.
2. Assets → Destinations → "Create destination" → Forms. This exercises the new desktop FormBuilder too, which is a bonus over creating via API.
3. Open https://staging.tactile.to/t/<hash>, fill the form, submit.
4. Confirm the row actually landed:
     select id, destination_hash, data, submitted_at from public.form_submissions where destination_hash = '<hash>';
   Schema confirmed: form_submissions is keyed by destination_hash (text), with data jsonb, submitted_at, respondent_ip, is_read. A 201 with nothing persisted is exactly the failure this task exists to rule out, so check the table, not the success message.
5. Confirm after_submit behaviour — success_message inline, or redirect_url followed.
6. Delete the throwaway BY EXACT HASH, from form_submissions, form_destinations and destinations. Never a filtered or bulk delete.

HAZARD, unchanged: there is no staging database. staging-api writes land in PRODUCTION, and prod has NO backups (pitr_enabled false, backups [], free plan). Related: t_a2ccb527.

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

Web — Public destination viewer

Prove a form submit end-to-end against a live API