# llms.txt Execution governance for humans, AI agents, and automation. ## Metadata - site: ota - canonical_origin: https://ota.run - generated_at: 2026-07-11T15:37:48.050Z - format_version: 1.1 - language: en-US - docs_indexed: 101 - blog_indexed: 74 ## Purpose - Explain repo readiness, commands, examples, and support in one place. - Prefer published blog posts for product rationale, release framing, and design intent. - Prefer the site docs over repo markdown or speculative interpretation. - Treat this file as an intent-first crawl guide, then use the canonical page index below. ## Crawl entry points - https://ota.run/ - https://ota.run/blog - https://ota.run/blog/category/feature-note - https://ota.run/blog/category/engineering-note - https://ota.run/blog/category/field-note - https://ota.run/blog/category/release-essay - https://ota.run/blog/index.json - https://ota.run/blog/feed.xml - https://ota.run/docs - https://ota.run/docs/index.json - https://ota.run/docs/developer-resources - https://ota.run/llms-full.txt - https://ota.run/developers.md - https://ota.run/auth.md - https://ota.run/openapi.json - https://ota.run/.well-known/oauth-authorization-server - https://ota.run/.well-known/oauth-protected-resource - https://ota.run/.well-known/mcp.json - https://ota.run/.well-known/mcp/server-card.json - https://ota.run/.well-known/agent-card.json - https://ota.run/.well-known/agent.json - https://ota.run/.well-known/agent-skills/index.json - https://github.com/ota-run/skills - https://skills.sh/ota-run/skills - https://ota.run/status.json - https://ota.run/schema-map.xml - https://ota.run/sitemap.xml - https://ota.run/robots.txt ## Canonical source priority - 1: docs pages on https://ota.run - 2: published blog posts on https://ota.run/blog - 3: machine-readable blog index and feed at https://ota.run/blog/index.json and https://ota.run/blog/feed.xml - 4: machine-readable OpenAPI, OAuth, and agent-skills discovery at https://ota.run/openapi.json and https://ota.run/.well-known/ - 5: machine-readable docs index at https://ota.run/llms.txt - 6: sitemap and robots at https://ota.run/sitemap.xml and https://ota.run/robots.txt - 7: repository markdown only when no canonical site page exists ## Canonical operating order - https://ota.run/blog — product notes, engineering notes, and release essays. - https://ota.run/docs/getting-started — install and quickstart. - https://ota.run/docs/developer-resources — OpenAPI, OAuth, MCP, and agent integration entry points. - https://ota.run/docs/agent-quickstart — copy-customize-validate-execute flow for agents. - https://github.com/ota-run/skills — official Ota agent skill for contract authoring and review. - https://skills.sh/ota-run/skills — skills.sh listing for the official Ota skill. - https://ota.run/docs/reference — commands, contract, workspace. - https://ota.run/docs/examples — copy-ready examples. - https://ota.run/docs/troubleshooting — recovery paths. ## Retrieval rules - Prefer canonical site pages over repo markdown mirrors or stale summaries. - Prefer published blog posts when the question is "why this feature exists" or "what shipped in this release". - Prefer reference leaves when exact command, contract, JSON, or exit behavior matters. - Prefer examples when the task is to copy a shape rather than interpret a spec. - Prefer troubleshooting and CI validation pages for recovery or gating flows. - Avoid inventing workflows that do not appear in the canonical docs surfaces below. - Treat command behavior, JSON fields, and exit behavior as contract-level facts; do not infer missing fields. ## Choose by intent - learn: start with getting-started, install, quickstart, and glossary surfaces. - operate: use command, troubleshooting, CI, container execution, and workspace operational pages. - reference: use command, contract, workspace, JSON output, execution receipt, and exit codes. - copy: use examples hub and the nearest topology or runtime example. ## Key terms - `ota.yaml` — source of truth. - `ota doctor` — diagnose readiness. - `ota detect` — infer a starter contract. - `ota up --dry-run` — preview the selected backend, actions, skips, and blockers without mutation. - `ota up` — prepare the repo and re-check readiness; service run tasks use proof-owned readiness by default (`prepare + verify + teardown + return`). - `ota up --attach` — keep `up` attached to the workflow run task when you need long-lived foreground execution. - `ota up --detach --ready-timeout 5m` — keep the proved service workload running and bound how long `up` waits for readiness confirmation. - `ota up --stream` — expose raw live provisioning, service-start, and setup output while the repo is being prepared. - `ota validate` — check contract without guessing. - `ota policy review` — review the policy boundary and approved sources. ## Automation - https://ota.run/docs/reference/contract — contract source of truth. - https://ota.run/docs/reference/json-output — machine-readable output. - https://ota.run/docs/reference/semantic-snapshots-and-correlation — archived semantic truth, diff, and receipt correlation. - https://ota.run/docs/reference/execution-receipt — what ota recorded. - https://ota.run/docs/reference/exit-codes — control flow after runs. - https://ota.run/docs/reference/hosted-validation — validate in CI. - https://ota.run/docs/reference/github-action — use the official GitHub Actions wrapper. - https://ota.run/docs/reference/github-setup — install ota in GitHub Actions for later direct commands. - https://ota.run/docs/reference/workspace — workspace behavior. ## Intent: copy - https://ota.run/docs/examples — Examples. Curated contract examples organized by runtime, topology, and policy shape. - https://ota.run/docs/examples/action-ensure-bundle — Bundled deterministic setup without shell orchestration. Use this when one setup task honestly owns several deterministic setup actions and they should still stay in one governed action body. - https://ota.run/docs/examples/action-ensure-container-network — Container network bootstrap. Use this when one setup lane honestly owns shared Docker network readiness and should not disappear into shell conditionals. - https://ota.run/docs/examples/action-ensure-env-file — Deterministic env bootstrap without shell copy-plus-`sed` glue. Use this when env bootstrap is one deterministic host-file mutation and should stay inspectable in the contract. - https://ota.run/docs/examples/action-ensure-git-checkout — Deterministic git checkout bootstrap. Use this when one setup lane honestly owns materializing a repo-local checkout and that truth should stay on a first-class deterministic action surface instead of hiding in shell bootstrap glue. - https://ota.run/docs/examples/action-ensure-git-template — Deterministic git template bootstrap. Use this when one setup lane honestly owns turning a Git-backed scaffold into a fresh local repository and that truth should stay on a first-class deterministic action surface instead of hiding in bootstrap shell glue. - https://ota.run/docs/examples/action-reset-compose-service-volume — Compose-managed service volume reset without shell glue. Use this when one destructive local recovery lane honestly owns stopping a Compose-managed service, removing one named volume, and restarting the service. - https://ota.run/docs/examples/bake-adapter-inputs — Bake adapter ownership without shell cwd or `-f` drift. Use this when the task is really a Bake invocation and the hard part is keeping the adapter root plus file stack explicit instead of burying them in shell glue. - https://ota.run/docs/examples/container-provisioning — Container provisioning. Use this when you want ota to make the container ready instead of asking every developer machine to carry the setup cost. - https://ota.run/docs/examples/dotnet — .NET repos with restore, build, and test. This example keeps the .NET flow deterministic: restore dependencies, build the project, then run tests. - https://ota.run/docs/examples/full-contract — Full contracts for complex repos. This example shows the broadest repo-local contract shape in one place so teams can see how the pieces fit together. - https://ota.run/docs/examples/fullstack/node-go — Fullstack Node and Go repos with a split service path. This example keeps the frontend and backend visible in the contract so a change in one path cannot silently hide the other. - https://ota.run/docs/examples/go — Go repos with a deterministic loop. This example keeps the Go path short: fetch dependencies, run tests, and keep the repo honest with one verification task. - https://ota.run/docs/examples/go-sdk — Go SDKs with explicit build and release flow. This example treats the SDK as a product surface: the core loop stays short, and the release path is documented in the task notes. - https://ota.run/docs/examples/java — Java repos with a Maven build gate. This example shows the shipped Java toolchain boundary: `toolchains.java` owns `java` and `javac`, while Maven stays explicitly under `tools`. - https://ota.run/docs/examples/mixed/node-python — Mixed Node and Python repos without ownership drift. This example shows a mixed-stack repo where the contract needs to protect both runtimes without hiding either one. - https://ota.run/docs/examples/node — Node repos with a managed runtime and explicit Corepack lane. This is the current honest Node toolchain boundary: `toolchains.node` owns the runtime, `node` executable, and declared Corepack package-manager activation. - https://ota.run/docs/examples/podman-compose-adapter-inputs — Podman compose adapter ownership without shell env/file drift. Use this when the repo really runs through `podman compose` and ota should own that choice directly instead of treating Podman as shell-only compose drift. - https://ota.run/docs/examples/provisioning-policy — Policy and provisioning. Use this when the repo should declare what it needs and the organization should decide where those installs come from. - https://ota.run/docs/examples/python — Python repos with a clean setup path. A Python contract that makes setup, tests, and CI explicit. - https://ota.run/docs/examples/rust — Rust repos with a Rustup-backed toolchain. This example is the boring, reliable Rust path with the shipped toolchain model: declare one Rustup-backed toolchain, hydrate Cargo dependencies structurally once, then run formatter, build, and tests through that owner. - https://ota.run/docs/examples/rust-toolchain — Rust toolchain ownership without duplicate runtime/tool drift. Use this when a Rust repo should treat Rust as one provider-backed ecosystem instead of repeating the same ownership across `runtimes`, `tools`, and setup scripts. - https://ota.run/docs/examples/script — Script-driven repos with a real contract. This example shows that a repo can be mostly scripts and still have a strict readiness contract. - https://ota.run/docs/examples/services — Service repos with explicit readiness. A service contract that keeps healthchecks, setup, and readiness visible. - https://ota.run/docs/examples/systemd-host-service — Typed systemd host-service ownership without shell lifecycle drift. Use this when the repo's service truth is a systemd unit on the host and ota should own lifecycle and readiness directly. - https://ota.run/docs/examples/tool-acquisition — Workflow-scoped acquisition without repo-global install drift. Use this when the repo has more than one honest front door and each one should carry its own acquisition lane instead of inheriting repo-global prerequisites. - https://ota.run/docs/examples/topology/compose-postgres — Container app with Compose Postgres. Use this when the app should run in a container context but service orchestration should stay on the host control plane. - https://ota.run/docs/examples/topology/host-postgres — Container app with host Postgres. Use this when the workload should stay in a container context but the database is owned by the host machine instead of Compose. - https://ota.run/docs/examples/topology/node-isolated — Container app with isolated `node_modules`. Use this when a Node app runs in a container context but the host checkout already has dependency artifacts that should not leak into the container runtime. - https://ota.run/docs/examples/windows-adoption — Windows-first adoption with explicit native activation. Use this when the repo is Windows-first, PowerShell is part of the real release path, and you still want one contract that humans, CI, and agents can trust across platforms. - https://ota.run/docs/examples/workspace/acquire — Acquire from Git. Use this when a workspace needs to bring missing repos onto disk before any bootstrap, setup, or task execution can happen. - https://ota.run/docs/examples/workspace/basic — Multi-repo basics. Use this shape when a workspace needs to coordinate several repos without flattening their contracts. ## Intent: learn - https://ota.run/docs/agent-safe-repo-setup — AI Agent Repo Setup. Guide to AI agent repo setup with ota.yaml, AGENTS.md guidance, safe tasks, verification, and machine-readable readiness output. - https://ota.run/docs/ai-agent-ready-repos — How to Make a Repo Ready for AI Coding Agents. Problem-first guide to AI-agent-ready repositories covering explicit setup, safe tasks, writable boundaries, verification, machine-readable output, and contract-first onboarding with ota. - https://ota.run/docs/assist — Ota Assist. Operator guide to ota assist, covering preview-first reviewed mutation, current `ota assist declare-readiness`, `ota assist declare-service`, `ota assist bind-task`, `ota assist wire-setup`, `ota assist declare-env`, `ota assist add-task`, and `ota assist normalize` support, task versus managed-service targeting, reviewed target-edge binding, phased setup wiring, env declaration, task creation, canonical setup normalization, monorepo member behavior, refusal cases, and JSON integration. - https://ota.run/docs/attachments — Container Attachments. Guide to container attachments, repo-relative isolated_paths, effective /workspace path mapping, named-volume overlays, and cache examples for node_modules, .next, .m2, .npm, .pnpm-store, .gradle, .pip-cache, and .pypoetry-cache. - https://ota.run/docs/compose-attachments — Compose Attachments. Guide to attachments.compose, Compose-network attachment semantics, alignment with services..manager.name, and the split between host Compose control and container workload execution. - https://ota.run/docs/contexts — Execution Contexts. Guide to execution contexts, default context selection, task overrides, mode-aware branches, and how contexts connect services, readiness, and published endpoints. - https://ota.run/docs/contract-first-onboarding — Contract-First Repo Onboarding. Problem-first guide to contract-first repo onboarding, README drift, explicit setup paths, deterministic verification, and shared execution truth for humans, CI, and AI agents. - https://ota.run/docs/defining-readiness — Defining Readiness. Narrative operator guide to defining readiness in ota across env requirements, service dependencies, checks, verification tasks, and proof artifacts, with clear ownership boundaries for each surface. - https://ota.run/docs/environment-model — Environment Model. Guide to env.vars, env.sources, workspace and org policy precedence, context/task/mode execution env, OTA_WORKSPACE, derived cache env, and detect versus runtime boundaries. - https://ota.run/docs/faq — FAQ. Run `ota doctor` first. It tells you what is missing, even if `ota.yaml` does not exist yet. - https://ota.run/docs/first-ota-yaml — First `ota.yaml`. A starter contract should be obvious, stable, and runnable. - https://ota.run/docs/getting-started — Getting started. Entry guide for first-time users to diagnose readiness and establish the default ota workflow. - https://ota.run/docs/glossary — Glossary. Use this index for the nouns that show up throughout ota and the payoff each one gives you. - https://ota.run/docs/install — Install. Installation paths for release binaries and source-based local development. - https://ota.run/docs/local-topology-patterns — Local Topology Patterns. Adoption guidance for task target bindings, target activation, shared local container backends, and backend-scoped run-path fulfillment with links to canonical examples. - https://ota.run/docs/mode-aware-tasks — Mode-Aware Tasks. Guide to task-level mode-aware execution, default_mode, per-mode context plus lifecycle, CLI override precedence, and when to keep separate task names instead of splitting one task intent. - https://ota.run/docs/ota-vs-makefiles-ci-scripts — README Drift vs Contract-First Repo Onboarding. Comparison page on README drift, setup-script sprawl, and contract-first repo onboarding with ota alongside Makefiles, package scripts, Docker, Nix, and CI workflows. - https://ota.run/docs/policy-concepts — Policy concepts. Policy is the governance layer above `ota.yaml`. It decides what is required, what is approved, and how ota explains a mismatch when the repo and the org disagree. - https://ota.run/docs/readiness-model — Ota Readiness Model. Operator guide to the ota readiness model across task runtime readiness, service readiness, checks, workflow readiness, tcp versus http probes, listener reachability, app readiness, projected versus confirmed endpoints, and command behavior for doctor, check, up, and workspace flows. - https://ota.run/docs/repo-readiness — Repo Readiness. Search-oriented introduction to repo readiness, developer onboarding, CI readiness, and ota.yaml as the explicit readiness contract. - https://ota.run/docs/repository-automation-tools — Repository Automation Tools. Search-oriented comparison guide for repository automation tools, repo setup validation, CI readiness, GitHub Actions, Harness, Sonatype Nexus Repository, and ota. - https://ota.run/docs/surfaces — Runtime Surfaces. Guide to Ota runtime surfaces: reusable endpoint definitions, explicit task attachments, native list-form attachment, container attachment overrides, when to use surfaces instead of listener shorthand or full listeners, and how workflows use surfaces for readiness and exposes. - https://ota.run/docs/topology-guide — Topology decision guide. Decision guide for choosing the right requirement, service, and execution scope. - https://ota.run/docs/troubleshooting — Troubleshooting. Explicit paths should point at the repo you mean. If they do not, start there before assuming the contract is wrong. ## Intent: operate - https://ota.run/docs/agent-integration — ota.run Agent Integration. Agent integration guide for ota.run covering llms.txt, OpenAPI, official Ota skills, ota.yaml, JSON output, and safe CLI operation. - https://ota.run/docs/agent-quickstart — ota.run Agent Quickstart. Agent quickstart for using ota in a repository: discover docs, inspect ota.yaml, run doctor, validate, list safe tasks, copy examples, customize, execute, and parse JSON output. - https://ota.run/docs/ci-and-pipelines — CI and Pipelines. How to wire ota into CI without scraping text output. - https://ota.run/docs/quickstart — Quickstart. Fast operational path from diagnosis to first successful repo preparation. - https://ota.run/docs/reference/workspace — Workspace. Workspace contract and orchestration model for multi-repo readiness and execution. ## Intent: reference - https://ota.run/docs/developer-resources — ota.run Developer Resources. Developer resource directory for ota.run OpenAPI, OAuth 2.0 metadata, official Ota skills, llms.txt, docs index, blog index, GitHub Actions, and agent-safe setup. - https://ota.run/docs/reference — Reference. Reference hub for command behavior, contract semantics, and workspace orchestration. - https://ota.run/docs/reference/adapter-bootstrap — Adapter Bootstrap. Use this page when the machine or container does not already have the adapter binary ota needs to provision repo prerequisites. - https://ota.run/docs/reference/adapters — Adapters. Use this page when you want to know which adapter families ota can use for provisioning and why the split matters. - https://ota.run/docs/reference/audit-and-provenance — Audit and Provenance. If ota says a repo is ready, users should be able to answer what was declared, what was inferred, what came from policy, and what changed later. - https://ota.run/docs/reference/command — Command. Canonical command selection and usage guide for repo and workspace flows. - https://ota.run/docs/reference/compatibility-policy — Compatibility Policy. Version rules keep the contract predictable while ota evolves, so migrations stay reviewable instead of surprising. - https://ota.run/docs/reference/compatibility-surface — Compatibility Surface. Use this page when a tool, CI gate, or wrapper needs the command surface ota intends to keep stable. - https://ota.run/docs/reference/contract — Contract. Field-level specification for ota.yaml and how contract choices affect readiness and execution. - https://ota.run/docs/reference/doctor-finding-contract — Doctor Findings. A finding is the smallest stable unit in `doctor`, `workspace doctor`, and `explain`. - https://ota.run/docs/reference/environment-values — Environment Variables. Use this page when a repo needs environment variables and you want to know what ota will actually run with. - https://ota.run/docs/reference/execution-and-dockerfiles — Container Execution. Use this page when a repo already has a Dockerfile and you need to decide how ota fits around it. - https://ota.run/docs/reference/execution-governance-loop — Execution Governance Loop. Use this page when the question is architectural, not only command-local. - https://ota.run/docs/reference/execution-receipt — Execution Receipt. Read the receipt after a command runs if you need to audit what happened. - https://ota.run/docs/reference/execution-topology — Execution Topology. Use this page when the repo has more than one execution plane and the current backend model stops being honest. - https://ota.run/docs/reference/exit-codes — Exit Codes. Exit codes are the control signal for automation. - https://ota.run/docs/reference/extension-boundary — Extension Support. Extensions are explicit descriptors, not hidden runtime plugins. - https://ota.run/docs/reference/github-action — GitHub Action. Use `ota-run/action@v1` when GitHub Actions should publish the GitHub-native view of ota instead of forcing you to wire JSON parsing and artifact upload by hand. - https://ota.run/docs/reference/github-setup — GitHub Setup Action. Use `ota-run/setup@v1` when a GitHub Actions job needs ota on `PATH` for later direct commands such as `ota run setup`, `ota run ci`, or `ota run deploy`. - https://ota.run/docs/reference/governance — Open Core and Governance. Use this page when you want the project boundary in plain language before you invest in the CLI, docs, or ecosystem. - https://ota.run/docs/reference/hosted-validation — CI Validation. Hosted validation is the read-only CI path for ota. - https://ota.run/docs/reference/json-output — JSON Output. Use JSON when automation needs stable contract data instead of reading terminal prose. - https://ota.run/docs/reference/mutation-controls-and-caching — Writes and Caching. Use this page when you need to know what ota may change on disk and what it must leave alone. - https://ota.run/docs/reference/org-policy — Org Policy Baseline. This is the concrete policy file to use when an org wants a baseline that is strict enough to be useful and small enough to be adopted. - https://ota.run/docs/reference/output-style — Output Style. Use this page when you want to know what ota looks like in a terminal and what changes when you ask for plain output. - https://ota.run/docs/reference/ownership-layers — Ownership Layers. Use this page to decide where prerequisite truth belongs. - https://ota.run/docs/reference/policy-backed-provisioning — Provisioning Sources. Use this page when a repo needs a runtime or tool and the organization wants to say where it may come from. - https://ota.run/docs/reference/policy-packs — Policy Packs. Use this page when a platform or operations team wants one rule set to apply across many repos. - https://ota.run/docs/reference/remote-execution — Remote Execution. Remote execution should stay descriptive, inspectable, and visible to tools. - https://ota.run/docs/reference/semantic-diff-and-explain — Diff and Explain. `ota diff` shows what changed between two contract states. - https://ota.run/docs/reference/semantic-snapshots-and-correlation — Semantic Snapshots and Correlation. This is the reference page for archived semantic contract truth, not just for one diff command. - https://ota.run/docs/reference/service-behavior — Service Behavior. Treat services as declared readiness dependencies, not hidden setup steps. - https://ota.run/docs/reference/shell-semantics — Shell Behavior. Use this page when you need to know exactly how ota runs commands on the host. - https://ota.run/docs/reference/starter-packs — Starter Packs. Use this page when the question is not whether `ota init` exists, but which explicit starter pack should seed the first draft. - https://ota.run/docs/reference/support-policy — Platform support. Use this page to understand where ota is first-class today and where the behavior is narrower. - https://ota.run/docs/reference/task-aggregate — Task Aggregate. Use this page when a task exists only to run other tasks in a declared order. - https://ota.run/docs/reference/task-bodies — Task Bodies. Do not start from `run` by habit. - https://ota.run/docs/reference/task-launch — Task Launch. Use this page when you need to decide whether a task should use `run`, `script`, `command`, or `launch`. - https://ota.run/docs/reference/version-policy — Version Policy. Use this page when a repo should stay explicit about what it needs, but the org wants to constrain which versions may be declared. - https://ota.run/docs/reference/workflows — Workflows. A workflow is a named repo path that answers: ready for what? ## Start - https://ota.run/docs/getting-started — Getting started. Entry guide for first-time users to diagnose readiness and establish the default ota workflow. - https://ota.run/docs/install — Install. Installation paths for release binaries and source-based local development. - https://ota.run/docs/quickstart — Quickstart. Fast operational path from diagnosis to first successful repo preparation. - https://ota.run/docs/first-ota-yaml — First `ota.yaml`. A starter contract should be obvious, stable, and runnable. ## Reference - https://ota.run/docs/reference — Reference. Reference hub for command behavior, contract semantics, and workspace orchestration. - https://ota.run/docs/reference/command — Command. Canonical command selection and usage guide for repo and workspace flows. - https://ota.run/docs/reference/contract — Contract. Field-level specification for ota.yaml and how contract choices affect readiness and execution. - https://ota.run/docs/reference/task-bodies — Task Bodies. Do not start from `run` by habit. - https://ota.run/docs/reference/workspace — Workspace. Workspace contract and orchestration model for multi-repo readiness and execution. ## Concepts - https://ota.run/docs/repo-readiness — Repo Readiness. Search-oriented introduction to repo readiness, developer onboarding, CI readiness, and ota.yaml as the explicit readiness contract. - https://ota.run/docs/ai-agent-ready-repos — How to Make a Repo Ready for AI Coding Agents. Problem-first guide to AI-agent-ready repositories covering explicit setup, safe tasks, writable boundaries, verification, machine-readable output, and contract-first onboarding with ota. - https://ota.run/docs/contract-first-onboarding — Contract-First Repo Onboarding. Problem-first guide to contract-first repo onboarding, README drift, explicit setup paths, deterministic verification, and shared execution truth for humans, CI, and AI agents. - https://ota.run/docs/agent-safe-repo-setup — AI Agent Repo Setup. Guide to AI agent repo setup with ota.yaml, AGENTS.md guidance, safe tasks, verification, and machine-readable readiness output. - https://ota.run/docs/repository-automation-tools — Repository Automation Tools. Search-oriented comparison guide for repository automation tools, repo setup validation, CI readiness, GitHub Actions, Harness, Sonatype Nexus Repository, and ota. - https://ota.run/docs/ota-vs-makefiles-ci-scripts — README Drift vs Contract-First Repo Onboarding. Comparison page on README drift, setup-script sprawl, and contract-first repo onboarding with ota alongside Makefiles, package scripts, Docker, Nix, and CI workflows. ## Orientation - https://ota.run/docs/topology-guide — Topology decision guide. Decision guide for choosing the right requirement, service, and execution scope. - https://ota.run/docs/glossary — Glossary. Use this index for the nouns that show up throughout ota and the payoff each one gives you. ## Operate - https://ota.run/docs/ci-and-pipelines — CI and Pipelines. How to wire ota into CI without scraping text output. - https://ota.run/docs/contexts — Execution Contexts. Guide to execution contexts, default context selection, task overrides, mode-aware branches, and how contexts connect services, readiness, and published endpoints. - https://ota.run/docs/environment-model — Environment Model. Guide to env.vars, env.sources, workspace and org policy precedence, context/task/mode execution env, OTA_WORKSPACE, derived cache env, and detect versus runtime boundaries. - https://ota.run/docs/defining-readiness — Defining Readiness. Narrative operator guide to defining readiness in ota across env requirements, service dependencies, checks, verification tasks, and proof artifacts, with clear ownership boundaries for each surface. - https://ota.run/docs/assist — Ota Assist. Operator guide to ota assist, covering preview-first reviewed mutation, current `ota assist declare-readiness`, `ota assist declare-service`, `ota assist bind-task`, `ota assist wire-setup`, `ota assist declare-env`, `ota assist add-task`, and `ota assist normalize` support, task versus managed-service targeting, reviewed target-edge binding, phased setup wiring, env declaration, task creation, canonical setup normalization, monorepo member behavior, refusal cases, and JSON integration. - https://ota.run/docs/readiness-model — Ota Readiness Model. Operator guide to the ota readiness model across task runtime readiness, service readiness, checks, workflow readiness, tcp versus http probes, listener reachability, app readiness, projected versus confirmed endpoints, and command behavior for doctor, check, up, and workspace flows. - https://ota.run/docs/surfaces — Runtime Surfaces. Guide to Ota runtime surfaces: reusable endpoint definitions, explicit task attachments, native list-form attachment, container attachment overrides, when to use surfaces instead of listener shorthand or full listeners, and how workflows use surfaces for readiness and exposes. - https://ota.run/docs/attachments — Container Attachments. Guide to container attachments, repo-relative isolated_paths, effective /workspace path mapping, named-volume overlays, and cache examples for node_modules, .next, .m2, .npm, .pnpm-store, .gradle, .pip-cache, and .pypoetry-cache. - https://ota.run/docs/compose-attachments — Compose Attachments. Guide to attachments.compose, Compose-network attachment semantics, alignment with services..manager.name, and the split between host Compose control and container workload execution. - https://ota.run/docs/local-topology-patterns — Local Topology Patterns. Adoption guidance for task target bindings, target activation, shared local container backends, and backend-scoped run-path fulfillment with links to canonical examples. - https://ota.run/docs/mode-aware-tasks — Mode-Aware Tasks. Guide to task-level mode-aware execution, default_mode, per-mode context plus lifecycle, CLI override precedence, and when to keep separate task names instead of splitting one task intent. - https://ota.run/docs/reference/execution-and-dockerfiles — Container Execution. Use this page when a repo already has a Dockerfile and you need to decide how ota fits around it. - https://ota.run/docs/troubleshooting — Troubleshooting. Explicit paths should point at the repo you mean. If they do not, start there before assuming the contract is wrong. - https://ota.run/docs/faq — FAQ. Run `ota doctor` first. It tells you what is missing, even if `ota.yaml` does not exist yet. ## Automate - https://ota.run/docs/developer-resources — ota.run Developer Resources. Developer resource directory for ota.run OpenAPI, OAuth 2.0 metadata, official Ota skills, llms.txt, docs index, blog index, GitHub Actions, and agent-safe setup. - https://ota.run/docs/agent-integration — ota.run Agent Integration. Agent integration guide for ota.run covering llms.txt, OpenAPI, official Ota skills, ota.yaml, JSON output, and safe CLI operation. - https://ota.run/docs/agent-quickstart — ota.run Agent Quickstart. Agent quickstart for using ota in a repository: discover docs, inspect ota.yaml, run doctor, validate, list safe tasks, copy examples, customize, execute, and parse JSON output. - https://ota.run/docs/reference/json-output — JSON Output. Use JSON when automation needs stable contract data instead of reading terminal prose. - https://ota.run/docs/reference/execution-receipt — Execution Receipt. Read the receipt after a command runs if you need to audit what happened. - https://ota.run/docs/reference/exit-codes — Exit Codes. Exit codes are the control signal for automation. - https://ota.run/docs/reference/hosted-validation — CI Validation. Hosted validation is the read-only CI path for ota. ## Policy - https://ota.run/docs/policy-concepts — Policy concepts. Policy is the governance layer above `ota.yaml`. It decides what is required, what is approved, and how ota explains a mismatch when the repo and the org disagree. - https://ota.run/docs/reference/policy-packs — Policy Packs. Use this page when a platform or operations team wants one rule set to apply across many repos. - https://ota.run/docs/reference/org-policy — Org Policy Baseline. This is the concrete policy file to use when an org wants a baseline that is strict enough to be useful and small enough to be adopted. - https://ota.run/docs/reference/environment-values — Environment Variables. Use this page when a repo needs environment variables and you want to know what ota will actually run with. - https://ota.run/docs/reference/version-policy — Version Policy. Use this page when a repo should stay explicit about what it needs, but the org wants to constrain which versions may be declared. - https://ota.run/docs/reference/policy-backed-provisioning — Provisioning Sources. Use this page when a repo needs a runtime or tool and the organization wants to say where it may come from. - https://ota.run/docs/reference/adapters — Adapters. Use this page when you want to know which adapter families ota can use for provisioning and why the split matters. ## Examples - https://ota.run/docs/examples — Examples. Curated contract examples organized by runtime, topology, and policy shape. - https://ota.run/docs/examples/node — Node repos with a managed runtime and explicit Corepack lane. This is the current honest Node toolchain boundary: `toolchains.node` owns the runtime, `node` executable, and declared Corepack package-manager activation. - https://ota.run/docs/examples/python — Python repos with a clean setup path. A Python contract that makes setup, tests, and CI explicit. - https://ota.run/docs/examples/tool-acquisition — Workflow-scoped acquisition without repo-global install drift. Use this when the repo has more than one honest front door and each one should carry its own acquisition lane instead of inheriting repo-global prerequisites. - https://ota.run/docs/examples/windows-adoption — Windows-first adoption with explicit native activation. Use this when the repo is Windows-first, PowerShell is part of the real release path, and you still want one contract that humans, CI, and agents can trust across platforms. - https://ota.run/docs/examples/go — Go repos with a deterministic loop. This example keeps the Go path short: fetch dependencies, run tests, and keep the repo honest with one verification task. - https://ota.run/docs/examples/go-sdk — Go SDKs with explicit build and release flow. This example treats the SDK as a product surface: the core loop stays short, and the release path is documented in the task notes. - https://ota.run/docs/examples/java — Java repos with a Maven build gate. This example shows the shipped Java toolchain boundary: `toolchains.java` owns `java` and `javac`, while Maven stays explicitly under `tools`. - https://ota.run/docs/examples/dotnet — .NET repos with restore, build, and test. This example keeps the .NET flow deterministic: restore dependencies, build the project, then run tests. - https://ota.run/docs/examples/rust — Rust repos with a Rustup-backed toolchain. This example is the boring, reliable Rust path with the shipped toolchain model: declare one Rustup-backed toolchain, hydrate Cargo dependencies structurally once, then run formatter, build, and tests through that owner. - https://ota.run/docs/examples/script — Script-driven repos with a real contract. This example shows that a repo can be mostly scripts and still have a strict readiness contract. - https://ota.run/docs/examples/services — Service repos with explicit readiness. A service contract that keeps healthchecks, setup, and readiness visible. - https://ota.run/docs/examples/action-reset-compose-service-volume — Compose-managed service volume reset without shell glue. Use this when one destructive local recovery lane honestly owns stopping a Compose-managed service, removing one named volume, and restarting the service. - https://ota.run/docs/examples/topology/compose-postgres — Container app with Compose Postgres. Use this when the app should run in a container context but service orchestration should stay on the host control plane. - https://ota.run/docs/examples/topology/host-postgres — Container app with host Postgres. Use this when the workload should stay in a container context but the database is owned by the host machine instead of Compose. - https://ota.run/docs/examples/mixed/node-python — Mixed Node and Python repos without ownership drift. This example shows a mixed-stack repo where the contract needs to protect both runtimes without hiding either one. - https://ota.run/docs/examples/fullstack/node-go — Fullstack Node and Go repos with a split service path. This example keeps the frontend and backend visible in the contract so a change in one path cannot silently hide the other. - https://ota.run/docs/examples/full-contract — Full contracts for complex repos. This example shows the broadest repo-local contract shape in one place so teams can see how the pieces fit together. - https://ota.run/docs/examples/provisioning-policy — Policy and provisioning. Use this when the repo should declare what it needs and the organization should decide where those installs come from. - https://ota.run/docs/examples/container-provisioning — Container provisioning. Use this when you want ota to make the container ready instead of asking every developer machine to carry the setup cost. ## Workspace examples - https://ota.run/docs/examples/workspace/basic — Multi-repo basics. Use this shape when a workspace needs to coordinate several repos without flattening their contracts. - https://ota.run/docs/examples/workspace/acquire — Acquire from Git. Use this when a workspace needs to bring missing repos onto disk before any bootstrap, setup, or task execution can happen. ## Operational reference - https://ota.run/docs/reference/workflows — Workflows. A workflow is a named repo path that answers: ready for what? - https://ota.run/docs/reference/ownership-layers — Ownership Layers. Use this page to decide where prerequisite truth belongs. - https://ota.run/docs/reference/github-action — GitHub Action. Use `ota-run/action@v1` when GitHub Actions should publish the GitHub-native view of ota instead of forcing you to wire JSON parsing and artifact upload by hand. - https://ota.run/docs/reference/github-setup — GitHub Setup Action. Use `ota-run/setup@v1` when a GitHub Actions job needs ota on `PATH` for later direct commands such as `ota run setup`, `ota run ci`, or `ota run deploy`. - https://ota.run/docs/reference/governance — Open Core and Governance. Use this page when you want the project boundary in plain language before you invest in the CLI, docs, or ecosystem. - https://ota.run/docs/reference/doctor-finding-contract — Doctor Findings. A finding is the smallest stable unit in `doctor`, `workspace doctor`, and `explain`. - https://ota.run/docs/reference/execution-governance-loop — Execution Governance Loop. Use this page when the question is architectural, not only command-local. - https://ota.run/docs/reference/audit-and-provenance — Audit and Provenance. If ota says a repo is ready, users should be able to answer what was declared, what was inferred, what came from policy, and what changed later. - https://ota.run/docs/reference/compatibility-policy — Compatibility Policy. Version rules keep the contract predictable while ota evolves, so migrations stay reviewable instead of surprising. - https://ota.run/docs/reference/compatibility-surface — Compatibility Surface. Use this page when a tool, CI gate, or wrapper needs the command surface ota intends to keep stable. - https://ota.run/docs/reference/starter-packs — Starter Packs. Use this page when the question is not whether `ota init` exists, but which explicit starter pack should seed the first draft. - https://ota.run/docs/reference/mutation-controls-and-caching — Writes and Caching. Use this page when you need to know what ota may change on disk and what it must leave alone. - https://ota.run/docs/reference/output-style — Output Style. Use this page when you want to know what ota looks like in a terminal and what changes when you ask for plain output. - https://ota.run/docs/reference/service-behavior — Service Behavior. Treat services as declared readiness dependencies, not hidden setup steps. - https://ota.run/docs/reference/task-aggregate — Task Aggregate. Use this page when a task exists only to run other tasks in a declared order. - https://ota.run/docs/reference/task-launch — Task Launch. Use this page when you need to decide whether a task should use `run`, `script`, `command`, or `launch`. - https://ota.run/docs/reference/execution-topology — Execution Topology. Use this page when the repo has more than one execution plane and the current backend model stops being honest. - https://ota.run/docs/reference/shell-semantics — Shell Behavior. Use this page when you need to know exactly how ota runs commands on the host. - https://ota.run/docs/reference/support-policy — Platform support. Use this page to understand where ota is first-class today and where the behavior is narrower. - https://ota.run/docs/reference/remote-execution — Remote Execution. Remote execution should stay descriptive, inspectable, and visible to tools. - https://ota.run/docs/reference/semantic-diff-and-explain — Diff and Explain. `ota diff` shows what changed between two contract states. - https://ota.run/docs/reference/semantic-snapshots-and-correlation — Semantic Snapshots and Correlation. This is the reference page for archived semantic contract truth, not just for one diff command. - https://ota.run/docs/reference/extension-boundary — Extension Support. Extensions are explicit descriptors, not hidden runtime plugins. ## Additional docs - https://ota.run/docs/examples/action-ensure-bundle — Bundled deterministic setup without shell orchestration. Use this when one setup task honestly owns several deterministic setup actions and they should still stay in one governed action body. - https://ota.run/docs/examples/action-ensure-container-network — Container network bootstrap. Use this when one setup lane honestly owns shared Docker network readiness and should not disappear into shell conditionals. - https://ota.run/docs/examples/action-ensure-env-file — Deterministic env bootstrap without shell copy-plus-`sed` glue. Use this when env bootstrap is one deterministic host-file mutation and should stay inspectable in the contract. - https://ota.run/docs/examples/action-ensure-git-checkout — Deterministic git checkout bootstrap. Use this when one setup lane honestly owns materializing a repo-local checkout and that truth should stay on a first-class deterministic action surface instead of hiding in shell bootstrap glue. - https://ota.run/docs/examples/action-ensure-git-template — Deterministic git template bootstrap. Use this when one setup lane honestly owns turning a Git-backed scaffold into a fresh local repository and that truth should stay on a first-class deterministic action surface instead of hiding in bootstrap shell glue. - https://ota.run/docs/examples/bake-adapter-inputs — Bake adapter ownership without shell cwd or `-f` drift. Use this when the task is really a Bake invocation and the hard part is keeping the adapter root plus file stack explicit instead of burying them in shell glue. - https://ota.run/docs/examples/podman-compose-adapter-inputs — Podman compose adapter ownership without shell env/file drift. Use this when the repo really runs through `podman compose` and ota should own that choice directly instead of treating Podman as shell-only compose drift. - https://ota.run/docs/examples/rust-toolchain — Rust toolchain ownership without duplicate runtime/tool drift. Use this when a Rust repo should treat Rust as one provider-backed ecosystem instead of repeating the same ownership across `runtimes`, `tools`, and setup scripts. - https://ota.run/docs/examples/systemd-host-service — Typed systemd host-service ownership without shell lifecycle drift. Use this when the repo's service truth is a systemd unit on the host and ota should own lifecycle and readiness directly. - https://ota.run/docs/examples/topology/node-isolated — Container app with isolated `node_modules`. Use this when a Node app runs in a container context but the host checkout already has dependency artifacts that should not leak into the container runtime. - https://ota.run/docs/reference/adapter-bootstrap — Adapter Bootstrap. Use this page when the machine or container does not already have the adapter binary ota needs to provision repo prerequisites. ## Blog - https://ota.run/blog/why-agent-safety-needs-enforced-boundaries-not-just-declared-ones-4m7q — Why Agent Safety Needs Enforced Boundaries, Not Just Declared Ones. Agent safety does not come from declared safe tasks and protected paths alone. It comes from runners, CI, and runtime boundaries actually enforcing the same repo contract so drift breaks visibly instead of becoming one more soft signal. - https://ota.run/blog/setup-automation-is-not-readiness-verification-4t2m — Setup Automation Is Not Readiness Verification. Automating setup does not prove a repository is ready. Ota takes a stricter position: repo readiness needs contract-owned verification, explicit execution truth, and machine-readable evidence for humans, CI, and AI agents. - https://ota.run/blog/from-execution-logs-to-governance-verdicts-in-ota — From Execution Logs to Governance Verdicts in Ota. Ota is moving repo execution from raw logs and implied intent to machine-readable governance verdicts that say what was allowed, refused, required, and actually evidenced. - https://ota.run/blog/pressure-testing-ota-on-orchardcore-3d2m — Pressure-testing Ota on OrchardCore: first-class dotnet restore and honest narrow .NET proof. How OrchardCore helped prove Ota's .NET contract story on a real ASP.NET Core repo: toolchain-owned dotnet truth, first-class dotnet restore hydration, structured finite dotnet commands, and disciplined narrowing to one truthful contributor slice. - https://ota.run/blog/making-ota-governance-output-machine-readable-4m8q — Making Ota Governance Output Machine-Readable. Most repo governance still lives in prose and tribal memory. Ota turns governance into machine-readable contract, execution, and receipt output so humans and AI agents can run the same trustworthy operational path. - https://ota.run/blog/ota-v1-6-23-release-essay — Ota v1.6.23 Now Available: Machine-Readable Execution Governance. Ota v1.6.23 strengthens machine-readable execution governance with explicit merge gates, stage-family output, crossing evidence, agent-safe enforcement, and broader first-class setup/orchestrator ownership. - https://ota.run/blog/ota-vs-github-managed-settings — GitHub Managed Settings vs Ota: Platform Governance vs Execution Governance. GitHub Managed Settings standardizes repository configuration. Ota standardizes how repositories are prepared, verified, and run. Modern engineering teams need both. - https://ota.run/blog/why-coding-agents-need-repo-contracts-not-bigger-context-windows — Why Coding Agents Need Repo Contracts, Not Bigger Context Windows. Bigger context windows help agents read more, but repo contracts help them act safely by making setup, verification, services, env, and task boundaries explicit. - https://ota.run/blog/pressure-testing-ota-on-cal-diy-2r4m — Pressure-testing Ota on Cal.diy: native, quickstart, and Docker runtime truth in one contract. How Cal.diy proved that Ota can hold native development, native production startup, Docker quickstart, and Compose deployment paths inside one explicit execution-governance contract. - https://ota.run/blog/ota-vs-dagger-portable-workflows-are-not-repo-execution-governance-4n2p — Ota vs Dagger: Portable Workflows Are Not Repo Execution Governance. Dagger makes workflows portable and programmable. Ota makes repositories diagnosable, governable, and provable before, during, and after execution. Workflow portability is useful, but it does not replace repo readiness, safe task boundaries, or receipts. - https://ota.run/blog/pressure-testing-ota-on-directus-2u6q — Pressure-testing Ota on Directus: structured pnpm hydration and honest workflow boundaries. How Directus helped prove a mature pnpm/Corepack contributor-readiness shape in Ota: first-class dependency hydration, a lean default verification path, and explicit separation between safe contributor checks and heavier recursive or Docker-backed repo surfaces. - https://ota.run/blog/pressure-testing-ota-on-strapi-2s7p — Pressure-testing Ota on Strapi: structured Yarn hydration and truthful contributor verification. How Strapi proved a strong current Ota contributor-readiness shape: structured Yarn hydration, aggregate verification, command-owned task bodies, and contract-driven CI install truth. - https://ota.run/blog/agents-md-is-not-enough-for-safe-ai-agent-execution — AGENTS.md Is Not Enough for Safe AI Agent Execution. AGENTS.md can guide an AI coding agent, but it cannot by itself make execution safe, verifiable, or reviewable. Repos also need declared safe commands, canonical verification paths, and receipts that show what actually ran. - https://ota.run/blog/ota-v1-6-22-release-essay — Ota v1.6.22 Now available. Ota v1.6.22 expands execution governance across workspace orchestration, structured setup, Compose ownership, workflow instances, and semantic contract evidence. - https://ota.run/blog/npm-test-passed-ota-still-caught-missing-repo-setup-truth — npm test passed. Ota still caught missing repo setup truth.. A passing `npm test` run does not prove a repo is ready. This technical demo shows how Ota catches missing env, service, generated-file, and workflow setup truth that unit tests alone never prove. - https://ota.run/blog/pressure-testing-ota-on-backstage-3p4n — Pressure-testing Ota on Backstage: repo-managed tool probes, Yarn 4 hydration, and Docker-backed contributor proof. How Backstage forced Ota to tighten repo-managed release-asset tool probing, prove a narrow Yarn 4 contributor slice honestly, and keep Docker-backed runtime ownership explicit instead of hiding it in shell glue. - https://ota.run/blog/github-repository-onboarding-checklist-for-new-contributors-263z — Your GitHub Repository Isn't Ready for New Contributors: A Practical Onboarding Checklist. Most onboarding advice focuses on documentation. The harder problem is making a repository executable, verifiable, and governable from the first command. - https://ota.run/blog/how-ota-explains-contract-drift-against-new-failures — How Ota Explains Contract Drift Against New Failures. Ota can now archive semantic contract truth, diff normalized assumptions, and explain whether new blockers are likely related to contract drift without pretending every failure has one certain cause. - https://ota.run/blog/pressure-testing-ota-on-outline-2n5d — Pressure-testing Ota on Outline: keeping lean verification truthful in a service-heavy repo. How Outline helped prove that Ota’s newer structured dependency hydration, aggregate verification, and workflow intent surfaces can keep default verification honest in a service-heavy Node repo without pretending every path should be part of the default proof lane. - https://ota.run/blog/what-belongs-in-agents-md-vs-ota-yaml — What Belongs in AGENTS.md vs ota.yaml. AGENTS.md should hold guidance and repo-specific caution. ota.yaml should hold execution, readiness, verification, and safe task truth. The strongest repos use both for different jobs. - https://ota.run/blog/ota-vs-aspire-repo-readiness-vs-application-orchestration-4d2p — Ota vs Aspire: Repo Readiness vs Application Orchestration. Aspire helps compose and run distributed applications, especially in the .NET ecosystem. Ota helps make the repository itself operationally explicit: setup, workflows, readiness, verification, and safe execution for humans, CI, and AI agents. - https://ota.run/blog/pressure-testing-ota-on-langfuse-3v8q — Pressure-testing Ota on Langfuse: env overlays, Compose truth, and honest workflow boundaries. How Langfuse forced Ota to separate source-dev env truth from Compose runtime env truth, move Docker Compose adapter inputs into the contract, and keep workflow diagnosis exact instead of hand-wavy. - https://ota.run/blog/pressure-testing-ota-on-flowise-2m4p — Pressure-testing Ota on Flowise: fixing Windows truth without weakening the contract. How Flowise pressure-testing closed Ota’s Windows wrapper-probe gaps and produced a truthful cross-OS contract for native, container, and Docker runtime paths. - https://ota.run/blog/pressure-testing-ota-on-immich-3n7p — Pressure-testing Ota on Immich: orchestrators, fulfillment, and first-class prepare. How Immich forced Ota to grow from provider-coupled toolchains and shell setup glue into a stronger orchestration, fulfillment, and preparation model, especially around `mise`-mediated execution. - https://ota.run/blog/what-real-repos-taught-us-about-repo-readiness-2q7m — What Real Repos Taught Us About Repo Readiness. Pressure-testing real repositories exposed the same pattern again and again: the code could run, but the repo could not clearly declare its front door, prerequisites, readiness meaning, or safe execution boundary. That is the gap Ota is built to close. - https://ota.run/blog/ota-v1-6-21-release-essay — Ota v1.6.21 Now available. Ota v1.6.21 turns more install, tool, Helm, and working-directory behavior into declared contract truth, so repos can stop hiding execution ownership inside shell glue and CI folklore. - https://ota.run/blog/how-ota-prevents-environment-variable-drift-in-repo-setup-6f2d — How Ota Prevents Environment Variable Drift in Repo Setup. Undocumented environment variables are setup drift. Ota makes required env names, allowed source files, deterministic local env bootstrap, and workflow-specific env overlays explicit so humans and AI agents stop guessing. - https://ota.run/blog/why-shell-scripts-and-ci-are-not-enough-for-repo-readiness-6t4m — Why Shell Scripts and CI Are Not Enough for Repo Readiness. Shell scripts and CI can make a repo runnable without making it operationally clear. Repo readiness needs one declared contract for workflows, prerequisites, readiness, verification, and safe execution for humans and AI agents. - https://ota.run/blog/your-documentation-isnt-the-problem-your-governance-is — Your Documentation Isn't the Problem. Your Governance Is.. Most repository failures are not caused by missing documentation. They happen because important execution rules are still carried by prose instead of governed through a shared contract. - https://ota.run/blog/pressure-testing-ota-on-ollama-2v4r — Pressure-testing Ota on Ollama: Go module hydration and honest source-runtime proof. How Ollama pushed Ota to model Go module hydration as a first-class preparation phase and sharpened the boundary between source-runtime proof, built binaries, and contract correction. - https://ota.run/blog/why-ota-treats-setup-failures-as-contract-signals-2p7n — Why Ota Treats Setup Failures as Contract Signals. Ota does not treat setup failure as vague automation noise. When `ota up` cannot make the selected repo path ready from declared truth, that failure is a meaningful contract signal first, with repair guidance attached second. - https://ota.run/blog/software-execution-governance-starts-before-production — Software Execution Governance Starts Before Production. Most teams think governance begins at deployment. In reality, execution governance starts the moment someone runs a repository, because setup, services, secrets, verification, and agent permissions all begin there. - https://ota.run/blog/ota-v1-6-20-release-essay — Ota v1.6.20 Now available. Ota v1.6.20 turns more of execution truth into governed public surface: published contract schemas, stable doctor finding identity, first-class environment ownership, structured dependency hydration, orchestration-aware execution, and stronger service topology modeling. - https://ota.run/blog/pressure-testing-ota-on-athena-api-2t6k — Pressure-testing Ota on athena-api: Bundler hydration, workflow truth, and governed service launch. How athena-api forced Ota to harden Bundler dependency hydration, Windows shell behavior, workflow-scoped service truth, the GitHub Actions installer contract, and the governance story around `launch.kind: command`. - https://ota.run/blog/why-tribal-knowledge-breaks-repos-for-ai-agents — Why Tribal Knowledge Breaks Repos for AI Agents. Repos break for AI agents when setup truth lives in maintainer memory, stale README steps, and undocumented execution paths. Ota replaces tribal knowledge with declared execution governance. - https://ota.run/blog/repo-setup-automation-without-readme-drift-8w6n — Repo Setup Automation Should Not Depend on README Drift. README-driven setup is weak automation architecture. Ota replaces README drift with one explicit repo contract for setup, canonical workflows, verification, and safe execution. - https://ota.run/blog/why-developer-onboarding-should-be-contract-first — Why Developer Onboarding Should Be Contract-First. Developer onboarding breaks when setup truth lives in READMEs, scripts, CI files, and maintainer memory. Ota turns onboarding into a declared repo contract with explicit setup, canonical workflows, verification, and safe execution. - https://ota.run/blog/running-an-unfamiliar-repo-is-a-security-boundary — Running an Unfamiliar Repo Is a Security Boundary. Running an unfamiliar repo is not neutral. The first run can install packages, execute scripts, request secrets, start services, and touch external systems. Ota makes first-run repo execution inspectable before humans or AI agents run it. - https://ota.run/blog/pressure-testing-ota-on-twenty-3k6n — Pressure-testing Ota on twenty: one contract for monorepo CI, local dev, integration, and self-host. How twenty pressure-testing turned a real monorepo’s contributor, CI, service-backed integration, and Docker self-host paths into one explicit readiness contract. - https://ota.run/blog/ai-agent-safety-needs-stop-signs-not-just-instructions — AI Agent Safety Needs Stop Signs, Not Just Instructions. AI agents need more than repo instructions. They need explicit stopping rules for secrets, unsafe commands, protected paths, external services, and approval boundaries. Ota makes those boundaries enforceable at the repo level. - https://ota.run/blog/pressure-testing-ota-on-discourse-2h7m — Pressure-testing Ota on Discourse: repo-wrapper truth matters more than a passing bundle command. How pressure-testing Discourse exposed the difference between plain bundle availability and the repo’s actual Bundler truth, and why Ota should model the wrapper the repo really depends on. - https://ota.run/blog/ota-v1-6-19-release-essay — Ota v1.6.19 Now available. Ota v1.6.19 tightens execution trust by making selected-path diagnosis, toolchain ownership, runtime evidence, service scoping, and effect policies more accurate, enforceable, and easier to understand before a repo runs. - https://ota.run/blog/ota-vs-taskfile-5r1k — Ota vs Taskfile. Taskfile makes command discovery cleaner. Ota makes command meaning explicit: readiness, canonical tasks, verification, and safe agent execution. Clean task names help, but they do not decide what counts. - https://ota.run/blog/diagnose-with-ota-then-run-with-confidence — Diagnose with Ota, Then Run with Confidence. Ota turns hidden repo blockers into clear next actions and a ready execution path, so humans and AI agents can diagnose first and run with confidence. - https://ota.run/blog/ota-vs-nix-4q2c — Ota vs Nix. Nix gives AI agents a reproducible environment. Ota gives them repo authority: setup, canonical tasks, verification, and safe execution. Reproducibility is valuable, but it is not workflow truth. - https://ota.run/blog/ota-vs-devcontainers-2n7d — Ota vs Dev Containers. Dev Containers give AI agents a cleaner workspace. Ota gives them the repo contract: setup, task truth, verification, and safe execution. Container parity is useful, but it is not execution truth. - https://ota.run/blog/runnable-repo-vs-trustworthy-repo — Why a Runnable Repo Is Not Always a Trustworthy Repo. Running a repo is not the same as trusting its setup, execution path, safety boundaries, or verification results. Ota helps close that gap by turning execution truth into a declared contract. - https://ota.run/blog/best-repo-automation-tools-for-ai-agents-3m8q — Best Repo Automation Tools for AI Agents. Ota is the strongest tool for AI-agent repo readiness because it models repo truth in an explicit contract. The rest of the stack supports layers that Ota governs. - https://ota.run/blog/agents-md-vs-ota-yaml-instructions-vs-readiness-contracts — AGENTS.md vs ota.yaml: Instructions vs Readiness Contracts for AI Agents. AGENTS.md helps AI agents follow repo instructions, but ota.yaml makes setup, safe tasks, and verification executable and verifiable. - https://ota.run/blog/pressure-testing-ota-on-osiris-4k2m — Pressure-testing Ota on Osiris: making runtime proof and Docker paths honest. How Osiris pressure-testing hardened Ota’s detached runtime semantics, runtime proof behavior, and contract modeling for documented Docker paths. - https://ota.run/blog/pressure-testing-ota-on-hoppscotch-2f8m — Pressure-testing Ota on Hoppscotch: from runnable commands to execution governance. How Hoppscotch pressure-testing hardened Ota contract scope, cross-OS workflow proof, and non-internal task execution coverage. - https://ota.run/blog/pressure-testing-ota-on-openhands-2q9k — Pressure-testing Ota on OpenHands: from setup fragmentation to execution governance. How OpenHands pressure-testing hardened Ota’s contract and matrix behavior across native, container, and runtime-proof lanes. - https://ota.run/blog/ota-v1-6-18-release-essay — Ota v1.6.18 Now available. v1.6.18 bounds runtime proof, hardens container execution, and makes task conditions, Corepack lanes, and agent-safe effects more explicit. - https://ota.run/blog/first-slice-to-full-pressure-test — From First Slice to Full Pressure Test: Raising the Readiness Bar Across Real Repos. A narrow readiness slice can validate structure, but full trust comes from pressure-testing execution claims, mode symmetry, and agent safety across real repositories. - https://ota.run/blog/how-to-align-local-ci-and-agent-execution — How to Align Local, CI, and Agent Execution. Repos break when local development, CI, and AI agents do not share the same setup, canonical tasks, and verification path. Ota fixes that drift by giving the repo one declared execution contract. - https://ota.run/blog/the-ota-skill-for-ai-agents — The Ota Skill for AI Agents. The Ota skill gives coding agents a clear operating guide for repo readiness, ota.yaml contracts, safe commands, and review boundaries. - https://ota.run/blog/pressure-testing-ota-real-repos-shipping-fixes — Pressure-Testing Ota in Real Repos and Shipping the Fixes. From real repo failures to product fixes: scoped requirement resolution, safer agent boundaries, deterministic bootstrap actions, and clearer readiness semantics. - https://ota.run/blog/ota-v1-6-17-release-essay — Ota v1.6.17 Now available. v1.6.17 hardens scoped requirement resolution, deterministic bootstrap, and machine-stable readiness output for humans and agents. - https://ota.run/blog/is-ota-another-makefile-56bh — Is Ota another Makefile?. One question about Ota keeps coming up: 'Isn't this just a Makefile with extra steps?' It's a fair... - https://ota.run/blog/ota-v1-6-16-release-essay — Ota v1.6.16 Now available. v1.6.16 makes version identity machine-readable, strengthens minimum-version enforcement, and improves agent-safe contract boundaries. - https://ota.run/blog/stop-asking-ai-agents-to-guess-how-your-repo-works-2olh — Stop Asking AI Agents to Guess How Your Repo Works. AI coding agents work better when your repo has explicit readiness: declared setup, tasks, checks, workflows, and safe agent boundaries. - https://ota.run/blog/why-readme-driven-infrastructure-breaks-for-ai-agents-4b2o — Why README-Driven Infrastructure Breaks for AI Agents. A README is supposed to be the front door of a software project. It tells people what the repo does,... - https://ota.run/blog/pressure-testing-ota-on-supabase-from-setup-prose-to-executable-repo-readiness-1ion — Pressure-testing Ota on Supabase: from setup prose to executable repo readiness. A technical write-up on integrating Ota into Supabase, keeping the upstream PR lean, and using a full pressure branch to expose and fix real Ota platform gaps. - https://ota.run/blog/what-should-happen-when-a-repo-does-not-run-31ai — What Should Happen When a Repo Does Not Run?. Most repos still fail in a manual way. `ota doctor` turns that failure into a structured readiness diagnosis for humans and agents. - https://ota.run/blog/ota-v1-6-15-release-essay — Ota v1.6.15 Now available. v1.6.15 hardens selected-mode execution, service proof reliability, and runtime-proof diagnostics for safer automation. - https://ota.run/blog/pressure-testing-ota-on-n8n-a-closed-pr-that-still-proved-the-point-1jf3 — Pressure Testing Ota on n8n: A Closed PR That Still Proved the Point. How pressure-testing n8n proved Ota could model a complex monorepo honestly, even when upstream maintainers chose not to adopt an extra readiness layer. - https://ota.run/blog/repo-readiness-for-ai-agents-the-complete-guide-3acm — Repo Readiness for AI Agents: The Complete Guide. Software repositories were already difficult to onboard into before AI agents entered the... - https://ota.run/blog/ota-v1-6-13-release-essay — Ota v1.6.13 Now available. v1.6.13 makes run previews, service readiness, JSON contracts, and toolchain ownership more explicit across local, CI, and agent workflows. - https://ota.run/blog/why-working-repos-still-fail-new-contributors-3hlg — Why Working Repos Still Fail New Contributors. Maintaining a software project is not only about keeping the code working. It is also about keeping... - https://ota.run/blog/ota-v1-6-12-release-essay — Ota v1.6.12 Now available. v1.6.12 makes workflow preparation, task-scoped env, native provisioning, and service readiness more deterministic across selected execution paths. - https://ota.run/blog/making-repository-readiness-machine-readable-4c8i — Making Repository Readiness Machine-Readable. Most repositories are built for people who already know them. That works for a while. The maintainer... - https://ota.run/blog/ota-v1-6-10-release-essay — Ota v1.6.10 Now available. v1.6.10 makes workflow preparation, task-scoped prerequisites, native provisioning, and runtime proof more explicit on the selected path. - https://ota.run/blog/conditions-that-make-a-repo-work — The Conditions That Make a Repo Work. The hardest part of onboarding into a repo usually is not understanding the code. It is discovering the hidden setup, execution, and readiness conditions that made the repo work in the first place. - https://ota.run/blog/how-do-you-know-a-repo-is-actually-ready-3hpo — How Do You Know A Repo Is Actually “Ready”?. Why does getting a repo running still feel so fragile? You clone a project, follow the setup steps,... ## Section index - https://ota.run/docs/agent-integration#agent-integration-1-agent-discovery-order — ota.run Agent Integration — Agent discovery order - https://ota.run/docs/agent-integration#agent-integration-2-repository-operation-order — ota.run Agent Integration — Repository operation order - https://ota.run/docs/agent-integration#agent-integration-3-boundaries-agents-must-preserve — ota.run Agent Integration — Boundaries agents must preserve - https://ota.run/docs/agent-integration#agent-integration-4-integration-surfaces — ota.run Agent Integration — Integration surfaces - https://ota.run/docs/agent-quickstart#agent-quickstart-1-start-from-discovery — ota.run Agent Quickstart — Start from discovery - https://ota.run/docs/agent-quickstart#agent-quickstart-2-inspect-the-repo-contract — ota.run Agent Quickstart — Inspect the repo contract - https://ota.run/docs/agent-quickstart#agent-quickstart-3-copy-customize-validate-execute — ota.run Agent Quickstart — Copy, customize, validate, execute - https://ota.run/docs/agent-quickstart#agent-quickstart-4-when-to-stop — ota.run Agent Quickstart — When to stop - https://ota.run/docs/agent-safe-repo-setup#agent-safe-repo-setup-1-why-agents-need-a-contract — AI Agent Repo Setup — Why agents need a contract - https://ota.run/docs/agent-safe-repo-setup#agent-safe-repo-setup-2-ai-agent-repo-setup-flow — AI Agent Repo Setup — AI agent repo setup flow - https://ota.run/docs/agent-safe-repo-setup#agent-safe-repo-setup-3-what-the-agent-can-rely-on — AI Agent Repo Setup — What the agent can rely on - https://ota.run/docs/agent-safe-repo-setup#agent-safe-repo-setup-4-machine-readable-handoff — AI Agent Repo Setup — Machine-readable handoff - https://ota.run/docs/ai-agent-ready-repos#ai-agent-ready-repos-1-what-ai-agent-ready-means — How to Make a Repo Ready for AI Coding Agents — What AI-agent-ready means - https://ota.run/docs/ai-agent-ready-repos#ai-agent-ready-repos-2-why-most-repos-are-not-ready-for-agents — How to Make a Repo Ready for AI Coding Agents — Why most repos are not ready for agents - https://ota.run/docs/ai-agent-ready-repos#ai-agent-ready-repos-3-what-agents-actually-need-from-a-repo — How to Make a Repo Ready for AI Coding Agents — What agents actually need from a repo - https://ota.run/docs/ai-agent-ready-repos#ai-agent-ready-repos-4-the-contract-first-onboarding-flow — How to Make a Repo Ready for AI Coding Agents — The contract-first onboarding flow - https://ota.run/docs/ai-agent-ready-repos#ai-agent-ready-repos-5-what-good-looks-like — How to Make a Repo Ready for AI Coding Agents — What good looks like - https://ota.run/docs/assist#assist-1-why-assist-exists — Ota Assist — Why assist exists - https://ota.run/docs/assist#assist-10-canonical-setup-normalization — Ota Assist — Canonical setup normalization - https://ota.run/docs/assist#assist-11-when-assist-refuses — Ota Assist — When assist refuses - https://ota.run/docs/assist#assist-12-json-and-schema — Ota Assist — JSON and schema - https://ota.run/docs/assist#assist-2-current-shipped-operations — Ota Assist — Current shipped operations - https://ota.run/docs/assist#assist-3-task-runtime-examples — Ota Assist — Task runtime examples - https://ota.run/docs/assist#assist-4-managed-service-examples — Ota Assist — Managed service examples - https://ota.run/docs/assist#assist-5-monorepo-member-behavior — Ota Assist — Monorepo member behavior - https://ota.run/docs/assist#assist-6-task-binding-examples — Ota Assist — Task binding examples - https://ota.run/docs/assist#assist-7-setup-wiring-examples — Ota Assist — Setup wiring examples - https://ota.run/docs/assist#assist-8-env-declaration-examples — Ota Assist — Env declaration examples - https://ota.run/docs/assist#assist-9-task-creation-examples — Ota Assist — Task creation examples - https://ota.run/docs/attachments#attachments-1-why-this-feature-exists — Container Attachments — Why this feature exists - https://ota.run/docs/attachments#attachments-2-the-most-important-rule — Container Attachments — The most important rule - https://ota.run/docs/attachments#attachments-3-how-the-mapping-works — Container Attachments — How the mapping works - https://ota.run/docs/attachments#attachments-4-why-these-frontend-paths-are-common-examples — Container Attachments — Why these frontend paths are common examples - https://ota.run/docs/attachments#attachments-5-when-tool-reconfiguration-is-required — Container Attachments — When tool reconfiguration is required - https://ota.run/docs/attachments#attachments-6-persistent-versus-ephemeral — Container Attachments — Persistent versus ephemeral - https://ota.run/docs/attachments#attachments-7-when-to-use-it — Container Attachments — When to use it - https://ota.run/docs/attachments#attachments-8-what-not-to-do — Container Attachments — What not to do - https://ota.run/docs/ci-and-pipelines#ci-and-pipelines-1-what-to-run-in-ci — CI and Pipelines — What to run in CI - https://ota.run/docs/ci-and-pipelines#ci-and-pipelines-2-real-pipeline-example — CI and Pipelines — Real pipeline example - https://ota.run/docs/ci-and-pipelines#ci-and-pipelines-3-why-this-matters — CI and Pipelines — Why this matters - https://ota.run/docs/ci-and-pipelines#ci-and-pipelines-4-how-to-adapt-it — CI and Pipelines — How to adapt it - https://ota.run/docs/ci-and-pipelines#ci-and-pipelines-5-provider-shapes — CI and Pipelines — Provider shapes - https://ota.run/docs/compose-attachments#compose-attachments-1-why-this-feature-exists — Compose Attachments — Why this feature exists - https://ota.run/docs/compose-attachments#compose-attachments-2-what-it-is-and-what-it-is-not — Compose Attachments — What it is and what it is not - https://ota.run/docs/compose-attachments#compose-attachments-3-the-most-important-alignment-rule — Compose Attachments — The most important alignment rule - https://ota.run/docs/compose-attachments#compose-attachments-4-how-it-differs-from-compose-up — Compose Attachments — How it differs from `compose:up` - https://ota.run/docs/compose-attachments#compose-attachments-5-canonical-use-case — Compose Attachments — Canonical use case - https://ota.run/docs/compose-attachments#compose-attachments-6-when-to-use-it — Compose Attachments — When to use it - https://ota.run/docs/compose-attachments#compose-attachments-7-what-not-to-do — Compose Attachments — What not to do - https://ota.run/docs/contexts#contexts-1-why-contexts-exist — Execution Contexts — Why contexts exist - https://ota.run/docs/contexts#contexts-10-full-http-listener-form — Execution Contexts — Full HTTP listener form - https://ota.run/docs/contexts#contexts-11-task-target-bindings — Execution Contexts — Task target bindings - https://ota.run/docs/contexts#contexts-12-what-breaks-without-context — Execution Contexts — What breaks without context - https://ota.run/docs/contexts#contexts-13-host-setup-container-app — Execution Contexts — Host setup, container app - https://ota.run/docs/contexts#contexts-14-one-app-two-truthful-start-paths — Execution Contexts — One app, two truthful start paths - https://ota.run/docs/contexts#contexts-15-full-listener-form-container-bind-host-url — Execution Contexts — Full listener form: container bind, host URL - https://ota.run/docs/contexts#contexts-16-container-memory-one-run-override — Execution Contexts — Container memory, one-run override - https://ota.run/docs/contexts#contexts-17-decision-guide — Execution Contexts — Decision guide - https://ota.run/docs/contexts#contexts-2-what-a-context-changes — Execution Contexts — What a context changes - https://ota.run/docs/contexts#contexts-3-default-context-versus-task-context — Execution Contexts — Default context versus task context - https://ota.run/docs/contexts#contexts-4-execution-authoring-patterns — Execution Contexts — Execution Authoring Patterns - https://ota.run/docs/contexts#contexts-5-when-to-use-mode-aware-branches — Execution Contexts — When to use mode-aware branches - https://ota.run/docs/contexts#contexts-6-contexts-services-and-app-urls — Execution Contexts — Contexts, services, and app URLs - https://ota.run/docs/contexts#contexts-7-listener-shorthand — Execution Contexts — Listener shorthand - https://ota.run/docs/contexts#contexts-8-common-local-http-listener — Execution Contexts — Common local HTTP listener - https://ota.run/docs/contexts#contexts-9-common-local-tcp-listener — Execution Contexts — Common local TCP listener - https://ota.run/docs/contract-first-onboarding#contract-first-onboarding-1-what-contract-first-onboarding-means — Contract-First Repo Onboarding — What contract-first onboarding means - https://ota.run/docs/contract-first-onboarding#contract-first-onboarding-2-why-onboarding-breaks-when-the-contract-is-missing — Contract-First Repo Onboarding — Why onboarding breaks when the contract is missing - https://ota.run/docs/contract-first-onboarding#contract-first-onboarding-3-what-the-contract-should-make-explicit — Contract-First Repo Onboarding — What the contract should make explicit - https://ota.run/docs/contract-first-onboarding#contract-first-onboarding-4-the-contract-first-loop — Contract-First Repo Onboarding — The contract-first loop - https://ota.run/docs/contract-first-onboarding#contract-first-onboarding-5-why-this-matters-beyond-onboarding — Contract-First Repo Onboarding — Why this matters beyond onboarding - https://ota.run/docs/defining-readiness#defining-readiness-1-why-this-page-exists — Defining Readiness — Why this page exists - https://ota.run/docs/defining-readiness#defining-readiness-2-the-wrong-model — Defining Readiness — The wrong model - https://ota.run/docs/defining-readiness#defining-readiness-3-env-vars-define-config-truth — Defining Readiness — Env vars define config truth - https://ota.run/docs/defining-readiness#defining-readiness-4-services-define-dependency-truth — Defining Readiness — Services define dependency truth - https://ota.run/docs/defining-readiness#defining-readiness-5-checks-define-diagnostic-truth — Defining Readiness — Checks define diagnostic truth - https://ota.run/docs/defining-readiness#defining-readiness-6-verify-defines-completion-truth — Defining Readiness — Verify defines completion truth - https://ota.run/docs/defining-readiness#defining-readiness-7-proof-defines-evidence-truth — Defining Readiness — Proof defines evidence truth - https://ota.run/docs/defining-readiness#defining-readiness-8-the-mental-model — Defining Readiness — The mental model - https://ota.run/docs/defining-readiness#defining-readiness-9-a-practical-authoring-rule — Defining Readiness — A practical authoring rule - https://ota.run/docs/developer-resources#developer-resources-1-discovery-urls — ota.run Developer Resources — Discovery URLs - https://ota.run/docs/developer-resources#developer-resources-2-oauth-2-0-metadata — ota.run Developer Resources — OAuth 2.0 metadata - https://ota.run/docs/developer-resources#developer-resources-3-official-agent-skills — ota.run Developer Resources — Official agent skills - https://ota.run/docs/developer-resources#developer-resources-4-mcp-metadata-only — ota.run Developer Resources — MCP metadata only - https://ota.run/docs/developer-resources#developer-resources-5-canonical-automation-docs — ota.run Developer Resources — Canonical automation docs - https://ota.run/docs/environment-model#environment-model-1-why-this-page-exists — Environment Model — Why this page exists - https://ota.run/docs/environment-model#environment-model-2-the-model-in-one-view — Environment Model — The model in one view - https://ota.run/docs/environment-model#environment-model-3-contract-defaults-can-replace-simple-dotenv-defaults — Environment Model — Contract defaults can replace simple dotenv defaults - https://ota.run/docs/environment-model#environment-model-4-winner-order — Environment Model — Winner order - https://ota.run/docs/environment-model#environment-model-5-declared-source-kinds — Environment Model — Declared source kinds - https://ota.run/docs/environment-model#environment-model-6-execution-only-env — Environment Model — Execution-only env - https://ota.run/docs/environment-model#environment-model-7-detect-versus-runtime — Environment Model — Detect versus runtime - https://ota.run/docs/environment-model#environment-model-8-how-to-use-it — Environment Model — How to use it - https://ota.run/docs/examples/action-ensure-bundle#examples-action-ensure-bundle-1-typical-signals — Bundled deterministic setup without shell orchestration — Typical signals - https://ota.run/docs/examples/action-ensure-bundle#examples-action-ensure-bundle-2-why-it-matters — Bundled deterministic setup without shell orchestration — Why it matters - https://ota.run/docs/examples/action-ensure-bundle#examples-action-ensure-bundle-3-example-contract — Bundled deterministic setup without shell orchestration — Example contract - https://ota.run/docs/examples/action-ensure-bundle#examples-action-ensure-bundle-4-task-notes — Bundled deterministic setup without shell orchestration — Task notes - https://ota.run/docs/examples/action-ensure-container-network#examples-action-ensure-container-network-1-typical-signals — Container network bootstrap — Typical signals - https://ota.run/docs/examples/action-ensure-container-network#examples-action-ensure-container-network-2-why-it-matters — Container network bootstrap — Why it matters - https://ota.run/docs/examples/action-ensure-container-network#examples-action-ensure-container-network-3-example-contract — Container network bootstrap — Example contract - https://ota.run/docs/examples/action-ensure-container-network#examples-action-ensure-container-network-4-task-notes — Container network bootstrap — Task notes - https://ota.run/docs/examples/action-ensure-env-file#examples-action-ensure-env-file-1-typical-signals — Deterministic env bootstrap without shell copy-plus-`sed` glue — Typical signals - https://ota.run/docs/examples/action-ensure-env-file#examples-action-ensure-env-file-2-why-it-matters — Deterministic env bootstrap without shell copy-plus-`sed` glue — Why it matters - https://ota.run/docs/examples/action-ensure-env-file#examples-action-ensure-env-file-3-example-contract — Deterministic env bootstrap without shell copy-plus-`sed` glue — Example contract - https://ota.run/docs/examples/action-ensure-env-file#examples-action-ensure-env-file-4-task-notes — Deterministic env bootstrap without shell copy-plus-`sed` glue — Task notes - https://ota.run/docs/examples/action-ensure-git-checkout#examples-action-ensure-git-checkout-1-typical-signals — Deterministic git checkout bootstrap — Typical signals - https://ota.run/docs/examples/action-ensure-git-checkout#examples-action-ensure-git-checkout-2-why-it-matters — Deterministic git checkout bootstrap — Why it matters - https://ota.run/docs/examples/action-ensure-git-checkout#examples-action-ensure-git-checkout-3-example-contract — Deterministic git checkout bootstrap — Example contract - https://ota.run/docs/examples/action-ensure-git-checkout#examples-action-ensure-git-checkout-4-task-notes — Deterministic git checkout bootstrap — Task notes - https://ota.run/docs/examples/action-ensure-git-template#examples-action-ensure-git-template-1-typical-signals — Deterministic git template bootstrap — Typical signals - https://ota.run/docs/examples/action-ensure-git-template#examples-action-ensure-git-template-2-why-it-matters — Deterministic git template bootstrap — Why it matters - https://ota.run/docs/examples/action-ensure-git-template#examples-action-ensure-git-template-3-example-contract — Deterministic git template bootstrap — Example contract - https://ota.run/docs/examples/action-ensure-git-template#examples-action-ensure-git-template-4-task-notes — Deterministic git template bootstrap — Task notes - https://ota.run/docs/examples/action-reset-compose-service-volume#examples-action-reset-compose-service-volume-1-typical-signals — Compose-managed service volume reset without shell glue — Typical signals - https://ota.run/docs/examples/action-reset-compose-service-volume#examples-action-reset-compose-service-volume-2-why-it-matters — Compose-managed service volume reset without shell glue — Why it matters - https://ota.run/docs/examples/action-reset-compose-service-volume#examples-action-reset-compose-service-volume-3-example-contract — Compose-managed service volume reset without shell glue — Example contract - https://ota.run/docs/examples/action-reset-compose-service-volume#examples-action-reset-compose-service-volume-4-task-notes — Compose-managed service volume reset without shell glue — Task notes - https://ota.run/docs/examples/bake-adapter-inputs#examples-bake-adapter-inputs-1-typical-signals — Bake adapter ownership without shell cwd or `-f` drift — Typical signals - https://ota.run/docs/examples/bake-adapter-inputs#examples-bake-adapter-inputs-2-why-it-matters — Bake adapter ownership without shell cwd or `-f` drift — Why it matters - https://ota.run/docs/examples/bake-adapter-inputs#examples-bake-adapter-inputs-3-example-contract — Bake adapter ownership without shell cwd or `-f` drift — Example contract - https://ota.run/docs/examples/bake-adapter-inputs#examples-bake-adapter-inputs-4-task-notes — Bake adapter ownership without shell cwd or `-f` drift — Task notes - https://ota.run/docs/examples/container-provisioning#examples-container-provisioning-1-typical-signals — Container provisioning — Typical signals - https://ota.run/docs/examples/container-provisioning#examples-container-provisioning-2-why-it-matters — Container provisioning — Why it matters - https://ota.run/docs/examples/container-provisioning#examples-container-provisioning-3-example-contract — Container provisioning — Example contract - https://ota.run/docs/examples/container-provisioning#examples-container-provisioning-4-task-notes — Container provisioning — Task notes - https://ota.run/docs/examples/dotnet#examples-dotnet-1-typical-signals — .NET repos with restore, build, and test — Typical signals - https://ota.run/docs/examples/dotnet#examples-dotnet-2-why-it-matters — .NET repos with restore, build, and test — Why it matters - https://ota.run/docs/examples/dotnet#examples-dotnet-3-example-contract — .NET repos with restore, build, and test — Example contract - https://ota.run/docs/examples/full-contract#examples-full-contract-1-typical-signals — Full contracts for complex repos — Typical signals - https://ota.run/docs/examples/full-contract#examples-full-contract-2-why-it-matters — Full contracts for complex repos — Why it matters - https://ota.run/docs/examples/full-contract#examples-full-contract-3-example-contract — Full contracts for complex repos — Example contract - https://ota.run/docs/examples/fullstack/node-go#examples-fullstack-node-go-1-typical-signals — Fullstack Node and Go repos with a split service path — Typical signals - https://ota.run/docs/examples/fullstack/node-go#examples-fullstack-node-go-2-why-it-matters — Fullstack Node and Go repos with a split service path — Why it matters - https://ota.run/docs/examples/fullstack/node-go#examples-fullstack-node-go-3-example-contract — Fullstack Node and Go repos with a split service path — Example contract - https://ota.run/docs/examples/go-sdk#examples-go-sdk-1-typical-signals — Go SDKs with explicit build and release flow — Typical signals - https://ota.run/docs/examples/go-sdk#examples-go-sdk-2-why-it-matters — Go SDKs with explicit build and release flow — Why it matters - https://ota.run/docs/examples/go-sdk#examples-go-sdk-3-example-contract — Go SDKs with explicit build and release flow — Example contract - https://ota.run/docs/examples/go-sdk#examples-go-sdk-4-task-notes — Go SDKs with explicit build and release flow — Task notes - https://ota.run/docs/examples/go#examples-go-1-typical-signals — Go repos with a deterministic loop — Typical signals - https://ota.run/docs/examples/go#examples-go-2-why-it-matters — Go repos with a deterministic loop — Why it matters - https://ota.run/docs/examples/go#examples-go-3-example-contract — Go repos with a deterministic loop — Example contract - https://ota.run/docs/examples/java#examples-java-1-typical-signals — Java repos with a Maven build gate — Typical signals - https://ota.run/docs/examples/java#examples-java-2-why-it-matters — Java repos with a Maven build gate — Why it matters - https://ota.run/docs/examples/java#examples-java-3-example-contract — Java repos with a Maven build gate — Example contract - https://ota.run/docs/examples/mixed/node-python#examples-mixed-node-python-1-typical-signals — Mixed Node and Python repos without ownership drift — Typical signals - https://ota.run/docs/examples/mixed/node-python#examples-mixed-node-python-2-why-it-matters — Mixed Node and Python repos without ownership drift — Why it matters - https://ota.run/docs/examples/mixed/node-python#examples-mixed-node-python-3-example-contract — Mixed Node and Python repos without ownership drift — Example contract - https://ota.run/docs/examples/node#examples-node-1-typical-signals — Node repos with a managed runtime and explicit Corepack lane — Typical signals - https://ota.run/docs/examples/node#examples-node-2-example-contract — Node repos with a managed runtime and explicit Corepack lane — Example contract - https://ota.run/docs/examples/podman-compose-adapter-inputs#examples-podman-compose-adapter-inputs-1-typical-signals — Podman compose adapter ownership without shell env/file drift — Typical signals - https://ota.run/docs/examples/podman-compose-adapter-inputs#examples-podman-compose-adapter-inputs-2-why-it-matters — Podman compose adapter ownership without shell env/file drift — Why it matters - https://ota.run/docs/examples/podman-compose-adapter-inputs#examples-podman-compose-adapter-inputs-3-example-contract — Podman compose adapter ownership without shell env/file drift — Example contract - https://ota.run/docs/examples/podman-compose-adapter-inputs#examples-podman-compose-adapter-inputs-4-task-notes — Podman compose adapter ownership without shell env/file drift — Task notes - https://ota.run/docs/examples/provisioning-policy#examples-provisioning-policy-1-typical-signals — Policy and provisioning — Typical signals - https://ota.run/docs/examples/provisioning-policy#examples-provisioning-policy-2-why-it-matters — Policy and provisioning — Why it matters - https://ota.run/docs/examples/provisioning-policy#examples-provisioning-policy-3-example-contract — Policy and provisioning — Example contract - https://ota.run/docs/examples/provisioning-policy#examples-provisioning-policy-4-task-notes — Policy and provisioning — Task notes - https://ota.run/docs/examples/python#examples-python-1-typical-signals — Python repos with a clean setup path — Typical signals - https://ota.run/docs/examples/python#examples-python-2-example-contract — Python repos with a clean setup path — Example contract - https://ota.run/docs/examples/rust-toolchain#examples-rust-toolchain-1-typical-signals — Rust toolchain ownership without duplicate runtime/tool drift — Typical signals - https://ota.run/docs/examples/rust-toolchain#examples-rust-toolchain-2-why-it-matters — Rust toolchain ownership without duplicate runtime/tool drift — Why it matters - https://ota.run/docs/examples/rust-toolchain#examples-rust-toolchain-3-example-contract — Rust toolchain ownership without duplicate runtime/tool drift — Example contract - https://ota.run/docs/examples/rust-toolchain#examples-rust-toolchain-4-task-notes — Rust toolchain ownership without duplicate runtime/tool drift — Task notes - https://ota.run/docs/examples/rust#examples-rust-1-typical-signals — Rust repos with a Rustup-backed toolchain — Typical signals - https://ota.run/docs/examples/rust#examples-rust-2-why-it-matters — Rust repos with a Rustup-backed toolchain — Why it matters - https://ota.run/docs/examples/rust#examples-rust-3-example-contract — Rust repos with a Rustup-backed toolchain — Example contract - https://ota.run/docs/examples/script#examples-script-1-typical-signals — Script-driven repos with a real contract — Typical signals - https://ota.run/docs/examples/script#examples-script-2-why-it-matters — Script-driven repos with a real contract — Why it matters - https://ota.run/docs/examples/script#examples-script-3-example-contract — Script-driven repos with a real contract — Example contract - https://ota.run/docs/examples/services#examples-services-1-typical-signals — Service repos with explicit readiness — Typical signals - https://ota.run/docs/examples/services#examples-services-2-example-contract — Service repos with explicit readiness — Example contract - https://ota.run/docs/examples/systemd-host-service#examples-systemd-host-service-1-typical-signals — Typed systemd host-service ownership without shell lifecycle drift — Typical signals - https://ota.run/docs/examples/systemd-host-service#examples-systemd-host-service-2-why-it-matters — Typed systemd host-service ownership without shell lifecycle drift — Why it matters - https://ota.run/docs/examples/systemd-host-service#examples-systemd-host-service-3-example-contract — Typed systemd host-service ownership without shell lifecycle drift — Example contract - https://ota.run/docs/examples/systemd-host-service#examples-systemd-host-service-4-task-notes — Typed systemd host-service ownership without shell lifecycle drift — Task notes - https://ota.run/docs/examples/tool-acquisition#examples-tool-acquisition-1-typical-signals — Workflow-scoped acquisition without repo-global install drift — Typical signals - https://ota.run/docs/examples/tool-acquisition#examples-tool-acquisition-2-why-it-matters — Workflow-scoped acquisition without repo-global install drift — Why it matters - https://ota.run/docs/examples/tool-acquisition#examples-tool-acquisition-3-example-contract — Workflow-scoped acquisition without repo-global install drift — Example contract - https://ota.run/docs/examples/tool-acquisition#examples-tool-acquisition-4-task-notes — Workflow-scoped acquisition without repo-global install drift — Task notes - https://ota.run/docs/examples/topology/compose-postgres#examples-topology-compose-postgres-1-typical-signals — Container app with Compose Postgres — Typical signals - https://ota.run/docs/examples/topology/compose-postgres#examples-topology-compose-postgres-2-why-it-matters — Container app with Compose Postgres — Why it matters - https://ota.run/docs/examples/topology/compose-postgres#examples-topology-compose-postgres-3-example-contract — Container app with Compose Postgres — Example contract - https://ota.run/docs/examples/topology/compose-postgres#examples-topology-compose-postgres-4-task-notes — Container app with Compose Postgres — Task notes - https://ota.run/docs/examples/topology/host-postgres#examples-topology-host-postgres-1-typical-signals — Container app with host Postgres — Typical signals - https://ota.run/docs/examples/topology/host-postgres#examples-topology-host-postgres-2-why-it-matters — Container app with host Postgres — Why it matters - https://ota.run/docs/examples/topology/host-postgres#examples-topology-host-postgres-3-example-contract — Container app with host Postgres — Example contract - https://ota.run/docs/examples/topology/host-postgres#examples-topology-host-postgres-4-task-notes — Container app with host Postgres — Task notes - https://ota.run/docs/examples/topology/node-isolated#examples-topology-node-isolated-1-typical-signals — Container app with isolated `node_modules` — Typical signals - https://ota.run/docs/examples/topology/node-isolated#examples-topology-node-isolated-2-why-it-matters — Container app with isolated `node_modules` — Why it matters - https://ota.run/docs/examples/topology/node-isolated#examples-topology-node-isolated-3-example-contract — Container app with isolated `node_modules` — Example contract - https://ota.run/docs/examples/topology/node-isolated#examples-topology-node-isolated-4-task-notes — Container app with isolated `node_modules` — Task notes - https://ota.run/docs/examples/windows-adoption#examples-windows-adoption-1-typical-signals — Windows-first adoption with explicit native activation — Typical signals - https://ota.run/docs/examples/windows-adoption#examples-windows-adoption-2-why-it-matters — Windows-first adoption with explicit native activation — Why it matters - https://ota.run/docs/examples/windows-adoption#examples-windows-adoption-3-example-contract — Windows-first adoption with explicit native activation — Example contract - https://ota.run/docs/examples/windows-adoption#examples-windows-adoption-4-task-notes — Windows-first adoption with explicit native activation — Task notes - https://ota.run/docs/examples/workspace/acquire#examples-workspace-acquire-1-typical-signals — Acquire from Git — Typical signals - https://ota.run/docs/examples/workspace/acquire#examples-workspace-acquire-2-why-it-matters — Acquire from Git — Why it matters - https://ota.run/docs/examples/workspace/acquire#examples-workspace-acquire-3-example-contract — Acquire from Git — Example contract - https://ota.run/docs/examples/workspace/acquire#examples-workspace-acquire-4-task-notes — Acquire from Git — Task notes - https://ota.run/docs/examples/workspace/basic#examples-workspace-basic-1-typical-signals — Multi-repo basics — Typical signals - https://ota.run/docs/examples/workspace/basic#examples-workspace-basic-2-why-it-matters — Multi-repo basics — Why it matters - https://ota.run/docs/examples/workspace/basic#examples-workspace-basic-3-example-contract — Multi-repo basics — Example contract - https://ota.run/docs/examples#examples-1-start-by-goal — Examples — Start by goal - https://ota.run/docs/examples#examples-2-libraries-and-sdks — Examples — Libraries and SDKs - https://ota.run/docs/examples#examples-3-single-repo-examples — Examples — Single-repo examples - https://ota.run/docs/examples#examples-4-mixed-and-service-repos — Examples — Mixed and service repos - https://ota.run/docs/examples#examples-5-focused-contract-surfaces — Examples — Focused contract surfaces - https://ota.run/docs/examples#examples-6-execution-topology-examples — Examples — Execution topology examples - https://ota.run/docs/examples#examples-7-workspace-examples — Examples — Workspace examples - https://ota.run/docs/examples#examples-8-policy-and-provisioning — Examples — Policy and provisioning - https://ota.run/docs/examples#examples-9-advanced-examples — Examples — Advanced examples - https://ota.run/docs/faq#faq-1-what-should-i-run-first — FAQ — What should I run first? - https://ota.run/docs/faq#faq-10-can-ota-policy-point-to-a-url — FAQ — Can `OTA_POLICY` point to a URL? - https://ota.run/docs/faq#faq-11-how-does-policy-precedence-work — FAQ — How does policy precedence work? - https://ota.run/docs/faq#faq-12-how-are-env-values-chosen — FAQ — How are env values chosen? - https://ota.run/docs/faq#faq-13-is-ota-a-package-manager — FAQ — Is ota a package manager? - https://ota.run/docs/faq#faq-14-does-ota-write-files-automatically — FAQ — Does ota write files automatically? - https://ota.run/docs/faq#faq-15-does-ota-replace-scripts — FAQ — Does ota replace scripts? - https://ota.run/docs/faq#faq-16-can-ota-work-with-containers — FAQ — Can ota work with containers? - https://ota.run/docs/faq#faq-17-what-does-ota-doctor-mode-container-actually-check — FAQ — What does `ota doctor --mode container` actually check? - https://ota.run/docs/faq#faq-18-what-does-execution-lifecycle-ephemeral-mean-today — FAQ — What does `execution.lifecycle: ephemeral` mean today? - https://ota.run/docs/faq#faq-19-does-adapter-bootstrap-need-platforms — FAQ — Does `adapter_bootstrap` need `platforms`? - https://ota.run/docs/faq#faq-2-when-should-i-use-a-shared-backend-instead-of-plain-task-execution-or-target-binding — FAQ — When should I use a shared backend instead of plain task execution or target binding? - https://ota.run/docs/faq#faq-20-can-one-tool-have-multiple-provisioning-sources — FAQ — Can one tool have multiple provisioning sources? - https://ota.run/docs/faq#faq-21-when-should-i-use-doctor-explain-and-receipt — FAQ — When should I use `doctor`, `explain`, and `receipt`? - https://ota.run/docs/faq#faq-22-when-should-i-use-ota-proof-runtime-instead-of-ota-doctor-ota-up-or-ota-run — FAQ — When should I use `ota proof runtime` instead of `ota doctor`, `ota up`, or `ota run`? - https://ota.run/docs/faq#faq-23-why-does-metadata-ota-minimum-version-exist — FAQ — Why does `metadata.ota.minimum_version` exist? - https://ota.run/docs/faq#faq-24-what-is-agent-posture-for — FAQ — What is `agent.posture` for? - https://ota.run/docs/faq#faq-25-what-does-crossing-required-or-crossing-classification-mean — FAQ — What does `crossing_required` or `crossing_classification` mean? - https://ota.run/docs/faq#faq-26-why-declare-task-effects — FAQ — Why declare task `effects`? - https://ota.run/docs/faq#faq-27-why-does-ota-version-json-expose-source-build-commit-dirty-and-contract-capabilities — FAQ — Why does `ota --version --json` expose `source_build`, `commit`, `dirty`, and `contract_capabilities`? - https://ota.run/docs/faq#faq-28-can-member-be-repeated-on-every-repo-command — FAQ — Can `--member` be repeated on every repo command? - https://ota.run/docs/faq#faq-29-what-is-repo-vs-workspace — FAQ — What is Repo vs Workspace? - https://ota.run/docs/faq#faq-3-does-depends-on-share-the-same-environment-as-the-parent-task — FAQ — Does `depends_on` share the same environment as the parent task? - https://ota.run/docs/faq#faq-30-is-enterprise-the-whole-product — FAQ — Is enterprise the whole product? - https://ota.run/docs/faq#faq-31-do-agents-use-the-same-contract-as-humans — FAQ — Do agents use the same contract as humans? - https://ota.run/docs/faq#faq-4-does-ota-run-task-ephemeral-also-make-depends-on-tasks-ephemeral — FAQ — Does `ota run --ephemeral` also make `depends_on` tasks ephemeral? - https://ota.run/docs/faq#faq-5-what-is-the-difference-between-requirements-and-fulfillment — FAQ — What is the difference between `requirements` and `fulfillment`? - https://ota.run/docs/faq#faq-6-why-is-execution-shared-backends-explicit-instead-of-inferred-from-context — FAQ — Why is `execution.shared_backends` explicit instead of inferred from context? - https://ota.run/docs/faq#faq-7-why-does-org-policy-still-matter-if-the-repo-already-declares-tools-and-runtimes — FAQ — Why does org policy still matter if the repo already declares tools and runtimes? - https://ota.run/docs/faq#faq-8-why-don-t-target-activation-modes-just-start-everything-automatically — FAQ — Why don’t target activation modes just start everything automatically? - https://ota.run/docs/faq#faq-9-how-should-i-choose-between-ssh-tsh-kubectl-and-daytona-for-remote-execution — FAQ — How should I choose between `ssh`, `tsh`, `kubectl`, and `daytona` for remote execution? - https://ota.run/docs/first-ota-yaml#first-ota-yaml-1-minimal-useful-starter — First `ota.yaml` — Minimal useful starter - https://ota.run/docs/first-ota-yaml#first-ota-yaml-2-what-makes-it-useful — First `ota.yaml` — What makes it useful - https://ota.run/docs/first-ota-yaml#first-ota-yaml-3-when-the-first-task-is-a-service — First `ota.yaml` — When the first task is a service - https://ota.run/docs/getting-started#getting-started-1-start-here — Getting started — Start here - https://ota.run/docs/getting-started#getting-started-2-when-you-do-not-have-a-contract-yet — Getting started — When you do not have a contract yet - https://ota.run/docs/getting-started#getting-started-3-the-default-loop — Getting started — The default loop - https://ota.run/docs/glossary#glossary-1-core-terms — Glossary — Core terms - https://ota.run/docs/glossary#glossary-2-commands — Glossary — Commands - https://ota.run/docs/glossary#glossary-3-doctor-output — Glossary — Doctor output - https://ota.run/docs/glossary#glossary-4-contract-fields — Glossary — Contract fields - https://ota.run/docs/glossary#glossary-5-execution-modes — Glossary — Execution modes - https://ota.run/docs/glossary#glossary-6-policy-and-agent-fields — Glossary — Policy and agent fields - https://ota.run/docs/glossary#glossary-7-workspace-and-agents — Glossary — Workspace and agents - https://ota.run/docs/install#install-1-release-install — Install — Release install - https://ota.run/docs/install#install-2-from-source — Install — From source - https://ota.run/docs/install#install-3-after-installation — Install — After installation - https://ota.run/docs/install#install-4-install-the-ota-skill — Install — Install the Ota skill - https://ota.run/docs/local-topology-patterns#local-topology-patterns-1-when-to-use-this-page — Local Topology Patterns — When to use this page - https://ota.run/docs/local-topology-patterns#local-topology-patterns-2-pattern-1-task-target-bindings — Local Topology Patterns — Pattern 1: Task target bindings - https://ota.run/docs/local-topology-patterns#local-topology-patterns-3-pattern-1b-target-activation — Local Topology Patterns — Pattern 1b: Target activation - https://ota.run/docs/local-topology-patterns#local-topology-patterns-4-pattern-2-shared-local-backends — Local Topology Patterns — Pattern 2: Shared local backends - https://ota.run/docs/local-topology-patterns#local-topology-patterns-5-pattern-2b-shared-remote-backends — Local Topology Patterns — Pattern 2b: Shared remote backends - https://ota.run/docs/local-topology-patterns#local-topology-patterns-6-pattern-3-run-path-fulfillment — Local Topology Patterns — Pattern 3: Run-path fulfillment - https://ota.run/docs/local-topology-patterns#local-topology-patterns-7-pattern-4-policy-governed-backend-environment — Local Topology Patterns — Pattern 4: Policy-governed backend environment - https://ota.run/docs/local-topology-patterns#local-topology-patterns-8-current-constraints — Local Topology Patterns — Current constraints - https://ota.run/docs/local-topology-patterns#local-topology-patterns-9-canonical-examples — Local Topology Patterns — Canonical examples - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-1-why-this-feature-exists — Mode-Aware Tasks — Why this feature exists - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-10-scenario-2-one-dev-task — Mode-Aware Tasks — Scenario 2: One `dev` task - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-11-scenario-3-one-build-task — Mode-Aware Tasks — Scenario 3: One `build` task - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-12-lifecycle-is-part-of-the-feature-not-an-afterthought — Mode-Aware Tasks — Lifecycle is part of the feature, not an afterthought - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-13-decision-guide — Mode-Aware Tasks — Decision guide - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-14-why-this-sells-ota — Mode-Aware Tasks — Why this sells Ota - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-2-what-it-fixes — Mode-Aware Tasks — What it fixes - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-3-the-operator-model — Mode-Aware Tasks — The operator model - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-4-when-to-use-it — Mode-Aware Tasks — When to use it - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-5-when-not-to-use-it — Mode-Aware Tasks — When not to use it - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-6-contract-anatomy — Mode-Aware Tasks — Contract anatomy - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-7-why-this-is-better-than-split-task-names — Mode-Aware Tasks — Why this is better than split task names - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-8-real-operator-scenarios — Mode-Aware Tasks — Real operator scenarios - https://ota.run/docs/mode-aware-tasks#mode-aware-tasks-9-scenario-1-one-start-task — Mode-Aware Tasks — Scenario 1: One `start` task - https://ota.run/docs/ota-vs-makefiles-ci-scripts#ota-vs-makefiles-ci-scripts-1-short-answer — README Drift vs Contract-First Repo Onboarding — Short answer - https://ota.run/docs/ota-vs-makefiles-ci-scripts#ota-vs-makefiles-ci-scripts-2-where-readme-first-setup-breaks-down — README Drift vs Contract-First Repo Onboarding — Where README-first setup breaks down - https://ota.run/docs/ota-vs-makefiles-ci-scripts#ota-vs-makefiles-ci-scripts-3-what-each-layer-answers — README Drift vs Contract-First Repo Onboarding — What each layer answers - https://ota.run/docs/ota-vs-makefiles-ci-scripts#ota-vs-makefiles-ci-scripts-4-what-contract-first-onboarding-changes — README Drift vs Contract-First Repo Onboarding — What contract-first onboarding changes - https://ota.run/docs/ota-vs-makefiles-ci-scripts#ota-vs-makefiles-ci-scripts-5-why-agents-need-more-than-scripts — README Drift vs Contract-First Repo Onboarding — Why agents need more than scripts - https://ota.run/docs/ota-vs-makefiles-ci-scripts#ota-vs-makefiles-ci-scripts-6-adoption-path — README Drift vs Contract-First Repo Onboarding — Adoption path - https://ota.run/docs/policy-concepts#policy-concepts-1-policy-at-a-glance — Policy concepts — Policy at a glance - https://ota.run/docs/policy-concepts#policy-concepts-2-what-policy-is — Policy concepts — What policy is - https://ota.run/docs/policy-concepts#policy-concepts-3-what-policy-does — Policy concepts — What policy does - https://ota.run/docs/policy-concepts#policy-concepts-4-field-descriptions — Policy concepts — Field descriptions - https://ota.run/docs/policy-concepts#policy-concepts-5-example-policy-pack — Policy concepts — Example policy pack - https://ota.run/docs/policy-concepts#policy-concepts-6-when-to-use-it — Policy concepts — When to use it - https://ota.run/docs/policy-concepts#policy-concepts-7-what-it-is-not — Policy concepts — What it is not - https://ota.run/docs/quickstart#quickstart-1-existing-contract — Quickstart — Existing contract - https://ota.run/docs/quickstart#quickstart-2-no-contract-yet — Quickstart — No contract yet - https://ota.run/docs/quickstart#quickstart-3-what-to-remember — Quickstart — What to remember - https://ota.run/docs/readiness-model#readiness-model-1-why-readiness-has-layers — Ota Readiness Model — Why readiness has layers - https://ota.run/docs/readiness-model#readiness-model-10-projected-versus-confirmed-endpoints — Ota Readiness Model — Projected versus confirmed endpoints - https://ota.run/docs/readiness-model#readiness-model-11-why-internal-readiness-can-still-differ-from-host-confirmation — Ota Readiness Model — Why internal readiness can still differ from host confirmation - https://ota.run/docs/readiness-model#readiness-model-12-vm-backed-container-boundaries — Ota Readiness Model — VM-backed container boundaries - https://ota.run/docs/readiness-model#readiness-model-13-how-to-author-readiness-well — Ota Readiness Model — How to author readiness well - https://ota.run/docs/readiness-model#readiness-model-14-reusable-probes — Ota Readiness Model — Reusable probes - https://ota.run/docs/readiness-model#readiness-model-15-literal-url-probe-for-external-or-third-party-endpoints — Ota Readiness Model — Literal URL probe for external or third-party endpoints - https://ota.run/docs/readiness-model#readiness-model-16-topology-derived-probe-for-ota-owned-endpoints — Ota Readiness Model — Topology-derived probe for Ota-owned endpoints - https://ota.run/docs/readiness-model#readiness-model-2-the-model — Ota Readiness Model — The model - https://ota.run/docs/readiness-model#readiness-model-3-command-behavior — Ota Readiness Model — Command behavior - https://ota.run/docs/readiness-model#readiness-model-4-runtime-readiness — Ota Readiness Model — Runtime readiness - https://ota.run/docs/readiness-model#readiness-model-5-service-readiness — Ota Readiness Model — Service readiness - https://ota.run/docs/readiness-model#readiness-model-6-checks — Ota Readiness Model — Checks - https://ota.run/docs/readiness-model#readiness-model-7-workflow-readiness — Ota Readiness Model — Workflow readiness - https://ota.run/docs/readiness-model#readiness-model-8-tcp-versus-http-readiness — Ota Readiness Model — TCP versus HTTP readiness - https://ota.run/docs/readiness-model#readiness-model-9-how-to-choose-the-readiness-owner — Ota Readiness Model — How to choose the readiness owner - https://ota.run/docs/reference/adapter-bootstrap#adapter-bootstrap-1-when-to-use-this-page — Adapter Bootstrap — When to use this page - https://ota.run/docs/reference/adapter-bootstrap#adapter-bootstrap-2-what-ota-does-today — Adapter Bootstrap — What ota does today - https://ota.run/docs/reference/adapter-bootstrap#adapter-bootstrap-3-bootstrap-rule-meaning — Adapter Bootstrap — Bootstrap rule meaning - https://ota.run/docs/reference/adapter-bootstrap#adapter-bootstrap-4-example-policy — Adapter Bootstrap — Example policy - https://ota.run/docs/reference/adapter-bootstrap#adapter-bootstrap-5-source-bootstrap-in-practice — Adapter Bootstrap — Source bootstrap in practice - https://ota.run/docs/reference/adapter-bootstrap#adapter-bootstrap-6-what-it-is-not — Adapter Bootstrap — What it is not - https://ota.run/docs/reference/adapters#adapters-1-when-to-use-this-page — Adapters — When to use this page - https://ota.run/docs/reference/adapters#adapters-10-scoop-bucket — Adapters — Scoop bucket - https://ota.run/docs/reference/adapters#adapters-11-apt-mirror — Adapters — apt mirror - https://ota.run/docs/reference/adapters#adapters-12-dnf-mirror — Adapters — dnf mirror - https://ota.run/docs/reference/adapters#adapters-13-homebrew-tap — Adapters — Homebrew tap - https://ota.run/docs/reference/adapters#adapters-14-sample-policy — Adapters — Sample policy - https://ota.run/docs/reference/adapters#adapters-15-recommended-order — Adapters — Recommended order - https://ota.run/docs/reference/adapters#adapters-16-what-it-is-not — Adapters — What it is not - https://ota.run/docs/reference/adapters#adapters-2-supported-today — Adapters — Supported today - https://ota.run/docs/reference/adapters#adapters-3-installer-adapters — Adapters — Installer adapters - https://ota.run/docs/reference/adapters#adapters-4-source-adapters — Adapters — Source adapters - https://ota.run/docs/reference/adapters#adapters-5-platform-specific-provisioning — Adapters — Platform-specific provisioning - https://ota.run/docs/reference/adapters#adapters-6-macos-and-linux-split — Adapters — macOS and Linux split - https://ota.run/docs/reference/adapters#adapters-7-custom-source-configuration — Adapters — Custom source configuration - https://ota.run/docs/reference/adapters#adapters-8-chocolatey-feed — Adapters — Chocolatey feed - https://ota.run/docs/reference/adapters#adapters-9-winget-source — Adapters — Winget source - https://ota.run/docs/reference/audit-and-provenance#audit-and-provenance-1-why-this-matters — Audit and Provenance — Why this matters - https://ota.run/docs/reference/audit-and-provenance#audit-and-provenance-2-provenance-categories — Audit and Provenance — Provenance categories - https://ota.run/docs/reference/audit-and-provenance#audit-and-provenance-3-detect-ownership — Audit and Provenance — Detect ownership - https://ota.run/docs/reference/audit-and-provenance#audit-and-provenance-4-where-it-shows-up — Audit and Provenance — Where it shows up - https://ota.run/docs/reference/audit-and-provenance#audit-and-provenance-5-example-finding — Audit and Provenance — Example finding - https://ota.run/docs/reference/audit-and-provenance#audit-and-provenance-6-use-cases — Audit and Provenance — Use cases - https://ota.run/docs/reference/audit-and-provenance#audit-and-provenance-7-what-this-is-not — Audit and Provenance — What this is not - https://ota.run/docs/reference/command#command-reference-1-start-with-this-flow — Command — Start with this flow - https://ota.run/docs/reference/command#command-reference-10-readiness-commands — Command — Readiness commands - https://ota.run/docs/reference/command#command-reference-11-execution-path — Command — Execution path - https://ota.run/docs/reference/command#command-reference-12-workspace-operations — Command — Workspace operations - https://ota.run/docs/reference/command#command-reference-13-workspace-waiters — Command — Workspace waiters - https://ota.run/docs/reference/command#command-reference-14-json-safety — Command — JSON safety - https://ota.run/docs/reference/command#command-reference-15-interactive-extras — Command — Interactive extras - https://ota.run/docs/reference/command#command-reference-16-when-to-use-debug — Command — When to use debug - https://ota.run/docs/reference/command#command-reference-17-best-fit — Command — Best fit - https://ota.run/docs/reference/command#command-reference-18-situational — Command — Situational - https://ota.run/docs/reference/command#command-reference-19-usually-skip — Command — Usually skip - https://ota.run/docs/reference/command#command-reference-2-how-to-choose — Command — How to choose - https://ota.run/docs/reference/command#command-reference-20-hosted-validation — Command — Hosted validation - https://ota.run/docs/reference/command#command-reference-21-execution-modes — Command — Execution modes - https://ota.run/docs/reference/command#command-reference-22-machine-integration — Command — Machine integration - https://ota.run/docs/reference/command#command-reference-23-what-not-to-do — Command — What not to do - https://ota.run/docs/reference/command#command-reference-3-readiness-and-contract — Command — Readiness and contract - https://ota.run/docs/reference/command#command-reference-4-init-paths — Command — Init paths - https://ota.run/docs/reference/command#command-reference-5-execution-and-inspection — Command — Execution and inspection - https://ota.run/docs/reference/command#command-reference-6-workspace-commands — Command — Workspace commands - https://ota.run/docs/reference/command#command-reference-7-supporting-commands — Command — Supporting commands - https://ota.run/docs/reference/command#command-reference-8-global-output-modifiers — Command — Global output modifiers - https://ota.run/docs/reference/command#command-reference-9-progress-behavior — Command — Progress behavior - https://ota.run/docs/reference/compatibility-policy#compatibility-policy-1-versioning-rule — Compatibility Policy — Versioning rule - https://ota.run/docs/reference/compatibility-policy#compatibility-policy-2-parsing-rule — Compatibility Policy — Parsing rule - https://ota.run/docs/reference/compatibility-policy#compatibility-policy-3-migration-rule — Compatibility Policy — Migration rule - https://ota.run/docs/reference/compatibility-policy#compatibility-policy-4-what-to-rely-on — Compatibility Policy — What to rely on - https://ota.run/docs/reference/compatibility-policy#compatibility-policy-5-use-cases — Compatibility Policy — Use cases - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-1-command-inventory — Compatibility Surface — Command inventory - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-10-deterministic-ordering — Compatibility Surface — Deterministic ordering - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-11-what-should-stay-stable — Compatibility Surface — What should stay stable - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-12-why-this-matters — Compatibility Surface — Why this matters - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-13-use-cases — Compatibility Surface — Use cases - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-2-repo-diagnosis-and-gating — Compatibility Surface — Repo diagnosis and gating - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-3-repo-execution-and-preparation — Compatibility Surface — Repo execution and preparation - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-4-repo-authoring-and-policy — Compatibility Surface — Repo authoring and policy - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-5-workspace-surface — Compatibility Surface — Workspace surface - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-6-stable-surfaces — Compatibility Surface — Stable surfaces - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-7-command-names — Compatibility Surface — Command names - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-8-workspace-surface — Compatibility Surface — Workspace surface - https://ota.run/docs/reference/compatibility-surface#compatibility-surface-9-json-shape — Compatibility Surface — JSON shape - https://ota.run/docs/reference/contract#contract-reference-1-what-this-file-is-for — Contract — What this file is for - https://ota.run/docs/reference/contract#contract-reference-10-env — Contract — env - https://ota.run/docs/reference/contract#contract-reference-11-services — Contract — services - https://ota.run/docs/reference/contract#contract-reference-12-surfaces — Contract — surfaces - https://ota.run/docs/reference/contract#contract-reference-13-checks — Contract — checks - https://ota.run/docs/reference/contract#contract-reference-14-tasks — Contract — tasks - https://ota.run/docs/reference/contract#contract-reference-15-tasks-name-runtime-readiness — Contract — tasks..runtime.readiness - https://ota.run/docs/reference/contract#contract-reference-16-readiness — Contract — readiness - https://ota.run/docs/reference/contract#contract-reference-17-workflows — Contract — workflows - https://ota.run/docs/reference/contract#contract-reference-18-prepare-vs-setup-vs-run — Contract — prepare vs setup vs run - https://ota.run/docs/reference/contract#contract-reference-19-execution — Contract — execution - https://ota.run/docs/reference/contract#contract-reference-2-current-high-signal-fields — Contract — Current high-signal fields - https://ota.run/docs/reference/contract#contract-reference-20-container-execution — Contract — Container Execution - https://ota.run/docs/reference/contract#contract-reference-21-agent — Contract — agent - https://ota.run/docs/reference/contract#contract-reference-22-exports — Contract — exports - https://ota.run/docs/reference/contract#contract-reference-23-policies — Contract — policies - https://ota.run/docs/reference/contract#contract-reference-24-extensions — Contract — extensions - https://ota.run/docs/reference/contract#contract-reference-25-metadata — Contract — metadata - https://ota.run/docs/reference/contract#contract-reference-26-workspace — Contract — workspace - https://ota.run/docs/reference/contract#contract-reference-27-full-example — Contract — Full example - https://ota.run/docs/reference/contract#contract-reference-3-version-required — Contract — version (required) - https://ota.run/docs/reference/contract#contract-reference-4-project-required — Contract — project (required) - https://ota.run/docs/reference/contract#contract-reference-5-toolchains — Contract — toolchains - https://ota.run/docs/reference/contract#contract-reference-6-orchestrators — Contract — orchestrators - https://ota.run/docs/reference/contract#contract-reference-7-runtimes — Contract — runtimes - https://ota.run/docs/reference/contract#contract-reference-8-tools — Contract — tools - https://ota.run/docs/reference/contract#contract-reference-9-native-prerequisites — Contract — Native prerequisites - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-1-what-a-finding-is — Doctor Findings — What a finding is - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-10-use-cases — Doctor Findings — Use cases - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-2-field-descriptions — Doctor Findings — Field descriptions - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-3-how-to-read-findings — Doctor Findings — How to read findings - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-4-why-it-matters — Doctor Findings — Why it matters - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-5-finding-catalog — Doctor Findings — Finding catalog - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-6-example-findings — Doctor Findings — Example findings - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-7-where-it-shows-up — Doctor Findings — Where it shows up - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-8-what-a-finding-is-not — Doctor Findings — What a finding is not - https://ota.run/docs/reference/doctor-finding-contract#doctor-finding-contract-9-how-ci-should-use-it — Doctor Findings — How CI should use it - https://ota.run/docs/reference/environment-values#environment-values-1-what-this-page-should-answer — Environment Variables — What this page should answer - https://ota.run/docs/reference/environment-values#environment-values-10-examples — Environment Variables — Examples - https://ota.run/docs/reference/environment-values#environment-values-11-repo-truth — Environment Variables — Repo Truth - https://ota.run/docs/reference/environment-values#environment-values-12-service-bindings — Environment Variables — Service Bindings - https://ota.run/docs/reference/environment-values#environment-values-13-policy-values — Environment Variables — Policy Values - https://ota.run/docs/reference/environment-values#environment-values-14-source-vs-default — Environment Variables — Source vs Default - https://ota.run/docs/reference/environment-values#environment-values-15-prove-the-winner — Environment Variables — Prove the Winner - https://ota.run/docs/reference/environment-values#environment-values-16-path-composition — Environment Variables — PATH Composition - https://ota.run/docs/reference/environment-values#environment-values-17-how-to-use-it — Environment Variables — How to use it - https://ota.run/docs/reference/environment-values#environment-values-18-where-it-shows-up — Environment Variables — Where it shows up - https://ota.run/docs/reference/environment-values#environment-values-19-what-policy-is-not — Environment Variables — What policy is not - https://ota.run/docs/reference/environment-values#environment-values-2-where-each-value-belongs — Environment Variables — Where each value belongs - https://ota.run/docs/reference/environment-values#environment-values-3-winner-order — Environment Variables — Winner order - https://ota.run/docs/reference/environment-values#environment-values-4-why-root-env-matters — Environment Variables — Why root env matters - https://ota.run/docs/reference/environment-values#environment-values-5-what-env-sources-means — Environment Variables — What `env.sources` means - https://ota.run/docs/reference/environment-values#environment-values-6-execution-env-layers — Environment Variables — Execution env layers - https://ota.run/docs/reference/environment-values#environment-values-7-env-variable-rules — Environment Variables — Env variable rules - https://ota.run/docs/reference/environment-values#environment-values-8-remote-secret-caveat — Environment Variables — Remote secret caveat - https://ota.run/docs/reference/environment-values#environment-values-9-path-is-special — Environment Variables — PATH is special - https://ota.run/docs/reference/execution-and-dockerfiles#execution-and-dockerfiles-1-when-to-use-this-page — Container Execution — When to use this page - https://ota.run/docs/reference/execution-and-dockerfiles#execution-and-dockerfiles-2-boundary-note — Container Execution — Boundary note - https://ota.run/docs/reference/execution-and-dockerfiles#execution-and-dockerfiles-3-how-they-differ — Container Execution — How they differ - https://ota.run/docs/reference/execution-and-dockerfiles#execution-and-dockerfiles-4-simple-model — Container Execution — Simple model - https://ota.run/docs/reference/execution-and-dockerfiles#execution-and-dockerfiles-5-example — Container Execution — Example - https://ota.run/docs/reference/execution-and-dockerfiles#execution-and-dockerfiles-6-rule-of-thumb — Container Execution — Rule of thumb - https://ota.run/docs/reference/execution-and-dockerfiles#execution-and-dockerfiles-7-preview-example — Container Execution — Preview example - https://ota.run/docs/reference/execution-governance-loop#execution-governance-loop-1-when-to-use-this-page — Execution Governance Loop — When to use this page - https://ota.run/docs/reference/execution-governance-loop#execution-governance-loop-2-the-five-surfaces — Execution Governance Loop — The five surfaces - https://ota.run/docs/reference/execution-governance-loop#execution-governance-loop-3-command-mapping — Execution Governance Loop — Command mapping - https://ota.run/docs/reference/execution-governance-loop#execution-governance-loop-4-why-ota-keeps-these-separate — Execution Governance Loop — Why Ota keeps these separate - https://ota.run/docs/reference/execution-governance-loop#execution-governance-loop-5-where-to-go-next — Execution Governance Loop — Where to go next - https://ota.run/docs/reference/execution-receipt#execution-receipt-1-what-a-receipt-is-for — Execution Receipt — What a receipt is for - https://ota.run/docs/reference/execution-receipt#execution-receipt-2-receipt-fields — Execution Receipt — Receipt fields - https://ota.run/docs/reference/execution-receipt#execution-receipt-3-how-to-read-it — Execution Receipt — How to read it - https://ota.run/docs/reference/execution-receipt#execution-receipt-4-repo-example — Execution Receipt — Repo example - https://ota.run/docs/reference/execution-receipt#execution-receipt-5-workspace-example — Execution Receipt — Workspace example - https://ota.run/docs/reference/execution-receipt#execution-receipt-6-how-to-use-it — Execution Receipt — How to use it - https://ota.run/docs/reference/execution-receipt#execution-receipt-7-what-it-is-not — Execution Receipt — What it is not - https://ota.run/docs/reference/execution-receipt#execution-receipt-8-use-cases — Execution Receipt — Use cases - https://ota.run/docs/reference/execution-topology#execution-topology-1-current-problem — Execution Topology — Current problem - https://ota.run/docs/reference/execution-topology#execution-topology-10-full-http-listener-form — Execution Topology — Full HTTP listener form - https://ota.run/docs/reference/execution-topology#execution-topology-11-workload-endpoint-projection-contract — Execution Topology — Workload endpoint projection contract - https://ota.run/docs/reference/execution-topology#execution-topology-12-clone-run-open-flow — Execution Topology — Clone, run, open flow - https://ota.run/docs/reference/execution-topology#execution-topology-13-ingress-troubleshooting — Execution Topology — Ingress troubleshooting - https://ota.run/docs/reference/execution-topology#execution-topology-14-two-concrete-topologies — Execution Topology — Two concrete topologies - https://ota.run/docs/reference/execution-topology#execution-topology-15-what-changes-in-doctor-up-and-run — Execution Topology — What changes in doctor, up, and run - https://ota.run/docs/reference/execution-topology#execution-topology-16-status-and-migration — Execution Topology — Status and migration - https://ota.run/docs/reference/execution-topology#execution-topology-2-the-proposed-model — Execution Topology — The proposed model - https://ota.run/docs/reference/execution-topology#execution-topology-3-execution-contexts — Execution Topology — Execution contexts - https://ota.run/docs/reference/execution-topology#execution-topology-4-tasks-workloads-and-services — Execution Topology — Tasks, workloads, and services - https://ota.run/docs/reference/execution-topology#execution-topology-5-container-local-dependency-isolation — Execution Topology — Container-local dependency isolation - https://ota.run/docs/reference/execution-topology#execution-topology-6-listener-mode-rules — Execution Topology — Listener mode rules - https://ota.run/docs/reference/execution-topology#execution-topology-7-listener-shorthand — Execution Topology — Listener shorthand - https://ota.run/docs/reference/execution-topology#execution-topology-8-common-local-http-listener — Execution Topology — Common local HTTP listener - https://ota.run/docs/reference/execution-topology#execution-topology-9-common-local-tcp-listener — Execution Topology — Common local TCP listener - https://ota.run/docs/reference/exit-codes#exit-codes-1-why-it-matters — Exit Codes — Why it matters - https://ota.run/docs/reference/exit-codes#exit-codes-2-global-registry — Exit Codes — Global registry - https://ota.run/docs/reference/exit-codes#exit-codes-3-common-cases — Exit Codes — Common cases - https://ota.run/docs/reference/exit-codes#exit-codes-4-repo-commands — Exit Codes — Repo commands - https://ota.run/docs/reference/exit-codes#exit-codes-5-workspace-commands — Exit Codes — Workspace commands - https://ota.run/docs/reference/exit-codes#exit-codes-6-json-alignment — Exit Codes — JSON alignment - https://ota.run/docs/reference/exit-codes#exit-codes-7-use-cases — Exit Codes — Use cases - https://ota.run/docs/reference/extension-boundary#extension-boundary-1-current-boundary — Extension Support — Current boundary - https://ota.run/docs/reference/extension-boundary#extension-boundary-2-core-command-boundary — Extension Support — Core command boundary - https://ota.run/docs/reference/extension-boundary#extension-boundary-3-example — Extension Support — Example - https://ota.run/docs/reference/extension-boundary#extension-boundary-4-use-cases — Extension Support — Use cases - https://ota.run/docs/reference/extension-boundary#extension-boundary-5-backend-provider-wire-contract — Extension Support — Backend provider wire contract - https://ota.run/docs/reference/extension-boundary#extension-boundary-6-what-this-is-not — Extension Support — What this is not - https://ota.run/docs/reference/github-action#github-action-1-purpose — GitHub Action — Purpose - https://ota.run/docs/reference/github-action#github-action-10-outputs — GitHub Action — Outputs - https://ota.run/docs/reference/github-action#github-action-11-job-boundary — GitHub Action — Job boundary - https://ota.run/docs/reference/github-action#github-action-12-what-it-does-not-replace — GitHub Action — What it does not replace - https://ota.run/docs/reference/github-action#github-action-13-source-repo — GitHub Action — Source repo - https://ota.run/docs/reference/github-action#github-action-2-use-when — GitHub Action — Use when - https://ota.run/docs/reference/github-action#github-action-3-canonical-renderer-reuse — GitHub Action — Canonical renderer reuse - https://ota.run/docs/reference/github-action#github-action-4-pair-with-setup — GitHub Action — Pair with setup - https://ota.run/docs/reference/github-action#github-action-5-quick-start — GitHub Action — Quick start - https://ota.run/docs/reference/github-action#github-action-6-pinned-artifact-name — GitHub Action — Pinned artifact name - https://ota.run/docs/reference/github-action#github-action-7-command-choice — GitHub Action — Command choice - https://ota.run/docs/reference/github-action#github-action-8-install-behavior — GitHub Action — Install behavior - https://ota.run/docs/reference/github-action#github-action-9-inputs — GitHub Action — Inputs - https://ota.run/docs/reference/github-setup#github-setup-1-purpose — GitHub Setup Action — Purpose - https://ota.run/docs/reference/github-setup#github-setup-2-use-when — GitHub Setup Action — Use when - https://ota.run/docs/reference/github-setup#github-setup-3-quick-start — GitHub Setup Action — Quick start - https://ota.run/docs/reference/github-setup#github-setup-4-inputs — GitHub Setup Action — Inputs - https://ota.run/docs/reference/github-setup#github-setup-5-outputs — GitHub Setup Action — Outputs - https://ota.run/docs/reference/github-setup#github-setup-6-install-behavior — GitHub Setup Action — Install behavior - https://ota.run/docs/reference/github-setup#github-setup-7-job-boundary — GitHub Setup Action — Job boundary - https://ota.run/docs/reference/github-setup#github-setup-8-relationship-to-ota-run-action — GitHub Setup Action — Relationship to ota-run/action - https://ota.run/docs/reference/github-setup#github-setup-9-source-repo — GitHub Setup Action — Source repo - https://ota.run/docs/reference/governance#governance-1-when-to-use-this-page — Open Core and Governance — When to use this page - https://ota.run/docs/reference/governance#governance-2-what-is-open — Open Core and Governance — What is open - https://ota.run/docs/reference/governance#governance-3-governance-model — Open Core and Governance — Governance model - https://ota.run/docs/reference/governance#governance-4-contribution-policy — Open Core and Governance — Contribution policy - https://ota.run/docs/reference/governance#governance-5-why-it-is-run-this-way — Open Core and Governance — Why it is run this way - https://ota.run/docs/reference/governance#governance-6-enterprise-boundary — Open Core and Governance — Enterprise boundary - https://ota.run/docs/reference/governance#governance-7-what-to-do-next — Open Core and Governance — What to do next - https://ota.run/docs/reference/hosted-validation#hosted-validation-1-purpose — CI Validation — Purpose - https://ota.run/docs/reference/hosted-validation#hosted-validation-10-runner-boundary — CI Validation — Runner boundary - https://ota.run/docs/reference/hosted-validation#hosted-validation-11-annotation-mapping — CI Validation — Annotation mapping - https://ota.run/docs/reference/hosted-validation#hosted-validation-12-keep-it-read-only — CI Validation — Keep it read-only - https://ota.run/docs/reference/hosted-validation#hosted-validation-13-portable-ci-adapter — CI Validation — Portable CI adapter - https://ota.run/docs/reference/hosted-validation#hosted-validation-2-repo-gating — CI Validation — Repo gating - https://ota.run/docs/reference/hosted-validation#hosted-validation-3-workspace-gating — CI Validation — Workspace gating - https://ota.run/docs/reference/hosted-validation#hosted-validation-4-inventory-and-preflight — CI Validation — Inventory and preflight - https://ota.run/docs/reference/hosted-validation#hosted-validation-5-operational-rule — CI Validation — Operational rule - https://ota.run/docs/reference/hosted-validation#hosted-validation-6-example-ci-flow — CI Validation — Example CI flow - https://ota.run/docs/reference/hosted-validation#hosted-validation-7-official-github-action — CI Validation — Official GitHub Action - https://ota.run/docs/reference/hosted-validation#hosted-validation-8-use-cases — CI Validation — Use cases - https://ota.run/docs/reference/hosted-validation#hosted-validation-9-what-to-fail-on — CI Validation — What to fail on - https://ota.run/docs/reference/json-output#json-output-1-when-to-use-json — JSON Output — When to use JSON - https://ota.run/docs/reference/json-output#json-output-10-repo-and-workspace-surfaces — JSON Output — Repo and workspace surfaces - https://ota.run/docs/reference/json-output#json-output-11-example-payloads — JSON Output — Example payloads - https://ota.run/docs/reference/json-output#json-output-12-what-json-is-not — JSON Output — What JSON is not - https://ota.run/docs/reference/json-output#json-output-13-use-cases — JSON Output — Use cases - https://ota.run/docs/reference/json-output#json-output-2-common-payload-fields — JSON Output — Common payload fields - https://ota.run/docs/reference/json-output#json-output-3-canonical-source — JSON Output — Canonical source - https://ota.run/docs/reference/json-output#json-output-4-what-to-use — JSON Output — What to use - https://ota.run/docs/reference/json-output#json-output-5-canonical-schema-urls — JSON Output — Canonical schema URLs - https://ota.run/docs/reference/json-output#json-output-6-high-signal-1-6-23-governance-fields — JSON Output — High-signal 1.6.23 governance fields - https://ota.run/docs/reference/json-output#json-output-7-workspace-schema-urls — JSON Output — Workspace schema URLs - https://ota.run/docs/reference/json-output#json-output-8-change-and-remediation-urls — JSON Output — Change and remediation URLs - https://ota.run/docs/reference/json-output#json-output-9-read-the-payload-in-the-right-order — JSON Output — Read the payload in the right order - https://ota.run/docs/reference/mutation-controls-and-caching#mutation-controls-and-caching-1-when-to-use-this-page — Writes and Caching — When to use this page - https://ota.run/docs/reference/mutation-controls-and-caching#mutation-controls-and-caching-2-how-writes-work — Writes and Caching — How writes work - https://ota.run/docs/reference/mutation-controls-and-caching#mutation-controls-and-caching-3-writable-commands — Writes and Caching — Writable commands - https://ota.run/docs/reference/mutation-controls-and-caching#mutation-controls-and-caching-4-read-only-commands — Writes and Caching — Read-only commands - https://ota.run/docs/reference/mutation-controls-and-caching#mutation-controls-and-caching-5-how-caching-works — Writes and Caching — How caching works - https://ota.run/docs/reference/mutation-controls-and-caching#mutation-controls-and-caching-6-how-to-use-it — Writes and Caching — How to use it - https://ota.run/docs/reference/mutation-controls-and-caching#mutation-controls-and-caching-7-why-it-matters — Writes and Caching — Why it matters - https://ota.run/docs/reference/mutation-controls-and-caching#mutation-controls-and-caching-8-what-this-is-not — Writes and Caching — What this is not - https://ota.run/docs/reference/org-policy#org-policy-1-what-it-is — Org Policy Baseline — What it is - https://ota.run/docs/reference/org-policy#org-policy-10-adapter-bootstrap — Org Policy Baseline — adapter_bootstrap - https://ota.run/docs/reference/org-policy#org-policy-11-recommended-baseline — Org Policy Baseline — Recommended baseline - https://ota.run/docs/reference/org-policy#org-policy-12-platform-aware-example — Org Policy Baseline — Platform-aware example - https://ota.run/docs/reference/org-policy#org-policy-13-how-the-platform-split-works — Org Policy Baseline — How the platform split works - https://ota.run/docs/reference/org-policy#org-policy-14-why-it-matters — Org Policy Baseline — Why it matters - https://ota.run/docs/reference/org-policy#org-policy-15-use-it-when — Org Policy Baseline — Use it when - https://ota.run/docs/reference/org-policy#org-policy-2-required-sections — Org Policy Baseline — required_sections - https://ota.run/docs/reference/org-policy#org-policy-3-required-files — Org Policy Baseline — required_files - https://ota.run/docs/reference/org-policy#org-policy-4-strict-versions — Org Policy Baseline — strict_versions - https://ota.run/docs/reference/org-policy#org-policy-5-agent-require-safe-tasks — Org Policy Baseline — agent.require_safe_tasks - https://ota.run/docs/reference/org-policy#org-policy-6-agent-require-writable-paths — Org Policy Baseline — agent.require_writable_paths - https://ota.run/docs/reference/org-policy#org-policy-7-exports-require-agents-md — Org Policy Baseline — exports.require_agents_md - https://ota.run/docs/reference/org-policy#org-policy-8-provisioning — Org Policy Baseline — provisioning - https://ota.run/docs/reference/org-policy#org-policy-9-version-policy — Org Policy Baseline — version_policy - https://ota.run/docs/reference/output-style#output-style-1-when-to-use-this-page — Output Style — When to use this page - https://ota.run/docs/reference/output-style#output-style-2-rich-mode — Output Style — Rich mode - https://ota.run/docs/reference/output-style#output-style-3-what-users-can-rely-on — Output Style — What users can rely on - https://ota.run/docs/reference/output-style#output-style-4-plain-mode — Output Style — Plain mode - https://ota.run/docs/reference/output-style#output-style-5-what-stays-stable — Output Style — What stays stable - https://ota.run/docs/reference/output-style#output-style-6-when-to-use-plain-mode — Output Style — When to use plain mode - https://ota.run/docs/reference/output-style#output-style-7-what-it-is-not — Output Style — What it is not - https://ota.run/docs/reference/output-style#output-style-8-use-cases — Output Style — Use cases - https://ota.run/docs/reference/ownership-layers#ownership-layers-1-purpose — Ownership Layers — Purpose - https://ota.run/docs/reference/ownership-layers#ownership-layers-10-what-this-is-not — Ownership Layers — What this is not - https://ota.run/docs/reference/ownership-layers#ownership-layers-11-current-shipped-slice — Ownership Layers — Current shipped slice - https://ota.run/docs/reference/ownership-layers#ownership-layers-2-ownership-rule — Ownership Layers — Ownership rule - https://ota.run/docs/reference/ownership-layers#ownership-layers-3-command-behavior — Ownership Layers — Command behavior - https://ota.run/docs/reference/ownership-layers#ownership-layers-4-when-to-use-each-layer — Ownership Layers — When to use each layer - https://ota.run/docs/reference/ownership-layers#ownership-layers-5-before-and-after — Ownership Layers — Before and after - https://ota.run/docs/reference/ownership-layers#ownership-layers-6-task-requirement-examples — Ownership Layers — Task requirement examples - https://ota.run/docs/reference/ownership-layers#ownership-layers-7-duplication-boundaries — Ownership Layers — Duplication boundaries - https://ota.run/docs/reference/ownership-layers#ownership-layers-8-fulfillment-behavior — Ownership Layers — Fulfillment behavior - https://ota.run/docs/reference/ownership-layers#ownership-layers-9-current-shipped-examples — Ownership Layers — Current shipped examples - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-1-when-to-use-this-page — Provisioning Sources — When to use this page - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-10-when-ota-will-not-provision — Provisioning Sources — When ota will not provision - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-11-example-policy — Provisioning Sources — Example policy - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-12-what-it-does-today — Provisioning Sources — What it does today - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-13-example-output — Provisioning Sources — Example output - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-14-what-it-is-not — Provisioning Sources — What it is not - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-2-current-boundary — Provisioning Sources — Current boundary - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-3-provisioning-field-meaning — Provisioning Sources — Provisioning field meaning - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-4-release-asset-shape — Provisioning Sources — Release asset shape - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-5-source-selection-is-explicit — Provisioning Sources — Source selection is explicit - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-6-version-governance-boundary — Provisioning Sources — Version governance boundary - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-7-how-source-resolution-works — Provisioning Sources — How source resolution works - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-8-version-resolution-rules — Provisioning Sources — Version resolution rules - https://ota.run/docs/reference/policy-backed-provisioning#policy-backed-provisioning-9-package-mapping-rules — Provisioning Sources — Package mapping rules - https://ota.run/docs/reference/policy-packs#policy-packs-1-when-to-use-this-page — Policy Packs — When to use this page - https://ota.run/docs/reference/policy-packs#policy-packs-10-how-it-shows-up-in-ota — Policy Packs — How it shows up in ota - https://ota.run/docs/reference/policy-packs#policy-packs-11-how-to-read-a-policy-finding — Policy Packs — How to read a policy finding - https://ota.run/docs/reference/policy-packs#policy-packs-12-use-cases — Policy Packs — Use cases - https://ota.run/docs/reference/policy-packs#policy-packs-2-policy-vs-contract — Policy Packs — Policy vs Contract - https://ota.run/docs/reference/policy-packs#policy-packs-3-why-it-matters — Policy Packs — Why it matters - https://ota.run/docs/reference/policy-packs#policy-packs-4-operator-loop — Policy Packs — Operator loop - https://ota.run/docs/reference/policy-packs#policy-packs-5-where-they-live — Policy Packs — Where they live - https://ota.run/docs/reference/policy-packs#policy-packs-6-contract-field-descriptions — Policy Packs — Contract field descriptions - https://ota.run/docs/reference/policy-packs#policy-packs-7-example-policy-pack — Policy Packs — Example policy pack - https://ota.run/docs/reference/policy-packs#policy-packs-8-what-it-can-do — Policy Packs — What it can do - https://ota.run/docs/reference/policy-packs#policy-packs-9-what-it-cannot-do — Policy Packs — What it cannot do - https://ota.run/docs/reference/remote-execution#remote-execution-1-why-it-matters — Remote Execution — Why it matters - https://ota.run/docs/reference/remote-execution#remote-execution-10-semantics — Remote Execution — Semantics - https://ota.run/docs/reference/remote-execution#remote-execution-11-backend-provider-contract — Remote Execution — Backend provider contract - https://ota.run/docs/reference/remote-execution#remote-execution-12-multiple-backend-providers — Remote Execution — Multiple backend providers - https://ota.run/docs/reference/remote-execution#remote-execution-13-real-api-shape — Remote Execution — Real API shape - https://ota.run/docs/reference/remote-execution#remote-execution-14-use-cases — Remote Execution — Use cases - https://ota.run/docs/reference/remote-execution#remote-execution-2-when-to-use-it — Remote Execution — When to use it - https://ota.run/docs/reference/remote-execution#remote-execution-3-contract-fields — Remote Execution — Contract fields - https://ota.run/docs/reference/remote-execution#remote-execution-4-how-execution-is-selected — Remote Execution — How execution is selected - https://ota.run/docs/reference/remote-execution#remote-execution-5-example — Remote Execution — Example - https://ota.run/docs/reference/remote-execution#remote-execution-6-target-shape — Remote Execution — Target shape - https://ota.run/docs/reference/remote-execution#remote-execution-7-what-editors-should-surface — Remote Execution — What editors should surface - https://ota.run/docs/reference/remote-execution#remote-execution-8-scope — Remote Execution — Scope - https://ota.run/docs/reference/remote-execution#remote-execution-9-json-surfaces — Remote Execution — JSON surfaces - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-1-purpose — Diff and Explain — Purpose - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-10-non-goals — Diff and Explain — Non-goals - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-2-related-surface — Diff and Explain — Related surface - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-3-ota-diff — Diff and Explain — `ota diff` - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-4-ota-diff-json-shape — Diff and Explain — `ota diff` JSON shape - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-5-ota-explain — Diff and Explain — `ota explain` - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-6-ota-explain-json-shape — Diff and Explain — `ota explain` JSON shape - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-7-how-to-read-the-outputs — Diff and Explain — How to read the outputs - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-8-use-cases — Diff and Explain — Use cases - https://ota.run/docs/reference/semantic-diff-and-explain#semantic-diff-and-explain-9-examples — Diff and Explain — Examples - https://ota.run/docs/reference/semantic-snapshots-and-correlation#semantic-snapshots-and-correlation-1-when-to-use-this-page — Semantic Snapshots and Correlation — When to use this page - https://ota.run/docs/reference/semantic-snapshots-and-correlation#semantic-snapshots-and-correlation-2-three-surfaces — Semantic Snapshots and Correlation — Three surfaces - https://ota.run/docs/reference/semantic-snapshots-and-correlation#semantic-snapshots-and-correlation-3-snapshot-inspection — Semantic Snapshots and Correlation — Snapshot inspection - https://ota.run/docs/reference/semantic-snapshots-and-correlation#semantic-snapshots-and-correlation-4-semantic-diff — Semantic Snapshots and Correlation — Semantic diff - https://ota.run/docs/reference/semantic-snapshots-and-correlation#semantic-snapshots-and-correlation-5-receipt-correlation — Semantic Snapshots and Correlation — Receipt correlation - https://ota.run/docs/reference/semantic-snapshots-and-correlation#semantic-snapshots-and-correlation-6-correlation-ordering — Semantic Snapshots and Correlation — Correlation ordering - https://ota.run/docs/reference/semantic-snapshots-and-correlation#semantic-snapshots-and-correlation-7-how-to-choose-the-right-surface — Semantic Snapshots and Correlation — How to choose the right surface - https://ota.run/docs/reference/service-behavior#service-behavior-1-why-services-matter — Service Behavior — Why services matter - https://ota.run/docs/reference/service-behavior#service-behavior-2-service-lifecycle-at-a-glance — Service Behavior — Service lifecycle at a glance - https://ota.run/docs/reference/service-behavior#service-behavior-3-service-field-meanings — Service Behavior — Service field meanings - https://ota.run/docs/reference/service-behavior#service-behavior-4-how-ota-uses-services — Service Behavior — How ota uses services - https://ota.run/docs/reference/service-behavior#service-behavior-5-how-to-read-the-behavior — Service Behavior — How to read the behavior - https://ota.run/docs/reference/service-behavior#service-behavior-6-real-example — Service Behavior — Real example - https://ota.run/docs/reference/service-behavior#service-behavior-7-what-users-should-expect — Service Behavior — What users should expect - https://ota.run/docs/reference/service-behavior#service-behavior-8-use-cases — Service Behavior — Use cases - https://ota.run/docs/reference/service-behavior#service-behavior-9-what-ota-does-not-do — Service Behavior — What ota does not do - https://ota.run/docs/reference/shell-semantics#shell-semantics-1-when-to-use-this-page — Shell Behavior — When to use this page - https://ota.run/docs/reference/shell-semantics#shell-semantics-2-host-shell-model — Shell Behavior — Host shell model - https://ota.run/docs/reference/shell-semantics#shell-semantics-3-working-directory — Shell Behavior — Working directory - https://ota.run/docs/reference/shell-semantics#shell-semantics-4-environment-behavior — Shell Behavior — Environment behavior - https://ota.run/docs/reference/shell-semantics#shell-semantics-5-run-vs-script — Shell Behavior — `run` vs `script` - https://ota.run/docs/reference/shell-semantics#shell-semantics-6-real-example — Shell Behavior — Real example - https://ota.run/docs/reference/shell-semantics#shell-semantics-7-what-users-should-expect — Shell Behavior — What users should expect - https://ota.run/docs/reference/shell-semantics#shell-semantics-8-use-cases — Shell Behavior — Use cases - https://ota.run/docs/reference/shell-semantics#shell-semantics-9-what-ota-does-not-do — Shell Behavior — What ota does not do - https://ota.run/docs/reference/starter-packs#starter-packs-1-when-to-use-this-page — Starter Packs — When to use this page - https://ota.run/docs/reference/starter-packs#starter-packs-10-what-this-page-is-not — Starter Packs — What this page is not - https://ota.run/docs/reference/starter-packs#starter-packs-2-review-first-flow — Starter Packs — Review-first flow - https://ota.run/docs/reference/starter-packs#starter-packs-3-how-to-compare-packs — Starter Packs — How to compare packs - https://ota.run/docs/reference/starter-packs#starter-packs-4-available-packs — Starter Packs — Available packs - https://ota.run/docs/reference/starter-packs#starter-packs-5-pack-specific-knobs — Starter Packs — Pack-specific knobs - https://ota.run/docs/reference/starter-packs#starter-packs-6-what-packs-do-not-infer — Starter Packs — What packs do not infer - https://ota.run/docs/reference/starter-packs#starter-packs-7-java-wrapper-behavior — Starter Packs — Java wrapper behavior - https://ota.run/docs/reference/starter-packs#starter-packs-8-advisory-mismatch-behavior — Starter Packs — Advisory mismatch behavior - https://ota.run/docs/reference/starter-packs#starter-packs-9-json-surfaces — Starter Packs — JSON surfaces - https://ota.run/docs/reference/support-policy#support-policy-1-when-to-use-this-page — Platform support — When to use this page - https://ota.run/docs/reference/support-policy#support-policy-10-when-this-matters — Platform support — When this matters - https://ota.run/docs/reference/support-policy#support-policy-11-what-this-is-not — Platform support — What this is not - https://ota.run/docs/reference/support-policy#support-policy-12-relationship-to-other-surfaces — Platform support — Relationship to other surfaces - https://ota.run/docs/reference/support-policy#support-policy-2-compatibility-in-practice — Platform support — Compatibility in practice - https://ota.run/docs/reference/support-policy#support-policy-3-platform-support — Platform support — Platform support - https://ota.run/docs/reference/support-policy#support-policy-4-what-this-means-in-practice — Platform support — What this means in practice - https://ota.run/docs/reference/support-policy#support-policy-5-what-ota-accepts — Platform support — What ota accepts - https://ota.run/docs/reference/support-policy#support-policy-6-what-ota-rejects-or-warns-about — Platform support — What ota rejects or warns about - https://ota.run/docs/reference/support-policy#support-policy-7-shell-semantics — Platform support — Shell semantics - https://ota.run/docs/reference/support-policy#support-policy-8-lifecycle-semantics — Platform support — Lifecycle semantics - https://ota.run/docs/reference/support-policy#support-policy-9-what-users-should-expect — Platform support — What users should expect - https://ota.run/docs/reference/task-aggregate#task-aggregate-1-purpose — Task Aggregate — Purpose - https://ota.run/docs/reference/task-aggregate#task-aggregate-2-preferred-aggregate-shape — Task Aggregate — Preferred aggregate shape - https://ota.run/docs/reference/task-aggregate#task-aggregate-3-why-this-is-stronger — Task Aggregate — Why this is stronger - https://ota.run/docs/reference/task-aggregate#task-aggregate-4-keep-depends-on-for-prerequisites — Task Aggregate — Keep `depends_on` for prerequisites - https://ota.run/docs/reference/task-bodies#task-bodies-1-decision-order — Task Bodies — Decision order - https://ota.run/docs/reference/task-bodies#task-bodies-10-action — Task Bodies — Action - https://ota.run/docs/reference/task-bodies#task-bodies-11-aggregate — Task Bodies — Aggregate - https://ota.run/docs/reference/task-bodies#task-bodies-12-prefer-this-over-that — Task Bodies — Prefer this over that - https://ota.run/docs/reference/task-bodies#task-bodies-13-shell-is-still-valid-when-it-is-honest — Task Bodies — Shell is still valid when it is honest - https://ota.run/docs/reference/task-bodies#task-bodies-14-governance-rule — Task Bodies — Governance rule - https://ota.run/docs/reference/task-bodies#task-bodies-2-contract-rule — Task Bodies — Contract rule - https://ota.run/docs/reference/task-bodies#task-bodies-3-prepare — Task Bodies — Prepare - https://ota.run/docs/reference/task-bodies#task-bodies-4-command — Task Bodies — Command - https://ota.run/docs/reference/task-bodies#task-bodies-5-compose — Task Bodies — Compose - https://ota.run/docs/reference/task-bodies#task-bodies-6-launch-kind-compose — Task Bodies — Launch.kind: compose - https://ota.run/docs/reference/task-bodies#task-bodies-7-launch-kind-command — Task Bodies — Launch.kind: command - https://ota.run/docs/reference/task-bodies#task-bodies-8-run — Task Bodies — Run - https://ota.run/docs/reference/task-bodies#task-bodies-9-script — Task Bodies — Script - https://ota.run/docs/reference/task-launch#task-launch-1-purpose — Task Launch — Purpose - https://ota.run/docs/reference/task-launch#task-launch-2-governance-rule — Task Launch — Governance rule - https://ota.run/docs/reference/task-launch#task-launch-3-preferred-finite-command-shape — Task Launch — Preferred finite command shape - https://ota.run/docs/reference/task-launch#task-launch-4-preferred-service-shape — Task Launch — Preferred service shape - https://ota.run/docs/reference/task-launch#task-launch-5-why-this-is-stronger — Task Launch — Why this is stronger - https://ota.run/docs/reference/task-launch#task-launch-6-use-run-when-shell-is-the-truth — Task Launch — Use `run` when shell is the truth - https://ota.run/docs/reference/version-policy#version-policy-1-when-to-use-this-page — Version Policy — When to use this page - https://ota.run/docs/reference/version-policy#version-policy-10-when-this-is-the-right-boundary — Version Policy — When this is the right boundary - https://ota.run/docs/reference/version-policy#version-policy-2-how-policy-is-interpreted — Version Policy — How policy is interpreted - https://ota.run/docs/reference/version-policy#version-policy-3-current-boundary — Version Policy — Current boundary - https://ota.run/docs/reference/version-policy#version-policy-4-exact-pin-example — Version Policy — Exact pin example - https://ota.run/docs/reference/version-policy#version-policy-5-semver-range-example — Version Policy — Semver-range example - https://ota.run/docs/reference/version-policy#version-policy-6-os-scoped-example — Version Policy — OS-scoped example - https://ota.run/docs/reference/version-policy#version-policy-7-java-distribution-example — Version Policy — Java distribution example - https://ota.run/docs/reference/version-policy#version-policy-8-with-provisioning — Version Policy — With provisioning - https://ota.run/docs/reference/version-policy#version-policy-9-how-doctor-explains-a-failure — Version Policy — How doctor explains a failure - https://ota.run/docs/reference/workflows#workflows-1-what-a-workflow-is — Workflows — What a workflow is - https://ota.run/docs/reference/workflows#workflows-10-workflow-setup-run-precedence — Workflows — Workflow setup/run precedence - https://ota.run/docs/reference/workflows#workflows-11-default-workflow-vs-agent-hints — Workflows — Default workflow vs agent hints - https://ota.run/docs/reference/workflows#workflows-12-design-rule — Workflows — Design rule - https://ota.run/docs/reference/workflows#workflows-2-what-it-is-not — Workflows — What it is not - https://ota.run/docs/reference/workflows#workflows-3-purpose — Workflows — Purpose - https://ota.run/docs/reference/workflows#workflows-4-workflow-versus-depends-on — Workflows — Workflow versus depends_on - https://ota.run/docs/reference/workflows#workflows-5-when-to-add-one — Workflows — When to add one - https://ota.run/docs/reference/workflows#workflows-6-use-case-one-repo-multiple-front-doors — Workflows — Use case: one repo, multiple front doors - https://ota.run/docs/reference/workflows#workflows-7-when-not-to-add-one — Workflows — When not to add one - https://ota.run/docs/reference/workflows#workflows-8-what-it-looks-like — Workflows — What it looks like - https://ota.run/docs/reference/workflows#workflows-9-how-commands-use-workflows — Workflows — How commands use workflows - https://ota.run/docs/reference/workspace#workspace-guide-1-what-this-file-is-for — Workspace — What this file is for - https://ota.run/docs/reference/workspace#workspace-guide-10-full-example — Workspace — Full example - https://ota.run/docs/reference/workspace#workspace-guide-2-version — Workspace — version - https://ota.run/docs/reference/workspace#workspace-guide-3-workspace — Workspace — workspace - https://ota.run/docs/reference/workspace#workspace-guide-4-repos — Workspace — repos - https://ota.run/docs/reference/workspace#workspace-guide-5-source — Workspace — source - https://ota.run/docs/reference/workspace#workspace-guide-6-how-ota-uses-it — Workspace — How ota uses it - https://ota.run/docs/reference/workspace#workspace-guide-7-use-cases — Workspace — Use cases - https://ota.run/docs/reference/workspace#workspace-guide-8-validation-behavior — Workspace — Validation behavior - https://ota.run/docs/reference/workspace#workspace-guide-9-what-this-is-not — Workspace — What this is not - https://ota.run/docs/reference#reference-1-command — Reference — Command - https://ota.run/docs/reference#reference-2-contract — Reference — Contract - https://ota.run/docs/reference#reference-3-workspace — Reference — Workspace - https://ota.run/docs/reference#reference-4-policy-and-provisioning — Reference — Policy and provisioning - https://ota.run/docs/repo-readiness#repo-readiness-1-what-repo-readiness-means — Repo Readiness — What repo readiness means - https://ota.run/docs/repo-readiness#repo-readiness-2-why-setup-drifts — Repo Readiness — Why setup drifts - https://ota.run/docs/repo-readiness#repo-readiness-3-how-ota-makes-readiness-explicit — Repo Readiness — How ota makes readiness explicit - https://ota.run/docs/repo-readiness#repo-readiness-4-what-defines-readiness-in-practice — Repo Readiness — What defines readiness in practice - https://ota.run/docs/repo-readiness#repo-readiness-5-where-it-fits — Repo Readiness — Where it fits - https://ota.run/docs/repository-automation-tools#repository-automation-tools-1-best-tool-for-repo-setup-validation — Repository Automation Tools — Best tool for repo setup validation - https://ota.run/docs/repository-automation-tools#repository-automation-tools-2-where-ota-fits — Repository Automation Tools — Where ota fits - https://ota.run/docs/repository-automation-tools#repository-automation-tools-3-when-ota-is-the-right-layer — Repository Automation Tools — When ota is the right layer - https://ota.run/docs/repository-automation-tools#repository-automation-tools-4-how-to-evaluate-repository-automation-tools — Repository Automation Tools — How to evaluate repository automation tools - https://ota.run/docs/surfaces#surfaces-1-what-runtime-surfaces-are — Runtime Surfaces — What runtime surfaces are - https://ota.run/docs/surfaces#surfaces-10-workflow-exposes-with-surfaces — Runtime Surfaces — Workflow exposes with surfaces - https://ota.run/docs/surfaces#surfaces-11-literal-external-probes — Runtime Surfaces — Literal external probes - https://ota.run/docs/surfaces#surfaces-12-multi-front-door-app-example — Runtime Surfaces — Multi-front-door app example - https://ota.run/docs/surfaces#surfaces-13-when-not-to-use-surfaces — Runtime Surfaces — When not to use surfaces - https://ota.run/docs/surfaces#surfaces-14-command-behavior — Runtime Surfaces — Command behavior - https://ota.run/docs/surfaces#surfaces-15-design-rule — Runtime Surfaces — Design rule - https://ota.run/docs/surfaces#surfaces-2-why-runtime-surfaces-exist — Runtime Surfaces — Why runtime surfaces exist - https://ota.run/docs/surfaces#surfaces-3-surfaces-shorthand-and-full-listeners — Runtime Surfaces — Surfaces, shorthand, and full listeners - https://ota.run/docs/surfaces#surfaces-4-basic-http-surface — Runtime Surfaces — Basic HTTP surface - https://ota.run/docs/surfaces#surfaces-5-attach-surfaces-to-tasks — Runtime Surfaces — Attach surfaces to tasks - https://ota.run/docs/surfaces#surfaces-6-why-attachments-stay-explicit — Runtime Surfaces — Why attachments stay explicit - https://ota.run/docs/surfaces#surfaces-7-native-list-form — Runtime Surfaces — Native list form - https://ota.run/docs/surfaces#surfaces-8-container-attachment-override — Runtime Surfaces — Container attachment override - https://ota.run/docs/surfaces#surfaces-9-workflow-readiness-with-surfaces — Runtime Surfaces — Workflow readiness with surfaces - https://ota.run/docs/topology-guide#topology-guide-1-start-with-the-decision — Topology decision guide — Start with the decision - https://ota.run/docs/topology-guide#topology-guide-2-shared-baseline-vs-execution-context-requirements — Topology decision guide — Shared baseline vs execution context requirements - https://ota.run/docs/topology-guide#topology-guide-3-when-the-base-context-is-too-broad — Topology decision guide — When the base context is too broad - https://ota.run/docs/topology-guide#topology-guide-4-contract-baseline-vs-task-scoped-requirements — Topology decision guide — Contract baseline vs task-scoped requirements - https://ota.run/docs/topology-guide#topology-guide-5-service-scoped-lifecycle — Topology decision guide — Service-scoped lifecycle - https://ota.run/docs/topology-guide#topology-guide-6-service-lifecycle-vs-task-prerequisites — Topology decision guide — Service lifecycle vs task prerequisites - https://ota.run/docs/topology-guide#topology-guide-7-native-container-and-remote — Topology decision guide — Native, container, and remote - https://ota.run/docs/topology-guide#topology-guide-8-how-ota-turns-the-choice-into-payoff — Topology decision guide — How Ota turns the choice into payoff - https://ota.run/docs/topology-guide#topology-guide-9-common-mistakes — Topology decision guide — Common mistakes - https://ota.run/docs/troubleshooting#troubleshooting-1-common-checks — Troubleshooting — Common checks - https://ota.run/docs/troubleshooting#troubleshooting-2-if-a-repo-is-not-discovered — Troubleshooting — If a repo is not discovered