Speed up hosted and vendored scans: concurrent API requests, parallel crawl, single-pass rewriters

[Mikola Lysenko (mikolalysenko)]

Hosted and vendored scans spent most of their time in two places:

• waiting on HTTPS requests sent one at a time;
• per-ecosystem work that re-read, re-parsed and re-wrote the same files, plus an npm crawl that made one async round trip per filesystem call.

This PR makes the network phases concurrent and the crawlers and rewriters single-pass. It also adds lazy vendored sources, in-memory repacking and per-run parse memos, and ends with a small set of approved behavior changes.

Up to the approved batch, stdout, stderr, lockfiles, ledgers and exit codes are byte-identical to main. The approved changes are listed below and detailed in this comment.

Results

"Before" is main without this PR and "after" is this branch's head. Both use a replay proxy (recorded API responses served locally) at 100 ms/request, 2 interleaved reps, medians. Instructions retired are in parentheses.

The "before" binary predates #251–#254. #254 made cargo vendoring heavier, so the cargo rows understate the gain. Measured against the pre-batch head of this branch, cargo vendored fresh drops 49.6 → 38.9 G.

Target	Before	After
depscan scan --mode hosted --dry-run (live API)¹	18.3 s	4.1 s	4.5×
depscan hosted dry-run	17.1 s (17.9 G)	3.5 s (10.1 G)	4.9×
depscan hosted, real run (recorded latency)¹	35.8 s	7.5 s	4.8×
depscan vendored, fresh	46.3 s (28.8 G)	8.8 s (13.4 G)	5.3×
depscan vendored, idempotent re-run	16.3 s (28.9 G)	3.1 s (12.1 G)	5.3×
cargo (zed) hosted dry-run	36.4 s (204 G)	2.9 s (8.2 G)	12.6×
cargo vendored, fresh	63.5 s (66.8 G)	34.1 s (38.9 G)	1.9×
cargo vendored, re-run	20.7 s (50.0 G)	4.3 s (26.6 G)	4.8×
maven hosted dry-run	16.7 s (28.5 G)	2.8 s (3.3 G)	6.0×
maven vendored, fresh	61.5 s (55.1 G)	31.1 s (7.6 G)	2.0×
maven vendored, re-run	17.2 s (36.0 G)	3.1 s (5.1 G)	5.6×
nuget vendored, fresh / re-run	22.7 s / 7.0 s	11.8 s / 1.1 s	1.9× / 6.6×
composer vendored, re-run	8.0 s (7.2 G)	1.5 s (1.0 G)	5.4×
poetry hosted, real run	5.5 s (15.4 G)	1.4 s (4.5 G)	3.9×
uv hosted dry-run	4.2 s (15.1 G)	1.6 s (2.3 G)	2.7×
go hosted, real run	13.4 s	2.1 s	6.2×
strapi (yarn v1) hosted, real run, full clone¹	31.3 s	7.0 s	4.4×
187-project cross-ecosystem corpus, hosted / vendored¹	161.9 s / 136.0 s	111.7 s / 98.1 s	−31 % / −28 %

¹ Measured on the first slice of this PR and not re-run since.

• Byte equality (behavior-preserving part):
  • Every commit before the approved batch was A/B'd against the previous head.
  • The results were identical in all cases: stdout, stderr, the full project and home tree digest (locks, ledgers, vendored artifacts), the file list, and request counts. This held across 11 hosted/vendored fixtures and 9 ecosystems.
  • The integrated behavior-preserving tree was also identical to the original binary in all 35 steps × 2 reps.
• Request shape:
  • depscan hosted still sends 131 requests (56 batch + 74 by-package + 1 package-vendor), up to 8 in flight instead of 1.
  • Vendored fresh sends exactly main's 71 grants / 344 requests.
  • Cargo and uv send fewer requests only because of the approved deferred fetch (X1b).

What changed

Network (all ecosystems)

• utils/concurrent.rs is an ordered-concurrency helper (buffered, never buffer_unordered). Results, warnings and errors are folded in input order.
• By-package GETs, batch POSTs, hosted GET /patches/view, download views and vex record fetches run concurrently: 8 in flight on the API, 4 on the public proxy.
• The batch loop reproduces the proxy fallback exactly, at any chunk.
• The vendor prefetch plans downloads from each backend's own pre-flight gates, so it requests exactly what the serial loop will consume. Writes and wiring stay serial in record order, and the outage circuit breaker is replayed at consumption time.
• Lockfile-only packages are fetched concurrently.
• Telemetry is sent in the background and flushed before the next stdout write.
• New env var SOCKET_API_CONCURRENCY: 1 restores strictly serial requests. A tight descriptor limit falls back to serial automatically.

