machine-bridge-mcp 2.0.0 → 3.0.0-beta.102

package/CONTRIBUTING.md

@@ -34,31 +34,29 @@ An npm version is required when a change affects `package.json`, `package-lock.j
 
 Repository-only infrastructure changes, such as a `.github/` workflow update, do not require a synthetic npm version when package bytes are unchanged. They still require review and all applicable CI, dependency-review, CodeQL, governance, and Scorecard checks.
 
-## Required before pushing an npm-package change
-
-1. bump `package.json` to a version newer than the latest reachable `v*` tag;
-2. add the matching dated section to `CHANGELOG.md` and update audit/documentation records;
-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. 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. resolve every open issue and pull request before pushing. The current branch may cover an issue only with a standard closing keyword such as `Closes #47`; unrelated open PRs block the push. Commit the acceptance record and push the clean non-`main` branch only with `npm run github:push`, which paginates and enforces that backlog contract.
-
-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 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.
-
-Supported upgrade and rollback behavior is defined in [docs/UPGRADING.md](docs/UPGRADING.md). Support requests follow [SUPPORT.md](SUPPORT.md), and repository participation follows [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).
-
-After npm publication, the standard machine update is:
-
-```bash
-npm install -g --omit=optional --allow-scripts=esbuild,workerd,sharp,fsevents machine-bridge-mcp@latest && machine-mcp
-```
+Repository tests are verification inputs, not npm tarball entries under the current `package.json.files` manifest. A `tests/**`-only change therefore does not itself change package bytes; if a bug fix also changes shipped source, scripts, metadata, or documentation, that packaged change still requires the prerelease/version flow and the regression test remains mandatory verification evidence.
+
+## Required prerelease flow for an npm-package change
+
+1. choose a `dev`, `beta`, or `rc` version; version 3 and later must not begin as stable;
+2. update changelog, audit notes, and documentation;
+3. run targeted and one complete frozen-tree check, dependency audits, Worker dry-run, privacy review, `npm run sbom:test`, and package inspection; the successful full check writes a short-lived exact-generation receipt under ignored `.project-local/`;
+4. inspect the complete diff and run `npm run release:candidate`; it must consume that matching receipt and does not repeat the complete suite;
+5. run `node scripts/start-release-candidate.mjs --install-only`; this non-live preflight must still match current source/package modes and install the exact tarball disposably, otherwise repair and regenerate the candidate;
+6. obtain explicit owner authorization for `npm run release:candidate:activate -- --allow-worker-deploy`; the owner or authorized agent may run it through the local control plane;
+7. after activation, derive `<activated-runtime-package>` from activation `runtime_entry`, run `node <activated-runtime-package>/scripts/release-oauth-canary.mjs --allow-live-oauth-canary` as direct argv from the checkout cwd, then verify the Worker, candidate relay, verified service daemon, exact version, representative behavior, and relevant failure paths through Machine Bridge;
+8. only after the candidate-bound canary and observed live verification both succeed, record exact candidate acceptance;
+9. commit and push only with `npm run github:push`, then complete review and required checks;
+10. after explicit owner authorization, create the GitHub Prerelease with `npm run prerelease:release -- --owner-confirm`; a TTY is optional;
+11. run `npm run prerelease:publish` and `npm run prerelease:install -- --allow-worker-deploy` only under their own explicit owner authorization;
+12. use the published prerelease for at least seven days for a major, three days for a minor, or one day for a patch;
+13. every blocking defect increments the prerelease number and restarts the interval;
+14. after explicit owner confirmation, record the soak result; stable promotion must pass `npm run release:soak:verify` and preserve the functional promotion digest;
+15. activate and observe the exact stable candidate, repeat acceptance and review, then run `npm run release -- --owner-confirm` after explicit owner authorization; `npm run stable:publish` remains a separately authorized operation.
+
+Automated checks do not authorize candidate acceptance or soak success. The agent observes the live candidate; the owner reports the real soak outcome. Release evidence contains bounded release metadata only and no private user content.
+
+Repository-only infrastructure changes whose package bytes are unchanged skip candidate activation and soak but still require review and applicable checks. The complete state machine is in [docs/RELEASING.md](docs/RELEASING.md).
 
 ## Privacy
 

