Billing: complimentary enrollment renewal tested on a Stripe test clock #192

Part of the post-launch billing hardening (follows #139).

Run a complimentary enrollment through renewal on a Stripe test clock, in the sandbox only, for each of these:

• (a) a waived fee;
• (b) a custom fee (send_invoice);
• (c) "charge past the allowance".

Advance the test clock across a month boundary and a renewal, and verify:

• the allowance resets, with no rollover;
• the fee invoice is paid, recorded in plan_payments as money received, with tax kept separate;
• metered usage at month end is allocated to the right month's allowance;
• charge mode bills only what's past the allowance;
• a past-due or unpaid fee ends the enrollment coherently;
• conversion to the plan still works afterwards.

Add it as a harness phase with evidence in target/billing-audit/, fix what it finds, and delete the test-clock customers when you're done.

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.