@damenor/agent-docs 0.1.1 → 0.4.0

package/templates/base/docs/adr/TEMPLATE.md

@@ -1,83 +0,0 @@
----
-created: "2025-01-01"
-status: active
-type: adr-template
-tags: [adr, plantilla, decisiones, arquitectura]
----
-
-# ADR: [Título de la decisión]
-
-**Número**: `[NNNN]` (asignar al crear el archivo, ej. `0002`)
-**Fecha**: `[YYYY-MM-DD]`
-**Estado**: [Propuesto | Aceptado | Deprecado | Reemplazado por ADR-NNNN]
-
----
-
-## Contexto
-
-[1-3 oraciones que describen la situación que motivó la decisión. Qué problema se intenta resolver. Qué restricciones existían.]
-
-## Decisión
-
-[1-3 oraciones describiendo la decisión tomada. Ser específico: qué se eligió y qué se descartó.]
-
-## Por qué
-
-[La justificación. Por qué esta opción y no otra. Qué criterio se usó para elegir (performance, mantenibilidad, costo, tiempo, etc.).]
-
----
-
-## Opciones consideradas *(opcional)*
-
-| Opción | Pros | Contras |
-|--------|------|---------|
-| **[Opción A]** (elegida) | [Beneficios principales] | [Desventajas aceptadas] |
-| **[Opción B]** | [Beneficios] | [Por qué se descartó] |
-| **[Opción C]** | [Beneficios] | [Por qué se descartó] |
-
-## Consecuencias *(opcional)*
-
-**Positivas**:
-- [Beneficio esperado de la decisión.]
-
-**Negativas**:
-- [Trade-off aceptado.]
-
-**Riesgos**:
-- [Qué podría salir mal y cómo se mitiga.]
-
----
-
-## Cuándo escribir un ADR
-
-Escribir un ADR cuando la decisión cumple **al menos 2 de estos 3 criterios**:
-
-1. **Irreversible**: Costaría mucho tiempo o dinero revertirla. No es un "probamos y si no funciona cambiamos".
-2. **Sorprendente**: Alguien nuevo en el equipo preguntaría "¿por qué hicimos esto?". No es la opción obvia.
-3. **Trade-off**: Hay al menos dos opciones válidas con pros y contras reales. No era claro desde el inicio.
-
-Si la decisión es trivial, obvia, o fácilmente reversible — **no escribir un ADR**. Un comentario en el código es suficiente.
-
-### Ejemplos de cuándo SÍ escribir un ADR
-
-- "Usamos PostgreSQL en lugar de MongoDB para los datos de usuarios."
-- "Elegimos autenticación con JWT en lugar de sesiones."
-- "Usamos colas (RabbitMQ) para procesamiento asíncrono de pagos."
-
-### Ejemplos de cuándo NO escribir un ADR
-
-- "Usamos ESLint para linting." (Obvio, sin trade-off)
-- "Nombramos las branches como `feature/xxx`." (Convención, no decisión de arquitectura)
-- "Elegimos el color azul para el botón principal." (Fácilmente reversible)
-
----
-
-## Formato del nombre de archivo
-
-```
-docs/adr/NNNN-titulo-en-kebab-case.md
-```
-
-- `NNNN`: Número secuencial (0001, 0002, 0003...).
-- El título debe ser descriptivo de la decisión, no del problema.
-- Ejemplo: `0002-use-postgresql-over-mongodb.md`

package/templates/modules/design/docs/DESIGN.md

