[STUB-deploy] Register C0 stub as a resolvable BillingProvider — DO NOT MERGE

[seanhanca]

🚫 DO NOT MERGE — Phase-2 generalization artifact. Based on preview/phase-2-integration (the consolidated integration vehicle), not main.

Coordination

Plan PR ID:   STUB-deploy
Repo:         NaaP (livepeer/naap)
Base:         preview/phase-2-integration
Depends-on:   C0, NAAP-A (+ NAAP-A-db, NAAP-B/C/1 for the resolve path)
Blocks:       INT-G
Feature flag: NAAP_ENABLE_STUB_PROVIDER (env, default OFF); catalog enabled:false
Merge-safety: stub is catalog-disabled + adapter is in-process only ⇒ no prod
              behavior change; migrations expand-only (adapterType already added
              by NAAP-A-db); INV-1 green.

What

Stand up the C0 in-memory stub as a first-class, registered BillingProvider alongside pymthouse, so the NAAP-C front door can resolve a naap_ key against BOTH providers — proving the seam is provider-agnostic (generalization E8, enforced by INT-G).

• BillingProvider{slug:"stub", adapterType:"stub", enabled:false} added to the catalog; adapterType now persisted in all three upsert paths (web-next seed, packages/database seed, sync-plugin-registry).
• enabled:false keeps the stub out of the production provider picker; binding a team's billingAccountRef.providerSlug to "stub" is an explicit, opt-in action. The stub carries no secrets and needs no provisioning (contrast pymthouse's OIDC/M2M env).
• src/lib/billing/stub-provider-config.ts: registration/resolution helpers, NAAP_ENABLE_STUB_PROVIDER env gate (default OFF), and structured deploy-status logging (no secrets/PII).

Self-review

• The static registry (registry.ts) and the DB registry (registry-db.ts, NAAP-A-db) both resolve "stub" → StubAdapter; DB resolution falls back to static on any miss so it stays resolvable even before the catalog row is seeded.
• No live secrets — stub is in-memory only. Structured logs assert no secret-bearing keys.

Guardrail tests (added)

• catalog registers stub + pymthouse (≥2 providers);
• static + DB registries resolve "stub";
• deploy gate defaults OFF;
• structured log line contains no secret|token|password.

DoD

• Registry resolves ≥2 providers (pymthouse + stub)
• No prod behavior change (catalog-disabled, env gate OFF) — INV-1 green
• No secrets; stub in-memory only
• DO NOT MERGE (intentional)

Made with Cursor

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
naap-platform	Ready	Preview	Jun 17, 2026 9:32pm

[github-actions]

⚠️ This PR is large (250 lines changed). Consider splitting it into smaller PRs for easier review.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 1ecfce49-c6fe-41a0-a26f-20f72b538cd4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/stub-provider-deploy

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[seanhanca]

🔎 Self code-review (STUB-deploy)

Correctness

• adapterType is persisted in all three upsert paths (web-next seed, packages/database seed, sync-plugin-registry) so the catalog row and the DB-driven registry (NAAP-A-db) agree. DB resolution falls back to the static slug map on any miss, so the stub stays resolvable even before the row is seeded — no chicken-and-egg.
• Front-door resolution keys off billingAccountRef.providerSlug → adapter, which is independent of the catalog enabled flag, so enabled:false does not block a stub-backed team (intended).

Safety / invariants

• enabled:false + NAAP_ENABLE_STUB_PROVIDER default OFF ⇒ the stub never surfaces in the production provider picker and prod behavior is unchanged (INV-1).
• Stub is in-memory; no secrets, no external calls, no provisioning. Structured deploy-status log asserts it carries no secret|token|password keys.
• Migration: none new — adapterType was added expand-only by NAAP-A-db.

Risks considered

• Could the new catalog row leak into a provider dropdown? Guarded by enabled:false; if a UI ignores enabled, that's a UI bug to fix there, not here.
• Generality: this PR adds a second BPP provider without NaaP importing it directly — the registry/adapter seam is the only coupling. ✅