About this project

Bug Manager is a browser-based, fully simulated demonstration of agentic bug management, published as the public companion to a case study. Nothing in the demo scans real code, calls a language model, or makes a network request: every repository, finding, pull request, and ticket is generated in the browser, and a fixed seed always produces the same 156 findings. What the demo shows - Agents scan twelve fictional repositories and rank what they find. - For each finding the agent can fix, it opens a pull request with a proposed fix and logs a ticket. - A team then works the ranked list down over a single sprint. Running it The project ships a small static server with no install step and no dependencies: python3 serve.py # http://0.0.0.0:8430/ python3 serve.py --port 9000 # another port Only the public/ directory is served, directory listings are disabled, and the server sends a strict Content-Security-Policy. A systemd user unit is included for keeping it running, with lingering enabled so the service starts at boot. Because the server accepts any Host header, a reverse proxy can map a domain name directly to it. All asset URLs are relative, so public/ can also be dropped into any folder of a static host. Layout - public/index.html — the app shell (top bar, status bar, cards, workspace, drawer, About dialog) - public/assets/app.js — data generator, scan, ranking, filters, drawer, burn-down sprint - public/assets/app.css — all styles, light and dark themes, no external fonts - public/assets/theme-init.js — applies the saved or system theme before first paint - serve.py — static server with a strict Content-Security-Policy - bug-manager.service — systemd user unit The app is self-contained: it loads no fonts, scripts, or images from another origin, and the CSP (default-src 'self', connect-src 'none', no inline styles) enforces that. Using it - The app opens with a completed scan; Run scan replays the scan from scratch. - Clicking a repository filters the findings; clicking a finding opens a detail drawer with code, reasoning, pull request, ticket, and ranking explanation. - Play sprint closes the highest-ranked findings over ten days, and the Burn-down tab compares that with closing the same number in no particular order. - About explains what is simulated and links to the case study. How the simulation works - Findings: 156 findings are generated from templates covering data consistency, failure risk, security, and code smell, across 12 fictional repositories, using a fixed random seed. - Ranking: illustrative only — risk score = severity weight × (1 + the repository's client exposure) × the agent's confidence. - Pull requests: a finding gets a simulated pull request unless the agent's confidence is low or the fix needs a design decision, in which case it is flagged for an engineer. - Burn-down: a ten-day sprint closes the highest-ranked findings first, and the chart compares that with closing the same number in no particular order. The real system behind the case study ran Claude agents over real repositories, and its findings are confidential; this demo reproduces the workflow and presentation rather than the underlying analysis.