deadbyte-mcp 0.8.7

package/docs/V071-HOST-PLANE.md

@@ -0,0 +1,113 @@
+# DEADBYTE MCP V0.7.1 — PRIVILEGED HOST PLANE
+
+## Boundary
+
+V0.7.1 does not change the five-tool containment core. Without
+`DEADBYTE_PRIVILEGED_POLICY`, the server registers only:
+
+- `workspace_open`
+- `file_read`
+- `proof_execute`
+- `contained_transform`
+- `evidence_verify`
+
+A valid local `deadbyte.host-policy.v1` enables registration of three additional
+privileged tools:
+
+- `host_file_read`
+- `host_file_write`
+- `host_exec`
+
+Registration alone is not authorization. Every privileged invocation also requires
+a live `deadbyte.host-arm.v1` lease whose `policy_sha256` matches the exact policy
+file and whose expiry is still in the future. The controller creates a 15-minute
+lease with `armhost` and removes it with `disarmhost`.
+
+## host_file_read
+
+The caller supplies a policy `root_id` plus a portable relative path. The runtime:
+
+1. validates the relative path before filesystem resolution;
+2. resolves the configured root to its real path;
+3. rejects lexical escape and symlink escape;
+4. enforces the local read budget;
+5. returns bytes plus SHA-256 and UTF-8 or base64 content.
+
+## host_file_write
+
+The caller supplies:
+
+- `root_id`
+- portable relative `path`
+- UTF-8 or base64 `content`
+- `expected_sha256`, either `absent` or an exact lowercase digest
+
+The runtime rejects stale preconditions, symlink targets, parent escape and writes
+above the local budget. Data is written to a same-directory exclusive temporary
+file, flushed, the precondition is rechecked immediately before commit, then the
+temporary file is renamed over the target. The final file is re-read and its
+SHA-256 must equal the intended bytes.
+
+This is a hash-precondition atomic replacement, not a claim of a kernel-level
+compare-and-swap primitive. An unrelated writer racing between the final hash check
+and rename cannot be excluded by portable Node filesystem APIs.
+
+## host_exec
+
+`host_exec` is intentionally not a raw command-string interface. The caller selects:
+
+- `command_id`
+- policy-approved `root_id`
+- relative `script_path`
+- exact `script_sha256`
+- bounded argument array
+- bounded working directory below the selected root
+- timeout not exceeding the local command policy
+
+The local policy pins the executable path and executable SHA-256, allowed roots,
+script extensions, prefix arguments, timeout and output limit. The executable hash
+and script hash are recomputed immediately before spawn. Node launches with
+`shell:false`, hidden/non-detached process semantics, bounded stdout/stderr and a
+hard timeout. Known control-plane/signing secrets are removed from the child
+environment.
+
+This plane is deliberately privileged host execution. It is not AppContainer
+containment and must not be described as such. Scripts can act with the account's
+host authority while the local arm lease is live.
+
+## Default Windows policy bootstrap
+
+`scripts/init-host-policy.ps1` creates a disarmed policy and pins the installed
+hashes of:
+
+- Windows PowerShell 5.1
+- `cmd.exe`
+- the active `node.exe`
+
+The default allowed roots are the V0.7.1 core, the ChatGPT bridge directory,
+Downloads, and `D:\Projects` only when that directory exists. The policy is ordinary
+local configuration, not a secret. Changing the policy changes its SHA-256 and
+therefore invalidates any existing arm lease.
+
+## Trust rule
+
+Containment core and privileged host plane are separate authorities:
+
+```text
+PUBLIC MCP REQUEST
+        |
+        +--> CORE TOOL ------------------> APPCONTAINER PROOF PATH
+        |
+        +--> HOST TOOL
+               |
+               +--> POLICY PRESENT
+               +--> POLICY HASH VALID
+               +--> LOCAL ARM LIVE
+               +--> ROOT ALLOWED
+               +--> EXECUTABLE HASH PINNED
+               +--> SCRIPT HASH PINNED
+               |
+               +--> HOST AUTHORITY
+```
+
+No arm lease means no host read, no host write and no host execution.

package/docs/V073-TUNNEL-STDIO-COMPAT.md

