ReleaseGuard is a release-readiness gate for pull requests that catches the one category of risk generic code review tools miss entirely: institutional knowledge loss. Most AI review tools ask "is this code correct?" — they scan a diff, flag style issues, suggest a refactor. ReleaseGuard asks the harder question nobody automates: "if this PR ships, does anyone left on the team actually understand what it touched?" THE PROBLEM Manual PR review today takes 30–60 minutes and still misses undocumented, unowned, and untested code almost entirely, because verifying "does anyone actually understand this part of the codebase" isn't something a human reviewer can check quickly under time pressure. The result: teams lose institutional knowledge silently — a departing engineer's undocumented logic, or a module nobody has touched in over a year, ships a breaking change that isn't caught until production. HOW IT WORKS ReleaseGuard takes a repo and a PR diff and runs four checks as parallel subagents rather than one sequential pass: - Test coverage — finds touched code with zero test coverage and generates real, runnable unit tests for the gaps. - Docs vs. behavior — builds a "claimed behavior" baseline from the README, CONTRIBUTING.md, and inline comments, then flags where the code's actual behavior contradicts what the documentation says. - Ownership & history — checks git history for the touched files and flags code with no clear recent owner or a stale/departed contributor (bus-factor risk). - Breaking change — traces call sites across the repo to catch changes that silently break other code depending on the touched interface. Each subagent normalizes its findings against a deterministic evidence bundle before reporting back, and a check that fails or times out still returns a result via a fallback path, so the pipeline never dies mid-review. The aggregation layer then does something a checklist can't: a file that is untested, undocumented, contradicted by its own README, AND owned by someone who's gone gets escalated to a NO-GO blocker on its own — even when no single check alone would have flagged it as severe. THE PROTOTYPE - Backend (Express + SQLite) ingests a repo/diff, builds the document- understanding baseline, runs the four subagents in parallel, and verifies generated tests actually execute before including them in the report. - Frontend (React) lets you submit a repo/PR, watch each check complete live, and view the final Release Readiness Report with a dedicated Institutional Knowledge Gap panel alongside the GO / GO_WITH_WARNINGS / NO-GO verdict. - A seeded before/after demo: a "flawed" sample project (untested pricing logic, a README that no longer matches the code, a file last touched 18 months ago by a departed contributor) and a "clean" version of the same app, so the same PR type produces a NO-GO on one and a GO on the other. - A headless workflow mode (submit → parallel checks → report, exit code reflects the verdict) so the whole pipeline is repeatable in CI, not just demoable in a browser. IMPACT On the flawed sample PR, ReleaseGuard returns a full four-check verdict with auto-generated tests and a knowledge-gap panel in under two minutes, versus an estimated 45+ minutes for a careful manual review — and it catches the docs-contradiction and stale-ownership risks that manual review typically misses entirely, because nobody has time to check git blame and re-read the README on every PR. The clean sample project returns a GO in the same window, confirming the pipeline doesn't just flag everything indiscriminately. WHY IT'S DIFFERENT This isn't a linter with an LLM bolted on. It fuses four evidence sources a single chat-based review can't hold at once — a document-understanding baseline, git archaeology, symbol-level test coverage, and call-site tracing — runs them concurrently, and aggregates them into a single risk score per file. The output is a release gate, not a comment thread
Category tags: