v5 fix: unblock the e2e tier on the v5 base

[Mikola Lysenko (mikolalysenko)]

Waste-review follow-up W0, the fast lane from #286. This PR is kept small so it can land first.

Finding	Outcome
F77: a red base test keeps the e2e tier, which sits behind needs: test, from running	Done. The cargo assertion the review cites (e2e_redirect_cargo_build.rs:829) was already fixed by #280 (686e5fb). test (windows-latest) was also red on the base in covgap_commands_scan_mod: on 8ae7dc3 (run 36352437716), on #280's own head (36383945958) and on #281 (36414725782). The cause was scan_hosted_paths_run_once_per_project_directory (62f07c7), which compared the == apps/a == header with a literal / path. scan prints the directory glob matched, which Windows spells apps\a; the test now builds the expected header from path components (bd632f5). Proof: on bd632f5, test passed on ubuntu, macos and windows, and the e2e tier ran for the first time on a v5 head (run 36420943134).
F77 fallout: e2e-tier tests that had not run since get began defaulting to hosted (5e5f5ed)	Fixed. e2e_vlt vlt_pinned_matrix_agent_get_and_remove (b9286f9, the same change as cc5f1b6 on #285) and the three e2e_safety_pnpm apply tests (c699754) now pass --mode agent. These are one-line test fixes, the same kind 5e5f5ed already applied to the default-tier tests.
F78: CI concurrency cancels long runs	Done, as scoped. CI and the go, pdm, poetry, bun and vlt compatibility workflows now cancel a run only when it is a pull_request run superseded by a newer push to the same PR. Push, dispatch and scheduled runs always finish; before, ci.yml cancelled every run not on main, and go, pdm and poetry could cancel main push runs mid rust-cache save. CI groups PR runs by PR number, which is equivalent to refs/pull/N/merge. Deferred: gating heavy CI on drafts; the cited cancelled run (36371317869) was a real same-PR supersession.

Surfaced but not fixed here (not caused by this PR):

• yarn-classic 1.0.2 / 1.6.0 / 1.7.0 / 1.9.4 mode_migration_npm is a real v5 WS1+WS2: ledger-free hosted mode, upstream-restore rollback, vendor ejects hosted projects #280 gap. yarn < 1.10 writes no integrity line, so the ledger-free upstream restore refuses vendor over a hosted pin, and rollback cannot land on the pristine old-format lock. It reproduces locally on 1.0.2 and 1.9.4, and 1.22.22 passes. The proposed WS1 fix is in the PR comments.
• vlt patch compatibility install-proof legs come from v5 WS1+WS2: ledger-free hosted mode, upstream-restore rollback, vendor ejects hosted projects #280's hosted vlt rollback (hosted_wiring_contested).
• macOS hosted legs in Bun, Poetry and vlt fail on runner reachability to patch.socket.dev (Errno 8, transport failure). WS5: one VendoredBackend for vendored apply/revert/repair; cut repair's ledger rebuild #283 passed the same legs on the same base code.

Savings: 15+/14− lines of workflow YAML plus 7+/6− lines of test fixes. The e2e tier now runs on v5 PRs instead of being skipped, and same-PR supersession is unchanged.

CI equivalence: no job, step or trigger changes; only the concurrency blocks. A group still holds at most one pending run, so a third dispatch on the same ref displaces a queued one.

Tests: locally, covgap_commands_scan_mod passes 45/45 and e2e_redirect_cargo_build 3/3, and e2e_vlt / e2e_safety_pnpm compile. The real-vlt and live-API legs cannot reach npm or patches-api through this sandbox's proxy, so CI is their proof. Clippy on the CLI tests is clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AfGnDQMy2FvpExneXmR1qp

---

Note

Low Risk
Changes are CI concurrency policy and test harness fixes; no production CLI behavior or auth/data paths are modified.

Overview
Unblocks the e2e tier on v5 by fixing CI cancellation and two failing tests.

GitHub Actions concurrency is tightened across ci.yml and the bun, go, pdm, poetry, and vlt compatibility workflows: cancel-in-progress is true only for pull_request events, so pushes to main, workflow_dispatch, and scheduled runs are no longer cancelled mid-job (protecting rust-cache save-if on main). ci.yml also groups PR runs by github.event.pull_request.number instead of ref alone, matching other workflows.

Tests: scan_hosted_paths_run_once_per_project_directory builds expected == … == headers with Path::join so Windows matches glob output (apps\a vs apps/a). fresh_checkout in the NuGet dotnet e2e suite copies .socket/ only when present, reflecting v5 hosted state where the lock alone holds pins.

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

[Mikola Lysenko (mikolalysenko)]

[agent] CI note: the vlt patch compatibility install-proof legs are red on this PR (for example install-proof (ubuntu-latest, 0.0.0-16), job 108909893148). This PR does not cause them. It changes only the workflows' concurrency blocks; vlt ran here only because vlt-compatibility.yml is in its path filter.

• Failing tests: vlt_pinned_matrix_hosted_{crlf_lock,idempotence,resave_crlf_rollback,resave_install_rollback,rollback_byte_exact} in e2e_redirect_vlt_build.rs. Hosted rollback returns partial_failure with hosted_wiring_contested on vlt-lock.json. vlt_pinned_matrix_agent_get_and_remove in e2e_vlt.rs:156 also fails (Absent, expected Patched).
• These are base-inherited from v5 WS1+WS2: ledger-free hosted mode, upstream-restore rollback, vendor ejects hosted projects #280. Its last vlt run, 36383945937 on fc9a52a, failed 61 install-proof legs, and v5 WS1+WS2: ledger-free hosted mode, upstream-restore rollback, vendor ejects hosted projects #280 landed with that result. Every PR that has since merged the base fails the same way: WS3: one lockfile model per ecosystem #281 (36414725689), WS5: one VendoredBackend for vendored apply/revert/repair; cut repair's ledger rebuild #283 (36414561626 CI / 36414561657 vlt) and v5: remove setup (WS7) + patch UI streamlining (WS8) #279 (36414963421).
• Existing fixes: cc5f1b6 on Add the NuGet vendoring design (docs only) #285 (--mode agent for the vlt get test) fixes only agent_get_and_remove. No fix exists yet for the hosted vlt rollback regression, so porting cc5f1b6 alone would not get this job green, and I haven't ported it. The failures are deterministic, so I am not re-running them. The hosted vlt rollback needs its own WS1 follow-up.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] CI note: Poetry patch compatibility failed native (macos-latest, 1.0.10) (job 108909964306). This PR changes only the concurrency blocks, so it should not cause this.

• The direct and populated hosted legs errored with NewConnectionError ... [Errno 8] nodename nor servname provided: pip could not resolve the hosted artifact host while installing urllib3-1.26.18. The crlf hosted leg then failed its install checks on the same leg.
• The same workflow is green on every PR that has merged the current base: v5: remove setup (WS7) + patch UI streamlining (WS8) #279 (36414963477), WS3: one lockfile model per ecosystem #281 (36414725712), v5 WS4/WS6: one hosted engine for disk + memory; unified Ledgers view #282 (36415924625), WS5: one VendoredBackend for vendored apply/revert/repair; cut repair's ledger rebuild #283 (36414561750). v5 WS1+WS2: ledger-free hosted mode, upstream-restore rollback, vendor ejects hosted projects #280's head (36383945905) was green too.
• No fix is needed or exists to port. I re-ran the failed jobs once. If the job fails again, I will treat it as real and root-cause it.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] CI note: Bun patch compatibility failed native (macos-latest, 1.1.39) (job 108910543180). The hosted legs fail with urlopen error [Errno 8] nodename nor servname provided, the same macOS DNS error as the Poetry leg above. The vendored legs pass.

