Structure-review batch: sweep fixes, module taxonomy, npm-family dedup, coverage gaps, CI honesty by mikolalysenko · Pull Request #150 · SocketDev/socket-patch

Mikola Lysenko (mikolalysenko) · 2026-08-10T17:35:20Z

Summary

The complete 2026-08-10 structure-review implementation as one PR (consolidates and replaces #151–#155, which are closed in its favor). Ten commits, reviewable in order — each was independently verified before folding in:

1–2. The 2026-07 review-sweep, landed at last (fix: ×2): the 66-file bug-fix + test-harness sweep rebased onto main, plus the four fixes its own RED regression tests were pinning without: scan --redirect human mode printed JSON-quoted values; detect_updates was blind to percent-encoded/artifact-qualified manifest keys (scoped packages never reached updates[]); the vendor reconcile's on-disk ledger mutation was invisible to JSON consumers when staging failed afterward (the step error now carries the envelope); CARGO_HOME="" resolved registry/src against the CWD and silently crawled nothing. Also in the sweep: the nested-apply fix (get no longer drops --api-token/--api-url/--org/--proxy-url on its internal apply).

3–6. Module taxonomy (refactor(core): ×4): patch/vendor/ (34 files, ~47% of core) promoted to top-level vendor/; the strays rehomed (bun_lock_text, go_mod_edit → vendor/; go_redirect → patch::redirect::golang_local); the generic TOML helpers extracted from the pypi hook into utils::toml_edit_ext; the utils/ misfiles dissolved (telemetry → top level, cleanup_blobs → manifest/, date → api/, fuzzy_match → crawlers/). Old paths keep compiling via pub use shims for external consumers of the published core crate; internal references are repointed, and a CI grep step rejects new internal uses (#[deprecated] on re-exports emits no warnings — rust-lang/rust#30827). Commit 3 is a pure-rename commit: if squash-merging, please add the squash SHA to .git-blame-ignore-revs.

7. Setup umbrella (refactor(core):): gem_setup/composer_setup/pth_hook — four naming schemes for one concept — unified as setup/{gem,composer,pypi} plus a thin setup::npm alias over package_json's setup surface (package_json stays top-level: it doubles as the shared npm-manifest library).

8. npm-family knowledge dedup (refactor(npm):): a structured role-flag table in constants::npm_family (sites accept intentionally divergent subsets, so a flat list can't serve them), equality drift-guard tests beside each consumer, PnP-marker and Rush-lock-path dedup, an exhaustive package-manager match in apply, and deno.lock's absence recorded as a decision.

9. CI honesty (ci:): the test/test-release jobs build --all-features --no-run but run default features, so the docker-e2e/setup-e2e suites stop reporting dozens of soft-skip fake greens per OS leg (they keep executing for real in e2e-docker/setup-matrix).

10. Coverage gaps (fix(setup,scan):): setup --exclude fails closed on a corrupt manifest instead of rewriting it down to a bare setup block (bytes-unchanged, RED-verified); scan --redirect --json emits a parseable error envelope on all four failure exits instead of empty stdout (RED-verified); 7 unit tests for the previously-untested fetch_stage.rs download planner.

Verification

Full workspace suite on the consolidated head: 164 test binaries green; the only 2 failures are the live-API composer tests hitting the current patches-api.socket.dev 503 "Service temporarily over capacity" production incident (same tests were green this morning; same 503 failed this PR's earlier CI runs — infra, not code).
cargo clippy --workspace --all-targets -- -D warnings clean, cargo fmt --check clean, alias-path grep guard clean.
Every RED-first test was verified red against the unfixed code before its fix landed.

🤖 Generated with Claude Code

Bug fixes - scan --prune now exempts manifest entries whose ecosystem this run never crawled: an unknown `pkg:<type>/` (a newer CLI's ecosystem in a committed, shared manifest) and the runtime-gated maven/nuget crawlers with their gate off. Absence from a crawl that never looked is not evidence of removal, so pruning them silently deleted a teammate's patch plus its blobs. - get: thread --api-token/--api-url/--org/--proxy-url into the nested apply. They were dropped, so a token supplied purely as a flag fell through to the token-less public proxy — against the wrong host, with the wrong client. - redirect: write the managed `[registries.…]` block into the legacy extensionless `.cargo/config` when a project carries it. Cargo reads that spelling in preference to `config.toml`, so the block was landing in a file cargo ignores while the run still reported the dep redirected. - rollback: fall back to dropping the go.mod `replace` + `.socket/go-patches/` copy for a local-mode go patch whose module the crawler cannot find. - crawlers: composer reads `installed.json` through `open_regular_file` (a planted FIFO no longer hangs scan/apply forever); maven treats an empty MAVEN_REPO_LOCAL/M2_HOME as unset; nuget matches `nuget.config` / `packages.config` case-insensitively; python scans the macOS `osx_framework_user` user-install root; ruby's local-mode fallback returns every gem home `gem env` reports (not just `gemdir`) and accepts the alternate `gems.rb`/`gems.locked` Bundler spelling. - setup: `--exclude` trims CSV whitespace and covers the excluded directory's whole subtree; `finalize_gem` forwards an absolutized --manifest-path. - update: non-fatal advisories ride the envelope's run-level `warnings[]`, so a `--json` run no longer silently swallows a managed-install override. - vex: git-config parsing matches git itself (case-insensitive names, BOM tolerance, whitespace before a quoted subsection). - lib: `--update=<VERSION>` (inline `=` spelling) is recognized, and a `--update` after `--` is correctly left as an escaped operand. Test harness / CI - New [profile.ci-release] (release minus the full-LTO link) for test-release, and dependency opt-levels raised in the dev profile — the self_update fixtures gzip and sha256 a multi-MB binary per test at opt-level 0. Workspace members stay at opt-level 0, so llvm-cov line fidelity and debug experience are unchanged. - CI: per-job timeout-minutes, and a concurrency group that supersedes stale runs while never cancelling main (main is the only rust-cache writer). - The two wall-bound real-package-manager redirect capstones are #[ignore]-gated out of the serial `test` job and relocated to the parallel e2e matrix, which runs `-- --ignored` on all three OSes. Same coverage, off the critical path. - Drop the unused testcontainers dev-dependency (-1001 Cargo.lock lines). - Many new invariant/e2e suites: scan, apply, remove, setup, vendor, vex, crawlers, in-process redirect, CLI config fallback. Known-RED tests, gated with #[ignore] and a reason Each of these is a correct test for a real bug whose production fix is NOT in this change. They are gated rather than deleted so the finding is not lost: apply_lock waiter/orphaned-inode (two simultaneous holders of the "exclusive" apply lock), apply's manifest_unreadable fail-closed arm, the telemetry --api-url/--proxy-url env mirror (on-prem token egress), composer.json setup mode preservation (one-line fix: use atomic_write_bytes_preserving_mode), pnpm `node-linker=pnp` detection, pnpm workspace flow-sequence parsing, apply's cached-package-archive fallback, remove's ledger-generation match, and the yarn-PnP refusal scoping (its counter-guard stays live). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issues.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit f41b2d6. Configure here.}

…treat empty CARGO_HOME as unset Two more fixes the sweep's own RED regression tests were pinning: * scan --vendor --json: reconcile_dropped mutates the on-disk ledger BEFORE staging, but a staging failure returned Err without the envelope — the JSON consumer saw only the error object and never learned entries had been reverted on disk. The step error now carries the envelope built so far and the JSON fold attaches it as `vendor`. (Human mode prints no per-event lines even on success; unchanged.) * cargo crawler: CARGO_HOME="" hit PathBuf::from("") and resolved registry/src against the CWD, silently crawling nothing. Empty now means unset (env_non_empty convention), falling back to ~/.cargo. Pinned by scan_vendor_staging_error_still_reports_the_reconcile and empty_cargo_home_falls_back_to_home_dot_cargo. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Pure move, no logic changes. patch/ was 63% of the crate but only ~11% patch engine; the vendoring + lockfile-rewriting subsystem it contained (34 files, ~47% of core) is the crate's real center of mass and now lives at crate::vendor. The npm-family strays move with it (bun_lock_text, go_mod_edit), and the project-local Go replace-redirect backend joins the other rewiring code as patch::redirect::golang_local. Old `patch::*` paths keep compiling through re-export shims for external consumers of the published crate; internal references are repointed in the follow-up commit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…e paths Mechanical: patch::vendor → vendor, patch::go_mod_edit → vendor::go_mod_edit, patch::bun_lock_text → vendor::bun_lock_text, patch::go_redirect → patch::redirect::golang_local, across both crates and tests. The patch::* re-export shims stay for external consumers of the published core crate, but #[deprecated] on a pub use emits no warnings (rust-lang/rust#30827), so a CI grep now rejects new internal uses of the alias paths. The bun_lock_text shim is dropped outright: it was pub(crate) before the move, so no external consumer could name it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

ensure_table / has_table were defined inside the pypi setup backend (pth_hook) but consumed by vendor::cargo_config, vendor::pypi and vendor::pypi_uv — the pypi hook module owned the crate's generic structured-TOML seam. Move both (verbatim) to utils::toml_edit_ext and repoint the five callers. Unblocks folding pth_hook under a future setup/ umbrella without dragging vendor dependencies along. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Mechanical moves with compat re-exports left in utils/ for external consumers of the published crate (internal paths repointed, CI grep-guarded like the vendor promotion): * utils/telemetry.rs -> src/telemetry.rs — a 1k-LOC subsystem, not a leaf helper * utils/cleanup_blobs.rs -> manifest/cleanup_blobs.rs — imports manifest::operations/schema; it is manifest-domain blob GC * utils/date.rs -> api/date.rs — parses the API's RFC-2822 wire dates * utils/fuzzy_match.rs -> crawlers/fuzzy_match.rs — depends on crawlers::types utils/ keeps the genuine leaves: fs, env_compat, http, process, purl, serde, socket_cli_config, toml_edit_ext, uri. Also: vendor/state.rs flavor docstring gains the missing yarn-berry (npm_flavor emits and revert-routes it; the doc list had drifted). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Four naming schemes for one concept, now one umbrella: gem_setup -> setup::gem, composer_setup -> setup::composer, pth_hook -> setup::pypi, plus a thin setup::npm alias re-exporting package_json's setup-facing surface. package_json itself stays top-level: it doubles as the crate-wide shared npm-manifest library (crawlers and vendor parse package.json through it), which is exactly why it never fit under a setup umbrella wholesale. Pure git-mv moves — the pypi backend's generic TOML helpers were already extracted to utils::toml_edit_ext, so nothing vendor-shaped rides along. Old top-level paths keep compiling through lib.rs aliases for external consumers of the published crate; internal references are repointed and the CI alias-path grep now rejects the three old paths. The shared per-backend Status enum the four modules' docs describe informally is deliberately NOT introduced here: their status semantics differ subtly (gem template regeneration), and unification is a behavior decision, not motion. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…drift-guard tests The npm-family package managers spell their shared knowledge across four subsystems, each with its own list — and those lists accept INTENTIONALLY divergent subsets (hosted redirect deliberately omits bun.lockb; the pnpm-lock.yml spelling is setup-detection-only), so a flat shared list cannot serve them. Instead constants::npm_family now holds a structured row table (name x per-consumer role flags) plus the genuinely shared literals, and each consumer keeps its own shape guarded by an equality test against its role: * vendor::npm_flavor: probe families == rows flagged vendor_probe; local PNP_MARKERS deduped onto the shared const (same set the crawler probes — a past-divergence risk, now one definition) * scan::hosted: REDIRECT_CANDIDATE_FILES' npm-family subset == rows flagged redirect_candidate, both directions, so bun.lockb's deliberate absence is pinned as deliberate * package_json::find: detection iterates rows flagged detects_pnpm (behavioral pin per spelling, incl. pnpm-lock.yml) * crawlers::pkg_managers: PnP probe uses the shared PNP_MARKERS * Rush's common/config/rush/pnpm-lock.yaml literal (3 code sites) is now RUSH_COMMON_LOCK_REL Also: apply's package-manager match is exhaustive (a 7th layout must make an explicit appearance instead of falling into the wildcard), and deno.lock's absence from the npm-family lists is recorded as a decision in the table and the hosted candidate list. Not attempted here, deliberately: unifying the three PM enums (they answer different questions), merging redirect's pnpm regex grammar onto vendor's parser (intentionally different version envelopes), and the setup PackageManager Yarn/Bun widening (a product decision on hook commands, its own PR). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The test and test-release jobs ran `cargo test --workspace --all-features`, which also RUNS the feature-gated docker-e2e and setup-e2e suites. Those tests soft-skip as "ok" when no socket-patch-test images exist — which is always true in these jobs (no images are built there; macOS/Windows have no Docker at all). Every OS leg therefore reported dozens of fake green tests, and a broken skip-guard would disable a whole suite while CI stayed green. Split build from run: --all-features --no-run keeps the compile-rot coverage for the gated suites, the run step uses default features only. The dedicated e2e-docker and setup-matrix jobs remain the places where the gated suites actually execute. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…every hosted failure; fetch_stage unit tests Three coverage gaps from the 2026-08-10 structure review, each with the test that pins it: * setup --exclude persistence clobbered a corrupt manifest: persist_setup_excludes flattened a read/parse error to "no manifest yet" and rewrote the file as a bare setup block, destroying every patch record a merely-corrupt manifest still held. Now fails closed (skip persistence, warn on stderr, manifest bytes untouched). RED test: exclude_persistence_fails_closed_on_corrupt_manifest. * scan --redirect --json emitted empty stdout on every failure exit (discovery-detail failure, reference-resolve failure, file/ledger write failure) — exit 1 with nothing to parse. All four bail-outs now emit the machine-readable error envelope (status/error mirror the success envelope's error fold). RED test: redirect_json_mode_failures_emit_error_envelope. * fetch_stage.rs (the offline-guard-critical download planner) had zero direct tests. In-src unit tests now pin: the read-only-.socket contract, in-place staging when fully cached, the diff-archive disk-vs-vendor staging asymmetry both module docs describe, overlay promotion for late downloads, overlay_dir semantics, and the bad --download-mode hard failure. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ken by the setup/ move Two CI reds from the consolidated branch's first run, plus doc-path rot: * e2e_composer's scan tests were designed offline ("the package count is derived from the local crawl") but implicitly called the LIVE public proxy — their exit-0 assumption dated from before the all-batches-failed fix made total API failure exit non-zero, so any production hiccup (like today's patches-api 503 "over capacity" incident) failed the test, coverage and test-release jobs on every OS. Now pinned to an in-test wiremock proxy with the same harness shape as e2e_nuget/e2e_gem (empty no-patch result, env scrub, spawn_blocking, request-count hermeticity guard). e2e_embedded_vex audited too: its scans find zero packages, so no API call fires — left as is. * lint-ecosystems ruby-checked the gem templates at their pre-move path; the setup/ umbrella relocated them to src/setup/gem/templates/ and the Rust-path CI grep could not catch a filesystem path in a workflow. Also: release.yml's gem_setup comment and CLI_CONTRACT.md's src/patch/vendor/ references updated to the new module homes (the only stale non-Rust references a repo-wide sweep found). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

macOS debug builds use unpacked split-debuginfo: every linked binary — including each of the ~90 e2e test executables — pins its per-codegen-unit .o files in target/debug/deps, and cargo never garbage-collects the generations superseded by lockfile/toolchain bumps; this grew a single worktree's target/ to 99 GB. Line tables keep panic backtraces readable while dropping the bulk of the retained DWARF; for a full-fidelity debugger session, override with CARGO_PROFILE_DEV_DEBUG=full. Applies to the test/bench profiles via inheritance. (Authored during the 2026-08-10 disk-space cleanup; folded into this branch at the owner's request.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Mikola Lysenko (mikolalysenko) · 2026-08-11T16:08:34Z

Two commits appended addressing this PR's CI reds plus the disk-space work:

fix(ci,test) — the test/coverage/test-release reds were e2e_composer's scan tests: designed offline, but implicitly calling the live public proxy, so yesterday's patches-api.socket.dev 503 incident failed them on every OS. They're now pinned to an in-test wiremock proxy (same harness shape as e2e_nuget/e2e_gem, with the request-count hermeticity guard). The lint-ecosystems red was the gem templates being ruby-checked at their pre-setup/-move path — fixed, along with the two stale non-Rust path references a repo-wide sweep found (release.yml comment, CLI_CONTRACT.md).
build — dev-profile debuginfo capped at line tables ([profile.dev] debug = "line-tables-only"): macOS unpacked split-debuginfo was pinning per-codegen-unit .o files for ~90 e2e binaries and grew a single worktree's target/ to 99 GB. Override with CARGO_PROFILE_DEV_DEBUG=full when a debugger session needs full DWARF.

Remaining known red: hosted-e2e depends on production health — patches-api.socket.dev is still degraded (TLS accepts, requests hang) as of this push. That job is the deliberate prod-drift sensor; rerun it once the incident resolves. Everything else was verified locally under the new profile: clippy -D warnings clean, fmt clean, composer/vex/redirect/setup suites green.

… status, dead Err plumbing removed — with the pins the review demanded Review follow-ups (2026-08-11 ULTRACODE pass over #150): * detect_updates: the qualifier-stripped fallback did HashMap iter().find(), so qualifier TWINS (one package under two artifact-pinned manifest keys, e.g. a pypi wheel+sdist pair) resolved to a per-process-random record. Now: any stale twin means an update; twins scan in sorted-key order and the first differing one names old_uuid — deterministic across runs. New pins: the qualifier-bridge leg (previously only percent-encoding was tested) and the twin cases (stale twin wins over 16 iterations; all-twins- current stays quiet). * scan --vendor --json: the envelope carried into the staging-error fold is now demoted to partialFailure before the carry — a consumer reading .vendor.status inside a "status":"error" result saw the fresh-envelope default "success". Pinned in scan_vendor_step_error_e2e. * stage_vendor_sources_in_memory returns MemStageOutcome directly: it never constructed Err, so the Result wrapper bred statically-dead stage_failed arms in three callers (scan flow, vendor, repair_vendor) — all removed. * Hosted --json write-failure bail-outs (legs 3-4: unwritable lockfile, directory squatting on the revert-ledger path) get the envelope test the 882cdb7 commit message claimed — driven with real filesystem obstructions, cross-platform via set_readonly. * get nested apply: a token-less --proxy-url-only leg. The two authenticated legs could not catch a dropped proxy_url (the client consults it only on the token-less branch); this leg goes red for exactly that regression. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The fail-closed skip on a corrupt manifest only warned on stderr behind !silent: a --json consumer saw a fully-successful setup whose excludes silently evaporate on the next flag-less run, and --silent left no trace at all. persist_setup_excludes now returns the warning and run_setup folds it into the run's warnings channel — human summary line and the --json envelope's warnings array. --silent stays quiet by contract ("errors only") and is now PINNED as a decision: the silent leg asserts suppression AND that fail-closed still holds byte-identically. Known edge left as-is: a corrupt manifest in a project with zero hook files exits through report_no_files before warnings assemble. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…k the pnpm-pin self-reference, truth the table doc * BUN_MIGRATE_CMD had zero call sites while its doc claimed it was spliced into every message — deleted; the four messages keep their literals (the executed bun argv lives separately anyway, so the const single-sourced nothing). * npm_flavor's vendor_rush_unsupported message now formats RUSH_COMMON_LOCK_REL instead of hardcoding the path twice — the third code site the original commit claimed but did not wire. * find.rs gains a hardcoded pnpm-spelling pin: production code and the guard test iterated the identical names_with(detects_pnpm) expression, so a deleted table row shrank both together while .yml detection silently vanished. * The npm_family module doc now states exactly which consumers are guard-tested and which are behaviorally pinned instead (pkg_managers' own lockfile literals, the probe's decision literals) — it previously promised per-consumer guards it did not have. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…pt removal preserves quoted && bytes * vex's three track_vex_* sites passed the raw --api-token/--org flags, so a `socket login`-only user attributed vex telemetry anonymously — the exact gap list/setup closed in the sweep (the long-standing "vex.rs telemetry raw-flags twin"). All three now resolve through list::telemetry_credentials (flag / env / socket-cli config.json). * remove_socket_patch_from_script kept survivors via trim+canonical " && " rejoin, which rewrote a && INSIDE a quoted argument of a surviving user command: `grep "a&&b"` came back as `grep "a && b"` — a different pattern, not the "cosmetic" respacing the docstring claimed. Survivors are now spliced out of the original text verbatim (inner spacing included); only seams next to removed segments collapse. All eleven existing removal pins hold unchanged; two new tests pin the quoted-&& and inner-spacing preservation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Mikola Lysenko (mikolalysenko) · 2026-08-11T20:43:25Z

Four follow-up commits from the adversarial review of this PR's own diff (every finding independently verified against the code before fixing):

fix(scan,vendor) — detect_updates now resolves qualifier-twin manifest keys deterministically (any stale twin ⇒ update, sorted-key order; was HashMap-order random), the envelope carried into the staging-error fold is demoted to partialFailure (consumers no longer read "vendor":{"status":"success"} inside an error result), and the never-constructed Err plumbing on the in-memory stager is gone along with three statically-dead stage_failed arms. New pins: qualifier-bridge + twin determinism units, hosted --json envelope on the two write-failure bail-outs (the commit that added them claimed "all four" but tested two), and a token-less --proxy-url nested-apply leg that actually goes red if proxy_url forwarding is dropped.
fix(setup) — a skipped (fail-closed) --exclude persistence now rides the warnings channel into the --json envelope; --silent suppression is pinned as a decision, with fail-closed still holding byte-identically.
refactor(npm) — dead BUN_MIGRATE_CMD deleted, the Rush refusal message wired to RUSH_COMMON_LOCK_REL (the claimed-but-unwired third site), a hardcoded pnpm-spelling pin breaking the guard's self-reference, and the table doc now states exactly what is guard-tested vs behaviorally pinned.
fix(vex,setup) — vex telemetry resolves credentials through the layered chain (flag/env/socket-cli config) like list/setup, closing the long-standing raw-flags twin; and script removal now preserves quoted && bytes in surviving user commands (grep "a&&b" no longer comes back respaced as a different pattern).

Verified: clippy -D warnings clean, fmt clean, 347 CLI + 2068 core lib tests green, all touched integration suites green.

…m image (#156) * .git-blame-ignore-revs (new): the #150 squash merge contains the pure-rename taxonomy moves plus ~50 files of mechanical import repoints — exactly the churn blame should skip. The PR body deferred this to post-merge since the squash SHA only exists now. * Dockerfile.npm: bun's install script downloads the release zip from GitHub with no retry, and a single transient CDN drop ("curl: (56) Connection died") failed the whole coverage-docker (npm) image build on the first post-merge main run. Three attempts with backoff. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

… digest, project-scoped stamp The generated Bundler setup plugin could deadlock a project on its own bootstrap, its design comment described trigger behavior bundler does not have, and its digest stamp was a machine-global file blind to the actual gem-file state. All trigger claims below were re-derived empirically against real bundler 4.0.15 (host) and 2.7.2 (docker image). plugins.rb template (+ published socket-patch-bundler twin): - [P0] bootstrap deadlock: bundler evaluates plugins.rb at plugin REGISTRATION, before any project gem is installed; the load-time SocketPatch.apply! got apply's exit 1 ("No packages found") and raised Bundler::BundlerError, so the FIRST `bundle install` of every fresh clone of a setup-wired project died (exit 29 under 4.0.15, exit 1 under 2.7) and every retry failed identically (registration never completed). Patch failures now warn once per process — naming what failed and the manual remediation — and let the install continue; SOCKET_PATCH_STRICT=1 restores the raise. The load-time and per-gem triggers are additionally stamp-gated so the bootstrap install stays quiet and defers to the forced after-install-all pass. - [P1] trigger reality: the header claimed plugins.rb runs during the Gemfile pass "on EVERY bundle invocation" — false; bundler evaluates a plugin when a subscribed hook event first fires. Measured surface (identical on 2.7 and 4.0): every `bundle install` — fresh AND fully cached — fires before/after-install(-all); `bundle pristine` fires ONLY the per-gem events; `bundle exec`/`bundle check`/`gem pristine` fire nothing. The plugin now also subscribes `after-install` (digest+stamp-gated), which catches `bundle pristine`'s patch reversion in the same run, and the digest folds in the on-disk CONTENT of every gem-patch target (resolved from the manifest purls under Bundler.bundle_path/gems), recomputed after apply — so out-of-band reversion flips the digest even when every committed input is byte-identical. Header documents precisely which flows re-apply and which cannot, including the stale .bundle/plugin/index caveat for checkouts registered by an older plugin version. - [P2] stamp location: the digest stamp was a fixed-name file under Bundler.bundle_path — the interpreter's machine-global gem dir when no bundle path is configured, shared and clobbered across every socket-patch project on the host. It now lives at .socket/gem-plugin-stamp (project-local, excluded from its own digest inputs); the legacy global stamp is deleted best-effort and never read. launcher.rb (gem/socket-patch): - Windows arm now propagates the child's real exit code instead of collapsing every non-zero exit to 1. - the binary-cache install is atomic: staged as a temp file in the destination dir, chmodded, then renamed into place (cross-run race on Windows rename tolerated when the winner already published). - first-run failures outside LauncherError exit with a clean one-line message instead of a raw backtrace; the PowerShell Expand-Archive fallback quotes paths containing single quotes; `version`'s documented from-a-checkout fallback never engaged because Gem::MissingSpecError is a Gem::LoadError (ScriptError family), not a StandardError — found by the new launcher guard. - socket-patch-bundler.gemspec: stale `git:` comment corrected to `path:` (the source has been path: since #150). setup-matrix driver (gem-scoped, npm-family byte-identical — verified by diffing the fixtures the old and new driver produce for npm across all patchsets): - the gem fixture now serves the REAL git-blob beforeHash probed from the published .gem (`gem fetch` + `gem unpack`, mirroring docker_e2e_gem's probe; verified against an independent oracle), so hash-gated gem apply passes the variant gate without --force. With the deadlock fix this turns the formerly-gapped gem with-setup docker cases green: the full 6-case gem matrix passes in BOTH host mode (bundler 4.0.15, real rubygems.org installs) and docker mode (rebuilt image, bundler 2.7) — no dependency on any sibling apply change. Tests (each red without its fix): - core template invariants: test_plugin_template_failure_policy_and_ stamp_location (new) + test_templates_are_well_formed (extended) pin the tolerant reporter, strict hatch, stamp constants, legacy cleanup, target-content digest, and the published twin's parity — 2 failures against the old template. - setup_matrix_gem::plugin_runtime drives the plugin generated by the REAL binary through REAL `bundle install` runs with a fake apply: first_bundle_install_survives_failing_apply (the P0 repro: red at exit 29 on the old template), strict_mode_fails_bundle_install_on_apply_ failure, successful_apply_stamps_project_scoped (stamp path + exactly one forced apply per cached install), digest_tracks_gem_file_content_ and_legacy_stamp_is_removed (plain-ruby drive; red on the old manifest-only digest and old stamp path). - setup_matrix_gem::launcher_guard drives launcher.rb with host ruby: windows_branch_propagates_child_exit_code (red: 7 collapsed to 1), unexpected_download_errors_exit_cleanly (red: raw backtrace), powershell_quote_doubles_single_quotes and install_executable_is_atomic_into_place (red: helpers absent). 7 of 8 runtime/launcher guards fail against the base-branch code. Verified: core 2461/0, cli lib 350/0, setup_matrix_gem 11/11 (incl. the docker-mode 6-case matrix on a fresh image AND host-mode 4.0.15 run), docker_e2e_gem 2/2, docker_e2e_vendor_gem 1/1, e2e_gem 11/11 (incl. live lifecycle), clippy+fmt clean on both crates. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

… digest, project-scoped stamp (#178) * fix(gem): bundler vendored+hosted sweep — 13 confirmed bugs fixed, tests hardened ULTRACODE review + full test matrix over the gem/bundler ecosystem (vendored and hosted modes, every configuration). 24 findings survived adversarial verification; the 13 well-scoped ones are fixed here, each pinned by a test that fails without its fix. Hosted redirect (patch/redirect/mod.rs, gem section): - splice the Gemfile edit by regex byte range: a commented-out duplicate of the gem line no longer gets rewritten instead of the live line - grant-agnostic idempotency guard: re-running scan --mode hosted with a rotated grant token refreshes the source URL in place instead of nesting a second source block (new edit kind redirect_gemfile_source_url) - fail closed on gem-level git:/github:/path:/source: options (they override the enclosing source block, making the redirect an attested no-op); warn redirect_gem_source_option and skip the dep - fail closed on platform-suffixed CHECKSUMS siblings (redirect_gem_platform_unsupported) instead of inserting a duplicate bare-coordinate pin - recognize paren/tab/multi-space gem declarations; gate the append-branch on the gem being genuinely undeclared (no more duplicate declarations bundler rejects) - never pin the lock CHECKSUMS when the Gemfile source redirect did not land (mixed state guaranteed a checksum failure) - warn that a redirected pair breaks frozen/deployment installs - record the upstream sha256 line as original on the CHECKSUMS edit so a future revert can restore it (golden fixture updated) Vendored backend (vendor/gem.rs): - insert new PATH sections at bundler's sorted position (identifier order, verified against real bundler 4.0.15 bundle lock) — two or more vendored gems no longer churn the committed lock - fail closed on platform-suffixed GEM-specs siblings on no-CHECKSUMS locks (mirrors the existing CHECKSUMS guard) - re-vendor on a patch UPDATE (new uuid, same purl): recognize our own path: wiring and rewire in place instead of refusing with gemfile_declaration_not_editable — the documented automatic re-vendor contract now actually works for gem Auto-fetch (vendor/registry_fetch.rs): - stage fetched gems into the canonical <name>-<version> leaf instead of a dir literally named "gem", which vendor_gem refused as platform_gem_unsupported — lockfile auto-fetch for gems was dead Crawler (crawlers/ruby_crawler.rs): - parse_dir_name_version prefers the last dotted-version boundary, so http-2-1.0.1 parses as (http-2, 1.0.1) instead of the ghost (http, 2) - vendor/bundle discovery enumerates engine dirs (jruby, truffleruby) instead of hardcoding ruby/ Scan/get plumbing: - run_nested_apply now threads --ecosystems: scan --ecosystems gem --sync no longer applies (or mutates) other ecosystems' patches - scan --vendor --dry-run --vex no longer writes the VEX file nor exits 1 on not-yet-vendored state Test hardening: - e2e_gem lifecycle harness: BUNDLE_PATH replaces bundle install --path (removed in bundler 3+; all 3 lifecycle tests green under 4.0.15) - e2e_hosted_production gem leg now asserts the CHECKSUMS digest CHANGED after redirect (client-verifiable today) and, in the success arm, verifies installed content against the published afterHashes — an inert gem patch can no longer stay green (the npm minimist blindspot) - docker_e2e_gem serves the true git-blob beforeHash so the chain exercises the default non-forced apply path, not just --force - setup_matrix_gem module doc: the with-setup Docker cases ARE still a baseline gap (bootstrap deadlock: plugin registration evaluates plugins.rb before any gems land; exit-semantics twin), doc corrected Verified: core 2460/0, cli lib 350/0, clippy+fmt clean; e2e_gem 11/11 (incl. live lifecycle under bundler 4.0.15), e2e_vendor_gem_build 6/6 (incl. real-bundler capstone), docker_e2e_gem 2/2, docker_e2e_vendor_gem 1/1, hosted production gem leg green (redirect verified; install still blocked by the known depscan#23630 compact-index 404 — server-side). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(review): CRLF-tolerant source-block guard; dry-run VEX skip for all scan arms Addresses both Bugbot findings on #175: - The grant-agnostic Gemfile idempotency guard required LF (`do\n`), so a core.autocrlf checkout of a previously-redirected Gemfile was not recognized and the indented gem line inside the block got wrapped in a second, nested source block on re-run. The recognizer now accepts `do\r?\n`; pinned by gemfile_rerun_on_crlf_checkout_never_nests (verified red without the fix). - The dry-run VEX skip only covered the vendor JSON arm; the interactive `scan --vendor --dry-run --vex` path (embed_vex_human) and the JSON `scan --apply --dry-run --vex` path (embed_vex_into_json at the apply fall-through) still generated the document — exiting 1 on a not-yet-vendored project or writing the attestation during --dry-run. The guard now lives at the top of both embed helpers, covering every scan arm; pinned by scan_vendor_dry_run_with_vex_interactive_* and scan_apply_json_dry_run_with_vex_* (both verified red without it). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(gem): production-safe bundler plugin — tolerant bootstrap, honest digest, project-scoped stamp The generated Bundler setup plugin could deadlock a project on its own bootstrap, its design comment described trigger behavior bundler does not have, and its digest stamp was a machine-global file blind to the actual gem-file state. All trigger claims below were re-derived empirically against real bundler 4.0.15 (host) and 2.7.2 (docker image). plugins.rb template (+ published socket-patch-bundler twin): - [P0] bootstrap deadlock: bundler evaluates plugins.rb at plugin REGISTRATION, before any project gem is installed; the load-time SocketPatch.apply! got apply's exit 1 ("No packages found") and raised Bundler::BundlerError, so the FIRST `bundle install` of every fresh clone of a setup-wired project died (exit 29 under 4.0.15, exit 1 under 2.7) and every retry failed identically (registration never completed). Patch failures now warn once per process — naming what failed and the manual remediation — and let the install continue; SOCKET_PATCH_STRICT=1 restores the raise. The load-time and per-gem triggers are additionally stamp-gated so the bootstrap install stays quiet and defers to the forced after-install-all pass. - [P1] trigger reality: the header claimed plugins.rb runs during the Gemfile pass "on EVERY bundle invocation" — false; bundler evaluates a plugin when a subscribed hook event first fires. Measured surface (identical on 2.7 and 4.0): every `bundle install` — fresh AND fully cached — fires before/after-install(-all); `bundle pristine` fires ONLY the per-gem events; `bundle exec`/`bundle check`/`gem pristine` fire nothing. The plugin now also subscribes `after-install` (digest+stamp-gated), which catches `bundle pristine`'s patch reversion in the same run, and the digest folds in the on-disk CONTENT of every gem-patch target (resolved from the manifest purls under Bundler.bundle_path/gems), recomputed after apply — so out-of-band reversion flips the digest even when every committed input is byte-identical. Header documents precisely which flows re-apply and which cannot, including the stale .bundle/plugin/index caveat for checkouts registered by an older plugin version. - [P2] stamp location: the digest stamp was a fixed-name file under Bundler.bundle_path — the interpreter's machine-global gem dir when no bundle path is configured, shared and clobbered across every socket-patch project on the host. It now lives at .socket/gem-plugin-stamp (project-local, excluded from its own digest inputs); the legacy global stamp is deleted best-effort and never read. launcher.rb (gem/socket-patch): - Windows arm now propagates the child's real exit code instead of collapsing every non-zero exit to 1. - the binary-cache install is atomic: staged as a temp file in the destination dir, chmodded, then renamed into place (cross-run race on Windows rename tolerated when the winner already published). - first-run failures outside LauncherError exit with a clean one-line message instead of a raw backtrace; the PowerShell Expand-Archive fallback quotes paths containing single quotes; `version`'s documented from-a-checkout fallback never engaged because Gem::MissingSpecError is a Gem::LoadError (ScriptError family), not a StandardError — found by the new launcher guard. - socket-patch-bundler.gemspec: stale `git:` comment corrected to `path:` (the source has been path: since #150). setup-matrix driver (gem-scoped, npm-family byte-identical — verified by diffing the fixtures the old and new driver produce for npm across all patchsets): - the gem fixture now serves the REAL git-blob beforeHash probed from the published .gem (`gem fetch` + `gem unpack`, mirroring docker_e2e_gem's probe; verified against an independent oracle), so hash-gated gem apply passes the variant gate without --force. With the deadlock fix this turns the formerly-gapped gem with-setup docker cases green: the full 6-case gem matrix passes in BOTH host mode (bundler 4.0.15, real rubygems.org installs) and docker mode (rebuilt image, bundler 2.7) — no dependency on any sibling apply change. Tests (each red without its fix): - core template invariants: test_plugin_template_failure_policy_and_ stamp_location (new) + test_templates_are_well_formed (extended) pin the tolerant reporter, strict hatch, stamp constants, legacy cleanup, target-content digest, and the published twin's parity — 2 failures against the old template. - setup_matrix_gem::plugin_runtime drives the plugin generated by the REAL binary through REAL `bundle install` runs with a fake apply: first_bundle_install_survives_failing_apply (the P0 repro: red at exit 29 on the old template), strict_mode_fails_bundle_install_on_apply_ failure, successful_apply_stamps_project_scoped (stamp path + exactly one forced apply per cached install), digest_tracks_gem_file_content_ and_legacy_stamp_is_removed (plain-ruby drive; red on the old manifest-only digest and old stamp path). - setup_matrix_gem::launcher_guard drives launcher.rb with host ruby: windows_branch_propagates_child_exit_code (red: 7 collapsed to 1), unexpected_download_errors_exit_cleanly (red: raw backtrace), powershell_quote_doubles_single_quotes and install_executable_is_atomic_into_place (red: helpers absent). 7 of 8 runtime/launcher guards fail against the base-branch code. Verified: core 2461/0, cli lib 350/0, setup_matrix_gem 11/11 (incl. the docker-mode 6-case matrix on a fresh image AND host-mode 4.0.15 run), docker_e2e_gem 2/2, docker_e2e_vendor_gem 1/1, e2e_gem 11/11 (incl. live lifecycle), clippy+fmt clean on both crates. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(gem): bootstrap gate keys on target presence, not the committed-dir stamp; gitignore + lifecycle it The require_stamp gate trusted the EXISTENCE of .socket/gem-plugin-stamp — a file living in the directory every other workflow file tells users to COMMIT. Reproduced against bundler 4.0.15: a stale stamp that reaches version control passes the gate at plugin REGISTRATION on a fresh clone, digest-mismatches (targets absent), shells apply, and under SOCKET_PATCH_STRICT=1 resurrects the exact bootstrap deadlock this plugin exists to avoid (exit 29, "Failed to install plugin", no plugin index, every retry identical). Deleting the stamp had the inverse sharp edge: the gated triggers went dead, so `bundle pristine` left the patches reverted until the next `bundle install`. - plugins.rb template + published twin: the bootstrap gate now bails while NONE of the manifest's gem-patch targets exist on disk, reading the live gem tree and never the stamp (which is now a pure digest cache). Registration on a fresh clone stays quiet regardless of stamp state, and pristine heals in the same run even with the stamp deleted — both verified against real bundler 4.0.15. - report_failure: the trailer now states what the ACTIVE mode does — the strict raise says the install is failing because SOCKET_PATCH_STRICT is set, instead of claiming "`bundle install` continues". - setup wires /gem-plugin-stamp into .socket/.gitignore (append-only, sparing user lines) so the stamp never lands in git status or a blanket `git add .socket`; `--check` demands the entry (check/setup agreement); `--remove` best-effort deletes the stamp and strips our line. - matrix.json: the gem row records reality — hook_family bundler-plugin, baseline_supported true — so a future regression of the with-setup flow classifies as blocking regression, not a known gap. - launcher_guard::run_ruby scrubs RUBYOPT/BUNDLE_*/GEM_*/SOCKET_* like plugin_runtime::scrub, so the suite survives `bundle exec`. New pins: plugin_runtime::committed_stale_stamp_does_not_deadlock_strict_ fresh_clone (registration recorded, hook-only failure, retry converges), plugin_runtime::bootstrap_gate_keys_on_target_presence_not_stamp (both gate directions), strict-trailer asserts in the strict-mode test, gitignore and stamp-lifecycle asserts in host_guard + core gem tests. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(gem): normalize the platform-gem glob base to forward slashes Dir.glob treats backslash as an escape on EVERY platform, and Bundler.bundle_path carries Windows backslash separators through verbatim (verified: BUNDLE_PATH='vendor\bundle' yields <root>/vendor\bundle/ruby/3.4.0). The platform-install wildcard in patch_target_files (<gems>/<name>-<version>-*/<rel>) therefore escape-ate the separator and matched nothing on Windows: platform installs (nokogiri-1.15.0-x64-mingw-ucrt) dropped out of the digest, so a bundle pristine reversion of them left the stamp matching and the re-apply skipped. Fix: glob a slash-normalized base (forward slashes are valid separators on Windows); the direct non-glob join stays byte-faithful. Applied to both the setup template and the published gem twin, pinned by new needles in the core parity test. Regression test (verified red without the fix): plugin_runtime::backslash_bundle_path_still_digests_platform_gem_files drives the generated plugins.rb with plain ruby under a backslash-bearing BUNDLE_PATH while the real tree lives at the slash spelling (the two-spellings-one-directory situation Windows creates): the platform install must be enumerated as a patch target and its reversion must flip the digest and re-run apply. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…the listing first, pass --cli-build-sha, fix the path filters Download step: pre-populate Bun 1.1.38 (the `legacy-lockb` baseline the script installs with on every other release) beside the matrix release or the dispatch override — de-duplicated, only when that shape is in play — so the script's in-job install_tool() fetch, and the GitHub-outage exposure it carried on 42 of 45 cells, is gone; check the SHASUMS256.txt listing BEFORE fetching the archive (a release without this OS's asset fails in one request instead of five 404 rounds); skip override releases before 1.1.0 on Windows with a `::notice::` (no Windows build exists) and export the staged releases through `steps.bun.outputs.versions`. Run step: consume that output, report `noCells` and pass when every requested release was skipped, and pass `--cli-build-sha "$CLI_BUILD_SHA"` so the provenance the comment promised is actually recorded. Path filters: the `crates/socket-patch-core/src/patch/bun_lock_text.rs` entries named a file that has not existed since #150 — now `vendor/bun_lock_text.rs`; the push list gains `Cargo.lock` (what rust-cache keys on), `vendor/**`, `commands/scan/**`, `vendor.rs`, `repair_vendor.rs` and `remove.rs`. The step logic was exercised locally with stubbed curl/python3 across six scenarios; yaml parse, pin-check grep and `zizmor --offline --min-severity medium` are clean. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Fix Bun patch compatibility and refusals Support Bun text lock version 0 and reject workspace layouts whose tarball paths cannot survive native reinstalls. Refuse incompatible vendored downloads before recording manifest patch intent. Add native release/configuration checks for hosted, vendored and detached installs, patched bytes, integrity and rollback. Assisted-by: Codex:gpt-6-astra * Keep Bun compatibility probes nonblocking Use the regular-file reader for Bun preflight and vendoring. Verify FIFO inputs refuse promptly, and snapshot the CLI for native runs so concurrent builds cannot change the binary under test. Assisted-by: Codex:gpt-6-astra * Guard Bun manifests for explicit patch retrieval Apply Bun compatibility preflight to get by UUID as well as search. Exercise both entry points across the native release matrix. Assisted-by: Codex:gpt-6-astra * fix(bun): claim and replay bun.lock hosted edits per purl in the takeover revert `revert_npm_redirect_purl` hard-refused any `redirect_bun_lock_package` edit whose fragments mentioned the package ("cannot replay yet"), so on a bun project every hosted->vendored conversion (`scan --mode vendored`, `get --mode vendored`, `vendor`) exited 1 with `redirect_revert_failed`, and a scoped `rollback <purl>` / `remove <purl>` holding a second hosted record did the same — although the whole-ledger replay already inverted the edit kind. The refusal text prescribed `bun install` (a no-op: bun keeps a URL 3-tuple byte-identically) and hand-editing the ledger. The bun rewriter records the whole packages-entry line as `original` / `new` and keys the edit by the lock MAP key (`minimist`, a nested `other/minimist`, an install alias), never `name@version`. Ownership is therefore read from the recorded line's spec, exactly the field the rewriter matched on: a registry spec equal to `<name>@<version>`, or a hosted http(s) URL spec for `<name>` whose last path segment is `<bare>-<version>.tgz` (the leaf `tgz_rel_leaf` / `is_prior_hosted_bun_spec` agree on for scoped names). Sibling versions are foreign (never claimed, never a refusal); an edit that mentions the package but parses as no bun entry line refuses with the WORKING remedy (an unscoped `rollback`). Claimed edits replay through the same whole-fragment `replacen(new, original, 1)` path as the yarn/pnpm text kinds, with the same drift refusal, so a CRLF lock round-trips byte-exactly. Tests: the fail-closed refusal test becomes a success round-trip through the real rewriter; added sibling-version non-claim, scoped re-redirect chain claimed by spec+leaf (same-leaf `@other/pkg` and bare `pkg` untouched), drift refusal, CRLF round-trip, two-records-revert-one, dry-run, undecidable-edit remedy text, alias-keyed instance, and hand-restored no-op. rollback.rs: the `defer_bun` comment no longer describes a refusal. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(vendor): probe the hosted takeover on dry runs instead of promising it The dry-run arm of the cross-mode gate emitted `vendor_would_revert_redirect` for every purl the redirect ledger claimed without ever asking the per-purl revert whether it would succeed, so `vendor --dry-run` promised a takeover the wet run could refuse (`redirect_revert_failed` on drift or a corrupt edit). It now runs `revert_redirect_purl(.., dry_run = true)` on a throwaway ledger clone — write-free, same inverses and drift checks — and surfaces a refusal with the SAME code and detail the wet run emits. On success, when the probe would rewrite bun.lock the preview stops after the advisory (which already states the whole plan: revert, then vendor): the bun backend reads the lock from disk, where the hosted URL 3-tuple has replaced the `name@version` spec it keys on, so previewing over it would emit a `vendor_lock_entry_not_found` the wet run never sees. Flavors whose hosted rewrite keeps the entry identity (yarn, pnpm, package-lock) preview exactly as before. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): hermetic hosted->vendored takeover, dry-run and scoped unwind CLI suite Drives the built binary against a wiremock patch API over a real bun 1.4.2 lockfileVersion-2 lock (matrix-capture grammar; no bun binary needed): 1. scan --mode hosted -> scan --mode vendored succeeds with `vendor_takeover_reverted_redirect`, the redirect ledger record is dropped, bun.lock carries the `.socket/vendor/npm/<uuid>/` 3-tuple and no hosted URL, state.json records the PRISTINE registry line as the wiring original, a re-run is `already_vendored`, and `vendor --revert` restores the pristine bytes. 2. vendor --dry-run over the live hosted redirect previews the takeover (`vendor_would_revert_redirect`, no `vendor_lock_entry_not_found`, no writes); the wet vendor completes it. 3./4. Two hosted records: scoped `rollback <purl>` and `remove <purl>` (per-purl path, replay not eligible) unwind only the targeted line and record; the sibling stays hosted. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(process): shared PATH tool resolver — absolute entries only, PATHEXT + cmd.exe shims; pipenv uses it Lift resolve_on_path / is_executable / is_batch_shim / the cmd.exe /C launcher out of utils/pipenv.rs into utils::process as resolve_tool / resolve_tool_with / command_for / tool_command, so every tool the CLI spawns inside a scanned project (bun, pipenv) skips relative PATH entries (a repo-planted binary) and finds .cmd/.bat shims on Windows. pipenv.rs keeps its thin wrapper; behaviour and its tests are unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): rollback restores bun.lockb from the redirect ledger Inverse::BunLockbMigrated now decodes the pre-migration bytes (standard base64 in FileEdit.original) and writes bun.lockb back through the crate's atomic writer, leaving the migrated bun.lock in place, with the informational redirect_bun_lockb_restored warning. Without captured bytes the honest redirect_bun_lockb_unrestorable fires only when bun.lockb is actually absent; a present-but-different lock is never clobbered. The migration record now obeys the ledger path-safety rule because the replay writes its path. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): truthful bun.lockb migration ledger, manual-migration code, resolved bun spawn - After a successful migration a bun.lockb that bun 1.1.43-1.1.45 kept is removed by the CLI so the ledger's removed record is always true; the pre-migration bytes are captured as standard base64 in the FileEdit original (raw cap 8 MiB) so rollback can restore the binary lock. The zero-redirect unwind keys off an in-memory flag + bytes, not the ledger payload. - exit 0 with no bun.lock (bun 1.1.39) is redirect_bun_lockb_manual_migration naming bun install --save-text-lockfile; spawn failure / non-zero exit stays redirect_bun_lockb_unsupported and now carries bun's output tail. - bun is resolved via utils::process::tool_command (absolute PATH entries, PATHEXT, cmd.exe shims) and the resolved path is spawned, never the bare name. - The spurious redirect_npm_no_lockfile on bun.lockb-only projects is dropped by the driver. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): shim-driven lockb migration + rollback round trips, Windows bun.cmd twins, real 3-tuple fixtures Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(redirect): golden harness pins warning codes via optional expected-warnings.json redirect_golden.rs asserted only the changed-file set and the edits ledger, so every refusal fixture passed on ANY early return: a renamed code, a refusal firing for the wrong reason, or an entry that silently failed to match all produced the same "no files, edits == []". A case may now ship `expected-warnings.json` (JSON array of codes, order-sensitive) and the harness asserts `result.warnings[].code` equals it. The file is optional so the maven cases that legitimately rewrite AND warn keep passing unchanged; positive cases may pin `[]`. The four bun refusal fixtures now pin their codes (redirect_bun_workspace_unsupported, redirect_bun_lock_unsupported, redirect_bun_lockb_unsupported, redirect_bun_missing_sha512). Mutation- checked: renaming the workspace code at its emit site fails lock-v0-workspace-refusal with "warning codes mismatch". The depscan TS twin (golden.test.ts) consumes the same fixture tree and must gain the same optional file for the cross-language contract to hold. Findings: test-quality:golden-harness-never-asserts-warnings, hosted-engine:v0-workspace-refusal-has-no-code-asserting-test, docs-contract:hosted-workspace-refusal-code-unasserted. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): one actionable lockfileVersion refusal message for hosted and vendored check_lock_version accepts 0, 1 and 2 and parses a u64, so the only reachable `Some(v)` refusal is v >= 3: a lock written by a Bun NEWER than this release tests. Both the vendored gate and the hosted rewriter told the user to "re-lock with bun >= 1.4", which reproduces the same head. The `Some(v)` arm now says the lock is newer than this socket-patch release supports and to update socket-patch (or re-lock with a Bun that writes 0-2); only the `None` arm (no integer head) keeps a re-lock remedy, now "Bun >= 1.2 (`bun install`)", the first release whose default lock is text. rewrite_bun_lock pushes the gate's Err text as the redirect_bun_lock_unsupported detail instead of its own fixed string, so hosted and vendored share exactly one message and cannot drift. Unit tests in both modules pin the per-arm remedies and the equality. Finding: docs-contract:future-lockfileversion-remedy-incoherent. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): true remedy for the v0 workspace refusal, pinned on real bun grammar redirect_bun_workspace_unsupported told the user to "upgrade Bun and regenerate the text lockfile" without saying how. Verified with real Bun on a 1.1.45-written lockfileVersion-0 workspace lock: a plain `bun install` with EVERY release from 1.2.0 on (1.2.0, 1.2.23, 1.3.0, 1.3.13, 1.3.14, 1.4.0, 1.4.1, 1.4.2) rewrites it in place as lockfileVersion 1 (the root workspace dep spelling changes from a bare path to `workspace:*`, forcing the save), while 1.1.45 keeps it at 0; a v0 lock WITHOUT workspaces is kept at 0 by 1.2.x and only bumped by >= 1.3.14. The detail now names that remedy: re-lock with Bun >= 1.2 (a plain `bun install` rewrites the lock as lockfileVersion 1, which hosted mode accepts) or delete bun.lock and re-run `bun install`. End-to-end with this CLI: real 1.1.45 v0 workspace lock -> refused, bytes untouched; `bun install` with 1.2.0 -> v1 -> re-scan redirected=1, frozen install rc=0, rollback rc=0. The code was asserted by no test and no test fed the rewriter a lockfileVersion 1/2 lock containing a `workspace:` entry, so widening the gate to every workspace lock passed everything. New unit tests: the real 1.1.39-1.1.45 2-tuple `["consumer@workspace:packages/consumer", { "dependencies": {...} }]` at v0 -> files empty, exactly one warning with this code and the remedy text; the SAME entries at v1 and v2 -> rewritten with the workspace line byte-identical and no warnings (plus the real v1 1-tuple spelling); a v0 lock whose only workspace is the root "" -> rewritten. Mutation-checked: `lock_version(content).is_some()` fails the unit test and the lock-v1-workspace golden case. Fixtures now carry the grammar bun actually writes (captured from bun 1.1.45 / 1.3.14 / 1.4.2 on real workspace projects): the lock-v0-workspace-refusal input is the verbatim 1.1.45 shape (no configVersion, bare-path root workspace dep, 2-tuple member entry with its deps object, blank line between entries) and is still refused; new lock-v1-workspace (1-tuple member, root-declared dep rewritten, warnings []) and lock-v2-workspace-nested (root `left-pad` and nested `consumer/left-pad` at the same version both rewritten, nested `other/left-pad` at another version untouched). Findings: test-quality:redirect-workspace-gate-code-unasserted-no-negative-twin, hosted-engine:v0-workspace-refusal-has-no-code-asserting-test, vendored-engine:v0-fixtures-not-real-bun-grammar (golden half), test-quality:new-unit-tests-weak-oracles-and-v0-fixture-arity (fixture half). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): keep CRLF on the rewritten hosted bun.lock line rewrite_bun_lock splits on '\n' and rebuilt the matched entry from its parsed parts, so on a CRLF bun.lock (Windows core.autocrlf checkout) exactly the rewritten line lost its trailing '\r': the file became mixed-EOL and the ledger `new` fragment no longer matched the on-disk bytes the way `original` did (replay matches fragments exactly, so after an autocrlf commit/checkout round-trip a revert would leave '\r\r\n'). The vendored engine (vendor/bun_lock.rs) already re-emits the '\r'; the hosted rewriter now does the same. Verified with real Bun against the production minimist@1.2.2 patch on a CRLF-converted lock: PR-head CLI -> 14 CRLF / 1 LF-only lines and ledger `new` without '\r'; this CLI -> 15/15 CRLF, `original` and `new` both carry '\r', `bun install --frozen-lockfile` rc=0 on 1.4.2 and 1.3.14, rollback restores the CRLF original byte-exact. Adds the bun_crlf_lock_keeps_crlf_on_rewritten_line unit test (modelled on the yarn classic CRLF test: every line keeps CRLF, output == LF rewrite with '\n' -> '\r\n', both ledger fragments end in '\r') and the lock-v2-crlf golden fixture (real bun 1.4.2 grammar, CRLF input + expected; .gitattributes already keeps the fixture tree -text). Mutation-checked: dropping the '\r' re-emit fails both. Findings: windows-macos:hosted-bun-rewrite-drops-cr-mixed-eol, hosted-engine:hosted-bun-rewrite-drops-cr-on-rewritten-line. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): golden fixtures for the stale-URL re-pin and bun's alias spelling re-redirect-stale-url: the input already carries a hosted URL 3-tuple from an EARLIER redirect (older token + patch uuid + integrity). The registry `name@version` spec is gone, so ownership is origin + `<name>-<version>.tgz` leaf (is_prior_hosted_bun_spec); the entry is re-pinned to the current URL and sha, and the ledger `original` is the stale URL line. Until now this arm was covered by one unit test only, so the TS<->Rust byte-parity contract never saw it. NOTE for depscan: bun.ts has no prior-URL arm, so this case needs a TS port (or a TS_LAGGING entry) in lockstep. alias: bun's spelling for `"alias": "npm:left-pad@1.3.0"` (captured from bun 1.3.14 and 1.4.2) keys the packages entry by the ALIAS while the tuple spec is the real `left-pad@1.3.0`. The rewriter matches on the spec and re-emits the key verbatim, so the alias is rewritten (as the live 1.4.2 alias-hosted matrix cell showed) and the ledger key is the alias; this pins it. Both pin `expected-warnings.json` = []. Finding: hosted-engine:re-redirect-path-has-no-golden-or-cli-test (golden half). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): gate the vendored workspace refusal on the classified instance and make its remedy converge The workspace gate added by the PR ran on the raw bun.lock before the target instances were classified, so a project vendored on a lockfileVersion 0/1 lock that later grew a workspace member was refused every maintenance verb (`vendor`, `scan --mode vendored`, `repair`) with vendor_bun_workspace_unsupported, and `repair` left the lock pointing at a tarball it declined to rebuild (cold `bun install --frozen-lockfile` then fails). The gate now runs after classification and refuses only a run that would WRITE a new local-tarball tuple (a Registry instance); in-sync re-runs and repair rebuilds (every instance already Ours) go through. It stays ahead of staging, so refusals still precede writes. The remedy could not converge: Bun 1.4.x never bumps an existing v1 lock to 2 in place (install, --save-text-lockfile, --force, add, update all keep it), so "upgrade to Bun >= 1.4 and run `bun install`" looped forever. The message now names the lock's version, says to delete bun.lock and re-lock with Bun >= 1.4, notes that an in-place install keeps the version, and offers `--mode hosted`. The gate itself is kept as a documented over-approximation (root-only declarations would work on v1, but the lock cannot cheaply prove who declares an entry). vendor_bun_lockb_unsupported had two emitters with different remedies; the preflight one dropped the contract's `bun install --save-text-lockfile` pointer and said "upgrade Bun". Both now share one const carrying the flag and its 1.1.39 floor. Module doc: integrity is enforced fail-closed by Bun >= 1.3.10 (registry tuples from >= 1.2.0); earlier releases install a tampered tarball with exit 0 (the PR's docs said 1.3.14). Tests use the real per-version workspace grammar (v0: no configVersion, bare-path root dep, 2-tuple member entry with deps; v1/v2: 1-tuple), byte-exact BN3 oracles for the v0 and v2 arms including revert, message assertions, and three new cases: in-sync re-run, rebuild-on-missing, and fresh-vendor-still-refuses on v0/v1 workspace locks. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): surface a bun.lockb-only project as a scan diagnosis instead of a silent empty inventory A bun project whose only lockfile is the legacy binary bun.lockb (bun <= 1.1.38 always; 1.1.39-1.1.45 without --save-text-lockfile) with no node_modules scanned as `status: success / scannedPackages: 0` with no warnings in every mode (54 lockfile-only matrix cells passed as clean), because the lock inventory mapped the probe's vendor_bun_lockb_unsupported to the calm Ok(None) reserved for "no lockfile". The inventory now returns an UnsupportedNpmLayout with the stable code bun_lockb_unsupported and an inventory-phrased remedy, which rides scan's additive run-level warnings[] (and the human `Warning (code): detail` line) exactly like the PnP refusals; exit code and status are unchanged. Hosted mode drops that warning only on the NON-empty path, where the hosted driver runs and owns the bun.lockb story (it migrates the lock when a bun candidate exists, or reports its own redirect_bun_lockb_* outcome); the zero-package hosted envelope keeps it, because the driver never runs there and the run would otherwise be the exact silent no-op this closes. Inventory tests now loop lockfileVersion {0, 1, 2} with the real v0 2-tuple workspace entry asserted skipped, and pin the lockb-only diagnosis (plus bun.lock-beside-bun.lockb inventorying normally). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): run the repair flavor suite over bun lockfileVersion {0,1,2} x workspace shapes No test layer ran `repair` on a workspace-bearing or lockfileVersion-0 bun.lock, which is how the workspace-gate repair regression slipped past 1,809 green matrix rows. The bun arm of repair_rebuilds_deleted_* / repair_rebuilds_corrupt_* now covers six shapes; v0/v1 workspace shapes are reached the way real projects reach them (vendored first, member added afterwards, since a fresh vendor into such a lock is refused by design) with the real per-version workspace entry grammar, asserting a byte-identical rebuild, unchanged lock bytes and exit 0. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): preflight every vendored download path, keep refusals visible under --silent `scan --mode vendored --detached` skipped the Bun preflight: it fetched the patch view first and, for alias-installed packages on a bun.lockb project, the vendor step then misreported `package_not_installed`. The preflight now runs once on every path that feeds the vendor engine (manifest-tracked and detached download phases, `get <uuid>` / `get <purl> --mode vendored`, and the `--dry-run` previews), BEFORE any `/patches/view/` fetch, through one shared `BunVendorRefusal` helper. - `--silent` is "errors only": the purl-path `[error]` line prints whenever not JSON and is code-tagged (`[error] <purl> (<code>): <detail>`); the uuid path's `Error (<code>): <detail>` drops its `!silent` gate. - Already-vendored exemption: a purl the vendor ledger wires at the SAME uuid the run selected is never refused (in-sync re-runs and the pre-gate upgrade path reach the engine's already_vendored skip); an unreadable ledger exempts nothing (fail closed). - uuid-path envelope parity: the failed record gains `error` and the envelope gains `skipped: 0`; the refusal fires `patch_vendor_failed` telemetry. The search path and both scan arms report run-outcome telemetry (`has_errors`, download refusals included) instead of a success event on an exit-1 run. - `--dry-run` previews emit the additive `would_refuse` action (+ `errorCode` / `error`) for npm purls the wet run would refuse; status and exit code are unchanged; the human dry-run names them as `[would-refuse]` lines. Unit tests: download_patch_records refuses lockb / v1 workspace before any fetch, skips non-npm purls, exempts the in-sync ledger entry; the preview classifies would_refuse / already_vendored / lockb. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): hermetic CLI coverage for the vendored Bun preflight New tests/in_process_vendor_bun.rs (wiremock, real bun lock grammar: v1/v2 1-tuple workspace locks, the bun 1.1.45 v0 2-tuple lock, bun.lockb-only, malformed lockfileVersion 3, a Unix FIFO): exit codes, exact envelopes (uuid path status:error + error{code,message} + record errorCode+error; scan / purl paths partial_failure), zero view fetches on refusal, byte-identical bun.lock, no .socket/vendor, a seeded manifest record preserved (Value equality), --silent stderr carries the code with an empty stdout, --dry-run reports would_refuse on every entry point, --save-only agent runs bypass the preflight, positive controls (v2 workspace vendors; v0 direct lock vendors via get and rollback restores bytes), --detached refuses pre-fetch, the already-vendored download-phase exemption, and the workspace-member --cwd behaviour pinned as it is today. The full already_vendored re-run is #[ignore]d pending lane B1's engine-side ordering fix (verified to fail today on vendor_bun_workspace_unsupported). get_modes_e2e.rs: silent visibility (both identifiers), dry-run would_refuse, save-only exemption. scan_vendor_e2e.rs: download-phase refusal, detached twin, silent human arm. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): hard-fail gates, lock-era assertions, 1.3.10 digest boundary, rollback + plain-install legs in the hosted real-bun suite The hosted real-bun capstone soft-skipped whenever `bun` was missing, so it passed vacuously in every CI job; its tampered leg hard-asserted a frozen-install failure that bun < 1.3.10 never produces; its forced-v2 leg proved nothing distinct (native lock on >= 1.4, unreadable below); and it had no rollback leg and no plain-install lock-stability check. - `SOCKET_PATCH_BUN_E2E_REQUIRED` (set AND non-empty — CI passes an empty string for non-bun legs) turns every SKIP (no bun, fixture install failed, no text lock, unparsable version, pre-1.1.39 bun) into a hard assert; `SOCKET_PATCH_BUN_E2E_VERSION` must equal `bun --version` so a leg cannot pass on the wrong bun. - `bun --version` is parsed once; `--save-text-lockfile` is passed only for bun < 1.2.0 (the opt-in era); the fixture ASSERTS the emitted lockfileVersion matches the era table (1.1.39–1.1.x → 0, 1.2–1.3 → 1, >= 1.4 → 2) and every later assertion is version-independent. - Tampered leg gated on `TARBALL_INTEGRITY_ENFORCED_FROM = (1,3,10)`: >= 1.3.10 must fail on the integrity check; below it a DIFFERENT valid tarball must install with exit 0 and the installed bytes must be the tampered bytes (PARTIAL). Verified on 1.3.9 (accepts) vs 1.3.10 (rejects). - Forced-v2 leg replaced by the one distinct cross-version proof a single binary can give: on bun >= 1.4 the native v2 lock is relabelled to lockfileVersion 1 (configVersion kept — dropping it makes bun add `"configVersion": 0` on a plain install), the rewrite must keep the version line, and frozen + plain installs must succeed without a bump. - New rollback leg: `rollback --yes --json` restores bun.lock byte-for- byte, deletes the redirect ledger, and a fresh frozen install lands the ORIGINAL bytes. - Every install proof now also runs a plain `bun install` (node_modules removed, empty cache) and asserts the lock stays byte-identical — frozen mode never writes the lock, so only this observes re-serialization drift. - Tarballs are built with the tar crate (no system `tar`; Windows-ready), all bun installs pass `--ignore-scripts`, every CLI run passes `--no-telemetry`, and the stale lockb header comment now points at the in-process shim tests and the bun-compatibility native matrix. Verified with SOCKET_PATCH_BUN_E2E_REQUIRED=1 on real bun 1.1.39, 1.1.45, 1.2.23, 1.3.9, 1.3.10, 1.3.13, 1.3.14 and 1.4.2 (10/10 each); no bun → soft-skip, REQUIRED + no bun → loud failure. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): accept lockfileVersion 0, hard-fail gates, tampered twin, repair + plain-install legs in the vendored real-bun suite The vendored real-bun capstone hard-asserted the fixture lock was lockfileVersion 1 or 2, so on bun 1.1.39–1.1.45 (the releases whose `--save-text-lockfile` writes 0 — the very ones the PR adds support for) both tests panicked at fixture setup; it soft-skipped without bun (vacuous CI pass); it had no tampered twin, no repair leg, and its only lock-stability check ran after `--frozen-lockfile`, which never writes. - Same REQUIRED / VERSION gates and version-aware fixture as the hosted suite: `bun --version` parsed once, `--save-text-lockfile` only for bun < 1.2.0, the emitted lockfileVersion ASSERTED against the era table (0 / 1 / 2) and recorded on the fixture; the rewrite must keep the version line; the registry 4-tuple spelling is identical across eras so every downstream assertion is version-independent. - New tampered twin: the vendored `.tgz` is swapped for a DIFFERENT valid tarball; from 1.3.10 the fresh frozen install must fail on the integrity check, below it must exit 0 and install the tampered bytes (PARTIAL). Verified on 1.3.9 (accepts) vs 1.3.10 (rejects). - New repair leg inside the capstone: `.socket/vendor/npm/<uuid>/` is deleted, `repair --offline --yes` must rebuild the tarball byte- identically without touching bun.lock, and a cold fresh checkout must frozen-install the marker bytes from the rebuilt artifact. - Every install proof now also runs a plain `bun install` (node_modules removed, empty cache) and asserts bun.lock stays byte-identical and the marker lands again. - Tests are `#[serial]` like the hosted suite, all bun installs pass `--ignore-scripts`, every CLI run passes `--no-telemetry`, and the replacement tarball is built with the tar crate (Windows-ready). Verified with SOCKET_PATCH_BUN_E2E_REQUIRED=1 on real bun 1.1.39, 1.1.45, 1.2.23, 1.3.9, 1.3.10, 1.3.13, 1.3.14 and 1.4.2 (8/8 each); no bun → soft-skip, REQUIRED + no bun → loud failure. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): real-bun scoped dependency-bearing legs — {dependencies, bin} meta must survive hosted and vendored rewrites Every real-bun proof so far patched left-pad, whose lock meta is `{}`, so the engines' deps-preserving branches (redirect/mod.rs deps_verbatim, vendor/bun_lock.rs) and scoped `@scope/name` keys were exercised only by parser-level goldens and unit tests. A meta-dropping regression would be SILENT under those legs: bun installs a `{}`-meta tarball tuple with exit 0, patched bytes and a stable lock — and no deps, no bin. Both suites gain a `Target` (LeftPad | ScopedWithDeps) and one leg each for `@scope/pkg@1.0.0`: a scoped package with `dependencies: {left-pad}` and a `bin`, served by a wiremock npm registry through bun's `[install.scopes]` (bunfig.toml — a committable file that travels with the fresh checkouts). Bun records it as `["@scope/pkg@1.0.0", "<tarball url>", { "dependencies": {…}, "bin": {…} }, "sha512-…"]`; the legs assert that exact pre-rewrite spelling, that the rewrite produces the 3-tuple with the meta object byte-identical (hosted URL / local path `.socket/vendor/npm/<uuid>/@scope/pkg-1.0.0.tgz`), that left-pad's own registry entry stays byte-identical, and that the fresh frozen AND plain installs land the patched bytes, install left-pad and link the bin (`node_modules/.bin/scope-pkg*`, Windows shims included). Tarballs built from the installed tree now keep file modes (the bin script stays executable); Windows falls back to 0755 under `bin/`. Verified with SOCKET_PATCH_BUN_E2E_REQUIRED=1 on real bun 1.1.39, 1.1.45, 1.2.23, 1.3.9, 1.3.10, 1.3.13, 1.3.14 and 1.4.2: redirect suite 11/11, vendor suite 9/9 on every version. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: run the hermetic real-bun e2e suites in the e2e matrix e2e_redirect_bun_build and e2e_vendor_bun_build have never executed a bun command in CI: the `test` job runs them on runners that ship no bun, so both soft-skip and report "ok" in 0.00s on all three OS, and the `e2e` matrix had no bun leg. Add legs for both suites plus the new mode_migration_bun suite on ubuntu/macos/windows with bun 1.4.2 (lockfileVersion 2), and ubuntu lock-era legs with 1.1.45 (v0 opt-in text lock) and 1.2.23 (v1 default; 1.3.14 for mode_migration_bun), installed by SHA-pinned oven-sh/setup-bun v2.2.0. `test_filter: --include-ignored` is mandatory on every bun leg: the suites carry no #[ignore] tests, so the job default `-- --ignored` would select nothing and pass vacuously (the e2e_composer trap). The run step exports SOCKET_PATCH_BUN_E2E_REQUIRED=1 and SOCKET_PATCH_BUN_E2E_VERSION=<pin> on bun legs (empty string elsewhere) so the suites hard-fail instead of skipping when bun is missing or the wrong release. The rust-cache key gains the bun release so several legs of one suite on one OS no longer collide. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci(bun): main trigger, wider paths, verified retried bun download, dispatch inputs The native bun matrix ran only on path-filtered pull_request events, so post-merge main was never exercised and its rust-cache (save-if main) was never written: every build restored nothing and compiled cold. Add a path-filtered `push: branches: [main]` (pdm shape) and gate cancel-in-progress on non-main so the seeding run is never cancelled mid-save. Widen the pull_request filter to the code the backtest actually drives (rollback/vendor/repair_vendor/remove commands, npm crawler and pkg_managers detection, constants, utils/process, bun_lock_text, the bun redirect fixtures, the doc and Cargo.lock). scripts/backtest-bun.py fetches each release with one un-retried urlretrieve before any case runs; a transient GitHub 500 killed a whole cell on the workflow's first run. Add a step that pre-populates the exact `tools/<version>/<asset>/bun[.exe]` layout install_tool() looks up with a 5-attempt backoff loop, verifies the archive against the release's SHASUMS256.txt before extracting (fail closed) and checks `bun --version`, then pass `--tools native-bun/tools` so the script only sees a verified, cached binary. Also: add 1.1.43 (first `--lockfile-only`), 1.3.9 and 1.3.10 (URL/local tarball sha512 enforcement boundary) to the matrix — all three ship a Windows asset, so the exclude list is unchanged; add workflow_dispatch inputs versions/shapes/modes wired like pdm-compatibility.yml; record provenance as both `--cli-revision` (branch-resolvable head SHA, via env) and CLI_BUILD_SHA (the SHA actions/checkout actually built); add the `# vX.Y.Z` comments on every SHA pin, name every step, add setup-python + `python3` and `chmod || true` per the sibling workflows, and a header comment pointing at docs/testing/bun-compatibility.md. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): un-ignore the already-vendored workspace re-run now the gate is instance-scoped Lane B2 wrote this scenario against the pre-fix engine, where vendor_bun applied the workspace gate before classifying the in-sync tuple, and parked it behind #[ignore]. With the gate now evaluated per classified instance the re-run reports the documented `skipped`/`already_vendored` event; assert that shape (action `skipped`, errorCode `already_vendored`) instead of a bare `already_vendored` action that the CLI never emits. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): real-bun hosted<->vendored mode-migration suite (takeover, dry-run parity, scoped unwind, rollback) Adds crates/socket-patch-cli/tests/mode_migration_bun.rs, the bun twin of mode_migration_npm.rs (yarn) and mode_migration_cargo.rs: a two-dep project (left-pad@1.3.0 patched, is-number@7.0.0 bystander / second record) installed by REAL `bun install --ignore-scripts` (`--save-text-lockfile` below 1.2.0), private BUN_INSTALL + cache per project, wiremock patch API, patched tarballs built from the installed bytes. The native lockfileVersion is asserted against the era table (0 for 1.1.39-1.1.x, 1 for 1.2-1.3, 2 for 1.4+), and every terminal state ends with a fresh checkout's `bun install --frozen-lockfile` from an EMPTY cache proving the bytes the lock claims. 1. vendored -> hosted: `redirect_takeover_reverted_vendored`, vendored ledger entry + artifact gone, URL 3-tuple line, redirect-ledger `original` == the PRISTINE registry line, marker bytes installed; `rollback` -> pristine bytes, original bytes installed. 2. hosted -> vendored via BOTH `vendor --offline` and `scan --mode vendored` (copies of one hosted project): `vendor_takeover_reverted_redirect`, redirect record + edit dropped, local `.socket/vendor/npm/<uuid>/` 3-tuple, vendor-ledger `original` == pristine line, marker bytes installed, re-run `already_vendored`; `vendor --revert` -> pristine. 3. dry-run parity: `vendor --dry-run` previews `vendor_would_revert_redirect` (no `vendor_lock_entry_not_found`, no `redirect_revert_failed`), `scan --mode vendored --dry-run` classifies `would_vendor` (never `would_refuse`), `scan --mode hosted --dry-run` over a vendored state previews `redirect_would_revert_vendored`; a whole-tree snapshot proves none of them writes a byte; the wet runs land the previewed takeovers. 4. two hosted records in one scan; scoped `rollback <purl>` and `remove <purl>` (per-purl path) unwind only that line/record/edit, the sibling stays hosted, a fresh install lands a's original + b's marker bytes, then the unscoped rollback restores pristine. 5. unscoped `rollback` from each mixed state restores pristine bytes and leaves no vendor artifacts or ledgers. Gates mirror the two bun capstones: soft-skip without bun unless SOCKET_PATCH_BUN_E2E_REQUIRED is set and non-empty (then hard failure), and SOCKET_PATCH_BUN_E2E_VERSION must equal `bun --version`. Verified green (10/10 each) against real bun 1.4.2 (v2), 1.3.14 (v1) and 1.1.45 (v0); the CI legs for this suite were added by the ci.yml e2e matrix already. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): backtest oracle of documented boundaries, exit-code/envelope assertions, conversion + legacy-lockb + CRLF + workspace shapes, verified retried downloads The runner classified cells from the CLI's own refusal codes, so a CLI regression that refused a supported configuration (or "supported" a refused one) passed as an unsupported cell. Every cell is now judged against `expected_outcome(version, shape, mode)`, which encodes the measured Bun boundaries: bun.lockb-only releases (<= 1.1.38 by default, 1.1.39-1.1.42 for the CLI's migration recipe -> redirect_bun_lockb_manual_migration, 1.1.43+ migrate), the version-0 workspace hosted refusal, the pre-v2 workspace vendored refusal, the vendored bun.lockb refusal (scan adds the bun_lockb_unsupported diagnosis), the 0.8.1/1.0.0 peer/override upstream limitation, everything else supported. Refusal codes must match the expectation EXACTLY after an explicit informational allowlist; regression codes (migration reverted / entry not found / revert failed) fail a supported cell. Every CLI invocation records its exit code (main, repeat, rollback, conversion, repair): supported -> 0, hosted refusals -> 0 with redirected 0, vendored / detached / get refusals -> non-zero with no download and no stray manifest record. The repeat run must be the documented no-op (hosted: redirected 1, no warnings; vendored: applied 0 / skipped 1 / one already_vendored event). Rollback must exit 0 and satisfy the lockfile presence rules (text projects: bun.lock back, no bun.lockb; migrated projects: bun.lockb restored from the ledger with redirect_bun_lockb_restored, bun.lock kept). Digest boundary: TARBALL_INTEGRITY_ENFORCED_FROM = 1.3.10 (1.3.9 installs a tampered tarball, 1.3.10 refuses); below it the observation is recorded, not asserted. A new registryDigestEnforced probe proves the registry tuple IS verified on every text-lock release, documenting the downgrade the rewrite introduces below 1.3.10. Bun 1.3.9/1.3.10 print the integrity error and never exit on a workspace project; the tamper installs tolerate that hang. New shapes: hosted-then-vendored / vendored-then-hosted (takeover round trips, ledger and manifest contracts pinned), legacy-lockb (bun.lockb written by 1.1.38, the matrix release migrates it; rollback restores the binary lock byte-identically), crlf-lock (every line stays CRLF through rewrite, repeat and rollback), text-workspace (a REAL version-0 workspace lock), workspace-root, workspace-get-uuid / -search, already-vendored-workspace (re-run over a grown workspace lock, then `repair` rebuilds a deleted artifact), preexisting-manifest (a foreign manifest record with its blob survives a refused vendored run). custom-registry now injects bun's full-URL registry slot and asserts the rewrite drops it; the text gate is >= 1.1.39 and asserts the text lock was written; the alias/package_not_installed carve-out is gone. install_tool downloads with backoff (5xx/429/connection/stall/truncated zip), verifies the zip against the release's SHASUMS256.txt (fail closed), records bunSha256 / bunArchiveSha256 per row, and a tool-install failure still writes summary.json for the artifact upload. Flags and the tools layout stay compatible with bun-compatibility.yml. Verified on macOS against the production patch service with real Bun 1.1.38 1.1.39 1.1.43 1.1.45 1.2.23 1.3.9 1.3.10 1.3.14 1.4.2 over 11 shapes x 3 modes. The only failing cells are already-vendored-workspace on Bun < 1.3.10: those releases re-save URL/local tarball tuples WITHOUT their sha512 (a 2-tuple) whenever bun.lock changes, after which the CLI no longer recognizes its own wiring (redirect_bun_entry_not_found / vendor_lock_entry_not_found) and rollback refuses on drift — a CLI gap the oracle deliberately keeps visible. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(bun): contract, ecosystem matrix and changelog for the merged Bun fixes CLI_CONTRACT.md now describes the MERGED bun behaviour: text bun.lock lockfileVersion 0/1/2 (0 = Bun 1.1.39-1.1.45 --save-text-lockfile, 1 = 1.2-1.3, 2 = 1.4+) with the shared version-gate message, the version-0 workspace refusal (redirect_bun_workspace_unsupported) and its verified remedy, the truthful bun.lockb migration (PATH-resolved bun incl. Windows bun.cmd shims, works from 1.1.43, CLI removes a surviving bun.lockb so the `removed` ledger edit is true, pre-migration bytes kept base64 up to 8 MiB, redirect_bun_lockb_manual_migration for 1.1.39-1.1.42, output tail on redirect_bun_lockb_unsupported), rollback's redirect_bun_lockb_restored / narrowed redirect_bun_lockb_unrestorable, bun's participation in the per-purl hosted revert (hosted->vendored takeover, scoped rollback/remove, dry-run probe), the vendored pre-download preflight on every get/scan/ detached path (codes, no fetch, search-path partial_failure records with errorCode+error, uuid-path status:"error" envelope, already-vendored exemption, --silent visibility, --dry-run would_refuse), the vendored workspace policy gate (pre-v2 workspace locks; delete bun.lock + re-lock with Bun >= 1.4, or hosted) and the measured digest boundary (URL/local tarball sha512 enforced by Bun >= 1.3.10, registry tuples from 1.2.0). Error-code table rows for every bun code; patches[] shape notes that a failed record may carry errorCode. Everything is additive (MINOR). docs/ecosystems.md: bun rows carry the same facts, short. CHANGELOG.md [Unreleased] ### Fixed: one house-style bun entry covering lockfileVersion 0, the workspace refusals + remedies, the pre-download preflight per path, the working takeover + scoped unwind, the truthful lockb migration + restore, bun_lockb_unsupported, --silent, detached parity, would_refuse, CRLF, the real-bun CI legs and the corrected digest boundary, pointing at docs/testing/bun-compatibility.md and scripts/backtest-bun.py (#245). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(bun): rewrite the compatibility guide around the merged matrix, suites and CI wiring docs/testing/bun-compatibility.md now mirrors the sibling compatibility guides: a formats/rewrite table per lock generation and workspace shape (codes + remedies), the pre-download preflight and mode-conversion story, the bun.lockb migration table measured per release (<= 1.1.38 and 1.1.39-1.1.42 manual, 1.1.43-1.1.45 migrate and keep bun.lockb, >= 1.2 migrate and delete), the measured installer boundaries (lock history, in-place re-versioning incl. the version-0 -> 1 rewrite by any Bun >= 1.2 on workspace locks, member-relative tarball paths on 1.2-1.3, digest enforcement from 1.3.10 with the downgrade below it, both-lockfiles precedence, the 0.8.1/1.0.0 upstream limitation), the matrix runner (pinned versions incl. 1.1.43/1.3.9/1.3.10, every shape, the expectation oracle, exit-code and repeat-envelope assertions, the registry-digest control, rollback lockfile rules, captures + provenance), a claim -> evidence table separating matrix, hermetic real-bun suites and bun-less tests, and the CI wiring (ci.yml e2e bun legs on three OSes, bun-compatibility.yml on PR + main + dispatch, production suites on demand). hosted-/vendored-production-e2e.md: one bun paragraph each stating what the hosted-e2e job's bun@1 leg covers and that the vendored production bun leg is on-demand, with the CI legs that carry per-PR real-bun coverage. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(bun): name the two workspace-get backtest shapes as the script spells them Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): recognise, heal and unwind digest-less tuples re-saved by Bun < 1.3.10 Every text-lock Bun below 1.3.10 (1.1.39–1.3.9; measured on 1.1.45, 1.2.23 and 1.3.9) re-saves a hosted URL or vendored local-tarball 3-tuple WITHOUT its sha512 whenever bun.lock is re-saved for another reason (`bun add`, `bun install` after a package.json / workspace change). The 2-tuple keeps the spec Bun installs from, but the CLI no longer recognised its own wiring: a repeat hosted scan warned redirect_bun_entry_not_found beside redirected: 1, `rollback` refused partial_failure, the hosted→vendored takeover (and scoped rollback / remove) refused as drift, and the vendored re-run / repair / revert refused vendor_lock_entry_not_found / _drifted. - bun_lock_text: same_wiring_modulo_integrity + restore_digestless_line — a live line is the recorded wiring iff byte-equal (modulo trailing \r) or the same key/spec/meta with only the trailing "sha512-…" dropped. - hosted rewriter: a 2-tuple at the current URL is healed back to the 3-tuple (the edit records the 2-tuple as original); a stale URL is re-pinned from either spelling; no entry_not_found for either. - replay + takeover: when neither `new` nor `original` is present, the unique digest-less spelling of `new` is replaced by `original` (redirect_bun_lock_package only); duplicates and anything else refuse. - vendored engine: classify accepts the 2-tuple as Ours; an in-sync digest-less line is healed on disk without a wiring record when the committed artifact still holds the bytes the lock was written from, otherwise re-pinned like any stale tuple (repair's rebuild returns a fresh entry whose original carry_forward_wiring refills); revert claims the 2-tuple by its uuid path. - fix the v0-bump comment (first bumping release lies in (1.3.0, 1.3.9]). - tests: unit tests in all five modules, goldens digestless-hosted-already-wired + digestless-hosted-stale-url-repin, in_process_redirect / in_process_vendor_bun / in_process_vendor_bun_takeover, and real-bun legs in both e2e suites (network-free `file:`-dep re-save, the era's spelling asserted from both sides); backtest already-vendored-workspace now expects the digest-less spelling below 1.3.10 (digestDroppedOnResave, resaveKeepsDigest). - docs: CLI_CONTRACT bun clauses, bun-compatibility guide, CHANGELOG. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): name the sibling lock a stale bun.lockb shadows in the discovery diagnosis The npm flavor router checks bun.lockb before pnpm/yarn/npm locks, so a project that migrated away from bun and left a stale bun.lockb committed loses lockfile-only discovery of its live lock. The `bun_lockb_unsupported` detail told that project to run `bun install --save-text-lockfile`, which would create a bun.lock for a non-bun project and never named the shadowed lock or the real remedy (delete the debris). The bun.lockb arm of `inventory_npm_lock` now probes for a sibling pnpm-lock.yaml / yarn.lock / npm-shrinkwrap.json / package-lock.json (router precedence) and, when one exists, phrases the detail as "shadows <sibling> in lockfile discovery; delete the stale bun.lockb if <sibling>'s installer is in use, or run `bun install --save-text-lockfile` (Bun >= 1.1.39) if bun is". Code and fail-closed no-inventory posture unchanged; the lockb-only text is unchanged. Unit test beside the stale-lockb tests covers all four sibling kinds and the precedence. Finding: VC-4 (PR #245 final review). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): version-specific hosted remedy for pre-v2 workspace locks; add wired_instances_all_ours `check_workspace_compatibility` always ended its remedy with "or use `--mode hosted`, which accepts version-1 workspace locks" - including for the lockfileVersion-0 lock it had just named. Hosted mode refuses every v0 workspace lock (`redirect_bun_workspace_unsupported`), so a Bun 1.1.39-1.1.45 user following the alternative hit a second refusal with a different remedy. The tail is now version-specific: v1 keeps the hosted pointer; v0 says "or delete bun.lock, re-lock with Bun >= 1.2 (which writes lockfileVersion 1) and use `--mode hosted`" (an in-place `bun install` does not reliably bump a v0 workspace lock). `assert_workspace_remedy` asserts the exact tail per version. New `pub async fn wired_instances_all_ours(project_root, purl)`: whether bun.lock already wires EVERY packages entry resolving the purl's `name@version` to one of our `.socket/vendor/npm/` tuples (any uuid, 3-tuple or the digest-less 2-tuple Bun < 1.3.10 re-saves). This is the engine's own criterion for skipping the workspace gate, exposed so the CLI's pre-download preflight can exempt exactly what the engine would let through (a superseding-uuid patch update, a wiped ledger) instead of refusing with a remedy Bun 1.2/1.3 teams cannot follow. `preflight_vendor`'s doc comment now states the real exemption rule (ledger same-uuid OR lock all-ours). Findings: VC-3, VC-2 core half (PR #245 final review). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): gate the vendor takeover on the shared vendored preflight; keep bun.lockb warning on hosted scans Bun vendored preflight moved out of get.rs into a shared `commands/bun_preflight.rs` used by get.rs, scan/vendor_flow.rs AND vendor.rs, with three behaviour changes: * takeover-1 / DC-1 / takeover-2 (P1 regression): `vendor_records` ran the hosted->vendored takeover (wet `revert_redirect_purl` + `persist_redirect_state`) BEFORE `dispatch_vendor_one`, and the plain `vendor` command never ran the Bun preflight. Over a hosted-wired lockfileVersion-0/1 workspace bun.lock (hosted accepts it, the vendored backend refuses it) that stripped the live hosted redirect, deleted the ledger record, then failed `vendor_bun_workspace_unsupported` - unpatched in both modes, with a remedy pointing at the mode it had just destroyed. The dry run promised the takeover (`vendor_would_revert_redirect`, status success). The preflight now runs once per run before the dispatch loop and refuses per candidate BEFORE the takeover block, dry and wet alike: same `failed` event/code/detail the engine would emit, hosted wiring, ledger and lock byte-untouched, exit 1 on both. * VC-2 (P2): the already-vendored exemption was ledger+same-uuid only, so a superseding patch uuid on a project vendored before it grew a workspace member (or the same project with a wiped state.json) was refused at download while the engine would re-vendor in place. A purl is now exempt when EITHER the vendor ledger wires it at the selected uuid OR `wired_instances_all_ours` says every lock instance is already ours. * GCP-2 (P3): all three `load_state` sites (uuid-path preflight, detached download, dry-run preview) flattened an unreadable ledger into an empty one and reported a Bun lock remedy. They now hand the load outcome to the preflight as a Result; an Err yields `vendor_state_unreadable` with the io/parse detail (fail-closed, nothing exempt). Scan changes in the same file set: * VC-1 (P2 fail-open): scan/mod.rs dropped the discovery `bun_lockb_unsupported` warning on every non-empty hosted run, but the hosted driver only speaks about bun.lockb when an npm override is granted (decided inside `run_redirect`, which owns the envelope from there). The retain is gone: the warning stays in EVERY mode on both paths; nothing is deduplicated. * GCP-1 (P3): `print_dry_run_refusals` moved next to `preview_vendor_json` in vendor_flow.rs as pub(crate); scan's interactive `--mode vendored --dry-run` arm now prints the same `[would-refuse] <purl> (<code>): <detail>` lines as get, under the same `!silent` gate. Tests: in_process_vendor_bun_takeover.rs scenario 5 (hosted v1 workspace -> vendor dry+wet refuse before un-hosting; v2 twin still takes over); in_process_vendor_bun.rs superseding-uuid re-vendor, wiped-ledger not-refused, corrupt-ledger -> vendor_state_unreadable on uuid/human/dry-run/ detached; covgap_commands_scan_mod.rs hosted arm flipped to keep the warning + human scan dry-run [would-refuse] line; bun_preflight.rs unit tests. Verified end to end with real Bun 1.3.14 and the production minimist patch: scan --mode hosted -> get <uuid> -> vendor exits 1, lock still hosted, cold-cache frozen install installs the patched bytes. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): refuse a non-regular bun.lockb and a stale one beside a sibling lock before spawning bun Two fail-closed gates now run in the hosted driver's bun.lockb migration BEFORE any `bun install` spawn: * A `bun.lockb` that is not a regular file (a FIFO, socket or directory squatting the path) passes the `exists()` gate but wedged the plain `std::fs::read` capture of the pre-migration bytes forever — and bun's own open of the lock blocks on the same FIFO, so guarding the read alone would only move the hang into the child. The capture now goes through a new FIFO-safe `utils::fs::read_regular_to_bytes_sync` (non-blocking open + fstat regular-file check, the bytes twin of `read_regular_to_string_sync`); `InvalidInput` refuses with `redirect_bun_lockb_unsupported` "bun.lockb is not a regular file; refusing to migrate it" and bun is never spawned. Dry-run predicts the same refusal (stat, never open). Other read errors keep today's contract (migrate, record without restorable bytes). * A `bun.lockb` beside a live `package-lock.json`, `npm-shrinkwrap.json`, `yarn.lock` or `pnpm-lock.yaml` (and no `bun.lock`) is most likely debris of a migration AWAY from bun; migrating it converted an npm / yarn / pnpm project into a bun.lock project (verified with bun 1.4.2: bun.lockb deleted, lockfileVersion-2 bun.lock created and redirected beside the redirected package-lock.json). The driver now leaves it alone with the new stable warning `redirect_bun_lockb_sibling_lock` naming the sibling(s) and both remedies; the redirect follows the sibling lock as before. Dry-run reports the same code instead of `redirect_bun_lockb_would_migrate`. Tests: core `read_regular_to_bytes_sync` (binary verbatim, error kinds, FIFO fails fast), hosted unit tests for the sibling probe and details, and three covgap subprocess tests with a marker `bun` shim proving no spawn: FIFO bun.lockb (deadline-guarded, dry-run + live), stale lockb beside package-lock.json (dry-run, live, human stderr) and beside pnpm-lock.yaml. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(process): spawn resolved .cmd/.bat shims directly; std quotes them correctly `command_for` launched a Windows batch shim as `cmd.exe /C <shim>`. std quotes that path as an ordinary argument, and cmd's `/c` rule keeps the quotes only when the quoted string has no `& < > ( ) @ ^ |`, so a shim under a directory with a space AND a metacharacter (`C:\Program Files (x86)\...\bun.cmd`, `C:\Users\Jane (Work)\...`) was stripped to `C:\Program` and failed with "is not recognized" — bun degraded to `redirect_bun_lockb_unsupported`, pipenv's installed major to None — although the shim works in the user's shell. Rust std >= 1.77.2 (the toolchain pins 1.93.1) already detects `.bat`/`.cmd` on the resolved program and spawns `%SystemRoot%\System32\cmd.exe /e:ON /v:OFF /d /c ""<script>" <escaped args>"` with an outer quote pair and per-argument escaping, so the wrapper was redundant and strictly less robust. `command_for` now returns `Command::new(<resolved path>)` unconditionally (the PATHEXT-aware resolver stays: std does not search PATHEXT); `is_batch_shim` is gone with its last callers. The cfg(windows) tests assert the shim is the program with no wrapper args and spawn it — once from a plain dir, once from `Program Files (x86)` — expecting the shim's output; the pipenv Windows test spawns its `.bat` and parses the banner. Doc comments corrected ("CreateProcess refuses them" was false). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(bun): state the v0 workspace remedy as delete-and-relock, in-place bump conditional `redirect_bun_workspace_unsupported` claimed a plain in-place `bun install` with any Bun >= 1.2 rewrites a version-0 workspace lock as lockfileVersion 1. That was measured only for the backtest's `workspace` shapes, whose root depends on the member: Bun >= 1.2 re-saves that dependency's bare-path spelling as `workspace:*`, which forces the save. For a v0 workspace lock with no inter-workspace dependency (a root that only lists `workspaces`), Bun 1.2.0 exits 0 and keeps 0, and 1.2.23 to 1.4.2 exit 1 with `<pkg>@<ver> failed to resolve` and keep 0 — hosted mode kept refusing and the stated remedy never converged. The detail now leads with the remedy that converges on every release (delete bun.lock and re-run `bun install` with Bun >= 1.2, which writes lockfileVersion 1) and states the in-place bump as conditional on a workspace depending on another workspace. The gate comment and the unit test (now an exact-string pin) follow. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): share the ambient BUN_*/npm_config_* scrub across the three bun suites `scrub_socket_env` in the redirect and vendor capstones removed only `SOCKET_*`, `VIRTUAL_ENV` and `BUN_INSTALL_CACHE_DIR`, and `cache_env::isolate` pins no registry variable, so an ambient `BUN_CONFIG_REGISTRY`, `npm_config_registry` or `NPM_CONFIG_REGISTRY` pointing at a URL-rewriting mirror reached the fixture `bun install`; bun then recorded the mirror tarball URL in the 4-tuple's registry slot instead of `""` and 5/11 redirect and 3/9 vendor legs failed as false negatives, while mode_migration_bun (which scrubbed `BUN_*` and case-insensitive `npm_config_*`) stayed green. The scrub now lives once in `tests/common/cache_env.rs` (`is_ambient_bun_var` + `scrub_ambient_bun_env`) with self-tests on the covered names, and all three bun suites call it, so they cannot drift. Verified: both capstones pass on bun 1.2.23 and 1.4.2 with `BUN_CONFIG_REGISTRY=https://registry.npmmirror.com/` exported. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): assert the vendor capstone's re-run is an already_vendored skip Step 6 of `bun_vendor_fresh_checkout_frozen_install_and_revert` asserted only `failed == 0` and bun.lock byte-identity, so a regression that re-classifies the in-sync local-path tuple as needing a rewrite (applied == 1, tarball re-packed, wiring re-recorded, lock bytes unchanged) passed it — and step 7's revert still restored the lock via the ledger's carried-forward original. Mirror the pnpm capstone: `applied == 0`, `skipped == 1`, a `skipped`/`already_vendored` event for the target purl and no `applied` event. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): pin warning-free rewrites in the positive bun golden cases The golden harness asserts warning codes only when a case ships `expected-warnings.json`, so a positive case without one (rerun-noop, basic, lock-v0, lock-v2, nested-entry, scoped-package, custom-registry) could degrade into a warning-emitting non-match that changes no file and still pass. Each now pins `[]`. No harness enforcement is added: ten non-bun no-`expected/` fixtures legitimately warn today and are shared with depscan's TS twin, which ignores the extra file. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): oracle carries bun_lockb_unsupported on every bun.lockb scan, records cliBuildSha, reports empty narrowings Every `scan` on a bun.lockb-only project now carries the run-level `bun_lockb_unsupported` layout warning in every mode, hosted included (the discovery pass never read the binary lock; the hosted driver's own `redirect_bun_lockb_*` outcome rides beside it on the run that migrates, nothing deduplicated). The oracle encodes that as a `layout` set folded into every bun.lockb band: the 0.8.1 / 1.0.0 `transitive` cells (mkdirp still installs, so a bun.lockb is left — `peer` leaves no lock and stays empty), the manual-migration and version-0-workspace refusals, the supported migrating runs and the vendored refusals; `get` shapes run no inventory pass and keep the driver's codes alone. Verified 104/104 on 0.8.1 + 1.0.0 (all shapes x 3 modes) and 12/12 on 1.1.39 + 1.4.2 against the base CLI with the pre-F1 rule, then 28/28 across every band against a base + lane-F1 build; the base binary fails exactly the two hosted lockb cells the new rule adds. `--cli-build-sha` (default `$CLI_BUILD_SHA`, else null) is recorded as `cliBuildSha` beside `cliRevision`, so PR rows carry the refs/pull/N/merge commit actions/checkout actually built. A `--versions/--shapes/--modes` narrowing that leaves no applicable cell prints a `::notice::`, writes a single `{"noCells": true, "passed": false, "error": …}` summary row and exits 0 instead of a red "0/0 passed" — the default shape list always holds `direct`, so an un-narrowed run can never go vacuous. The Bun 1.1.38 legacy baseline is fetched only when a `legacy-lockb` cell applies to a requested release. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci(bun): stage the legacy baseline, skip pre-1.1.0 on Windows, check the listing first, pass --cli-build-sha, fix the path filters Download step: pre-populate Bun 1.1.38 (the `legacy-lockb` baseline the script installs with on every other release) beside the matrix release or the dispatch override — de-duplicated, only when that shape is in play — so the script's in-job install_tool() fetch, and the GitHub-outage exposure it carried on 42 of 45 cells, is gone; check the SHASUMS256.txt listing BEFORE fetching the archive (a release without this OS's asset fails in one request instead of five 404 rounds); skip override releases before 1.1.0 on Windows with a `::notice::` (no Windows build exists) and export the staged releases through `steps.bun.outputs.versions`. Run step: consume that output, report `noCells` and pass when every requested release was skipped, and pass `--cli-build-sha "$CLI_BUILD_SHA"` so the provenance the comment promised is actually recorded. Path filters: the `crates/socket-patch-core/src/patch/bun_lock_text.rs` entries named a file that has not existed since #150 — now `vendor/bun_lock_text.rs`; the push list gains `Cargo.lock` (what rust-cache keys on), `vendor/**`, `commands/scan/**`, `vendor.rs`, `repair_vendor.rs` and `remove.rs`. The step logic was exercised locally with stubbed curl/python3 across six scenarios; yaml parse, pin-check grep and `zizmor --offline --min-severity medium` are clean. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(bun): contract, guide and changelog for the final-review fixes Contract rows and prose for the code landing in lanes F1/F2: `vendor` and the vendor step run the Bun vendored preflight BEFORE a hosted -> vendored takeover's revert (a refused lock leaves the hosted wiring, ledger and bun.lock untouched and reports `failed <code>`; `vendor --dry-run` previews the same code instead of `vendor_would_revert_redirect`); the already-vendored exemption is ledger-at-selected-uuid OR every matching bun.lock instance already a `.socket/vendor/npm/` tuple; a corrupt vendor ledger at the preflight is `vendor_state_unreadable` (added to the `failed`/`would_refuse` enumerations); `bun_lockb_unsupported` is kept in every mode, hosted included, and names a shadowed sibling lock; new hosted warning `redirect_bun_lockb_sibling_lock`; a bun.lockb that is not a regular file is refused before any spawn; the version-specific `vendor_bun_workspace_unsupported` remedy tail; Windows `.cmd`/`.bat` shims are spawned directly (std quotes batch paths); scan's human dry-run prints `[would-refuse]` lines like get's. The version-0 workspace remedy at all six sites (contract x2, ecosystems, guide row + measured bullet, changelog) is now "delete bun.lock and re-lock with Bun >= 1.2 (writes lockfileVersion 1)"; the in-place `bun install` bump is conditional on an inter-workspace dependency (root -> member, the only shape measured) — otherwise Bun 1.2.0 keeps 0 and 1.2.23+ fail to resolve. The older CHANGELOG "Hosted redirect unwind" bullet no longer calls the bun.lockb migration unrestorable by design (bytes ride the ledger; `redirect_bun_lockb_restored`; `redirect_bun_lockb_unrestorable` names git history only when bytes are absent or a different bun.lockb is present). The guide gains a "depscan TS parity" section (the TS_LAGGING entries the submodule bump needs, the expected-warnings.json harness requirement, the bun.ts porting items), a provenance note for the synthetic same-version nested entry in `lock-v2-workspace-nested`, a softened byte-identity sentence, the 0.8.1/1.0.0 transitive/peer oracle rows, the `cliBuildSha` provenance key, the noCells / Windows-skip dispatch behaviour and the widened push filter. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(bun): keep uuid-derived values out of assertion messages for CodeQL GitHub's default CodeQL setup raised eight rust/cleartext-logging alerts on the new bun tests: its name-based heuristic treats any value flowing from a `uuid`-named binding (a loop variable, a tuple holding `dep.uuid_h`, the `other_uuid` fixture) as sensitive when it reaches a panic/assert message. The values are patch identifiers in test fixtures, not secrets, but the repo keeps the check green on PRs, so the messages now describe the failed condition without interpolating those values and the uuid is bound apart from the vendor envelope it was paired with. No assertion got weaker: each still checks the same condition and prints the same envelope/lock context. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Mikola Lysenko <mik@socket.dev>

cursor Bot reviewed Aug 10, 2026

View reviewed changes

Comment thread crates/socket-patch-cli/src/commands/scan/mod.rs

Comment thread crates/socket-patch-cli/src/commands/update.rs

Mikola Lysenko (mikolalysenko) mentioned this pull request Aug 10, 2026

ci: stop counting docker-e2e/setup-e2e soft-skips as passing tests #151

Closed

Mikola Lysenko (mikolalysenko) mentioned this pull request Aug 10, 2026

fix(setup,scan): fail closed on corrupt manifests, JSON envelopes on every hosted failure; fetch_stage unit tests #152

Closed

Mikola Lysenko (mikolalysenko) and others added 4 commits August 10, 2026 10:58

This was referenced Aug 10, 2026

refactor(core): promote vendor/ to top level, rehome ecosystem strays, dissolve utils/ misfiles #153

Merged

refactor(npm): single-source npm-family file-name knowledge with drift-guard tests #154

Closed

Mikola Lysenko (mikolalysenko) and others added 4 commits August 10, 2026 11:09

Mikola Lysenko (mikolalysenko) changed the title ~~fix: bug-fix + test-harness sweep across CLI, crawlers, setup and CI~~ Structure-review batch: sweep fixes, module taxonomy, npm-family dedup, coverage gaps, CI honesty Aug 10, 2026

Wenxin Jiang (Wenxin-Jiang) approved these changes Aug 10, 2026

View reviewed changes

Mikola Lysenko (mikolalysenko) and others added 2 commits August 11, 2026 09:06

Mikola Lysenko (mikolalysenko) and others added 4 commits August 11, 2026 13:42

Mikola Lysenko (mikolalysenko) merged commit 08ea9ba into main Aug 12, 2026
119 of 120 checks passed

Mikola Lysenko (mikolalysenko) deleted the fix/sweep-bugfixes-and-test-harness branch August 12, 2026 16:53

Mikola Lysenko (mikolalysenko) mentioned this pull request Aug 12, 2026

chore: blame-ignore the #150 squash; retry the bun download in the npm image #156

Merged

Mikola Lysenko (mikolalysenko) mentioned this pull request Aug 14, 2026

fix(gem): production-safe bundler plugin — tolerant bootstrap, honest digest, project-scoped stamp #178

Merged

Mikola Lysenko (mikolalysenko) mentioned this pull request Sep 28, 2026

docs: v5 waste review + repacking-to-depscan design #286

Draft

Navigation Menu

Structure-review batch: sweep fixes, module taxonomy, npm-family dedup, coverage gaps, CI honesty - #150

Structure-review batch: sweep fixes, module taxonomy, npm-family dedup, coverage gaps, CI honesty#150
Mikola Lysenko (mikolalysenko) merged 16 commits into
mainfrom
fix/sweep-bugfixes-and-test-harness

Mikola Lysenko (mikolalysenko) commented Aug 10, 2026 •

edited

Loading

Uh oh!

cursor Bot left a comment

Uh oh!

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Aug 11, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Aug 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Mikola Lysenko (mikolalysenko) commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Verification

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Aug 11, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Aug 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Mikola Lysenko (mikolalysenko) commented Aug 10, 2026 •

edited

Loading