feat(review): enrich issue planning with gittensor type-label taxonomy when enrolled

[JSONbored]

Summary

• Adds gittensor-enrollment-aware enrichment to loopover_plan_repo_issues (#7426): when the target repo has opted into the gittensor plugin (LOOPOVER_EXPERIMENTAL_GITTENSOR AND the repo's own .loopover.yml experimental.gittensor: true — shouldEnableGittensorForRepo, src/review/gittensor-wire.ts), the repo's configured bug/feature/priority type-label taxonomy is merged into the "existing labels" the prompt already prefers reusing.
• Purely additive — no new prompt section, no system-prompt change. The gittensor type labels are just merged into the same array of label names already passed to buildIssuePlanUserPrompt, so the model treats them exactly like any other repo label to prefer reusing.
• Zero footprint when the plugin is off (the fleet-wide default): isGittensorPluginEnabled(env) short-circuits before this ever loads a manifest or resolved settings, matching gittensor-wire.ts's own documented contract ("a self-host instance with no gittensor affiliation has zero footprint from it").
• Uses resolveRepositorySettings (DB overlaid with .loopover.yml), not the raw DB-only getRepositorySettings: typeLabels/typeLabelsEnabled are config-as-code only now (no DB column backs them, per an existing #6443 comment in src/db/repositories.ts) — reading the raw DB row would have silently ignored a repo's actual configured taxonomy and always produced the built-in default.
• Label names only — never any scoring weight/multiplier. Those never leave the private scoring pipeline.
• Sub-issue of #7424 (Epic: ORB self-hoster issue & milestone planning routine).

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves (e.g. Closes #123) — a linked open issue is required for every contributor PR.

Validation

• git diff --check
• npm run typecheck
• npm run test:coverage locally — full unsharded suite: 1021 files / 19392 tests passed, 2 skipped. The same 9 pre-existing failures in 3 unrelated miner test files (already tracked separately, currently under independent investigation) reproduce identically regardless of this change. New/changed code in src/services/issue-plan-draft.ts is 100% branch-covered.
• npm run selfhost:env-reference:check / npm run ui:openapi:check / npm run docs:drift-check / npm run manifest:drift-check — all clean; no new env vars, no OpenAPI/manifest/MCP-schema surface touched (this PR only changes internal prompt-building logic, no new tool input/output shape).
• npm run ui:lint / npm run ui:typecheck / npm run ui:build / npm run test:workers — not run; no apps/loopover-ui/** or workers-pool-specific files changed.
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries — 6 new tests in test/unit/issue-plan-draft.test.ts: zero-footprint when the plugin is off fleet-wide (even with the repo's own manifest opted in), no enrichment when only one of the two gates is on, full default taxonomy merged when both gates are on, no enrichment when typeLabelsEnabled is explicitly false (config-as-code), a custom typeLabels override taking precedence over the gittensor:* defaults, and the DEFAULT_TYPE_LABELS fallback branch.

If any required check was skipped, explain why:

• ui:lint/ui:typecheck/ui:build/test:workers: no apps/loopover-ui/** or workers-pool-specific files changed.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed — only public label NAMES are ever read into the prompt, never scoring weights/multipliers.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics — every generated draft still passes through the existing isFocusManifestPublicSafe check unchanged.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A here — no auth/session surface touched; covered instead by the zero-footprint/disabled-gate tests above, which are this PR's equivalent negative paths.)
• API/OpenAPI/MCP behavior is updated and tested where needed — no MCP input/output schema change; this is purely an internal enrichment of the existing tool's generation step, already covered by the existing MCP surface-parity test.
• UI changes use live API data or real empty/error/loading states. (N/A — no UI.)
• Visible UI changes include a UI Evidence section. (N/A — backend-only change.)
• Public docs/changelogs are updated where needed. (N/A — no user-facing docs surface; the MCP tool's own description string is unchanged since no input/output shape changed.)

UI Evidence

N/A — this is a backend-only change with no visible UI, frontend, or docs surface.

Notes

• Sub-issue of #7424. Enriches #7426's loopover_plan_repo_issues tool (already merged, #7476).

Closes #7428

[superagent-security]

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.46%. Comparing base (4b67bd9) to head (3649b59).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7516      +/-   ##
==========================================
- Coverage   88.48%   88.46%   -0.02%     
==========================================
  Files         720      720              
  Lines       75703    75710       +7     
  Branches    22533    22537       +4     
==========================================
- Hits        66983    66979       -4     
- Misses       7677     7684       +7     
- Partials     1043     1047       +4     

Flag	Coverage Δ
shard-1	32.93% <0.00%> (-0.12%)	⬇️
shard-2	36.84% <0.00%> (-0.01%)	⬇️
shard-3	25.64% <100.00%> (+0.03%)	⬆️
shard-4	38.91% <0.00%> (+0.01%)	⬆️
shard-5	34.20% <0.00%> (-0.01%)	⬇️
shard-6	36.22% <0.00%> (-0.01%)	⬇️

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

Files with missing lines	Coverage Δ
src/services/issue-plan-draft.ts	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-20 19:56:29 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR adds gittensor-enrollment-aware type-label enrichment to the issue-plan prompt: when both the global env flag and the repo's own manifest opt in, and typeLabelsEnabled is true, the resolved typeLabels (or DEFAULT_TYPE_LABELS) are merged (deduped via Set) into the existing label names passed to buildIssuePlanUserPrompt. The gating correctly short-circuits on isGittensorPluginEnabled before touching the manifest or settings, matching gittensor-wire.ts's documented zero-footprint contract, and uses resolveRepositorySettings (not the raw DB-only getRepositorySettings) which is the right choice per the #6443 comment since typeLabels/typeLabelsEnabled are config-as-code only. Tests cover the off/on matrix, the false typeLabelsEnabled case, the DEFAULT_TYPE_LABELS fallback, and custom overrides — solid coverage of the new branches.

Nits — 5 non-blocking

• The `Spec: gittensor-enrollment-aware planning enrichment (optional input, zero footprint when disabled) #7428` issue reference in the docstring at src/services/issue-plan-draft.ts:232 doesn't match the PR description's cited issue Spec: repo-agnostic issue-planning MCP tool (draft-by-default, explicit create) #7426 for the base feature — worth double-checking which issue number this enrichment itself is meant to close.
• src/services/issue-plan-draft.ts's `resolveGittensorLabelEnrichment` docstring is quite long (15+ lines) for a single small function; consider trimming to the non-obvious parts (the zero-footprint short-circuit and the resolveRepositorySettings-vs-getRepositorySettings rationale) and dropping the restated summary/description content.
• The file crosses the 400-line long-file threshold per the external brief; not a blocker but worth watching if further gittensor wiring gets added here.
• Consider extracting the docstring's config-as-code rationale (resolveRepositorySettings vs getRepositorySettings) into a shared comment near resolveRepositorySettings itself if other call sites will need the same explanation, to avoid re-deriving it per caller.
• The test file's `capturedUserMessage` helper indexes `run.mock.calls[0]` — if this suite ever calls the AI more than once in a test, this will silently grab the wrong call; a comment noting that assumption would help future maintainers.

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	#7428
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: 28 registered-repo PR(s), 21 merged, 369 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 28 PR(s), 369 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds an enrichment hook to the planning tool gated by isGittensorPluginEnabled and shouldEnableGittensorForRepo, merging gittensor type-label taxonomy purely additively into existing label suggestions, and short-circuits before any additional reads when the plugin is off, matching the zero-footprint contract from gittensor-wire.ts.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Ruby, Go, JavaScript, MDX, Shell, Solidity
• Official Gittensor activity: 28 PR(s), 369 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.

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.