Problem

There is no good place to set deployment-config fields on ProjectConfiguration (e.g. from_email). The two available options both have sharp edges:

1. .copier-answers.yml — ProjectConfiguration is loaded from there (paths.config_vars → .copier-answers.yml). But fields like from_email are not copier template questions, so every copier update reconciles the answers file down to known questions and silently strips them. This breaks transactional email on each scaffolding bump (the from-address falls back to the no-reply@example.com default). We hit this on a v10.21→v10.22 bump.

2. .env — doesn't work for ProjectConfiguration. Unlike CoreConfiguration (and the other settings classes) which set env_file=_ENV_FILES, ProjectConfiguration's model_config is SettingsConfigDict(case_sensitive=False, extra="ignore") with no env_file. pydantic-settings' env_file loading is private per-class and does not populate os.environ, so ProjectConfiguration only sees FROM_EMAIL if it happens to be a real process env var (e.g. injected by docker compose env_file:). That works in a containerized prod but not under host dev (vibetuner run dev), so the from-address silently differs between environments.

Impact

Deploy-time config (from-address, fqdn-adjacent settings, etc.) has nowhere stable to live. Projects that want to keep the copier questionnaire minimal are pushed to add questions they don't want, or to rely on the fragile copier-answers keys that get stripped.

Proposed fix

Give ProjectConfiguration the same .env support the other settings classes already have:

model_config = SettingsConfigDict(
    env_file=_ENV_FILES,           # same source CoreConfiguration uses
    case_sensitive=False,
    extra="ignore",
)

Then deploy-config fields like from_email can be set via .env consistently in dev and prod, without being copier questions and without being stripped on update. (Precedence: keep explicit copier-answers values winning if present, for back-compat.)

Filed by Claude Code.