#3087 Docs: dispatch-env-allow and how remote shell steps receive secrets (swamp-club#2760, swamp-club#2791)

Shipped in swamp 20261006.163206.0-sha.959961d6 (swamp-club/swamp#2871). The manual does not describe either change yet.

reference/swamp-serve/serve-flags

Add --dispatch-env-allow / dispatch-env-allow / SWAMP_DISPATCH_ENV_ALLOW to the flag table and to the Supported keys list.

• Comma-separated names on the flag and env var; a YAML list in serve.yaml.
• Only the listed variables ship to workers with each dispatch.
• Matching is case-insensitive, and the denylist still applies: HOME, PATH, SWAMP_*, DENO_*, XDG_*, OTEL_* and the rest never ship.
• Unset (the default) ships serve's whole environment minus the denylist, as before.
• To ship nothing, use dispatch-env-allow: [] in serve.yaml or an empty SWAMP_DISPATCH_ENV_ALLOW. The flag needs a value.
• At startup, serve logs the scope and warns about listed names the denylist always drops.
• Entries that are blank or contain a comma make serve refuse to start.

explanation/remote-execution.md and explanation/worker-fleets.md

The environment a worker step sees. By default, serve's environment is overlaid on the worker's, so serve's credentials reach every step and serve's values win. That includes cloud identity such as AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE. With dispatch-env-allow, only the listed names ship. Anything left off keeps the worker's own value, which is how a worker keeps its own cloud identity, for example its own IRSA role on Kubernetes. Recommend scoping the snapshot and moving secrets to vault.get.

Secret delivery. A command/shell step on a worker now receives vault.get() and sensitive data.latest() values as environment variables, never in its command line. This matches local runs and covers the remote case that the sensitive-data work (swamp-club#2171) left out. Serve and workers must both be on this release or later. With either side older, the values are in the worker's command line as before.

how-to/swamp-serve (optional)

A short how-to on scoping what serve ships to workers. Include a k8s example where serve holds an OP_SERVICE_ACCOUNT_TOKEN and workers have their own role, using dispatch-env-allow: [DEPLOY_ENV, AWS_REGION].

Source of truth: design/enablers/remote-execution.md ("The execution environment", "Secret delivery on the worker") and design/primitives/serve.md in the swamp repo.