.png&w=256&q=75)
🤝 Top Collaborators
.png&w=640&q=75)
🤓 Latest Submissions
Vigil – Living Architectural Immune System
Problem: Application maintenance is still a high-friction workflow. Teams lose time and introduce risk when three kinds of decay pile up: dependency drift without codebase-specific impact analysis, AI-generated code that hides weak auth, hardcoded secrets, and mixed I/O, and architectural rules written in docs but silently broken in source. Existing tools are often noisy, reactive, or blind to repository structure and team invariants. The result is slow review, rework, and preventable production surprises. Solution: Vigil is a living architectural immune system built with IBM Bob 2.0. It maintains a health model of a repository and runs four specialized agents under a Supervisor: Drift Scanner, AI-Code Risk, Invariant Guardian, and Healing & Documentation. The agents read the real project, extract rules from ARCHITECTURE.md and docs/invariants.md, score findings, and propose the smallest safe fix. A deterministic fix engine can apply known patches. The same report is available from a CLI, a REST API, and a simple admin dashboard with a History tab. Target users: The users are software developers, maintainers, and small engineering teams who own a codebase and want faster, lower-risk maintenance decisions. A judge or new teammate can use the same flow after cloning the sample app. How they interact: A user installs dependencies and runs one command: node vigil/cli.js scan --verbose. Vigil prints FAIL, WARN, and PASS findings with file and line evidence. The user can preview patches with vigil fix --dry-run, apply them with vigil fix, or click Apply fix in the dashboard at http://localhost:3000/. After a fix, they scan again and watch the FAIL count drop. History records each scan and applied fix so the before-and-after trail is visible. The scan exits with code 1 when FAIL or ERROR exists, so it can be used in CI. What makes it unique: Vigil does not treat maintenance as autocomplete or as a single linter rule. It combines three decay types that teams usually handle in separate tools, grounds checks in the team’s own architecture documents, and closes the loop from detection to proposed fix to applied patch to re-scan. IBM Bob 2.0 was used as the core builder: full repository context, Agent mode, subagents, and document understanding produced the living model, the agents, the CLI, the API, and the dashboard. Effectiveness: The sample app ships with planted issues so the workflow is visible immediately: mixed payment logic in the controller, a direct axios call from a route, a weak token check, a hardcoded JWT secret, and unpinned dependencies. One scan surfaces those issues. Safe patches can be previewed or applied. A second scan shows architectural and AI-code FAILs reduced, leaving explicit dependency warnings. That turns a slow manual review into a short, repeatable maintenance loop.
27 Sep 2026