package/GOVERNANCE.md

@@ -4,7 +4,7 @@
 
 The project currently has one human maintainer, `@YuLeiFuYun`. Repository automation may complete reviewed source changes under [AGENTS.md](AGENTS.md), but automation is not an independent reviewer and cannot replace accountable human ownership.
 
-The maintainer owns product direction, security policy, repository administration, npm package ownership, Cloudflare deployment decisions, and release credentials. Live npm publication, Worker deployment, credential rotation, and daemon/service replacement remain explicit operator actions.
+The maintainer owns product direction, security policy, repository administration, GitHub tag/Release publication, npm package ownership, Cloudflare deployment decisions, and release credentials. GitHub source publication, live npm publication, Worker deployment, credential rotation, and daemon/service replacement remain explicit operator actions.
 
 ## Decision model
 
@@ -34,7 +34,7 @@ Once a second active maintainer exists, branch protection must require one non-a
 
 ## Release authority
 
-Source release completion requires the exact `main` commit to pass CI, CodeQL, Governance, and OpenSSF Scorecard gates. The annotated Git tag, GitHub Release, release asset, package version, Worker version, and extension version must identify the same source state.
+Source release completion requires the exact `main` commit to pass CI, CodeQL, Governance, and OpenSSF Scorecard gates. The repository owner must start Git tag/GitHub Release publication from a TTY-backed terminal with the explicit confirmation flag; background agents, managed jobs, CI, and redirected sessions are rejected by the supported workflow. This ceremony records accountable operator action but cannot distinguish a human from arbitrary code already running as the same OS user. The annotated Git tag, GitHub Release, release asset, package version, Worker version, and extension version must identify the same source state.
 
 npm publication should move to trusted publishing with GitHub OIDC and a protected release environment. Until the external npm trust relationship is configured, publication remains a deliberate local operator action and no long-lived npm token may be stored in the repository.
 

package/README.md

@@ -3,7 +3,7 @@
 `machine-bridge-mcp` exposes one local workspace to MCP clients through a shared, policy-controlled runtime. Hosted clients connect through an OAuth-protected Cloudflare Worker relay; local clients may launch the same runtime over stdio.
 
 > [!WARNING]
-> The default `full` profile retains every local-user capability: unrestricted files, shell commands, the parent environment, browser automation, applications, resources, and jobs. It is **not** an operating-system sandbox. An authenticated owner may use that ceiling directly without terminal approval. Delegated non-owner accounts require bounded local capability leases for high-impact operations. Use a narrower profile or an isolated OS account, VM, or container for mutually untrusted workloads.
+> The default `full` profile retains every local-user capability: unrestricted files, shell commands, the parent environment, browser automation, applications, resources, and jobs. It is **not** an operating-system sandbox. An authenticated owner may use that ceiling without per-operation prompts. Delegated accounts are permanently constrained by their role; no approval, token, or reconnect can elevate them. Use a narrower profile or an isolated OS account, VM, or container for mutually untrusted workloads.
 
 ## Choose a path
 
@@ -24,18 +24,21 @@ Support boundaries are defined in [SUPPORT.md](SUPPORT.md). Repository participa
 - policy profiles with shared local/Worker enforcement contracts;
 - bounded file, patch, Git, process, diagnostic, application, browser, and managed-job tools;
 - account roles whose authority is intersected with the connected daemon policy;
-- device-signed daemon transport, interruption-free authenticated owner authority, and account/client-bound capability leases for delegated high-impact transactions;
-- structured, privacy-conscious lifecycle events and stable error codes;
+- root-certified ephemeral daemon sessions, trusted OAuth client binding, refresh-family ownership, and non-escalatable account roles;
+- structured, privacy-conscious lifecycle events, a worker-thread-isolated tamper-evident audit chain, and stable error codes;
+- control-plane resilience through end-to-end reserved diagnostic capacity, event-loop-aware relay liveness, and explicit draining-process accounting;
 - fail-closed state, lock, release, package, and supply-chain checks.
 
 The remote Worker authenticates and relays requests. It cannot directly read local files or start local processes. Local-user authority remains in the daemon process.
 
