For teams using AI agents in development: how do you tell the agent what is safe to run in a repo?

Hi Adamma — this really resonates. I build my app (NEXIA, an AI app) almost entirely with an AI coding agent, so "how do you tell the agent what's safe to run" isn't theoretical for me — it's a daily safety question What's worked for me is treating a few documents as the single source of truth for execution knowledge: a top-level file (plus a docs/ folder) that explicitly states what's frozen, what's forbidden, and what must be checked before running anything. The agent reads it before acting. That's basically what you're describing with Ota — making the "what's safe" knowledge explicit instead of letting the agent guess. But here's the lesson I learned the hard way: documentation alone isn't enough. I now think of it as three levels of protection, from weakest to strongest: Docs only — "don't touch X." Depends on the agent actually reading and respecting it. Fragile. Automated tests — a test that fails if a protected behavior changes. Catches regressions even when the doc is missed. Hard/platform locks — read-only production database, locked config files. The mistake becomes impossible. A real example: a plan to modify a deliberately frozen part of my codebase got proposed mid-session. It was refused only because the freeze was written explicitly in my source-of-truth doc. Without that, the agent would have happily done unsafe work. That's exactly the gap you're pointing at — and it's what convinced me that for the few truly catastrophic operations (production data, deployments, frozen modules), docs aren't enough on their own; I back them with a test or a hard lock. So my short answer: make the knowledge explicit in one canonical place the agent always reads — but for the handful of operations that could cause real damage, enforce it with something that can't be ignored, not just described. Curious to see where Ota lands on that doc-vs-enforcement spectrum.