Retain sandbox generations and apply verified E2B changes online

CONTRIBUTING.md

@@ -758,7 +758,7 @@ inspection enforce the declared CPU/memory and exact image. E2B setup verifies t
 exact ready template build and matching CPU/memory through the pinned SDK before
 saving its encrypted account key, and records the build as read for the safe view;
 an omitted E2B `resources` adopts that build's CPU and memory. Loading a committed selection reconstructs its
-provider from the original credentials and receipts without repeating candidate
+provider from its owned generation, current committed credential and receipts without repeating candidate
 template validation; a template endpoint outage must not block cleanup of existing
 sandboxes. Creation and instance inspection still enforce the saved resources.
 E2B uses direct placement without a node. Node
@@ -767,9 +767,9 @@ OCI manifest digest, microsandbox image reference, Runtime and firmware hashes.
 These identities are distinct and cannot substitute for each other.
 
 Startup claims the stable installation identity and a new owner epoch before
-provider selection. The existing runtime manager loads one immutable generation.
+provider selection. The runtime manager retains generation-aware provider facades.
 Initial setup and replacement prepare and validate candidates before database
-writes. Rejected candidates preserve the active configuration and workers. A clean
+writes. Rejected candidates preserve the active configuration and workers. A node
 replacement uses the existing mutation gate, pauses manager admission, drains old
 calls and loops, then repeats the resource/generation guards in the commit
 transaction. A changed selection, its generation and retirement of old nodes and
@@ -791,10 +791,48 @@ read.
 All sandbox writes require the observed generation, including initial POST at
 zero; reject stale state before provider preparation, reset or no-op checks, and
 repeat it under the committing row lock. Same-provider PUT currently requires no
-reset and zero held resources. A different backend or unspecified old selection
-requires reset. No online rollout is implemented at this stage; omit that projection.
+reset. Node PUT keeps the zero-held-resource guard until the complete multi-generation
+node protocol ships. E2B changes apply online without retiring nodes, tokens or the
+owner epoch. A different backend, E2B team or unspecified old selection requires reset.
 Preserve historical allocation ownership and placement, never migrate a Session.
 
+Persist immutable allocation and placement deployment generations, distinct from
+compute generations. Node allocations copy their placement; E2B binds at reservation.
+Keep superseded specification/build rows without credentials while current, owned by
+an unreleased allocation/placement, or pinned by any nonremoved node. A durable node
+serving pin survives offline state and zero resources. GC uses the deployment lock
+and bounded pages; reset clears pins only after release. Never downgrade facts needed
+for generation routing. Node readiness and no-gap placement remain PR-N work; do not
+relax the node PUT guard or introduce half a protocol.
+
+Use one E2B classifier. Omitted key preserves the current key; identical selection
+with omitted key is a no-op. Explicit key submission, including identical bytes,
+verifies and increments generation. Check the candidate and retained builds, paginated
+team-owned template membership and every settled live receipt under the candidate key.
+Initial E2B selection must also belong to the submitted key's team. Before online
+replacement, verify the current exact template under the committed key, then under
+the candidate key: shared membership is the ownership anchor, including for legacy
+installations with no retained resources. The pinned SDK exposes team-owned template
+listing, not an authenticated team ID; never invent or persist an inferred team ID.
+Public readability cannot anchor ownership. A legacy selection outside the committed
+key's team, or a revoked committed key, requires reset without blaming the candidate
+key. Transport uncertainty remains unconfirmed. Keep the old key valid until the PUT
+returns 200; revoke it only afterward. Missing/unsettled receipts and
+unconfirmed reads reject. Fence credential commits against all provider calls and
+actual helper subprocess completion after cancellation, then reverify. Helper exit
+never settles unknown remote Create. Bounded failure keeps the original key and
+lifecycles. Resolve each allocation's immutable specification and current key in one
+snapshot; no stale-key cache, fallback to current spec, or provider-map unloading.
+Audit the committed change without secret fields.
+
+Project rollout and reset from the same database snapshot. Old retained resources
+alone never imply preparation or high-frequency polling. Rollout state is settled
+unless actual target preparation is active. Offline/unconfirmed nodes are unknown;
+only exact current connection/epoch/generation readiness is ready. A durable pin is
+not connectivity. Fixed diagnostics alone may explain failed preparation. PR-G reports
+no synthetic preparing state; old online v1 nodes can be update_required while their
+valid pin remains available to the eventual PR-N placement contract.
+
 Reset is durable execution state, advanced by the existing manager outside its
 counted work. Serialize start, escalation, cancel, setup, update and finalization
 through the mutation gate. Auto waits only for in-progress/waiting root/subagent