+Expected file-state failures are machine-readable. File mutations return stable codes such as `conflict`, `not_found`, `invalid_request`, and `limit_exceeded`, with bounded `details.reason` tokens where useful. Conflict responses should trigger a fresh read and reconciliation rather than a blind retry; public errors do not include file contents, compared hashes, or hidden paths.
+
 ```text
 Hosted MCP client
   -> HTTPS + OAuth 2.1 / PKCE
   -> Cloudflare Worker + Durable Object
-  -> P-256 device-authenticated outbound WebSocket
-  -> local transaction authorization
+  -> root-certified ephemeral P-256 daemon channel (WebSocket primary; signed HTTPS fallback)
+  -> request-level effective authority and object ownership
   -> local runtime
 
 Local MCP client
@@ -45,6 +48,20 @@ Local MCP client
 
 The complete component and trust-boundary diagram is in [docs/OVERVIEW.md](docs/OVERVIEW.md).
 
+## MCP protocol model
+
+Machine Bridge uses MCP `2026-07-28` as its native protocol. Stdio is current-only. Remote HTTP also accepts bounded, stateless initialization compatibility for `2025-06-18` and `2025-11-25` so older hosts can migrate without restoring the removed session model.
+
+- **Native current requests are self-describing.** Protocol version and client capabilities travel in `_meta`; HTTP requests also mirror the version, method, and applicable name/parameter values into validated headers. Native `2026-07-28` clients use `server/discover` and do not create an MCP protocol session.
+- **Remote initialization compatibility is stateless.** Compatible HTTP clients may use `initialize`, `notifications/initialized`, `ping`, `tools/list`, and `tools/call`; tool calls still execute through the current request-scoped controller. Compatibility does not create or accept `Mcp-Session-Id`, recovery GET, `Last-Event-ID`, persisted replay/delivery state, or initialization-owned authorization state.
+- **HTTP streams are request-scoped and non-resumable.** Closing the response stream cancels that request. There is no recovery GET, SSE event-ID replay, or session-bound delivery store.
+- **Removed session/replay semantics never execute.** Unsupported protocol dates and requests for the retired session/recovery model receive bounded rejection or upgrade guidance rather than legacy state or replay behavior.
+- **Transport identity is not conversation identity.** Stdio and HTTP processes/connections may interleave unrelated requests; state that spans calls must use an explicit tool, job, process-session, or resource identifier.
+
+The Worker validates the actual `/mcp` Origin, mirrored headers, role-filtered tool visibility, and raw arguments before routing or daemon dispatch. Tool arguments use one bounded JSON Schema 2020-12 contract in both Worker and local runtime; validation has fixed schema and runtime-work budgets and never echoes rejected values. Request-stream cancellation uses a private random capability stripped from public requests and forwards no OAuth/DPoP credential.
+
+`resolve_task_capabilities` provides bounded, set-level route advice across registered commands, direct Bash/argv, process sessions, managed jobs, files/Git, browser, applications, resources, and diagnostics. It does not hide or disable tools: Bash through `exec_command` remains the first-class general escape hatch under a shell-capable effective policy. The versioned result is filtered by the authenticated account's effective authority, reports routing ambiguity and fallbacks, and accepts the previous `refresh.fingerprint` to omit unchanged static instructions while still recomputing task-specific matches. Route scores are deterministic relative ranks within one response, not probabilities or cross-version metrics.
+
 ## Requirements
 
 - Node.js 26 or newer
@@ -110,7 +127,7 @@ Use the printed endpoint in the hosted client:
 https://<worker>.<account>.workers.dev/mcp
 ```
 
-Remote readiness is end-to-end. A daemon becomes available only after a Worker probe traverses the same authenticated local dispatch and session-bound result path used by real tool calls. A replacement daemon is verified before it displaces a healthy incumbent.
+Remote readiness is end-to-end. A daemon becomes available only after a Worker probe traverses the same authenticated local dispatch and result-delivery path used by real tool calls. A replacement daemon is verified before it displaces a healthy incumbent.
 
 For account roles, OAuth lifecycle, supported callback behavior, and tenancy limits, read [docs/GETTING_STARTED.md](docs/GETTING_STARTED.md) and [docs/MULTI_ACCOUNT.md](docs/MULTI_ACCOUNT.md).
 
