# dai · configuración del adaptador de PM (copiar a .env.dai y completar).
# El .env.dai NO se versiona (evita filtrar secretos) y el .env del equipo no se toca
# (ADR-0017). Este .example SÍ se versiona. Precedencia: shell/CI > .env.dai > .env.

# ── Backend del tracker ──────────────────────────────────────────────────────
# md | jira | clickup
DAI_PM=md

# OPCIONAL. Plantilla del link al ticket (`dai ls`, `dai pr`, stamp). {id} se reemplaza.
# Con DAI_PM=jira o =clickup, dai ya deduce el link solo: esto es un OVERRIDE, y solo
# hace falta si tu tracker vive en otra URL (p. ej. un Jira Server con path propio).
# Si dai no puede saber el link, avisa y deja la PR sin él — nunca escribe el id pelado.
# DAI_TRACKER_URL_TEMPLATE=https://jira.miempresa.com/browse/{id}

# ── Flujo de branches (dai pr · dai done) ────────────────────────────────────
# Las DOS ramas de vida larga del repo. No se configura "la base" de las PR: la base sale
# del TIPO de branch, y con eso dai deja de adivinar.
#   feature/ · fix/     → PR contra DAI_BRANCH_DEV
#   release/ · hotfix/  → PR contra DAI_BRANCH_PROD, con confirmación explícita
#
# Rama que INTEGRA el desarrollo (la que se despliega a test). Sin declarar, dai usa la
# rama default del remoto (origin/HEAD) y avisa que la está adivinando.
# DAI_BRANCH_DEV=testing

# Rama que DESPLIEGA A PRODUCCIÓN. `dai pr` la marca en el preview y pide confirmación
# antes de publicar; con --yes hace falta --to-prod. Sin declarar, dai no marca ninguna
# rama como producción: no adivina cuál es.
# DAI_BRANCH_PROD=main

# ── Aviso de release a un canal de equipo (opcional) ─────────────────────────
# Tercer adaptador de dai, con la misma forma que DAI_PM: una variable elige el canal y el
# canal trae las suyas. Por default no hay aviso: dai no habla hacia afuera sin pedirlo.
#   discord | slack | webex | telegram | webhook | none
# `webhook` es el genérico: manda los campos del release en JSON a cualquier endpoint
# (Teams, Mattermost, un sistema interno) e incluye además el texto ya armado.
# DAI_NOTIFY=webex

# El endpoint del canal. ⚠️ ES LA CREDENCIAL: quien lo tiene, puede postear. Nunca lo
# commitees; dai muestra el host, nunca la URL. Probalo con `dai release notify --test`.
# DAI_NOTIFY_WEBHOOK=

# Solo para telegram: no tiene webhooks de entrada, así que el endpoint es el bot y hace
# falta decir a qué chat va el mensaje.
# DAI_NOTIFY_CHAT_ID=

# ── Backend md (local, offline) ──────────────────────────────────────────────
# Carpeta donde viven las US como <ID>.md (p. ej. ABC-482.md).
DAI_MD_US_DIR=.dai/us

# ── Backend jira (REST v3 / Jira Cloud) — activar con DAI_PM=jira ────────────
# DAI_JIRA_BASE_URL=https://miempresa.atlassian.net
# DAI_JIRA_EMAIL=usuario@miempresa.com
# DAI_JIRA_TOKEN=          # ← SECRETO. api_token de id.atlassian.com. Nunca commitear.
# DAI_JIRA_PROJECT=        # clave del PROYECTO (ej. PROJ), NO la de un ticket (PROJ-123) — para `dai publish`
# DAI_JIRA_ISSUETYPE=Story # tipo de issue a crear (default Story). Se pisa con `dai publish --issuetype Epic`
# DAI_JIRA_FIELDS_FILE=.dai/jira-fields.json   # campos propios que tu Jira exige al crear
#                          # (ADR-0015). Si el archivo no existe, se ignora. Molde en templates/.
#
# ¿El proxy de tu empresa intercepta TLS? Node no usa el trust store del sistema, así que
# falla donde el navegador anda. Declará la CA — NUNCA NODE_TLS_REJECT_UNAUTHORIZED=0:
# NODE_EXTRA_CA_CERTS=/ruta/ca-empresa.pem

# ── Backend clickup (REST v2) — activar con DAI_PM=clickup ───────────────────
# DAI_CLICKUP_TOKEN=       # ← SECRETO. token personal scopeado.
# DAI_CLICKUP_LIST_ID=     # ID de la lista donde crear tareas — solo para `dai publish`

# ── Forge (dai-review: comentar PR/MR) ───────────────────────────────────────
# Token SCOPEADO del forge para postear comentarios (git usa SSH, no esto).
# GITHUB_TOKEN=            # ← SECRETO. Scope: repo / pull-requests.
# GITLAB_TOKEN=            # ← SECRETO. Scope: api (o solo notes).