machine-bridge-mcp 3.0.0-beta.115 → 3.0.0-beta.141

package/CHANGELOG.md

@@ -1,5 +1,183 @@
 # Changelog
 
+## 3.0.0-beta.141 - 2026-08-26
+
+- Preserve immediate recovery evidence for remote one-step process carriers under a saturated 512-state managed-job store. The previous eviction order always discarded `transient_process` terminal results before any ordinary durable terminal history; with 510 durable terminals already retained, short `exec_command` helpers could therefore return a recoverable job ID and then become `not_found` before the next `read_job`. Beta.141 reserves at most the newest 16 otherwise-removable transient results for thirty minutes. The incoming transient counts against that bound, older/excess transient history is still evicted first, ordinary durable history is next, dependency-protected records remain pinned, and the hard 512-state cap is unchanged.
+- Correct the Windows same-daemon runner-exit integration oracle exposed by merged-main CI. Production schedules reconciliation at 10.1 seconds and may retry two more times at 10.1-second intervals after transient `permission_denied`/conflict/timeout/resource-unavailable failures, but the fixture asserted autonomous relaunch after only 20 seconds. The provider logged attempt 1 with `retry_scheduled:true`, making the earliest legal second attempt 20.2 seconds. The fixture now allows forty seconds, while deterministic unit coverage continues to inject a first Windows sharing failure and require bounded retry semantics.
+- Keep the host boundary explicit: recent transient retention improves `read_job` recovery after MCP/host interruption but cannot revive a ChatGPT turn that the external host already terminated or prove final-response receipt. No tool arguments, results, paths, or identities are added to diagnostics or logs; hosted tool schema generation remains 11.
+- Supersede the accepted beta.140 candidate before GitHub prerelease publication because managed-job retention production code and shipped documentation changed. Beta.141 therefore requires a fresh frozen full verification, candidate, guarded activation, activated-package OAuth canary, live verification, acceptance, exact-head provider run, and merged-main exact-commit CI.
+
+## 3.0.0-beta.140 - 2026-08-26
+
+- Retire the expired beta.104 resource-transaction directory compatibility state machine after an independent maintenance review confirmed its documented removal condition is satisfied. Current `transaction.lock` ownership remains the complete-before-visible regular-file contract; the old directory reader, owner-publication staging recovery, quarantine/restore branch, and migration-only process-identity paths are removed. An obsolete `transaction.lock/owner.json` directory now fails closed without mutation so unsupported historical state remains inspectable instead of being destructively migrated by stale code.
+- Extract Worker role-visible tool selection and effective authority projection from the near-limit `BridgeRoom` composition root into `worker-tool-authority.ts`. Direct regressions bind owner/reviewer catalog filtering, cloned tool definitions, and daemon-tool intersection; the Worker root drops from 828 to 818 lines without changing OAuth, Durable Object, relay, or local authorization semantics.
+- Refresh current architecture/testing/upgrading documentation around those boundaries. The independent privacy pass continues to find no tracked credential-bearing files or real secret values in publication surfaces; current-tree and reachable-history privacy gates plus development/production dependency audits remain clean. Historical audit/changelog records are retained as history rather than rewritten.
+- Supersede the accepted beta.139 candidate because shipped local/Worker source and documentation changed after acceptance. Beta.140 therefore requires a fresh frozen full verification, candidate, activation, deployed OAuth canary, live verification, acceptance, and exact-head provider run before publication.
+
+## 3.0.0-beta.139 - 2026-08-26
+
+- Correct an independent documentation-contract drift that survived existing release tests: current `ARCHITECTURE.md`, `THREAT_MODEL.md`, and `TESTING.md` still described the retired GitHub TTY/confirmation ceremony even though governance, engineering, releasing, and the implemented publisher make GitHub source publication standing-authorized after exact evidence gates. npm registry publication remains the sole explicit current-task owner authorization boundary through `--owner-confirm`. Architecture regression coverage now treats those three normative guides as part of the same publication contract so the obsolete user-presence model cannot silently return.
+- Remove a duplicate managed-job terminal-state classifier from recent-activity diagnostics. Activity aggregation now consumes the canonical `isTerminalManagedJobStatus()` contract instead of maintaining a second negative list of active/staged/unreadable states, preventing future lifecycle additions from being miscounted as terminal merely because one diagnostic helper was not updated.
+- Move application-automation composition out of `runtime.mjs` into a dedicated runtime composition module. This is a behavior-preserving responsibility extraction that restores meaningful headroom to a core composition file that had reached 696/700 lines without changing application authorization, capability projection, background-input selection, cancellation, or process execution semantics.
+
+## 3.0.0-beta.138 - 2026-08-26
+
+- Supersede the accepted beta.137 candidate after its exact-head Windows provider run reached the new npm publication regression and proved the hard-timeout tree barrier was still incomplete. The resistant lifecycle descendant wrote its delayed marker after `runExecutable(..., hardTimeout:true)` had already returned, so the provider correctly rejected the claim that publication timeout settlement implied complete process-tree termination.
+- Separate **tree-termination request** from **tree-termination settlement** in the shared internal executable runner. On POSIX, isolated-process-group `SIGKILL` remains a synchronous kernel signal-dispatch boundary. On Windows, hard termination now uses a dedicated bounded barrier that launches `taskkill.exe /PID <leader> /T /F` and waits for the helper's terminal `close(0)` before tree settlement is accepted. A failed, nonzero, or non-settling helper cannot be silently reclassified as an ordinary successful timeout; publication reports unconfirmed termination distinctly.
+- Make `runExecutable` wait for both direct-child close and the hard tree barrier before returning a timeout result. Deterministic runtime coverage proves that an early direct-child `close` cannot release the caller while the tree barrier is still pending, and a Windows simulation proves the barrier remains pending until the forced `taskkill` helper completes. The existing real resistant-descendant publication regression remains unchanged, so hosted Windows must prove the original post-timeout side effect is impossible rather than passing through a longer sleep.
+- Remove the beta.137 acceptance record and advance package/runtime identity to **3.0.0-beta.138**. The new shared `src/local` process-tree module changes package bytes, so beta.138 requires a fresh full gate, candidate, activation, OAuth canary, live verification, acceptance, and exact-head provider run.
+
+## 3.0.0-beta.137 - 2026-08-26
+
+- Supersede the locally accepted beta.136 candidate after exact-head Windows CI independently validated the new npm publication regression and then failed later in `worker-types-generator:test`. The provider reached and passed `publish-npm:test`, proving the beta.136 process-tree/deadline repair itself was portable; it then failed in the older Wrangler lifecycle cleanup path with `wrangler types could not force cleanup`.
+- Fix the Windows cleanup-settlement race in `wrangler-command-lifecycle.mjs`. A `ChildProcess.kill()` return value now means only that a cleanup request was attempted; it is never treated as proof that the process has or has not reached terminal state. Graceful cleanup may escalate to a force request, but the wrapper waits for the child `close` event or a separate bounded post-force settlement deadline. A real zero exit retains precedence over raced cleanup requests, while a child that actually closes only after forced termination still fails closed.
+- Add a deterministic cross-platform regression for the exact provider semantics: the fixture crosses the completion grace, accepts the synthetic `SIGTERM`, returns `false` for the later synthetic `SIGKILL`, and then exits zero. The old implementation necessarily failed immediately on the `false` request result; beta.137 waits for observed settlement and succeeds. Architecture now forbids reintroducing `killed !== true` as process-settlement evidence.
+- Remove the beta.136 acceptance record and advance package/runtime identity to **3.0.0-beta.137**. Because `scripts/` ships in the npm package, the Windows provider repair changes package bytes and requires a fresh full gate, candidate, activation, OAuth canary, live verification, acceptance, and exact-head provider run.
+
+## 3.0.0-beta.136 - 2026-08-26
+
+- Fix the npm prerelease publication control plane exposed after beta.135 GitHub release. `prepublishOnly` legitimately ran the full verification plan for 681.4 seconds, but `publish-npm.mjs` applied one fixed ten-minute `spawnSync` deadline to every npm stage. The direct npm parent therefore returned `ETIMEDOUT` while lifecycle descendants continued the remaining verification, `version:check`, and `release:check` on the inherited terminal. The registry was independently checked after the incident and `machine-bridge-mcp@3.0.0-beta.135` remained absent, proving the upload stage never ran.
+- Run publication npm stages through the existing isolated process-tree execution boundary instead of `spawnSync`. Full prepublication verification now has a separate thirty-minute deadline while dry-run/upload retain ten-minute bounds; deadline expiry hard-terminates the complete npm lifecycle tree before returning failure. A real regression fixture launches a resistant descendant that would write after the parent timeout and proves it cannot continue after publication settlement.
+- Correct relay interruption evidence without inventing a network repair. The observed beta.135 episode was WSS close `1006` on a system VPN/TUN route with no daemon event-loop stall; the signed HTTPS fallback became verified-ready after roughly 1.35 seconds while WSS itself recovered after roughly 13 seconds. WebSocket warnings now name the affected WSS layer instead of claiming the whole relay is unavailable, and `https_fallback_last_takeover_ms` retains the bounded WSS-close-to-HTTPS-ready interval after WSS reclaims primary ownership. Same-instance call recovery, fallback takeover semantics, replay safety, and hosted tool schema generation **11** are unchanged.
+- Advance package/runtime identity to **3.0.0-beta.136** because the shipped publication script, relay diagnostics, and documentation changed after beta.135 acceptance and GitHub prerelease publication.
+
+## 3.0.0-beta.135 - 2026-08-26
+
+- Harden same-daemon managed-job runner recovery on Windows after PR #95 advanced beyond beta.134's fixed `file://` test-hook loading bug. The exact-head Windows run reached the later dependency-wait crash regression, observed the runner `exit` callback, then logged `permission_denied` from `reconcileStatus` and failed to autonomously relaunch the runner. This proves the remaining defect was transient Windows filesystem contention in the recovery path rather than a missed child-exit event or another ESM-loader failure.
+- Retry only bounded transient filesystem mutation errors (`EACCES`, `EBUSY`, `EPERM`, `ENOTEMPTY`) while clearing stale runner runtime/ownership artifacts, and clear those artifacts before persisting the next recovery-attempt state so a failed cleanup cannot leave a fresh half-committed status that suppresses immediate recovery. Runner-exit reconciliation also receives a bounded retry schedule for transient permission/conflict/timeout/resource-unavailable failures; integrity and other non-transient failures remain fail closed rather than being looped.
+- Add deterministic regression coverage for transient removal backoff and runner-exit reconciliation retry policy while preserving the existing real dependency-wait runner kill/relaunch integration test. Production authorization, resource admission, cleanup guarantees, managed-job execution ceilings, hosted read pacing, and tool schema generation **11** are unchanged. Advance package/runtime identity to **3.0.0-beta.135** because production recovery code changed after beta.134 acceptance.
+
+## 3.0.0-beta.134 - 2026-08-25
+
+- Correct the beta.131 managed-job test runner hook for Windows without changing production execution. PR #95 showed the test-only `node --import` argument was passed as a native absolute path; Node accepts that form on POSIX but the Windows ESM loader interprets a drive-letter path such as `D:\\...` as an unsupported `d:` URL scheme. The fixture now passes the hook as its canonical `file://` URL, preserving the exact-parent/exact-specifier interception boundary on every supported platform.
+- Keep beta.133 production continuity behavior unchanged: planned daemon drain, same-`job_id` read recovery, privacy-bounded Durable Object continuity evidence, managed-job retention/listing policy, resource admission, hosted read pacing, and the six-hour managed-job step ceiling are unchanged. Hosted tool schema generation remains **11**.
+- Advance package/runtime identity to **3.0.0-beta.134** because the candidate/test tree changed after beta.133 acceptance.
+
+## 3.0.0-beta.133 - 2026-08-25
+
+- Persist a privacy-bounded Worker continuity summary in Durable Object storage so post-incident diagnosis survives Worker isolate replacement. The owner/full `server_info` projection now retains only fixed-category counters/timestamps for planned drains, planned-drain affected-call count, socket disconnects with planned/unplanned classification and bounded close metadata, plus the latest request-abort and stream-cancel-control observations. It stores no account/client identity, call IDs, tool names, arguments, results, network endpoints, or close reasons.
+- This closes a diagnostic gap exposed by the beta.132 live restart canary itself: the in-flight hosted `read_job` correctly returned retryable `daemon_planned_drain` with `recovery.mode=read_same_job`, but a subsequent `server_info` landed on a fresh Worker isolate and the isolate-local continuity counters had reset to zero. The new durable summary is evidence for later causal classification; it still cannot observe or revive a ChatGPT host turn or prove final assistant-message receipt.
+- Keep beta.132 planned-drain execution semantics unchanged. Daemon process identities remain generation-distinct, generic ambiguous mutations remain fail closed, and a planned drain still only makes read-only `read_job` recoverable with the same `job_id`. Production managed-job/resource-admission limits, the 600-second durable-process ceiling, six-hour managed-job step ceiling, and hosted read pacing are unchanged.
+- Advance package/runtime identity to **3.0.0-beta.133** and hosted tool schema generation to **11** because `server_info` full diagnostics and its host-visible description now advertise durable continuity evidence.
+
+## 3.0.0-beta.132 - 2026-08-25
+
+- Convert planned local-daemon shutdown from an unclassified transport loss into an explicit drain handshake. Before a ready runtime closes its relay, it sends one bounded `daemon_draining` control message; the Worker settles calls still owned by that daemon with a structured `daemon_planned_drain` error and acknowledges the drain before shutdown proceeds. Generic calls remain fail-closed when execution may have started, while hosted `read_job` now carries read-only recovery metadata binding the original `job_id` and is retryable as the same read after reconnect. This does not make an already terminated ChatGPT host turn resumable and does not claim final-response receipt is observable.
+- Improve retained-job recovery visibility without expanding the 512-state cap. `list_jobs` still prioritizes unreadable/active/staged state, then durable terminal managed-job results, and only then transient one-step process history. Owner/local capacity diagnostics now distinguish `durable_terminal` from `transient_terminal`; delegated callers do not receive this global retained-state composition. Existing retention still reclaims transient process history before ordinary durable terminal history.
+- Preserve the beta.131 managed-job test-isolation work while keeping production resource security unchanged. Its private resource-lock fixture now tolerates only the test-side complete-before-visible hard-link publication window while acquiring the deliberate contention lock; the production transaction reader retains the fixed four-attempt multiple-link fail-closed policy.
+- Advance package/runtime identity to **3.0.0-beta.132** and hosted tool schema generation to **10** because hosted `read_job` recovery semantics and discovery guidance changed. The thirty-minute managed-job resource-admission ceiling, 600-second durable-process ceiling, six-hour managed-job step ceiling, and hosted read pacing remain unchanged.
+
+## 3.0.0-beta.131 - 2026-08-25
+
+- Isolate the managed-job integration suite's semantic child-process fixtures from unrelated hosted-runner pressure without weakening production resource admission. Beta.130 proved the deterministic light fixtures were fixed, then the merged `main` Windows run failed in `timeout terminates descendants`: that regression must execute a real Node script that creates a descendant process, so converting it to a light probe would destroy the behavior under test.
+- Thread the existing `launchRunner(..., { spawnProcess })` in-process test seam through `ManagedJobManager` normal launch and recovery paths. The option is a JavaScript function accepted only by direct in-process construction; it is not part of MCP input, persisted job plans, environment configuration, or the CLI. Production `LocalRuntime` does not provide it and `job-runner.mjs` still constructs the ordinary production `ResourceCoordinator` unchanged.
+- `managed-jobs:test` now uses that seam to start runner processes with a Node `--import` hook scoped to the exact `job-runner.mjs` parent URL and exact `./resource-admission.mjs` specifier. Only that runner import is redirected to a test fixture that subclasses the production coordinator and injects the established synthetic healthy-host sampler. Job child processes do not inherit the import hook, coordinator leases/locks/fairness still use the production implementation, and dedicated resource-admission tests continue to cover real pressure decisions independently.
+- Advance package/runtime identity to **3.0.0-beta.131**. Hosted schema generation remains **9**; production resource admission, the thirty-minute admission ceiling, 600-second durable-process ceiling, six-hour managed-job step ceiling, and hosted read pacing remain unchanged.
+
+## 3.0.0-beta.130 - 2026-08-25
+
+- Remove the last unrelated adaptive launch from the Windows dependency-retention fail-closed regression. Beta.129 correctly stopped injecting `NODE_V8_COVERAGE` into minimal-environment jobs, and PR CI then advanced to the next pressure-sensitive setup: `old protected dependency result` still used `node -e ""` even though the test only needs one successfully persisted upstream result before it mutates retention metadata. Under hosted Windows pressure that no-op was correctly classified as adaptive and remained in `resource_admission` until the fixture settlement window expired.
+- That setup now uses the exact current-runtime `node --version` light probe, matching the already-hardened dependency execution fixtures. An architecture contract prevents this specific retention setup from regaining adaptive work. Staged validation-only plans and fixtures whose scripts, failures, timing, process trees, resources, or cleanup behavior are themselves under test remain unchanged.
+- Advance package/runtime identity to **3.0.0-beta.130**. Hosted schema generation remains **9**; production resource admission, the thirty-minute admission ceiling, 600-second durable-process ceiling, six-hour managed-job step ceiling, and hosted read pacing remain unchanged.
+
+## 3.0.0-beta.129 - 2026-08-25
+
+- Fix the remaining Windows managed-job fixture pressure leak exposed only after beta.128 reached merged-main push CI. The dependency-failure regression uses a `minimalEnv:true` manager and an exact current-runtime `node --version` cleanup probe, but the suite-wide `createManagedJobTestManager()` wrapper still injected an empty `NODE_V8_COVERAGE` key into every step. Production correctly treats the presence of Node instrumentation keys as untrusted even when the value is empty, so that test-only injection forced the cleanup probe back into adaptive resource admission; on a pressured Windows runner it stayed in `cleaning/resource_admission` until the test settlement window expired.
+- Preserve coverage isolation only where it is actually needed. Full-environment test managers (`minimalEnv:false`) continue to receive the empty `NODE_V8_COVERAGE` override so their business children cannot write into the parent coverage stream. Minimal-environment managers no longer receive a synthetic instrumentation key because production `executionEnv` already excludes it. An architecture contract binds this distinction. Production light-command security, resource-admission policy, cleanup behavior, and all long-task execution ceilings remain unchanged.
+- Advance package/runtime identity to **3.0.0-beta.129**. Hosted schema generation remains **9**; the thirty-minute resource-admission ceiling, 600-second durable-process ceiling, six-hour managed-job step ceiling, and hosted read pacing remain unchanged.
+
+## 3.0.0-beta.128 - 2026-08-25
+
+- Harden the Wrangler lifecycle regression fixture against transient Windows filesystem locks after a fully settled child process. Beta.127 proved the earlier managed-job resource-admission issue was gone, then Windows CI failed much earlier in `worker-types-generator:test` with `EBUSY` while recursively removing its unique `machine-bridge-wrangler-lifecycle-*` temp root. The Wrangler helper resolves only from the child `close` event, after process exit and stdio closure; the remaining failure is the bounded Windows filesystem lock window seen immediately after releasing a process working directory.
+- Reuse the repository's established Node `fs.rm` cleanup policy for temporary roots: recursive forced removal now permits five native retries with a 50 ms retry delay. This applies only to test-fixture cleanup and only when Node reports a retryable filesystem removal error; it does not add a business-process sleep, change Wrangler completion/termination semantics, weaken resource admission, or change any production task execution ceiling.
+- Advance package/runtime identity to **3.0.0-beta.128**. Hosted schema generation remains **9**; the thirty-minute resource-admission ceiling, 600-second durable-process ceiling, six-hour managed-job step ceiling, and hosted read pacing remain unchanged.
+
+## 3.0.0-beta.127 - 2026-08-25
+
+- Fully isolate the managed-runner log-trimming fixture from shared coverage instrumentation as well as host pressure. Beta.126 Windows CI proved that changing its child argv to `node --version` was not sufficient: the suite-wide `isolateStepCoverage()` wrapper deliberately adds an empty `NODE_V8_COVERAGE` key to every managed-job step, while the production release-control classifier correctly treats the presence of Node instrumentation/preload environment keys as untrusted and therefore refuses the zero-resource light-command bypass. On a pressured hosted Windows runner that sent this unrelated log fixture back into normal resource admission for the test settlement window.
+- The fixture now uses a dedicated raw `ManagedJobManager`, independent job root, and `minimalEnv:true`, bypassing the suite's child-coverage wrapper only for this log-bounding probe. It explicitly asserts `full_env=false` and absence of `NODE_V8_COVERAGE` before launch, then still executes the exact current runtime `node --version`. Production environment hardening and fail-closed resource classification are unchanged; no unsafe environment is newly granted light admission.
+- Advance package/runtime identity to **3.0.0-beta.127**. Hosted schema generation remains **9**; the thirty-minute resource-admission ceiling, 600-second durable-process ceiling, six-hour managed-job step ceiling, and hosted read pacing remain unchanged.
+
+## 3.0.0-beta.126 - 2026-08-25
+
+- Make the same-daemon dependency-wait runner recovery regression prove its intended property without contaminating the observation. Beta.125 Windows CI showed that the final assertion still called `manager.read(upstream)` after the downstream had already failed, even though that read itself performs reconciliation. The test already proves autonomous relaunch from persisted state by observing `recovery_attempts=1` and a new runner PID without a managed-job read. It now completes the proof through the independently running downstream job's structured `dependency_failure` witness, requiring that downstream observed the recovered upstream as `status=failed` with `error_class=dependency_failed`; no external upstream read participates in that proof.
+- Beta.125 removed the previous eight-minute host-resource wait and reduced the Windows platform failure from 22m47s to 15m14s. macOS platform+install passed in 6m15s, Ubuntu full in 9m39s, and all CodeQL/governance/dependency/workflow/package gates were green. The remaining Windows failure was the test-only upstream read assertion above, not a production timeout or CI outer-envelope limit.
+- Advance package/runtime identity to **3.0.0-beta.126**. Hosted schema generation remains **9**; the thirty-minute resource-admission ceiling, 600-second durable-process ceiling, six-hour managed-job step ceiling, and hosted read pacing remain unchanged.
+
+## 3.0.0-beta.125 - 2026-08-25
+
+- Fix the remaining Windows `managed-jobs:test` host-pressure dependency exposed by beta.124 PR CI. The suite's bounded runner-log diagnostic fixture staged a no-op `node -e` child, manually promoted the draft to queued state, and launched a real runner only to verify log trimming. Since beta.123 correctly classifies arbitrary Node eval as adaptive, that otherwise unrelated diagnostic could spend the entire eight-minute test settlement window in production resource admission on a loaded Windows hosted runner. The fixture now uses the exact current-runtime `node --version` light probe, matching the deterministic dependency fixtures and testing log bounding rather than host scheduling. An architecture contract prevents this specific runner-diagnostic fixture from regaining adaptive business work.
+- Beta.124 remains valid evidence for the self-test isolation fix: macOS platform CI passed in 5m27s, proving the former macOS self-test hang was removed, while Ubuntu full, CodeQL, governance, dependency review, workflow policy, and package audit were all green. Windows failed only at the final `managed-jobs:test` fixture above after 22m47s; the new 30-minute platform CI envelope was not the failure source. Because beta.125 changes test/release inputs after beta.124 acceptance, it must earn fresh frozen verification and candidate acceptance before promotion.
+- Advance package/runtime identity to **3.0.0-beta.125**. Hosted schema generation remains **9**; the thirty-minute resource-admission ceiling, 600-second durable-process ceiling, six-hour managed-job step ceiling, and hosted read pacing remain unchanged.
+
+## 3.0.0-beta.124 - 2026-08-25
+
+- Make `local-self-test` resource/managed-job CLI fixtures deterministic on shared CI hosts instead of accidentally using real host pressure as a clock. Executing fixtures use the exact runtime `node --version` probe introduced in beta.122 and settlement uses one shared five-minute **test-harness** wall-clock budget with direct persisted-state reads plus one actual CLI read. A follow-up local run exposed a more serious isolation bug in the test itself: its uninstall-safety fixture could fall through to the real machine-level `stopAutostart`/launchd path when its synthetic managed-job state was not actually active, taking the currently serving beta.123 login daemon offline. The self-test now calls the exported managed-state uninstall preflight directly, never invokes the real uninstall command, and architecture contracts require the production uninstall path to run that preflight before any autostart mutation. Production resource admission remains capped at thirty minutes and managed-job steps remain capable of six-hour execution; no user-task or ChatGPT-turn duration was shortened.
+- Forward only `local-self-test` phase-start/phase-complete markers through the otherwise bounded/suppressed verification runner, so a future hosted hang identifies the active phase without enabling verbose test logs or increasing host-visible MCP call density.
+- Increase only the GitHub `platform-check` job envelope from 20 to 30 minutes. Beta.123 Windows CI completed all 123 platform checks in about 18.3 minutes and printed a successful global-install smoke result before GitHub cancelled the job at its old 20-minute shell deadline; the larger CI envelope preserves rather than shortens valid cross-platform verification.
+- Advance package/runtime identity to **3.0.0-beta.124**. Hosted schema generation remains **9** and all long-task delivery/read/step limits remain unchanged.
+
+## 3.0.0-beta.123 - 2026-08-25
+
+- Close a pre-commit resource-admission bypass found while independently reviewing the beta.122 diff. An absolute executable or exact runtime `node --version` invocation is no longer eligible for the generic light profile when its child environment contains Node startup injection/profiling/cache overrides, TLS/key-log overrides, `LD_PRELOAD`/`LD_AUDIT`/library-path overrides, or the corresponding Darwin dynamic-loader variables. This reuses the existing hardened release-control environment denylist rather than introducing a second security vocabulary. A caller that already has execution authority still retains that authority; the fix prevents injected work from being mis-accounted as a zero-resource probe.
+- Add regressions proving `NODE_OPTIONS=--require=...` keeps the exact runtime version command adaptive and `LD_PRELOAD` keeps a nominally trusted absolute executable adaptive. Clean exact runtime `--version`/`-v` remains light, while arbitrary Node eval/scripts and lookalike executable paths remain adaptive as introduced in beta.122.
+- Beta.122 was fully verified, locally activated, canaried, and accepted but had not been committed or pushed when this environment-injection gap was found. Its acceptance is therefore invalidated rather than promoted; beta.123 must earn fresh frozen verification and release evidence. Long-task execution limits, the thirty-minute resource-admission ceiling, the six-hour managed-job step ceiling, and hosted schema generation **9** remain unchanged.
+
+## 3.0.0-beta.122 - 2026-08-25
+
+- Remove host-resource-pressure nondeterminism from managed-job dependency integration coverage after beta.121 Windows CI spent the full eight-minute fixture wait on the first upstream job. The previous teardown `ENOTEMPTY` failure is gone, confirming beta.121 fixed that Windows filesystem race; the new failure was a separate fixture-design problem. Dependency success/failure and dependency-wait runner recovery now use persisted pending/terminal dependency fixtures plus real independent downstream runners, so those tests exercise dependency orchestration rather than accidentally waiting on the production thirty-minute resource-admission policy. Same-daemon dependency-wait runner relaunch remains covered, while exact active-child ownership/termination remains covered by its dedicated safety test.
+- Fix managed-job timeout diagnostics to inspect the manager's actual job root instead of the suite's unrelated default root. A future fixture timeout therefore retains bounded `status.json` and runner-log evidence instead of misleadingly reporting an empty diagnostic object.
+- Treat only the exact current Node runtime invoked solely with `--version` or `-v` as a light resource probe. Arbitrary Node eval/scripts and lookalike `node` paths remain adaptive/heavy, so this gives cross-platform dependency fixtures a deterministic no-side-effect child without creating a general resource-admission bypass.
+- Advance package/runtime identity to **3.0.0-beta.122**. Hosted tool schema generation remains **9**: long-task limits, the thirty-minute managed-job resource-admission ceiling, six-hour step ceiling, hosted read pacing, and MCP tool schemas are unchanged.
+
+## 3.0.0-beta.121 - 2026-08-25
+
+- Harden the managed-jobs integration-test teardown on Windows after PR CI exposed a terminal-runner filesystem race: the test had already observed terminal job state, but a runner could still be completing its final filesystem close while the suite recursively removed the temporary root, causing Windows `fs.rm` to fail with `ENOTEMPTY`. Keep product terminal semantics unchanged and use Node's documented bounded recursive-remove retry behavior only for the test root cleanup, so the suite waits for the OS deletion race to settle instead of weakening the CI gate or delaying managed-job terminal publication.
+- Advance package/runtime identity to **3.0.0-beta.121**. Hosted tool schema generation remains **9** because this patch changes only test teardown behavior and no MCP input/output contract or hosted description.
+
+## 3.0.0-beta.120 - 2026-08-24
+
+- Reopen the long-task interruption investigation after beta.119 still ended with a severe user-visible host interruption despite a healthy local daemon and successful Worker calls. The persisted content-free security audit makes the amplification measurable: in the 15 minutes ending at 2026-08-24T13:58:58Z, Machine Bridge recorded 152 daemon-reached relay tool calls with a 17-calls/minute peak, including 62 `read_job` calls and 54 one-step process-helper calls. Only three tool calls failed in that window and the Worker did not report execution timeouts. This is a lower-bound observation rather than a total ChatGPT event count because host-only schema discovery, control-plane activity, and final-message delivery never reach the daemon audit. It does not reveal ChatGPT's private turn-termination cause, but it materially strengthens the long-turn plus high host-visible event-density hypothesis over a local execution-timeout explanation.
+- A second severe interruption was reported while these beta.120 changes were still only an uncommitted checkout and the live Worker/login daemon remained beta.119/schema generation 8, so the recurrence does not constitute live evidence against the beta.120 mitigations. The immediate post-incident inventory was saturated at 512/512 retained managed-job states and its 50-record window was dominated by recent one-step helper churn; one older job remained pre-spawn in `resource_admission` for more than nine minutes. The daemon was still callable, resource pressure at the diagnostic instant was Green, the event-loop stall counter was zero, and no relay outage was active. Capacity saturation and the long waiter are therefore retained as amplifiers/diagnostic signals rather than asserted as the hidden ChatGPT termination trigger. Generic remote filesystem access to control-plane state is intentionally denied, so beta.120 obtains the audit/waiter evidence from the running runtime itself instead of guessing a profile path and risking a false-negative empty snapshot.
+- Remove the most common helper-event doubling without shortening work. Remote `exec_command`, `run_process`, and `run_local_command` still commit a durable one-step managed job first, but the original hosted tool call now keeps a two-second initial settlement window. Helpers that finish inside it return their terminal managed-job result in the same tool response with `follow_up_read_required=false`; helpers still active retain the same `job_id`/idempotent recovery envelope and continue through ordinary `read_job`. Child execution remains independently bounded up to 600 seconds, resource admission may still wait up to 30 minutes, and multi-step managed-job steps retain the six-hour ceiling.
+- Make interruption recovery inventory resilient to helper churn. The 50-record `list_jobs` response now prioritizes unreadable, active, and staged state ahead of terminal history, so an older long-running or pre-spawn-waiting job cannot disappear merely because more than 50 short helpers completed afterward. Owner/local inventory also exposes bounded 1/5/15/60-minute creation counts, transient-helper counts, terminal/failure counts, and peak creation rate without exposing internal retention labels per job.
+- Turn existing privacy-safe evidence into actionable interruption diagnostics. The 4096-event hash-chained security audit now publishes owner/local recent activity aggregates (call counts, process-helper/read/start-job counts, failure counts, peak calls/minute, and bounded top-tool frequencies) while still storing no tool arguments or results. Resource-admission snapshots now include up to four owner/local waiter summaries with age, resource class/family, bounded CPU/IO/memory request, protection state, and the current admission reason; waiter IDs, tokens, process identities, contention keys, paths, and command content remain hidden. `diagnose_runtime` also includes managed-job churn so one call can distinguish high host-visible event density from a task that is silently waiting pre-spawn.
+- The incident review found one real local stall amplifier: an interactive unbounded `pytest` request remained in resource admission for roughly eighteen minutes because `cpu_pressure_window` rejected its effective seven-core reservation while host CPU was already busy; generic machine pressure could still look green/yellow at another instant. This is a pre-spawn scheduling wait, not a job execution timeout and not a reason to shorten the overall task. The new waiter diagnostics make that distinction explicit.
+- Separate a later local suspension episode from the earlier user-visible host interruption instead of folding both into one vague "event-loop stall" diagnosis. macOS power history shows an idle-sleep assertion process disappearing at 00:32:43 +0800, the machine entering Idle Sleep five seconds later, and a subsequent 954-second sleep ending at 01:04:11; the runtime recorded a 947.954-second event-loop pause ending at 01:04:10.810. That near-exact duration/end-time match proves this particular pause was operating-system suspension rather than synchronous JavaScript blockage. It occurred more than two hours after the severe interruption whose immediate snapshot had zero event-loop stalls and no active relay outage, so it is a separate continuity risk rather than a retroactive explanation for that host failure. Beta.120 now projects a bounded owner-only macOS sleep history, correlates a recorded runtime stall with same-duration sleep evidence, and records idle-sleep-guard activity/grace/release timestamps plus coarse release reason. The existing thirty-minute post-activity grace is intentionally not lengthened merely to mask an unobservable host lifecycle failure.
+- Advance package/runtime identity to **3.0.0-beta.120** and the hosted tool contract to **schema generation 9** because hosted descriptions and process-result semantics changed. The npm-only authorization model from beta.118 remains unchanged: activation, Worker/daemon replacement, tags, GitHub push/release, and supported Action-control refresh may proceed automatically; npm publication still requires explicit owner authorization.
+
+## 3.0.0-beta.119 - 2026-08-24
+
+- Repair two external-CI defects found after beta.118 local acceptance. CodeQL correctly rejected a managed-job recovery test that interpolated a filesystem path into `node -e` source; the test now keeps executable source static and passes paths as ordinary argv values instead of constructing code from data.
+- Remove a Windows-sensitive wall-clock assertion from dependency-failure propagation coverage. The test continues to require the actual invariants that prevent the original blind-artifact-wait failure mode: the dependent remains in pre-execution `dependency_wait`, private inputs are not materialized early, upstream failure produces structured `dependency_failed`, the downstream business child never starts, and declared cleanup still runs. Host/runner scheduling speed is no longer mistaken for dependency semantics.
+- Beta.118 remains an exact locally accepted/activated candidate but is not releaseable because its PR failed required CodeQL and Windows platform gates. Beta.119 supersedes it and must earn fresh frozen verification, activation, live canary, acceptance, and required GitHub checks. The npm-only conversational authorization model introduced in beta.118 is unchanged, and hosted tool schema generation remains 8.
+
+## 3.0.0-beta.118 - 2026-08-24
+
+- Make npm package publication the sole conversational authorization boundary in the release workflow. Candidate activation, same-name Worker replacement, login-daemon/service replacement, guarded GitHub push/PR/merge, version tags, GitHub Releases/Prereleases, registry installation/activation, and supported ChatGPT Action control refresh/review may proceed automatically when the current task requires them and the effective policy plus repository integrity gates permit them. This removes unnecessary stop-and-ask handoffs without weakening clean-tree, exact-commit, acceptance, CI, digest, publication-lock, identity, idempotency, or unknown-settlement safeguards.
+- Move the explicit anti-accident confirmation to the operation that still requires owner authorization. `npm run prerelease:publish -- --owner-confirm` and `npm run stable:publish -- --owner-confirm` now fail before publication work when the flag is absent, while GitHub release/backfill no longer require `--owner-confirm` or a TTY ceremony. GitHub publication remains serialized by the common-Git-dir publication lock and continues to stage the exact accepted candidate, reconcile remote state, and verify the uploaded asset digest.
+- Synchronize repository automation, governance, release, upgrade, testing, client, and operations guidance with the new model. Historical audit/changelog entries retain the authorization rules that applied to those older releases; current guidance supersedes them. The hosted tool schema remains generation 8 because this change alters release-operation ownership and packaged guidance rather than MCP tool input/output semantics.
+
+## 3.0.0-beta.117 - 2026-08-24
+
+- Complete a fresh independent review after beta.116 activation instead of treating the previous green suite or release acceptance as proof. The pass rechecked managed-job architecture, dependency state transitions, crash windows, retention, cleanup/resource lifetimes, logging/privacy boundaries, tests, generated contracts, and current documentation while preserving the six-hour single-step ceiling and same-response hosted continuation contract.
+- Delay private registered-resource and temporary-file materialization until a dependent job actually clears `dependency_wait`. A dependency failure therefore does not create long-lived private execution copies while the job is only waiting; declared `finally_steps` still receive their inputs just in time when cleanup must run. Recovery keeps the existing error-attribution rule: a failed main-stage resource reconstruction is not retried and double-counted as an independent cleanup failure.
+- Harden dependency and retention integrity. Dependency polling now recognizes a valid durable terminal `result.json` during the result-first/status-second crash window without mutating upstream state, terminal job projections clear stale dependency-pending counts, public dependency counters/error labels are bounded, and active/staged dependency retention verifies the canonical plan hash before using `depends_on` to authorize destructive pruning. Missing, corrupted, or hash-mismatched protection state fails closed.
+- Close the same-daemon dead-runner gap without adding a polling loop. A daemon now observes exits only for detached runners it actually launched and schedules one reconciliation after the existing crash-settlement grace period; daemon restart still uses the established startup scan. Running business children also gain an owner-only job-scoped `active-child.json` identity claim containing PID/start-time/process-group evidence. Recovery verifies that exact process identity and terminates the old detached process tree before releasing the recovery lock or running `finally_steps`; unverifiable ownership is never signalled or deleted, and exhausted recovery cannot declare a job terminal while a verified old business child remains alive. Real integration coverage kills a running upstream runner without reading that upstream job and proves the same daemon terminates the orphaned child, recovers the upstream as non-success, and propagates `dependency_failed` downstream without user-driven polling.
+- Remove parallel managed-job identity/plan-integrity implementations. Managed-job IDs now come from the canonical directory contract, while hashing/integrity verification is centralized and shared by admission inspection, runner launch, recovery relaunch, and retention. Architecture checks pin those boundaries so a later refactor cannot silently reintroduce divergent security rules.
+- Tighten publication privacy and documentation freshness. The package no longer publishes an external project codename, local task label, or unrelated function names from the incident that motivated beta.116; the local privacy denylist carries the private vocabulary instead. Current client guidance now describes the 512-state durable store with a 50-record `list_jobs` window and generation-8 hosted orchestration semantics instead of carrying forward beta.114/beta.115 limits as current behavior.
+- Reduce host-visible event amplification after a long independent review completed locally but the external chat surface still failed to deliver a normal terminal response. The review had generated dozens of one-step durable helper jobs, and `read_job` could additionally wake on every short `current_step` transition. Generation 8 now treats host-visible event density as a continuity resource: coherent non-interactive command sequences should use a repository umbrella command or a multi-step `start_job`; hosted `read_job` ignores `current_step`-only wakeups and coalesces other nonterminal progress for at least 30 seconds by default while terminal settlement still returns on the next bounded poll. The 40-second default long-poll, five-minute opt-in maximum, same-response follow-up, and six-hour managed-step ceiling remain intact.
+- Advance package/runtime identity to **3.0.0-beta.117** and the hosted tool schema to **generation 8**. These fixes do not shorten autonomous task duration and do not authorize live activation; beta.116 remains the active accepted runtime until a separately owner-authorized beta.117 candidate is activated and verified.
+
+## 3.0.0-beta.116 - 2026-08-24
+
+- Fix a reproduced long-workflow failure mode without shortening autonomous task lifetime. An upstream implementation step failed immediately, while already-submitted downstream jobs kept polling for qualification/artifact files that could never appear and consumed 15–22 minutes each before failing. `start_job`/`stage_job` now accept up to 16 durable `depends_on` job IDs. An accepted dependent job stays pre-execution `queued` with `current_phase=dependency_wait`, does not spawn its main child, wakes hosted `read_job` when dependency progress changes, releases only after all upstream jobs succeed, and terminates with `result.error_class=dependency_failed` when an upstream later fails. Staged or already-failed dependencies are rejected before acceptance. This removes impossible artifact waits rather than imposing a shorter conversation or step lifetime.
+- Preserve dependency waiting across local runner failure. Dependency identity is bound at acceptance to the durable job ID, plan hash, and creation generation. If a dependency-wait runner dies before dependent business execution begins, manager reconciliation relaunches the same pre-execution job rather than converting it into cleanup-only recovery. Integration coverage force-kills the waiting runner, waits through the existing dead-runner observation window, and proves the original downstream job resumes and succeeds without resubmission or user input.
+- Harden the runner-claim publication race exposed by the full local self-test. The parent intentionally upgrades `runner.pid` through atomic provisional/committed generations; a reader that opened the old inode while the path moved to the committed generation could previously receive `MBM_IDENTITY_CHANGED` and misclassify a healthy runner as an invalid claim. Only this publication-coupled reader now retries that exact identity-change condition with the same fixed four-attempt, 1 ms budget used for transient publication races, then re-runs the full no-follow, single-link, path-identity and claim-shape checks. Ordinary and destructive secure-file reads remain fail-closed.
+- Expand managed-job recovery depth from 50 to 512 retained states while keeping `list_jobs` bounded to 50 returned records per response. Internal status inventory can still account for the complete retained set. One-step process carriers remain lower-priority `transient_process` history, and active/staged `depends_on` plans pin referenced upstream terminal records so helper churn or capacity pruning cannot remove recovery evidence that a live workflow still depends on. If dependency protection cannot be read safely, pruning fails closed rather than guessing that no dependency exists. Seven-day terminal and 24-hour staged-plan retention remain unchanged.
+- Keep the existing long-task pacing contract instead of reintroducing a forced handoff. Relay `read_job` still defaults to a 40-second server-side long-poll, same-response follow-up remains supported while calls continue to be accepted, individual managed-job steps may still run for up to 21,600 seconds (six hours), and no new aggregate few-minute task cutoff is introduced. Hosted status now states both `host_turn_deadline_observable=false` and `host_terminal_receipt_observable=false`, and exposes `same_response_followup_supported` rather than pretending Machine Bridge can observe or manufacture the host's final ChatGPT turn.
+- Advance the hosted tool contract to **schema generation 7** and package/runtime identity to **3.0.0-beta.116**. The public `start_job`/`stage_job` schema documents `depends_on`, `read_job` documents `dependency_wait` progress/failure semantics, and `list_jobs` distinguishes its 50-record response window from the 512-state durable store. Candidate activation remains a separately owner-authorized release boundary.
+
 ## 3.0.0-beta.115 - 2026-08-22
 
 - Remove ChatGPT-internal `api_tool` / tool-loader cache inspection from release and upgrade acceptance entirely. Release evidence now stops at the governed Workspace Action control snapshot when that product layer applies, plus live MCP/runtime discovery, subscription behavior where the protocol contract changed, and harmless changed-generation invocation behavior. Historical loader-split observations remain audit history only; release automation must not query, compare, or grade those host-internal cache views.

