ADR-0017 — La config de dai vive en .env.dai, no en el .env del equipo

• Estado: aceptado
• Fecha: 2026-07-18
• Decide: lead / arquitecto de la metodología

Contexto

dai guarda su config y sus secretos (token del tracker, email, plantilla de URL) en variables de entorno, y hasta ahora las escribía en el .env del repo, con la premisa de que ese .env está gitignored (por eso dai init lo agregaba al .gitignore y el loader avisaba "NUNCA commitees tokens").

Esa premisa se rompe en muchas empresas: versionan el .env como política (mismas variables públicas para todo el equipo y el CI). Pasó de verdad en un repo de frontend corporativo: el .env estaba trackeado con VITE_* públicas, y dai init

1. le inyectaba sus claves DAI_* a un archivo compartido del equipo, y
2. le agregaba .env al .gitignore — inútil, porque git no ignora un archivo ya trackeado, y encima confuso (parece que lo protege y no lo hace).

El día que un dev completara DAI_JIRA_TOKEN en ese .env versionado, git lo marcaba para commit: un secreto a un empujón de filtrarse al historial del repo corporativo.

Decisión

dai deja de tocar el .env del equipo. Toda su config vive en archivos propios:

Archivo	Versionado	Quién lo maneja	Contenido
.env	según el equipo	el equipo	dai no lo escribe; solo lo lee (compat)
.env.dai	no (gitignored)	cada dev	config + secretos de dai (token, email)
.env.dai.example	sí	dai / el equipo	plantilla: mismas claves, valores vacíos

• dai init crea .env.dai (real, ignorado) y .env.dai.example (plantilla versionada), de forma aditiva, y nunca modifica .env/.env.example.
• reconcileGitignore ignora .env.dai (su archivo), no .env: el .env del equipo es del equipo, y muchas orgs lo versionan a propósito. .env.dai.example no matchea el patrón exacto .env.dai, así que se versiona sin negación extra.
• El loader (loadDaiEnv) lee .env.dai y .env. Precedencia: entorno (shell/CI) > .env.dai > .env. Se logra cargando .env.dai primero, porque el loader es "primero-gana". Seguir leyendo .env mantiene compatibilidad con repos previos que tienen los DAI_* ahí — no se rompe nada.

Consecuencias

• A favor: dai no ensucia ni pone en riesgo un archivo compartido del equipo. El secreto vive en un archivo que git ignora de verdad (no trackeado). Funciona igual en equipos que versionan el .env y en los que no. Los repos viejos siguen andando (se lee .env).
• En contra: una convención más de archivos (.env.dai, .env.dai.example) que documentar. Un repo que ya tenía DAI_* en un .env gitignored puede migrarlos a .env.dai cuando quiera; no es urgente, porque el loader sigue leyendo .env.
• Vite: el nombre .env.dai solo lo cargaría Vite con vite --mode dai (raro), y las claves de dai no llevan prefijo VITE_, así que nunca van al bundle del cliente.

Alternativas descartadas

• Destrackear el .env (git rm --cached): rompe la convención del equipo y les saca del control de versiones las VITE_* públicas que comparten a propósito.
• Secreto solo por variable de shell: anda hoy (el loader no pisa el entorno), pero obliga a source en cada sesión: fricción para todo el equipo, sin plantilla que guíe.
• Seguir usando .env y forzar el .gitignore: es justo lo que fallaba — inerte sobre un archivo ya trackeado, y peligroso el día que alguien escribe el token.