- AutoMigrate migraba ~50 modelos en un solo llamado que se detiene en
el primer error, dejando todo lo posterior (plantillas_documento,
tarifas, documentos_generados, arquitecturas, telegram_staff_tokens)
sin tabla, en silencio. Ahora se migra modelo por modelo: uno roto
ya no bloquea al resto.
- /app/contabilidad/entidades pedía datos a la misma URL de la página
(devuelve HTML) en vez de /list (JSON) — el listado nunca traía nada.
- Mensaje de bienvenida del asistente: estaba generado por la IA cada
vez con calidad variable; ahora es determinístico para /ayuda y
/start, con redacción revisada, y el system prompt pide el mismo
formato cuando el usuario solo saluda.
Un archivo adjunto que no fuera PDF o imagen se mandaba igual como
bloque "image" a la API de Claude, que la rechaza (400) y tumbaba toda
la respuesta del agente. Ahora solo se intenta previsualizar tipos que
Claude soporta (PDF/jpeg/png/webp/gif); cualquier otro formato se
guarda igual con adjuntar_documento_tarea/proyecto/factura, solo que
la IA no puede leer su contenido, únicamente el nombre.
Antes solo facturas y documentos de proyecto consumían el adjunto
pendiente de Telegram; crear_tarea/asignar_tarea lo ignoraban. Agrega
adjuntar_documento_tarea: si el usuario manda un archivo junto con una
instrucción de tarea ("asigna esto a Natalia"), el agente crea/resuelve
la tarea y guarda el archivo como comentario adjunto, visible igual que
un adjunto subido desde /app/tareas.
- El agente creaba tareas con estado='pendiente' (default), pero el tablero
Kanban del dashboard solo reconoce por_hacer/en_progreso/revision/hecho. La
tarea se guardaba bien (por eso llegaba el correo de notificación) pero no
aparecía en ninguna columna. Se corrigen los enums y el default de las tools
crear_tarea/actualizar_estado_tarea, y se agrega una reparación única al
arranque que corrige las tareas ya creadas con el estado inválido.
- adjuntar_factura siempre asumía factura de VENTA (ligada a un cliente). Se
agrega adjuntar_factura_compra: cuando un proveedor le factura a U-SITE (no
al revés), busca/crea la Entidad proveedor y registra una cuenta por pagar
con el documento adjunto (se agregan campos archivo/original_name/tipo_mime
a CuentaPagar, que no los tenía). El prompt del sistema instruye a Claude a
decidir la dirección leyendo quién emite y quién recibe el documento.
De paso: endpoint de descarga del soporte de la factura de compra, expuesto
también en el dashboard (/app/contabilidad/cuentas-pagar).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seguridad (crítico):
- Los webhooks de Bold y dLocal solo validaban la firma si el atacante la
enviaba: sin cabecera se aceptaba cualquier payload. Ahora es obligatoria.
- GET /pago-exitoso marcaba contratos como pagados leyendo un query param del
navegador. Ahora solo muestra estado; la confirmación la hace la verificación
contra la API de la pasarela o el webhook firmado.
- /uploads se servía como estático público: se descargaban RUTs, facturas y
entregables sabiendo la ruta. Ahora exige sesión.
- Los secretos JWT no se podían sobreescribir por entorno (faltaba el tag env:)
y su valor estaba en el repo, permitiendo firmarse una sesión de admin. Ahora
son configurables y el arranque se detiene si siguen con el valor publicado.
- .env y session.db salen del control de versiones.
- Query Runner, gestión de usuarios/roles/módulos y seeds quedan restringidos a
administradores; antes bastaba con tener sesión.
Pasarelas de pago:
- dLocal generaba enlaces que nunca se reconciliaban: mandaba el ID numérico en
vez de "contrato-N", la URL de retorno apuntaba a la API de dLocal y nunca se
enviaba notification_url, así que su webhook jamás se disparaba.
- PayPal solo tenía pantalla de configuración. Se implementa el servicio
completo (OAuth, orden, captura, verificación de webhook) y queda
seleccionable como pasarela.
- La moneda estaba fija en COP: un contrato en USD generaba un cobro por esa
cifra en pesos.
Contratos:
- pago_confirmado nunca volvía a false, así que el segundo ciclo de renovación
no se cobraba aunque el cliente pagara. Se reinicia al generar enlace nuevo.
- Los contratos vencidos nunca cambiaban de estado y recibían correo a diario
de forma indefinida; ahora se cierran tras 30 días de gracia.
Otros:
- Coolify: coolifyCall ignoraba el status HTTP y reportaba errores como éxito.
El agente pasa de 10 a cobertura completa (servicios, bases de datos,
variables de entorno, proyectos, equipos y recursos de servidor).
- SeedBalanceData ya no corre en cada arranque (recreaba transacciones
borradas); ahora se invoca con SEED_BALANCE=1.
- Los seeds dejan de devolver permisos revocados en cada despliegue.
- Timeouts en las llamadas HTTP a Telegram y dLocal que podían colgarse.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El bot manda mensajes con parse_mode=HTML, pero la IA responde en Markdown
(##, **negrita**, listas con "-", separadores ---), que Telegram no
interpreta — salía todo literal con los símbolos. Ahora FormatearParaTelegram
convierte el Markdown a las etiquetas que Telegram sí soporta (b, code, pre,
a) justo antes de enviar, escapando cualquier < > & literal para que
sendMessage tampoco falle por HTML inválido. Se ajustó el único lugar que ya
armaba HTML a mano (/instancias) para que use el mismo formato Markdown y
pase por el mismo conversor. Incluye tests con el caso real reportado.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- crear_fase_proyecto: agrega fases/etapas a un proyecto (se puede llamar
varias veces seguidas para cargar todas las fases de un proyecto nuevo).
- adjuntar_documento_proyecto: guarda el archivo que el usuario acaba de
enviar por Telegram como documento del proyecto (mismo mecanismo de
adjuntos ya usado para facturas — se generalizó TelegramAttachment para
servir a ambos casos).
- listar_usuarios + asignado_id en crear_tarea + asignar_tarea: permite
asignar tareas a alguien del equipo por Telegram, disparando la misma
notificación (Telegram/email/sistema) que ya dispara el dashboard.
- El prompt del sistema ahora indica cómo decidir entre adjuntar_factura y
adjuntar_documento_proyecto según el contexto del archivo recibido.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Antes solo se avisaba en texto "llegó un documento" — la IA nunca veía el
archivo, por eso siempre tenía que preguntar cliente y monto. Ahora, cuando
el proveedor activo es Anthropic, se le adjunta la imagen/PDF real (base64)
al mensaje para que Claude lo lea directamente y extraiga cliente, monto y
número de factura, llamando a adjuntar_factura sin pedir confirmación salvo
que de verdad no pueda determinar cliente o monto.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
El bot solo procesaba mensajes de texto: un documento o foto enviado al chat
se ignoraba por completo (Telegram lo manda en message.document/photo con
caption, no en el campo text). Ahora el webhook detecta el adjunto, lo
descarga desde la API de Telegram y lo deja pendiente para el chat; el agente
usa la nueva tool adjuntar_factura para asociarlo a un cliente (preguntando
cliente/monto si el caption no los trae) y crear la Factura con el archivo ya
vinculado, igual que si se subiera desde el dashboard.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Implementa las 4 fases de la especificación de automatización: módulo de
plantillas/tarifas editable por el equipo, generación de PDF (HTML+JS vía
Chrome headless) para cotizaciones/contratos/arquitecturas/cuentas de cobro,
chat propio en el dashboard reutilizando el mismo motor y tools del bot de
Telegram, y nuevas tools del agente para crear estos documentos end-to-end.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Los tool_calls y tool_results intermedios (JSON crudo de listas) se
mantenían en BD y se reenviaban a la IA en cada turno, consumiendo
la mayoría de tokens sin aportar contexto nuevo.
Ahora solo se persisten mensajes user y la respuesta final assistant.
Los datos de herramientas viven únicamente en memoria durante el round
actual. También se reduce el límite de historial de 20 a 10 mensajes.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cuando el agente hacía múltiples rondas de herramientas, los mensajes
del asistente con tool_calls se guardaban como JSON en Content. Al
recargar el historial, ToolCalls quedaba nil y Anthropic recibía
tool_result sin el tool_use correspondiente → error 400.
Ahora se detecta si Content es un array JSON y se deserializa de vuelta
a []agentToolCall antes de enviarlo a la API.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Agrega callAnthropicAI() que convierte mensajes y herramientas al formato
nativo de Anthropic Messages API (tool_use / tool_result), con conversión
de vuelta al formato interno OpenAI para mantener el historial unificado.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Coolify: soporte multi-instancia (CRUD de configs, ?config_id= en todos
los endpoints, endpoints expandidos para services/databases/teams/envs)
- AiConfig: campos es_agente_bot + telegram_config_id para marcar qué
config de IA actúa como cerebro del bot administrador
- TelegramAgentHistory + TelegramAgentAuth: historial de conversación por
chat_id y whitelist de chats autorizados
- Agent Engine: function calling OpenAI-compatible con 25+ herramientas
(clientes, contratos, contabilidad, proyectos, tickets, tareas,
Coolify multi-instancia, servidores, monitores URL)
- Webhook POST /webhooks/telegram-agent/:bot_token (público, sin sesión)
- API /api/v2/agent/auth y /api/v2/agent/history para administrar el agente
- AutoMigrate: AiConfig, TelegramAgentHistory, TelegramAgentAuth
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Lizandro GD