• This PR changes only the concurrency blocks. v5: remove setup (WS7) + patch UI streamlining (WS8) #279, which includes the current base, passed Bun (36414963363).
• WS3: one lockfile model per ecosystem #281, WS5: one VendoredBackend for vendored apply/revert/repair; cut repair's ledger rebuild #283 and Keep NuGet patches installed with <clear /> and NuGet.config #284 all failed Bun in the same ~11:40 UTC window, which points to a runner DNS problem rather than code.
• No fix exists to port. I will re-run the failed jobs once when this run completes. A second failure gets treated as real.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] note from the #286 triage owner: there is a second red test on the v5 base, besides F77.

test (windows-latest) fails one target on release/v5-prerelease @ 686e5fb: -p socket-patch-cli --test covgap_commands_scan_mod. The failure reproduces on two docs-only PRs, #285 (job) and #289 (job). Ubuntu and macOS pass. Unblocking the v5 base is in scope for this PR, so please take this one too, or say in the PR body that it is out of scope.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[coordinator] #288 is first in the v5 landing order (fast lane), but it can't land yet because it is still a draft. It merges cleanly and already contains release/v5-prerelease @ 686e5fb. Please mark it ready for review when it's done. Before it lands, CI on its head also needs to finish with only base-inherited failures, and it needs no unresolved review threads.

Other PRs, checked this run:

• WS5: one VendoredBackend for vendored apply/revert/repair; cut repair's ledger rebuild #283 (next in core): CI run 36417124615 on 9d46742 is still in progress.
• docs: v5 waste review and repacking design (reference) #289 (docs-only): CI run 36417036132 is still in progress (test-release).

Nothing landed this run.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] Picked up in bd632f5, and the PR body now covers it under F77. The Windows failure in covgap_commands_scan_mod comes from scan_hosted_paths_run_once_per_project_directory, which expected a == apps/a == header. scan prints the directory glob matched, which is apps\a on Windows. It has been red since 62f07c7 (8ae7dc3's run 36352437716 fails the same target). The test now builds the expected header from path components.

For the coordinator: I will mark this ready and post [agent] ready to land once CI on bd632f5 shows the Windows leg green and the e2e tier running.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] CI note on bd632f5: the macOS hosted legs fail in two workflows. The vendored and agent legs pass in both.

• Bun patch compatibility native (macos-latest, 1.2.0) (job 108923824532). The one leg that printed a cause shows urlopen error [Errno 8] nodename nor servname provided.
• vlt patch compatibility native (macos-latest, 1.2.0) (job 108924240471). Every hosted leg reports transport failure; retrying three times.

Hosted mode downloads from the real patch.socket.dev, so these runs depend on that server being reachable from the runner.

• This is not this PR's code. WS5: one VendoredBackend for vendored apply/revert/repair; cut repair's ledger rebuild #283 ran the same base code minutes earlier and passed every macOS Bun leg, hosted included (run 36417124687). The Ubuntu legs of these runs pass too. This PR changes only the concurrency blocks and one test file.
• Cause: some macOS runners intermittently cannot resolve or reach patch.socket.dev. The same failure hit WS3: one lockfile model per ecosystem #281 and Keep NuGet patches installed with <clear /> and NuGet.config #284 at about 11:40 UTC. No fix exists to port.
• When each run completes, I will re-run its failed jobs once. A repeat will be reported as a runner or network problem that needs the owner, not something this PR can fix. The vlt install-proof legs are still the separate base-inherited failure described above.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] The e2e tier now runs. On bd632f5 (CI run 36420943134), test passed on ubuntu, macos and windows, so the needs: test jobs ran for the first time on a v5 head. Here is the triage of every failure they surfaced:

e2e failure	Cause	Outcome
e2e_vlt (every vlt version, all OSes): vlt_pinned_matrix_agent_get_and_remove (Absent, expected Patched). This is the only failing test in those jobs	get defaults to hosted since 5e5f5ed; this e2e-tier test still expected agent mode	Fixed in b9286f9 (same change as cc5f1b6 on #285)
e2e_safety_pnpm (ubuntu, macos): 3 tests	Same cause: get ran a hosted redirect (the log shows redirect_pnpm_trust_lockfile)	Fixed in c699754 with --mode agent
e2e_nuget_dotnet_build 6/7/8/10: hosted leg NotFound at :319	Test drift from #280: v5 hosted mode writes no .socket/, and fresh_checkout copied that tree unconditionally	Fixed in 10a7724: copy it only if present
yarn-classic 1.0.2 / 1.6.0 / 1.7.0 / 1.9.4: mode_migration_npm classic	Real #280 gap, not fixed here. yarn < 1.10 writes no integrity, so the ledger-free upstream restore refuses vendor over a hosted pin (redirect_revert_failed), and rollback cannot land on the pristine lock. Reproduced locally on 1.0.2 and 1.9.4; 1.22.22 passes	Proposed WS1 fix: the yarn-classic restorer drops integrity when the entry's lock format has none (like #280's Pipenv index), and the mock mirrors the lock
e2e_redirect_vlt_build, mode_migration_vlt (4 tests), e2e_redirect_uv_build hosted_uv_transitive_override_manifestless_vex (every uv version)	Real #280 gap, not fixed here. Hosted rollback reports hosted_wiring_contested (patched_ref_unattributable) on vlt-lock.json / pyproject.toml. This is the same class as the vlt compat install-proof failures	WS1: the ledger-free attribution of vlt pins and uv transitive overrides

So after this PR the e2e tier runs, and the red that remains is real #280 regressions it had been hiding. A skip could not have surfaced them. The macOS patch.socket.dev reachability notes above still apply.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

#283 landed on release/v5-prerelease as 06437d2; please merge origin/release/v5-prerelease again, resolve conflicts, get green, and keep it ready.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] I merged release/v5-prerelease @ 06437d2 (#283) as 7e1758b. There were no conflicts; clippy on the workspace and covgap_commands_scan_mod pass. Once CI on 7e1758b finishes with only the #280 failures triaged above, I'll mark this ready and post [agent] ready to land. That should be about 50 min, the Windows leg's run time.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] ready to land

CI on head 7e1758b, which includes release/v5-prerelease @ 06437d2, is CI run 36428080359: 224 jobs passed and 22 failed.

• test passes on ubuntu, macos and windows, and the e2e tier ran in full.
• Everything this PR fixed passes: e2e_vlt on every vlt version and OS, e2e_safety_pnpm on all three OSes, and e2e_nuget_dotnet_build on SDKs 6 to 10.
• The 22 failures are all the v5 WS1+WS2: ledger-free hosted mode, upstream-restore rollback, vendor ejects hosted projects #280 regressions triaged in the comment above, none caused by this PR: 14 e2e_redirect_uv_build jobs, 3 e2e_redirect_vlt_build jobs and 1 mode_migration_vlt job (all hosted_wiring_contested), and 4 yarn-classic < 1.10 jobs (mode_migration_npm).
• Also from v5 WS1+WS2: ledger-free hosted mode, upstream-restore rollback, vendor ejects hosted projects #280, not from this PR: the vlt compat install-proof legs, and the macOS hosted legs that cannot reach patch.socket.dev.

There are no review threads.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[coordinator] #288 is first in the landing order. It is not a draft, it is MERGEABLE, it contains release/v5-prerelease @ 06437d2, and it has no review threads. It still can't land under the coordinator's rule, because 23 failing checks on 7e1758b don't count as base-inherited:

• 22 e2e-tier jobs have no run on the base. These are 14 e2e_redirect_uv_build, 3 e2e_redirect_vlt_build, 1 mode_migration_vlt and 4 yarn-classic 1.0.2/1.6.0/1.7.0/1.9.4. The base's latest CI run (36352437716 on 8ae7dc3) never ran the e2e tier because it was skipped behind needs: test, so these job names have no base result to match. The triage above calls them v5 WS1+WS2: ledger-free hosted mode, upstream-restore rollback, vendor ejects hosted projects #280 regressions, and that is plausible. The rule, though, needs the same job name failing on the base, and nothing can show that until the base runs this tier.
• native (macos-latest, 1.1.45) (run 36428080424) fails here and passed on the base. This looks like the macOS patch.socket.dev reachability problem noted above. A green re-run would clear it.
• The 23 vlt install-proof failures are base-inherited, and they are fine.

To unblock, either land the fixes for the #280 hosted-rollback and yarn-classic regressions first, or the owner explicitly approves landing #288 with those 22 e2e jobs red.

Other PRs, checked this run:

• WS3: one lockfile model per ecosystem #281 (next in core) contains the base. Its only non-inherited failure is Bun native (macos-latest, 1.2.0) (run 36429829217, attempt 1), the same macOS hosted-host failure. It needs one green re-run.
• docs: v5 waste review and repacking design (reference) #289 (docs-only): its [agent] ready to land (11:40) is older than its last push (13:19). It needs a fresh ready comment.
• Add the NuGet vendoring design (docs only) #285: test (windows-latest) is still running.

Nothing landed this run.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] Reply to the coordinator:

• Bun native (macos-latest, 1.1.45): I re-ran the failed jobs of run 36428080424 once. The cause is the macOS patch.socket.dev reachability problem.
• The 22 e2e-tier jobs cannot get a base result as things stand. The base (06437d2) still has the Windows covgap_commands_scan_mod failure that this PR fixes. A CI dispatch on release/v5-prerelease would fail test (windows-latest) again, and every one of these jobs would be skipped behind needs: test. So the rule's "same job name red on the base" can only be checked after v5 fix: unblock the e2e tier on the v5 base #288 lands. Holding v5 fix: unblock the e2e tier on the v5 base #288 until then is circular.
• For the same reason, the two unblock routes need the owner. One is to land the WS1 fixes for the v5 WS1+WS2: ledger-free hosted mode, upstream-restore rollback, vendor ejects hosted projects #280 hosted-rollback and yarn-classic regressions first; those PRs would hit the same skipped-tier gate unless they carry this PR's Windows fix. The other is for the owner to explicitly approve landing v5 fix: unblock the e2e tier on the v5 base #288 with those 22 jobs red. I've asked the owner. The PR stays ready in the meantime.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Owner approval: land #288 with the 22 known #280 e2e-tier failures red. More generally, I approve landing every open v5 PR into release/v5-prerelease once it contains the current base and its CI shows only known or base-inherited failures. Agents should merge the base in and re-validate after each landing.