Epic: dual-path repo provisioning — BYOR + APR

[JSONbored]

Problem

This epic's own Problem statement assumes a customer already has "their own repository" — every foundations issue (#4780's repo-agnostic capability audit, #4784-4788's generalized any-repo agent work, #4798's idea-intake tool) is written against that assumption. Nothing covers the case where the idea-submitter has no repository at all and doesn't want one — describe an idea, get a working project back, with zero GitHub interaction on their end. That's a real, distinct product surface (bring-your-own-repo vs. auto-provisioned-repo), not an edge case of the existing one.

Area

Product spec / architecture. Sub-epic of this milestone, not a replacement for its existing BYOR-shaped scope.

Proposal

Support both paths cleanly as two entry points into the same underlying pipeline (idea-intake → AMS discovery/build → ORB review), not two separate products:

• BYOR (bring your own repo) — the path this milestone already assumes: customer has a repo, installs the GitHub App (Self-serve signup & App-install flow #4802), AMS/ORB operate against it at the customer's configured autonomy level. Already substantially specced.
• APR (auto-provisioned repo) — net new: the idea-submitter never touches GitHub. Two sub-pieces, filed separately below:
  • Where the resulting repo lives and who owns it by default, with a path to full customer ownership later.
  • How "the idea is done" gets decided and communicated back to someone who never sees a PR, an issue, or a commit.

Both paths share everything downstream of "which repo does this task-graph target" — the idea-intake tool (#4798), AMS's discovery/build loop, ORB's review, and the settlement/pool mechanism are all repo-origin-agnostic already or trivially made so. The fork is narrow: provisioning + ownership + completion-signaling, not a second architecture.

Deliverables

• Two sub-issues (linked) covering the APR-specific gap.
• Idea-intake bridge schema #4779's idea-intake schema gets an explicit target field (existing repo vs. to-be-provisioned) once the sub-issues below land — not scoped here, follow-on work.

Resources

• Epic: Miner Wave 5 — Rent-a-Loop #4778 (parent Wave 5 epic)
• Repo-agnostic capability audit #4780, Idea-intake API/MCP tool #4798, Self-serve signup & App-install flow #4802, Third-party autonomy & security governance spec #4782 (existing BYOR-shaped foundations, cross-referenced not duplicated)
• Content-moderation policy for submitted ideas #5136, Terms of Service & liability terms #4805 (content-moderation and ToS — both get an APR-specific consideration, cross-referenced there)

Boundaries

Spec-level only in this epic and its two sub-issues — no repo-creation code, no hosting/ownership decision implemented yet, no reward/pricing figures.

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

[linear-code]

JSO-5375

[JSONbored]

Update (2026-07-20): two more sub-issues added, both arising directly from #7591's completion-signal question:

• Design: default starting autonomy/quality-gate baseline for zero-history projects (APR + never-configured BYOR repos) #7595 — default starting autonomy/quality-gate baseline for zero-history projects. Confirmed direction: Design spec: idea-completion determination + customer-facing status for APR (no GitHub UI exposure) #7591's completion determination reuses the existing per-repo autonomy dial (observe/auto_with_approval/auto) exactly as self-hosted ORB already works, not a bespoke human-confirmation requirement — but that dial needs a defined starting point for a project with no operator to configure one, since the existing tightening-only self-tune loop (src/settings/repository-settings.ts) only ever raises an existing threshold, never invents one.
• Audit: how many installs currently have no qualityGateMinScore set, to inform a safe cold-start default #7596 — a small, genuinely contributor-eligible audit informing Design: default starting autonomy/quality-gate baseline for zero-history projects (APR + never-configured BYOR repos) #7595's decision with real data (how many current installs have no threshold set today) rather than a guess. First contributor-unlocked issue out of this whole research thread — everything else on it stays maintainer-only per this repo's own "what's safe to unleash" test.