package/CONTRIBUTING.md

@@ -43,18 +43,18 @@ Repository tests are verification inputs, not npm tarball entries under the curr
 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;
+6. run `npm run release:candidate:activate -- --allow-worker-deploy` through the local control plane after the install-only preflight succeeds; no additional conversational approval is required;
 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;
+10. create the GitHub Prerelease with `npm run prerelease:release` once exact-commit and release-integrity gates pass;
+11. stop only for npm publication authorization; when explicitly authorized, run `npm run prerelease:publish -- --owner-confirm`, then continue automatically with `npm run prerelease:install -- --allow-worker-deploy`;
 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.
+15. activate and observe the exact stable candidate, repeat acceptance and review, then run `npm run release` automatically; `npm run stable:publish -- --owner-confirm` remains the separately authorized npm-publication 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.
+Automated checks do not prove 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. npm package publication is the sole operation that requires a separate current-task conversational authorization; other task-relevant release operations proceed under standing repository authority when their technical gates pass.
 
 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).
 

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, 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.
+The maintainer owns product direction, security policy, repository administration, npm package ownership, Cloudflare deployment decisions, and release credentials. Repository automation has standing authority to perform task-relevant Git/GitHub publication, Worker deployment/replacement, login-daemon/service replacement, installation, and control-plane maintenance when repository integrity gates permit them. Live npm package publication remains the sole operation that requires separate current-task owner authorization.
 
 ## Decision model
 
