If you've been following along and would like to support us we would appreciate a star of GitHub: https://github.com/ota-run/ota

Ota now supports refusal canaries. Repositories declare tasks that must remain unavailable to agents, and CI verifies that the real execution boundary rejects them with `--expect-refusal`.

In the AI era, governance cannot stop at documenting what agents may do. Teams also need negative tests proving that forbidden execution remains forbidden.

If you've been following along and would like to support us we would appreciate a star of GitHub: https://github.com/ota-run/ota

A repo can look fine until it is run in a different environment. Native setup, Docker, CI, and remote execution often carry different assumptions, and most teams only discover the mismatch when something breaks.

Ota makes those execution paths explicit so a repo can declare how it should be prepared, verified, and run in each environment.

Where does drift cost your team the most today: local setup, CI, containers, or remote environments?

I built Ota after years of watching the same thing happen: you clone a repo, follow the README, and hit a wall because the project s actual setup changed, while docs and run paths drifted out of sync.

I wanted a reliable way to make the ready-to-run and safe state explicit, not tribal, using an execution contract in `ota.yaml` that humans, CI, and AI agents can use.

So if you want to ask about how Ota works under the hood, how execution contracts are structured, onboarding pain, or where we re taking governed repo execution for AI workflows, I m here.

If you ve been following along and want to support us, we d really appreciate a GitHub star:

https://github.com/ota-run/ota

A repo reaching a working state once is useful.

But the real value comes when that working state can be repeated by the next person, on the next machine, or in the next automation run.

We're live! If repo setup drift, execution inconsistency, or governing what AI agents are allowed to run in a codebase is something you've thought about, today is a good day to check out what we've been building.

You can find us here: https://www.producthunt.com/prod...

AI agents are becoming part of everyday development, but most repos still don t have a clear way to tell an agent what is safe to run, what needs to be checked first, or which commands are actually trusted.

That gap is what we re thinking about with Ota: making repo execution knowledge explicit enough for humans, CI, and AI agents to follow without guessing.

Two months ago, we launched Ota on Product Hunt for the first time.

It was an amazing experience. We met developers, founders, and open source maintainers who helped us see the problem more clearly.
Since then, we've shipped dozens of improvements, refined the product, improved onboarding, and listened closely to feedback from real repositories.

So we're coming back this Friday.

If you've ever joined a repo and wondered "what am I actually supposed to run?" or "why does this work locally but fail elsewhere?", that's the problem we're tackling.

We've been running Ota against real-world repos to see how it handles messy setup, drifted docs, hidden dependencies, and inconsistent run paths.

If you want to see what Ota would surface in your repo, drop the Github link below. We'll pressure-test it, draft an `ota.yaml`, and open a PR so you can see exactly what it found and how the execution contract takes shape.

If you ve been following along and want to support us, we d really appreciate a GitHub star:

https://github.com/ota-run/ota

The first thing I'd teach an AI coding agent isn't how my code works.

It's what not to do.