fix(engine): exclude inline code spans in predicted-gate extractLinkedIssueNumbers

[ultrahighsuper]

What

packages/loopover-engine/src/signals/predicted-gate-engine.ts's local extractLinkedIssueNumbers (used by buildPreflightResult for the miner's local predicted-gate preview) had no inline-code-span exclusion, unlike its canonical twin extractLinkedIssueNumbersWithOverflow in src/db/repositories.ts.

This repo's own PR template contains the literal `Closes #123` example, so a miner previewing an unfilled/lightly-edited template body would misread that backtick-wrapped boilerplate as a real linked-issue reference — silently suppressing a missing_linked_issue warning the live gate (using the canonical extractor) would still raise, breaking the documented predicted/live gate parity.

Resolves #6630.

Fix

Port the canonical exclusion into the local function: collect inline code-span ranges via text.matchAll(/[^\n]*/g)and skip any closing-keyword match whose range overlaps a span, across all three match forms (bare#N, qualified owner/repo#N`, full issue URL). The span text itself is not stripped — per the canonical comment, blanking spans would let text on either side combine into a fake closing reference.

Scoped only to this file — src/db/repositories.ts (already correct) and engine.ts (imports the canonical extractor) are untouched.

Acceptance / tests

Per the issue's exact criteria, extended test/unit/predicted-gate-engine-coverage.test.ts:

• `Closes #123` inside a code span → []
• Closes #123 (unwrapped) → [123]
• qualified `closes owner/repo#77` and URL `closes https://github.com/owner/repo/issues/88` inside spans → []

Locally green: npx vitest run test/unit/predicted-gate-engine-coverage.test.ts → 22/22; the file's coverage is 100% lines / 98%+ branch (the new exclusion branches fully covered).

[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 93.65%. Comparing base (5a2db4c) to head (6ac8c1f).
⚠️ Report is 17 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6658   +/-   ##
=======================================
  Coverage   93.64%   93.65%           
=======================================
  Files         680      681    +1     
  Lines       68026    68086   +60     
  Branches    18671    18688   +17     
=======================================
+ Hits        63704    63764   +60     
  Misses       3347     3347           
  Partials      975      975           

Flag	Coverage Δ
shard-1	43.98% <70.00%> (+0.04%)	⬆️
shard-2	36.88% <70.00%> (-0.12%)	⬇️
shard-3	32.42% <70.00%> (+0.01%)	⬆️
shard-4	34.57% <0.00%> (+0.80%)	⬆️
shard-5	30.94% <90.00%> (-0.67%)	⬇️
shard-6	45.69% <70.00%> (-0.09%)	⬇️

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

Files with missing lines	Coverage Δ
...opover-engine/src/signals/predicted-gate-engine.ts	100.00% <100.00%> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-16 18:09:35 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR ports the inline-code-span exclusion from the canonical extractLinkedIssueNumbersWithOverflow in repositories.ts into the local extractLinkedIssueNumbers in predicted-gate-engine.ts, fixing a real predicted/live gate parity bug where backtick-wrapped 'Closes #123' template boilerplate would be misread as a real linked-issue reference. The logic correctly reuses the same overlap-check approach (matchStart < range.end && matchEnd > range.start) and is applied consistently across all three match forms (bare, qualified, URL), matching the canonical implementation. Tests directly exercise the new behavior for all three forms both inside and outside code spans, and CI is green.

Nits — 3 non-blocking

• The insideCodeSpan closure and inlineCodeSpanRanges computation duplicate logic already present in src/db/repositories.ts; consider extracting a shared helper to avoid future drift between the two extractors.
• The inline comment above the diff is quite long (5+ lines) relative to the repo's terser commenting elsewhere in this function — could be trimmed while still capturing the why.
• Consider factoring the code-span detection (inlineCodeSpanRanges + insideCodeSpan) into a shared utility used by both predicted-gate-engine.ts and repositories.ts to guarantee the two extractors never drift out of sync again.

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	#6630
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High 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: 120 registered-repo PR(s), 72 merged, 21 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	ultrahighsuper; Gittensor profile; 120 PR(s), 21 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: ultrahighsuper
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 120 PR(s), 21 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 2 steps in the Signals table above.

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