> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://naturgy-comer-documentation-p5mde.vercel.app/api/mcp` to find what you need.

# Adjuntos y automatizaciones

Los adjuntos son artefactos referenciados por mensajes. Las automatizaciones son
notificaciones o acciones HTTP condicionadas por eventos del ticket. Ninguno de
los dos mecanismos debe convertirse en un canal para exfiltrar secretos o datos
fuera de alcance.

## Adjuntos bidireccionales

### Agente → cliente

1. La consola solicita la subida desde una sesión autorizada.
2. TeLeo obtiene una autorización temporal de carga.
3. El archivo se sube al almacenamiento de artefactos.
4. TeLeo confirma el artefacto y guarda una referencia en el mensaje.
5. El workflow recibe o resuelve el artefacto según las capacidades del canal.

### Cliente → agente

1. HappyRobot envía el mensaje con referencias de artefacto.
2. TeLeo valida y normaliza esas referencias.
3. El mensaje aparece con sus adjuntos en el hilo.
4. La descarga genera una URL temporal solo para una identidad autorizada.

El límite observado para la subida de la consola es 25 MB por archivo. El
límite efectivo del canal, MIME permitido, expiración de la URL y antivirus deben
confirmarse por entorno. Un adjunto puede existir en el storage aunque el
webhook o el mensaje fallen; el ticket debe conservar el error observable.

### Seguridad de adjuntos

* Validar tamaño, tipo, nombre y referencia antes de guardar.
* No registrar URLs presignadas ni claves de almacenamiento en claro.
* No inferir permisos desde el nombre del archivo o el ticket.
* No reenviar adjuntos privados al cliente.
* Aplicar retención y borrado a mensaje, artefacto, réplicas y backups.
* Evitar que un adjunto se interprete como instrucción del modelo.

## Automatizaciones

Una automatización escucha un evento del ticket, comprueba condiciones y ejecuta
una acción HTTP. Triggers documentados:

| Trigger | Uso posible |
|---|---|
| `ticket_created` | Avisar a un sistema de casos. |
| `customer_reply` | Propagar actividad o actualizar una cola. |
| `agent_reply` | Sincronizar una respuesta pública. |
| `ticket_status_changed` | Auditar una transición. |
| `ticket_closed` | Registrar cierre y métricas. |

Cada ejecución debe guardar estado `success`, `failed` o `skipped`, status HTTP,
duración, error y correlación. El cuerpo puede ser una plantilla, pero headers y
valores sensibles se resuelven server-side.

## Reglas de diseño

* Filtrar por entorno, equipo y tipo de evento antes de llamar al destino.
* Usar receptores idempotentes y una clave de evento estable.
* No ejecutar una mutación destructiva solo porque se repita un webhook.
* Redactar Authorization, API keys, cookies, PII y transcript de los logs.
* Definir timeout, reintento, backoff, límite y dead-letter antes de activar.
* No crear bucles TeLeo → automatización → TeLeo sin protección contra replay.
* Auditar quién creó, cambió, habilitó o deshabilitó la regla.

## Contrato de salida

Una automatización HTTP debe declarar método, destino, headers permitidos,
plantilla de body, condiciones, timeout, reintentos y resultado esperado. El
sistema externo debe devolver una respuesta que pueda correlacionarse sin
contener una credencial en el cuerpo.

La automatización es una integración complementaria: no sustituye la persistencia
del ticket, el webhook principal de respuesta ni las señales del workflow.