@@ -0,0 +1,37 @@
+# DEADBYTE MCP V0.7.3 — TUNNEL STDIO STARTUP-PROBE COMPATIBILITY BOUNDARY
+
+## Classification
+
+The five-tool containment core and optional locally armed host plane remain MCP 2026-07-28.
+The server still uses `serveStdio(..., { legacy: 'reject' })`.
+
+A local ingress prefilter is enabled only when
+`controller/tunnel-stdio-probe-compat.enabled` exists or
+`DEADBYTE_TUNNEL_STDIO_PROBE_COMPAT=1` is inherited by the MCP process.
+
+## Surgical compatibility
+
+The prefilter handles exactly the obsolete startup opening used by legacy tunnel runtimes:
+
+- a JSON-RPC `initialize` request is answered locally with a legacy protocol selection and
+  a minimal `tools` capability marker;
+- the matching `notifications/initialized` notification is consumed locally.
+
+Everything else is forwarded unchanged. In particular, the prefilter does **not** modernize
+legacy `tools/list`, `tools/call`, `ping`, logging, cancellation, or any other capability
+traffic. Real ChatGPT capability traffic must satisfy the strict MCP 2026-07-28 SDK boundary
+itself (`server/discover` + per-request modern envelope).
+
+The prefilter registers no MCP tools, spawns no process, writes no file, and cannot widen
+filesystem, AppContainer, Job, or host-policy authority.
+
+## Evidence
+
+V2 runtime identity records:
+
+- `mcp_protocol_version = 2026-07-28` for the strict capability dispatch boundary;
+- `mcp_ingress_adapter = none | tunnel-stdio-probe-compat-v1`;
+- SHA-256 of the MCP server entry, prefilter source, and ingress-mode source.
+
+The independent verifier recomputes those source hashes. The compatibility opening is therefore
+explicit evidence rather than a silent claim that the outer tunnel startup probe spoke the same era.

package/docs/V080-AGENT-RUNTIME.md

@@ -0,0 +1,101 @@
+# V0.8.0 / R22 DURABLE AGENT RUNTIME
+
+## Purpose
+
+R22 adds durable, bounded orchestration without adding a general command runner.
+The agent runtime persists explicit task state and delegates executable effects to
+the already trusted `proof_execute` and fixed `contained_transform` authorities.
+
+## MCP surface
+
+When `DEADBYTE_AGENT_RUNTIME=1`, seven tools are registered:
+
+```text
+agent_task_submit
+agent_task_run
+agent_task_status
+agent_task_events
+agent_task_cancel
+agent_task_approve
+agent_task_verify
+```
+
+Agent mode is optional. With it disabled, no `agent_task_*` tools are registered.
+
+## Durable layout
+
+Each task is rooted at:
+
+```text
+.deadbyte-agent/tasks/<64-hex-task-id>/
+```
+The task directory contains a normalized signed plan, numbered signed events,
+step outputs, a run lock, optional signed cancel request, and final task receipt.
+
+## Plan identity
+
+`workspace_id + submission_id` deterministically derives the task id. Reusing the
+same submission id with the same normalized plan returns the existing task; using
+it with a different plan is rejected.
+
+Plans permit at most 32 ordered steps. Step kinds are:
+
+- `proof_execute`
+- `contained_transform` using the compile-time operation registry
+- `checkpoint`
+
+A step may read a workspace path or a successful earlier step output. Forward or
+unknown step references are rejected during normalization. Retry limit is 0..2.
+
+## Authenticated journal
+
+Events are stored as contiguous six-digit JSON files. Each event binds:
+
+- schema, sequence, task id, UTC creation time
+- previous event SHA-256
+- event type, optional step id, payload
+- canonical event SHA-256
+- Ed25519 attestation
+The reader verifies signature authenticity before identity/hash-chain state is
+trusted. Missing sequence numbers, bad previous hashes, wrong task ids, altered
+bodies, or signatures from another key fail closed.
+
+## Cancellation and checkpoints
+
+A cancel request is an Ed25519-signed `deadbyte.agent-cancel.v1` envelope. `run`
+verifies it before appending `task_cancelled`; unsigned or altered cancel files do
+not drive authenticated cancellation.
+
+A checkpoint transitions to `waiting_approval`. `agent_task_approve` records an
+explicit approve/reject decision under the task lock. Approval completes only the
+checkpoint; it never silently runs the next step.
+
+## Crash recovery
+
+Before retrying an interrupted executable step, R22 checks the expected output and
+signed step receipt. A verified receipt whose operation/output binding matches the
+step is adopted as recovered success. No observable effect permits retry. Orphan
+or invalid evidence pauses the task instead of guessing.
+
+The lock is an availability/concurrency mechanism, not an authenticity root.
+Workspace write access can still destroy availability by deleting or replacing
+local files; authentication prevents such unauthenticated content from becoming
+trusted history.
+
+## Task receipt
+
+After all steps succeed, R22 creates a signed `deadbyte.agent-task-receipt.v1`
+receipt binding the task/plan, pre-completion journal head, runtime/package/protocol
+identity, successful step receipt hashes and request hashes, plus checkpoint
+outcomes. The final `task_completed` event binds that receipt SHA-256.
+
+`agent_task_verify` re-verifies the task receipt and every underlying executable
+step receipt before returning success.
+
+## Release gates
+
+R22's dedicated agent gate covers idempotency, submission collisions, checkpoint
+behavior, cancellation, plan/event/cancel forgery rejection, real process-death
+recovery, chained execution, task-receipt recovery, and receipt tamper rejection.
+The Windows batch gate runs this agent gate before rebuilding and exercising the
+native containment boundary.

