fix(github): reject a malformed three-segment repoFullName in comments.ts

[ultrahighsuper]

What

createOrUpdateIssueCommentWithMarker in src/github/comments.ts validated repoFullName with const [owner, repo] = repoFullName.split("/") + a truthiness check. "owner/repo/extra" passed it — the destructure silently dropped the extra segment, and the GitHub API call was issued against owner/repo, a repo the caller never specified.

Resolves #6612.

Fix

Add the missing parts.length !== 2 segment-count check inline, matching the guard already in parseRepoFullName (assignees.ts / labels.ts):

const parts = repoFullName.split("/");
const owner = parts[0];
const repo = parts[1];
if (parts.length !== 2 || !owner || !repo) throw new Error(`Invalid repository full name: ${repoFullName}`);

• No-slash ("invalid") and empty-segment ("owner/", "/repo") inputs are still rejected exactly as before.
• Whitespace handling is intentionally left unchanged (a separate issue, pr-actions.ts splitRepo misses per-segment whitespace padding (owner/ repo slips through) #6613, covers per-segment padding in a different file).
• Both exported wrappers (createOrUpdatePrIntelligenceComment, createOrUpdateAgentCommandComment) continue to propagate the thrown error unchanged.

Test

test/unit/github-comments.test.ts gains a case asserting "owner/repo/extra" is rejected via createOrUpdatePrIntelligenceComment, mirroring the precedent in github-assignees.test.ts. The new parts.length !== 2 branch is exercised by it.

Locally green: npx vitest run test/unit/github-comments.test.ts → 14/14 pass; the new branch is covered (diff patch-coverage complete).

[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.64%. Comparing base (42805e0) to head (fcbe3a5).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6640   +/-   ##
=======================================
  Coverage   93.64%   93.64%           
=======================================
  Files         680      680           
  Lines       68026    68028    +2     
  Branches    18673    18673           
=======================================
+ Hits        63704    63706    +2     
  Misses       3347     3347           
  Partials      975      975           

Flag	Coverage Δ
shard-1	43.93% <100.00%> (-0.08%)	⬇️
shard-2	36.99% <75.00%> (+0.21%)	⬆️
shard-3	32.41% <0.00%> (-0.01%)	⬇️
shard-4	34.17% <75.00%> (-0.60%)	⬇️
shard-5	31.50% <0.00%> (+0.52%)	⬆️
shard-6	45.77% <75.00%> (+0.06%)	⬆️

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

Files with missing lines	Coverage Δ
src/github/comments.ts	100.00% <100.00%> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-16 17:13:49 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 adds a segment-count check (`parts.length !== 2`) to the repoFullName validation in `createOrUpdateIssueCommentWithMarker`, closing the gap where a three-segment string like "owner/repo/extra" silently truncated instead of being rejected. The fix correctly mirrors the existing guard pattern in `parseRepoFullName` (assignees.ts/labels.ts), and the added test exercises the exact new branch via the public `createOrUpdatePrIntelligenceComment` wrapper, verifying no GitHub call occurs. This is a minimal, well-scoped, correctly-traced fix for a real security/data-integrity gap tied to issue #6612.

Nits — 3 non-blocking

• The inline comment on comments.ts:56-58 is fairly verbose for a one-line guard; could be trimmed to a single sentence per repo convention.
• Consider also testing edge cases like "owner//repo" (empty middle segment with 3 parts) though this is already implicitly covered by the length check.
• Could extract the shared owner/repo parsing guard (`parts.length !== 2 || !owner || !repo`) into a small shared helper alongside `parseRepoFullName` to avoid drift between comments.ts, assignees.ts, and labels.ts.

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

Linked issue satisfaction

Addressed
The diff adds the required parts.length !== 2 check to comments.ts matching the parseRepoFullName shape, and adds a new test asserting 'owner/repo/extra' is rejected via createOrUpdatePrIntelligenceComment.

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: 118 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

[loopover-orb]

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