fix(content-lane): add snake_case source-url aliases to sourceUrlFields (#7250)

[xfodev]

Summary

content-repo-spec.ts defines two lists over the same concept — the manifest-entry keys that hold a
source/provenance URL — but they had diverged:

• urlFields (a Set, read by duplicates.ts) lists both camelCase and snake_case aliases
  (sourceUrl/source_url, githubUrl/github_url, …).
• sourceUrlFields (an array, read by source-evidence.ts) listed only the camelCase names.

So a manifest entry using a legitimately-listed snake_case key — e.g. source_url:, in fact the canonical
field per the repo's contribution conventions — was seen by duplicate-detection but invisible to the
source-evidence gate.

This adds the eight snake_case aliases (docs_url, download_url, github_url, package_url, repo_url,
repository_url, source_url, website_url) to sourceUrlFields, matching urlFields's existing pairing
one-for-one. Data-only change to the spec constant; neither consumer's logic is touched. (src/review/content-lane/content-repo-spec.ts is a export * re-export shim, so the app sees the fix automatically.)

Closes #7250

Scope

• Conventional Commit title; focused (one spec constant + its test); no site//CNAME/lovable; no new dependency.
• Linked a currently open issue (Closes #7250).

Validation

• git diff --check
• npm run typecheck (root — clean)
• npm run test:coverage — 100% of the changed lines covered. New regression: a source_url: frontmatter
  field is now extracted by extractSubmittedSourceUrls (it was dropped before), and every snake_case alias in
  sourceUrlFields is asserted present in both lists. Existing content-lane duplicate/source-evidence suites pass unchanged.
• Change is a pure data addition to a readonly string[]; both consumers' logic is untouched.

If any required check was skipped, explain why:

• Change confined to packages/loopover-engine/src/review/content-lane/** (one constant + one test); CI runs the full suite incl. engine-parity.

Safety

• No secrets, wallets, hotkeys, coldkeys, PATs, trust scores, or private data exposed.
• Public GitHub text stays sanitized and low-noise.
• No auth/CORS/session/API/OpenAPI/MCP surface change — a spec-constant data fix; it only makes the source-evidence gate recognize the same fields duplicate-detection already did.
• No UI change — no UI Evidence needed.

[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.81%. Comparing base (3c72fce) to head (d13c5da).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7269   +/-   ##
=======================================
  Coverage   93.81%   93.81%           
=======================================
  Files         704      704           
  Lines       69457    69457           
  Branches    18899    18899           
=======================================
  Hits        65161    65161           
  Misses       3302     3302           
  Partials      994      994           

Flag	Coverage Δ
shard-1	43.61% <ø> (ø)
shard-2	37.33% <ø> (+0.10%)	⬆️
shard-3	33.18% <ø> (+0.08%)	⬆️
shard-4	33.74% <ø> (-0.59%)	⬇️
shard-5	32.89% <ø> (+0.70%)	⬆️
shard-6	45.48% <ø> (-0.30%)	⬇️

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

Files with missing lines	Coverage Δ
...ngine/src/review/content-lane/content-repo-spec.ts	100.00% <ø> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-19 11:46:28 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a small, well-targeted data-only fix: it adds the eight snake_case URL field aliases to sourceUrlFields so it matches urlFields, closing a real gap where source-evidence.ts couldn't see legitimately-aliased snake_case fields like source_url that duplicates.ts already recognized. The accompanying test directly exercises the previously-broken path (extractSubmittedSourceUrls on a source_url: frontmatter entry) and asserts parity between the two field lists, which is exactly the right regression guard. Neither consumer's logic is touched, matching the stated scope, and CI is green.

Nits — 3 non-blocking

• The inline comment in content-repo-spec.ts:109-111 is fairly long for a single array addition; could be trimmed to one line referencing the issue.
• No corresponding test added for content-lane-duplicates.ts to confirm urlFields already covered these aliases pre-fix, though this isn't strictly required since that file wasn't changed.
• Consider extracting the shared list of URL field base names (e.g. docsUrl/docs_url pairs) into a single source-of-truth array that generates both camelCase and snake_case variants, to prevent this exact kind of drift from recurring.

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	#7250
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: 19 registered-repo PR(s), 9 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	xfodev; Gittensor profile; 19 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff adds all eight required snake_case aliases to sourceUrlFields, matching urlFields' existing pairing exactly, and includes a regression test asserting a snake_case-keyed source_url entry is recognized and that every alias pair is present in both lists.

Review context

• Author: xfodev
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript, TypeScript
• Official Gittensor activity: 19 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 1 step 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.