docs(agent-workflows): rescope runner self-hosting cleanup to v2

Adopt owner review round 1: defer the capability endpoint, the bootstrap
manifest, and fail-loud mounts; add the hosting-layout workstream, per-page
docs dispositions, and the agenta_cloud migration delta.

Claude-Session: https://claude.ai/code/session_01XhENr63WL9npkKrJGnzDc1

Author: mmabrouk

docs/design/agent-workflows/projects/runner-selfhosting-cleanup/README.md

@@ -1,10 +1,10 @@
 # Runner self-hosting cleanup
 
-Status: DESIGNED, awaiting owner review
+Status: DESIGNED v2 after owner review round 1, awaiting second-round review
 Date: 2026-07-13
 Target branch: `big-agents`
 
-This project makes the agent runner understandable from its deployment configuration alone. It replaces shared and overlapping environment variables with one runner-owned provider contract, removes automatic subscription credential upload, adds explicit bootstrap assets, and makes required mounts fail loudly.
+This project makes the agent runner understandable from its deployment configuration alone. It replaces shared and overlapping environment variables with one runner-owned provider contract, removes automatic subscription credential upload, and documents explicit operator-owned subscription mounts. A capability endpoint, a bootstrap manifest, and fail-loud mount semantics are deferred open issues, not release work.
 
 ## Outcome
 
@@ -23,23 +23,25 @@ The normal deployment uses one runner service. That runner can support both loca
 
 - The runner is a deployment-level service, not one sidecar per harness or sandbox provider.
 - The operator enables sandbox providers explicitly. Unset means local only, not every provider known to the binary.
+- The enabled-provider list is also the deployment security posture: `daytona` only means no user code ever runs inside the runner container. That is the right posture for any multi-tenant or exposed deployment.
+- API and web get provider availability from the same environment value, set once per deployment by the hosting templates. A discovery endpoint is deferred (RSH-7).
 - Daytona configuration belongs under the runner namespace. Code-evaluator Daytona configuration is separate.
 - The runner never discovers an operator's home directory or automatically uploads Pi or Claude OAuth state.
-- Subscription authentication is an explicit local self-hosting setup taught in a tutorial.
-- Bootstrap assets are declarative, typed, and implemented by both local and Daytona adapters. Version 1 does not execute arbitrary hooks.
+- Subscription authentication is an explicit local self-hosting setup: a read-only Compose volume mount taught in a tutorial. There is no bootstrap manifest in version 1 (RSH-4).
+- Runtime customization (extra binaries, certificates, dependencies) happens through operator-built images and the shipped Daytona snapshot scripts, not runner configuration.
 - Remote subscription authentication is unsupported until the relevant provider explicitly approves the integration and Agenta defines a safe product contract.
 - Pi installation is detected and repaired by the runtime. There is no deployment-wide "Pi is installed" boolean.
-- Durable mounts required by a session or workflow artifact fail the run when they cannot be signed or mounted. Sessionless runs remain ephemeral.
+- Mount failure behavior stays best-effort in version 1, with one structured warning when a durable mount degrades. The fail-loud contract is deferred (RSH-11).
 - The runner receives a narrow environment and no static Agenta API key. Per-run caller credentials authorize callbacks and trace export. It does not inherit a shared application environment or database and cryptographic secrets.
 
 ## Reading order
 
 - [Context](./context.md) explains today's architecture and why the current variables are confusing.
 - [Research](./research.md) records repository evidence and the review of PRs #5274, #5285, and #5286.
-- [Interface](./interface.md) defines the target environment, Helm, capability, bootstrap, and failure contracts.
+- [Interface](./interface.md) defines the target environment, Helm, provider-availability, subscription-mount, and failure contracts.
 - [Plan](./plan.md) splits the cleanup into reviewable implementation PRs.
 - [QA](./qa.md) defines the environment, harness, and credential matrix.
-- [Documentation plan](./documentation-plan.md) maps the final public docs through Diátaxis.
+- [Documentation plan](./documentation-plan.md) maps the final public docs through Diátaxis, with per-page dispositions for the existing self-host tree.
 - [Open issues](./open-issues.md) parks work that should not block the cleanup.
 - [Status](./status.md) is the owner review checklist and progress log.
 
