fix(hosted): honest warnings for pnpm/yarn/bun and CRLF locks - #182

Problem

Four warning-hygiene defects in the hosted redirect rewriters (audit 2026-08-13, crates/socket-patch-core/src/patch/redirect/mod.rs) made the warnings channel noisy or misleading — the same channel that carries the module's real signals (berry cache refusals, entry-not-found):

1. Spurious redirect_npm_no_lockfile on every pnpm/Rush project (mod.rs:174): rewrite_npm_lock warned "no package-lock.json / npm-shrinkwrap.json present" whenever its own lock was absent, with no regard for the sibling pnpm-lock.yaml (root or Rush common/config/rush/) that was successfully rewritten. A fully green Rush hosted run always carried the bogus warning in both --json warnings[] and human stderr.
2. Same spurious warning on every yarn/bun-only scan (mod.rs:177): all yarn/bun deps are ecosystem "npm", so every hosted scan of a pure yarn or bun project emitted the noise even on complete success — training CI users to ignore warnings.
3. Berry CRLF misdiagnosis (mod.rs:852): a CRLF yarn berry lock (which yarn itself parses fine) collapses the \n\n block grammar, so berry_cache_key returned None and the refusal claimed cacheKey is `(missing)` — even though the lock's cacheKey IS 10c0. Windows-checkout users were sent chasing yarn cache/compression config instead of line endings.
4. pnpm CRLF misdiagnosis (mod.rs:698): the pnpm rewrite pattern anchors on ):\n, which never matches CRLF lines, so a Windows-normalized pnpm-lock.yaml surfaced per-dep as a misleading redirect_pnpm_entry_not_found ("no inline resolution for X") though the entry exists.

Concrete failing scenario: scan --mode hosted --json on a pnpm-only project with one granted patch returned redirected: 1 with warnings: ["redirect_npm_no_lockfile", "redirect_pnpm_trust_lockfile"] — a fully successful run flagged with a lockfile complaint about a file the project should not have.

Fix

Warning hygiene only — zero behavior change to rewrites (CRLF locks were already never rewritten; they were only misdiagnosed).

• rewrite_npm_lock now emits redirect_npm_no_lockfile only when NO npm-family lockfile is present at all: a sibling yarn.lock, bun.lock/bun.lockb, or pnpm-lock.yaml (root or nested Rush) suppresses it, since that lock's own rewriter carries the per-dep diagnostics (findings 1+2 are the same defect at one boundary and share this fix). A genuinely lockfile-less project still warns, unchanged.
• rewrite_yarn_berry detects CRLF content before the cacheKey gate and refuses with a new redirect_yarn_berry_crlf_unsupported warning naming the line endings and the LF remedy — same fail-closed outcome, honest diagnosis. Placed after the __metadata: berry-detection gate, so CRLF classic locks are untouched by this code (classic CRLF handling is a separate audit lane: classic-hosted-crlf, deliberately not addressed here).
• rewrite_pnpm_lock skips each CRLF lock up front with a new per-file redirect_pnpm_crlf_unsupported warning naming the lock path, instead of the per-dep entry-not-found; if no LF lock remains it returns before the dep loop. Mixed CRLF+LF lock sets proceed on the LF locks unchanged.

New warning codes: redirect_yarn_berry_crlf_unsupported, redirect_pnpm_crlf_unsupported — both fail-closed refusals.

Testing

• New rewriter unit tests (in redirect/mod.rs): exact-empty warning set on clean npm and pnpm success; redirect_npm_no_lockfile gating across yarn-only, Rush-nested-pnpm-only, and lockfile-less projects; CRLF berry lock with cacheKey: 10c0 diagnosed as exactly redirect_yarn_berry_crlf_unsupported with no rewrite; CRLF pnpm v9 lock diagnosed as exactly redirect_pnpm_crlf_unsupported (naming the file) with no rewrite.
• New subprocess --json envelope test (in_process_redirect.rs): clean_success_warning_set_is_exact_for_npm_and_pnpm pins the EXACT warning set (npm success = empty; pnpm success = exactly redirect_pnpm_trust_lockfile). Independently verified RED against pre-fix code by the reviewer: the pre-fix envelope carried ["redirect_npm_no_lockfile", "redirect_pnpm_trust_lockfile"].
• Suites green: cargo test -p socket-patch-core --lib patch::redirect (59 passed), cargo test -p socket-patch-core --test redirect_golden (1 passed), cargo test -p socket-patch-cli --test in_process_redirect (24 passed), cargo test -p socket-patch-cli --test in_process_redirect_pnpm (3 passed).
• The pre-existing lockfile-less human-mode test (redirect_human_mode_prints_rewriter_warnings) still passes — the warning still fires when no npm-family lock exists.

No skipped findings in this lane.

🤖 Generated with Claude Code