# Phase 3 — Credentials (.env)

Goal: `.env` defines the URL + key for the env-var *names* chosen in Phase 2.

The project fixes **no** env-var names. Whatever `backend_url_env` /
`backend_key_env` you wrote in the model YAML are exactly the two lines `.env`
must define. Read `.env.example` for the pattern (it's a documented template,
not a required-var list).

## Steps

1. For each of `backend_url_env` and `backend_key_env`, add a matching line to
   `.env`:

   ```
   MY_PROVIDER_BASE_URL=https://backend.example.com/v1
   MY_PROVIDER_API_KEY=sk-...
   ```

2. Offer the user both ways and let them choose:
   - they paste the value and you write it in, or
   - you write the var name with a placeholder and they fill it themselves.

## Base-URL gotcha

Some backends mount chat completions under a sub-path. The base URL must include
that sub-path, e.g. `https://backend.example.com/openapi` — not just the host.
When a run later 404s on the model call, a truncated base URL is the first
suspect.

## Guardrails (hard rules)

- Secrets live **only** in `.env`. Never write a real key or URL into any YAML.
- Never `git add .env` or otherwise commit it. Do not echo secret values back in
  responses.
- Before moving to dry-run, verify every env-var name the model references
  actually exists in `.env` — a missing name surfaces as an auth/connection
  failure much later and is annoying to trace.