Crawl

• npm uses a parallel gather followed by an ordered single-threaded merge, checked against the old crawler kept as a randomized-equivalence oracle.
• The nine ecosystem crawlers run concurrently and merge in a fixed order.
• go, cargo, NuGet, site-packages and composer lookups run on one blocking task, with directory listings memoized only when complete.
• Maven POMs are parsed in parallel with bounded buffers.
• gem env and composer home are asked once per process.

Rewriters and vendoring

• Each lock is parsed once, indexed, and spliced in one pass. This covers pnpm (depscan 868 ms → 8 ms), npm, yarn classic/berry, bun, composer, uv/pylock/PEP 723, poetry/pdm, go.mod/go.sum and Cargo.lock (block search stops at the next [[package]]). The old rewriters are kept as oracles.
• Backend parse memos per run: Cargo.lock/config, composer.lock, packages.lock.json, the pypi locks, the JS lockfiles and the hatch ledger.
• Lazy vendored source: a fetched package is extracted only where something reads it.
• Zip members are inflated on a bounded pool, by name.
• Jars, nupkgs and wheels are rebuilt from memory. Digests are computed where the bytes are already verified.
• sha2 uses the aarch64 SHA-256 instructions.

Tooling: scripts/perf/ holds the record/replay benchmark harness.

Behavior changes (approved)

Details and measurements are in the batch comment.

• Ledger schema version 2 (X11): whole-file wiring snapshots (maven, nuget, pylock/PEP 723/hatch) are stored as {snapshot, ops} edits of the record's own original. Version 1 ledgers are still read and revert byte for byte. Other ledgers stay byte-identical v1. state.json shrinks: maven 29.8 → 15.1 MB, pylock 43.9 → 22.0 MB, nuget 7.2 → 3.9 MB.
• Deferred pristine fetch (X1b): a purl the ledger already covers, and a cargo crate the patch service serves, is not downloaded up front. An in-sync --offline / network-less re-run now succeeds (already_vendored, exit 0), and re-runs no longer report vendor_fetched_missing.
• -e <eco> crawl scope (MVN-4): without --prune/--sync, only the named ecosystems are crawled. lockfileOnlyPackages counts only them (depscan+zed -e npm: 6920 → 5347).
• Maven coordinates from the ~/.m2 path (MVN-1): canonical POMs are not opened once their top-level group directory is confirmed. A hand-placed POM that disagrees with its path reports the path's coordinates.
• Per-run group commit with journal replay (V2): lock/manifest/config/ledger edits are committed once per run through .socket/vendor/.commit-journal.json. A crash leaves the pre-run wiring, or is rolled forward by the next locked command. A failed commit write now fails the run with the new top-level error vendor_commit_failed (exit 1), replacing the per-purl vendor_state_write_failed / redirect_ledger_write_failed events; locks and ledgers stay pre-run, and artifacts written in the loop remain until the next run. vendor_stale_artifact_removed events now follow the per-package events.
• fsync policy (X12): vendored artifacts are written without a per-file fsync. One durability barrier runs before every durable commit point and at the end of the run, and lockfiles and ledgers stay durable.
• Caveat: the crash/journal and fsync semantics are covered by unit, failpoint and injection tests only, not by a live crash fixture.

Resolved: exact plan, 71 grants

The earlier prefetch planned download grants before each backend's pre-flight checks ran, so depscan sent 74 grant POSTs where main sends 71. The plan now calls each backend's own pre-flight gates, so fresh depscan vendoring sends exactly 71 grants and 344 requests, with 0 replay misses. Parity tests pin each npm flavor's plan against its loop, refusal for refusal.

Other observable differences

• With --debug, the [socket-patch debug] GET/POST <url> lines for concurrent requests interleave. Normal warnings keep serial order, and tests pin that.

Test plan

