Billing: disputes tested end to end in the sandbox #191

Part of the post-launch billing hardening (follows #139). None of it blocked launch, and all of it must be done before heavier volume.

Exercise charge.dispute.created and charge.dispute.closed (won and lost) end to end, through the real local billing Worker, with Stripe's dispute test cards (for example pm_card_createDispute). In the sandbox only.

Verify:

• the payment stop;
• dispute_owed_micros;
• the balance reversal on a loss, and the give-back on a win;
• duplicate and out-of-order delivery;
• a smaller, unrelated payment never clears a dispute stop.

Add the checks as a phase of scripts/ops/billing-sandbox.mjs, with evidence in target/billing-audit/. Fix whatever they find.

Billing safety rules (non-negotiable)

Billing has been live on Stripe since 2026-10-15 and takes real money from real customers.

• Never run fixtures, seeds or the sandbox harness against the production Stripe account. Test only with the separate Stripe sandbox key and a local billing Worker (target/billing-audit). Its .dev.vars loads automatically, and --env-file does not bind secrets. The harness is scripts/ops/billing-sandbox.mjs (phases: protocol, seed, run, cleanup, lifecycle, enterprise, complimentary). Ask the owner for the sandbox key's location.
• Never print or commit secrets. Writing Worker secrets is the owner's job: hand them the exact command, in Git Bash syntax with single quotes and forward slashes.
• Any live charge, refund or change to a Stripe object needs the owner's explicit OK for that specific action.
• Pushing to main deploys production, migrations first and then the Workers. Every migration must be safe against the code already running.
• Billing's own API requests stay pinned to Stripe API 2025-02-24.acacia. The live webhook's events are listed in services/billing/src/webhooks.rs EVENTS.
• The owner's billing audit notes (docs/audits/2026-10-14-billing.md, local and ignored by Git) hold the "LIVE" section and the remaining launch gates. Ask for them if you don't have them.

Validation for every change

cargo test -p g1t-billing --lib (and -p g1t-repos for storage); cargo check of the workspace and of the changed services for wasm32-unknown-unknown; node --test --test-isolation=none conformance/*.test.mjs; the TypeScript checks and tests for anything touching apps/ or packages/; npm run test:deploy; build the actual billing Worker before running sandbox phases; git diff --check; and inspect what is staged for secrets and artifacts. Get an independent review of money-path changes before they are pushed. Report what was verified live and what was verified only in the sandbox.

How to work on this repository

• Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
• Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
• Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
• Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
• Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
• User-facing text never names other products or compares g1t to them. Internal notes and code comments may.