machine-bridge-mcp 1.2.8 → 1.2.10

package/CHANGELOG.md

@@ -1,5 +1,25 @@
 # Changelog
 
+## 1.2.10 - 2026-07-20
+
+### Relay interruption recovery
+
+- Preserve an in-flight MCP tool call across a brief daemon WebSocket interruption instead of converting every transient proxy or network reset into an immediate cancellation. The Worker now detaches pending calls for a bounded 30-second grace period and rebinds them only when the same local daemon process instance completes the full authenticated readiness probe on its replacement socket.
+- Keep the local operation running during that grace period and queue a completed result until the relay is ready again. Before `ready_ack`, the Worker sends an authoritative `resume_calls` set so the runtime cancels work whose client disappeared during the outage; results are replayed only for same-instance calls that still have a receiver. A different daemon instance cannot claim them, and an unrecovered outage cancels ordinary calls and process trees when the grace period expires.
+- Add deterministic registry/runtime regressions and a real Worker/OAuth/MCP fault-injection test that starts a tool call, forcibly drops the daemon WebSocket, reconnects the same daemon instance, and proves the original HTTP request completes. Expose the bounded `pending_calls.detached` count for diagnosis, require a validated ephemeral daemon instance identifier in the current-version hello contract, and update architecture, logging, operations, audit, and multi-account documentation.
+
+## 1.2.9 - 2026-07-18
+
+- Repair cross-platform release infrastructure found by PR CI: the layered check runner now invokes the pinned npm CLI through Node instead of spawning `npm.cmd`, and `release:accept` computes and locally validates the portable Git-content digest through a temporary index so CI can verify accepted package content across merge commits without mutating the maintainer index.
+- Correct the release handoff: add `npm run release:candidate:start -- --allow-worker-deploy` for an isolated local installation plus explicitly authorized in-place candidate Worker deployment, require owner-started and agent-observed live verification before acceptance, allow the coding agent to record acceptance and complete commit/push/tag/GitHub Release work, and add `npm run release` as the canonical source-release command. npm publication and Worker deployment remain owner-operated.
+
+### Architecture headroom, verification feedback, and threat model
+
+- Split tool registration, relay adaptation, path redaction, Agent-context projection/rendering, bounded skill discovery and text reading, browser request lifecycle, runtime-client broker routing, authenticated loopback server setup, browser HTTP handling, Windows launcher quoting, managed-job transition locks, runner identity, private storage, public projections, Worker OAuth authorization-page rendering, JSON-RPC framing, and WebSocket protocol cleanup out of near-limit orchestration modules. Tighten architecture budgets around the new boundaries so `runtime`, Agent context, browser broker, Windows service, managed jobs, and `BridgeRoom` retain explicit headroom instead of treating their previous line caps as targets.
+- Replace the monolithic package-script chain with audited `check:fast`, `check:platform`, and `check:full` plans while keeping `npm run check` as the complete gate. Each task reports elapsed time; macOS and Windows CI run the cross-platform behavior plan plus installed-package smoke coverage, while Ubuntu runs the full coverage, browser, package, stdio, Worker/OAuth, and real-browser suites.
+- Expand critical-module coverage gates to state persistence, relay lifecycle, managed jobs, runtime path redaction, Agent-context projection, browser broker/request routing, Worker OAuth, JSON-RPC framing, and WebSocket protocol helpers. Add strict checked-JavaScript coverage for the runtime path/redaction, Agent-context projection, skill-discovery, and bounded text-file boundaries. Repair a detached-process self-test race by waiting monotonically for the child PID handoff file, and remove fixed CI-job-count and implementation-location assumptions from source-shape tests.
+- Replace the oversized README with a decision-oriented entry path, add a component overview and explicit threat model, document the Node 26/npm 12 support trade-off, and add a contributor first-30-minutes workflow. Security objectives, attacker classes, non-goals, and external governance gaps are now stated separately from incident and release audit history.
+
 ## 1.2.8 - 2026-07-17
 
 ### Owner-tested release gate and dependency workflow repair

package/CONTRIBUTING.md

