For Sales

Straight answer: this isn't a customer-facing feature

There is no external pitch here. This PR doesn't change what Dentolize does for a dental clinic, and it shouldn't appear in any customer conversation, demo, or competitive comparison. If a prospect asks "what have you shipped recently," this item doesn't count.

The internal version of "selling" this

The only audience that needs convincing is other engineers on the team, and whoever administers the repo's GitHub Environments. If you're in a position to advocate for adopting it (e.g. you maintain a workflow that touches sandboxes), the pitch is:

• The objection: "We already put settings in the PR body, why do we

need another place?" — Answer: the PR body is still there and still wins every conflict (see The precedence chain). This adds a default, it doesn't remove the override.

• The objection: "Won't this make debugging harder — now there are five

places a setting could come from?" — Answer: the compose step logs every resolved toggle and every env key name (never values) in a single collapsible log group, 🧪 sandbox settings (layered: env vars → secrets → PR inline), so the effective settings are always visible in one place regardless of which layer set them (see Secrets and safety guardrails).

• The objection: "Does this slow down or gate my PR deploy?" —

Answer: no. The sandbox GitHub Environment declared for this has no protection rules attached, so it adds zero approval steps (see The sandbox GitHub Environment).

There's no competitive angle to speak of — this is an internal tooling choice, not something a competitor's product does or doesn't do.