@@ -153,9 +170,11 @@ The default is intentionally `full` for owner-operated local automation. This is
 
 The shared source of truth is `src/shared/policy-contract.json`. The generated matrix is in [docs/POLICY_REFERENCE.md](docs/POLICY_REFERENCE.md).
 
-For remote calls, `server_info.authorization.effective_policy` and `effective_tools` are authoritative. Daemon policy and tools describe only the local capability ceiling before account-role and host-side filtering.
+For routine remote health checks, prefer `server_info` with `detail: "summary"`; the empty/default call remains full diagnostics. For routine workspace inventory, `project_overview` also accepts `detail: "summary"`; it preserves policy/tool counts and top-level names/types without repeating exact tool arrays, account identity, routing fingerprints, or per-entry paths/sizes. Its empty/default call likewise remains full for compatibility. For remote calls, `server_info.authorization.effective_policy` and, when exact membership is needed, the full projection's `effective_tools` are authoritative. Daemon policy and tools describe only the local capability ceiling before account-role and host-side filtering.
 
-`full` is the daemon capability ceiling. An authenticated owner account may exercise it directly without approval IDs or terminal commands. Delegated reviewer, editor, and operator accounts remain constrained by their role profile, and their high-impact operations require account/client-bound, time-bounded local leases. Use `machine-mcp approval` only when administering those delegated-account leases. See [local transaction authorization](docs/LOCAL_AUTHORIZATION.md).
+`tools/list` is a stable discovery catalog for the authenticated account role. A brief relay interruption does not withdraw tool definitions or require a tools-list-changed notification. Discovery is not authority: every `tools/call` is still intersected with the current end-to-end-ready daemon policy and tool ceiling, and fails retryably with `unavailable` when no daemon is ready. `server_info.tool_delivery` distinguishes the stable advertised catalog from the currently effective daemon/account intersection. WebSocket is the preferred daemon transport: it uses a five-second protocol-level Ping and a ten-second inbound-silence timeout, with an independent twenty-five/seventy-five-second application heartbeat and a wider ninety-second Worker liveness fallback. For a scheduling-responsive daemon, WSS black-hole detection is therefore bounded to fifteen seconds; local event-loop stalls use the separate recovery-grace path. If WSS is not verified-ready, the same root-certified ephemeral device identity can establish a signed HTTPS fallback. Fallback requests bind the fixed route/origin/server/version, a short-lived nonce, timestamp, and exact body hash; they use a seven-second request deadline, twelve-second liveness window, one-second ordinary poll cadence, and a 750 ms minimum request-start interval. The first authenticated exchange enters probing immediately, so verified readiness requires at most two bounded exchanges rather than a separate challenge round trip. Candidate → probing → verified-ready handover prevents the Worker from dispatching until the daemon has processed `ready_ack` and returned sequenced `https_ready`; a same-instance takeover may retire a Worker-side zombie WSS only after the signed candidate preconditions pass. Both directions use bounded contiguous transport sequences, so a lost HTTP response retransmits the same transport envelope and duplicates are discarded before business handling; this does not restore MCP sessions, recovery GET, `Last-Event-ID`, or public result persistence. Same-instance `resume_calls` / `resume_calls_ack` remains authoritative for in-flight ownership. The daemon sends `resume_calls_ack.missing_ids` only after replacement readiness and only for IDs absent from both its active-call set and unacknowledged-result ledger. Those proven-undelivered calls may be retransmitted with the same call ID, arguments, authority, and a reduced timeout inside the original deadline; a call that may have executed is never automatically replayed. A new call may wait up to fifteen seconds for a verified daemon channel, but measured recovery time is deducted from that call's original execution budget instead of extending the hosted foreground envelope. Hosted synchronous calls otherwise retain their ordinary 20-second execution plus separate five-second Worker settlement margin; configurable browser/application tools retain 20-second ordinary defaults, compound `computer_observe` / `computer_act` retain 30-second defaults, and the explicit remote maximum remains 45 seconds. Remote `exec_command`, `run_process`, and `run_local_command` require a caller-held `idempotency_key`, commit a principal-bound one-step managed job, and remain recoverable with `read_job`; `start_process` remains daemon-lifetime interactive state, while `read_process` uses short bounded polls. The durable process façade preserves account/tool authority and delegated workspace sandbox rather than expanding privileges.
+
+`full` is the daemon capability ceiling. An authenticated owner may exercise it without per-operation approval IDs. Delegated reviewer, editor, and operator accounts remain inside immutable role ceilings; out-of-role operations are denied rather than converted into a temporary elevation workflow. Process sessions, retained output, and managed jobs are additionally bound to account, client, and refresh-token family. See [local authorization](docs/LOCAL_AUTHORIZATION.md).
 
 ## Browser and application automation
 
