Agent should run project test suite before committing — no default guardrail against shipping broken code

{"body": "## The problem\n\nClaude Code can write code, get human approval on the diff, and commit it \u2014 without ever running the project's test suite. There is no built-in mechanism to validate changes against the project's own tests before they land.\n\nThis means the agent can ship code that looks correct in review but fails at runtime. The human approver is the last line of defense, and they're trusting the agent got it right.\n\n## What happened\n\nI'm using Claude Code as a co-developer on a production Flask app (~4,500 lines across several modules). During a session, the agent added a database backfill inside a deduplication function. The code was correct in isolation \u2014 right logic, right SQL, right result. I approved the diff.\n\nThe problem: it opened a new database connection inside a for loop that processes ~400 items on every search run. The search hung. I had to report it back to the agent, who then fixed it.\n\nWhen I pointed out this was a regression, the agent offered to:\n1. Add it to a checklist (a markdown file it reads at the start of sessions)\n2. Promise to be more careful\n3. Add a memory note to test before shipping\n\nI pushed back: checklists are trust-based. The agent already had a checklist and didn't follow it. We needed a deterministic guardrail.\n\nThe solution was trivial \u2014 a 20-line git pre-commit hook that runs pytest before every commit. Now the tests gate every commit automatically. But it took three rounds of me rejecting promise-based solutions before we got to the right answer.\n\n## The suggestion\n\nClaude Code should have a built-in mechanism to discover and run a project's test suite before committing changes. Some options:\n\n1. Auto-detect test suites \u2014 if pytest, jest, go test, cargo test, etc. are available and test files exist, run them before git commit\n2. Scaffold a pre-commit hook \u2014 when Claude Code first starts writing code in a repo that has tests but no pre-commit hook, suggest or create one\n3. Built-in test-before-commit step \u2014 make \"run tests\" a native part of the agent's commit workflow, not something the user has to set up\n\nThe current behavior \u2014 where the agent can modify core functions, commit the changes, and never validate them against the project's own regression suite \u2014 is a real reliability gap. Especially as these tools get used on larger codebases by users who trust the agent to get it right.\n\n## Why this matters beyond my project\n\nThis is an agentic orchestration problem. As AI agents ship more code faster, the human's ability to catch runtime bugs in diff review decreases. The agent moves fast, the changes look reasonable, and the approval becomes rubber-stamping. Trust-based approaches (checklists, promises, memory notes) don't survive the pace of agentic development.\n\nThe only thing that scales is deterministic verification \u2014 mechanisms that operate outside the agent's own reasoning loop and produce pass/fail results the agent can't negotiate with. A pre-commit hook is the simplest version of this, but the principle extends much further: any agentic system that modifies artifacts (code, documents, configurations) needs a verification layer that is structurally independent of the model producing the changes.\n\nI work on this problem professionally \u2014 building deterministic verification systems that validate AI-generated outputs using non-probabilistic, auditable methods (v3pi.com). Happy to have a deeper conversation with anyone on the team thinking about agent reliability and guardrails.\n\nContact info available on request \u2014 reach out via the GitHub profile linked to this issue."}