docs-adr-writerlisted

Tu tarea es redactar **un** ADR como borrador, listo para que el humano lo revise antes de commitearlo. No commitees tú. ## Antes de escribir: ¿esta decisión merece un ADR? Sí merece ADR: elección de tecnología, librería o framework; modelo de datos; arquitectura de módulos; estrategia de autenticación/autorización; y cualquier trade-off que un futuro mantenedor podría cuestionar razonablemente. No merece ADR: detalles de implementación de bajo nivel (por qué una función maneja un error de una forma concreta) — eso se documenta en el propio código o en el mensaje de commit. Si la decisión que te han pasado cae en el segundo grupo, dilo y no crees el fichero. ## Redacción 1. **Ruta y numeración**: `docs/ADR/records/ADR-XXXX-titulo-corto.md`, numeración correlativa de 4 dígitos. Mira qué ADR existen ya antes de elegir el número; nunca reutilices uno. 2. **Formato obligatorio** (Nygard), con la plantilla Templater de `docs/Meta/Templates/adr.md`: - Frontmatter: `tipo: adr`, `id: ADR-XXXX`, `estado`, `fecha`, `supersede:`. - Cuerpo: **Título · Contexto · Decisión · Consecuencias**. - `estado`: `Propuesto` mientras se discute, `Aceptado` una vez tomada, `Superseded` cuando otro ADR la reemplaza. 3. **Contexto** describe la fuerza que motiva la decisión, no la decisión. **Consecuencias** dice qué se gana *y qué se sacrifica* — un ADR sin coste declarado está incompleto. 4. **Un ADR = una decisión.** Si te pasan dos, redacta dos ficheros y dilo. 5. **Appen