* fix(skills): keep the disposal verdict when staging cleanup fails
`begin()` ended with `await this.removeOwnershipIfDisposed()` inside its `finally`,
so when a caller raced `dispose()` the rejection it received was whatever that
opportunistic `rmdir` threw -- not `skill-upload-service-disposed`. A caller could
not tell "the service shut down" from "the filesystem broke", and the Windows
release gate saw it as `EPERM: operation not permitted, rmdir`.
Two causes, both fixed here:
- The EPERM itself: an in-flight operation and disposal each call
`ownership.remove()`, so two `rm -rf` run concurrently against the same owner
directory. On POSIX the loser reads ENOENT and `force: true` swallows it; on
Windows the loser reads a delete-pending directory and gets EPERM.
`SkillUploadStagingOwnership.remove()` now joins one removal and forgets it on
failure so a later caller still retries.
- The masking: cleanup in a `finally` no longer replaces the outcome of the call
it is cleaning up after. Disposal retries staging removal and reports its own
failure, matching `removeUnpublished`/`retainFailedCleanup` in this class.
Both regressions are pinned platform-independently: one injects a failing
ownership removal and asserts the racing `begin` still rejects with
`skill-upload-service-disposed` while `dispose()` reports the cleanup failure; the
other models Windows delete-pending rmdir in the `node:fs/promises` mock, which
turns a second removal into EPERM on every platform.
* ci(release-cut): retry the installs that fetch node-gyp headers
`golden e2e windows` installs with lifecycle scripts enabled, so pnpm runs
node-gyp for the `native/windows-registry` workspace project, which downloads that
Node version's headers from nodejs.org. A single `read ECONNRESET` on that fetch
failed a blocking release gate, and the release build job one screen below already
wraps its install in `nick-fields/retry@v4` for exactly this class of failure.
Both remaining unretried installs in this workflow (the blocking platform golden and
the non-blocking rendering-evidence lane) now use the same wrapper, and a contract
test keeps every release-cut install retryable.
* Reduce native dependency installs to the host platform
* Remove install policy documentation
* Guard cross-arch packaging and scope release installs to the runner
electron-builder only logs a warning for a missing extraResources source,
so a host-only install silently shipped a foreign-arch slice without its
natives — `pnpm build:mac` on Apple Silicon produced an x64 DMG with no
sherpa-onnx-darwin-x64 and no @parcel/watcher-darwin-x64. The previous
beforePack hook covered only win32.
- Add assertPackagedNativeVariantsInstalled, an arch-aware check over the
target's sherpa-onnx, @parcel/watcher, and (on Windows) node-gyp addons.
beforePack now runs it for every platform, with remedies split: another
architecture comes from install:release, the os:win32 addons need a
Windows host.
- Drop --os from the release installs. Every packaging job already runs on
a runner whose OS matches its target, so only the macOS lanes need extra
breadth, and only on CPU for their x64+arm64 config. Windows and Linux
packaging return to a plain host-only install.
- Add --frozen-lockfile to install:release so a bare run cannot rewrite
the lockfile.
- Restore the install policy reference doc and the CONTRIBUTING note, plus
the rationale comments dropped from the runtime contract test.
- Gate the packaging-closure assertions on whether the Windows addons are
installed rather than on the host OS, so a cross-arch install exercises
them off Windows too.
- Make the workflow contract test read `run:` steps as well as retry-action
commands, and enforce host-only scoping on the non-macOS packaging lanes.
- Remove the unreferenced install measurement script; its numbers live in
the policy doc.
* Track the install policy doc and index it from AGENTS.md
docs/** is ignored behind a per-file allow-list, so the new reference doc
was only committed via git add -f and future edits would be skipped. Add
it to the allow-list and give it an AGENTS.md entry like every other
tracked reference doc, so the host-only install rule is discoverable
before someone packages a second architecture.
* Route Windows-lane removals through the retrying helper
Adding these four specs to the PR Windows lane pulled them into the
windows-lane-tree-removal-boundary ratchet, which failed on 20 raw
recursive removals. On Windows a bare rmSync races a handle the OS has
not released, throwing EPERM after the assertions already passed and
reporting a green test as a lane failure.
* Adapt the packaging guard to the vendored Windows registry addon
main vendored windows-native-registry as the workspace package
@orca/windows-registry (#20438). A workspace link resolves on every
host, so including it in the installed-Windows-addons checks proved
nothing. @vscode/windows-process-tree is the only os: win32 npm addon
left, so it alone decides whether the win32 resource plan resolves.
Jinwoo Hong
Neil