package/docs/V080-R23-CODING-AGENT.md

@@ -0,0 +1,50 @@
+# DEADBYTE MCP V0.8.0 / R23 CODING AGENT PLANE
+
+R23 adds a separately authorized coding execution plane above the R22 durable
+machine-truth runtime. The MCP/model remains the planner; DEADBYTE owns bounded
+inspection, mutation, command execution, benchmarking, journaling and evidence.
+
+## Authority
+
+`CodingRuntimeEnabled` controls tool registration. Registration alone grants no
+write/exec authority. `armcoding` creates a policy-SHA-bound `deadbyte.coding-grant.v2`
+standing grant until explicit revoke; `disarmcoding` removes it immediately. No MCP
+tool can create, widen, or renew this grant. The privileged host plane remains independent.
+
+Coding command execution is explicit host-code authority, not AppContainer
+containment. The child executes as the current host user. Policy constrains which
+root contains the script/cwd, which executable hash is allowed, script extension,
+time/output budgets and denied paths, but it does not filesystem-sandbox arbitrary
+code executed by that script.
+
+## Direct coding tools
+
+The 15 coding tools cover session status, bounded tree/read, atomic write, exact
+text replacement, command execution, benchmark execution, action-receipt verify,
+and durable coding task submit/run/status/events/cancel/approve/verify.
+
+Writes require `absent` or exact SHA-256 preconditions, race re-check before rename,
+and post-commit hash verification. Command profiles pin executable SHA-256 and the
+caller must bind the selected script to its current SHA-256. `spawn` uses
+`shell:false`; child environment is an allowlist rather than inherited wholesale.
+
+Benchmarks run bounded warmups and measured iterations and return sample times,
+median, P95, optional baseline regression percent and an explicit `pass|regression`
+verdict. A regression is a signed observation rather than a transport failure.
+
+## Durable coding tasks and recovery
+
+Typed task steps are `write`, `replace`, `command`, `benchmark`, and `checkpoint`.
+Plans, journal events, cancel requests and final task receipts use separate Ed25519
+domains plus canonical SHA-256 event chaining. Retry limits are bounded to 0..2.
+
+A deterministic action receipt ID lets a new runtime generation reconcile an
+interrupted step. A valid signed receipt is adopted. Command/benchmark execution
+with no receipt pauses instead of rerunning an operation whose side effects are
+unknown. For writes/replacements, no-receipt recovery retries only when the target
+still equals the exact expected pre-state; a changed target pauses as an ambiguous
+unreceipted mutation.
+
+Release proof requires the dedicated coding smoke, full Windows target gate,
+public 30-tool strict-schema gate, public edit/command/benchmark task verification,
+and final controller state with host authority disarmed.

package/docs/V080-R24-AUTONOMOUS-PRODUCTION.md

