[Feature] Team & billing in openhuman binary (RPC/CLI: plans, top-ups, payment links, members)

[senamakel]

Summary

Expose team management and payments / subscriptions through the openhuman core binary (JSON-RPC and/or CLI), so operators and automations can create payment links, run top-ups, inspect current plans and usage, and add or remove team members—without depending solely on the desktop app or raw HTTP calls to the hosted API.

Problem

Today, billing and team flows are largely UI- and app-layer concerns (e.g. React + apiClient / REST). That makes it harder to:

• Script provisioning, invoicing, or member changes from CI, admin tooling, or support playbooks.
• Dogfood the same contracts the app uses from the sidecar in a single, versioned surface (openhuman.* RPC).
• Integrate with headless or server-adjacent setups where the Tauri shell is not in the loop.

We want parity with product capabilities (within policy) on a stable RPC boundary aligned with existing controller/registry patterns.

Solution (optional)

Design-first; implementation can span multiple PRs.

Suggested scope

1. Payments & plans

   • List / describe current plan (and relevant limits or entitlements as returned by the backend).
   • Top-up or purchase flows that the backend already supports (expose parameters that match existing REST or GraphQL—do not invent parallel billing logic in Rust).
   • Payment links (create/list/revoke as applicable) with clear idempotency and error semantics over RPC.

2. Team

   • List members, invite (if API supports), remove or change role (as API allows).
   • Respect auth (session / API key) and tenant boundaries exactly as the hosted API enforces.

Implementation notes

• Prefer thin Rust adapters: validate params, call existing HTTP client modules or a small dedicated openhuman::billing / openhuman::team domain that wraps the same base URL + auth as the app.
• Register controllers + schemas per the migration checklist (src/openhuman/<domain>/schemas.rs, wire src/core/all.rs, tests + JSON-RPC E2E where applicable).
• No secrets in logs; redact tokens and PII.

Non-goals (unless explicitly expanded)

• Replacing the hosted billing provider or duplicating pricing rules in the binary.
• Full Stripe dashboard parity inside the CLI.

Acceptance criteria

• Design doc — RPC method names (openhuman.<namespace>_<function>), params, outcomes, and mapping to existing backend routes; auth requirements stated.
• Core implementation — At least one end-to-end path each for plan/summary, top-up or payment-link creation, and team member list + add/remove (or invite), matching backend reality.
• JSON-RPC / CLI — Methods reachable via the same envelope as other openhuman controllers; CLI mirrors if the project standard includes it.
• Tests — Unit tests for parsing and error mapping; integration tests against mock backend (or recorded fixtures) where feasible.
• Security review — Confirm no new bypass of server-side authorization; document who may call these methods in production.

Related

• App references: app/src/services/api/ (e.g. billing, team, credits) and settings panels for Billing / Team—use as the contract source of truth for HTTP shape.
• Architecture: docs/ARCHITECTURE.md, controller registry / RpcOutcome patterns in AGENTS.md.
• Follow-up: UI could later thin-wrap the same RPC for consistency (optional).