Sonia Ndione@sonia118

## Problem A developer can remove a small defensive check, commit it, and only discover the regression after the code has already been pushed. Traditional linters and static analysis can identify suspicious changes, but they do not necessarily prove that a real behavior protected by the project has been broken. Dev Sentinel addresses this gap at the exact moment a developer runs `git push`. ## Solution Dev Sentinel is a Git pre-push safety checkpoint. When a push contains relevant Python changes, it investigates the change through a multi-stage pipeline: **Code Change → Explorer → Impact → Tester → Pytest Runner → Evidence** The Explorer identifies what changed. The Impact agent analyzes how the change may affect behavior and identifies potentially affected inputs and components. The Tester identifies relevant existing tests that can exercise the affected behavior. The test runner then provides concrete evidence by executing those tests. If the relevant tests fail, Dev Sentinel blocks the push and persists an incident containing the changed files, affected behavior, suspected issue, and test evidence. The repair process is deliberately separate from the push hook. The developer can run `dev-sentinel fix`, review the evidence, and explicitly authorize a proposed fix. The Fixer then applies the narrowly scoped repair and verifies it first against the focused tests and then against the full test suite. If verification fails, the change is rolled back. ## Target Users Dev Sentinel is designed for software developers and teams working with Git and automated tests, especially when preventing regressions before code leaves a local development environment is important. ## Interaction Developers interact with Dev Sentinel through normal Git commands. They install a pre-push hook once, then continue using `git push normally`. A clean change passes through automatically. A confirmed regression is blocked with evidence. A developer can then review and authorize a repair separately. ## What Makes It Different Dev Sentinel connects code-change analysis with behavioral evidence at the exact Git workflow boundary where a change is about to leave the developer's machine. Its core principle is: **Impact predicts. Tests prove. Fix only when I authorize.** The investigation stages are read-only, the push hook does not automatically modify source code, and the Fixer requires explicit human authorization. There is no automatic commit or push. The current implementation is deterministic and evidence-driven, while its agent interfaces are structured so individual stages can later be replaced or extended with Bob subagents without weakening these safety boundaries.

Six Matches. One leaderboard. Build on AMD, earn points and compete for prizes.

💻 Online Hackathon | ⏳ Build: 48 hours | 📅 September 25–27, 2026 The official IBM Bob 2.0 hackathon. Build what's next in AI-assisted development, alongside the developers and experts shaping it. ⭐ Get help from experts throughout the event 🤝 Join a team or build solo 💰 Prize pool: $12,000 🧑🏻‍💻 Register before the Kick-Off Stream to start building with Bob