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).
native/
English | 中文
Native source and public packages maintained with DeepSeek Harness. The landlock-run/ workspace owns the Landlock self-restrict-then-exec launcher consumed by the harness, including its architecture, three-package npm family, platform support, development workflow, and release procedure.
Workspace and release boundary
landlock-run/ and its packages belong to the repository's root pnpm workspace and lockfile. Harness consumers use the current workspace entry package during development and CI, so a launcher contract change and its consumer update can land and be tested together.
The main repository's Landlock Run workflow builds and tests each supported architecture. Landlock Run Release assembles those native artifacts, packs and verifies the three npm tarballs, then optionally publishes them under one launcher version. The entry package retains platform packages as npm optional dependencies, so npm still installs only the package matching the user's operating system and CPU.