@@ -170,9 +189,15 @@ Load the printed unpacked-extension directory into the intended Chromium profile
 
 Machine Bridge does not launch or identify a separate browser profile. It controls whichever profile contains the extension, including that profile's tabs and login state. Read [docs/LOCAL_AUTOMATION.md](docs/LOCAL_AUTOMATION.md) before enabling it.
 
+For stateful GUI trajectories, owner/full callers can use the higher-level `computer_observe` / `computer_act` pair. `computer_observe` creates one bounded browser or application snapshot with semantic evidence and native MCP image content when available; `computer_act` consumes the exact snapshot as one-shot mutation authority, dispatches at most once, observes post-state, and reports dispatch/effect settlement separately so ambiguous mutations are not automatically replayed. Their `timeout_seconds` value is one end-to-end budget for the compound operation rather than a fresh timeout for each internal screenshot, Accessibility/DOM preflight, dispatch, verification, or post-observation stage. See [docs/COMPUTER_USE.md](docs/COMPUTER_USE.md).
+
 ## Durable work and local resources
 
-Interactive process sessions end with the daemon connection. Long, cleanup-sensitive, or remotely initiated workflows should use managed jobs, which persist ordered argv steps and `finally_steps` under owner-only local state.
+Remote request-owned foreground work uses the hosted reply-safe budgets described above; configurable browser/application calls may explicitly request at most 45 seconds, while remote `exec_command`, `run_process`, and `run_local_command` are durable one-step jobs with a 10-second acceptance envelope and an independent 1–600-second child execution budget after admission. The Worker retains separate settlement ownership for five additional seconds, but neither that margin nor its internal stream metrics prove that an external MCP host consumed the terminal frame. Keep mutations and validation in independently terminal calls. A timeout is a protocol result, not proof that descendant cleanup has already completed; a remote owner can inspect `diagnose_runtime.runtime.processes`, while local stdio exposes `server_info.runtime.processes`. Non-owner accounts receive authority-scoped readiness rather than machine-wide process activity. Long, cleanup-sensitive, or remotely initiated workflows should use process sessions or managed jobs; managed jobs persist ordered argv steps and `finally_steps` under owner-only local state and continue across an MCP disconnect.
+
+On macOS, authorized remote activity uses a bounded idle-sleep assertion so ordinary system Idle Sleep does not suspend an active remote workflow. Relay handlers share the assertion for their execution lifetime plus a fixed five-minute inactivity grace; an admitted remote process session extends daemon-side ownership until its child settles, and an account-backed managed-job runner owns a runner-bound assertion from confirmed claim through terminal persistence. Local managed jobs do not acquire the remote-continuity assertion. These protections do not override explicit sleep or lid-close behavior.
+
+When `run_process` or `exec_command` returns a child exit code and bounded stdout/stderr, the local process did run. For nested tools such as `ssh`, a remote forced-command usage message or command allowlist is therefore evidence from the target-side authorization layer, not evidence that Machine Bridge blocked process execution. Diagnose and change the narrowest failing layer instead of widening the `full` profile, which already removes Machine Bridge's own shell and path restrictions.
 
 Credentials and files can be registered by alias without returning their contents through MCP:
 
