Reporte para Frank · 2026-04-27

Lo que cambió esta noche en el sistema PMO

Un cambio estructural para que cuando el bot diga "✅ aprobado", esté respaldado por validación real contra TUS registros — no por declaración del agente.

Por: Roberto Estado: En main, listo para activar Tests: 102 → 123

Lo que escuchamos de tu lado

Tus reclamos sobre LAP-271, 256 y 273 tenían razón. El bot estaba declarando "aprobado" usando cuentas vacías de prueba — no tus registros reales. Es exactamente la falla estructural que llamamos "QA Theater": validación que parece seria pero pasa trivialmente porque la data de prueba no triggerea los bugs que tú sí encuentras con LPDI PYME y LPDI SCALEUP.

Reconocimiento explícito: tu patrón de reportar con caps-lock, LAP refs claros y screenshots ha sido la herramienta más efectiva que tenemos para detectar este tipo de fallas. Ese patrón queda igual — no cambies nada de cómo reportas.

Lo que construimos (en castellano sencillo)

Tres piezas independientes que juntas hacen imposible que el bot declare "aprobado" sin pasar por una validación real contra tu data.

📒

Un registro persistente de tus reportes

Cada vez que reportas algo en Slack, queda guardado en un "ledger" propio. Si no se cierra con tu confirmación explícita, el bot no puede decir que un LAP está listo.

🎯

Validación contra tus registros reales

El sistema corre tests automáticos contra LPDI PYME y LPDI SCALEUP — no contra cuentas vacías. Si los puntajes en sidebar, formulario detallado y perfil público no coinciden, el test falla y el bot bloquea el cierre.

🚦

Un gate determinista antes del "✅"

Para que el bot declare un LAP aprobado, el sistema verifica automáticamente: que no haya reportes abiertos tuyos, que existan fixtures reales, y que el test diferencial pase. Si una sola condición falla, el bot publica 🚫 con el motivo.

🔍

Un revisor previo a publicar

Antes de que cualquier mensaje del bot llegue a Slack, un chequeo automático verifica que si menciona un LAP con reporte abierto tuyo, la respuesta lo reconozca explícitamente. Si no, lo bloquea y reescribe.

El bug que cazamos esta misma noche

No es teoría. La primera corrida del nuevo sistema contra producción detectó automáticamente un bug real en tu cuenta de LPDI SCALEUP que LAP-273 no había arreglado del todo. Lo arreglamos y lo verificamos en vivo.

Antes

LPDI SCALEUP divergente

Sidebar: 19%  ·  Form detallado: 19%  ·  Perfil público: 27%

Mismo registro, dos puntajes distintos. Exactamente el patrón que reportabas en LAP-273.

Después

LPDI SCALEUP unificado

Sidebar: 19%  ·  Form detallado: 19%  ·  Perfil público: 19%

Mismo registro, mismo puntaje en las tres pantallas. Verificado en vivo contra eco.lpdi.co.

El sistema lo tomó del mismo modo en que tú lo habrías reportado con un screenshot — pero esta vez sin que tengas que hacerlo. Este será el patrón a futuro: los bugs los caza el sistema antes que tú.

Lo que vas a notar diferente

Tres cambios concretos en la conducta del bot que comenzarás a ver a partir de tu próximo requerimiento.

pmo_agent
✅ LAP-X aprobado. Evidencia: storage/gate_evidence/LAP-X/2026-04-28T03:15:00Z.json

↑ Ahora cada "aprobado" viene con un path a la evidencia real. Roberto puede mostrártela si dudas.

pmo_agent
🚫 LAP-X no puede cerrarse: 1 open issue(s) in ledger for LAP-X

↑ Si tú reportaste algo y no lo confirmaste como cerrado, el bot físicamente NO PUEDE declarar el LAP aprobado.

pmo_agent
🚫 LAP-X no puede cerrarse: diff_test failed: 1 fixture(s) diverged

↑ Si los puntajes en tus pantallas no coinciden, el bot lo detecta antes de declarar nada y bloquea.

Cómo puedes ayudarnos

Tres pequeñas cosas — ninguna te cambia el flujo de trabajo, sólo lo hacen más eficiente para el sistema.

Mantén tu patrón de reporte

Caps-lock cuando es urgente, screenshots cuando puedas, mención explícita del LAP. Eso entra al ledger automáticamente y permite que el sistema cace el bug antes de que vuelvas a verlo. No cambies nada.

Cuando algo se arregla, di "CONFIRMO LAP-X"

Una palabra clara — CONFIRMO LAP-X, OK LAP-X o cerrado LAP-X — le permite al sistema marcar tu acknowledgement y liberar el LAP del gate. Sin tu confirmación, el issue se queda abierto en el ledger por diseño.

Si dudas de un "✅", pide la evidencia

Ahora cada aprobación viene con un path a un JSON que muestra los puntajes per-pantalla de tus registros reales. Si no estás seguro, siempre puedes contradecir al bot y el ledger se mantiene como fuente de verdad — tus reportes pesan más que sus declaraciones.

Recomendación adicional (entre tú y Roberto)

Sobre reaccionar al bot cuando ves algo raro: sigue escribiendo en caps-lock cuando estés frustrado — es la señal más clara que tenemos. Pero si puedes agregar el LAP-N específico al inicio del mensaje, el sistema lo agarra todo y reduce el tiempo en que Roberto tiene que parsear lo que pasó. Algo como "LAP-273: NO QUEDÓ BIEN, MIRA ESTE SCREENSHOT" es ideal.

No es exigencia — el parser ya entiende variantes como NI 273 NI 256 SE RESOLVIERON, LAP 257?, o frases sin LAP explícito. Pero con el LAP al inicio, el sistema tarda milisegundos menos en clasificar y la respuesta es más rápida y precisa.

Lo que NO necesitas cambiar: tu intensidad cuando algo no anda, tu hábito de pedir evidencia, tu costumbre de mandar screenshots. Todo eso es exactamente lo que el sistema necesita para funcionar bien.

Próximos pasos

Roberto activará el sistema progresivamente, un LAP a la vez, observando cómo responde. Esperar 3 a 5 días viendo el comportamiento en producción antes de que sea el default.

Si en cualquier momento ves un comportamiento raro — el bot diciendo "aprobado" cuando no debería, o bloqueando algo que sí está bien — lo reportas como siempre. El sistema mantiene tu palabra como fuente de verdad y Roberto puede ajustar manualmente.