Separate runtime environment validation from compiler config loading

[cssbruno]

Summary

Loading gowdk.config.go currently calls:

config.Env.Validate(os.LookupEnv)

As a result, project-aware compiler and inspection commands can fail unless runtime/deployment secrets and variables are present in the CLI process environment.

The generated application also validates the same runtime contract at startup, which is the appropriate place for deployment-value validation.

Why this is a problem

Commands that inspect or compile source should not normally require access to production-style secrets such as database URLs, session keys, or CSRF signing keys.

The current coupling:

• makes static checks and route/manifest inspection environment-dependent;
• encourages CI jobs that only compile or inspect code to receive unnecessary secrets;
• reduces build reproducibility;
• conflates schema validation with value validation;
• makes EnvConfig act as both compiler input and deployment readiness gate.

This affects commands that load project config, including check, manifest, sitemap, routes, endpoints, inspect, build, and development flows.

Proposed direction

Split validation into explicit phases:

1. Structural validation during config loading: valid names, duplicates, secret classification, non-negative MinBytes, and other schema rules.
2. Build-input validation only for variables explicitly consumed by build-time functions.
3. Runtime value validation when a generated app starts.
4. Explicit deployment validation through a dedicated command or flag, for example gowdk env check --profile production.

A validation mode or separate APIs would make the boundary visible instead of passing os.LookupEnv unconditionally.

Acceptance criteria

• Static commands such as check, manifest, routes, endpoints, and inspect do not require runtime secret values.
• Ordinary source compilation does not require runtime-only values.
• Structural errors in EnvConfig are still reported during config loading.
• Generated applications still fail before serving requests when required runtime values are absent or too short.
• There is an explicit way to validate deployment readiness against process and/or env-file values.
• Build-time code that genuinely consumes an environment value can declare and validate that dependency separately.
• Tests prove that a config with required runtime secrets can be inspected and compiled without exposing those secrets, while generated-app startup and the explicit env-check path still reject missing values.
• Documentation distinguishes build-time variables, runtime variables, and secrets.