@@ -194,11 +219,10 @@ machine-mcp status
 machine-mcp doctor
 machine-mcp workspace show|set|reset
 machine-mcp service status|install|start|stop|uninstall
-machine-mcp account list|add|role|enable|disable|rotate-password|remove
-machine-mcp approval list|approve|grant|revoke|clear
+machine-mcp account list|clients|revoke-client|add|role|enable|disable|rotate-password|remove
 machine-mcp browser status|setup|pair|path
 machine-mcp resource add|list|check|remove
-machine-mcp job submit|inspect|approve|list|read|cancel
+machine-mcp job submit|inspect|list|read|cancel
 machine-mcp rotate-secrets
 machine-mcp uninstall [--keep-worker] [--yes]
 ```
@@ -212,11 +236,11 @@ The exact tool set depends on the effective policy and account role. Both transp
 Major groups include:
 
 - workspace reads, writes, exact edits, and transactional patches;
-- Git status, diff, log, and show with helper suppression and privacy bounds;
+- Git status, diff, log, and show with helper suppression and privacy bounds, plus structured staged-only `git_commit`;
 - direct argv execution, shell execution, and interactive process sessions;
 - runtime diagnostics and structured project/capability discovery;
 - managed jobs and registered local resources;
-- supported application and browser operations.
+- supported application/browser operations and snapshot-bound Computer Use.
 
 ## Development and verification
 
@@ -236,17 +260,31 @@ Testing details and design rules are in [docs/TESTING.md](docs/TESTING.md). Engi
 
 ## Release boundary
 
-A package change requires a version bump, matching changelog section, complete verification, and interactive verification of the exact candidate tarball:
+Version 3 and later use a mandatory prerelease and soak path. Package work starts as `dev`, `beta`, or `rc`; it does not claim the stable version while candidate testing is still underway.
 
 ```sh
 npm run release:candidate
-# After explicit owner authorization in the conversation, the coding agent starts and verifies:
-npm run release:candidate:start -- --allow-worker-deploy
-# The coding agent records acceptance, pushes, merges, then runs:
-npm run release
+# The coding agent rechecks source/package identity and disposable installability before live activation:
+node scripts/start-release-candidate.mjs --install-only
+# After explicit owner authorization, the owner or authorized agent runs the exact persistent activation command:
+npm run release:candidate:activate -- --allow-worker-deploy
+# Activation requires device-authenticated relay readiness. One explicit authentication rejection may
+# redeploy the same Worker once with the unchanged selected identity; it never rotates credentials.
+# The login service is accepted only after a committed machine owner and the matching daemon
+# publish the post-authentication, post-relay-probe readiness checkpoint.
+# After the coding agent verifies the live Worker/daemon and records acceptance,
+# source publication requires explicit owner authorization; a TTY is optional:
+npm run prerelease:release -- --owner-confirm
+# Registry publication and live install are separately authorized operations:
+npm run prerelease:publish
+npm run prerelease:install -- --allow-worker-deploy
 ```
 
-The owner action is to explicitly authorize the exact candidate and any in-place update of the configured same-name Worker in the active conversation; the coding agent performs the startup and verification through Machine Bridge. The coding agent must observe the deployed Worker version/hash, remote health, relay readiness, connected candidate version, and representative functionality before recording acceptance; automated checks alone are insufficient. npm publication and Worker deployment remain separate owner-operated live actions. See [docs/RELEASING.md](docs/RELEASING.md).
+Formal soak begins only after the exact published prerelease is installed and activated. Minimum soak is seven days for a major release, three days for a minor release, and one day for a patch. Every blocking fix creates a new prerelease and restarts the clock.
+
+Stable promotion must retain the soaked package's functional digest. After the owner reports successful soak, the agent records the soak result and prepares and verifies the stable candidate. Final GitHub tag/Release publication requires explicit owner authorization and uses `npm run release -- --owner-confirm`; npm stable publication is the separate explicitly authorized `npm run stable:publish` operation.
+
+See [docs/RELEASING.md](docs/RELEASING.md).
 
 ## Documentation