OHCAYGO

Building tools for verifiable AI-assisted engineering. First experiment: merge-proof. Open source. Testing assumptions in public.

[OHCAYGO @OHCAYGO]

CI was green. Was the merge proven?

Merge-Proof checks whether a change was validated against the state it actually landed on — especially with agent PRs. NOT_PROVEN ≠ bad code.

If that problem shows up in your world, look at the sample and tell me if it’s useful or noise.

https://t.co/mfenque4pD

[OHCAYGO @OHCAYGO]

@BenRipkens I would, with one more receipt: that the tree that auto-merged is the same one the screenshots and checks ran on. Auto-merge loops rebase, and the evidence can end up describing an earlier commit. Curious how AutoMerge will handle that.

[OHCAYGO @OHCAYGO]

@RhysSullivan Love this loop. At a 6-hour cadence the thing I'd keep is a record per merge: the tree that landed is the one staging validated and the review agents saw. If main moves and it rebases in between, the green quietly belongs to an older commit.

[OHCAYGO @OHCAYGO]

@GergelyOrosz Once agent PRs outnumber reviewers, the PR stops being the thing anyone can really check. What can still be checked is what landed: which tree hit main, which base it was tested on, and which checks covered that exact tree.

[OHCAYGO @OHCAYGO]

@KhaireddinneD Which commit was checked is the line that bites. Agents rebase, the branch moves, and the green stays pinned to the old SHA. We'd add one more: which tree actually landed on main, and whether those checks covered it.

[OHCAYGO @OHCAYGO]

@s4yonnara "Reviewed them on main, after the fact" is the new review loop. It holds up if every land leaves a record: which tree hit main, which base it was tested on, which checks covered it. Otherwise you're reviewing the PR, not what shipped.

[OHCAYGO @OHCAYGO]

@Qweex_eth @Qweex_eth Agreed, provenance is its own layer, and your list is close to ours. One we'd add: say plainly when it can't be proven, like a merge that skipped the queue. If you want to try ours on a repo, happy to set up a free trial for honest feedback.

[OHCAYGO @OHCAYGO]

@vibexpr @vibexpr That's clean, matching on the pair beats a stale flag. The gap we keep hitting is merges that skip the queue: an admin bypass or a direct merge lands a tree no verdict names. Does your record catch those, or only what came through the queue?

[OHCAYGO @OHCAYGO]

@vibexpr Tree hash is the right anchor, nice. One thing we kept tripping on: a check that ran against an earlier base still reads green after the batch rebuilds. Do you mark those stale in the record, or just log what ran?

[OHCAYGO @OHCAYGO]

@poteto @mattpocockuk 2,500 lands a month means the gate was right at merge time. Curious what you keep after: for a given land, which exact tree hit main, which base it was tested on, and which checks applied — still showable after CI logs age out?

[OHCAYGO @OHCAYGO]

@anrayama @melissapan Agreed, that's the bar. Want to run the 10-day window on a real repo? Free trial for honest feedback. Every CURRENT / STALE / NOT_PROVEN has to be re-derivable from check + inputs + commit, or you call it out.

[OHCAYGO @OHCAYGO]

@anrayama @melissapan Agree — the receipt that matters is catching a green that no longer names the tip mid-cycle, plus a clear true CURRENT and a clear false alarm. That’s the bar we’re aiming the 10-day window at.

If those don’t show up in the first 10 days on a repo where required checks matter, we’re open to extending so you can keep running until they do. We’ve also got improvements finishing and launching before that window closes — happy to extend access through that drop as well.

Reply with the GitHub username that should own the install and I’ll get you on the allowlist.

[OHCAYGO @OHCAYGO]

@anrayama @melissapan Exactly — if you can’t re-derive the green from the named check + its inputs + the commit that last moved it, it’s rumor dressed as proof.

That’s the bar we measure: tip-bound CURRENT / STALE / NOT_PROVEN (fail-closed when you can’t prove it).

Still happy to force a tip-move STALE on one repo where required checks actually gate merge — name the repo (or PR) + your GitHub username and we’ll send the CURRENT→STALE receipt. Blunt notes welcome.

[OHCAYGO @OHCAYGO]

@garvinechan @kunchenguid Plan → TDD → review → e2e → PR is a clean agent workflow.

One check I still want at create-PR: do those greens still name the exact tip that just demo’d — or an older happy path?

[OHCAYGO @OHCAYGO]

@RyanEls4 Trusting the loop enough to skip reading the code and the reviews is the spiral in one sentence.

Same question at merge: when CI stays green, does it name the tip that lands — or just that something once looked fine?

[OHCAYGO @OHCAYGO]

@killix Green checks that say “tests pass” while the agent rewrote one file 17× is the receipt gap in one log.

Curious add-on: which tip SHA did that green name — still the one about to land?

[OHCAYGO @OHCAYGO]

Same shop wrote it and greenlit it. Platform governance on top. Cool.

Does that receipt still name the tip you're about to merge — or just that the pipeline said ok once?

Assumption we're proving: those aren't the same thing.

You treating them as the same?

[OHCAYGO @OHCAYGO]

Green checks aren't a tip-named receipt.

Tip can move after the green. Receipt that still names the old tip goes STALE. Working assumption: that gap is the thing worth measuring.

Is that worth it for you, or is green enough?

[OHCAYGO @OHCAYGO]

@pixincreate @pixincreate keen eye — we could use someone who spots bullshit. free trial for honest feedback if you want to tear into it. reach out and we’ll set you up

[OHCAYGO @OHCAYGO]

@shipsatnight Exactly — review asks if the diff is right; tip-bound receipt asks whether the proof still names the commit that actually merged. Both matter when agents push overnight. Totally understand you’re not adding tools right now. If that ever changes, we’d love to offer a free trial for some honest feedback — good or bad. We’re interested in what you think.