@@ -2,6 +2,16 @@
 
 Read [docs/PROJECT_STANDARDS.md](docs/PROJECT_STANDARDS.md), [docs/ENGINEERING.md](docs/ENGINEERING.md), [GOVERNANCE.md](GOVERNANCE.md), and the relevant domain documentation before changing behavior.
 
+## First 30 minutes
+
+1. Use Node.js 26 and npm 12, then run `npm ci`.
+2. Read [System overview](docs/OVERVIEW.md), [Engineering](docs/ENGINEERING.md), and the domain document for the code being changed.
+3. Run `npm run check:fast` before editing to establish a clean local baseline.
+4. Make one responsibility-focused change and run its nearest behavior test while iterating.
+5. Run `npm run check` before declaring a package-affecting change complete.
+
+Do not begin by raising a module line cap, weakening a coverage threshold, or adding a parallel policy/protocol shape. First identify the responsibility that belongs in a focused module or the shared contract that should own the rule. Source-shape architecture assertions are supplementary; security and lifecycle changes require behavior, denial, race, or fault-injection coverage for the underlying mechanism.
+
 ## Development workflow
 
 The repository uses GitHub Flow: branch from current `main`, keep one coherent change, validate it locally, open a pull request, satisfy required checks, squash-merge, and delete the branch. Permanent `develop` or generic release integration branches are not used unless an independently maintained release line creates a concrete need.
@@ -31,13 +41,14 @@ Repository-only infrastructure changes, such as a `.github/` workflow update, do
 3. run targeted tests, both dependency audits, `npm run worker:dry-run`, privacy/history review, signature verification, SBOM generation, and package inspection as applicable;
 4. inspect the complete diff;
 5. run `npm run release:candidate`, which executes the complete suite and creates the exact candidate tarball under ignored `.release-candidate/`;
-6. have the repository owner test that exact tarball on the maintainer machine through the normal installation/startup path;
-7. have the owner record the explicit decision with the exact command printed by the candidate tool, creating `release-acceptance/v<version>.json`;
-8. commit the acceptance record and push the clean non-`main` branch only with `npm run github:push`.
+6. give the repository owner `npm run release:candidate:start -- --allow-worker-deploy`; the owner explicitly authorizes the in-place candidate Worker deployment, starts the exact candidate locally, and leaves it running;
+7. verify the live candidate through Machine Bridge, including Worker version/hash, remote health, relay readiness, exact local version, and representative functionality relevant to the change;
+8. after observed verification succeeds, have the coding agent run the exact `release:accept` command printed by the candidate tool, creating `release-acceptance/v<version>.json`;
+9. commit the acceptance record and push the clean non-`main` branch only with `npm run github:push`.
 
-Automated checks do not authorize step 7. A coding agent must not record owner acceptance or push the release-relevant branch before the owner has tested it. Any packaged-file change after acceptance changes the npm tarball hash and requires a regenerated candidate and a new owner test.
+Automated checks do not authorize step 8. The coding agent may record acceptance only after it has observed the owner-started candidate operating successfully. Any packaged-file change after acceptance changes the npm tarball hash and requires a regenerated candidate and another observed live verification.
 
-After all required pull-request checks pass, repository automation may complete the source release: squash-merge, verify the exact `main` push CI, CodeQL, Governance, and Scorecard runs, and run `npm run release:publish`. The publication helper requires `HEAD === origin/main`; it does not push `main`. It creates or verifies the annotated version tag and final GitHub Release only after the accepted package hash and exact-commit checks match.
+After all required pull-request checks pass, repository automation completes the source release: squash-merge, verify the exact `main` push CI, CodeQL, Governance, and Scorecard runs, and run `npm run release`. The helper requires `HEAD === origin/main`; it does not push `main`. It creates or verifies the annotated version tag and final GitHub Release only after the accepted package hash and exact-commit checks match. `release:publish` remains a compatibility alias.
 
 The release operator separately authorizes npm publication and any live machine update. Automation must not publish, deprecate, or unpublish npm packages; install the CLI globally; deploy the Worker; rotate credentials; mutate live deployment state; or start, stop, install, remove, or replace the daemon or autostart service without explicit user authorization.