Decision (ratified 2026-07-21): the flow is verify-then-trigger, not verify-then-instructions. Customer completes the existing GitHub-install-admin OAuth verification (src/auth/github-oauth.ts), and that success immediately calls #7180's provisioning API (via #7654's POST /v1/tenants) to kick off provisioning asynchronously — no manual credential-pasting step, no "go start your own container" instructions.
Real gap found, not just caution: #7180's provisioning API is explicitly scoped "internal/admin-only" in its own Boundaries — it isn't built to be safely triggered directly by an unauthenticated-until-now customer action. Before this flow can call it, it needs:
- Idempotency: the same customer completing verification twice (double-click, retry, back button) must not create two tenants.
- One-tenant-per-customer-per-product gate: check whether this customer already has an active tenant for this product before calling provisioning; if so, route them to their existing instance's status instead of creating another.
v1 does not need a full quota/plan system (#4920, separate) — just these two guards, which are the minimum bar for "a customer's own clicking can't create unbounded real infrastructure."
Problem: Today's self-enrollment flow verifies GitHub-install-admin identity and hands back credentials with instructions to paste into a container the operator manually restarts.
Area: ORB / Onboarding.
Deliverables:
Resources
maintainer-only — this is the trigger point for real, billable infrastructure creation from a customer-initiated action; the idempotency/one-tenant gate needs to actually hold, not be assumed correct on a first pass.
Decision (ratified 2026-07-21): the flow is verify-then-trigger, not verify-then-instructions. Customer completes the existing GitHub-install-admin OAuth verification (
src/auth/github-oauth.ts), and that success immediately calls #7180's provisioning API (via #7654'sPOST /v1/tenants) to kick off provisioning asynchronously — no manual credential-pasting step, no "go start your own container" instructions.Real gap found, not just caution: #7180's provisioning API is explicitly scoped "internal/admin-only" in its own Boundaries — it isn't built to be safely triggered directly by an unauthenticated-until-now customer action. Before this flow can call it, it needs:
v1 does not need a full quota/plan system (#4920, separate) — just these two guards, which are the minimum bar for "a customer's own clicking can't create unbounded real infrastructure."
Problem: Today's self-enrollment flow verifies GitHub-install-admin identity and hands back credentials with instructions to paste into a container the operator manually restarts.
Area: ORB / Onboarding.
Deliverables:
Resources
src/auth/github-oauth.ts(the existing verification this reuses)maintainer-only — this is the trigger point for real, billable infrastructure creation from a customer-initiated action; the idempotency/one-tenant gate needs to actually hold, not be assumed correct on a first pass.