Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Inbox — on deck·56 in this wave

Wave

Inbox — on deck

Briefs Nova has teed up and are ready to run — each task's prompt is a complete, self-contained brief.

TacTile › Inbox — on deck

44/56 done12 open2 open blockers

Selected taskclear

web-mobile: send return_origin on checkout and the portal, or buyers still land on tactile.to (follow-up to t_4fefd007)

To doOwner · ait_c8a48aa8

The API half of t_4fefd007 is PR #703 (draft): POST /api/billing/checkout and /portal accept an optional return_origin and honour it only if it exactly equals an origin in utils/cors.ts. No client sends it, so merging #703 changes nothing for a real buyer. This task is the client half and is what actually fixes the user-visible defect. Keep t_4fefd007 open until this ships.

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

**web-mobile: send return_origin on checkout and the portal, or buyers still land on tactile.to (follow-up to t_4fefd007)** · to do

The API half of t_4fefd007 is PR #703 (draft): POST /api/billing/checkout and /portal accept an optional return_origin and honour it only if it exactly equals an origin in utils/cors.ts. No client sends it, so merging #703 changes nothing for a real buyer. This task is the client half and is what actually fixes the user-visible defect. Keep t_4fefd007 open until this ships.

Where it sits: TacTile › Inbox — on deck

## The brief on file

[2026-10-09 · Viv] PREPARED (not done) on draft PR https://github.com/TacTile-dev/TacTile/pull/747: Kept OPEN on purpose. WHAT I DID: checkout half, commit dbb7fdce on r30/web-r3 (not pushed). WHERE I STOPPED: apps/web-mobile/app/settings/subscription/page.tsx:127 (portal fetch headers) is untouched because open PR #649 (fix/qa-web-20260921) edits that file. WHY: avoid a rebase collision on a 51-file PR. WHAT IS MISSING AND WHO SUPPLIES IT: (a) the page.tsx edit, any agent after #649 merges or is rebased; (b) PR #703 (API half) merged and deployed, Matthew's call, because the client change is inert until then (an API that predates #703 ignores the field); (c) the staging check from the task (start a checkout on staging-app.tactile-connect.com and confirm the Stripe session success_url host) needs both deployed. HUB NOTE TO PREPEND (stamp from `date +%F`): [2026-10-09 · Viv] Checkout half

[2 Oct 2026 overnight — Viv: draft PR #703 https://github.com/TacTile-dev/TacTile/pull/703 — api: checkout and the billing portal can return a buyer to the origin they started on (inert until the client sends the field) (the client half, split out as its own task; not done here); not merged, not deployed]

Context: PR #703 (r28/checkout-return-origin) adds an optional `return_origin` to POST /api/billing/checkout and POST /api/billing/portal. It is honoured only when it is, byte for byte, one of the origins in apps/api/tactile-api/src/utils/cors.ts (STATIC_ALLOWED_ORIGINS); anything else falls back to the old default and is never an error. No client sends it yet, so a buyer who pays on app.tactile-connect.com is still sent to tactile.to, where they have no session. That is the defect t_4fefd007 describes, and it is NOT fixed until this task ships.

Do, in apps/web-mobile only (use the feature/web-mobile worktree, ~/TacTile-dev/TacTile-web-mobile, branched from main):
1. apps/web-mobile/features/billing/lib/checkout.ts (~line 62-70): change the checkout body from JSON.stringify({ tier, interval }) to JSON.stringify({ tier, interval, return_origin: window.location.origin }). The function is client-side, so window is available; guard with typeof window if it can run during SSR.
2. apps/web-mobile/app/settings/subscription/page.tsx (~line 125, handleManageBilling): the portal fetch sends no body and no Content-Type. Add headers Content-Type: application/json and body JSON.stringify({ return_origin: window.location.origin }). The API reads the body whatever the Content-Type, but send it honestly.
3. Tests: a unit test next to each (or extend the existing ones) asserting the request body carries return_origin equal to window.location.origin, and that an unset/undefined window does not throw.
4. Do NOT add an SDK type: packages/sdk-js has no checkout or portal type and every caller uses fetch directly.

Order does not matter. An API that predates #703 ignores the field (checkout reads only tier and interval; portal read no body), so client and API can deploy in either order. But the buyer is only fixed once BOTH are deployed: #703 merged AND deployed to the API Worker, and this change deployed to web-mobile.

Conflict warning: PR #649 also edits apps/web-mobile/app/settings/subscription/page.tsx. Rebase onto whichever lands first.

Staging: staging-app.tactile-connect.com is on the allowlist, so a staging web-mobile build returns to itself. Verify there before prod: start a checkout, confirm the Stripe session's success_url host is staging-app.tactile-connect.com.

Do not touch apps/web (tactile.to): its default return origin is already correct.

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

Inbox — on deck

web-mobile: send return_origin on checkout and the portal, or buyers still land on tactile.to (follow-up to t_4fefd007)