• cargo clippy --workspace --all-targets -- -D warnings is clean.
• cargo test --workspace --no-fail-fast: 9,218 passed, 0 failed, 136 ignored. No existing test was ignored or deleted. All existing test edits pin an approved behavior change: the two ledger-write-failure tests in covgap_commands_vendor.rs now expect the new vendor_commit_failed envelope error instead of a per-purl failed event (V2), and the redirect one no longer asserts that the artifact is absent, since it is written before the commit fails. It asserts instead that nothing is committed or rewired and no journal remains. The v1 legacy-ledger fixture for cargo was regenerated with the pre-batch binary to match main's Wire vendored cargo patches through Cargo.toml and tag the copy #254 cargo wiring. Every other change before the approved-behavior batch kept all existing assertions unchanged.
• New tests:
  • ordering under reversed latencies;
  • proxy fallback at any chunk;
  • telemetry flush;
  • crawler, rewriter and lazy-source equivalence against oracles;
  • plan-vs-loop parity for every npm flavor;
  • SOCKET_API_CONCURRENCY=1 and tight fds;
  • failpoint crash tests at the durability barrier and inside the group commit;
  • journal replay, set-aside and restore-failure paths;
  • ledger v1 ↔ v2 round trips for every ecosystem.
• Every commit went through adversarial review for behavior equivalence, concurrency and test integrity. Each finding was fixed or refuted with evidence.
• A/B benchmarks with byte-equality checks for every batch, as above and in the batch comments.

