mcp-pacemaker 2.0.2 → 2.1.1

package/CHANGELOG.md

@@ -7,7 +7,172 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
-Target release: **2.0.2**. This candidate has not yet been published.
+## [2.1.1] - 2026-10-15
+
+### Added
+
+- `upgrade --fix-legacy-access` is a one-time step for a Windows 1.3 install that was set up from
+  an administrator terminal. Run it from an administrator terminal. It gives the task's own
+  run-as user full control of that 1.3 task and makes that user the owner of the 1.3
+  `bin\cli.mjs`, and it records the previous permissions in
+  `legacy-upgrade\access-<time>.json` first. Nothing else changes: the task XML, triggers,
+  run-as account and run level, the other permission entries and the file contents stay the
+  same and are checked afterwards. `--plan` shows the change without making it.
+- The Windows release qualification can resume after a failed or killed run with
+  `--resume RUN_DIRECTORY`. Each run records its inputs, controller, Docker engine, Windows
+  build and passed steps in `run-state.json`. A resume refuses any change to those or to the
+  kept evidence, sets the failed attempt aside next to the run and reruns only the steps that
+  did not pass. The offline verifier checks the recorded history; the published regression
+  statement is unchanged.
+
+### Fixed
+
+- Upgrading a Windows 1.3 install that was set up from an administrator terminal no longer fails
+  part-way. Windows makes Administrators the owner of that task and lets your account only read
+  it, and makes Administrators the owner of the files, so the upgrade, which must run as an
+  ordinary user, was refused while copying the CLI file and would then have failed while holding
+  the task. Planning now checks these permissions first and stops before any process capture,
+  download or change. It names each item and the fix. Installs set up from a normal terminal
+  are unaffected.
+- `upgrade --to` from an elevated terminal is now refused before planning and before any
+  confirmation prompt, with the normal-terminal next step. It used to ask for the restart
+  confirmation first and refuse afterwards.
+- Managed upgrades no longer fail behind npm mirrors that publish only SHA-1 checksums, such as
+  some Azure Artifacts upstreams. Each release now carries the SHA-512 dependency lock it was
+  released and tested with (`bin/dependency-lock.json`, declared by `dependencyLock` in
+  `bin/upgrade-capability.json`), and staging installs exactly that lock with `npm ci` through
+  your configured registry, including when `replace-registry-host` is `never`.
+  Staged dependencies no longer move to newer in-range versions at upgrade time. Targets without
+  the lock keep the old resolution, and an entry without SHA-512 integrity now names the package.
+- The Windows legacy process broker now waits up to eight seconds instead of two for each WMI
+  command-line query, and reports the first real failure instead of a generic
+  `Argument query cancelled`. A WMI timeout is reported as `Argument query timed out`. On a busy
+  host with about 1,000 processes the two-second limit made legacy planning fail.
+- `reload` no longer reports a slow bridge as `bridge DOWN`. The bridge may spend its whole
+  pooling budget settling a pending batch before it answers, but the CLI gave up after five
+  seconds. It now waits past that budget and reports a late answer as a timeout. Status
+  checks wait ten seconds instead of two before treating a bridge as down. A refused
+  connection still fails at once.
+- Upgrading a busy Windows 1.3 install no longer fails. The legacy process broker put every
+  process under the 1.3 bridge into the plan and refused when that list changed, but a busy
+  bridge starts and ends a session process every few seconds. It also refused any install
+  with more than 512 such processes (one had 533), and the upgrade refused whenever 1.3
+  rewrote `sessions.json`, which it does on every session start and end. The plan now holds
+  only the supervisor and the bridge. The stop ends the supervisor, holds a handle to every
+  process under the bridge, ends the bridge, and then stops everything it holds plus anything
+  those processes started, up to 2048 processes. Holding them first matters: Node ends a
+  process's direct children with it, and 1.3 runs each bare server command under `cmd.exe`,
+  so ending the bridge first would have left those servers running with no traceable parent.
+  A process it cannot stop is reported and left running instead of blocking the upgrade.
+  Capture and revalidation also get 120 seconds from the request instead of 14 to 15 seconds
+  from the broker's start, which a loaded host could use up before the capture began.
+- A 1.3 upgrade started from inside the 1.3 tree, for example through an MCP server's shell,
+  is now refused before anything changes. It would have stopped itself part-way.
+- A managed upgrade no longer refuses because a client is connected. The bridge counted every
+  open session as active work and refused after eight seconds, and once any client had dropped
+  a stream it refused every later upgrade until it restarted. Each refusal also left the bridge
+  answering 503 until `upgrade --recover`. Now calls in progress and config work get up to
+  eight seconds to finish, and open sessions and calls still running end with the restart.
+  Config work still unfinished then refuses the upgrade, and the upgrader resumes the current
+  version, trying for up to ten seconds while that work settles. A session that starts or ends
+  during the download no longer fails the upgrade either; only `servers.json` must be
+  unchanged. The installed version runs an upgrade, so this applies to upgrades from 2.1.1 on.
+  To upgrade from 2.1.0, close your MCP clients and restart Pacemaker first.
+- `prewarm` no longer crashes on Windows with
+  `Assertion failed: !(handle->flags & UV_HANDLE_CLOSING)` after the bridge refuses a change. It
+  prints the refusal and exits with status 1. Node 23, 24 before 24.20.0, 25, and 26 before
+  26.7.0 can abort a process that exits soon after `fetch`
+  ([nodejs/node#56645](https://github.com/nodejs/node/issues/56645)), so `prewarm` now talks to
+  the bridge with `node:http` like the rest of the CLI. A bridge that does not answer within ten
+  seconds is now reported by port instead of as `The operation was aborted due to timeout`.
+
+### Changed
+
+- Upgrades now follow one written rule: an upgrade may end open sessions and calls in progress,
+  and never retries a call; it never changes `servers.json` or your client setup. See
+  [upgrades and rollback](docs/upgrades.md#what-an-upgrade-keeps-and-what-it-ends).
+- The Windows 1.3 upgrade accepts `--yes` to confirm the plan shown, like other upgrades, and
+  its confirmation now says what ends and what is kept. It used to require an interactive
+  terminal and ask you to pause callers first. Explicit-account (`--user`) upgrades still need
+  interactive confirmation, because they also create a task for that account.
+- Split the Windows release qualification into a contained lane and a host session lane.
+  The qualification container has no interactive logon, so it now verifies the
+  `source-ordinary` contract and defers the four session-bound test files; those files run
+  on the publishing host under an ordinary, non-elevated interactive account and produce a
+  `session-lane.json` receipt that the offline verifier requires, bound to the same commit.
+  This closes a gap where those four files ran in no automated lane.
+
+## [2.1.0] - 2026-10-12
+
+Published to npm on 2026-10-14.
+
+### Added
+
+- Explicit managed `upgrade --to`, read-only plans, isolated `--sxs` instances with
+  retained OS-assigned listeners, stable launchers, admission control and a durable
+  activation/recovery journal. Bare `upgrade` and `--self` remain compatible.
+- Preserve ports and host wiring during managed replacement; retain the previous
+  package and restrict rollback to verified, unchanged pre-admission state.
+- Add one-time restart-only migration for the exact Windows 1.3.0 registration,
+  with interactive uncertainty acknowledgement, held process identities, partial
+  observed-descendant receipts and scoped task/CLI rollback. No machine reboot.
+- Refuse unsupported or unknown supervisor/autostart identities before interruption.
+- Add explicit Windows original-account upgrades with a task-only administrator
+  controller and authenticated original-user worker. Keep current-user scope as
+  the default, preserve task security/account settings, and refuse unavailable or
+  changed logged-on session identity. Real elevated two-account qualification
+  remains required; `--all-users` is unsupported.
+
+### Fixed
+
+- Contain Windows bridge descendants in a kill-on-close Job Object before any
+  workload starts, preventing nested cmd/Node trees from surviving abrupt bridge
+  loss. Fail startup if containment cannot be established.
+- Preserve existing task security during legacy migration instead of resubmitting
+  its owner, allowing an ordinary user to update an eligible Administrators-owned
+  task without changing its permissions.
+- Handle Task Scheduler's equivalent XML serialization during post-write checks
+  and restoration, including rediscovery after rollback. Keep raw revision
+  preconditions, original backups and complete resource-security checks intact.
+- Avoid Windows upgrade-authorization failures caused by slow thread enumeration
+  and already-terminated thread records while retaining complete identity and
+  authority checks.
+- Capture larger legacy process trees with bounded discovery and distinguish
+  reused parent PIDs from proven descendant relationships.
+- Recheck shared-session test cooldown deadlines after early timer delivery before
+  acquiring a replacement generation.
+- Wait for the metrics test process and its stdio to close before removing fixture files.
+- Pin the Windows process-lifetime and task-channel helpers to their own packaged directory
+  instead of inheriting the caller's working directory. A process's working directory cannot
+  be removed on Windows, so a detached helper previously blocked removal of the instance,
+  configuration and staging directories with `EPERM`.
+- Report the native refusal reason when the task channel declines a request, instead of a
+  bare refusal with no cause.
+
+### Security
+
+- Refuse elevated or unverified default Windows upgrade and recovery before
+  staging, task writes or runtime launch, preserving the original runtime authority.
+- Raise the CLI's `smol-toml` floor to `1.9.0`.
+- Move the dashboard build to Tailwind CSS `4.3.3`, removing the vulnerable
+  `braces` and `postcss-selector-parser` dependency paths, and pin `source-map-js`
+  to `1.2.2`.
+- Retire the 2.0.2 producer exception from fresh native and OSV scans. New releases
+  require complete clean producer evidence; historical receipts retain their
+  original source bindings and expiry.
+
+### Changed
+
+- **Breaking for privileged callers.** The bridge, supervisor and default upgrades now verify
+  the caller before any runtime work and refuse an elevated or root caller at startup with
+  `User-runtime execution refused: …`. This is not Windows-only and not upgrade-only: on Linux
+  and macOS a `root` process is refused, which includes the default user in most container
+  images. There is no override; run as an ordinary account. Shipping this in a minor release is
+  deliberate — the previous behaviour let a bridge run with authority it could not verify.
+- Update the Tailwind PostCSS adapter, class-merging dependency, generated dashboard
+  assets and license attribution while retaining the existing theme configuration.
+
+## [2.0.2] - 2026-10-06
 
 ### Fixed
 
@@ -475,6 +640,11 @@ one is a trap for anyone building something similar.
 - Do not report a teardown the bridge initiated as a crash. `taskkill /F` exits non-zero, so
   every recycle, idle reap and session close was recorded as a failure, burying real ones.
 
+[Unreleased]: https://github.com/girishkvs/mcp-pacemaker/compare/v2.1.1...HEAD
+[2.1.1]: https://github.com/girishkvs/mcp-pacemaker/releases/tag/v2.1.1
+[2.1.0]: https://github.com/girishkvs/mcp-pacemaker/releases/tag/v2.1.0
+[2.0.2]: https://github.com/girishkvs/mcp-pacemaker/releases/tag/v2.0.2
+[2.0.1]: https://github.com/girishkvs/mcp-pacemaker/releases/tag/v2.0.1
 [2.0.0]: https://github.com/girishkvs/mcp-pacemaker/releases/tag/v2.0.0
 [1.3.0]: https://github.com/girishkvs/mcp-pacemaker/releases/tag/v1.3.0
 [1.2.0]: https://github.com/girishkvs/mcp-pacemaker/releases/tag/v1.2.0

package/CONTRIBUTING.md

@@ -18,12 +18,16 @@ part of its security posture. The setup CLI and the dashboard may use dependenci
 
 ## Lockfiles must resolve to the public registry
 
-CI fails any lockfile containing a `resolved` URL outside `registry.npmjs.org`. If you work
-behind a private mirror, re-resolve before committing:
+CI fails any lockfile containing a `resolved` URL outside `registry.npmjs.org`.
+Do not bypass a required registry policy to produce those URLs. Restore through the
+approved registry and preserve exact package names, versions and verified archive
+integrities when canonicalizing mirror-specific URLs for the public lockfile.
+Hosted CI must still restore the resulting lock from its configured registry.
 
-```bash
-npm install --registry https://registry.npmjs.org
-```
+For npm 12 mirrors whose metadata and tarball URLs have different prefixes,
+`replace-registry-host` supports command-local URL-prefix mapping back through the
+approved registry. This does not require relaxing `allow-remote`, disabling TLS,
+changing global settings or committing a private registry configuration.
 
 ## Tests
 
@@ -35,8 +39,13 @@ Tests are `node:test` only, no framework. Each test file that starts a bridge ow
 ports, because files run in parallel; the current allocation is listed at the top of
 `test/auth-token.test.mjs`. Pick unused ones for a new file.
 
-Before submitting, run the complete `npm test` command with its normal file concurrency.
-Focused or serialized runs help diagnose failures but do not replace that run. Record the
+Before submitting, run the complete `npm test` command with its normal file concurrency
+(`--test-concurrency=4`, matching the four vCPUs on hosted runners). CI and the local
+publication gate go through `npm run test:contract -- <name>` instead, which adds the
+execution-context preflight and, on Windows, splits the suite into the ordinary-account lane
+and the session lane; `npm run test:contract -- source --check` reports what a lane would run
+without running it. Focused or serialized runs help diagnose failures but do not replace that
+run. Record the
 exact Node and npm versions, OS, architecture, and command; matching only the Node major is
 not enough to reproduce a CI failure.
 
@@ -63,6 +72,14 @@ platform; Windows also exercises the real executable. Those checks do not replac
 byte-for-byte rebuild, and a rolling CI image may not contain the recorded compiler.
 No compiler or PowerShell host runs in the production config-write path.
 
+Windows bridge lifetime containment uses a **separate** packaged helper. Build
+and byte-for-byte verify it with `tools/windows-process-lifetime/build.ps1` and
+`-Verify`; see its README for the ownership and failure contract. Do not change
+the immutable config-security helper to update the lifetime helper. Run both
+`test/windows-process-lifetime.test.mjs` and `test/windows-lifetime-startup.test.mjs`
+on supported Windows/Node versions. They retain owned PID/creation-time cleanup
+receipts and TCP heartbeat observations outside Git.
+
 Batch tests must cover the full five-second trailing debounce, merging complete snapshots,
 Reload now, requests during a flip, stale active revisions, whole-batch Cancel/Undo and late
 commit outcomes. Use controlled clocks for scheduling boundaries and real file/HTTP cases for
@@ -77,9 +94,17 @@ sleeping a fixed interval.
 
 ## Real-version compatibility gates
 
+The dashboard uses the Tailwind 4 PostCSS adapter. Its optimizer stays disabled
+until generated selectors and license attribution have been checked; Vite still
+minifies the final CSS. Keep the inline Vite and standalone PostCSS settings
+consistent, and run the UI tests before regenerating the dashboard and notices.
+
 These are separate, mandatory CI gates, not substitutes for `npm test`. The root CI job runs
-CLI/API pairs on Windows, Linux and macOS with Node 20, 22 and 24. The Linux/Node 22 UI
-job runs one Chromium browser matrix after building the dashboard.
+CLI/API pairs on Linux and macOS with Node 20, 22 and 24. The Windows pair runs in the
+`windows-ordinary` job through `tools/windows-ci/ci-ordinary-user.ps1 -Contract compatibility`,
+which prepares, exercises and removes its fixtures inside a disposable standard account: the
+fixtures record the temp root that owns them, so an administrator-prepared pair is refused. The
+Linux/Node 22 UI job runs one Chromium browser matrix after building the dashboard.
 
 ```bash
 npm ci
@@ -103,6 +128,13 @@ instead of installing bundled Chromium. CI uses bundled Chromium, not that overr
 Both standalone test commands **fail** when preparation is missing or candidate bytes have
 changed. Clean and prepare again after changing package files, built assets, or Node major.
 
+On Windows, run these gates on Node 20, 22, 24.20.0 or a later 24.x, or 26.7.0 and later.
+Released CLIs up to 2.1.0 use `fetch` for `prewarm`, and Node 23, 24 before 24.20.0, 25, and 26
+before 26.7.0 can abort a process that exits soon after `fetch`
+([nodejs/node#56645](https://github.com/nodejs/node/issues/56645)). There, any test that runs a
+released CLI into a refused change (1.3.0, and 2.0.0 in the historical baseline) fails with exit
+code 3221226505 and a libuv `UV_HANDLE_CLOSING` assertion.
+
 Historical compatibility baselines remain explicitly **1.3.0 and 2.0.0**.
 Candidate versions must be canonical stable **1.x legacy / 2.x current** versions.
 The owner selects the actual release and any exact opposite-major patch pair;
@@ -111,13 +143,14 @@ The same harness runs in both maintained branches:
 
 | Preparation | Selected legacy / current pair |
 |---|---|
-| Default in the selected 2.0.2 checkout | Immutable 1.3.0 / packed 2.0.2 |
+| Default in the selected 2.1.1 checkout | Immutable 1.3.0 / packed 2.1.1 |
 | Default in the 1.3.1 checkout | Packed 1.3.1 / immutable 2.0.0 |
 | `npm run compat:prepare:baseline` | Immutable 1.3.0 / immutable 2.0.0 |
-| `npm run compat:prepare -- --peer-root <opposite-patch-checkout>` | Packed 1.3.1 / packed 2.0.2 |
+| `npm run compat:prepare -- --peer-root <opposite-patch-checkout>` | Packed explicit 1.x peer / packed 2.1.1 |
 
-These selections are not qualification evidence. The selected 1.3.1/2.0.2 pair
-requires fresh exact-byte gates; earlier 1.3.1/2.0.1 results remain historical.
+These selections are not qualification evidence. The 2.1.1 candidate requires fresh
+exact-byte gates; selecting it does not select an opposite-major patch pair.
+Earlier 1.3.1/2.0.2 and 1.3.1/2.0.1 results remain historical.
 
 Run both API and browser gates for the explicit patch pair before publishing either complete
 dual-major release set. The two default CI pairs alone do not establish that combined result.