apps/docs/FOLLOW-UP.md

@@ -1,14 +1,15 @@
 # Feature integration follow-up
 
-This candidate documents durable reset and the interim zero-resource same-provider
-update rule at source `f36ac3592bfe9f77a2172680aa52b14c6f525062`.
-The Core error-envelope foundation is included; online generations, later configuration
-validators and diagnostic endpoints are not. Do not replace current procedures with
-planned behavior before those features land.
+This candidate documents durable reset, retained Core generations and verified
+same-team E2B online changes at source `b9b13b186089b317db271ab83b10f86b48168f66`.
+Node changes still require zero held resources until the node protocol is complete.
+The Core error-envelope foundation is included; later configuration validators and
+diagnostic endpoints are not. Do not replace current procedures with planned behavior
+before those features land.
 
 | Feature dependency | Site pages to reconcile | Source and verification work |
 | --- | --- | --- |
-| Online generations and E2B changes (design 50 PR-G) | configure, hosted-providers, troubleshooting, execution-model, API reference/core | Document actual generation/rollout states, the supported change matrix and existing-sandbox behavior. Verify PUT examples against the final contract. |
+| Final Web generation controls (design 50 PR-W) | configure, hosted-providers, troubleshooting, execution-model | Reconcile the actual Web workflow after node online changes are qualified; keep target preparation separate from serving readiness. |
 | Node update protocol (design 50 PR-N) | hosted-providers, troubleshooting, API reference/machine | Explain the implemented update command, old-node handling and ownership preservation. Do not claim an update command now. |
 | Later configuration/error changes (design 40 and remaining installer work) | install, configure, troubleshooting, quickstart | Regenerate current configuration fields and revise diagnostics against merged code; keep secrets out of examples. |
 | Final feature assembly | every Chinese reading note, execution-model diagram, all generated references | Review translations against regenerated English, verify source provenance and links, run contract/route/copy/fact checks, typecheck/build, local browser review and the repository gate. |

apps/docs/content/docs/admin-api.mdx

@@ -99,13 +99,21 @@ may omit `resources` to adopt the validated build's CPU and memory; responses sh
 the build as read at selection time in `e2b.template_build`. Microsandbox responses
 return its idle `suspension` policy; other providers return null.
 
-Same-provider updates currently require zero retained/pending resources and no
-reset. Changing backend requires explicit durable reset before a new POST.
+Same-team E2B updates apply online after verification. Existing sandboxes retain
+their generation and use the committed credential for management; omitting the key
+preserves it, while explicitly submitting even the same key verifies a replacement.
+Node-provider updates still require zero retained/pending resources and no reset.
+Changing backend or E2B team requires explicit durable reset before a new POST.
 Auto archives idle/queued/suspended hosted Sessions, waits for started work and
 file writes, and escalates at its persisted deadline; force requests cancellation
 and verified cleanup. The deployment response supplies the authoritative
 `reset.remaining` partition and offline-node subset; Web must not derive either