@@ -0,0 +1,74 @@
+# DEADBYTE V0.8.0 / R24 AUTONOMOUS PRODUCTION ENGINE
+
+R24 layers a bounded autonomous goal engine over the R23 coding plane. It does not
+use Git or GitHub as mutation, rollback, or release authority.
+
+## Authority
+
+Autonomous registration requires the coding runtime to be registered. Execution
+requires two independent explicit local standing grants:
+
+- coding grant: policy-bound until explicit operator revoke
+- autonomous grant: policy-bound until explicit operator revoke
+
+The autonomous grant binds the coding-policy SHA-256. Revoking coding authority also
+revokes autonomous authority. No MCP tool can create, widen, or renew either grant.
+
+## Planner contract
+
+The planner may return exactly one strict JSON decision per round. Allowed actions:
+
+- `inspect`
+- `patch`
+- `run_profile`
+- `finish`
+- `pause`
+The model cannot choose an executable, raw shell string, provider URL, lease duration,
+or release criterion. Build/test/benchmark commands are selected only by trusted
+policy profile IDs. Unknown fields and malformed JSON fail closed.
+
+## DEADBYTE Native Diff
+
+Native Diff v1 is content-addressed and signed. Each operation uses exact SHA-256
+preconditions. Before mutation, the runtime records a signed preimage. Apply is
+transactional; partial failure rolls earlier operations back. Rollback refuses to
+overwrite a third-party state whose SHA is neither the proven preimage nor postimage.
+
+Historical diffs are independently verified and replayed into a DEADBYTE Native HEAD.
+The release gate compares current filesystem state to the latest replayed state for
+each changed path, so later diffs may legitimately supersede earlier diffs.
+
+## Autonomous loop
+
+A production goal may inspect source, propose a Native Diff, run mutation profiles,
+consume failure evidence, diagnose, replan, and patch again. Planner requests,
+responses, decisions, profile observations, diffs, cancellation, and release events
+are signed/hash-chained durable state.
+A repeated-decision detector, iteration/mutation/context/diff/command budgets,
+cooperative signed cancellation, process locks, and receipt-based crash adoption bound
+the loop. The active R24 policy intentionally has no wall-clock goal timeout. An
+interrupted profile with no expected signed receipt pauses instead of blindly rerunning.
+
+## Release gate
+
+`finish` is only a planner request. The engine independently requires all
+`required_for_release` profiles to pass at the current mutation epoch, verifies every
+Native Diff and underlying coding receipt, reconstructs Native HEAD, verifies current
+source state, then creates and independently verifies an Ed25519 release receipt.
+
+## Public MCP
+
+R24 adds 12 autonomous tools and raises the maximum catalog to 42. The Bridge accepts
+only exact catalog combinations and rejects autonomous-without-coding. In
+`client_sampling` mode the Bridge converts the core planner sentinel to MCP 2026-07-28
+`input_required` sampling, using authenticated requestState bound to goal/request IDs.
+The public schema does not expose the internal `planner_response` field.
+
+With `openai_compatible` policy the MCP server starts an in-process supervisor that scans
+durable submitted goals and advances them without later client `autonomous_goal_run`
+calls. With `client_sampling`, planning comes from the connected MCP client's model;
+every round is durable so an interrupted client run resumes without losing goal state.
+No Ollama installation and no Git/GitHub authority are required by R24.
+
+For the operator-requested drop-off baseline, Coding and Autonomous standing grants may
+remain enabled until explicit revoke while privileged Host authority remains DISARMED.

package/docs/V081-R25-MANUS-CONTROL-SEMANTICS.md

