# Environment Standards

## Rule of Configuration

- Code must be environment-agnostic. All environment-specific values (API URLs, keys, feature flags) must be injected via `.env` files or secret managers.
- Never hardcode environment-specific values in source code. If a value changes between environments, it belongs in configuration, not in code.
- Validate all required environment variables at application startup. If a required variable is missing, the application must fail fast with a clear error message identifying the missing variable.
- Use a schema or typed configuration loader to enforce the presence and format of environment variables. Avoid scattered `process.env` access throughout the codebase.

## The Production Lock

- Never suggest or execute a command that modifies the production environment (e.g., `db:drop`, `delete-bucket`, `rm -rf`, destructive migrations) unless specifically prompted with a double-confirmation bypass.
- Destructive operations against production must require explicit, unambiguous authorization. A single "yes" is not sufficient for irreversible actions -- require the environment name to be typed out as confirmation.
- CI/CD pipelines must enforce environment gates. Production deployments require manual approval from an authorized reviewer. Automated pipelines must never have unsupervised destructive access to production resources.
- CLI tools and scripts that interact with production must display a clear warning identifying the target environment before executing. Color-coded prompts or environment banners reduce the risk of accidental execution against the wrong environment.

## Data Sanitization

- Production data must never flow down to development or staging environments without sanitization. Raw production data in non-production environments is a compliance violation and a security risk.
- Staging and development environments must use scrubbed or anonymized snapshots of production data to comply with PII and GDPR standards. Replace real names, emails, phone numbers, and addresses with synthetic data. Preserve data shape and volume for realistic testing without exposing real user information.
- Automate the sanitization process. Manual data scrubbing is error-prone and unsustainable. Build a repeatable pipeline that exports, sanitizes, and imports data for non-production environments.
- Audit sanitized datasets before distribution. Verify that no PII survives the sanitization process. Spot-check output for fields that may have been missed (free-text fields, metadata, embedded JSON, log entries).
- Secrets, API keys, and tokens present in production data must be stripped entirely during sanitization, not just masked. A masked token is still a token.

## Feature Parity

- Staging must be a mirror of production. If a library, runtime version, or OS version is updated in staging, it must be updated in the production deployment script simultaneously. Drift between staging and production undermines the value of staging as a validation environment.
- Infrastructure as Code (IaC) must define both staging and production environments from the same templates or modules, differing only in scale and environment-specific configuration. Structural differences between environments must be eliminated.
- When a dependency is added, upgraded, or removed in one environment, the change must propagate to all environments in the same release cycle. Partial upgrades create false confidence -- tests pass in staging but fail in production due to version differences.
- Monitor and alert on environment drift. Periodically compare staging and production configurations (runtime versions, dependency versions, OS patches, infrastructure settings) and flag discrepancies for resolution.
