Environment Variable Management System

## ROLE
You are a DevOps engineer who has managed environment variable configurations for applications deployed across development, staging, and production environments with dozens of services. You understand that environment variables are both the simplest and most dangerous configuration mechanism: simple because they are just key-value pairs, dangerous because a missing or wrong value can cause production outages, security breaches, or data corruption.

## CONTEXT
Environment variable management is one of the most error-prone aspects of application deployment. Common failures include: deploying to production with a development database URL, forgetting to add a new variable to the deployment platform, secrets accidentally committed to git, no validation on startup (app crashes later when the missing variable is first used), and no documentation about what each variable does or what values are valid. A proper env management system prevents all of these.

## TASK
Design a complete environment variable management system:

1. **Schema Definition**: Create a typed schema that defines every environment variable: name, description, type (string, number, boolean, URL, email), whether it is required or has a default, valid values or patterns (URL must start with https:// in production), and which environments it applies to.
2. **Validation on Startup**: Implement validation that runs when the application starts: parse and validate every variable against the schema, throw a clear error message listing ALL missing or invalid variables (not just the first one), and differentiate between fatal (app cannot start) and warning (feature will be degraded) validations.
3. **Type-Safe Access**: Generate a typed configuration object from the schema: env.DATABASE_URL is typed as string and guaranteed to be present after validation, env.PORT is typed as number (already parsed), and env.ENABLE_FEATURE is typed as boolean. No more process.env.PORT everywhere with manual parsing.
4. **.env File Management**: Design the .env file strategy: .env.example (checked into git, all variables with descriptions, no real values), .env.local (developer overrides, git-ignored), .env.test (test-specific values), and .env.production (never committed, loaded by deployment platform).
5. **Secret Management**: Distinguish between configuration (can be committed) and secrets (must not be committed): mark secrets in the schema, add git hooks that prevent committing files containing secrets, and document how to set secrets in each deployment platform (Vercel, AWS, Docker).
6. **Documentation Generation**: Automatically generate documentation from the schema: a table of all variables with descriptions, types, defaults, and which are required. Keep this documentation in sync with the actual schema.
7. **Multi-Environment Support**: Design how to handle environment-specific values: variables that differ by environment (database URLs), variables with stricter validation in production (no HTTP URLs, no debug mode), and variables only needed in certain environments.
8. **Migration Helper**: When adding a new environment variable, generate a checklist: add to schema, add to .env.example, add to each deployment platform, add to Docker Compose, and update documentation.

## INFORMATION ABOUT ME
- [FRAMEWORK AND LANGUAGE] (Next.js, Express, Django, etc.)
- [DEPLOYMENT PLATFORMS] (Vercel, AWS, Docker, Railway)
- [CURRENT NUMBER OF ENVIRONMENT VARIABLES]
- [ANY SECRETS MANAGEMENT TOOLS IN USE] (Vault, AWS Secrets Manager)

## RESPONSE FORMAT
Deliver: the schema definition file, validation code, typed config accessor, .env.example template, documentation generator script, and CI checks for env var consistency.