The commits are the original reviewed commits, replayed onto current main (#251–#254). Where a conflict or an adaptation to main was needed, it is folded into the commit that needed it, and each batch comment lists them.

🤖 Generated with Claude Code

---

Note

High Risk
Changes vendoring crash semantics, ledger schema, offline/idempotent vendor behavior, Maven discovery coordinates, and concurrent API failure modes—areas that affect committed project state and patch correctness.

Overview
This PR speeds up hosted and vendored workflows by running patch-API traffic concurrently (default 8 authenticated / 4 on the public proxy) via ordered_concurrent, with SOCKET_API_CONCURRENCY (1–32) to throttle when a proxy or WAF limits in-flight requests. The same pacing applies to vex / scan --vex record fetches and hosted wheel-metadata downloads; hold_back_debug keeps per-request --debug lines in the same order as the old serial loop.

Beyond networking, it lands several v5.0 contract changes documented in CHANGELOG / CLI_CONTRACT: deferred pristine fetch so already-vendored / service-backed cargo re-runs can succeed offline without upfront registry pulls; scan -e crawls only selected ecosystems (except prune/sync); Maven derives coordinates from canonical ~/.m2 paths when the repo root is confirmed; vendor ledger v2 stores large whole-file wiring as snapshot+ops edits; one group commit per vendored run through .socket/vendor/.commit-journal.json (new top-level vendor_commit_failed on commit I/O failure); and batched fsync for artifacts before durable lockfile/ledger writes.

Smaller fixes include vex api_auth_fallback quoting the first refusal in pending order (not completion order), batched gem/Python stale-install probes using judge_installed_record, and confirm_waits so scan knows when a hosted confirm prompt will block.

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

[Mikola Lysenko (mikolalysenko)]

WP-P2 pushed: cfeafb0c..5492794c (19 commits cherry-picked from perf/pp2, no conflicts)

Items

• H1: Aho-Corasick presence probe. Hosted redirect confirmation makes one multi-needle pass per lock text instead of one scan per needle.
• H4: parallel rewriter groups. Independent hosted rewriter groups run concurrently. A group runs inline if the OS refuses its thread. A group oracle pins the cross-rewriter reads.
• H3: embedded --vex reuses the crawl snapshot. Hosted scan --vex answers its copy lookup from scan's npm crawl. It walks node_modules again after a waiting prompt.
• DC-1: walk pool 4 / perf-cores + SOCKET_WALK_THREADS. The node_modules and Maven walks run on 4 threads by default (fewer on machines with fewer performance cores). SOCKET_WALK_THREADS overrides this.
• H2-code: adaptive windows. Each patch-API window is sized from its own request count.

Before → after (PR head cfeafb0c → 5492794c, release builds, replayed stores, single runs)

run	before	after
polyglot hosted dry Dmitri Iouchtchenko (@0) ms	3.61 s / 40.2 G instr	2.03 s / 24.9 G
polyglot hosted wet Dmitri Iouchtchenko (@0) ms	3.45 s / 40.6 G	1.56 s / 25.2 G
polyglot vendored fresh Dmitri Iouchtchenko (@0) ms	8.74 s / 107.1 G	7.87 s / 100.8 G
polyglot vendored rerun Dmitri Iouchtchenko (@0) ms	3.69 s / 40.0 G	2.67 s / 33.9 G
polyglot hosted wet Devin Soni (@100) ms	18.42 s	5.82 s (concurrency 32)
depscan hosted dry ×2 Dmitri Iouchtchenko (@0) ms	1.77 / 1.46 s (11.7 / 10.5 G)	1.49 / 1.46 s (10.0 / 10.0 G)
depscan vendored fresh ×2 Dmitri Iouchtchenko (@0) ms	1.70 / 1.60 s	1.71 / 1.59 s (flat)

Equivalence gate. In every polyglot step at 0 ms (hdry, hwet, vfresh, vrerun), canonical stdout, the full work-tree digest, request count and per-ecosystem purls are identical to cfeafb0c. Depscan is identical too: hosted dry stdout, and vendored fresh stdout, lock, workspace, package.json, state.json, files and markers. The polyglot tree has 5 signed CACHEDIR.TAG dirs (target/, build/, tools/patcher/target/, two .venv/). None contains a node_modules, so the pruning is not expected to change output here, and it does not.

⚠️ Behavior changes (approved)

• API concurrency 8 → 32. The window is adaptive: n/4 of a step's requests, clamped to 8..32. VEX record fetches go up to 10. The public proxy stays at 4. SOCKET_API_CONCURRENCY overrides the cap (1-32; on the proxy it can only lower it).
• CACHEDIR.TAG pruning. A node_modules inside or below a directory with a signed CACHEDIR.TAG is no longer crawled. The scan root is always crawled. This reaches scan, scan --prune / --sync (such a package counts as not installed and is garbage-collected unless a lockfile resolves it), and the discovery of apply, rollback, remove, repair, vendor, get and vex.
• Bounded 429/503 retry.
  • Policy: every patch-API JSON call retries up to 3 times. A Retry-After is honored; one over 30 s gives up at once, and one under the jittered first step (0, a past date) is floored to it. Without one, backoff is 0.5 / 1 / 2 s (steps capped at 8 s) with equal jitter. All retries in a run must end within a 60 s wall-clock window opened by the first retry, so parallel waits overlap instead of adding up.
  • SOCKET_API_MAX_RETRIES (0-10; 0 = old single attempt).
  • Never retried: 401/403, which still drive the proxy fallback, and the proxy's permanent 503 "Patch API is not configured" on any path.
  • New error text names why retrying stopped: (gave up after 3 retries), (Retry-After <n> s exceeds the 30 s retry cap), (the run's 60 s retry window has closed). An over-capacity 503 is the typed ApiError::ServiceUnavailable.
  • New additive --json run-level warnings: api_batch_failed and patch_details_failed.
  • Legacy proxy batch: on a token-less proxy without POST /patch/batch, a package still throttled after its retries fails its whole batch query instead of being skipped silently.
  • Listed under CHANGELOG "Changed (BREAKING)" and the semver note; the --json warnings are under "Added".

Tests

cargo clippy --workspace --all-targets -D warnings is clean. cargo test --workspace --no-fail-fast on the PR head: 9273 passed, 0 failed, 136 ignored.

Review notes

• pp2: 3 adversarial reviewers, then a fixer.
• The retry got a dedicated adversarial reviewer, then a fixer. Its fixes landed in fix(api): bound retries by a wall-clock window; never retry "not configured":
  • The summed 60 s budget starved concurrent requests; it is now a wall-clock window.
  • A Retry-After over the cap now gives up at once, and 0 / past dates are floored.
  • The "not configured" 503 is no longer retried or treated as throttling on per-package and view calls.
  • Throttle classification is typed instead of matched on a message prefix.
  • New test: a persistent 503 / 429 on the proxy batch makes zero per-package GETs.
• Pushed commit subjects keep their original ! markers. fix(scan)! (the --json warnings) is additive and is documented under "Added"; history was not rewritten.
• Known pre-existing follow-up, unchanged here: two paths still drop failures silently, the scan/discovery.rs baseline view and repair_vendor.rs's .ok()??.

🤖 Generated with Claude Code

[Mikola Lysenko (mikolalysenko)]

Merged origin/main (#256) into this branch as 2b380e3. It's a merge commit, not a rebase or force-push.

CI was red because GitHub builds the PR merged with main. #256 removed CARGO_TOML_PACKAGE_RE and dropped the capture group from CARGO_TOML_REGISTRY_VAL_RE, and switched cargo manifest reads to parsing values as TOML (cargo_toml_string / cargo_toml_inline_string). The only code of this branch still on the old regexes was CargoRegistryPins::of, the one-pass-per-manifest pin extractor behind the vendored cargo PIN_MEMO.

Resolution:

• CargoRegistryPins::of now reads values the same way Fix Cargo hosted workspace redirects #256's cargo_socket_registry_pin does. That covers header-table and dotted keys via cargo_toml_string, and inline tables via cargo_toml_inline_string. cargo_socket_registry_pin is still its #[cfg(test)] equivalence oracle, now with Fix Cargo hosted workspace redirects #256's semantics.
• The V-7 pin-equivalence corpus now includes Fix Cargo hosted workspace redirects #256's spellings: literal strings, quoted inline keys, and a trailing comment on a header-table line.
• Everything else from Fix Cargo hosted workspace redirects #256 merged untouched: workspace-inheritance resolution, (name, version) lock owners, validate_cargo_toml_pins, and annotated [registries.*] headers. This branch's lock_block_end bounded search and its oracle, the parse memos, the presence probe and the parallel rewriter groups needed no changes.

Verification:

• clippy --workspace --all-targets -D warnings is clean.
• cargo test --workspace --no-fail-fast: 9286 passed, 0 failed, 136 ignored. That includes Fix Cargo hosted workspace redirects #256's new cargo tests and every cargo redirect and equivalence test.
• Cargo zed hosted dry run at 0 ms: output is identical to origin/main. It retires 9.76G instructions, against 9.82G on main@Fix Cargo hosted workspace redirects #256, 8.0G on this branch before the merge, 8.26G on main@Wire vendored cargo patches through Cargo.toml and tag the copy #254, and 203.5G on the old baseline. The roughly 1.5G Fix Cargo hosted workspace redirects #256 added shows up on main as well.
• Polyglot hosted dry and wet runs at 0 ms: stdout and full work-tree digests are identical to main@Fix Cargo hosted workspace redirects #256 (95dcaa380de0 / aead384e6318), at 27G instructions versus 95G on main.
• CI: all 417 checks pass on 2b380e3.

🤖 Generated with Claude Code

[Mikola Lysenko (mikolalysenko)]

WP-P3 pushed: vendored-loop prefetch across ecosystems, pre-staging, early lock refusals (2b380e3 → 35a42b0, fast-forward)

• Per-backend gate refactor (9d4c024c): each service-backed backend (cargo, composer, gem, golang, maven, nuget, pypi) now has a pre-service prelude plus a service_preflight plan gate. The checks, their order and their outcomes are unchanged.
• V-1: exact cross-ecosystem prefetch with a slow-start window (1074b871, 4738e4c5): the download plan now covers every service-backed record, not only npm, and each backend's own gate keeps out the packages that backend refuses first. That keeps the plan exact: a refused package gets no download grant. The prefetch window starts at 4, grows by one per good answer up to the API's in-flight cap, and drops back to 4 on an availability failure. A 128 MiB budget limits how many fetched archives wait for the loop: it stops new downloads from starting, but downloads already in flight still finish, so held bytes can go over it.
• V-3: pre-staging (976f3e39, 8298526d): verified archives are extracted next to each backend's stage while the loop runs, and the backend claims the result with one rename. Trees left behind by a crashed or interrupted run are removed at the start of the next wet vendor loop. Dry runs delete nothing.
• V-4a: early lock-text refusal (895dd939, narrowed in 0bc98bf8): the behavior change described below.

Before → after (replay harness, polyglot monorepo and depscan)

run	PR head before (2b380e30)	after (35a42b0c)
polyglot scan --mode vendored, fresh, 100 ms RTT	107.2 s	14.8 s
polyglot vendored fresh, 0 ms	8.26 s (2250 req)	7.01 s (2167 req)
polyglot vendored re-run, 0 ms	2.82 s (791 req)	2.89 s (708 req)
depscan vendored fresh, 100 ms (×2)	7.50 / 7.32 s (344 req)	4.24 / 4.20 s (341 req)

Output equality

• V-1 + V-3 change nothing observable. Against this PR's previous head, polyglot fresh and re-run at 0 ms produce byte-identical work trees (digest abfa49ef5bc7 for both binaries, both steps), with 0 replay misses. Stdout is identical after sorting arrays. The only differences are the V-4a records listed below.
• The depscan vendored fresh run (a copy containing only the lockfiles) produces an identical lock, workspace, package.json, ledger, vendored files and markers. Stdout differs only by the V-4a records listed below.

⚠️ Behavior change (approved): lock-text refusals happen before the download

On scan --mode vendored and get --mode vendored (both the search path and the uuid path), some packages are now refused before their patch view is fetched:

• Which refusals: the pnpm, yarn classic and yarn berry lock-text gates, and cargo's locked_version_mismatch when it is the crate's first refusal. These packages are now refused before their patch view, and any pristine source, is fetched.
• Which packages: only packages the vendor loop would actually hand to its backend. That means a package installed on disk, or one the lockfile resolves to a verifiable registry source.
• What moves: each such package becomes a download.patches[] record with action: "failed" and the backend's exact errorCode and error.
• Count changes: download.downloaded goes down and download.failed goes up by the number of these packages. vendor.events loses their failed events, and vendor.summary.failed drops by the same number. For lockfile-only packages, their vendor_fetched_missing events also disappear.
• Nested status: vendor.status becomes success when these refusals were the vendor step's only failures (depscan: partialFailure → success).
• What does not change: the exit code and the top-level status (partial_failure, exit 1).
• What stays as it was: a package that is absent from the lock and not installed never reached a backend. It still downloads and stays skipped / package_not_installed, exactly as before. As a result, cargo refuses early only a crate that is installed at an unlocked version.
• Also unchanged: purls claimed by the hosted redirect ledger, and all purls when that ledger is malformed; other lock flavors; --dry-run.
• Precedence: because the view is never fetched, the lock refusal now wins over outcomes that come from the view (a paid-access 403, a failed view fetch, the no-applicable-files guardrail). The Bun refusal and the ledger's already-vendored skip still come first.
• Manifest-driven vendor: the failed events stay. A refused lockfile-only package that the lock resolves is no longer fetched, so there is no vendor_fetched_missing event and no registry request. With the registry unreachable, the lock-gate code replaces vendor_fetch_failed.
• Measured:
  • Polyglot (fresh and re-run): 80 packages move to the download phase (74 vendor_lock_entry_not_found, 4 vendor_override_conflict, 2 vendor_lock_entry_unsupported). For every one of them, the old vendor-loop refusal had the same code and wording. That saves 80 views and 3 registry tarballs per run.
  • Depscan: 3 packages move (2 vendor_lock_entry_unsupported, 1 vendor_override_conflict).

Tests

cargo test --workspace --no-fail-fast: 9316 passed, 0 failed (136 ignored); cargo clippy --workspace --all-targets -D warnings clean. The PR head is the exact commit that was tested.

New tests (10), each shown to fail when the fix it covers is removed:

• V-4a scope: pnpm and cargo, across scan, exact-purl get and vendor.
• The plan gate: plan_service_downloads directly, plus the composer zero-grant e2e, now with the refused package in the middle of the plan.
• Stale pre-stage cleanup: a core unit test, and an e2e covering --offline and --dry-run.
• Slow-start window: the window arithmetic, opening at 4 inside a 32-wide cap, and growing to exactly the cap.

The yarn cacheKey refusal tests again check that the vendor step emits nothing for the refused package.

Review

One adversarial reviewer raised 8 findings; all are addressed in the commits above:

• the V-4a scope was too wide (narrowed);
• the composer gate test never exercised the gate (fixed and unit-tested);
• stale .socket-prestage trees were never removed (now cleaned up at loop start);
• the prefetch window jumped from 4 to 32 (now slow-starts);
• the byte budget and pre-stage limits were undocumented (documented);
• the new precedence over view outcomes was undocumented (documented);
• the lock-text dry run passed an empty installed path (fixed);
• the yarn tests had lost their vendor-step assertion (restored).

🤖 Generated with Claude Code