@@ -34,9 +34,9 @@ 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 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.
+Source release completion requires the exact `main` commit to pass CI, CodeQL, Governance, and OpenSSF Scorecard gates. Once those and the repository's acceptance/digest/lock checks pass, local automation may create and push the version tag and GitHub Release without a separate conversational approval or TTY ceremony. 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.
+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 owner-authorized action, represented by the npm publication command's explicit confirmation flag, and no long-lived npm token may be stored in the repository. This npm publication step is the sole conversational authorization boundary in the release workflow.
 
 ## Inactivity and transfer
 

package/README.md

@@ -170,9 +170,9 @@ 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 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.
+For routine remote health checks, prefer `server_info` with `detail: "summary"`; the empty/default call remains full diagnostics and, for owner/full callers, includes a privacy-bounded durable continuity summary that survives Worker isolate replacement without retaining identities, call IDs, tool arguments, results, endpoints, or close reasons. 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.
 
-`tools/list` is the authenticated account's current discovery catalog. Discovery instructions and tool descriptions carry execution/orchestration semantics, so both `server/discover` and `tools/list` advertise `ttlMs=0`. Current MCP 2026-07-28 remote discovery also advertises `tools.listChanged=true`: a client that opts into `toolsListChanged` through `subscriptions/listen` receives a correlated acknowledgement and level-trigger `notifications/tools/list_changed` event, then re-fetches `tools/list`. The request-scoped subscription remains open until explicit cancellation or the advertised bounded server lease expires; the lease is a fail-safe for HTTP disconnects that the Worker runtime cannot reliably observe and does not replace the initial level-trigger/refetch contract. Initialization-era 2025 compatibility retains `listChanged=false` because that protocol family uses different notification semantics. Every host-visible tool description carries `Tool schema generation N`; `server_info.tool_delivery` exposes the current `tool_schema_generation`, `tool_schema_server_version`, and `tool_list_ttl_ms`, while explicitly reporting that Machine Bridge cannot observe which schema generation an external host has actually cached. A generation change therefore requires the subscription/refetch path or another host-side schema refresh plus post-activation verification. 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` also distinguishes the advertised catalog from the currently effective daemon/account intersection. WebSocket is the preferred daemon transport: it requests a protocol-level Ping after five seconds, gives an actually dispatched Ping its full ten-second Pong deadline, then uses one independent fifteen-second application-confirmation window before a ready WSS may be terminated as a transport black hole. A protocol Pong or explicit application `pong` during that second stage preserves WSS; ordinary tool/control inbound remains receive-side evidence and cannot clear transport suspicion, while local event-loop stalls cancel remote suspicion and use the separate recovery-grace path. The periodic application heartbeat remains twenty-five/seventy-five seconds after end-to-end readiness, and the Worker keeps a wider ninety-second fallback. WSS connect attempts have a thirty-second outer budget. Signed HTTPS is independent of that budget: on first-stage WSS suspicion the same root-certified ephemeral device identity prewarms HTTPS in standby, and a real WSS loss promotes that path to exact-generation takeover while aborting any obsolete standby request. 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, only for IDs absent from both its active-call set and unacknowledged-result ledger, and only while it still has fail-closed proof that missing ownership means the call did not execute locally. If a completed-but-unacknowledged result expires, `diagnose_runtime.runtime.relay_result_recovery.automatic_redelivery_safe` becomes false and missing-ID automatic redelivery is disabled rather than risking duplicate side effects. A safe proven-undelivered call 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 through bounded same-response `read_job` follow-up when the current task needs terminal state. Hosted active `read_job` uses a server-side 40-second long-poll by default and returns earlier on meaningful job progress or terminal state; `wait_ms=0` requests an immediate checkpoint, while clients that have independently demonstrated longer request lifetimes may explicitly request up to five minutes. The default is intentionally below the maximum: live hosted evidence showed that this client carries a 40-second read but terminates the former five-minute default. This keeps long-task waiting inside Machine Bridge without exceeding the demonstrated per-call host lifetime; the 40-second interval also bounds interaction density to at most 150 reads for a synthetic unchanged 100-minute job, but that arithmetic does not prove that one assistant response can survive the aggregate duration or call count. If a real host/tool boundary ends a response, preserve the durable identifier and resume the same operation later rather than resubmitting its side effect. `start_process` remains daemon-lifetime interactive state; hosted `read_process` permits paced same-response follow-up, defaults an omitted relay `wait_ms` to the one-second blocking cap, and paces another would-block read inside the fifteen-second cooldown within that same MCP call until output/exit or the cooldown boundary. Active job/process reads do not force a user-turn handoff. Callers must not infer or preempt a host/tool deadline from elapsed wall-clock time: while calls continue to be accepted and the task still needs the result, bounded same-response follow-up may continue. Handoff is reserved for an actual observed host/tool boundary, required external input or authorization, or an explicit user checkpoint, while busy loops and status-surface substitution remain prohibited. The durable process façade preserves account/tool authority and delegated workspace sandbox rather than expanding privileges.
+`tools/list` is the authenticated account's current discovery catalog. Discovery instructions and tool descriptions carry execution/orchestration semantics, so both `server/discover` and `tools/list` advertise `ttlMs=0`. Current MCP 2026-07-28 remote discovery also advertises `tools.listChanged=true`: a client that opts into `toolsListChanged` through `subscriptions/listen` receives a correlated acknowledgement and level-trigger `notifications/tools/list_changed` event, then re-fetches `tools/list`. The request-scoped subscription remains open until explicit cancellation or the advertised bounded server lease expires; the lease is a fail-safe for HTTP disconnects that the Worker runtime cannot reliably observe and does not replace the initial level-trigger/refetch contract. Initialization-era 2025 compatibility retains `listChanged=false` because that protocol family uses different notification semantics. Every host-visible tool description carries `Tool schema generation N`; `server_info.tool_delivery` exposes the current `tool_schema_generation`, `tool_schema_server_version`, and `tool_list_ttl_ms`, while explicitly reporting that Machine Bridge cannot observe which schema generation an external host has actually cached. A generation change therefore requires the subscription/refetch path or another host-side schema refresh plus post-activation verification. 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` also distinguishes the advertised catalog from the currently effective daemon/account intersection. WebSocket is the preferred daemon transport: it requests a protocol-level Ping after five seconds, gives an actually dispatched Ping its full ten-second Pong deadline, then uses one independent fifteen-second application-confirmation window before a ready WSS may be terminated as a transport black hole. A protocol Pong or explicit application `pong` during that second stage preserves WSS; ordinary tool/control inbound remains receive-side evidence and cannot clear transport suspicion, while local event-loop stalls cancel remote suspicion and use the separate recovery-grace path. The periodic application heartbeat remains twenty-five/seventy-five seconds after end-to-end readiness, and the Worker keeps a wider ninety-second fallback. WSS connect attempts have a thirty-second outer budget. Signed HTTPS is independent of that budget: on first-stage WSS suspicion the same root-certified ephemeral device identity prewarms HTTPS in standby, and a real WSS loss promotes that path to exact-generation takeover while aborting any obsolete standby request. 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. A planned daemon shutdown is a different boundary: before a ready runtime closes its relay it sends `daemon_draining`; the Worker settles calls still owned by that daemon with structured `daemon_planned_drain` recovery and acknowledges the drain. In-flight `read_job` is explicitly read-only recoverable with `recovery.mode=read_same_job` plus the original `job_id`; resume by reading that same job after reconnect. This does not transfer an executing call to a new daemon process, whose random instance identity remains intentionally distinct, and it cannot revive an external assistant turn that has already ended. The daemon sends `resume_calls_ack.missing_ids` only after replacement readiness, only for IDs absent from both its active-call set and unacknowledged-result ledger, and only while it still has fail-closed proof that missing ownership means the call did not execute locally. If a completed-but-unacknowledged result expires, `diagnose_runtime.runtime.relay_result_recovery.automatic_redelivery_safe` becomes false and missing-ID automatic redelivery is disabled rather than risking duplicate side effects. A safe proven-undelivered call 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 through bounded same-response `read_job` follow-up when the current task needs terminal state. Hosted active `read_job` uses a server-side 40-second long-poll by default and returns earlier on meaningful job progress or terminal state; `wait_ms=0` requests an immediate checkpoint, while clients that have independently demonstrated longer request lifetimes may explicitly request up to five minutes. The default is intentionally below the maximum: live hosted evidence showed that this client carries a 40-second read but terminates the former five-minute default. This keeps long-task waiting inside Machine Bridge without exceeding the demonstrated per-call host lifetime; the 40-second interval also bounds interaction density to at most 150 reads for a synthetic unchanged 100-minute job, but that arithmetic does not prove that one assistant response can survive the aggregate duration or call count. If a real host/tool boundary ends a response, preserve the durable identifier and resume the same operation later rather than resubmitting its side effect. `start_process` remains daemon-lifetime interactive state; hosted `read_process` permits paced same-response follow-up, defaults an omitted relay `wait_ms` to the one-second blocking cap, and paces another would-block read inside the fifteen-second cooldown within that same MCP call until output/exit or the cooldown boundary. Active job/process reads do not force a user-turn handoff. Callers must not infer or preempt a host/tool deadline from elapsed wall-clock time: while calls continue to be accepted and the task still needs the result, bounded same-response follow-up may continue. Handoff is reserved for an actual observed host/tool boundary, required external input or authorization, or an explicit user checkpoint, while busy loops and status-surface substitution remain prohibited. 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).
 