@@ -0,0 +1,145 @@
+# DEADBYTE V0.8.1 / R25 MANUS CONTROL SEMANTICS
+
+R25 imports control ideas from the local `ai-manus-2.7.0` source archive without
+importing its service stack or execution authority.
+
+## Provenance
+
+Source artifact inspected locally:
+
+- path: `C:\Users\DEADBYTE\Downloads\ai-manus-2.7.0.zip`
+- SHA-256: `eded0d14998bf7b4e48e3139f97599b309a207b9974cb2bea5bee3c7227f9ed4`
+- archive entries: 606
+- unsafe archive path names found before extraction: 0
+
+The archive was extracted only after path traversal checks. Its application code was
+read as source; it was not imported, installed, or executed. The requested deterministic
+`skillguard` scan could not run because no `skillguard` executable exists on the host.
+That is a scan failure, not a safety certification.
+
+## What R25 takes
+
+The useful Manus mechanisms were control semantics rather than infrastructure:
+
+- structured-output validation feeds a bounded repair request back to the planner
+- stale context payloads may be elided while identity/evidence skeletons remain
+- an authoritative plan is visible across rounds and completion blocks more work
+- planning/progress state is coordination state, never release proof
+
+R25 deliberately does not import the Python/FastAPI backend, Vue frontend, MongoDB,
+Redis, Docker topology, Claw service, shell/browser tool suites, or their persistence
+model. DEADBYTE keeps its existing Node runtime, Native Diff, signed journals, coding
+policy, and objective release gate.
+
+## Planner contract repair
+
+Malformed or schema-invalid planner output no longer disappears as an exception-only
+failure. The autonomous journal records `planner_rejected` with:
+
+- exact request ID and planner round
+- mutation epoch
+- backend/model identity
+- SHA-256 of the rejected response
+- bounded validation reason
+- rejection attempt number
+
+The rejected payload itself is not replayed into the prompt. A new request ID is bound
+to the new journal head and its prompt contains only a canonical bounded
+`PREVIOUS_RESPONSE_REJECTED` repair record. Client-sampling mode returns a new typed
+input request. Provider mode retries inside the same autonomous run. Three consecutive
+contract failures in one planner round pause with `planner_contract_repeated_failure`.
+
+## Deterministic context compaction
+
+Planner state is measured as canonical UTF-8 bytes before dispatch. If it exceeds the
+policy budget, R25 compacts in this order:
+
+1. old inspected context payloads; path, SHA-256, source byte count and elision marker remain
+2. old profile stdout/stderr payloads; receipt/outcome metadata and byte counts remain
+3. oversized source tree; first 128 entries remain with explicit truncation metadata
+4. latest context payload, only if still required to satisfy the hard byte ceiling
+5. latest profile stdout/stderr payload, only if still required
+
+If the remaining skeleton still exceeds policy, planning fails closed. Elided source
+must be re-inspected before a patch because the planner is still forbidden to invent a
+file SHA or content.
+
+## Authoritative plan snapshot
+
+A normal planner decision may optionally carry:
+
+```text
+plan = {
+  title,
+  reason?,
+  steps: [{ step_id, title, status, result? }]
+}
+```
+
+No extra planner model call or public MCP tool is added. The snapshot lives inside the
+already signed `planner_decision` journal event and is exposed as `active_plan` in
+derived goal state.
+
+Plan invariants:
+
+- 1..24 steps
+- unique bounded step IDs
+- completed steps form a prefix
+- at most one running or failed step before the pending suffix
+- pending/running steps cannot carry a result
+- once a completed prefix exists, later snapshots cannot remove or rewrite it
+- plan title is immutable after creation
+
+Legacy planners may omit `plan`; existing R24 decision sequences remain valid.
+
+Runtime guards are before work execution:
+
+- complete plan + inspect/patch/run_profile -> `plan_complete_requires_finish`; no work runs
+- incomplete plan + finish -> `plan_incomplete_blocks_finish`; release gate is not entered
+
+The plan is not correctness evidence. A planner may be wrong about progress. Release
+still requires current-epoch policy profiles, verified Native Diff receipts, reconstructed
+Native HEAD, current filesystem agreement, and the Ed25519 release receipt.
+
+## Authority remains unchanged
+
+R25 adds no executable selector, shell string, provider URL, filesystem root, permission,
+lease extension, host-plane arm, or release criterion. Standing coding/autonomous grants
+remain external policy state and can still be revoked independently of planner output.
+
+## Self-host mutation boundary observed on Windows
+
+While the live MCP server had `src/autonomous-runtime.mjs` imported, DEADBYTE Native Diff
+correctly previewed the source edit but Windows rejected the atomic temp-file rename twice
+with `EPERM`. Native Diff rolled back both attempts. ACL was writable; the running MCP PID
+was the process that created the rejected temp file.
+
+For this R25 development pass only, imported source files were changed by a bounded
+emergency self-host procedure: exact preimage SHA-256 check, exact replacement count,
+known-good copy under `recovery\r25-manus-integration`, in-place write, immediate postimage
+SHA-256/readback, then fresh external Node tests. This fallback is not equivalent to a
+signed Native Diff mutation receipt.
+
+The permanent fix is a staged self-update boundary: validate a next image/tree while the
+current server is live, stop the old runtime, atomically switch from a separate bootstrap
+process, verify the new image, and restore the proven previous image on failed startup.
+Do not weaken Native Diff atomicity to make live self-overwrite appear to work.
+
+## Regression gates
+
+Focused behavior is covered by:
+
+- `test/autonomous-adversarial.test.mjs`
+- `test/autonomous-loop.test.mjs`
+
+Broad autonomous compatibility gate:
+
+```text
+npm run mcp:autonomous:smoke
+```
+
+Full repository gate remains:
+
+```text
+npm test
+```

