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.
Been in a thread lately about the "context tax" of re-explaining project state to an agent every session, and it made me realize the harder problem for me isn't memory, it's trust in the agent's own status reports.
When an agent says "fixed it, tests pass" or "yes that endpoint handles that case," how much do you actually check versus just believing it and moving on? I've gotten burned a couple times by an agent confidently describing behavior it never actually verified, it just pattern-matched to what a fix usually looks like.
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.
Ota
