feat(enrichment): add overly-broad dependency version-range analyzer

[jaso0n0818]

Closes #2036

What

A new local REES analyzer, looseRange, that flags newly-added/changed npm dependency specifiers using dangerously loose ranges instead of a pinned/caret/tilde range — a reproducibility and supply-chain drift risk, since a loose range lets any future publish (including a compromised one) flow into the next install:

• wildcard — * / x: accepts ANY published version
• latest — the latest dist-tag: floats to whatever is published next
• unbounded-gte — >=x / >x with no upper bound: accepts every future major, breaking changes included
• bare — a bare major (18, 18.x): floats across the whole major line

Distinct from the vuln/typosquat analyzers: this judges only the SPECIFIER, never the package. Pure compute over added package.json patch lines — no registry call, no network.

Detection

• Scans added lines in package.json patches only, with the shared hunk/line-counter conventions from the sibling local analyzers (pre-hunk preamble skipped, +++x added-content not mistaken for a header, \ No newline markers do not advance the counter, per-line char cap).
• Keys on the same "name": "spec" line shape as dependency-scan.ts and unwraps npm:pkg@range aliases exactly as it does; like that sibling, parsing is a documented line-based heuristic, not a full manifest parse.
• Positive dependency context required (fail-closed): lightweight "section": { state is tracked from added AND context lines (the same current-block state shape as lockfile-drift.ts's package-lock parser) and reset at every hunk boundary so state never leaks across discontinuous hunks. A line is judged ONLY when its enclosing block is a visible dependencies/devDependencies/peerDependencies/optionalDependencies header — inside one, every entry is classified with no suppression, so a real dependency literally named npm, node, or vscode with a loose range is still flagged. Inside any other visible block (engines, publishConfig, scripts, …) nothing is a dependency, so the legitimate and extremely common "node": ">=18" in engines never fires. When a hunk starts mid-block with no section header in view, the analyzer stays silent rather than guessing — a hunk starting mid-engines or mid-scripts must not report "some-engine": "*" or "releaseTag": "latest" as a dependency, and for an advisory brief a wrong finding costs more than a missed one (the same no-findings-on-uncertainty posture as the sibling analyzers).
• Pinned/caret/tilde ranges, bounded ranges (>=1 <2), non-latest dist-tags, and workspace: protocol specifiers are never flagged. Findings capped (maxFindings: 20) per file and globally.

Registration

Registered as a local descriptor (category supply-chain, cost local, requires ["files"]) with an inline render(), following the testRatio/migrationSafety descriptor shape. All wiring updated: types.ts (LooseRangeFinding + looseRange? key), render.ts, analyzer-registry.test.ts, root src/review/enrichment-analyzer-names.ts, root test/unit/enrichment-wire.test.ts, and the generated analyzer-metadata.json / rees-analyzers.ts / .env.example via node scripts/generate-analyzer-metadata.mjs.

Tests

review-enrichment/test/loose-range.test.ts (15 tests) covers: each loose kind via classifyRange (including x/X wildcards, > as well as >=, and 18.x.x), pinned/caret/tilde/bounded/minor-given/dist-tag/workspace: specifiers not flagged, npm: alias unwrapping, each kind end-to-end with exact file/line locations inside a visible dependencies block, non-range manifest values not flagged, a dependency literally named npm/node/vscode still flagged inside a visible dependencies block (the name-collision regression), entries inside a visible engines/publishConfig block never flagged, a hunk with NO visible section header staying completely silent — including "some-engine": "*" and "releaseTag": "latest" shapes (the fail-closed regression), section state reset at hunk boundaries with context-line tracking, removed/context lines ignored for classification, line-number accuracy across mixed hunks, the per-file cap + maxFindings: 0, the entrypoint's package.json-only gating + global cap across files, the no-files case, and the rendered brief section. Analyzer metadata is regenerated and committed.

[superagent-security]

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

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-04 22:12:34 UTC}

11 files · 1 AI reviewer · no blockers · readiness 62/100 · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This adds a local looseRange analyzer, wires it into the descriptor registry, rendered brief, metadata, UI docs, env examples, and analyzer-name allowlist, with focused tests covering the core range classification and patch scanning behavior. The implementation is coherent with the line-based local analyzer pattern and intentionally fails closed when a package.json hunk lacks visible dependency-section context. I do not see a reachable correctness break in the visible diff; the main remaining points are test precision and small hardening gaps around claimed edge cases.

Nits — 6 non-blocking

• nit: review-enrichment/test/loose-range.test.ts:131 names the removed/context-line behavior, but the fixture has no visible dependency section, so it does not actually prove loose context or removed dependency entries are ignored once section state is active.
• nit: review-enrichment/src/analyzers/loose-range.ts:67 patchLines yields a trailing empty logical line for newline-terminated patches, which is harmless today but makes the line-counter helper easier to misuse later.
• nit: review-enrichment/test/loose-range.test.ts:139 covers section reset and context-derived state, but there is no direct regression test for the comment at review-enrichment/src/analyzers/loose-range.ts:98 that an in-hunk +++ line is treated as added content rather than a diff file header.
• In review-enrichment/test/loose-range.test.ts:131, add a fixture with a visible context or added "dependencies" header, then include a removed loose entry, a context loose entry, and an added pinned entry so the test exercises the stated invariant on the real dependency path.
• In review-enrichment/src/analyzers/loose-range.ts:67, consider changing patchLines to avoid yielding the synthetic final empty line after a terminal newline, or add a short test documenting that it is intentionally ignored.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2036
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
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: 418 registered-repo PR(s), 255 merged, 7 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jaso0n0818; Gittensor profile; 418 PR(s), 7 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: jaso0n0818
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 418 PR(s), 7 issue(s).
• Related work: Titles/paths share 7 meaningful terms. (issue #2017, issue #2019)
• Related work: Titles/paths share 7 meaningful terms. (issue #2017, issue #2021)
• Related work: Titles/paths share 7 meaningful terms. (issue #2017, issue #2028)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Review top overlaps.
• Add a concise scope and risk note.
• Await review-lane availability.
• Refresh registry data or choose a registered active repo.
• 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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.10%. Comparing base (7e17234) to head (78e3ea6).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3241   +/-   ##
=======================================
  Coverage   94.10%   94.10%           
=======================================
  Files         274      274           
  Lines       30092    30092           
  Branches    10985    10985           
=======================================
  Hits        28319    28319           
  Misses       1127     1127           
  Partials      646      646           

Files with missing lines	Coverage Δ
src/review/enrichment-analyzer-names.ts	100.00% <ø> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

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