package/docs/V082-R26-RUNTIME-SELF-UPDATE.md

@@ -0,0 +1,86 @@
+# DEADBYTE MCP V0.8.2 / R26 RUNTIME SELF-UPDATE
+
+R26 closes the R25 live-source activation limitation without adding a new MCP capability.
+The updater is an operator-only Windows CLI. It changes only the `src` activation boundary.
+It does not publish, install dependencies, arm the host plane, accept a raw shell command,
+or give the autonomous model a new authority path.
+
+## Observed defect
+
+R25 activation used a separate bootstrap because a live Node runtime could block atomic
+replacement of imported source files. The first bootstrap then exposed a second Windows
+control-plane defect: a synchronous Node caller capturing PowerShell stdout/stderr can wait
+on handles inherited by a long-lived `Start-Process` descendant after the PowerShell parent
+has already printed its final output.
+
+An isolated R26 probe reproduced that defect: captured `spawnSync` timed out after about
+3 seconds while the PowerShell parent had already printed `PARENT_EXITING`. The same probe
+using `stdio:'ignore'` for the lifecycle `start` command returned in about 0.17 seconds while
+the long-lived descendant remained alive. The defect is transport lifetime, not DNS,
+Cloudflare, planner state, or controller ownership logic.
+
+## Boundary
+
+The updater lives at `scripts/runtime-self-update.mjs`, outside the `src` directory it swaps.
+All imports are loaded before mutation. Activation is exactly two same-volume directory
+renames: canonical `src` to a unique known-good backup, then staged `src` to canonical `src`.
+No copy-over fallback exists.
+## Candidate verification before stop
+
+The command requires three exact operator bindings:
+
+- sibling stage directory
+- expected package version
+- expected `MANIFEST.SHA256` SHA-256
+
+Canonical and stage roots must be real sibling directories on the same volume. Both package
+names and versions must match. Manifest bytes must be identical and match the supplied SHA.
+`npm pack --dry-run --json --ignore-scripts` must report the exact manifest path set for both
+trees. Every staged package file must match the manifest. Every canonical non-`src` file must
+also match. Therefore the only permitted pre-activation byte difference is under `src/`.
+
+## Authority transition
+
+Self-update requires the verified runtime to be ONLINE and the privileged host plane to be
+DISARMED. Coding/autonomous standing grants are explicitly revoked before the runtime stops.
+They remain revoked by default. `--restore-standing-grants` is an explicit operator decision
+to restore only the coding/autonomous grants that were active before the switch. Host authority
+is never restored by the updater.
+
+The controller `start` call uses a no-capture process transport. Truth is then read separately
+from controller status, process ledgers, and the downstream core process. Old and new Bridge
+and Cloud generations are compared using PID, instance nonce, creation time, executable path,
+and executable SHA-256. The downstream core must also be a fresh process generation.
+
+## Rollback
+
+If activation or boot verification fails after the swap, the updater attempts a verified stop,
+renames the failed new `src` aside, restores the known-good `src` by rename, restarts the old
+runtime, and restores prior coding/autonomous grants only when the operator explicitly requested
+standing-grant restoration. Failure state remains machine-readable under
+`controller/runtime/self-update/<update-id>/`.
+## Usage
+
+```text
+npm run self-update:runtime -- --stage <sibling-stage> --expected-version <version> --expected-manifest <sha256>
+```
+
+To deliberately restore the pre-update coding/autonomous standing grants:
+
+```text
+npm run self-update:runtime -- --stage <sibling-stage> --expected-version <version> --expected-manifest <sha256> --restore-standing-grants
+```
+
+A successful update emits an Ed25519 receipt using the dedicated
+`DEADBYTE-RUNTIME-SELF-UPDATE-V1` domain. The receipt binds candidate manifest, updater script
+hash, old/new runtime generations, rename boundary, known-good backup, and authority transition.
+A failed post-initialization update writes state and attempts a signed failure receipt with the
+rollback result. Signed evidence is integrity evidence for observed state; it is not proof that
+the trusted host itself was uncompromised.
+
+## Non-goals
+
+R26 is not a full installer or package-root swap. Non-`src` release bytes must already equal the
+candidate manifest before activation. It is not an MCP tool, model action, generic file mover,
+package downloader, updater service, or new framework. R25 remains preserved as its external
+tarball and signed release evidence; R26 development does not rewrite that artifact.