@@ -1,253 +0,0 @@
----
-created: "2025-01-01"
-status: active
-type: design-system
-tags: [diseño, ui, componentes, colores, tipografía, design-system]
-version: "1.0.0"
-name: "[Nombre del Design System]"
-description: "Sistema de diseño visual para {{PROJECT_NAME}}"
----
-
-# Design System — {{PROJECT_NAME}}
-
-```yaml
-# ⚠️ VALORES DE EJEMPLO — NO SON LOS TOKENS DEL PROYECTO
-# Los valores abajo son ilustrativos (basados en paleta Tailwind).
-# Reemplazar con los tokens reales del proyecto.
-# Para extraer tokens automáticamente del código, usar la skill `doc-design`.
-
-colors:
-  primary:
-    50: "#eff6ff"    # Fondo claro
-    100: "#dbeafe"   # Hover sutil
-    500: "#3b82f6"   # Color principal
-    600: "#2563eb"   # Hover
-    700: "#1d4ed8"   # Activo / Pressed
-    900: "#1e3a5f"   # Texto sobre claro
-  secondary:
-    50: "#f8fafc"
-    500: "#64748b"
-    700: "#334155"
-    900: "#0f172a"
-  semantic:
-    success: "#22c55e"
-    warning: "#f59e0b"
-    error: "#ef4444"
-    info: "#3b82f6"
-  neutral:
-    white: "#ffffff"
-    gray-100: "#f1f5f9"
-    gray-300: "#cbd5e1"
-    gray-500: "#64748b"
-    gray-700: "#334155"
-    black: "#0f172a"
-  brand:
-    corporate: "#[COLOR_PRINCIPAL]"
-    accent: "#[COLOR_SECUNDARIO]"
-
-typography:
-  fontFamily:
-    base: "[Nombre de fuente], sans-serif"
-    heading: "[Nombre de fuente], sans-serif"
-    mono: "[Nombre de fuente monoespaciada], monospace"
-  fontSize:
-    xs: "0.75rem"     # 12px
-    sm: "0.875rem"    # 14px
-    base: "1rem"      # 16px
-    lg: "1.125rem"    # 18px
-    xl: "1.25rem"     # 20px
-    2xl: "1.5rem"     # 24px
-    3xl: "1.875rem"   # 30px
-    4xl: "2.25rem"    # 36px
-  fontWeight:
-    regular: "400"
-    medium: "500"
-    semibold: "600"
-    bold: "700"
-  lineHeight:
-    tight: "1.25"
-    base: "1.5"
-    relaxed: "1.75"
-
-rounded:
-  none: "0"
-  sm: "0.25rem"
-  md: "0.375rem"
-  lg: "0.5rem"
-  xl: "0.75rem"
-  full: "9999px"
-
-spacing:
-  unit: "0.25rem"     # Base: 4px
-  scale: [0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 16, 20, 24]
-
-components:
-  button:
-    variants: [primary, secondary, ghost, danger]
-    sizes: [sm, md, lg]
-    borderRadius: "md"
-  input:
-    variants: [default, error, disabled]
-    borderRadius: "md"
-    height: "2.5rem"
-  card:
-    borderRadius: "lg"
-    shadow: "0 1px 3px rgba(0,0,0,0.1)"
-    padding: "1.5rem"
-  modal:
-    borderRadius: "xl"
-    maxWidth: "32rem"
-    overlay: "rgba(0,0,0,0.5)"
-  table:
-    headerBg: "gray-100"
-    rowHover: "gray-50"
-    borderColor: "gray-300"
-```
-
----
-
-## Visión general
-
-Este documento es la fuente de verdad para las decisiones visuales del proyecto. Todo cambio de UI debe consultar este archivo primero. Si el cambio requiere un nuevo token o componente, actualizar este archivo antes de implementar.
-
-Los tokens de diseño viven aquí. Los componentes se implementan en código y **referencian** estos tokens.
-
----
-
-## Colores
-
-### Paleta principal
-
-| Token | Valor | Uso |
-|-------|-------|-----|
-| `primary-500` | `#[valor]` | Botones principales, links activos, elementos de acción |
-| `primary-700` | `#[valor]` | Botones en estado hover/active |
-| `secondary-500` | `#[valor]` | Elementos secundarios, iconos, texto complementario |
-
-### Colores semánticos
-
-| Token | Valor | Cuándo usarlo |
-|-------|-------|---------------|
-| `success` | `#[valor]` | Operaciones exitosas, confirmaciones, estados positivos |
-| `warning` | `#[valor]` | Advertencias, datos que requieren atención sin ser error |
-| `error` | `#[valor]` | Errores, validaciones fallidas, operaciones fallidas |
-| `info` | `#[valor]` | Información contextual, tooltips, ayuda |
-
-### Reglas de contraste
-
-- Todo texto sobre fondos de color debe cumplir con **WCAG 2.1 nivel AA** (ratio mínimo 4.5:1 para texto normal, 3:1 para texto grande).
-- Verificar contraste con [WebAIM Contrast Checker](https://webaim.org/resources/contrastchecker/).
-- Nunca usar `gray-300` como color de texto sobre fondo blanco.
-
----
-
-## Tipografía
-
-### Jerarquía
-
-| Elemento | Tamaño | Peso | Line-height | Uso |
-|----------|--------|------|-------------|-----|
-| H1 | `2.25rem` (36px) | Bold (700) | Tight (1.25) | Título de página. Una sola vez por página. |
-| H2 | `1.5rem` (24px) | Semibold (600) | Tight (1.25) | Título de sección. |
-| H3 | `1.25rem` (20px) | Semibold (600) | Base (1.5) | Título de subsección o card. |
-| H4 | `1.125rem` (18px) | Medium (500) | Base (1.5) | Títulos menores. |
-| Body | `1rem` (16px) | Regular (400) | Base (1.5) | Texto de párrafo. |
-| Small | `0.875rem` (14px) | Regular (400) | Base (1.5) | Texto secundario, labels, helpers. |
-| Caption | `0.75rem` (12px) | Regular (400) | Base (1.5) | Notas legales, timestamps, metadatos. |
-
-### Reglas
-
-- Máximo **3 niveles de headings** por página (H1 → H2 → H3).
-- No usar H1 más de una vez por vista.
-- Texto siempre en `base` (16px) como mínimo. No usar `xs` para texto funcional.
-
----
-
-## Layout y espaciado
-
-### Grid
-
-- Grid base de **4px**. Todo espaciado debe ser múltiplo de 4.
-- Container máximo: `1280px` centrado.
-- Padding lateral del container: `1.5rem` en mobile, `2rem` en desktop.
-
-### Breakpoints
-
-| Nombre | Ancho | Dispositivo |
-|--------|-------|-------------|
-| `sm` | `640px` | Mobile horizontal |
-| `md` | `768px` | Tablet vertical |
-| `lg` | `1024px` | Tablet horizontal / laptop |
-| `xl` | `1280px` | Desktop |
-
----
-
-## Elevación (Shadows)
-
-| Nivel | Sombra | Uso |
-|-------|--------|-----|
-| `none` | `none` | Elementos flat, backgrounds |
-| `sm` | `0 1px 2px rgba(0,0,0,0.05)` | Cards en reposo |
-| `md` | `0 4px 6px rgba(0,0,0,0.1)` | Cards con hover, dropdowns |
-| `lg` | `0 10px 15px rgba(0,0,0,0.1)` | Modales, popovers |
-| `xl` | `0 20px 25px rgba(0,0,0,0.15)` | Elementos flotantes destacados |
-
----
-
-## Componentes
-
-### Botones
-
-| Variante | Fondo | Texto | Borde |
-|----------|-------|-------|-------|
-| **Primary** | `primary-500` | `white` | Ninguno |
-| **Secondary** | `white` | `gray-700` | `gray-300` |
-| **Ghost** | Transparente | `gray-700` | Ninguno |
-| **Danger** | `error` | `white` | Ninguno |
-
-| Tamaño | Height | Padding horizontal | Font size |
-|--------|--------|-------------------|-----------|
-| `sm` | `2rem` | `0.75rem` | `sm` |
-| `md` | `2.5rem` | `1rem` | `base` |
-| `lg` | `3rem` | `1.5rem` | `lg` |
-
-### Inputs
-
-- Altura: `2.5rem`
-- Border: `1px solid gray-300`
-- Border focus: `2px solid primary-500`
-- Border error: `2px solid error`
-- Placeholder: `gray-500`
-- Mensaje de error debajo del input en color `error`, tamaño `sm`.
-
-### Cards
-
-- Border radius: `lg`
-- Sombra: `sm` en reposo, `md` en hover
-- Padding interno: `1.5rem`
-- Separación entre cards: `1rem`
-
----
-
-## Comportamiento responsive
-
-Principio: **Mobile first**. Se diseña para mobile y se escala hacia desktop.
-
-1. En mobile (< 768px): una sola columna, navegación colapsada, cards apiladas.
-2. En tablet (768px - 1024px): dos columnas donde aplique, sidebar colapsable.
-3. En desktop (> 1024px): layout completo con sidebar expandida.
-
-Regla: ningún elemento debe quedar fuera de viewport o requerir scroll horizontal en ningún breakpoint.
-
----
-
-## Cómo actualizar este archivo
-
-Cuando se añada o cambie un elemento visual:
-
-1. Actualizar el token en el bloque YAML de arriba.
-2. Actualizar la tabla en la sección correspondiente.
-3. Verificar que los componentes que usan ese token sigan teniendo contraste adecuado.
-4. Si el cambio es significativo, crear un ADR explicando el motivo.
-
-Para gestión integral del design system, usar la skill `doc-design`.

package/templates/modules/explanation/docs/explanation/agent-flow.md

@@ -1,15 +0,0 @@
----
-created: "2026-05-07"
-updated: "2026-05-07"
-status: deprecated
-type: redirect
-tags: [flujo, diagrama, agentes]
----
-
-# ⚠️ Este archivo ha sido fusionado
-
-Todo el contenido de diagramas de flujo, estructura de agentes y flujos de decisión se ha consolidado en:
-
-→ **[`docs/internal/agent-guide.md`](../internal/agent-guide.md)**
-
-Este archivo se mantiene como redirect para no romper enlaces existentes.

package/templates/modules/explanation/docs/explanation/architecture.md

@@ -1,138 +0,0 @@
----
-created: "2026-05-07"
-updated: "2026-05-07"
-status: active
-type: explanation
-tags: [architecture, system-design, explanation]
----
-
-# Arquitectura del Sistema
-
-> **Propósito**: Este documento explica la arquitectura del sistema — no *cómo* usarlo, sino *por qué* está diseñado así. Para detalles de implementación, consulta el código fuente. Para decisiones concretas, consulta los ADRs en `docs/adr/`.
-
-## Visión General
-
-[Breve descripción del sistema: qué hace, quién lo usa, cómo se relaciona con otros sistemas]
-
-```mermaid
-flowchart TD
-    Client["🌐 Cliente<br/>(Browser / App / API Consumer)"]
-    CDN["CDN / Load Balancer"]
-    FE["Frontend<br/>[Framework]<br/>SSR/SPA · Routing · State"]
-    BE["API / Backend<br/>[Framework]<br/>REST API · Auth · Business logic"]
-    DB["🗄️ Base de datos<br/>[PostgreSQL]"]
-    Cache["⚡ Cache<br/>[Redis/etc]"]
-
-    Client --> CDN
-    CDN --> FE
-    CDN --> BE
-    BE --> DB
-    BE --> Cache
-```
-
-## Componentes Principales
-
-### Frontend
-
-- **Framework**: [Ej: React 18 / Next.js 14 / Vue 3]
-- **Renderizado**: [SSR / SSG / SPA / Híbrido]
-- **Estado**: [Local state / Context / Zustand / Redux]
-- **Routing**: [Client-side / Server-side / File-based]
-- **Estilos**: [Tailwind / CSS Modules / Styled Components]
-
-> Ver ADRs relevantes en `docs/adr/` para entender por qué se eligió cada tecnología.
-
-### Backend / API
-
-- **Framework**: [Ej: Express / Fastify / NestJS / Hono]
-- **Arquitectura**: [Monolito / Microservicios / Serverless]
-- **Autenticación**: [JWT / Session / OAuth / API Keys]
-- **Validación**: [Zod / Joi / class-validator]
-
-### Base de Datos
-
-- **Tipo**: [Relacional / NoSQL / Híbrido]
-- **Motor**: [PostgreSQL / MySQL / MongoDB]
-- **ORM**: [Prisma / TypeORM / Sequelize / Drizzle]
-- **Migraciones**: [Gestionadas por el ORM / Manuales]
-
-## Flujos Principales
-
-### Flujo de Autenticación
-
-```mermaid
-sequenceDiagram
-    participant U as Usuario
-    participant FE as Frontend
-    participant BE as Backend
-    participant DB as Base de datos
-
-    U->>FE: Login (email + password)
-    FE->>BE: POST /auth/login
-    BE->>DB: Verificar credenciales
-    DB-->>BE: Usuario válido
-    BE-->>FE: JWT + Refresh Token
-    FE->>FE: Almacenar tokens
-    U->>FE: Acción protegida
-    FE->>BE: Request + Bearer token
-    BE->>BE: Verificar JWT
-    BE-->>FE: Respuesta
-```
-
-### Flujo de Datos Principal
-
-```mermaid
-sequenceDiagram
-    participant U as Usuario
-    participant FE as Frontend
-    participant BE as Backend
-    participant DB as Base de datos
-
-    U->>FE: Acción en UI
-    FE->>BE: API Request
-    BE->>BE: Validación + Lógica
-    BE->>DB: Read/Write
-    DB-->>BE: Resultado
-    BE-->>FE: Respuesta JSON
-    FE->>FE: Actualizar UI
-    FE-->>U: Vista actualizada
-```
-
-## Decisiones Arquitectónicas Clave
-
-Las decisiones técnicas importantes están documentadas como ADRs en `docs/adr/`. Aquí un resumen:
-
-| Decisión | ADR | Resumen |
-|----------|-----|---------|
-| [Ej: Base de datos] | `0002-*` | [Por qué se eligió] |
-| [Ej: Framework frontend] | `0003-*` | [Por qué se eligió] |
-| [Ej: Autenticación] | `0004-*` | [Por qué se eligió] |
-
-> **Nota**: Para criterios de cuándo crear un ADR, ver [`docs/adr/TEMPLATE.md`](../adr/TEMPLATE.md).
-
-## Límites del Sistema
-
-### Qué NO hace este sistema
-
-- [Limitación 1]
-- [Limitación 2]
-
-### Escalabilidad
-
-- **Horizontal**: [Cómo escala el backend]
-- **Vertical**: [Límites de recursos]
-- **BD**: [Estrategia de escalado de datos]
-
-## Dependencias Externas
-
-| Servicio | Propósito | Alternativa si cae |
-|----------|-----------|-------------------|
-| [Servicio 1] | [Qué hace] | [Plan B] |
-| [Servicio 2] | [Qué hace] | [Plan B] |
-
-## Diagramas Relacionados
-
-- Ver [`docs/internal/agent-guide.md`](../internal/agent-guide.md) para diagramas de flujo de agentes
-- Ver `docs/guides/runbooks/` para procedimientos operativos
-- Ver `docs/reference/infrastructure.md` para detalles de entornos
-- Ver `docs/reference/api.md` para la referencia de la API

package/templates/modules/guides/docs/guides/deployment.md

@@ -1,189 +0,0 @@
----
-created: "2025-01-01"
-status: active
-type: guide
-tags: [guía, deployment, deploy, producción, staging]
----
-
-# Guía de Deployment
-
-Instrucciones paso a paso para hacer deploy de la aplicación a cada entorno.
-
----
-
-## Entornos
-
-| Entorno | Propósito | URL | Branch | Auto-deploy |
-|---------|-----------|-----|--------|-------------|
-| **Development** | Desarrollo local | `http://localhost:3000` | Cualquiera | N/A |
-| **Staging** | QA y validación antes de producción | `https://staging.[dominio]` | `develop` o `main` | Sí (push a branch) |
-| **Production** | Usuarios finales | `https://[dominio]` | `main` | Sí (tag / release) |
-
-Ver detalles de infraestructura en [`docs/reference/infrastructure.md`](../reference/infrastructure.md).
-
----
-
-## Prerrequisitos
-
-- Acceso al repositorio con permisos de push a `main`.
-- Acceso a la plataforma de CI/CD (ej. {{TECH_STACK}}, Vercel, AWS Console).
-- Variables de entorno configuradas para el entorno destino (ver [`configuration.md`](../reference/configuration.md)).
-
----
-
-## Deploy a Staging
-
-Staging se actualiza automáticamente al hacer push a `[develop / main]`. Si necesitas deploy manual:
-
-### Opción A: Deploy automático (recomendado)
-
-```bash
-# Hacer push a la branch que triggera staging
-git push origin [develop / main]
-```
-
-Verificar en la plataforma de CI/CD que el pipeline pasó correctamente.
-
-### Opción B: Deploy manual
-
-```bash
-# 1. Construir la aplicación
-[npm run build]
-
-# 2. Deploy manual (según plataforma)
-[comando de deploy específico — ej. vercel --prod, aws deploy push, etc.]
-```
-
-### Verificación post-deploy
-
-Después de que el deploy termine:
-
-1. Abrir `https://staging.[dominio]` y verificar que la versión es la correcta.
-2. Ejecutar smoke tests manuales:
-   - [ ] Login funciona
-   - [ ] Página principal carga
-   - [ ] [Flujo principal del negocio] funciona end-to-end
-3. Verificar que no hay errores en consola (browser) ni en logs (servidor).
-4. Verificar que la versión/metadata es correcta (footer, health check, etc.).
-
----
-
-## Deploy a Producción
-
-**Importante**: Los deploys a producción se hacen desde `main` **únicamente**. Nunca desde branches de feature.
-
-### Pre-deploy checklist
-
-Antes de hacer deploy a producción, verificar:
-
-- [ ] Todos los tests pasan en CI (último build verde).
-- [ ] Staging fue validado por QA/producto.
-- [ ] No hay migraciones de base de datos pendientes (o están preparadas).
-- [ ] Las variables de entorno de producción están actualizadas.
-- [ ] El CHANGELOG está actualizado.
-- [ ] Se comunicó al equipo el horario del deploy (si aplica).
-
-### Proceso
-
-#### Opción A: Deploy automático via tag
-
-```bash
-# 1. Crear un tag de release
-git tag -a v[VERSIÓN] -m "Release v[VERSIÓN]"
-
-# 2. Pushear el tag
-git push origin v[VERSIÓN]
-
-# 3. El pipeline de CI/CD detecta el tag y hace deploy automático
-```
-
-#### Opción B: Deploy manual
-
-```bash
-# 1. Asegurarse de estar en main y actualizado
-git checkout main
-git pull origin main
-
-# 2. Construir
-[npm run build]
-
-# 3. Deploy
-[comando de deploy a producción]
-```
-
-### Post-deploy
-
-Inmediatamente después del deploy:
-
-1. **Verificar la URL de producción**: abrir `https://[dominio]` y confirmar que la versión es la nueva.
-2. **Smoke tests rápidos**:
-   - [ ] Página principal carga
-   - [ ] Login funciona
-   - [ ] [Flujo principal] funciona
-3. **Monitorear logs** durante los primeros 15 minutos:
-   - Verificar que no hay errores inusuales.
-   - Verificar que el tráfico se ve normal.
-4. **Actualizar CHANGELOG**: mover los cambios de "Sin publicar" a la sección de la versión.
-5. **Comunicar**: notificar al equipo que el deploy fue exitoso (Slack / Teams / email).
-
-### Rollback
-
-Si algo sale mal después del deploy:
-
-```bash
-# 1. Identificar la versión anterior (la que funcionaba)
-git log --oneline -5
-
-# 2. Re-deployear la versión anterior
-git checkout v[VERSIÓN_ANTERIOR]
-[comando de deploy a producción]
-
-# 3. Alternativa: revertir el merge commit
-git revert -m 1 [HASH_DEL_MERGE]
-git push origin main
-```
-
----
-
-## Migraciones de base de datos
-
-Las migraciones se ejecutan como parte del pipeline de deploy, pero si necesitaras ejecutarlas manualmente:
-
-```bash
-# Ver el estado de las migraciones
-[comando de status — ej. npm run db:status]
-
-# Ejecutar migraciones pendientes
-[comando de migración — ej. npm run db:migrate]
-
-# Rollback de la última migración (solo en emergencias)
-[comando de rollback — ej. npm run db:rollback]
-```
-
-**Regla**: Las migraciones deben ser **siempre hacia adelante** (additive). No modificar columnas existentes en breaking ways. Crear nuevas columnas y migrar datos gradualmente.
-
----
-
-## Variables de entorno por entorno
-
-| Variable | Development | Staging | Production |
-|----------|-------------|---------|------------|
-| `APP_ENV` | `development` | `staging` | `production` |
-| `DATABASE_URL` | Local | Staging DB | Production DB |
-| `API_KEY_[SERVICIO]` | Key de testing | Key de staging | Key de producción |
-| `LOG_LEVEL` | `debug` | `info` | `warn` |
-
-Ver la referencia completa en [`configuration.md`](../reference/configuration.md).
-
----
-
-## Troubleshooting de deploys
-
-| Problema | Causa probable | Solución |
-|----------|---------------|----------|
-| Build falla en CI pero pasa local | Diferencia de versiones de Node/npm | Verificar que `.nvmrc` o `engines` en `package.json` coincida con CI |
-| Deploy exitoso pero página en blanco | Variables de entorno faltantes | Verificar todas las vars requeridas en el entorno |
-| Migración falla | Cambio breaking en schema | Ejecutar rollback y corregir la migración |
-| Timeout en deploy | Recursos insuficientes | Verificar logs del CI/CD y recursos del servidor |
-
-Más soluciones en [`troubleshooting.md`](troubleshooting.md).