fix(api): allow authenticated sessions to reach registration-readiness / gittensor-config-recommendation (#8654)

[RealDiligent]

Problem

Closes #8654.

src/api/routes.ts's registration-readiness and gittensor-config-recommendation route handlers have no internal auth/role check — they are advisory, any-authenticated-user lookups. The owner panel calls both via useApiResource (always credentials: "include") and takes a free-text repo name rather than scoping to the caller's own repos.

Neither path had a predicate in canSessionAccessPath, so a real non-operator browser session got 403 on the owner panel's only two data calls, while operators / server tokens (which bypass the allowlist) worked.

Fix — unblock only, no new restriction

Added the two missing path predicates and their allowlist entries in canSessionAccessPath, so any authenticated session may reach both routes.

This unblocks the existing intended open access; it adds no authorization restriction. Evidence the open access is intentional:

• The handlers carry no per-repo ownership check at all.
• buildRegistrationReadinessResponse deliberately strips owner-private context via stripOwnerPolicyContext before returning — the payload is designed for public/any-authenticated reads.
• The owner panel intentionally accepts an arbitrary free-text repo name.

Tests

A new test in test/unit/access-boundary.test.ts asserts a logged-in user who maintains no repo here now gets 200 (previously 403) on both routes for an arbitrary repo. Reverting the allowlist entries makes it fail. git diff --check clean.

(Supersedes #8703, which the bot auto-closed under the 2-open-PR limit; re-filed now that a slot is free.)

[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-26 00:07:12 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 two missing path predicates (registration-readiness, gittensor-config-recommendation) to canSessionAccessPath so authenticated non-operator sessions can reach the owner panel's two advisory, per-repo-scope-free data endpoints, matching the existing pattern used by sibling routes in this same function. It also (in a separately-scoped hunk) swaps merge-train.ts's hand-rolled 4-name lockfile regex for the canonical isLockfile helper and broadens the low-signal directory set, with new tests for both changes and the access-boundary fix. The two changes are unrelated to each other (auth allowlist fix vs. merge-train overlap classification) but both are narrow, well-tested, and each traces to a linked issue (#8654, #8647).

Nits — 4 non-blocking

• The PR bundles two unrelated fixes (fix(orb): registration-readiness and gittensor-config-recommendation routes are unreachable from a real browser session #8654 auth allowlist, fix(orb): merge-train.ts's hand-rolled lockfile/vendor-directory lists have drifted from the canonical path-matchers set #8647 lockfile-matching) in one diff; even though both are small and well-tested, splitting them would make each easier to review and revert independently.
• src/api/routes.ts's canSessionAccessPath is now well over a hundred predicate lines with no per-repo scoping check itself — the comment above it already flags that per-route guards do the real enforcement, but a table-driven route→predicate mapping would make future omissions (exactly this bug) less likely to recur.
• Consider splitting this into two PRs matching the two closed issues (fix(orb): registration-readiness and gittensor-config-recommendation routes are unreachable from a real browser session #8654 and fix(orb): merge-train.ts's hand-rolled lockfile/vendor-directory lists have drifted from the canonical path-matchers set #8647) for cleaner review history.
• In merge-train.ts, consider extracting the magic 24 (hours) already named via MERGE_TRAIN_MAX_WAIT_MS is fine, but the new LOW_SIGNAL_DIR_RE directory list could reference a shared constant if review-grounding.ts or review-diff.ts already export one, to avoid drift between the three copies.

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	#8654
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: 327 registered-repo PR(s), 134 merged, 37 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	RealDiligent; Gittensor profile; 327 PR(s), 37 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds the two missing predicates to canSessionAccessPath, explains explicitly (with evidence) that this unblocks existing intended open access rather than adding a restriction, and includes the required session-cookie-based test in access-boundary.test.ts asserting 200 for a non-maintaining user on both routes.

Review context

• Author: RealDiligent
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, Ruby, TypeScript, Svelte, Cuda, JavaScript, Markdown, MDX
• Official Gittensor activity: 327 PR(s), 37 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.