Mindbridge · track status

BILLING

The money path — signup cannot complete, or usage is not metered against what a contract promises.

Re-measured 2026-08-16 from gh issue list. Verify before starting — this page has never been published, and its prose decays as the track moves.

Next → #2768 Web Google signup can never complete — the OAuth full-page redirect destroys the form state. A user who cannot finish signup is lost before revenue exists.

2 open · both p1 — web Google signup can never complete · enterprise AMA usage metered by nothing.

2open issues

6,000/mocontract pool

$0.30/qoverage rate

32grandfathered tenants

Open work Why this order Standing rulings Census

Open work

Signup completion — launch-blocking

p1 #2768 Web Google signup can never complete — the OAuth full-page redirect destroys the form state web signup dies before submit Mizo

On web, signInWithGoogle redirects the whole page, so the in-memory signup form state (googleProfile, slug, display name) is destroyed before it can be submitted — submitGoogle is unreachable, and the user lands back at / with a valid session and no tenant_id. The signup screen hides behind the session guard, so the only exit is to sign out — recoverable only by a user who guesses that. The Google button is offered on web despite not working.

Enterprise metering — count-but-do-not-enforce

p1 #2915 Meter enterprise AMA questions for billing — Regina's contract has a 6,000/month fair-use pool with $0.30/question overage that nothing counts contract usage metered by nothing Enterprise

Regina's contract commits to a 6,000-question/month fair-use pool billed at $0.30/question overage, but ama_usage holds 0 rows for Regina — check_ama_quota bypasses enterprise before any meter write, and the metering flag is also off. Overage cannot be billed and consumption cannot be evidenced. The fix must be count-but-do-not-enforce, never a hard cap: deleting the enterprise bypass alone would start blocking Regina at the pool ceiling, which the contract does not permit — the allowance is a fair-use billing term (“billed monthly in arrears”), not a limit.

Why is it in this order?

Complete signup before metering. A user who cannot finish signup never becomes a customer at all — no tenant, no revenue. Regina's meter, by contrast, carries the owner's own runway (“needed in ~1 month”, 2026-08-01). So the signup issue is picked up first, the metering issue second.

What this criterion deliberately does not use: issue age (the signup issue is the older of the two, filed 2026-07-26 — age reorders nothing); track provenance (the index names the native metering issue first and marks the signup issue as moved here from the untracked pile — provenance does not set urgency); the severity label alone (both carry priority:p1, so the label cannot break the tie); estimated effort (neither issue body sizes its fix).

Standing rulings

None. The decided list for track:billing in track-order.json is empty, so nothing on this track is pre-settled. A question that needs an owner ruling should be raised on the needs:ruling label rather than assumed answered.

Census — the rail and its tenants

The billing rail has been live on production since 2026-08-05. All 32 pre-cutover tenants are sealed grandfathered — free indefinitely with every cap NULL, so gates fail open. The two issues above are the track's entire open backlog: one signup blocker, one metering gap.