feat(enrichment): allowlist 0.0.0.0 in the hardcoded-URL analyzer

[jeffrey701]

ALLOWLISTED_HOSTS treated localhost/127.0.0.1/example.com as placeholders but not 0.0.0.0, the unspecified/localhost bind address — so http://0.0.0.0:PORT (a dev/bind placeholder, not a real endpoint) was flagged as a hardcoded URL. Adds it + extends the allowlist test. rees green (1026).

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 Gittensory review result - reject/close recommended

_{Review updated: 2026-07-05 18:06:05 UTC}

2 files · 1 AI reviewer · 3 blockers · readiness 55/100 · CI green · clean

🛑 Suggested Action - Reject/Close

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.
• AI reviewers agree on a likely critical defect: The PR description gives no linked/eligible open issue for this change (only a garbled 'rees green (1026)' which reads like a CI/build reference, not an issue number) — per this repo's contributor policy every external PR must close or clearly link an eligible issue, so this should not be marked merge-ready until that's confirmed. — Resolve the flagged defect, or override if the AI reviewers are mistaken, then re-run the gate.

Review summary
This adds "0.0.0.0" to ALLOWLISTED_HOSTS in hardcoded-url.ts and extends the existing allowlist test with a case for it. The fix is correct and minimal: 0.0.0.0 is a legitimate bind-placeholder like localhost/127.0.0.1, and since isAllowlistedHost() is shared by both the http-url and ip-endpoint detection paths, adding it to the Set suppresses false positives for both `http:​//0.0.0.0:PORT` and bare `0.0.0.0:PORT` forms even though only the http-url form is explicitly tested. The diff renders as a near-total file rewrite (+148/-143 for what is functionally a one-entry Set addition), which is very likely a reformatting/line-ending artifact rather than real churn, but that's cosmetic, not a defect.

Blockers

• The PR description gives no linked/eligible open issue for this change (only a garbled 'rees green (1026)' which reads like a CI/build reference, not an issue number) — per this repo's contributor policy every external PR must close or clearly link an eligible issue, so this should not be marked merge-ready until that's confirmed.

Nits — 6 non-blocking

• hardcoded-url.ts's diff shows the entire file as removed/re-added for a one-line Set addition — worth asking the contributor to isolate the real change (likely a line-ending/whitespace normalization) so future diffs on this file are reviewable at a glance.
• The new test only exercises the HTTP_URL_RE branch for 0.0.0.0 (`fetch('http:​//0.0.0.0:8080')`); consider also asserting the bare IP:port form (e.g. `connect('0.0.0.0:8080')`) to explicitly cover the IP_ENDPOINT_RE path even though it shares the same allowlist check.
• No entry was added for 0.0.0.0 with a non-standard port or without a scheme in the http-url test group's docstring/comment style — the inline comment explaining why 0.0.0.0 is allowlisted is a nice touch worth keeping consistent with the other allowlist entries (none currently have inline rationale).
• Confirm/attach the issue this analyzer false-positive report is tracked under, per gittensory's issue-scope policy.
• If the whole-file diff is just a formatting artifact, consider re-saving with the repo's standard line endings before pushing to keep the diff minimal.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

Why this is blocked

• The PR description gives no linked/eligible open issue for this change (only a garbled 'rees green (1026)' which reads like a CI/build reference, not an issue number) — per this repo's contributor policy every external PR must close or clearly link an eligible issue, so this should not be marked merge-ready until that's confirmed.
• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 3 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	⚠️ 1 scoped overlap	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (no linked issue context).
Validation posture	❌ 5/25	Preflight is holding this PR: the review lane is unavailable, so it is not ready for automated review.
Contributor workload	✅ 10/10	Author activity: 74 registered-repo PR(s), 39 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jeffrey701; Gittensor profile; 74 PR(s), 0 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: jeffrey701
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: Clojure, TypeScript
• Official Gittensor activity: 74 PR(s), 0 issue(s).
• Related work: Titles/paths share 7 meaningful terms. (issue #2023, issue #2033)

Contributor next steps

• Explain no-issue PR.
• Review top overlaps.
• Add a concise scope and risk note.
• Await review-lane availability.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.
• Check active issues and PRs before submitting.

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.

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[loopover-orb]

Gittensory is closing this pull request on the maintainer's behalf (No linked issue detected; Maintainer requires a linked issue; AI reviewers agree on a likely critical defect: The PR description gives no linked/eligible open issue for this change (only a garbled 'rees green (1026)' which reads like a CI/build reference, not an issue number) — per this repo's contributor policy every external PR must close or clearly link an eligible issue, so this should not be marked merge-ready until that's confirmed.). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.