For Stakeholders

Why this matters

This is developer-experience/internal-tooling work, not a product feature — its value shows up as reduced engineering toil, not as anything a customer notices. Concretely, it removes two recurring frictions in the PR sandbox workflow:

• Repetition: before this PR, every PR description had to spell out any

non-default sandbox setting from scratch, even settings that "should basically always be on" for the team. Now those live once, in the sandbox GitHub Environment, and every PR inherits them automatically.

• Secret sprawl in PR text: a PR description is plain, permanent, and

visible to anyone with repo access. Shared test credentials previously had to be referenced individually, per PR, via secret:<NAME>. They still can be — but now a team default can supply a commonly-needed secret to every sandbox without a PR author needing to know it exists.

Risk profile

• No new deploy gating. The sandbox GitHub Environment declared for

this has no protection rules, so it adds no approval step and cannot block or slow a PR deploy today (verified against the workflow's environment: block, .github/workflows/sandbox.yml:96). This is a point-in-time fact, not a guarantee: if anyone later attaches a protection rule to that specific environment, every PR sandbox would start blocking on it. Worth a standing note for whoever administers repo environments.

• No CLI / runtime contract change. The workflow still emits the same

JSON shape the sandbox CLI already consumes (env, whatsapp, two_regions, cron, queue, seed) — this is a pure input-composition change, not a change to what the sandbox tooling itself does with those inputs. Lower blast radius than a CLI change would carry.

• Existing secret guardrails are unchanged, not weakened. The

github_token rejection and the "unresolvable secret fails the deploy" behavior both carry over unchanged from before this PR (see Secrets and safety guardrails). This PR widens where a default value can come from; it does not touch what's permitted to be injected.

• New failure surface, contained to CI. A malformed SANDBOX_ALL_* /

SANDBOX_<branch>_* value can't corrupt anything outside this workflow — worst case is a sandbox deploy that fails or comes up with an unexpected toggle, caught in the deploy job's own logs before it reaches a running container.

What to watch

• Whether the sandbox GitHub Environment ever gains protection rules

(changes the "no gating" fact above).

• Adoption: whether engineers actually move recurring PR-body settings into

the shared environment, which is where the toil reduction comes from — the mechanism only pays off if it's used.