标签：#reporeadiness

Overview Open WebUI exposed a real Ota lifecycle boundary. This was not mainly a parsing or contract-shape repo. The contract was already strong enough to model: source-checkout verification packaged native runtime through uv run open-webui serve frontend development runtime default Docker Compose runtime What the repo exposed was operational truth after proof: a successful native proof still left a host workload alive the first cleanup fix then widened too far and treated a Compose-owned runtime as the same class of host workload That made Open WebUI a valuable pressure repo. It forced Ota to get more precise about cleanup ownership instead of treating all successful runtime proof as one generic teardown problem. The current pressure contract pins released Ota v1.6.24 . Its latest green matrix run proves the release surface at the exact contract and workflow revision linked below. What Open WebUI exposed in Ota This repo exposed four meaningful weaknesses. 1. proof success was weaker than it looked The first issue was not that runtime proof failed. It was that runtime proof succeeded and still left the native workload alive afterward. In this repo, the packaged native workflow launches: serve:native : launch : kind : command exe : uv args : - run - open-webui - serve - --host - 0.0.0.0 - --port - " 8080" Ota proved that workflow, but the launched process tree was still alive after proof completed. In GitHub Actions, that surfaced through setup-uv post-job cleanup, which blocked while the uv cache was still in use. That was an Ota gap. If proof succeeds but leaves behind repo-owned runtime state that later breaks CI cleanup, the proof surface is still incomplete. 2. native service cleanup widened past its real ownership boundary The first core fix made Ota clean selected native service workloads after successful proof. That was directionally correct, but Open WebUI immediately exposed the next boundary. The Docker workflow uses a native task shape to launch Compose:

Overview lead-quorum was a strong pilot repo because it was small enough to reason about and real enough to fail honestly. It has: repo-local Python environment ownership pinned dependency installation env bootstrap from example truth a deterministic local test surface live external verification a local web runtime a distributed demo path a Docker build lane That is exactly the kind of repo where a contract can look clean while still hiding real setup and execution drift. Why this repo mattered The useful pressure here was not “can Ota run one Python command.” The useful pressure was whether Ota could stay truthful when the repo itself owns: the .venv the dependency install lane the local executable path the runtime listener truth If Ota probes or fulfills those in the wrong order, the contract is not trustworthy even if the repo itself is valid. That is what made lead-quorum valuable. What the contract now models The final contract is explicit about the repo’s real setup split. Setup is not one opaque shell step. It is three different ownership surfaces: copy .env from .env.example only if missing create the repo-local virtual environment hydrate dependencies through typed uv requirements-file installation That looks like this in the contract: setup : aggregate : tasks : - setup:env - setup:venv - setup:deps setup:env : action : kind : copy_if_missing from : .env.example to : .env setup:venv : action : kind : ensure_virtualenv path : .venv python : " 3.12" setup:deps : prepare : kind : dependency_hydration medium : package_dependencies source : kind : uv cwd : . mode : pip_requirements requirements_file : requirements.txt The contract also keeps verification and external-runtime claims separate: verify for deterministic local validation live for Gemini-backed end-to-end testing app for the local web service distributed for the A2A demo path That matters because a working local scoring test and a live distributed runtime are not the same readiness claim. What lead-q

Overview AGENTS.md is useful. It gives AI coding agents a place to find repo-specific guidance: how to behave what conventions matter what areas need extra caution what kinds of changes should trigger review That is a meaningful improvement over sending an agent into a repo with no instructions at all. But AGENTS.md is not enough. It can tell an agent to be careful. It cannot, by itself, make execution safe, verification trustworthy, or review inspectable. For that, a repository needs more than instructions. It needs: declared safe commands a canonical verification path receipts that show what actually ran That is the difference between agent guidance and execution governance. Instructions Help. They Do Not Govern Execution. An instruction file is still prose. That means it can express intent, but it does not automatically create operational truth. For example, AGENTS.md can say: run the right checks before handoff avoid destructive commands do not edit generated files ask before touching infrastructure Those are good rules. But notice what they leave unresolved: which checks are the right ones which commands are actually safe which paths are protected structurally versus only suggested what should count as evidence that verification happened how to tell whether a failure came from code, setup, or drift That is where many agent workflows still break down. The agent may follow the spirit of the instructions and still take the wrong execution path. Safe Commands Need To Be Explicit One of the biggest gaps in agent-oriented repos is that they often declare guidance without declaring a safe command surface. The repo may tell the agent: Run tests before you finish. But that still leaves a dangerous amount of interpretation. Which task is safe? Is it: npm test pnpm test make check docker compose run test a narrower unit-test path the CI workflow itself And if several exist, which one is canonical for a routine code change? The repo should not force the agent to infer that

Overview We built the Ota skill because too much "AI repo automation" is still fake confidence. An agent clones a repo, finds a plausible command, edits the right file, and looks smart right up until it does something expensive and stupid. It runs the wrong test path. It installs tools globally because local setup was unclear. It patches around a missing service as if the repo were healthy. That failure is usually blamed on the model. Most of the time it is a repo problem. The repository never made its real operating path explicit enough for the agent to follow without guessing. Ota already gives the repo a machine-readable contract through ota.yaml . The skill exists to teach agents how to behave around that contract: what to trust, what to run, and when to stop instead of improvising. It is not a replacement for ota.yaml . It is not an MCP server. It is not a hidden automation layer. It is the missing operating guide for agents working in Ota repos. Why an Ota skill exists We kept seeing the same pattern: the agent was fast, but the repo was vague. Without a repo-specific operating guide, an agent may see several possible paths: run the command from the README copy the command from CI infer setup from package.json , pyproject.toml , or go.mod run a broad test command because it looks conventional install tools globally because a local command failed patch around a missing service instead of identifying the readiness gap Some of those choices work. Some are dangerous. Some look fine locally and still miss the only verification path that matters. Our view is simple: if a repo has ota.yaml , that file should beat README prose, shell folklore, and whatever command happens to look familiar. Declared tasks, writable paths, setup requirements, and validation commands should be treated as contract facts. The skill exists to make that behavior explicit across agents that support skills. What the skill teaches an agent The official skill lives in ota-run/skills . It is aime