fix(cards): refuse a stale card order and recover a committed card whose reply was lost (follow-up to #882)

[NewWorldVenture]

Follow-up to repair B: an expected-count contract and recovery of a committed-but-unacknowledged card mirror (JIMMY-SUPPORT-CARD-RETRY-20261001). It answers the owner's independent review of #882 (5970508018).

Draft. Do not merge without coordination. Stacked on #882: base claude/card-attempt-identity-7q6vtf at 208c7e201. Claim: #811 5969137460. The actions.ts scope is issueCardAction only.

What #882 left open

1. A stale tab. So does a retry after a lost success answer. Once the first card is mirrored, the count moves, so an identical order from a view that never refreshed is a new attempt and gets a second card.
2. A mirror insert that committed but whose reply was lost. The parent was told "could not issue" for a live, mirrored card, and the card got no card_issued audit.

The change

• Expected-count contract.
  • View (components/wallet/money-cards-view.tsx): every order (Virtual, issue-all, the physical dialog) sends expectedCount, the number of that child's cards of that type it shows, in every status.
  • Action: issueCardAction refuses an expectedCount that isn't a non-negative safe integer, before any read, Trust check or provider call.
  • Library: issueCard throws StaleCardOrderError before any provider call when the mirrored count differs, in either direction.
  • Answer: the action returns { ok: false, error: t('wallet.refreshToTryAgain'), stale: true }. That's an existing key, so no i18n file is touched.
  • Refresh: the view, and the dialog via onStale, re-read on the stale flag, not on the words.
  • Overlapping orders made against the same count still share fix(cards): one card order gives one card across tabs — attempt identity (repair B) #882's attempt key.
• Read-back recovery in issueCard. After any mirror insert error, it reads the card back by stripe_card_id and adopts exactly this attempt's row:
  • After 23505, another request of this attempt inserted the row and audits it, so this request adopts it with no second audit.
  • After any other error, this insert committed with only its reply lost. The row is this order's own card: it's answered ok and audited here.
  • A failed or rejected read-back, or no row, keeps the refusal and names the card.

Results (synthetic provider; in-memory UNIQUE)

Case	#882	Now
Stale identical order after the first card is mirrored (gaps 0/1/60,000 ms)	2 live cards	refused as stale: 1 card, 1 row, 1 audit
The action's answer lost after mirror and audit, then a retry from the same view	2 cards	refused as stale: 1 card, 1 row, 1 audit
Insert committed and its reply lost (08006)	"could not issue", 0 audits	answered ok with that card, 1 audit; a retry is refused as stale
Deliberate order from an up-to-date view	new card	new card (unchanged)
Two orders overlapping against the same count	1 card	1 card (unchanged)

Tests

• tests/money-card-stale-order.test.ts, 32 cases. Against fix(cards): one card order gives one card across tabs — attempt identity (repair B) #882's issuing.ts and actions.ts, 24 fail; the 8 controls pass on both: overlap, count-read failures and a deliberate order.
  • The stale and lost-reply cases were committed failing first (eac32892e, 87a132998).
  • A committed-then-lost reply is simulated with a real committed row followed by a 08006 answer.
• tests/money-card-attempt-identity.test.ts. fix(cards): one card order gives one card across tabs — attempt identity (repair B) #882's "does not re-read after a non-duplicate insert failure" is deliberately replaced by four groups:
  • read-back recovers when the exact row is there (ok, 1 audit);
  • refusal when no row is found (card named in the log);
  • refusal when the read-back errors or rejects.
• Other suites. The characterization, money-treasury-card-actions and money-card-trust-bridge tests now send expectedCount. Every count stays exact.
• Browser (tests/e2e/money-cards-cross-tab.spec.ts, 10 cases):
  • a stale second tab ordering through each entry point is refused, shows the answer, re-reads, and its next order carries the new count;
  • the view re-reads on the stale flag even when the text is localized, and not on a plain refusal that only reads like it;
  • each order sends that child's per-type count, in every status.
  • The other card view specs only add expectedCount to recorded inputs.

Mutants: 13/13 killed. They cover:

• the guard removed, or one-directional;
• validation removed;
• the stale mapping made generic, or its flag dropped;
• read-back only on 23505;
• a recovered row reported as adopted (no audit), and an adopted row reported as own (double audit);
• the view sending the total, or a family-wide, count;
• the view or dialog not refreshing on stale, or refreshing on the words instead of the flag.

Validation on bd8543692:

• tsc, npm run lint and i18n:gate are clean.
• Every card browser spec passes, 92/92.
• Full vitest: 1832 files passed (1 skipped); 24,266 tests passed, plus 2 expected failures and 72 skipped.
• test(wallet): second-pass browser regression for card reveal, freeze and controls #772's second-pass spec, run against this view: 18/18.

Independent review of bd8543692 (read-only)

• No blocking correctness bug. The reviewer also confirmed:
  • the page loads every card, unfiltered under family RLS, so the view's count equals the server's;
  • the read-back can only adopt this provider card's row;
  • all four placeholder locales fall back to a real translation.
• Mutants: 19 of its 20 were killed. The survivor is equivalent: issue-all only orders for children with no cards, so both counts are 0.
• Fixed in 1494abb04:
  • (medium) the physical dialog stayed open after a stale refusal, one click from a second card ordered against the new count. It now closes and the view re-reads.
  • Stale refusals are now logged at warn level, with ids and counts only.
  • The docstring is corrected: a first order may already have created the cardholder before a stale refusal.
• New mutants on these fixes: 2/2 killed, 15 in all for this PR.
• Checks after the fixes: related suites 205/205, card browser specs 92/92, tsc and lint clean.

Residuals (stated, not fixed)

1. Orphans after the key is pruned. A card is created but never mirrored (the insert didn't commit), so the count doesn't move. After Stripe prunes the key (at least 24h), an order made against that count issues a second card and the orphan stays live and unlisted. Compensating orphans is repair E, which isn't implemented.
2. Intentional overlapping orders collapse to one (deliberate).
   • Within a tab, A serializes them.
   • Across tabs, two up-to-date views ordering the same type at once can't be told from a duplicate, so they get one card. The second view is answered with it and shows the true count after its refresh.
3. A rare double audit. A non-23505 insert failure that did not commit, while a concurrent request of the same attempt did, makes both requests audit.
   • A reply lost before the commit is not recovered. The insert commits after the read-back has found nothing, so the parent is told "could not issue" and no audit is written. The retry is refused as stale and refreshes, so no duplicate card results.
   • A quick second click is refused as stale. It happens when the second Virtual click lands before the first order's refresh, and the next click works.
   • A failed cards read on the page makes every order for a child with cards stale until the read recovers. This fails safe.
   • PostgREST row cap (unverified). A family with more than 1000 card rows could undercount under PostgREST's default max_rows.
4. A stale view must refresh first. A parent whose view is stale but who wants another card refreshes first; the answer does this for them.
5. Carried over from fix(cards): one card order gives one card across tabs — attempt identity (repair B) #882: saved provider failures (owner decision), the refusal wording for an in-flight conflict, and read-replica routing.

Not covered: live Stripe, RLS, a served browser → server → provider workflow, or production. No schema, migration, credential or provider change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DXw2nu25BjyRfA6Fg3YiMS

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
bubaly	Ignored		Oct 3, 2026 4:29pm UTC

[NewWorldVenture]

Closing again at the owner's direction to close the 85-PR backlog: this PR was in the sweep at 15:52 UTC and was reopened at 16:13 UTC. The branch is kept; nothing is merged or deleted. Please do not reopen without the owner's say-so.

---

Generated by Claude Code