Environment Switcher with Color-Coded Persistent Banner — Production, Staging, Development

Internal tools and admin consoles that operate against multiple environments (production, staging, development) create a real, recurring risk: an engineer or support agent forgetting which environment they're currently pointed at, and running a command or clicking a button that was only meant to be safe in a test environment. This snippet addresses that with two coordinated pieces: a persistent, unmistakably color-coded banner, and *asymmetric* friction on the switch itself — specifically harder to move *into* production than out of it.

Color escalation mirrors actual risk level, not arbitrary branding

The three environments use green (development), amber (staging), and red (production) — deliberately following the same "escalating alarm" convention used in traffic lights and hazard warnings, not a neutral or brand-driven color choice. This isn't just aesthetic: a user's peripheral vision registers a shift toward red far more readily than a shift between two similarly-saturated brand colors would, which matters because the entire point of the banner is to be noticed *before* an action is taken, not just to be technically present somewhere on screen.

Switching into production gets one more step than switching out of it

The click handler on each environment option checks specifically whether the *target* environment is production and the *current* one isn't — only in that specific direction does it insert a native confirm() prompt before proceeding. Switching from production back to staging or development requires no extra confirmation at all. This asymmetry is deliberate: the actual risk in this pattern isn't "switching environments" in the abstract, it's specifically *ending up in production without having meant to* — so the friction is placed exactly where the risk is, rather than uniformly slowing down every switch regardless of direction.

The banner label and the dropdown's own label are always the same source of truth

setEnvironment() updates both bannerLabel.textContent and selectLabel.textContent together, in the same function call, from the same ENV_LABELS lookup — there's no separate state tracked for "what the banner shows" versus "what the dropdown button shows." This guarantees the two can never disagree with each other, which matters specifically because the banner's entire job is to be a *trustworthy* indicator of the current environment; if it could ever show something different from what the dropdown itself reports, its value as a safety mechanism would be undermined.

A standard accessible disclosure pattern for the dropdown itself

The environment picker follows the same conventions as any accessible dropdown: aria-haspopup/aria-expanded on the trigger button, closing on an outside click, and closing on Escape — nothing about the environment-specific logic (the color coding, the confirmation gate) needed to compromise on these baseline accessibility behaviors.