@@ -48,20 +50,21 @@ The normal deployment uses one runner service. That runner can support both loca
 - Runner provider selection and configuration.
 - Runner-specific Daytona names and validation.
 - Runner-to-Services routing and authentication.
-- Declarative bootstrap assets for local and Daytona environments.
-- Local subscription setup.
+- Local subscription setup through explicit read-only mounts.
 - Removal of automatic Daytona OAuth upload.
 - Removal of deployment-wide runtime facts and hidden policy switches.
-- Required-mount failure behavior.
-- Compose, Helm, Railway, self-hosting docs, and the local 8280 QA deployment.
-- Capability discovery needed to keep the API and UI honest.
+- A structured warning when a durable mount degrades.
+- Compose, Helm, Railway, self-hosting docs, a `hosting/README.md` layout map, and the local 8280 QA deployment.
+- One shared provider-availability value read by API and runner.
 
 ## Out of scope
 
 - Implementing the Docker or E2B providers.
 - Sharing a personal subscription between users or tenants.
 - Remote subscription support.
-- Arbitrary bootstrap scripts, VPN hooks, or network overlays.
+- A runner capability-discovery endpoint (RSH-7).
+- A declarative bootstrap-asset manifest, scripts, VPN hooks, or network overlays (RSH-4).
+- Fail-loud required-mount semantics (RSH-11).
 - Reworking code-evaluator execution in the same change.
 - Backward-compatible aliases for unpublished pre-production variables.
 - A custom-role migration bridge. Default roles and tests still need the final mount permissions.

docs/design/agent-workflows/projects/runner-selfhosting-cleanup/cloud-impact.md

@@ -0,0 +1,36 @@
+# Cloud impact: what changes in agenta_cloud
+
+Scope: staging and the preview stages in `agenta_cloud`. Agenta keeps its current cloud security posture in this release; broader hardening is [RSH-12](./open-issues.md).
+
+## Current state
+
+The runner already ships in `agenta_cloud`: one `runner` service in `hosting/docker-compose/docker-compose.application.yml` (all stages share this file), built and pushed like the other images, with a `--runner-tag` in the deploy scripts and workflows. Staging is itself a preview-account stage; the only per-stage difference is which `${stage}.env` AWS secret gets pulled. Railway is not involved in `agenta_cloud` at all; the Railway scripts live in the public repo.
+
+Nothing needs to be created or moved. The migration is a rename inside one compose file plus new keys in the per-stage secrets.
+
+## The migration delta
+
+Two places change, in lockstep with the first runner image that reads the new names:
+
+1. **Compose runner env block** (about 10 lines in `docker-compose.application.yml`):
+   - `SANDBOX_AGENT_PROVIDER` becomes `AGENTA_RUNNER_DEFAULT_SANDBOX_PROVIDER` (value `daytona`).
+   - The five `DAYTONA_*` mappings become their `AGENTA_RUNNER_DAYTONA_*` names.
+   - Delete the `AGENTA_AGENT_SANDBOX_PI_INSTALLED` line.
+2. **Per-stage secret (`${stage}.env`)** for staging and each preview stage with agents enabled:
+   - Add `AGENTA_RUNNER_ENABLED_SANDBOX_PROVIDERS=daytona` and `AGENTA_RUNNER_DEFAULT_SANDBOX_PROVIDER=daytona`. The shared env_file already delivers these to both the API and the runner, so the API-side gate needs no compose change.
+   - Add the `AGENTA_RUNNER_DAYTONA_*` keys. Keep the generic `DAYTONA_*` keys: the code evaluator still reads them (`api/oss/src/utils/env.py`). The Daytona key is temporarily present under two names; that is accepted.
+   - Mint one random `AGENTA_RUNNER_TOKEN` per stage when the token PR lands; the shared env_file delivers it to services and runner with no compose change.
+   - Delete `AGENTA_SANDBOX_LOCAL_ALLOWED`, `AGENTA_SESSION_HARNESS_MOUNTS`, and other removed keys if they exist in the secret blobs.
+
+Effort: one small `agenta_cloud` PR, minutes per stage of secret edits, one paired deploy with a smoke test. Roughly half a day for staging plus preview, not weeks.
+
+## Why cloud needs no hardening work for this release
+
+Cloud sets `AGENTA_RUNNER_ENABLED_SANDBOX_PROVIDERS=daytona`. With local disabled, no user code ever executes inside the runner container, so nothing user-controlled can read the runner's process environment, the shared env_file contents, or the Daytona provisioning credential. The enabled-provider list is the posture switch; disabling local is the entire cloud-specific security story for this release.
+
+The impact report's remaining items (a dedicated `${stage}.runner.env` secret, removing the runner's shared env_file, dropping FUSE privileges, runner-first rollout ordering, evaluator namespace migration) describe pre-existing properties of the shared-secret model, not deltas this design imposes. They are deliberately out of scope; revisit them as their own hardening project after the release.
+
+## Operational cautions
+
+- **Lockstep deploy**: the new runner image stops reading the old names. The compose rename, the secret keys, and the runner tag must land in the same deploy, or Daytona config silently drops and, with local disabled, agent runs fail.
+- **Rollback window**: keep the legacy keys in the secret until rolling back to an old runner image is no longer possible; delete them last.

