refactor(engine): extract the pull-request-target-key parser into loopover-engine

[reyanthony062001-ops]

Summary

Extracts the pure parsePullRequestTargetKey parser out of the D1-query-heavy src/db/repositories.ts and into @loopover/engine as a standalone, independently-tested function — the "sweep for pure logic stranded inside I/O-bound files" work from #4882. The parser ("<owner>/<repo>#<number>" → { repoFullName, pullNumber } | null) has zero side effects, zero imports, and was module-private with only two in-file call sites, so it moves cleanly: the engine gains the function + a barrel export, and repositories.ts imports it (no behavior change at the two call sites).

Identified in the same file during the sweep and left as follow-up candidates (kept out to honor "one direction of movement per PR"): intersectionCount, maxIso, escapeSqlLikePattern.

Closes #4882

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• 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 (Closes #4882).

Validation

• git diff --check — clean
• npm run actionlint — no workflow changes
• npm run typecheck — passes (whole project; the new @loopover/engine import in repositories.ts resolves against the built engine)
• npm run test:coverage — the new suite test/unit/parse-pull-request-target-key.test.ts drives the moved function through the engine barrel and covers 100% of statements/branches/functions/lines on parse-pull-request-target-key.ts (verified via coverage-summary.json); codecov/patch measures only the diff, and the two consumer call sites are unchanged
• npm run test:workers — unaffected (no worker changes)
• npm run build:mcp / test:mcp-pack — unaffected (no MCP changes)
• npm run ui:openapi:check / ui:lint / ui:typecheck / ui:build — unaffected (no UI/OpenAPI changes)
• npm audit --audit-level=moderate — no dependency changes
• New or changed behavior has unit tests for new branches — every branch of the parser (falsy input, missing/leading/trailing #, repo half without /, non-integer / non-positive pull number, valid, and last-# split) is exercised

If any required check was skipped, explain why:

• This is an isolated pure-function extraction touching only src/db/repositories.ts (−1 def, +1 import) and packages/loopover-engine/src/** (+ a test). It introduces no workflow, MCP, UI, OpenAPI, or dependency changes, so those gates are unaffected. I validated the parts that touch the change: whole-project typecheck, the engine build, the engine's own suite (550/550), and the new function's test at 100% coverage.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests — N/A (none).
• API/OpenAPI/MCP behavior is updated and tested where needed — N/A (none).
• UI changes use live API data or real empty/error/loading states — N/A (no UI changes).
• Visible UI changes include a UI Evidence section — N/A (no UI/frontend/docs/extension changes).
• Public docs/changelogs are updated where needed — N/A.

Notes

• Pattern mirrors the merged engine extractions (e.g. refactor(engine): extract the deny-hook pure logic into gittensory-engine #5701 deny-hook, feat(engine): extract path-matchers.ts's pure classifier family to gittensory-engine #4252–feat(engine): extract buildIssueRagQuery to gittensory-engine #4254): new engine module + barrel export + a test that drives the moved code through the engine's public barrel so it carries its own coverage. src/db is outside check-engine-parity's scope (review/settings/signals + named twins), so no parity twin is introduced.

[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 95.07%. Comparing base (58f7d5d) to head (646d931).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5762   +/-   ##
=======================================
  Coverage   95.07%   95.07%           
=======================================
  Files         581      582    +1     
  Lines       46181    46183    +2     
  Branches    14811    14812    +1     
=======================================
+ Hits        43905    43907    +2     
  Misses       1516     1516           
  Partials      760      760           

Flag	Coverage Δ
shard-1	43.95% <0.00%> (-0.01%)	⬇️
shard-2	35.74% <0.00%> (-0.01%)	⬇️
shard-3	32.33% <0.00%> (+0.06%)	⬆️
shard-4	33.54% <0.00%> (+0.59%)	⬆️
shard-5	31.19% <100.00%> (-0.57%)	⬇️
shard-6	44.62% <0.00%> (-0.02%)	⬇️

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

Files with missing lines	Coverage Δ
...opover-engine/src/parse-pull-request-target-key.ts	100.00% <100.00%> (ø)
src/db/repositories.ts	96.70% <ø> (-0.02%)	⬇️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-14 12:49:32 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR does exactly what it claims: it relocates the pure, side-effect-free `parsePullRequestTargetKey` function from `src/db/repositories.ts` into `@​loopover/engine`, adds a barrel export, and updates the single call-site import — no logic was altered in the function body itself (identical implementation, same branches). The new dedicated test suite exercises all documented branches (falsy input, missing/leading/trailing `#`, no `/` in repo half, non-integer/non-positive pull number, valid parse, and the last-`#`-wins split case), which is appropriate coverage for a pure parser. This is a clean, narrowly-scoped mechanical extraction with no behavior change at the two consumer call sites.

Nits — 4 non-blocking

• The size-smell flags on `index.ts` (713 lines) and `repositories.ts` (3360 lines) predate this diff and are pre-existing file-length issues, not something this PR should be asked to fix, but worth tracking separately per the Sweep for pure logic stranded inside I/O-bound files #4882 sweep.
• The doc comment on `parsePullRequestTargetKey` (parse-pull-request-target-key.ts:1-5) duplicates the JSDoc that likely existed inline before extraction — worth confirming it wasn't left stale relative to the moved code.
• Consider adding a brief barrel-export comment convention note if other engine modules don't already follow the same header style as index.ts:710-713.
• None needed beyond the nits above — the extraction is mechanical and well-tested.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#4882
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), 17 merged, 1 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	reyanthony062001-ops; Gittensor profile; 28 PR(s), 1 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence. LLM value judgment: minor — This is a small, low-risk, well-tested mechanical code-organization move that incrementally advances the stated pure-logic-extraction sweep (#4882) but has no functional or user-facing impact.

Linked issue satisfaction

Partially addressed
The PR extracts one pure function (parsePullRequestTargetKey) with a proper test, satisfying the acceptance criterion for that function, but the issue explicitly asks for a sweep across multiple large I/O-bound files (repository-access layer, queue processor, GitHub-command layer) and moving at least the most valuable candidates, whereas this PR deliberately limits itself to a single small functio

Review context

• Author: reyanthony062001-ops
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Cuda, HTML, JavaScript, Python, TypeScript
• Official Gittensor activity: 28 PR(s), 1 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.

[BETA] Chat with Gittensory

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

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

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 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]

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