fix(content-lane): first-hop source URL validation failure is a hard failure, not passed

[kai392]

Closes #9669

What

checkOneSourceUrl's first-hop path (src/review/content-lane/source-evidence.ts) mapped a source_host_not_checked validation failure — a plain http:// URL, or one whose host fails the SSRF guard (isSafeHttpUrl: private/loopback/link-local) — to status: "passed", via an invalidProtocol ? "hard_failure" : "passed" ternary. The redirect-loop path treats the identical outcome as a hard_failure. So an unfetchable canonical source was silently reported OK, and a report whose only source was such a URL came back "passed".

The invalidProtocol ternary is removed: both validator failure outcomes now hard-fail on the first hop, identical to the redirect path. outcome/error still carry the validator's own values, and validateFetchableSourceUrl/isSafeHttpUrl/the warnings filter are untouched. downgradeInconclusiveSourceWarnings remains the only mechanism that makes a distribution-role source_host_not_checked non-blocking, so a distribution http:// source alongside a verifiable canonical is still relaxed — through the correct mechanism, not by mislabelling it "passed".

Tests

• First-hop http://example.com/x and https://127.0.0.1/x → hard_failure with outcome source_host_not_checked (deliverables 1 & 2).
• A canonical http:// source with no verifiable canonical → report status: "failed" (was "passed") (deliverable 4).
• A distribution http:// source alongside a reachable primary canonical → downgraded to blocking: false via downgradeInconclusiveSourceWarnings (deliverable 3 — proves the intended relaxation still applies through the correct mechanism).
• Updated the two prior tests that pinned the old "passed" behaviour.

Verified: 87/87 in content-lane-source-evidence.test.ts, tsc --noEmit clean, git diff --check clean.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-29 19:24:12 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR removes the `invalidProtocol` ternary in `checkOneSourceUrl` so both validator-failure outcomes (`invalid_url` and `source_host_not_checked`) hard-fail on the first hop, matching the redirect-loop path's existing behavior at the same file's `fetchSourceUrl` function. The trace is sound: `validateFetchableSourceUrl` genuinely returns `source_host_not_checked` for a plain `http:​//` or a private/loopback host, and before this change that outcome was mapped to `status: "passed"` while the identical outcome in the redirect loop was already `hard_failure` — a real inconsistency, not a can't-occur fix. The added regression test confirms the intended relaxation (distribution-role http:​// source alongside a reachable primary canonical) still works, but now correctly via `downgradeInconclusiveSourceWarnings` rather than by mislabelling the first-hop result "passed".

Nits — 4 non-blocking

• The PR description claims 'Closes orb(content-lane): an unfetchable source URL reports passed on the first hop #9669' but the external brief notes issue coverage is only partial — worth confirming the linked issue's full scope is addressed.
• The inline comment block added at source-evidence.ts:420-424 is fairly long for a one-line ternary removal; could be trimmed to the single non-obvious point (redirect path already hard-fails this).
• Consider a one-line comment instead of the four-line block at source-evidence.ts:420, since the redirect-path parity is the only non-obvious fact.
• No consumers of `SourceEvidenceItem.status === "passed"` for `source_host_not_checked` were found in this diff, but it's worth a repo-wide grep for callers relying on the old behavior before merging.

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

Linked issue satisfaction

Addressed
The diff removes the invalidProtocol ternary so the first-hop path unconditionally returns hard_failure with the validator's own outcome/error, mirroring the redirect path exactly as required, and adds named tests covering both failure outcomes, the canonical-http report-failure case, and a distribution-role downgrade regression test proving downgradeInconclusiveSourceWarnings remains the sole rel

Review context

• Author: kai392
• 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: 89 PR(s), 7 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.

🧪 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

[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 79.35%. Comparing base (e3247ed) to head (b670680).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9892      +/-   ##
==========================================
+ Coverage   79.28%   79.35%   +0.07%     
==========================================
  Files         281      282       +1     
  Lines       58516    58716     +200     
  Branches     6777     6850      +73     
==========================================
+ Hits        46393    46593     +200     
  Misses      11840    11840              
  Partials      283      283              

Flag	Coverage Δ
backend	100.00% <ø> (?)

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

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

[loopover-orb]

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