[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1633

Summary

Vendored vlt mode now refuses a package whose preprepare or postprepare script vlt build would run inside the committed vendor directory. Before, such a package was vendored with exit 0, and the next vlt ci rewrote the artifact. After that vendor --check and vex failed, and repair looped.

Root cause

vlt_build_steps (crates/socket-patch-core/src/vendor/npm_dir.rs) lists what vlt build runs in a package's own directory. Vendored vlt refuses any package with a non-empty result (vendor_vlt_build_scripts_unsupported). The list had preinstall, install, postinstall and prepare. vlt also runs preprepare and postprepare for a prepable (file:) node, and each one runs even when it is the package's only script: vlt's nodeNeedsBuild tests prepare || preprepare || postprepare.

Changes

• vlt_build_steps now covers all six scripts. This one helper backs both the read-only preflight (vlt_vendor_preflight) and the staged-download refusal, so both now refuse.
• Reuse path: a directory that an earlier release already vendored (and committed) used to be reused without any build-step check. Re-running vendor / scan --mode vendored on it now gives the same refusal (--mode hosted) instead of success, so projects that are already in Vendored vlt scan accepts a package with a preprepare or postprepare script, which vlt ci then runs inside the committed vendor directory, so vendor --check and vex fail and repair loops #1633's broken state get told what to do.
• The refusal detail lists several steps as "a, b and c" rather than "a and b and c".
• docs/ecosystems.md and CLI_CONTRACT.md now name all six scripts.

Test evidence

Red→green regression tests for #1633. Each was run failing before the fix and passing after it:

• vendor::npm_dir::tests::vlt_build_steps_name_every_script_vlt_build_runs_in_place: preprepare-only and postprepare-only manifests (before: left: []).
• vendor::vlt_lock::tests::the_preflight_decides_every_refusal_without_writing: preflight refuses both scripts.
• vendor::vlt_lock::tests::a_prepare_family_only_package_refuses_on_the_local_build: a full vendor run refuses both scripts, writes nothing, and leaves the lock untouched.
• vendor::vlt_lock::tests::a_dir_vendored_with_a_postprepare_script_refuses_on_reuse: the committed dir was vendored before the fix, the installed copy is clean, and the dir is refused on reuse (dry run and real run) with the lock unchanged. With the reuse check disabled, this test fails.

Local runs:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test --workspace --all-features --no-fail-fast: 232 suites ok. 4 suites had environment-only failures, none in vlt build-step code: e2e_bun_lockb and vlt::scan_redirect_vlt_heal_invalidation_failure_warns need network, and the rest are write-failure/unremovable-file tests that can't fail as root in this container.
• e2e_vendor_vlt_build with vlt 1.2.0: couldn't run here, because the container's proxy blocks the suite's npmjs fetch (could not fetch left-pad@1.3.0 from npmjs). CI runs it on Linux/macOS/Windows.

Per-issue checklist

• Vendored vlt scan accepts a package with a preprepare or postprepare script, which vlt ci then runs inside the committed vendor directory, so vendor --check and vex fail and repair loops #1633 postprepare-only: unit, preflight, staged-run and reuse tests
• Vendored vlt scan accepts a package with a preprepare or postprepare script, which vlt ci then runs inside the committed vendor directory, so vendor --check and vex fail and repair loops #1633 preprepare-only: unit, preflight and staged-run tests
• Docs: docs/ecosystems.md vlt notes and CLI_CONTRACT.md refusal row

Review notes (/code-review high)

• I didn't share a constant with the six-name list in bun_lockb.rs. That list is bun.lockb's binary field order for its script table, which is a different contract from "what vlt runs in place". Coupling the two would let a change to one silently change the other.
• The empty "Start fix" commit comes from the agent claim protocol. The PR is squash-merged.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

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

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

[Mikola Lysenko (mikolalysenko)]

Labeled Ready for review (burn-down agent).

• Head: 8ab8b124
• CI: all checks green on the head (success/skipped only); mergeable, no conflicts; no CHANGELOG.md change.
• Bugbot: reviewed 8ab8b124, no findings; 0 open review threads. Already approved by Tanmay Singla (@Tanmay182003) on this head.
• Worth a look: the reuse check in vlt_lock.rs that refuses already-vendored dirs carrying preprepare/postprepare scripts.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

The merge queue dropped this PR at 18:02 UTC. The failing check was e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0), in run 39470447347.

• What failed: pipenv::pipenv_pylock_projects_wire_what_pipenv_installs. uv pip install -r pylock.toml exited 2 with The target environment is not supported by the lockfile.
• Why it isn't this PR's: the diff only touches vlt vendoring (npm_dir.rs, vlt_lock.rs, docs). It doesn't touch pipenv, pylock or uv. The same leg passed two minutes later on queue commit 947f8dfe for Fix yarn copies with invalid manifest names (#1598) #1605, and that tree already contains this PR's change.
• Fix: none exists yet. The pylock test looks non-deterministic in the uv environment, so it should get its own issue.

I'm re-queuing once. If the leg fails again, I'll treat it as a real failure.

---

Generated by Claude Code