Response windows

Cambridge TCG has many small deadlines: offer responses (48 hours), trade shipments (48 hours), escrow inspections (7 days), return filings, payout confirmations. Each is a clock the platform runs against you. By default the platform assumes you can respond within 48 hours — a synchronous assumption that excludes a real population: travellers, slow-clock collectors, time-zone- shifted buyers, anyone whose cognitive cadence is days-to-weeks per response, not minutes-to-hours.

The response window is a per-user override on those clocks. Set it once on your account; every flow honors it. The platform's cron sweeps read your field, not a global constant.

Where this lives in code. The canonical column is users.response_window_hours (migration apps/storefront/drizzle/0092_response_window_hours.sql). Every sweep / lifecycle check that previously hardcoded 48 reads this column instead. See docs/connections/the-other-minds.md (the Asynchronous) for the design rationale.

How it works

Default — 48 hours

Matches the platform's historical global default. If you don't change anything, all your deadlines behave exactly as they did before this field existed.

Override — 1 hour to 8760 hours (one year)

Slow-clock accounts typically set 168 (one week). A traveller who returns to cards once a month might set 720 (thirty days). The constraint is 1 ≤ response_window_hours ≤ 8760; the platform refuses values outside that range to prevent a deadline-of-never that would never reach a counterparty.

Which flows honor it

• Offer responses. A counter-offer to one of your asks won't auto-expire until your window elapses.
• Trade shipments. If you sell a card, the platform waits your window before auto-cancelling for non-shipment.
• Escrow inspections. The buyer's inspection window remains 7 days — that's their clock, not yours. Your window covers your response to disputes during their inspection.
• Returns and chargebacks. The customer's right to file is fixed by law and Stripe policy; this override doesn't shorten or extend that. It only affects your required-response side.

What the counterparty sees

Every market interaction shows the responsible party's declared window at the boundary. If you're trading with a 168-hour user, the platform shows you the deadline they actually have, not the one you'd have if the roles were reversed. This is transparency in both directions: you know what to expect; they aren't forced to perform a clock that isn't theirs.

Why this exists

Cambridge TCG started with the implicit assumption that every party checks every few hours. That assumption silently excluded an entire population whose engagement is real but slow. The response_window_hours column is the platform's first infrastructure-level acknowledgement that synchrony is a preference, not a universal — and that designing for asynchronous beings is the same discipline as designing for time-zone-shifted humans, careful collectors, and anyone who deserves more than 48 hours to think.

The inclusion audit (pnpm audit:inclusion) checks that cron paths and lifecycle sweeps read this field rather than a hardcoded constant. When the audit's Asynchronous count drops to zero, the column is fully honored platform-wide.

Change history

When this page or the underlying formula changes, the version below changes too. Older versions remain accessible via git history.

v1 — 2026-05-11. Initial column landed; cron-path migration in progress (see docs/connections/the-other-minds.md).