feat(orb): create APR repos under the submitting customer's own account

[joaovictor91123]

Closes #7637

Summary

• Adds createAprRepoForCustomerSession (src/orb/apr-repo-creation.ts), which creates a new GitHub repository via POST /user/repos using a specific customer session's own live OAuth token (getLiveSessionGitHubToken) — never a fixed/operator session, never an installation-token driver.
• GitHub's POST /user/repos always creates the repo under the authenticated user's own account, so the result is <customer-login>/<repoName>, never a fixed owner.
• startGitHubWebOAuth now accepts an explicit scope parameter, defaulted to the existing "read:user" so every current caller (the standard login flow) is completely unaffected — only the APR idea-submission flow will pass "read:user repo".
• Returns a structured { created: false } result (never throws) on a missing/expired session token or a GitHub API error (e.g. a repo-name collision), so callers get a total function they can branch on.

Scope checklist

• No new auth flow invented — reuses the existing multi-user OAuth session infrastructure in src/auth/github-oauth.ts exactly as required
• No GitHub App, org, or installation-token driver used for repo creation
• Default login flow's scope (read:user) is unchanged — verified by an explicit test

Validation checklist

• npm run typecheck (repo-wide) passes clean (3 pre-existing, unrelated errors confirmed via git stash on a clean checkout)
• New tests cover: success with a mock customer session (default private, explicit private:false + description), a missing/expired session token failing closed without calling GitHub, a GitHub API error (e.g. repo-name collision) handled without throwing, and a malformed 2xx payload failing closed
• Added a test confirming the default OAuth flow still requests only read:user, and a new test for the explicit "read:user repo" variant

Safety checklist

• No secrets, tokens, wallets, hotkeys/coldkeys, trust scores, or reward/payout values touched — all token fixtures in tests are obviously-fake opaque placeholders, never PEM/private-key-shaped
• No changes to site/, CNAME, or **/lovable/**

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-22 15:17:03 UTC}

4 files · 1 AI reviewer · no blockers · readiness 98/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR adds createAprRepoForCustomerSession, which creates a GitHub repo via POST /user/repos using a customer's own live OAuth token (via getLiveSessionGitHubToken), and adds an optional scope parameter to startGitHubWebOAuth defaulting to "read:user" so existing callers are unaffected. The implementation is correct as shown: it fails closed on missing token, GitHub API errors, and malformed 2xx payloads, and tests cover all these paths plus verify the default OAuth scope is unchanged. Nothing in this diff actually wires createAprRepoForCustomerSession or the new scope parameter into the idea-submission flow itself — this appears to be a building-block PR (the caller/route that invokes this with `read:user repo` and calls createAprRepoForCustomerSession is not part of this diff), which is worth confirming against the linked issue's full scope.

Nits — 5 non-blocking

• The `api.github.com` endpoint is hardcoded in src/orb/apr-repo-creation.ts:38, consistent with the rest of the file's style (e.g. github-oauth.ts also hardcodes github.com URLs), so this is a non-issue for consistency but worth noting if the codebase ever needs to support GitHub Enterprise.
• src/orb/apr-repo-creation.ts:45 truncates the error detail to 200 characters with a magic number; consider a named constant like `MAX_ERROR_DETAIL_LENGTH` for clarity.
• The PR closes Implement APR repo creation under the submitting customer's own GitHub account (their OAuth, not a fixed account) #7637 but the diff only adds the repo-creation primitive and OAuth scope plumbing — confirm whether the actual idea-submission route wiring is coming in a follow-up PR or was expected here, since the issue title implies the customer-facing flow should work end-to-end.
• No test verifies that `options.private` explicitly set to `undefined` still defaults to `true` versus a caller passing `private: false` intentionally, though the `??` operator in apr-repo-creation.ts:34 correctly handles both cases.
• Consider adding a brief note in the PR description or a follow-up issue reference for where `createAprRepoForCustomerSession` and the new `scope` parameter get invoked, since this PR alone doesn't wire up the customer-facing flow described in Implement APR repo creation under the submitting customer's own GitHub account (their OAuth, not a fixed account) #7637.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#7637
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 158 registered-repo PR(s), 69 merged, 6 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	joaovictor91123; Gittensor profile; 158 PR(s), 6 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds createAprRepoForCustomerSession which calls POST /user/repos using getLiveSessionGitHubToken(env, sessionId) for a specific customer session and returns full name/URL/node ID, and extends startGitHubWebOAuth with a scope parameter defaulting to read:user while allowing an explicit read:user repo variant, matching the issue's core requirements.

Review context

• Author: joaovictor91123
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, JavaScript, MDX, C++, CSS, Rust, TypeScript
• Official Gittensor activity: 158 PR(s), 6 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.

[codecov]

Codecov Report

❌ Patch coverage is 93.33333% with 1 line in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@b3bd0ba). Learn more about missing BASE report.
⚠️ Report is 23 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/orb/apr-repo-creation.ts	92.30%	0 Missing and 1 partial ⚠️

❌ Your patch status has failed because the patch coverage (93.33%) is below the target coverage (99.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8046   +/-   ##
=======================================
  Coverage        ?   95.74%           
=======================================
  Files           ?        2           
  Lines           ?      141           
  Branches        ?       55           
=======================================
  Hits            ?      135           
  Misses          ?        2           
  Partials        ?        4           

Flag	Coverage Δ
shard-1	71.63% <13.33%> (?)
shard-2	51.77% <13.33%> (?)
shard-3	69.50% <93.33%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/auth/github-oauth.ts	96.09% <100.00%> (ø)
src/orb/apr-repo-creation.ts	92.30% <92.30%> (ø)