Design spec: APR repo creation under the submitting customer's own GitHub account (twice-corrected)

[JSONbored]

Problem

For an auto-provisioned repo (APR), no decision exists on where the repo actually lives or who owns it. This is foundational — the maintainer-authority question, the billing model, and the ToS/liability language (#4805) all depend on it.

Area

Product spec / platform architecture.

Proposal

Researched the actual GitHub mechanics rather than assuming: a GitHub App (which loopover already operates, per #4802's install flow) can create repositories directly under an organization it's installed on, using its installation token — no per-customer consent beyond the org install. It cannot create a repository directly in a customer's personal account; that specifically requires OAuth (repo scope) or a PAT tied to that user, which is itself a GitHub-facing consent step and cuts against "the user never touches GitHub."

Recommend: APR repos default to a loopover-controlled GitHub org, created via the existing App installation token — zero new GitHub interaction from the idea-submitter, matching the actual ask. Offer an explicit, optional transfer-to-your-own-account flow later using GitHub's standard repository transfer mechanism (a real, well-supported API — the new owner gets a confirmation email and accepts within a set window). This is the same shape Lovable already ships in production: managed hosting by default, most customers stay there, GitHub sync/export available any time as a "clean exit" for whoever wants direct ownership. Not inventing a new pattern — following a proven one.

This also simplifies the maintainer-authority question from #4782: since loopover's own GitHub App is the repo's installer/owner by construction under this model, ORB doesn't need a special "no human maintainer" governance carve-out — it's already the same authority model loopover uses for repos it operates directly. The customer's consent lives in the ToS at idea-submission time, not in a per-repo autonomy grant.

Deliverables

• A written decision: default hosting org/account, and the transfer-to-customer flow's trigger conditions (on request, automatic at some milestone, etc.).
• Confirmation of what "ownership" means practically before transfer — can the customer already see/read the repo, or only through loopover's own dashboard until they choose to take it?

Resources

• Self-serve signup & App-install flow #4802 (existing GitHub App install flow, BYOR path)
• Third-party autonomy & security governance spec #4782 (autonomy/governance spec — this narrows its scope for APR specifically)
• Terms of Service & liability terms #4805 (ToS — ownership-by-default and transfer consent need to be stated there)

Boundaries

No repo-creation code in this issue — decision only. No reward/pricing figures.

maintainer-only — architecture/ownership decision, not a build task.

[linear-code]

JSO-5376

[JSONbored]

Decided (2026-07-20): APR repos default to a loopover-controlled GitHub org, created via the existing GitHub App's installation token — zero new GitHub-facing consent from the idea-submitter. An explicit, optional transfer-to-customer-account flow is available any time via GitHub's standard repository transfer mechanism (recipient accepts via a confirmation email). Ownership before transfer: loopover, with read access exposed to the customer only through the loopover dashboard, not raw GitHub access. Closing — real implementation issues filed as follow-on work, linked below.

[JSONbored]

Correction (2026-07-21): the "loopover-controlled GitHub org" this decision assumes doesn't exist yet — everything currently lives under the JSONbored personal account. The decision itself still stands (org-hosted + optional transfer is the right shape, for the reasons already stated: a GitHub App cannot create repos under a personal account at all, so an org is required regardless of which way this went). What's missing is the org itself — a real prerequisite, maintainer-executed, account-level action (create the org, install the existing GitHub App on it with administration:write), not something scoped as a GitHub issue. See the note on #7637 for the implementation-side implication (reads the org name from config, so the code isn't blocked on the org existing — only real end-to-end testing is).