MergeProof

Inspiration

Pull-request review and release approval are related but different jobs. A review can say the code looks reasonable while release owners still need to know what changed, which tests matter, what evidence is missing, and how to roll back. Existing AI review tools often produce confident prose without showing exactly which supplied evidence supports each claim. MergeProof was built to make that boundary visible.

What it does

MergeProof accepts a public GitHub pull-request URL and collects a bounded ledger of PR metadata and changed-file patches. GPT-5.6 converts that evidence into a strict, structured release brief: a verdict and risk score, affected surfaces, cited findings, a prioritized test plan, release and rollback steps, and explicit unknowns. Every finding must cite one or more supplied file paths. The complete report can be copied or exported as JSON.

How it was built

The product is a single Cloudflare Worker with static assets. The Worker validates canonical GitHub PR URLs, reads metadata and up to 40 changed-file patches, enforces per-file and total evidence budgets, and sends the bounded payload to the OpenAI Responses API. GPT-5.6 (gpt-5.6-sol) runs with medium reasoning and strict JSON Schema output. The browser renders the structured response without executing repository content. Codex helped define the product boundary, implement the Worker and responsive interface, review security and evidence limits, add tests, and verify the production deployment.

Challenges

The hardest problem was preventing a useful release brief from becoming an ungrounded code-review summary. MergeProof treats GitHub content as untrusted input, separates it from developer instructions, requires path citations, reports truncation, and reserves an explicit section for unknowns. Another challenge was fitting dense engineering evidence into a mobile layout without hiding the decision context.

Accomplishments

• Real GPT-5.6 Responses API integration with strict structured output.
• File-path citations on every release finding.
• Bounded streaming reads for incoming requests, GitHub responses, and OpenAI responses.
• Explicit evidence truncation and unknown-context reporting.
• Production deployment with server-side secrets, CSP, logs, and traces.
• Responsive release workspace verified on desktop and mobile.

What we learned

Structured output solves response-shape consistency, but it does not solve grounding by itself. The evidence contract, prompt boundary, truncation signals, and UI treatment all need to reinforce the same rule: a claim without supplied evidence is an unknown. GPT-5.6 was especially effective at converting a narrow patch ledger into targeted checks and rollout actions when those boundaries were explicit.

What's next

The next step is optional GitHub App access for private repositories and CI evidence, followed by saved team policies for required checks and rollout gates. A future version could compare the generated plan with actual CI results while preserving the same cited-evidence contract.

Built With

• cloudflare
• codex
• github-api
• gpt-5
• javascript
• json-schema
• openai
• typescript