docs(review): correct lockfile-tamper.ts's module header to state its npm-only scope

[galuis116]

Summary

• src/review/lockfile-tamper.ts's module-level doc comment claimed the check scans "a changed package-lock.json (or another *.lock file) diff" — but isNpmLockfilePath, the function that actually decides what gets scanned, matches only basename === "package-lock.json"; yarn.lock, pnpm-lock.yaml, and any other *.lock file are never scanned, exactly as isNpmLockfilePath's own accurate doc comment already states.
• Corrects the module header to state the npm-only scope, aligning it with isNpmLockfilePath's own correct comment. Doc-only change — no behavioral diff. Does not extend lockfile parsing to yarn/pnpm (explicitly out of scope per the issue).

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves.

Closes #6997

Validation

• git diff --check
• npm run actionlint
• npm run typecheck — the whole-repo tsc --noEmit reliably OOMs on this shared, memory-constrained sandbox regardless of what changed; this is a comment-only change with zero behavioral surface, so npx vitest run test/unit/lockfile-tamper.test.ts (below) is sufficient local confidence, and CI's isolated runner performs the authoritative tsc --noEmit.
• npm run test:coverage — test/unit/lockfile-tamper.test.ts (28 tests, including the existing isNpmLockfilePath coverage of yarn.lock/pnpm-lock.yaml rejection the issue calls out as the acceptable no-op assertion) — 28/28 passing, unmodified.
• npm run test:workers / npm run build:mcp / npm run test:mcp-pack / npm run ui:openapi:check (not applicable — this is a single comment change in one backend module)
• npm audit --audit-level=moderate (no dependency changes)
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries. (N/A — doc-only change; the issue itself states no new test is required, and the existing isNpmLockfilePath test suite already exercises the exact behavior the corrected comment now accurately describes.)

If any required check was skipped, explain why:

• This is a single-comment doc-accuracy fix with no code/behavior change. The whole-repo npm run typecheck OOMs on this sandbox under current memory pressure regardless of diff size, so it was not run standalone for a change with no type-surface at all; the existing, unmodified test suite plus CI's isolated runner cover the rest.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A — no auth/cookie/CORS/session changes.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (N/A — no API/OpenAPI/MCP changes.)
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. (N/A — no UI changes.)
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots. (N/A — no UI changes.)
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

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

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7039   +/-   ##
=======================================
  Coverage   93.74%   93.74%           
=======================================
  Files         692      692           
  Lines       68740    68740           
  Branches    18768    18768           
=======================================
  Hits        64443    64443           
  Misses       3302     3302           
  Partials      995      995           

Flag	Coverage Δ
shard-1	43.35% <ø> (-0.45%)	⬇️
shard-2	36.90% <ø> (+0.05%)	⬆️
shard-3	33.15% <ø> (-0.21%)	⬇️
shard-4	34.40% <ø> (+0.50%)	⬆️
shard-5	31.70% <ø> (-0.52%)	⬇️
shard-6	46.04% <ø> (+0.27%)	⬆️

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

Files with missing lines	Coverage Δ
src/review/lockfile-tamper.ts	100.00% <ø> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-17 19:19:23 UTC}

1 file · 1 AI reviewer · no blockers · readiness 93/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a doc-only comment fix in src/review/lockfile-tamper.ts, correcting the module header to state the check only parses package-lock.json (npm), aligning it with isNpmLockfilePath's own accurate doc comment. The diff introduces no behavioral change and the correction is accurate per the actual implementation shown in the full file (isNpmLockfilePath matches only basename === "package-lock.json"). No test changes are needed since this is comment-only.

Nits — 3 non-blocking

• The new header still says 'a changed `package-lock.json` diff (npm only...)' but doesn't explicitly restate that lockfileVersion 1 legacy format is also covered per the bare-name fallback logic further down in the file — worth a one-clause mention for completeness.
• Consider linking directly to issue lockfile-tamper.ts module header claims broader lockfile support than isNpmLockfilePath actually provides #6997 in the comment (similar to the existing feat(gate): add a lockfile-tamper-risk check #2563/feat(gate): add a lockfile-tamper-risk check #2676/fix(review): stop false-positiving on transitive bumps and workspace links #2692 references) so future readers can trace why the header was corrected.
• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.

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	#6997
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: 1962 registered-repo PR(s), 1288 merged, 52 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	galuis116; Gittensor profile; 1962 PR(s), 52 issue(s).
Improvement	ℹ️ None detected	risk: low · value: none

Review context

• Author: galuis116
• 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: 1962 PR(s), 52 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

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.