package/docs/V083-R27-IMMUTABLE-RELEASE-SLOTS.md

@@ -0,0 +1,55 @@
+# DEADBYTE MCP V0.8.3 / R27 — Immutable Release Slots
+
+R27 changes activation, not MCP capability semantics. The operator updater is local Windows
+machinery and is not registered as an MCP tool. It accepts only an exact stage path, mutable
+development root, SemVer, release-manifest SHA-256, and optional bootstrap source root.
+
+## Stores
+
+`%USERPROFILE%\.deadbyte-mcp\releases\<release-id>` holds immutable package bytes copied from
+the verified manifest only. A release id binds version plus the first 16 hex characters of the
+full `MANIFEST.SHA256` digest. Existing release ids are adopted only after exact re-verification.
+
+`%USERPROFILE%\.deadbyte-mcp\generations\<generation-id>` holds controller config and generated
+coding, autonomous and optional host policies plus `GENERATION.SHA256`. Generation directories
+are create-once. A changed launch specification or policy input produces a different generation.
+
+Mutable ledgers, grants, logs, evidence and workspaces live outside both stores. The generated
+coding and host `core` roots point at the explicit development root, never at the release slot.
+
+## Activation transaction
+
+1. Verify stage and development roots against the exact expected manifest and version.
+2. Materialize or verify the immutable release slot.
+3. Pin Bridge/Cloud executable bytes and the external Bridge script bytes.
+4. Build and verify the immutable authority/config generation.
+5. Require the current runtime ONLINE and the host plane DISARMED.
+6. Revoke coding/autonomous grants, then stop only identity-verified owned processes.
+7. Move legacy workspace state only by same-volume directory rename when migration is needed.
+8. Install the stable launcher and atomically replace `active-release.json`.
+9. Re-verify release, generation, launcher and pointer bindings before boot.
+10. Prove fresh Bridge, Cloud and downstream core process generations.
+11. Restore prior coding/autonomous standing grants only with `--restore-standing-grants`.
+12. Emit Ed25519-signed update evidence.
+
+The stable launcher verifies its own SHA-256, the release-manifest SHA, every release file hash,
+the generation-manifest SHA, every generation file hash, package name/version and config path
+before invoking the controller. A pointer without these bindings fails closed.
+
+## Rollback and authority
+
+If failure occurs after pointer commit, the updater stops the new runtime through the new pointer,
+restores the prior pointer snapshot, restores launcher files, reverses any workspace migration,
+and restarts the prior verified runtime. Failure state and rollback results remain machine-readable.
+A signed failure receipt is attempted even when activation itself fails.
+
+The updater never arms the host plane. Coding/autonomous authority is revoked before process stop.
+Without the explicit restore flag it remains revoked after a successful switch. With that flag,
+only the previously observed coding/autonomous standing-grant shape is recreated against the new
+policy generation. Autonomous authority may not exist without coding authority.
+
+## Non-goals
+
+R27 is not a package downloader, background update service, generic installer, MCP capability,
+model-controlled deployment surface, Git release mechanism, or permission escalation path. It does
+not import Manus infrastructure. R26 remains preserved as historical lineage and rollback evidence.