Dos de las cuatro mejoras de la auditoría del agente.
1. Las herramientas aceptan cliente_nombre además de cliente_id.
De 27 parámetros que eran IDs, 10 eran de cliente. Para cada acción el
modelo tenía que encadenar: listar_clientes → leer la respuesta →
encontrar la fila → extraer el número → recién ahí llamar a la
herramienta. Cuatro pasos, y basta que falle uno para que no se guarde
nada — es la explicación más probable de la factura que nunca se creó,
porque ese cliente podía no venir en la primera página del listado.
Ahora el modelo pasa el nombre y el servidor lo resuelve, con búsqueda
completa y no paginada. Si hay varios candidatos devuelve la lista para
que el modelo pregunte cuál, en vez de elegir uno: cargarle una factura
a la empresa equivocada es peor que preguntar. Una coincidencia exacta
gana sobre las parciales, así "Metropolitana" no queda ambiguo solo
porque existe "Metropolitana Norte".
2. Contadores de uso y fallo por herramienta, expuestos como
estado_herramientas.
Cada problema se venía diagnosticando de a un caso, reconstruyendo qué
pasó después de que el usuario avisara. Ahora se puede preguntar
directamente qué viene fallando y ver si es una herramienta puntual o el
modelo eligiendo mal. En memoria a propósito: alcanza para responder eso
y no agrega una tabla.
Quedan las otras dos: adelgazar el prompt de 5,4 KB moviendo los manuales
por dominio a las descripciones de las herramientas, y comparar modelos con
un mismo caso. La primera conviene hacerla con el sistema estable, porque
toca cómo decide el modelo en todos los flujos a la vez.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Confirmado que la factura nunca se creó: la lista de /app/facturas no
filtra nada que pudiera esconderla. La herramienta falló y el modelo
informó "FACTURA GUARDADA EXITOSAMENTE" igual.
El commit anterior le prohíbe eso por prompt, pero un prompt es una
sugerencia. Esto es la garantía: el código junta los errores que
devolvieron las herramientas durante la conversación y los agrega a la
respuesta. Si algo no se completó, se ve, diga lo que diga el modelo.
No reemplaza al prompt — el modelo sigue debiendo explicar el fallo con
sus palabras. Es la red por debajo, para que un "guardado exitosamente"
sobre algo que no se guardó no pueda pasar desapercibido otra vez.
Sigue sin saberse por qué falló aquella vez, porque hasta hoy el resultado
de las herramientas no se registraba. Con el log y este aviso, el próximo
intento lo va a decir en el momento.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Auditoría de qué expone /api/v2 contra qué puede hacer el bot. El bot no
llama a la API: usa su propio registro de herramientas, así que la API
puede crecer y el bot queda atrás sin que nada lo señale.
De 46 herramientas contra ~300 endpoints de v2, el hueco más caro estaba
en el flujo que se estuvo usando hoy:
- Se podían crear cuentas por cobrar y por pagar, pero no marcarlas
pagadas — y marcar pagado es justamente lo que genera la transacción en
contabilidad. O sea que el bot podía registrar deuda pero nunca cerrarla.
- No había forma de corregir una factura mal cargada, que es exactamente lo
que hacía falta después del bug del monto en cero.
Se agregan actualizar_factura, marcar_cuenta_cobro_pagada y
marcar_cuenta_pagar_pagada. actualizar_factura solo pisa los campos que
vinieron, así que corregir el monto no borra el número ni el concepto.
Quedan sin herramientas áreas enteras que v2 sí cubre (hostinger,
cloudflare, websms, portal-usuarios, uMind, api-keys, saas, plantillas).
No se agregan a ciegas: cada herramienta ocupa lugar en el prompt y
compite por la atención del modelo, así que conviene sumarlas cuando haya
un uso real detrás.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Por qué no aparecía la factura: la única herramienta de venta del bot era
adjuntar_factura, y exige un documento pendiente en el chat. Al dictarle
los datos por texto el modelo no tenía con qué guardar — y como el prompt
tampoco se lo prohibía, informó "guardada exitosamente" sobre algo que
nunca se creó.
/api/v2/facturas ya permitía crearlas, pero el bot no llama a la API REST:
usa su propio registro de herramientas, así que solo puede hacer lo que ese
registro expone. El hueco estaba ahí, no en la API.
crear_factura toma cliente_id y monto (obligatorios), número, concepto y
fechas. Devuelve el monto realmente guardado y el id, que es lo que el
prompt le exige informar en vez de repetir lo que dijo el usuario.
Las descripciones de las dos herramientas se remiten entre sí para que el
modelo no elija la equivocada: con documento adjunto va adjuntar_factura,
con datos dictados va crear_factura. El test verifica esa distinción,
porque elegir mal reproduce exactamente el fallo original.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
El bot informó "FACTURA GUARDADA EXITOSAMENTE" con $290.000 y el registro
no aparecía. Revisando el camino salieron tres cosas, y las tres explican
por qué el mensaje del bot no se podía tomar como prueba de nada.
1. Los montos se leían con getInt, que solo acepta números JSON. Si el
modelo manda el monto como texto ("290000", "$290.000") devuelve el
valor por defecto: 0. Y con decimales los truncaba. La factura quedaba
creada en cero mientras el bot informaba el monto correcto, porque el
bot repite lo que dijo el usuario, no lo que se guardó. Ahora hay un
getFloat que acepta número o texto y limpia $ , y espacios.
2. Se registraba la llamada a la herramienta pero no su resultado, así que
no había forma de saber si guardó o devolvió error. Ahora se registra
también el resultado: es la única fuente confiable de qué pasó, porque
el mensaje del bot lo escribe el modelo.
3. El prompt no prohibía informar éxito sin haberlo verificado. Ahora se
le exige no decir que guardó algo si la herramienta devolvió error, y
confirmar con los valores que devolvió la herramienta y no con los que
dijo el usuario.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Es la base del cobro por uso: hasta ahora no había ninguna medición de
consumo en todo el repo.
- UmindUso registra cada evento facturable con el costo YA calculado al
precio vigente del plan. Congelarlo evita que subir un precio revalúe
consumo pasado, que haría indefendible una factura ante un reclamo.
- callAI devuelve los tokens que reportó el proveedor (campo usage, igual
en todos los OpenAI-compatibles; input+output en Anthropic). Se mide
cada ronda de tool-calling, no solo la última: todas gastan tokens.
- ExtraerTextoOCR y TranscribirAudioSelfHosted reciben agenteID; 0 = no
medir, que es lo que pasan los botones "Probar" del panel de staff.
- Aviso al superar el tope del plan, una vez por mes y sin cortar el
servicio. El flag de "ya avisé" es en memoria a propósito.
- GET /app/umind/uso con filtros de fecha: resumen por tipo + detalle.
- Test del cálculo de costo por tipo, incluida fracción de 1k tokens y
tenant sin plan.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Prepara el terreno para que el cliente cargue su propia cuenta de IA sin
que su clave quede en texto plano ni que el selector le muestre las de
los demás.
- ClaveEnClaro() descifra con fallback a texto plano: las filas viejas se
leen igual y quedan cifradas al primer guardado, sin script ni downtime.
utils.Decrypt hace panic (no devuelve error) con entrada que no es un
ciphertext válido, así que el fallback va sobre recover — eso mismo es
el mecanismo de detección de "todavía está en claro".
- Migrados TODOS los lectores: uMind (chat y embeddings), bot de Telegram,
Whisper, Query Runner, streaming de IA y Landing Generator. Un lector
sin migrar mandaría el ciphertext como API key.
- AiConfig gana TenantID (null = global del staff) y
GetAiConfigSelectPorTenants para acotar el selector.
- Test de los 4 casos del fallback, incluido hex válido que no descifra.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gemini (modelos "thinking" como 2.5) exige que el tool_call se reenvíe con
su thought_signature intacto en la ronda siguiente, o rechaza con 400
"Function call is missing a thought_signature". Nuestro parseo a
agentMessage/agentToolCall no conocía ese campo y lo descartaba en el
unmarshal, así que cualquier tool call con Gemini fallaba apenas el modelo
pedía usar una herramienta (buscar_conocimiento incluida).
agentMessage ahora guarda los bytes JSON originales cuando se parsea de una
respuesta (UnmarshalJSON) y los reenvía tal cual al volver a serializar
(MarshalJSON) — preserva thought_signature u otro campo propietario que
llegue, sin que el código necesite conocer su nombre/forma exacta. Los
mensajes que armamos nosotros (user/tool/system) no llevan Raw y siguen
serializando normal. Afecta tanto a uMind como al agente de Telegram, que
comparten este mismo motor.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
El fix anterior de Gemini (22efb9c) solo tocó providerDefaultURL, que usan
el chat/embeddings/whisper reales. TestAiConfigHandler (el botón "Probar
conexión" del panel de AI Config) tenía una tercera copia independiente del
mismo mapeo, sin caso para Gemini ni Deepseek — por eso el chat ya
funcionaba con Gemini pero la prueba de conexión seguía fallando.
Se exporta providerDefaultURL a services.ProviderDefaultURL y el controller
la reusa, en vez de mantener una copia más que se desactualiza cada vez que
se agrega un proveedor.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- providerDefaultURL no tenía caso para "gemini": sin Base URL manual caía
al default (la URL de OpenAI) y fallaba siempre con la API key de Google.
Se agrega la capa de compatibilidad OpenAI de Gemini
(generativelanguage.googleapis.com/v1beta/openai).
- El widget muestra el texto del agente tal cual (textContent, no innerHTML
— deliberado, evita XSS si algo del contenido crawleado se cuela en una
respuesta). El modelo respondía con **negrita** y listas en Markdown que
se veían como asteriscos/guiones sueltos en vez de renderizarse. Se
instruye al system prompt a no usar Markdown, en vez de sumar un parser
al widget. Aplica a los tres canales (widget, Telegram, WhatsApp) y al
chat de prueba del panel, porque todos comparten el mismo prompt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- El bot solo tenía listar_tareas (resumen: título/estado/prioridad),
sin forma de pedir la descripción completa ni el historial de
comentarios de una tarea puntual. Nuevo tool detalle_tarea trae la
tarea completa + comentarios (autor, contenido, adjuntos, fecha).
- UMIND_CASOS_DE_USO.html: documento comercial con casos de uso por
tipo de negocio, argumentos de venta y límites actuales del
producto, para ofrecer uMind a clientes.
- 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>
