bug-manager

Bug Manager es una demostración basada en el navegador y totalmente simulada de gestión agéntica de errores, publicada como el complemento público de un caso de estudio. Nada de la demostración escanea código real, llama a un modelo de lenguaje ni realiza una solicitud de red: cada repositorio, hallazgo, pull request y ticket se genera en el navegador, y una semilla fija produce siempre los mismos 156 hallazgos. Qué muestra la demostración - Los agentes escanean doce repositorios ficticios y clasifican lo que encuentran. - Por cada hallazgo que el agente puede corregir, abre un pull request con una corrección propuesta y registra un ticket. - Luego, un equipo trabaja en la lista clasificada a lo largo de un único sprint. Ejecutarlo El proyecto incluye un pequeño servidor estático sin paso de instalación y sin dependencias: python3 serve.py # http://0.0.0.0:8430/ python3 serve.py --port 9000 # otro puerto Solo se sirve el directorio public/, las listas de directorios están desactivadas y el servidor envía una Content-Security-Policy estricta. Se incluye una unidad de usuario de systemd para mantenerlo en ejecución, con lingering activado para que el servicio arranque al encender el equipo. Como el servidor acepta cualquier encabezado Host, un proxy inverso puede asignarle directamente un nombre de dominio. Todas las URL de los recursos son relativas, así que public/ también puede colocarse en cualquier carpeta de un host estático. Estructura - public/index.html — la estructura de la app (barra superior, barra de estado, tarjetas, espacio de trabajo, panel lateral, diálogo About) - public/assets/app.js — generador de datos, escaneo, clasificación, filtros, panel lateral, sprint de burn-down - public/assets/app.css — todos los estilos, temas claro y oscuro, sin fuentes externas - public/assets/theme-init.js — aplica el tema guardado o el tema del sistema antes del primer pintado - serve.py — servidor estático con una Content-Security-Policy estricta - bug-manager.service — unidad de usuario de systemd La app es autónoma: no carga fuentes, scripts ni imágenes de otro origen, y la CSP (default-src 'self', connect-src 'none', sin estilos en línea) lo exige. Uso - La app se abre con un escaneo completado; Run scan repite el escaneo desde cero. - Al hacer clic en un repositorio se filtran los hallazgos; al hacer clic en un hallazgo se abre un panel de detalles con código, razonamiento, pull request, ticket y explicación de la clasificación. - Play sprint cierra los hallazgos mejor clasificados a lo largo de diez días, y la pestaña Burn-down compara eso con cerrar la misma cantidad sin un orden particular. - About explica qué se simula y enlaza al caso de estudio. Cómo funciona la simulación - Hallazgos: se generan 156 hallazgos a partir de plantillas que cubren consistencia de datos, riesgo de fallos, seguridad y code smell, en 12 repositorios ficticios, mediante una semilla aleatoria fija. - Clasificación: solo es ilustrativa — puntuación de riesgo = peso de severidad × (1 + la exposición del cliente del repositorio) × la confianza del agente. - Pull requests: un hallazgo recibe un pull request simulado a menos que la confianza del agente sea baja o la corrección necesite una decisión de diseño, en cuyo caso se marca para un ingeniero. - Burn-down: un sprint de diez días cierra primero los hallazgos mejor clasificados, y el gráfico compara eso con cerrar la misma cantidad sin un orden particular. El sistema real detrás del caso de estudio ejecutó agentes de Claude sobre repositorios reales, y sus hallazgos son confidenciales; esta demostración reproduce el flujo de trabajo y la presentación, pero no el análisis subyacente.