Consolidate sandbox operations and diagnostic guidance in Core Web

CONTRIBUTING.md

@@ -68,6 +68,12 @@ described in `apps/web/DESIGN.md`. Keep explanations behind help tips, but keep
 errors, warnings and safety notices visible. Browser-derived metrics state their
 coverage, keep missing values missing, bound their fan-out and time, report a failed
 read as failed and never imply deployment-wide or billing totals.
+Sandbox deployment setup, configuration, reset and progress belong to the System
+secondary page (`#system?id=sandbox`). Nodes owns node management; Overview and
+metrics pages link to these owners instead of repeating their controls or details.
+Keep uncommon resource edits and rollout details in dialogs, and avoid repeating
+the same information within or across pages. Core responses remain the source of
+truth for deployment and connection state.
 
 For subsequent alignment and milestone closure batches, the main thread coordinates
 design, shared interface agreements, file ownership, integration and merge. First

apps/web/DESIGN.md

@@ -736,7 +736,7 @@ while the deployment cannot be read; Show Getting started, a quiet row above the
 sidebar's account controls, opens it again at any time.
 
 ### Sandbox setup
-Setting up hosted sandboxes is a set of pages inside the Nodes page, one decision each: where sandboxes run (own
+Setting up hosted sandboxes is a set of pages inside System’s Sandbox configuration secondary page, one decision each: where sandboxes run (own
 machines or E2B), then the backend or the E2B account, then the size of each sandbox
 (three presets; E2B skips it, since each sandbox takes the template build's size),
 then a review. Choices are large cards that advance on a click; short indigo dashes
@@ -750,25 +750,53 @@ read-only: it is config.json's `public_url`, and the console never asks for it.
 loopback address carries an amber line under it: only the Core machine reaches it.
 When Core rejects the configuration for it (E2B with a loopback `public_url`), a
 red-tinted block under the review keeps Core's message and adds the config file and
-apply command as copyable values. A save attempt clears the E2B key, so the review
-then says to enter it again, with a link to that step.
+apply command as copyable values. A save attempt clears the transient E2B key. Initial setup then asks for it again,
+with a link to that step; an update may leave it blank to keep the committed key.
 Advanced settings, one link away, hold the complete form: resources (not for
 E2B), the Runtime release and the E2B template. A change keeps the saved size
 and Runtime while the backend stays the same (a saved size outside the presets is
 offered as Current). Same-backend editing starts at size or E2B credentials with
-the provider fixed, and is available only with zero held resources;
-changing the backend requires reset and then a new setup. E2B always needs its key
-again. Optional explanations sit behind help tips; errors and safety consequences
-remain visible.
+the provider fixed. It is an online configuration update, including when older
+sandboxes remain: existing node identities and resource ownership are retained.
+Changing the backend or E2B team requires reset and then a new setup. E2B updates
+can omit the key to retain it; every explicitly entered key takes the verified
+replacement path and advances the target generation on success, including the same
+value. Rejections remain inline with a safe
+reason and a deliberate way back to reset; never infer teams from a key, auto-reset
+or auto-resubmit. Optional explanations sit behind help tips; errors and safety
+consequences remain visible.
+
+### Configuration generations
+A single rollout row opens a details dialog for Core's target generation,
+previous-generation sandboxes and rollout counts. Poll rapidly only while Core reports preparing, or
+while the independent reset is active. Settled is preparation state, not proof that
+all nodes are ready or all older Sessions have ended. Retained old resources alone
+must not keep rapid polling alive. Render failed, update-required and unknown target
+states distinctly. Keep offline/live-provider status separate from a node's durable
+serving-generation pin; the pin alone never means the node is online or ready.
+Node detail shows the serving generation and target preparation; allocation detail
+shows the owned configuration generation. Do not calculate rollout completion from
+these rows or promise immediate placement on the target.
+
+A generation-only update within the same installation/backend lifecycle retains
+compatible previous node/allocation evidence while refreshing. Failed or pending
+reads visibly qualify those observations; never replace them with fabricated zeros.
+Reset, backend and installation lifecycle changes still discard incompatible data.
+The shared deployment query and write ownership below continue to govern navigation,
+late reads, explicit retries and login isolation. This final online experience ships
+only with the qualified node-generation protocol; fixture results alone do not
+establish native online-upgrade capability.
 
 ### Sandbox reset
 The deployment section offers explicit reset rather than maintenance/resume. Reuse
-its existing panels and confirmation dialogs. Auto clear is selected first, with a
+its existing panels and confirmation dialogs. Keep the confirmation to one concise
+consequence paragraph, two mode choices, the auto deadline and footer actions.
+Put cleanup sequencing and preservation details in help tips. Auto clear is selected first, with a
 one-hour deadline editable from 5 minutes to 24 hours; Force clear and escalation
 require destructive confirmation. State directly that hosted work is archived,
 remaining active work may be cancelled, archived Sessions cannot resume and
-unpersisted workspace contents may be lost. Histories and persisted Files/Artifacts
-remain, and self-hosted execution is unaffected. Cancelling an active reset stops
+unpersisted workspace contents may be lost. Details about preserved histories, Files/Artifacts and unaffected self-hosted
+execution live behind the reset impact help tip. Cancelling an active reset stops
 further clearing but cannot undo completed archives.
 
 A persistent progress panel uses Core's busy, idle and cleanup counts, deadline and
@@ -777,19 +805,24 @@ never offer a browser-side force-release shortcut. Poll the deployment every fiv
 seconds only while its reset is non-null. A passed deadline does not establish force
 or completion; only a Core response does. Completion opens the existing setup flow,
 with a new explicit save using the generation read from Core, including zero on a
-fresh install. No automatic configuration replay or online-rollout progress exists.
+fresh install. Reset and online configuration rollout have independent authoritative
+progress; neither automatically replays configuration.
 
 Read deployment progress independently of node details. Partial failures retain
 successful facts with a visible stale/unavailable notice. An uncertain write opens
 the existing recovery dialog and requires a new authoritative read before another
 mutation; refresh reads state and never resubmits the write. The connection's
 QueryClient owns both the authoritative deployment and pending or uncertain writes
-across route transitions. Leaving Nodes cannot cancel or forget a submitted reset,
+across route transitions. Leaving Sandbox configuration cannot cancel or forget a submitted reset,
 and a cached node snapshot cannot replace a newer reset or completion learned on
-Overview or System. Returning to Nodes reads the shared deployment immediately and
+Overview. Returning to Nodes or Sandbox configuration reads the shared deployment immediately and
 refreshes node evidence separately. Only a successful authoritative read begun after
 the write settles can release the mutation block; an earlier or still-pending read
-cannot. Logout clears this connection-scoped state.
+cannot. Submitting consumes the reset confirmation even if its outcome is uncertain;
+recovery uses the separate read-and-review dialog. Observation retries preserve
+applicable non-secret configuration drafts. A changed installation, owner epoch,
+backend, mode or generation discards the prior draft and confirmation. Logout clears
+this connection-scoped state.
 
 ### System page
 Four sections, each saying where it changes. Installation: the public address, API
@@ -801,13 +834,35 @@ a help tip), then the provider's protocol, base URL, whether a key is configured
 token limits when set and the update time, or Not set. Set and Replace open one form
 dialog; the key field is a required password input, never prefilled or shown and
 forgotten when the form closes. Core's rejection stays in red inside the form; Clear
-is a ConfirmDialog. Sandboxes: the shared sandbox configuration, with a "Change on
-the Nodes page" text action in the section header. Startup settings: a line naming
+is a ConfirmDialog. Usage details opens Core’s observations in a separate dialog.
+Sandboxes: one navigation row to the Sandbox configuration secondary page; do not
+repeat its configuration facts on System. Startup settings: a line naming
 the config file and the apply command as copyable chips, with when they were last
 applied, over a table of each setting, its value and the services a change restarts.
 Sensitive settings show only Configured or Not set; Default and Fixed after install
 are neutral pills beside the value.
 
+### One place for each task
+A configuration or operation has one home. Other pages link to it instead of
+repeating the same panel. System links to the Sandbox configuration secondary
+page; Nodes contains node management. Keep the configuration page flat: the
+resource editor is a dialog, and rollout is one status row with a details
+action. Put low-frequency counts and generation metadata in that dialog.
+Explanatory prose belongs in help tips, not rows of small print. Keep actionable
+errors and unresolved state visible without duplicating the whole workflow.
+
+### Diagnostic observations
+Failure reasons belong beside the failed Session or Turn status. Their first
+read uses a skeleton; an unavailable reason names that state and puts the read
+retry beside its help tip. Technical classifications are
+translated through one catalogue, not shown as raw error codes. Trace Timing
+labels Core receipt times separately from tool-reported duration; explanations
+of batched delivery, clock differences and historical gaps live in help tips.
+
+The self-hosted connection panel names Core's observed state, the bound key and
+last heartbeat. The bound-key action follows the existing rotation confirmation
+and one-time credential flow. Stale observations cannot complete Run on host.
+
 ### Loading and motion
 The console has no spinners and no "Loading…" lines. Reads are cached (TanStack
 Query) and prefetched on navigation hover, so revisits show data at once and