-from independently loaded lists. No rollout projection is provided yet.
+from independently loaded lists. The separate `rollout.state` describes target
+preparation; old-generation resource counts alone do not imply active preparation.
+Poll rapidly while reset is active or rollout is preparing. Node `ready_generation`
+is a durable serving pin, not proof of current connectivity. Target unknown, failed
+or update-required state does not by itself invalidate confirmed old-generation
+service; consume Core's connection/provider facts separately.
 
 Administrators may [archive an individual hosted Session](https://github.com/MiniMax-AI/parsar-core/blob/f36ac3592bfe9f77a2172680aa52b14c6f525062/contracts/agents-api/admin-api.md#administrative-session-archive)
 at the current generation without reset. History and persisted Files/Artifacts

apps/docs/content/docs/api-reference/core/sandbox-manager.mdx

@@ -27,13 +27,15 @@ _openapi:
           no-op; differing selections and file-managed deployments reject. This
           does not create compute or execute work.
       - content: >-
-          Requires the current generation, the same backend type, no active
-          reset and verified cleanup of all old resources. A backend type change
-          requires reset. Credentials are write-only. E2B may omit resources to
-          adopt the validated template build's CPU and memory. A core_url member
-          is rejected with 400; the address comes from the installation public
-          URL. Historical records are retained; old node credentials and
-          enrollments are retired. Never automatically retry an uncertain write.
+          Requires the observed generation, the same backend type and no active
+          reset. E2B same-team changes apply online: allocations retain
+          immutable generation and current credentials; omitted api_key
+          preserves it, explicit submission including the same key verifies and
+          advances generation. Other teams require explicit reset. Node
+          providers retain the zero-resource guard and retire old nodes/tokens
+          on change. Core rejects core_url input. Never automatically replay an
+          uncertain write; rollout.state is the authoritative preparation
+          polling signal.
       - content: >-
           Archives hosted Sessions and waits for confirmed provider cleanup,
           preserving history and Files/Artifacts. Auto waits for started or

apps/docs/content/docs/configure.mdx

@@ -161,10 +161,20 @@ E2B takes no `runtime`, and Web sends no resources for it: Core adopts the CPU a
 memory of the ready template build `template-id:build-uuid`, and supplied values must
 match it. Docker has no separate disk quota.
 
-Changing the provider, the size or the Runtime applies to the whole deployment; see the
-**Nodes** page, and note that this flow will change in a coming release. A successful
-change retires the old nodes and enrollment commands; history stays, and existing
-Sessions never move between providers. See the
+Changing backend type or E2B team requires an explicit reset and a new setup.
+Same-team E2B template, resource and key changes apply online through the Core API:
+new allocations use the new generation, while existing sandboxes retain their
+original specification. Omit the key to preserve it; explicitly submitting a key,
+even the same value, verifies the replacement and advances the generation. Keep the
+old key valid until the update succeeds. Initial setup requires a team-owned template;
+a legacy public-template configuration or an already revoked old key requires reset
+when Core cannot verify the committed ownership anchor.
+
+Docker and microsandbox size/Runtime edits still require zero held resources and
+retire the old nodes and enrollment commands. Add those hosts again after cleaning
+up their retired node installations. Node online preparation and the corresponding
+Web controls are separate follow-up work. History stays, and existing Sessions never
+move between providers. See the
 [operator reference](https://github.com/MiniMax-AI/parsar-core/blob/f36ac3592bfe9f77a2172680aa52b14c6f525062/services/agents-api/HOSTED-SANDBOX-MANAGER.md#removal-and-reset)
 and the [deployment contract](https://github.com/MiniMax-AI/parsar-core/blob/f36ac3592bfe9f77a2172680aa52b14c6f525062/contracts/agents-api/sandbox-deployment.md).
 

apps/docs/content/docs/hosted-providers.mdx

@@ -266,13 +266,14 @@ WebSocket doesn't pass the reverse proxy.
 
 ## Change the sandbox backend or size
 
-To change the sandbox backend, the sandbox size or the Runtime, see the **Nodes** page;
-this flow will change in a coming release. A change applies to the whole deployment
-and retires every node. Retired nodes drop out of the list, so there is nothing to
+Changing backend type requires an explicit reset. Docker and microsandbox size or
+Runtime edits currently require zero held resources; node online updates are not
+available yet. These changes retire every node. Retired nodes drop out of the list, so there is nothing to
 remove in Web: on each host, run the [uninstall command](#remove-a-node) (Core no longer
 accepts the node, so it needs no `--force`), then add the host again with a new command.
 The [operator reference](https://github.com/MiniMax-AI/parsar-core/blob/f36ac3592bfe9f77a2172680aa52b14c6f525062/services/agents-api/HOSTED-SANDBOX-MANAGER.md#removal-and-reset)
-describes today's procedure and API.
+describes today's procedure and API. Same-team E2B edits have a separate online
+Core API path and do not involve node installation.
 
 
 ## Remove a node added before the rename

apps/docs/content/guide-sources.json

@@ -5,18 +5,18 @@
     "docs/design-principles.md": "5e1bff3cdcc77cd02ad692f67977cb4e0a5654989982d722bac0e3c79dbf82cb",
     "docs/web/architecture.md": "80bdb8053c06c2b2030b193aae17d5434545f9c72af50e9d3df3ade522fe25ed",
     "docs/getting-started/install.md": "15cfe81d4005a7337ac82bf6c35a8b441e9f9b0f2a2299021ad6c539f3f336a3",
-    "docs/configuration.md": "401bf72003cd2eb03ae217d49591273ea0a5c42d68190d1a7ad2f12169c287ea",
+    "docs/configuration.md": "e911757a03fbce4b803a284c8bb40bdb7000ca2f70e27938706dcdcd74bc7f9a",
     "docs/web/core-connection.md": "46f86520e70bf41079708e2c398655aa9087ad9488c8e661d9a73035d11098c4",
     "docs/getting-started/quickstart.md": "5effeffcfb343f7939910f0c1758e1492d49e7bd66c409b1819cefe67af592d7",
     "docs/api/README.md": "b2b4c7fdf9fbde62d2169014180698a77c671f85c1c68c2e5de0e73bbdf3b13c",
     "contracts/agents-api/execution-tools.md": "e0b61f6c0c236c362186c5f6d0ad69a16dd8a8d9afabe1329a1fe22e5f4a71e9",
     "docs/api/public-agent-api.md": "18829b366bd2e49fe5beb76dc8a709bc1aa8e35d4fbfd2484a0c52b46cf75417",
     "contracts/agents-api/environments.md": "89ffc903ee44d00ee87c16950202a3ca4c8345160780dcdd4ed2a71b25b1c2dc",
-    "docs/getting-started/nodes.md": "a79e0007c1712c457b40b7573423fd1fdb95d52e283567b4c3d732393fac5109",
+    "docs/getting-started/nodes.md": "71c422ba23b274b038a841dfdc960649c29a4409454f49f8916044fa88041458",
     "docs/getting-started/self-hosted.md": "3f1b402cf28bb320ba414eaf36110e9df4d792b81da0456a3c42d469357d8d99",
     "apps/web/public/onboarding/monitor-en.webp": "29dc220cb1250c7016b7c4bf7f30e9510b07c07b814a48c3aa9303b2d76f20b2",
     "docs/web/README.md": "9fce295f6f6ff04acefe338679c1e54723e123dd0027a778202adfa9ab95b6c4",
-    "docs/api/web-management.md": "ce248fbeb1ded0f3fe4c6021c800c268ebaf4bd37eb1292aecc3d919d138a391",
+    "docs/api/web-management.md": "dc79df33dade6139749752c9ce53d4e126354cfabccada3e7826de4dd20fae62",
     "contracts/agents-api/runtime-observability-api.md": "cd46e777fe716a7e76374f4655c96dfbad9d8be1bfca6203ed6118ab87874c2b",
     "docs/getting-started/operations.md": "b930724d4518621bd6bd8457c70e6aac8c041677ad532a2b63894ef0d20ba892",
     "apps/docs/scripts/guides.json": "9d1ba424f8fadd65ffa6175eaa9c7bc4878d3e1437971099812c984e1e593080"
@@ -30,7 +30,7 @@
     "content/docs/execution-model.zh.mdx": "9976a9203c6a83d49c2c753e3a8528a369078e87aeb88850654da948ac8c17e1",
     "content/docs/install.mdx": "cba5c14e55c6f474d810dc8e545fadbb4f35bcad50eeb6ceef0cbd967b3fb1ab",
     "content/docs/install.zh.mdx": "7ed0b726cf721b18e85b89145ef8ebd2f5d382afd0489633a7b63962aa2fc4ed",
-    "content/docs/configure.mdx": "ac8a8788881707287805811474aaabfc0d0f273aa2423b010b167443996d2530",
+    "content/docs/configure.mdx": "ec84259c766872eada11c1b0d9d9e3ec19acd8c867c6048cc0890a32b82d65f0",
     "content/docs/configure.zh.mdx": "a0c3a1df3e9f75e672e1d0a8c68c82c24ac36a8479d10a951de441960d07927f",
     "content/docs/bootstrap-projects-keys.mdx": "fc2da0aa255278281d8a57c664d7d30e5a458add4e58402386e0374f23973da4",
     "content/docs/bootstrap-projects-keys.zh.mdx": "509b4dcea4c865d6834bcaef78baa681180d48274931230f958a39e46011c88f",
@@ -44,14 +44,14 @@
     "content/docs/sessions.zh.mdx": "b1b1a7f8aacd9a902320f9692173ede24036124f85761cf02f23ef3ef2bcc4c1",
     "content/docs/environments-and-files.mdx": "0fce7c8806d532d64eff6319bba7d0a8e44da46f888d224644b3ab5c23428c41",
     "content/docs/environments-and-files.zh.mdx": "ee64577220a798f023b330c65302c14438f25a34a78c4e36144bfdb4304a3ae5",
-    "content/docs/hosted-providers.mdx": "e73657db13cbde92c1291534d910eba76172781a58645916ec7bfa770c42a5cf",
+    "content/docs/hosted-providers.mdx": "02a39c9fd07c7adfc065ca9510136362503c791334d8b084b7b9dc0958eec81b",
     "content/docs/hosted-providers.zh.mdx": "f54d80d6e65596dca6b20262abaa3dcb5af245227ffad146fcaed4bd69454dee",
     "content/docs/self-hosted-execution.mdx": "34877624962b24c22e8371ebd2e2f83bbf5a0d004c74d5d9b5db57f5133b692c",
     "content/docs/self-hosted-execution.zh.mdx": "f11d34ce30d48039376256474bc9509a508a2f6b9906f49b5cf6e396707ae5c0",
     "public/images/source/apps/web/public/onboarding/monitor-en.webp": "29dc220cb1250c7016b7c4bf7f30e9510b07c07b814a48c3aa9303b2d76f20b2",
     "content/docs/console.mdx": "cf0e6a1f9dd690ffe74c5d83111bb18df7eebe287848497c01257692ab3edc6a",
     "content/docs/console.zh.mdx": "72f953ba46dcc95933773ac0c4dffdc0d0a499be9d9a1cb9467db2659f1fa10d",
-    "content/docs/admin-api.mdx": "1f4917510d3335ec1e9fe0dd7527d0e625b4b9257df39c1691d2564261603959",
+    "content/docs/admin-api.mdx": "22331a4aa1c720711861d93db7d207868bf815ccc32b900d07b3d48ef077afd9",
     "content/docs/admin-api.zh.mdx": "07006de30df3080e54c3cd79ed0ea5337dce557aa2f11afea84edb7f92884d38",
     "content/docs/observability.mdx": "c5e2963a4dd7abddc60869a3ecd3b6b32a97c2ba1ae28b88b7453136656c1201",
     "content/docs/observability.zh.mdx": "9574b3412a5754f41ab2d3a16062ac1cad06766be481a8e6bff1b84acbde7e7e",