Is the VITE_ prefix convention enough to keep secrets out of a Vite client bundle?

Our team ships a Vite-built SPA and stores configuration in .env files per mode (.env.production, .env.staging). I understand Vite only inlines variables prefixed with VITE_ into import.meta.env, and that anything with that prefix ends up readable in the shipped JavaScript. Files in public/ are also copied verbatim to the output root with no access control.

The unresolved decision is process, not syntax: the VITE_ prefix is a naming convention, not a guardrail. A developer can accidentally prefix an API secret, or reuse a variable name across mode files so a value that was safe in one environment leaks in another. Similarly, a sensitive file dropped into public/ persists across builds until manually removed.

Assume a recent Vite major version; I know env inlining behavior has changed across releases and differs between dev, build, and SSR contexts, so answers should note version assumptions.

1. Do teams rely on the prefix convention alone, or is a build-time check (e.g., scanning dist/ for secret patterns in CI) a common complement?

2. Is there a documented way to make a build fail when an unprefixed secret-like variable is referenced from client code?

3. For public/, is manual audit the only option, or is there a supported mechanism to exclude specific files from the copy step?