docs/design/agent-workflows/projects/runner-selfhosting-cleanup/context.md

@@ -50,7 +50,7 @@ DAYTONA_JWT_TOKEN and DAYTONA_ORGANIZATION_ID.
 
 Nothing was wrong with the user's Daytona account. The request reached a runner deployment that was not configured for Daytona. The setup made it easy to split capabilities accidentally.
 
-The target local QA deployment is one trusted development runner with both providers enabled and explicit local subscription bootstrap assets. This is a development convenience, not a production multi-tenant topology. A local harness shares the runner container and can inspect other same-user processes through `/proc`.
+The target local QA deployment is one trusted development runner with both providers enabled and explicit read-only local subscription mounts. This is a development convenience, not a production multi-tenant topology. A local harness shares the runner container and can inspect other same-user processes through `/proc`.
 
 ## Trust boundaries
 
@@ -71,7 +71,7 @@ The runner stays in the deployment. The daemon and harness execute in a Daytona
 - the resolved model credential for the run;
 - workspace and instruction files;
 - scoped durable-mount credentials;
-- explicitly configured bootstrap assets;
+- explicitly configured runtime files;
 - runner-owned support binaries and configuration.
 
 The runner's Daytona organization credential provisions the sandbox. It is infrastructure control-plane material and must never enter the sandbox environment.
@@ -80,19 +80,19 @@ The runner's Daytona organization credential provisions the sandbox. It is infra
 
 ### Configuration describes intent
 
-Operators configure facts they own: enabled providers, a default, credentials, lifecycle values, and mounted bootstrap inputs. The runner detects runtime facts such as whether Pi is already installed.
+Operators configure facts they own: enabled providers, a default, credentials, lifecycle values, and mounted subscription inputs. The runner detects runtime facts such as whether Pi is already installed.
 
 ### One owner per value
 
 A Daytona API key used to provision agent sandboxes belongs to the runner. A Daytona key used by code evaluation belongs to the code evaluator. A shared ambient variable is not a simplification when the two consumers have different images, snapshots, permissions, and lifecycles.
 
 ### Explicit data movement
 
-The runner should never infer that a missing model API key means "copy whatever login I happen to have." Runtime authentication is a declared mode, and bootstrap assets are a declared deployment input.
+The runner should never infer that a missing model API key means "copy whatever login I happen to have." Runtime authentication is a declared mode, and subscription state is a declared deployment mount.
 
 ### Fail before side effects
 
-Unknown providers, disabled providers, missing provider credentials, invalid bootstrap paths, and contradictory defaults fail at startup or before sandbox creation. Required mount failures fail the run. There is no silent provider fallback and no silent durable-to-ephemeral downgrade.
+Unknown providers, disabled providers, missing provider credentials, and contradictory defaults fail at startup or before sandbox creation. There is no silent provider fallback. Mount behavior stays best-effort in version 1, with a structured warning on durable-to-ephemeral degradation (the fail-loud contract is RSH-11).
 
 ### Pre-production cleanup