@@ -193,7 +193,7 @@ For stateful GUI trajectories, owner/full callers can use the higher-level `comp
 
 ## Durable work and local resources
 
-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. A continuous process that legitimately needs more than 600 seconds must use `start_job`: managed-job main/finally steps default to 600 seconds and may explicitly request up to 21,600 seconds (six hours), with resource admission occurring before that execution timer begins. 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. Remote process sessions are for interactive stdin or incremental output, not a substitute for ordinary durable work: hosted `read_process` reports `status_polling_mode=paced_followup`, caps the actual output/exit blocking wait at one second, and paces a repeated would-block read inside the fifteen-second cooldown within that same MCP call until output/exit or the cooldown boundary instead of returning a rapid running checkpoint. When the current task needs more output or terminal state, the same session may be read again in the same assistant response without busy-looping. Non-interactive work should use durable `run_process`/`read_job`; multi-step, cleanup-sensitive, or daemon-restart-surviving workflows should use managed jobs, which persist ordered argv steps and `finally_steps` under owner-only local state and continue across an MCP disconnect. Durable acceptance does not force a hosted-turn handoff: active relay-origin `read_job` reports `status_polling_mode=bounded_followup` and `host_turn_handoff_recommended=false`. Its hosted default is a 40-second server-side long-poll, so an unchanged long job occupies one bounded live MCP response rather than forcing rapid host-side checkpoints; meaningful status/phase progress or terminal state returns early, `wait_ms=0` is available only when an immediate checkpoint is actually wanted, and an explicitly capable client may request up to five minutes. At the default, a synthetic 100-minute unchanged job has an anti-amplification ceiling of 150 status reads, but that is a density estimate rather than proof of aggregate same-response host lifetime. A known job may be followed through paced same-response `read_job` calls while those calls continue to be accepted and the task still needs the result; after an actual host/tool boundary, later recovery must continue from the same `job_id`. Completed one-step process carriers are lower-priority terminal retention than explicit managed jobs, so removable helper history is reclaimed first under the shared 50-state cap. A valid `job_id` that is no longer retained returns typed `not_found`; that absence is not proof that its underlying side effect never executed. `list_jobs` remains inventory rather than a substitute polling loop, and `server_info`/`diagnose_runtime` remain diagnostic surfaces rather than alternate wait channels. Elapsed minutes are not evidence that an external host deadline is near; return the durable recovery identifier for a later turn only after an actual host/tool boundary is observed, external input or authorization is required, or the user explicitly requested a checkpoint.
+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. A continuous process that legitimately needs more than 600 seconds must use `start_job`: managed-job main/finally steps default to 600 seconds and may explicitly request up to 21,600 seconds (six hours), with resource admission occurring before that execution timer begins. 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 unrelated mutations and validation independently terminal, but batch one coherent non-interactive command sequence into a repository umbrella command or multi-step `start_job` instead of creating one host-visible one-step job per tiny probe. 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. Remote process sessions are for interactive stdin or incremental output, not a substitute for ordinary durable work: hosted `read_process` reports `status_polling_mode=paced_followup`, caps the actual output/exit blocking wait at one second, and paces a repeated would-block read inside the fifteen-second cooldown within that same MCP call until output/exit or the cooldown boundary instead of returning a rapid running checkpoint. When the current task needs more output or terminal state, the same session may be read again in the same assistant response without busy-looping. Non-interactive work should use durable `run_process`/`read_job`; multi-step, cleanup-sensitive, or daemon-restart-surviving workflows should use managed jobs, which persist ordered argv steps and `finally_steps` under owner-only local state and continue across an MCP disconnect. Durable acceptance does not force a hosted-turn handoff: active relay-origin `read_job` reports `status_polling_mode=bounded_followup` and `host_turn_handoff_recommended=false`. Its hosted default is a 40-second server-side long-poll, so an unchanged long job occupies one bounded live MCP response rather than forcing rapid host-side checkpoints. Terminal settlement returns on the next bounded five-second internal poll; nonterminal status/phase/dependency progress is coalesced for at least 30 seconds by default, and `current_step`-only churn does not wake the hosted call. `wait_ms=0` is available only when an immediate checkpoint is actually wanted, and an explicitly capable client may request up to five minutes. At the default, a synthetic 100-minute unchanged job has an anti-amplification ceiling of 150 status reads, while continuously changing nonterminal progress is separately bounded by the 30-second coalescing floor; those are density estimates rather than proof of aggregate same-response host lifetime. A known job may be followed through paced same-response `read_job` calls while those calls continue to be accepted and the task still needs the result; after an actual host/tool boundary, later recovery must continue from the same `job_id`. Completed one-step process carriers are lower-priority terminal retention than explicit managed jobs, so removable helper history is reclaimed first under the 512-state durable cap while `list_jobs` remains a 50-record response window. The bounded inventory orders durable terminal managed-job results ahead of transient helper terminals, and owner/local `capacity` diagnostics expose only coarse `durable_terminal` and `transient_terminal` counts; this improves recovery visibility without pretending that Worker acknowledgement proves an external host rendered the final assistant message. Long cross-job workflows can declare `depends_on`: the dependent job remains pre-execution `queued/dependency_wait` without spawning its main child until all upstream jobs succeed, and an upstream failure settles `dependency_failed` instead of leaving a file-poll loop waiting for an artifact that can never appear. Active/staged dependency plans pin referenced retained results until the dependency-bearing plan is terminal. A valid `job_id` that is no longer retained returns typed `not_found`; that absence is not proof that its underlying side effect never executed. `list_jobs` remains inventory rather than a substitute polling loop, and `server_info`/`diagnose_runtime` remain diagnostic surfaces rather than alternate wait channels. Elapsed minutes are not evidence that an external host deadline is near; return the durable recovery identifier for a later turn only after an actual host/tool boundary is observed, external input or authorization is required, or the user explicitly requested a checkpoint.
 
 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 thirty-minute rolling inactivity grace; each new authorized remote activity cancels a pending release and restarts the full grace after the last concurrent handler settles. 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.
 
@@ -266,23 +266,24 @@ Version 3 and later use a mandatory prerelease and soak path. Package work start
 npm run release:candidate
 # 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:
+# Repository automation then runs the exact persistent activation command without another conversational approval:
 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
+# GitHub source publication proceeds automatically once release-integrity gates pass:
+npm run prerelease:release
+# npm publication is the sole explicit authorization boundary:
+npm run prerelease:publish -- --owner-confirm
+# Registry-verified installation/activation then proceeds automatically:
 npm run prerelease:install -- --allow-worker-deploy
 ```
 
 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.
