A landlock publication failed with `E409 Failed to save packument` on the
second of three packages. The registry answers a write it could not commit that
way, and publishing several packages back to back is what provokes it.
Neither publish path could recover. The native sequence published from a shell
loop of bare `npm publish` calls: no retry, and no way to resume, because the
registry rejects a repeat of an existing version permanently — so a failure
partway through left the release stuck. publish.ts skipped versions already
present, which made a re-run safe, but had no retry either.
Both paths now attempt a tarball up to four times, space writes at least two
seconds apart, and back off 2s/4s/8s between attempts. Every retry re-reads the
registry first, because a reported failure can answer a write that landed
anyway: a version that now exists with this tarball's integrity counts as
published rather than as one to place again. That same re-read is what turns a
mid-run `E403 cannot publish over the previously published versions` into a
skip when the bytes match, and leaves it a hard failure when they do not.
The native sequence gets the registry comparison publish.ts already had, through
its own script rather than shared code — the two sequences keep separate
publication paths. Its publish job now checks out the repository, which the
shell loop did not need.
Verified against a scripted registry: a clean publish, one E409 then success, an
E409 whose write landed anyway, E409 on every attempt (fails after four), and a
version already present with matching integrity (publishes nothing).
The failover Windows pool releases child-process and antivirus file
handles slower than the hosted pool; a 1-second window (10 x 100 ms)
still exhausts before release under load, so install-lefthook fixture
cleanup threw EPERM in rmSync. A 10-second window (50 x 200 ms) covers
the slower release without pinning afterEach cleanup, since a
terminated child's handles drain once rather than reacquire.
Local run of check:ci:windows-complete (the windows-native gate) on
latest master surfaced five Windows-only failures, all unreachable by
current CI because the native windows job is disabled and the wine gate
only covers build+site.
- install-lefthook/translation-pairing-merge specs junctioned the real
scripts/ and tsx package into fixtures; Windows recursive deletion
(Node rmSync and git worktree remove) follows MOUNT_POINT junctions and
deleted the repository's own directories mid-run. Fixtures now unlink
their reparse points before any recursive removal (shared helper in
scripts/test-fixture-cleanup.ts).
- workflow-workerthread spawned its worker with an empty env; on Windows
os.tmpdir() then degrades to the literal relative path undefined\temp,
so tsx wrote its transform cache into a cwd-relative undefined/
directory inside the repo. The worker env now injects the host temp
path on win32 (workerSpawnEnv, platform-parameterized and unit-tested
on both arms).
- workspace-context spec did not stub USERPROFILE (win32 homedir) or a
set DSH_HOME, leaking the developer machine's real ~/.dsh/AGENTS.md
into discovery.
- ui-trajectory client-bundle spec mounted the built artifact without the
remote/settingsScope provides the locale plugin needs, so the plugin
never activated and no view registered.
- subagent temp-fixture cleanup lacked the maxRetries Windows handle
release needs under load (EPERM); added retries to the three affected
specs and the fixture-cleanup helper.
