create-bk-agent 0.22.0 → 0.22.1

package/dist/src/index.js

@@ -94,7 +94,9 @@ function buildNextSteps(choices) {
             ? 'node test-flow.mjs calificacion-lead   # or propuesta-comercial'
             : tmpl === 'marketing'
                 ? 'node test-flow.mjs articulo-blog       # or campana-leads'
-                : '# Define your flows in flows/ and run: node test-flow.mjs';
+                : tmpl === 'soporte'
+                    ? 'node test-flow.mjs atencion-ticket     # or incidente-critico'
+                    : '# Define your flows in flows/ and run: node test-flow.mjs';
         return [
             'Add your API key to .env',
             'Edit orchestrator.yaml to customize agents for your domain',

package/dist/src/prompts.js

@@ -100,6 +100,11 @@ const WORKFLOW_TEMPLATE_CHOICES = [
         value: 'marketing',
         description: '6 agents: content strategist, copywriter, SEO, social, campaign, analytics',
     },
+    {
+        title: p('Soporte al cliente', 22) + 'Ticket triage, L1/L2/L3 escalation and critical incident management',
+        value: 'soporte',
+        description: '6 agents: triage, support L1, technical L2, escalation L3, communication, knowledge',
+    },
     {
         title: p('Blank', 22) + 'Empty orchestrator.yaml — define your own agents and flows',
         value: 'blank',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-bk-agent",
-  "version": "0.22.0",
+  "version": "0.22.1",
   "description": "Create a new BackendKit agent project",
   "main": "dist/src/index.js",
   "bin": {

package/templates/base/orchestrator/soporte/flows/atencion-ticket.yaml

@@ -0,0 +1,159 @@
+version: 1
+id: atencion-ticket
+name: "Atención de Ticket — {{payload.ticket_id}}"
+description: >
+  Pipeline completo de atención a un ticket de soporte: triage y priorización,
+  resolución L1 con la base de conocimiento, comunicación al cliente con gate de
+  aprobación, y registro de aprendizajes en la KB.
+
+steps:
+  - id: s1-triage
+    agent: triage-agent
+    depends_on: []
+    task: |
+      Clasificar y priorizar el siguiente ticket de soporte entrante.
+
+      DATOS DEL TICKET:
+      - ID: {{payload.ticket_id}}
+      - Cliente: {{payload.cliente}}
+      - Plan/Tier: {{payload.plan}}
+      - Canal de entrada: {{payload.canal}}
+      - Asunto: {{payload.asunto}}
+      - Descripción del problema: {{payload.descripcion}}
+      - Información del entorno (si la proporcionó): {{payload.entorno}}
+
+      Producir el triage completo:
+
+      1. PRIORIDAD
+         - P1 Crítico: sistema caído, impacto en producción, sin workaround
+         - P2 Alto: funcionalidad core degradada, impacto en operaciones
+         - P3 Medio: bug con workaround disponible o feature parcialmente afectada
+         - P4 Bajo: consulta, mejora sugerida o cosmético
+
+      2. TIPO DE ISSUE
+         - Bug / Error técnico
+         - Consulta / "How to"
+         - Solicitud de feature / mejora
+         - Problema de rendimiento / performance
+         - Acceso / permisos / facturación
+         - Integración con terceros
+
+      3. ÁREA DE PRODUCTO AFECTADA
+         Identificar qué módulo, API o componente está involucrado basándose en la descripción.
+
+      4. NIVEL DE SOPORTE REQUERIDO
+         - L1: resoluble con documentación existente o procedimiento estándar
+         - L2: requiere investigación técnica, acceso a logs o análisis de código
+         - L3: requiere escalación a ingeniería, posible bug en producción
+
+      5. SLA APLICABLE
+         Tiempo de respuesta y resolución según prioridad y plan del cliente.
+
+      6. INFORMACIÓN FALTANTE
+         Lista de datos adicionales que necesitamos del cliente para resolver más rápido
+         (si aplica).
+
+      7. CONTEXTO PARA EL AGENTE DE SOPORTE
+         Resumen ejecutivo de 3-4 líneas con lo que sabe el siguiente agente para arrancar.
+
+  - id: s2-resolucion
+    agent: support-agent
+    depends_on: [s1-triage]
+    task: |
+      Resolver el ticket de soporte usando la base de conocimiento.
+
+      TRIAGE DEL TICKET:
+      {{steps.s1-triage.output}}
+
+      TICKET ORIGINAL:
+      - Cliente: {{payload.cliente}} (Plan: {{payload.plan}})
+      - Asunto: {{payload.asunto}}
+      - Descripción: {{payload.descripcion}}
+      - Entorno: {{payload.entorno}}
+
+      Produce la respuesta de soporte L1:
+
+      1. DIAGNÓSTICO
+         Qué está causando el problema según la descripción y la base de conocimiento.
+
+      2. SOLUCIÓN PASO A PASO
+         Instrucciones claras y numeradas para que el cliente resuelva el problema.
+         Si hay un workaround mientras se investiga la causa raíz, indicarlo primero.
+
+      3. VERIFICACIÓN
+         Cómo sabe el cliente que el problema se resolvió (qué debe ver/comprobar).
+
+      4. ESTADO DE RESOLUCIÓN
+         - RESUELTO: el problema tiene solución documentada y completa
+         - NECESITA_INFO: falta información del cliente para continuar
+         - ESCALAR_L2: el issue supera el alcance de L1, necesita investigación técnica
+         - WORKAROUND: hay solución temporal pero el root cause requiere L2
+
+      5. ARTÍCULOS DE KB UTILIZADOS
+         Lista de artículos o secciones de la documentación consultados (para tracking).
+
+  - id: s3-comunicacion
+    agent: communication-agent
+    depends_on: [s1-triage, s2-resolucion]
+    gate: true
+    gate_criteria:
+      - "La respuesta es clara y accionable — el cliente sabe exactamente qué hacer"
+      - "El tono es empático sin ser condescendiente"
+      - "Si el issue no se resuelve completamente, se explica el próximo paso y el tiempo estimado"
+      - "No se incluye jerga interna ni información confidencial"
+    task: |
+      Redactar la respuesta al cliente para el ticket {{payload.ticket_id}}.
+
+      TRIAGE:
+      {{steps.s1-triage.output}}
+
+      RESOLUCIÓN L1:
+      {{steps.s2-resolucion.output}}
+
+      DATOS DEL CLIENTE:
+      - Nombre: {{payload.cliente}}
+      - Canal: {{payload.canal}}
+      - Plan: {{payload.plan}}
+
+      Redactar la comunicación completa:
+
+      ## Asunto del email / título de la respuesta
+      Claro, específico, que transmita que estamos trabajando en ello.
+
+      ## Cuerpo de la respuesta
+      - Apertura: reconocer el problema con empatía (1-2 líneas, sin excesos)
+      - Diagnóstico explicado en términos del cliente (no jerga técnica interna)
+      - Solución o próximos pasos numerados y claros
+      - Tiempo estimado si el problema no está completamente resuelto
+      - Cierre: cómo contactarnos si la solución no funciona o hay preguntas
+
+      ## Notas internas (no van al cliente)
+      - Información de contexto para el agente que haga seguimiento
+      - Acciones pendientes del equipo de soporte
+
+  - id: s4-kb
+    agent: knowledge-agent
+    depends_on: [s2-resolucion, s3-comunicacion]
+    task: |
+      Analizar el ticket resuelto y proponer mejoras a la base de conocimiento.
+
+      TICKET: {{payload.asunto}}
+      TRIAGE: {{steps.s1-triage.output}}
+      RESOLUCIÓN: {{steps.s2-resolucion.output}}
+
+      Evaluar:
+
+      1. ¿EXISTE ARTÍCULO EN LA KB?
+         - SÍ, está actualizado → no se requiere acción
+         - SÍ, pero está desactualizado o incompleto → proponer actualización
+         - NO → proponer nuevo artículo
+
+      2. PROPUESTA DE CONTENIDO (si aplica)
+         Si se necesita crear o actualizar un artículo, redactar el borrador completo
+         siguiendo la estructura: título + descripción del problema + causa + solución
+         paso a paso + verificación + casos relacionados.
+
+      3. MEJORAS AL PROCESO
+         Si este ticket reveló un gap en el proceso de atención (pregunta frecuente no
+         documentada, procedimiento ambiguo, criterio de escalación poco claro), proponer
+         la mejora específica.

package/templates/base/orchestrator/soporte/flows/incidente-critico.yaml

@@ -0,0 +1,218 @@
+version: 1
+id: incidente-critico
+name: "Incidente Crítico — {{payload.incidente_id}}"
+description: >
+  Gestión de incidentes P1/P2: confirmación y escalación con gate, diagnóstico
+  técnico profundo, plan de resolución con gate de aprobación, comunicado externo
+  al cliente y postmortem para prevenir recurrencias.
+
+steps:
+  - id: s1-confirmacion
+    agent: triage-agent
+    depends_on: []
+    gate: true
+    gate_criteria:
+      - "La prioridad P1/P2 está correctamente justificada con el impacto real"
+      - "El alcance del incidente está definido (cuántos clientes, qué funcionalidades)"
+      - "Se identificó el canal de comunicación de crisis y los responsables en guardia"
+      - "Hay un War Room o canal de coordinación definido"
+    task: |
+      Confirmar y documentar el incidente crítico para activar el protocolo de respuesta.
+
+      DATOS DEL INCIDENTE:
+      - ID: {{payload.incidente_id}}
+      - Reportado por: {{payload.reportado_por}}
+      - Fecha/hora de detección: {{payload.hora_deteccion}}
+      - Descripción inicial: {{payload.descripcion}}
+      - Sistemas afectados: {{payload.sistemas_afectados}}
+      - Clientes impactados (estimado): {{payload.clientes_impactados}}
+      - Síntomas observados: {{payload.sintomas}}
+
+      Producir el documento de apertura del incidente:
+
+      1. CLASIFICACIÓN
+         - Prioridad confirmada: P1 / P2 con justificación
+         - Tipo de incidente: outage total / degradación / pérdida de datos / seguridad / rendimiento
+         - Sistemas afectados con nivel de impacto por sistema
+
+      2. ALCANCE DEL IMPACTO
+         - Clientes afectados (cantidad y segmento)
+         - Funcionalidades no disponibles o degradadas
+         - Impacto en negocio estimado (revenue, operaciones, reputación)
+
+      3. HIPÓTESIS INICIALES
+         3 hipótesis de causa raíz ordenadas por probabilidad.
+
+      4. PLAN DE RESPUESTA INMEDIATA
+         - Acciones en las próximas 15 minutos
+         - Responsable de cada acción (rol)
+         - Canal de coordinación del equipo (War Room)
+
+      5. COMUNICACIÓN INICIAL
+         - A quién notificar dentro de la empresa (escalación interna)
+         - Si se debe notificar proactivamente a clientes ahora o esperar diagnóstico
+
+  - id: s2-diagnostico
+    agent: technical-agent
+    depends_on: [s1-confirmacion]
+    task: |
+      Realizar el diagnóstico técnico profundo del incidente.
+
+      DOCUMENTO DE APERTURA DEL INCIDENTE:
+      {{steps.s1-confirmacion.output}}
+
+      INFORMACIÓN TÉCNICA DISPONIBLE:
+      - Sistemas afectados: {{payload.sistemas_afectados}}
+      - Síntomas: {{payload.sintomas}}
+      - Logs o errores disponibles: {{payload.logs}}
+      - Cambios recientes en producción: {{payload.cambios_recientes}}
+
+      Producir el diagnóstico técnico:
+
+      1. ANÁLISIS DE CAUSA RAÍZ
+         Evaluación de cada hipótesis con la evidencia disponible.
+         Conclusión: causa raíz confirmada o hipótesis más probable con nivel de confianza.
+
+      2. ÁRBOL DE IMPACTO
+         Qué sistemas dependen del sistema afectado y cómo se propaga el fallo.
+
+      3. OPCIONES DE RESOLUCIÓN
+         Para cada opción: descripción, tiempo estimado, riesgo, impacto secundario.
+         - Opción A (más rápida): workaround o rollback
+         - Opción B (más definitiva): fix en producción
+         - Opción C (si aplica): fallback o degraded mode
+
+      4. RECOMENDACIÓN
+         Qué opción ejecutar primero y por qué, con los pasos concretos.
+
+      5. RIESGOS DE LA INTERVENCIÓN
+         Qué puede salir mal al aplicar la solución y cómo mitigarlo.
+
+  - id: s3-plan-resolucion
+    agent: escalation-agent
+    depends_on: [s2-diagnostico]
+    gate: true
+    gate_criteria:
+      - "La opción de resolución elegida está aprobada por el responsable técnico"
+      - "Hay un rollback plan definido si la solución empeora el incidente"
+      - "El tiempo estimado de resolución está actualizado y es realista"
+      - "Se definió quién ejecuta cada paso (no puede quedar sin responsable asignado)"
+    task: |
+      Diseñar y coordinar el plan de resolución del incidente.
+
+      DIAGNÓSTICO TÉCNICO:
+      {{steps.s2-diagnostico.output}}
+
+      CONTEXTO DEL INCIDENTE:
+      ID: {{payload.incidente_id}} | Sistemas: {{payload.sistemas_afectados}}
+      Clientes impactados: {{payload.clientes_impactados}}
+
+      Producir el plan de resolución:
+
+      1. DECISIÓN DE RESOLUCIÓN
+         Opción elegida con justificación y aprobación requerida.
+
+      2. RUNBOOK DE EJECUCIÓN
+         Pasos numerados con:
+         - Acción específica
+         - Responsable (rol)
+         - Tiempo estimado
+         - Criterio de verificación (cómo saber que el paso funcionó)
+
+      3. ROLLBACK PLAN
+         Si el fix empeora el incidente, qué hacer en los primeros 5 minutos.
+
+      4. CRITERIO DE RESOLUCIÓN
+         Cómo sabemos que el incidente está cerrado (métricas, checks, confirmación).
+
+      5. COMUNICACIÓN DURANTE LA RESOLUCIÓN
+         - Cada cuánto actualizar a clientes (ej: cada 30 minutos)
+         - Qué decirle al equipo interno
+         - Cuándo declarar "resuelto" públicamente
+
+      6. EQUIPO DE GUARDIA
+         Roles y responsabilidades durante la ejecución del plan.
+
+  - id: s4-comunicado-externo
+    agent: communication-agent
+    depends_on: [s1-confirmacion, s3-plan-resolucion]
+    task: |
+      Redactar las comunicaciones externas para el incidente {{payload.incidente_id}}.
+
+      CONTEXTO DEL INCIDENTE:
+      {{steps.s1-confirmacion.output}}
+
+      PLAN DE RESOLUCIÓN:
+      {{steps.s3-plan-resolucion.output}}
+
+      Redactar los 3 comunicados necesarios:
+
+      ## 1. COMUNICADO DE APERTURA (enviar ahora)
+      - Qué está pasando (sin jerga técnica, en términos de impacto al cliente)
+      - Qué estamos haciendo para resolverlo
+      - Tiempo estimado de resolución (dar rango, no promesas exactas)
+      - Dónde ver actualizaciones (status page, canal de comunicación)
+      - Contacto para urgencias
+
+      ## 2. ACTUALIZACIONES DE PROGRESO (template reutilizable)
+      Template con placeholders para actualizar cada 30 minutos durante el incidente:
+      - [HORA] Estado actual
+      - [AVANCE] Qué se hizo
+      - [PRÓXIMOS PASOS] Qué sigue
+      - [ETA] Estimación actualizada
+
+      ## 3. COMUNICADO DE CIERRE
+      - Confirmación de que el incidente fue resuelto
+      - Descripción breve de qué pasó y cómo se resolvió (sin exponer vulnerabilidades)
+      - Medidas tomadas para que no vuelva a ocurrir
+      - Disculpas y reconocimiento del impacto
+      - Crédito/compensación si aplica según política
+
+  - id: s5-postmortem
+    agent: technical-agent
+    depends_on: [s2-diagnostico, s3-plan-resolucion, s4-comunicado-externo]
+    task: |
+      Redactar el documento de postmortem del incidente {{payload.incidente_id}}.
+
+      DIAGNÓSTICO TÉCNICO:
+      {{steps.s2-diagnostico.output}}
+
+      PLAN Y RESOLUCIÓN:
+      {{steps.s3-plan-resolucion.output}}
+
+      DATOS DEL INCIDENTE:
+      - Hora de detección: {{payload.hora_deteccion}}
+      - Sistemas afectados: {{payload.sistemas_afectados}}
+      - Clientes impactados: {{payload.clientes_impactados}}
+
+      Estructura del postmortem (blameless — sin culpables, solo sistemas y procesos):
+
+      ## Resumen Ejecutivo
+      3-4 líneas: qué pasó, cuánto duró, impacto total.
+
+      ## Timeline
+      Cronología minuto a minuto desde la detección hasta la resolución.
+
+      ## Causa Raíz
+      Causa técnica confirmada. Usar "5 Whys" para llegar al root cause real.
+
+      ## Factores Contribuyentes
+      Condiciones que hicieron posible o empeoraron el incidente.
+
+      ## Qué Funcionó Bien
+      Partes del proceso de respuesta que fueron efectivas.
+
+      ## Qué No Funcionó
+      Gaps en detección, respuesta, comunicación o herramientas.
+
+      ## Acciones Correctivas
+      Lista priorizada de mejoras con responsable y fecha límite:
+      - Acciones de remediación inmediata (ya implementadas)
+      - Acciones de prevención a corto plazo (< 2 semanas)
+      - Acciones estructurales a mediano plazo (< 3 meses)
+
+      ## Métricas del Incidente
+      - MTTD (Mean Time to Detect)
+      - MTTA (Mean Time to Acknowledge)
+      - MTTR (Mean Time to Resolve)
+      - Clientes impactados y duración del impacto

package/templates/base/orchestrator/soporte/orchestrator.yaml

@@ -0,0 +1,98 @@
+version: 1
+
+orchestrator:
+  name: "Orquestador de Soporte al Cliente"
+  provider: __PROVIDER_ID__
+  vault:
+    path: ./vault
+    embedder: simple          # change to "ollama" in production for better semantic search
+
+__PROVIDERS_BLOCK__
+
+flows:
+  - id: atencion-ticket
+    file: ./flows/atencion-ticket.yaml
+    trigger: "ticket|soporte|consulta|problema|error|bug|incidencia|reclamo|ayuda|no funciona|falla"
+
+  - id: incidente-critico
+    file: ./flows/incidente-critico.yaml
+    trigger: "incidente|crítico|caído|urgente|p1|p2|emergencia|producción|caída del sistema|outage"
+
+agents:
+  - id: triage-agent
+    name: "Agente de Triage"
+    description: >
+      Clasifica y prioriza tickets de soporte entrantes. Determina la urgencia (P1-P4),
+      el tipo de issue (bug, consulta, facturación, feature request), el área de producto
+      afectada y el nivel de soporte requerido (L1/L2/L3). Genera el contexto inicial
+      para el agente que tomará el ticket.
+    capabilities: [triage, clasificacion, prioridad, sla, routing, diagnostico-inicial]
+    provider: __PROVIDER_ID__
+    domain: soporte
+
+  - id: support-agent
+    name: "Agente de Soporte L1"
+    description: >
+      Maneja tickets de soporte de nivel 1: consultas frecuentes, configuraciones estándar,
+      procedimientos documentados y troubleshooting básico. Usa la base de conocimiento para
+      dar respuestas precisas y consistentes. Si no puede resolver, prepara el contexto
+      para escalación a L2 con toda la información necesaria.
+    capabilities: [l1, soporte, faq, troubleshooting, kb, resolucion, guia-paso-a-paso]
+    provider: __PROVIDER_ID__
+    domain: soporte
+
+  - id: technical-agent
+    name: "Agente Técnico L2"
+    description: >
+      Investigación técnica profunda de issues complejos. Diagnóstico de root cause,
+      análisis de logs, identificación de bugs, propuesta de workarounds y soluciones
+      definitivas. Documenta hallazgos técnicos para el equipo de ingeniería y para
+      enriquecer la base de conocimiento.
+    capabilities: [l2, tecnico, diagnostico, root-cause, logs, bugs, workaround, ingenieria]
+    provider: __PROVIDER_ID__
+    domain: soporte
+    gate: true
+    gate_criteria:
+      - "El diagnóstico incluye el root cause o una hipótesis sólida con evidencia"
+      - "Se propone al menos un workaround inmediato para desbloquear al cliente"
+      - "La solución propuesta no implica cambios de datos o configuración sin respaldo"
+      - "Se documentaron los pasos de reproducción del issue"
+
+  - id: escalation-agent
+    name: "Agente de Escalación L3"
+    description: >
+      Gestiona incidentes críticos y escalaciones a ingeniería. Coordina la respuesta
+      ante outages, define el plan de acción con responsables y tiempos, y asegura que
+      se mantenga informado al cliente durante todo el incidente. Lidera el proceso de
+      postmortem y seguimiento de acciones correctivas.
+    capabilities: [l3, escalacion, incidente, outage, coordinacion, postmortem, p1, p2]
+    provider: __PROVIDER_ID__
+    domain: soporte
+    gate: true
+    gate_criteria:
+      - "La escalación a ingeniería está justificada y el impacto está cuantificado"
+      - "Hay un responsable asignado (nombre o rol) para cada acción del plan"
+      - "El cliente fue notificado del incidente y del tiempo estimado de resolución"
+      - "Se definió el criterio de resolución: cómo sabemos que el incidente está cerrado"
+
+  - id: communication-agent
+    name: "Agente de Comunicación"
+    description: >
+      Redacta todas las comunicaciones hacia el cliente: respuestas a tickets, actualizaciones
+      de estado durante incidentes, emails de cierre, solicitudes de información adicional y
+      encuestas de satisfacción. Adapta el tono y nivel técnico al perfil del cliente.
+      Asegura que cada comunicación sea clara, empática y accionable.
+    capabilities: [comunicacion, redaccion, email, respuesta-cliente, estado, cierre, empatia]
+    provider: __PROVIDER_ID__
+    domain: soporte
+
+  - id: knowledge-agent
+    name: "Agente de Base de Conocimiento"
+    description: >
+      Mantiene y mejora la base de conocimiento de soporte. Identifica gaps de documentación
+      a partir de tickets resueltos, propone nuevos artículos o actualizaciones de los
+      existentes, y sugiere mejoras en los procedimientos de atención para reducir el tiempo
+      de resolución en futuros tickets similares.
+    capabilities: [knowledge-base, documentacion, kb, articulos, mejora-continua, procedimientos]
+    provider: __PROVIDER_ID__
+    domain: soporte

package/templates/base/orchestrator/soporte/test-flow.mjs

@@ -0,0 +1,210 @@
+#!/usr/bin/env node
+/**
+ * Test runner for the soporte orchestrator
+ *
+ * Usage:
+ *   node test-flow.mjs atencion-ticket    # standard ticket (triage → L1 → gate → KB)
+ *   node test-flow.mjs incidente-critico  # P1 incident (gate → diagnosis → gate → comms → postmortem)
+ *   node test-flow.mjs dynamic            # dynamic planning (no flow match)
+ */
+
+import { spawn }          from 'node:child_process';
+import { createInterface } from 'node:readline';
+import * as path          from 'node:path';
+import * as fs            from 'node:fs';
+import * as url           from 'node:url';
+
+const __dirname   = path.dirname(url.fileURLToPath(import.meta.url));
+const CONFIG_PATH = path.resolve(__dirname, 'orchestrator.yaml');
+const SERVER_PATH = path.resolve(
+    __dirname,
+    'node_modules/@backendkit-labs/orchestrator-agent/dist/server.js',
+);
+
+// ── Sample payloads ───────────────────────────────────────────────────────────
+
+const FLOWS = {
+    'atencion-ticket': {
+        flow_id: 'atencion-ticket',
+        task: 'Atender ticket de soporte: error al exportar reportes en formato Excel',
+        payload: {
+            ticket_id:   'TKT-2024-1547',
+            cliente:     'Acme Corp',
+            plan:        'Professional',
+            canal:       'Portal de soporte',
+            asunto:      'Error al exportar reportes en formato Excel — aparece "Download failed"',
+            descripcion: 'Desde ayer a la tarde, cuando intento descargar cualquier reporte en formato Excel (no en CSV), me aparece el mensaje "Download failed" y no se genera ningún archivo. El botón de descarga en PDF sí funciona bien. Lo probé en Chrome y Firefox con el mismo resultado. Necesito los reportes para una reunión de directorio mañana a las 10hs.',
+            entorno:     'Chrome 124, Windows 11, cuenta admin. La sesión expira correctamente y puedo hacer todo lo demás en la plataforma sin problemas.',
+        },
+    },
+    'incidente-critico': {
+        flow_id: 'incidente-critico',
+        task: 'Gestionar incidente crítico: plataforma inaccesible para clientes Enterprise',
+        payload: {
+            incidente_id:       'INC-2024-003',
+            reportado_por:      'Sistema de monitoreo + 3 clientes Enterprise simultáneamente',
+            hora_deteccion:     '2024-06-14 09:23 ART',
+            descripcion:        'La plataforma devuelve error 503 para todos los usuarios. El health check de la API principal está fallando. Múltiples clientes Enterprise están llamando al número de emergencias.',
+            sistemas_afectados: 'API principal (/api/v3/*), Dashboard web, Mobile app. La base de datos parece responder (status page de RDS en verde).',
+            clientes_impactados: 'Estimado 100% de usuarios activos en este momento (~340 sesiones activas según los últimos logs disponibles)',
+            sintomas:           'HTTP 503 en todas las rutas de la API. Los worker processes de Node.js no están respondiendo. Los logs muestran "FATAL: Cannot allocate memory" repetidamente desde las 09:18.',
+            logs:               'FATAL: Cannot allocate memory in static TLS block\nnode: Cannot allocate memory\nAborted (core dumped)\nRestarting worker... (intent 47 en los últimos 5 minutos)',
+            cambios_recientes:  'Deploy de v3.4.1 a las 08:45 (35 minutos antes del incidente). El deploy incluyó actualización de una dependencia de procesamiento de imágenes.',
+        },
+    },
+    'dynamic': {
+        flow_id: undefined,
+        task: process.env.TASK ?? 'Analizar los tickets de la última semana e identificar los 3 problemas más frecuentes que deberían documentarse como artículos de KB',
+        payload: {},
+    },
+};
+
+// ── MCP Client (stdio) ────────────────────────────────────────────────────────
+
+class McpClient {
+    constructor(serverPath) {
+        this._nextId  = 1;
+        this._pending = new Map();
+
+        const env    = { ...process.env };
+        const dotenv = path.join(__dirname, '.env');
+        if (fs.existsSync(dotenv)) {
+            for (const line of fs.readFileSync(dotenv, 'utf-8').split('\n')) {
+                const m = line.match(/^\s*([A-Z_][A-Z0-9_]*)\s*=\s*(.*?)\s*$/);
+                if (m && m[2] && !(m[1] in env)) env[m[1]] = m[2].replace(/^["']|["']$/g, '');
+            }
+        }
+
+        this._proc = spawn('node', [serverPath], { stdio: ['pipe', 'pipe', 'inherit'], env });
+
+        const rl = createInterface({ input: this._proc.stdout });
+        rl.on('line', (line) => {
+            if (!line.trim()) return;
+            try {
+                const msg = JSON.parse(line);
+                if (msg.id !== undefined && this._pending.has(msg.id)) {
+                    const { resolve, reject } = this._pending.get(msg.id);
+                    this._pending.delete(msg.id);
+                    if (msg.error) reject(new Error(msg.error.message ?? JSON.stringify(msg.error)));
+                    else resolve(msg.result);
+                }
+            } catch {}
+        });
+
+        this._proc.on('error', (err) => console.error('[MCP] error:', err.message));
+    }
+
+    _send(msg) { this._proc.stdin.write(JSON.stringify(msg) + '\n'); }
+
+    async initialize() {
+        const id = this._nextId++;
+        const p  = new Promise((res, rej) => this._pending.set(id, { resolve: res, reject: rej }));
+        this._send({ jsonrpc: '2.0', id, method: 'initialize', params: {
+            protocolVersion: '2024-11-05', capabilities: {},
+            clientInfo: { name: 'test-flow', version: '0.1.0' },
+        }});
+        await p;
+        this._send({ jsonrpc: '2.0', method: 'notifications/initialized', params: {} });
+    }
+
+    async callTool(name, args) {
+        const id = this._nextId++;
+        const p  = new Promise((res, rej) => {
+            this._pending.set(id, { resolve: res, reject: rej });
+            setTimeout(() => {
+                if (this._pending.has(id)) { this._pending.delete(id); rej(new Error(`Timeout: ${name}`)); }
+            }, 120_000);
+        });
+        this._send({ jsonrpc: '2.0', id, method: 'tools/call', params: { name, arguments: args } });
+        return p;
+    }
+
+    close() { this._proc.stdin.end(); }
+}
+
+// ── Helpers ───────────────────────────────────────────────────────────────────
+
+const extractText = (r) => r?.content?.filter(c => c.type === 'text').map(c => c.text).join('\n') ?? String(r);
+const sleep       = (ms) => new Promise(r => setTimeout(r, ms));
+
+function printSection(title, text) {
+    const line = '─'.repeat(60);
+    console.log(`\n${line}\n  ${title}\n${line}`);
+    console.log(text);
+}
+
+// ── Main ──────────────────────────────────────────────────────────────────────
+
+async function main() {
+    const flowKey = process.argv[2] ?? 'atencion-ticket';
+    const flowDef = FLOWS[flowKey];
+    if (!flowDef) {
+        console.error(`Unknown flow: ${flowKey}\nOptions: ${Object.keys(FLOWS).join(', ')}`);
+        process.exit(1);
+    }
+    if (!fs.existsSync(SERVER_PATH)) {
+        console.error(`Server not found:\n  ${SERVER_PATH}\nRun: npm install`);
+        process.exit(1);
+    }
+
+    console.log(`\nStarting orchestrator (soporte)...`);
+    console.log(`  Flow:   ${flowKey}`);
+
+    const client = new McpClient(SERVER_PATH);
+    try {
+        await client.initialize();
+        console.log('  MCP: connected ✓\n');
+
+        const runArgs = { config_path: CONFIG_PATH, task: flowDef.task };
+        if (flowDef.flow_id) runArgs.flow_id = flowDef.flow_id;
+        if (Object.keys(flowDef.payload).length > 0) runArgs.payload = flowDef.payload;
+
+        const startText = extractText(await client.callTool('orchestrator_run', runArgs));
+        printSection('RUN STARTED', startText);
+
+        const runIdMatch = startText.match(/runId:\s*`?([a-z0-9-]+)`?/i);
+        if (!runIdMatch) { console.error('\n[ERROR] Could not extract runId.'); process.exit(1); }
+        const runId = runIdMatch[1];
+
+        let attempts = 0, lastStatus = '';
+        console.log(`\nPolling (runId: ${runId})...\n`);
+
+        while (attempts < 80) {
+            await sleep(5000);
+            attempts++;
+
+            const statusText = extractText(await client.callTool('orchestrator_status', {
+                config_path: CONFIG_PATH, run_id: runId,
+            }));
+            const status = statusText.match(/status:\s*\*\*([^*]+)\*\*/)?.[1]
+                        ?? statusText.match(/^status:\s*(\S+)/m)?.[1]
+                        ?? 'unknown';
+
+            if (status !== lastStatus) {
+                process.stdout.write(`  [${new Date().toLocaleTimeString()}] status: ${status}\n`);
+                lastStatus = status;
+            }
+
+            if (status === 'complete') { printSection('RESULT', statusText); break; }
+            if (status === 'failed')   { printSection('ERROR', statusText); break; }
+
+            if (status === 'waiting_gate') {
+                printSection('GATE — APPROVAL REQUIRED', statusText);
+                console.log('\nAuto-approving...\n');
+                await sleep(2000);
+                const approveText = extractText(await client.callTool('orchestrator_approve', {
+                    config_path: CONFIG_PATH, run_id: runId,
+                    approved: true, notes: 'Auto-approved by test-flow.mjs',
+                }));
+                printSection('GATE APPROVED', approveText);
+                lastStatus = '';
+            }
+        }
+
+        if (attempts >= 80) console.log('\n[TIMEOUT] Check orchestrator_status manually.');
+    } finally {
+        client.close();
+    }
+}
+
+main().catch(err => { console.error('\n[FATAL]', err.message); process.exit(1); });

package/templates/base/orchestrator/soporte/vault/comunicacion/plantillas.md

@@ -0,0 +1,211 @@
+---
+title: Plantillas de Comunicación con Clientes
+tags: [plantillas, comunicacion, email, respuesta, cierre, escalacion, empatia]
+description: Templates reutilizables para las situaciones más frecuentes de soporte
+---
+
+# Plantillas de Comunicación con Clientes
+
+Usar estas plantillas como base y personalizar siempre con el nombre del cliente
+y los detalles específicos del caso. Una respuesta genérica es peor que una tardía.
+
+---
+
+## Respuesta inicial — Acuse de recibo
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID]
+
+Hola [Nombre],
+
+Recibimos tu ticket y ya lo tenemos en cola.
+
+Prioridad asignada: [P1/P2/P3/P4]
+Tiempo estimado de primera respuesta: [X horas/minutos]
+
+[Si es P1/P2]: Un miembro de nuestro equipo se está asignando ahora mismo a este caso.
+
+[Si necesitamos info adicional]: Para poder ayudarte más rápido, ¿podrías enviarnos:
+- [dato específico 1]
+- [dato específico 2]
+
+Seguimos en contacto.
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Respuesta con solución — L1
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID] [Resuelto]
+
+Hola [Nombre],
+
+Investigamos el problema que reportaste y encontramos la causa.
+
+**¿Qué estaba pasando?**
+[Explicación breve en términos del cliente, sin jerga técnica]
+
+**Cómo resolverlo:**
+1. [Paso 1]
+2. [Paso 2]
+3. [Paso 3]
+
+**Cómo verificar que funciona:**
+[Describir qué debe ver el cliente si la solución funcionó]
+
+Si seguís teniendo problemas o la solución no funciona en tu caso, respondé a este email
+y lo revisamos juntos.
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Escalación a L2 — Notificación al cliente
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID] [Actualización]
+
+Hola [Nombre],
+
+Quisimos darte una actualización sobre tu caso.
+
+Revisamos el problema y determinamos que requiere una investigación técnica más profunda
+por parte de nuestro equipo de ingeniería de soporte.
+
+**Próximo paso:** Un técnico especializado tomará el caso.
+**Tiempo estimado de respuesta:** [según SLA del plan]
+
+Mientras tanto, [si hay workaround: "podés usar este workaround temporal: [descripción]"].
+
+Te mantendremos informado de cada avance.
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Pedido de información adicional
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID] [Necesitamos más info]
+
+Hola [Nombre],
+
+Estamos investigando el problema. Para poder reproducirlo y encontrar la solución
+más rápido, necesitamos que nos ayudes con esta información:
+
+1. **[Dato específico 1]:** [explicar por qué lo necesitamos si no es obvio]
+2. **[Dato específico 2]:** [explicar por qué]
+3. **Pasos exactos para reproducir el problema:** [si no los tenemos]
+
+[Opcional: "Podés enviarnos capturas de pantalla o los logs de la consola del navegador
+(F12 → Console) si hay errores visibles."]
+
+Una vez que tengamos esta info, continuamos la investigación de inmediato.
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Actualización de incidente — Status update (template periódico)
+
+```
+Asunto: [INCIDENTE #ID] Actualización de estado — [HH:MM]
+
+Hola [Nombre / Lista de clientes afectados],
+
+Les compartimos una actualización del incidente que está afectando [descripción breve].
+
+**Estado actual:** [Investigando / Identificada la causa / Aplicando fix / En monitoreo]
+
+**Qué hicimos desde la última actualización:**
+- [Acción 1]
+- [Acción 2]
+
+**Próximos pasos:**
+- [Paso 1] — responsable: [rol]
+- [Paso 2]
+
+**Tiempo estimado de resolución:** [ETA actualizado o "Sin ETA confirmado aún, próxima actualización en X minutos"]
+
+Seguimos trabajando en esto. Próxima actualización: [hora].
+
+[Nombre]
+Equipo de Soporte / Operaciones
+```
+
+---
+
+## Cierre de ticket
+
+```
+Asunto: Re: [Asunto original] — Ticket #[ID] [Cerrado]
+
+Hola [Nombre],
+
+Confirmamos que el problema fue resuelto y cerramos el ticket.
+
+**Resumen de lo que pasó:**
+[2-3 líneas explicando el issue y la causa]
+
+**Cómo lo resolvimos:**
+[1-2 líneas con la solución aplicada]
+
+**Para que no vuelva a ocurrir:**
+[Si aplica: qué cambió o qué puede hacer el cliente para evitarlo]
+
+Si el problema vuelve a aparecer o tenés alguna pregunta adicional, respondé a este email
+y reabrimos el caso de inmediato.
+
+¿Pudimos ayudarte bien? Nos ayudaría mucho conocer tu opinión: [link encuesta CSAT]
+
+[Nombre del agente]
+Equipo de Soporte
+```
+
+---
+
+## Comunicado de apertura de incidente (público / status page)
+
+```
+**[INCIDENTE] Problemas con [nombre del servicio/módulo]**
+[Fecha] — [HH:MM] (UTC-3)
+
+Estamos investigando un problema que afecta a [descripción del impacto al usuario].
+Los usuarios pueden experimentar [síntomas concretos: errores, lentitud, etc.].
+
+Nuestro equipo está trabajando activamente en la resolución.
+Próxima actualización: [hora].
+```
+
+---
+
+## Comunicado de cierre de incidente (público / status page)
+
+```
+**[RESUELTO] Incidente en [nombre del servicio/módulo]**
+[Fecha] — [HH:MM] (UTC-3)
+
+El incidente fue resuelto a las [hora]. El servicio está funcionando con normalidad.
+
+**Duración total:** [X horas Y minutos]
+**Clientes afectados:** [descripción sin números exactos si es sensible]
+
+**Qué pasó:** [Descripción técnica accesible, sin exponer vulnerabilidades]
+
+**Qué hicimos:** [Acciones de resolución]
+
+**Para que no vuelva a ocurrir:** [Medidas preventivas]
+
+Pedimos disculpas por el inconveniente. Estamos comprometidos con [uptime objetivo].
+Si tenés preguntas, contactá a soporte: [email/portal].
+```

package/templates/base/orchestrator/soporte/vault/procesos/escalacion.md

@@ -0,0 +1,106 @@
+---
+title: Protocolo de Escalación
+tags: [escalacion, l1, l2, l3, incidente, protocolo, guardia]
+description: Cuándo y cómo escalar tickets e incidentes, con responsables y canales
+---
+
+# Protocolo de Escalación
+
+## Niveles de escalación
+
+### L1 → L2: Escalación Técnica
+
+**Cuándo:** ver criterios en manejo-de-tickets.md
+
+**Cómo:**
+1. Actualizar el ticket con todo el contexto recopilado
+2. Cambiar estado a ESCALADO_L2
+3. Asignar al equipo técnico (o al técnico de guardia si es P1/P2)
+4. Notificar al cliente: "Escalamos tu caso a nuestro equipo técnico especializado. Te contactaremos en [tiempo según SLA]"
+5. Hacer handoff verbal (Slack/Teams) para P1/P2
+
+**Información obligatoria en el handoff:**
+- Resumen del problema en 3 líneas
+- Pasos ya intentados y resultados
+- Información del entorno del cliente
+- Historial de tickets relacionados del mismo cliente
+- Nivel de urgencia y SLA restante
+
+---
+
+### L2 → L3: Escalación a Ingeniería
+
+**Cuándo:**
+- Bug confirmado en el código (no configuración)
+- Requiere acceso a producción con permisos de ingeniería
+- Issue de seguridad de cualquier tipo
+- Pérdida de datos confirmada
+- L2 lleva más de 2 horas sin avance en un P1
+
+**Cómo:**
+1. Crear un bug report en el sistema de issues de ingeniería (Jira/Linear/GitHub Issues)
+2. Incluir: steps to reproduce, expected vs actual, logs relevantes, impacto al cliente
+3. Vincular el bug al ticket de soporte
+4. Notificar al Engineering Manager con el bug report
+5. Mantener el ticket de soporte abierto y actualizar al cliente
+6. No cerrar el ticket hasta que ingeniería confirme el fix deployado
+
+---
+
+### Escalación a Dirección
+
+**Cuándo:**
+- Cliente Enterprise amenaza con churn o acciones legales
+- SLA incumplido por más de 2x el tiempo prometido
+- Incident P1 que afecta a más del 10% de la base de clientes
+- Issue de seguridad con posible exposición de datos de clientes
+- Segunda reapertura del mismo ticket por el mismo cliente
+
+**Quién notificar:**
+- Customer Success Manager (siempre)
+- Director de Customer Experience (si es Enterprise o impacto > 5 clientes)
+- CEO (solo si hay impacto reputacional, legal o de seguridad significativo)
+
+---
+
+## Guardia de incidentes P1/P2
+
+### Roles en guardia
+
+| Rol | Responsabilidad | Contacto |
+|-----|-----------------|----------|
+| Ingeniero de Guardia | Diagnóstico técnico y fix | [definir en tu empresa] |
+| CS Manager de Guardia | Comunicación con cliente y coordinación | [definir en tu empresa] |
+| Engineering Manager | Decisiones de arquitectura o rollback | [definir en tu empresa] |
+
+### Cómo activar la guardia (fuera de horario)
+1. Llamar al número de emergencias del Ingeniero de Guardia
+2. Si no responde en 5 minutos, llamar al Engineering Manager
+3. Abrir el canal de War Room en Slack: `#incident-[fecha]-[descripción-breve]`
+4. Invitar a CS Manager, Ingeniero de Guardia, y Engineering Manager
+
+### War Room — reglas
+- Un solo responsable de comunicación con el cliente (CS Manager)
+- Un solo responsable técnico de coordinar el fix (Ingeniero de Guardia)
+- Actualizar el canal cada 15 minutos con estado
+- No hacer cambios en producción sin anunciarlo en el canal con al menos 2 minutos de anticipación
+- Documentar todo en tiempo real (se usa para el postmortem)
+
+---
+
+## Postmortem
+
+### Cuándo es obligatorio
+- Todo incidente P1
+- Incidentes P2 que duraron más de 4 horas
+- Cualquier incidente donde el SLA fue incumplido significativamente
+- Bugs que causaron pérdida de datos aunque sea parcial
+
+### Cuándo realizarlo
+- Draft del postmortem: dentro de las 24 horas post-resolución
+- Review con el equipo: dentro de los 3 días hábiles post-resolución
+- Publicación (versión resumida para clientes): opcional, según impacto y política
+
+### Principio: postmortem blameless
+El objetivo es entender los sistemas y procesos, nunca culpar personas.
+Preguntar "¿por qué el sistema permitió que esto pasara?" en lugar de "¿quién cometió el error?".

package/templates/base/orchestrator/soporte/vault/procesos/manejo-de-tickets.md

@@ -0,0 +1,101 @@
+---
+title: Proceso de Manejo de Tickets de Soporte
+tags: [proceso, tickets, atencion, workflow, l1, l2, l3]
+description: Guía completa del proceso de atención desde la recepción hasta el cierre del ticket
+---
+
+# Proceso de Manejo de Tickets
+
+## Ciclo de vida de un ticket
+
+```
+NUEVO → EN_TRIAGE → EN_ATENCIÓN → ESPERANDO_CLIENTE → RESUELTO → CERRADO
+                          ↓
+                    ESCALADO_L2 → ESCALADO_L3 → RESUELTO
+```
+
+### Estados y sus significados
+
+| Estado | Significado | Quién puede cambiarlo |
+|--------|-------------|----------------------|
+| NUEVO | Ticket recibido, sin asignar | Sistema (automático) |
+| EN_TRIAGE | Siendo clasificado por triage-agent | Sistema / L1 |
+| EN_ATENCIÓN | Asignado y trabajando activamente | L1, L2, L3 |
+| ESPERANDO_CLIENTE | Pedimos info, esperamos respuesta | L1, L2 |
+| ESCALADO_L2 | Requiere investigación técnica | L1 |
+| ESCALADO_L3 | Requiere ingeniería o es incidente crítico | L2 |
+| RESUELTO | Solución entregada, pendiente confirmación del cliente | L1, L2, L3 |
+| CERRADO | Confirmado resuelto o 48hs sin respuesta tras resolución | Sistema / cliente |
+
+---
+
+## Canales de entrada y prioridad default
+
+| Canal | Prioridad default | Notas |
+|-------|------------------|-------|
+| Teléfono de emergencias | P1 automático | Solo Enterprise, fuera de horario |
+| Chat en vivo | P2 | Si el cliente dice que es urgente |
+| Email directo al CS Manager | P2 | Escalar a L2 inmediato |
+| Portal de soporte | Según formulario | El cliente selecciona la prioridad |
+| Email de soporte general | P3 | Default para consultas |
+| Redes sociales | P3 | Mover al portal oficial |
+
+---
+
+## Cuándo escalar a L2
+
+Escalar inmediatamente a L2 cuando:
+- El issue requiere acceso a logs del servidor o base de datos
+- La solución de KB no funcionó después de 2 intentos documentados
+- El cliente reporta pérdida de datos (aunque sea parcial)
+- El bug no está documentado y no hay workaround conocido
+- El cliente tiene plan Enterprise y lleva más de 1 hora sin solución para P2
+
+**Al escalar a L2:** incluir siempre en el ticket:
+1. Pasos ya intentados y sus resultados
+2. Información del entorno del cliente (versión, OS, navegador, etc.)
+3. Mensajes de error completos (no solo capturas de pantalla)
+4. Horario en que el cliente puede ser contactado
+
+---
+
+## Cuándo escalar a L3 / activar protocolo de incidente
+
+Activar el protocolo de incidente crítico cuando:
+- El issue afecta a más de 1 cliente simultáneamente con el mismo síntoma
+- Hay pérdida de datos confirmada o sospechada
+- El sistema está completamente caído (no solo degradado)
+- El issue tiene potencial impacto en seguridad
+- L2 lleva más de 2 horas sin encontrar el root cause en un P1
+
+---
+
+## Buenas prácticas de atención
+
+### Apertura del ticket
+- Responder siempre dentro del SLA aunque no tengamos solución
+- Si necesitamos tiempo para investigar, confirmarlo: "Recibimos tu ticket, estamos investigando y te respondemos en [tiempo]"
+- No decir "revisaremos tu caso" sin un tiempo concreto
+
+### Durante la investigación
+- Actualizar el ticket con cada hallazgo aunque no sea la solución
+- Si el cliente pregunta el estado, responder en menos de 1 hora durante horario hábil
+- Si el SLA está por vencerse, notificar proactivamente con un nuevo ETA
+
+### Cierre del ticket
+- Siempre preguntar si la solución resolvió el problema antes de cerrar
+- Esperar 48 horas la respuesta del cliente tras marcar como RESUELTO
+- Incluir siempre un resumen de qué pasó y cómo se resolvió (útil para la KB)
+- Invitar a completar la encuesta de satisfacción
+
+---
+
+## Métricas de calidad
+
+| Métrica | Objetivo | Crítico |
+|---------|----------|---------|
+| First Response Time (FRT) | Dentro del SLA 95% de los tickets | < 90% |
+| Resolution Time | Dentro del SLA 85% de los tickets | < 75% |
+| CSAT (Customer Satisfaction) | > 4.2 / 5.0 promedio mensual | < 3.8 |
+| First Contact Resolution (FCR) | > 70% de tickets L1 | < 60% |
+| Reapertura de tickets | < 5% | > 10% |

package/templates/base/orchestrator/soporte/vault/productos/coberturas-de-soporte.md

@@ -0,0 +1,94 @@
+---
+title: Coberturas de Soporte por Plan
+tags: [planes, cobertura, soporte, enterprise, professional, starter]
+description: Qué está incluido y qué no en cada plan de soporte
+---
+
+# Coberturas de Soporte por Plan
+
+## Plan Enterprise
+
+### Incluye
+- Soporte 24/7/365 para P1 y P2 por teléfono, email y chat
+- SLA garantizado con créditos por incumplimiento
+- Ingeniero de cuenta dedicado (Technical Account Manager)
+- Acceso a canal de Slack privado con el equipo de soporte e ingeniería
+- Revisiones técnicas trimestrales
+- Early access a nuevas funcionalidades
+- Capacitación del equipo (hasta 4 horas por trimestre)
+- Onboarding personalizado (hasta 20 horas)
+
+### No incluye
+- Desarrollo de features a medida (requiere contrato de desarrollo)
+- Integración con sistemas de terceros no documentados
+- Soporte a código personalizado no desarrollado por nosotros
+- Data recovery de datos eliminados por el cliente (evaluar caso a caso)
+
+---
+
+## Plan Professional
+
+### Incluye
+- Soporte en horario hábil (L-V 9:00-18:00) para todas las prioridades
+- Soporte fuera de horario para P1 únicamente (respuesta en 4 horas)
+- Portal de soporte con priorización
+- Acceso a base de conocimiento y documentación completa
+- Webinars mensuales de producto
+- Onboarding básico (hasta 4 horas)
+
+### No incluye
+- Soporte telefónico (solo email y portal)
+- TAM dedicado
+- Canal de Slack privado
+- Revisiones técnicas proactivas
+
+---
+
+## Plan Starter
+
+### Incluye
+- Soporte en horario hábil ART (L-V 9:00-18:00)
+- Portal de soporte con formulario de tickets
+- Acceso a base de conocimiento y documentación
+- Foro de comunidad de usuarios
+
+### No incluye
+- Soporte fuera de horario (ninguna prioridad)
+- Chat en vivo
+- Prioridad sobre otros tickets
+
+---
+
+## Qué nunca está incluido en ningún plan
+
+- Consultoría de arquitectura o diseño de soluciones (servicio separado)
+- Desarrollo o modificación de código del cliente
+- Soporte a versiones EOL (End of Life) — ver política de versiones
+- Recovery de datos si el cliente borró información hace más de 30 días
+- Soporte en idiomas distintos al español e inglés
+
+---
+
+## Política de créditos por incumplimiento de SLA (Enterprise)
+
+| Incumplimiento | Crédito |
+|---------------|---------|
+| FRT fuera de SLA en P1 | 5% del MRR del mes |
+| Resolution Time fuera de SLA en P1 | 10% del MRR del mes |
+| FRT fuera de SLA en P2 | 2% del MRR del mes |
+| Resolution Time fuera de SLA en P2 | 5% del MRR del mes |
+
+**Límite de créditos:** máximo 30% del MRR mensual por mes calendario.
+Los créditos se aplican en la próxima factura. No son transferibles ni canjeables por dinero.
+
+---
+
+## Versiones soportadas
+
+| Versión | Estado | Soporte hasta |
+|---------|--------|---------------|
+| v3.x (latest) | Activo — soporte completo | Indefinido |
+| v2.x | Mantenimiento — solo bugs críticos y seguridad | 31/12/2026 |
+| v1.x | EOL — sin soporte | Venció 31/12/2025 |
+
+Clientes en versiones EOL deben migrar para recibir soporte.

package/templates/base/orchestrator/soporte/vault/sla/niveles-de-servicio.md

@@ -0,0 +1,104 @@
+---
+title: Niveles de Servicio (SLA)
+tags: [sla, prioridad, tiempos, soporte, acuerdo]
+description: Definición de prioridades, tiempos de respuesta y resolución por plan y tier de soporte
+---
+
+# Niveles de Servicio (SLA)
+
+## Definición de Prioridades
+
+### P1 — Crítico
+**Definición:** Sistema o servicio completamente caído. Sin workaround disponible. Impacto en producción.
+
+**Ejemplos:**
+- Plataforma inaccesible para todos o gran parte de los usuarios
+- Pérdida de datos en producción
+- Brecha de seguridad activa
+- Funcionalidad de pago o facturación no disponible
+
+### P2 — Alto
+**Definición:** Funcionalidad core degradada. Hay workaround pero es significativamente limitante.
+
+**Ejemplos:**
+- Módulo principal con rendimiento muy degradado (> 5x más lento de lo normal)
+- Feature crítica del negocio no disponible para un segmento de usuarios
+- Integraciones clave caídas (pagos, autenticación)
+
+### P3 — Medio
+**Definición:** Bug o problema que afecta una feature no crítica. Hay workaround razonable.
+
+**Ejemplos:**
+- Error en un reporte o export que tiene alternativa
+- UI con comportamiento incorrecto pero funcional
+- Notificaciones no enviándose pero datos disponibles en la plataforma
+
+### P4 — Bajo
+**Definición:** Consulta, mejora sugerida, cosmético o comportamiento no esperado sin impacto operativo.
+
+**Ejemplos:**
+- Pregunta de "cómo hacer X"
+- Solicitud de nueva funcionalidad
+- Texto o label incorrecto en la interfaz
+
+---
+
+## Tiempos de Respuesta y Resolución por Plan
+
+### Plan Enterprise
+
+| Prioridad | Primera respuesta | Actualización de progreso | Resolución objetivo |
+|-----------|-------------------|--------------------------|---------------------|
+| P1 | 15 minutos | Cada 30 minutos | 4 horas |
+| P2 | 1 hora | Cada 2 horas | 8 horas hábiles |
+| P3 | 4 horas hábiles | Diaria si está abierto | 3 días hábiles |
+| P4 | 1 día hábil | Semanal | 10 días hábiles |
+
+**Horario de cobertura P1/P2:** 24/7/365
+
+### Plan Professional
+
+| Prioridad | Primera respuesta | Resolución objetivo |
+|-----------|-------------------|---------------------|
+| P1 | 1 hora | 8 horas hábiles |
+| P2 | 4 horas hábiles | 2 días hábiles |
+| P3 | 1 día hábil | 5 días hábiles |
+| P4 | 2 días hábiles | 15 días hábiles |
+
+**Horario de cobertura:** Lunes a viernes 9:00-18:00 (zona horaria del cliente)
+
+### Plan Starter
+
+| Prioridad | Primera respuesta | Resolución objetivo |
+|-----------|-------------------|---------------------|
+| P1 | 4 horas hábiles | 2 días hábiles |
+| P2 | 1 día hábil | 5 días hábiles |
+| P3 | 2 días hábiles | 10 días hábiles |
+| P4 | 5 días hábiles | Best effort |
+
+**Horario de cobertura:** Lunes a viernes 9:00-18:00 ART
+
+---
+
+## Cómputo del SLA
+
+- El reloj del SLA **empieza cuando el ticket se recibe**, no cuando es asignado
+- El SLA se **pausa** cuando esperamos información del cliente (estado: "Esperando cliente")
+- El SLA se **reanuda** cuando el cliente responde
+- El SLA **se cumple** cuando el cliente confirma resolución o cuando han pasado 48hs sin respuesta tras nuestra solución
+- Los **días feriados** del país del cliente no cuentan en planes Professional y Starter (sí cuentan en Enterprise P1/P2)
+
+---
+
+## Escalación por Incumplimiento de SLA
+
+Si el SLA está en riesgo (>75% del tiempo consumido sin resolución):
+1. Notificar al Team Lead de Soporte
+2. Escalar automáticamente a L2 si está en L1
+3. Notificar proactivamente al cliente con actualización de estado y nuevo ETA
+
+Si el SLA se incumple:
+1. Notificar al Director de Customer Success
+2. Registrar el breach en el sistema de métricas
+3. Analizar en la reunión semanal de soporte
+4. Evaluar compensación según política de créditos