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.

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

1open 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).

What the audit found — generated

Evidence below is generated from the read-only audit of 2026-08-29 and reconciled against the open issues at build time. Every claim cites the issue it came from. Nothing here is a decision — rulings stay in the prose above, which is written by hand.

#2915 Meter enterprise AMA questions for billing — Regina's contract has a 6,000/month fair-use…prodhigh confidence

Prod (Supabase execute_sql, 2026-08-29): `select count(*) from public.ama_usage` → 0 rows total, 0 for Regina (e9d96b09-4e76-4bd6-b136-e36515d79695, deployment_mode='enterprise'), while `ama_turns` holds 165 Regina rows — questions ARE being asked and none are metered. Code on origin/main: `backend/app/api/ama_quota_gate.py::check_ama_quota` still returns None for ENTERPRISE before `quota_svc.record_question` is ever called (the enterprise-bypass branch is intact, immediately after the flag check). `backend/app/services/billing/ama_quota.py::_resolve_caps` still conflates unlimited with unmetered — it returns None when both caps are None and the caller then skips the DB write entirely, exactly as the issue describes. No count-but-do-not-enforce mode exists.

Open questions — what the audit could not settle

#2915 One premise in the issue body is STALE and must not be carried forward: the issue asserts "two independent reasons — AMA_METERING_ENABLED=False and the enterprise bypass". The 2026-08-05 billing cutover flipped AMA_METERING_ENABLED to True in the running fleet, and no NULL-plan rows remain; what keeps ama_usage at 0 for Mizo tenants now is the grandfathered plan (all caps NULL → _resolve_caps returns None → no write), and for Regina specifically the enterprise bypass alone. The conclusion (nothing counts Regina) is unchanged. I did not independently read the running fleet's env — the config lane failed. Closing command: `fly ssh console --machine <mawja-api worker> -C 'printenv AMA_METERING_ENABLED'`.

1 assessed issue closed since the audit and are not shown — a closed issue's evidence is history, and printing it as current is how a page starts lying.

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.