+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 uses `npm run release` automatically once its gates pass; npm stable publication is the sole separately authorized operation and uses `npm run stable:publish -- --owner-confirm`.
 
 See [docs/RELEASING.md](docs/RELEASING.md).
 

package/browser-extension/manifest.json

@@ -30,6 +30,6 @@
   "action": {
     "default_title": "Machine Bridge Browser"
   },
-  "version_name": "3.0.0-beta.115",
+  "version_name": "3.0.0-beta.141",
   "key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxryYkpZhq8+VAQLHcGS9BAHQcyKX8RHGIpIwvtIVRU/rcOcE0bNdnM0aZJ/h6xWQsGDHlhvjT2+1aJaAn/9k8473BRWajzVXld961CdHYVFVHoce2hHiSJ0xydWrHMMZhAm0mN0UzjEpgZ0tMw209efcZHIvSwuxhteZMRy4kyiVjwFlOf5oXFCxRuCJnPj3AK9CmCf4XgEBuPIJ0TZmjGHOOdBvJmbCNnAWXYEo5/mf7MfCGhV4IJ1hNuhpoNQfOFKMUcw9/v/IpT62XpfXdGYTfGYCmCjC+gntK1spbkr2P4/2+sYMQtLpse71mpSNGXfcf3abU55Vpn+gncSxRQIDAQAB"
 }