Gatekeeper

Inspiration

Software review is often treated as a pass/fail moment: a pull request gets a comment, a check turns red, and the context behind that decision disappears.

I wanted to build something more accountable. Gatekeeper is built around a simple idea: an AI assistant can help developers understand a repository, but it should not quietly become the authority that decides what is safe to merge.

The project was also inspired by a practical problem: teams carry important decisions in old pull requests, commits, ADRs, and conversations. When that context is hard to retrieve, the same mistakes and debates return.

What it does

Gatekeeper is a local-first, evidence-first repository review tool.

It reviews repository changes against deterministic policy and returns an inspectable verdict such as BLOCK, REQUIRE_CHANGES, ESCALATE, or FAST_PATH. Instead of producing an opaque score, it preserves the evidence, findings, policy authority, and history behind each result.

The dashboard includes Project Memory, an evidence timeline, historical commit review, and a Pull Request Explorer. Developers can inspect prior decisions and re-review a corrected change to see the verdict change with the evidence.

Codex connects through MCP and a Gatekeeper skill. It can retrieve and explain bounded evidence from Project Memory, while Gatekeeper remains the deterministic authority for the final verdict.

A key safety boundary is demonstrated in the project: repository text is always treated as untrusted evidence, never as instructions. Gatekeeper can detect prompt-injection-like text in a pull request without allowing that text to control the review.

How we built it

Gatekeeper is a TypeScript monorepo built for local-first use.

• Node.js and TypeScript power the review engine, CLI, MCP server, and local dashboard backend.
• React and Vite power the dashboard.
• SQLite stores bounded Project Memory and review evidence locally.
• Zod validates stable contracts and configuration.
• Git and the GitHub CLI provide explicit repository and GitHub access.
• Codex with GPT-5.6 was used throughout the project to help design, implement, test, document, and reason through the system via the Gatekeeper MCP workflow.

The project deliberately keeps its architecture narrow: one fixed repository per local service session, no hidden background GitHub activity, no GitHub write actions, and no requirement for a hosted backend.

Challenges we ran into

The hardest challenge was balancing usefulness with control.

It would have been easy to build a generic AI code-review interface that makes broad claims without preserving evidence. Instead, we had to design clear authority boundaries: what deterministic policy can decide, what Codex can contribute, what repository text is allowed to influence, and what remains visible to the developer.

Another challenge was making historical context useful without turning Gatekeeper into a GitHub clone. We scoped the Pull Request Explorer to local, bounded evidence and explicit sync actions rather than arbitrary GitHub browsing or background polling.

We also spent time hardening local operation: interrupted review runs, stale state, repository identity, process lifecycle, and reproducible offline demo data all needed careful handling.

What we learned

We learned that trustworthy AI-assisted developer tools need more than a good model response. They need visible evidence, explicit permissions, recoverable local state, and a clear answer to one question: who has the authority to make the decision?

Codex was most valuable as a bounded collaborator: helping retrieve context, explain evidence, and accelerate implementation—without replacing the deterministic rules that protect the repository.

Gatekeeper is our attempt to make that relationship tangible: AI assistance that is useful, inspectable, and still under the developer’s control.

Built With

• codex
• gpt-5.6
• node.js
• react
• sqlite
• typescript