Medios de Pago Automáticos
+ Fix 504 Scan de Licencias

Estado del sistema tras los dos cambios del día 2026-09-25

FOLIO: AUD-20260925-010 Secuencia: Auditoría #010 del día 2026-09-25

📅 2026-09-25 23:55:00 COT 👤 Auditor: Anderson Mares (AMR TECH) ● VIGENTE

Resumen Ejecutivo

2

Funcionalidades entregadas

1

Bug crítico resuelto (500)

3

Ramas actualizadas

💳

Fix 1 — Medios de Pago automáticos en el AI

NUEVO

Problema anterior

La regla 11 del prompt decía "NUNCA inventes datos de pago — Anderson los enviará manualmente". El AI respondía siempre con "Te comparto los datos en un momento" y se detenía, requiriendo intervención manual en cada venta.

Solución implementada

Se agregó bloque [MEDIOS DE PAGO DISPONIBLES] inyectado dinámicamente desde ai_settings.payment_methods en la BD.
Se actualizaron reglas 11 y 15: el AI ahora envía directamente Bancolombia, Nequi y Wompi al cerrar la venta.
Si el bloque está vacío (sin medios configurados), el AI sigue el flujo anterior manual.
Los QR y links de pago configurados en el tab "Medios de Pago" se incluyen en el mensaje.

Archivo modificado

whatsapp-crm/src/AIService.php — función determineSystemPrompt()

⏱️

Fix 2 — 504 Gateway Timeout en Scan de Licencias

CORREGIDO

Causa raíz

El botón "Escanear" enviaba 1 sola petición POST que ejecutaba hasta 40 requests cURL en serie (8 modelos × 5 keys × 12s timeout = hasta 480s). Hostinger corta conexiones a ~30s → 504.

Solución implementada

Nueva acción models: devuelve la lista de modelos y keys sin hacer ningún test (instantánea).
Nueva acción quicktest: testa exactamente 1 modelo × 1 key por request (máx ~6s, nunca supera el timeout).
Frontend itera todas las combinaciones con barra de progreso 3/40, 4/40…
Timeout cURL reducido de 12s → 6s como protección adicional.
Cada resultado parcial se guarda en caché en la BD para no perder progreso.

Archivos modificados

whatsapp-crm/public/audit_licenses.php — acciones models + quicktest
whatsapp-crm/public/config.php — función JS licScan()

🔴

Incidente — HTTP 500 en config.php

RESUELTO

Causa

Los deploys via rsync apuntaban a public_html/whatsapp-crm/ (raíz del proyecto) en vez de public_html/whatsapp-crm/public/ (web root real). El archivo config.php incorrecto en la raíz shadowed la rewrite de Apache, causando 500 por auth.php inexistente.

Solución

Los archivos incorrectos en la raíz fueron sobrescritos con stubs de reenvío chdir + require.
Todos los deploys futuros van a whatsapp-crm/public/ (documentado en memoria del agente).

Estado del sistema tras esta auditoría