For Stakeholders

Why this matters

The main sandbox is the team's persistent demo and training environment — the one used for internal walkthroughs, and available to point prospects or new hires at without spinning up a throwaway PR preview. It has been running with every optional capability defaulted off (no WhatsApp, no multi-region, no custom config) since it was introduced, because the only configuration channel Dentolize had — a PR description block — doesn't exist for a branch that isn't attached to an open PR. This PR removes that gap by giving main (and any other branch operated via Sandbox Ops) its own team-managed configuration surface: a GitHub Environment named sandbox.

Impact

• No product/customer impact. This is a single CI workflow file (.github/workflows/sandbox-ops.yml, +61/-0 lines). It does not touch packages/server, packages/prisma, or any clinic-facing code. Nothing here is deployed to production or reaches a real clinic.
• Reduces ops friction, not urgency. Before this PR, turning on WhatsApp for main would have required either a workaround (e.g., temporarily wiring a fake PR) or a change to the deploy tooling itself for every one-off need. Now it's a two-step, self-serve (for whoever has repo Environment access) operation: set a variable, run a redeploy.
• New privileged surface, old trust boundary. Anyone with write access to the sandbox GitHub Environment can now inject arbitrary environment variables — and, via secrets, masked values like real API credentials — into the containers backing main's sandbox. That's the same level of trust already extended to anyone who can edit a PR description on this repo (which can do the same for their own PR's sandbox); this PR doesn't expand who can do it, only which branches it can be done to. See Security & guardrails for the specific protections (prefix scoping, no github_token leak path, no secret values in logs).

Risk profile

Low. The blast radius is limited to non-production sandbox infrastructure that already resets on demand (reset-data, destroy). The PR author states the compose logic (prefix scoping, cross-branch isolation, github_token exclusion, secret-over-variable precedence, empty-input fallback) is unit-tested outside this repo, in the sandbox CLI's own test suite — not independently re-verified as part of this documentation pass. See For Quality for what's worth re-checking directly against a live run.

What to watch for

Whether the sandbox GitHub Environment ends up with deployment protection rules (e.g., required reviewers) — the PR description flags that these would gate this job if configured, and that the environment was newly created for this PR so likely has none yet. If protection rules get added later without updating this doc, a redeploy triggered by this mechanism could start requiring manual approval where it previously ran unattended.