otaExecution governance for software repositories.
Get startedGitHub

Examples

Examples

Validated, current contract patterns for common repo shapes, execution topology, adapter ownership, and workspace layouts.

copynew usersbasicstable2026-08-18

Copy with intent

Browse examples by repo shape, not just by language.

These examples are strongest when they answer the topology question first: one runtime, mixed runtimes, workspace acquisition, or policy-backed provisioning.

05

Start by goal

Use this layer first when you want to prove value quickly instead of scanning every example page.

01

Libraries and SDKs

A repo can be a reusable SDK and still keep readiness, linting, and release flow explicit.

10

Single-repo examples

Use these when one repo owns one contract and one task flow.

04

Mixed and service repos

Use these when more than one runtime or service boundary matters.

09

Focused contract surfaces

Use these when the repo shape is already clear and the real question is which stronger Ota surface should own setup or adapter truth.

03

Execution topology examples

Use these when the hard part is not language support but honest communication between host, workload, service contexts, and dependency storage.

02

Workspace examples

Use these when multiple repos need a shared bootstrap and execution order.

02

Policy and provisioning

Use these when you want to show how repo intent and org policy meet in one contract pair.

01

Advanced examples

This repo lives on GitHub, and the card below is meant to stand apart as a proven pattern to copy and adapt.

Example families

Start by goalLibraries and SDKsSingle-repo examplesMixed and service reposFocused contract surfacesExecution topology examplesWorkspace examplesPolicy and provisioningAdvanced examples

How to choose

Start from the closest topology and trim only what your repo does not need.

The examples are organized so you can choose by operational shape first, then by implementation detail once the readiness contract boundary is already right.

Single runtime

Use language-first examples when one repo owns one loop.

Node, Python, Go, Java, .NET, Rust, and script examples are the shortest path when one readiness contract owns one runtime boundary.

Mixed topology

Use mixed or fullstack examples when more than one runtime must stay explicit.

Choose mixed and service examples when the value comes from keeping boundaries legible instead of collapsing everything into one setup command.

Policy or workspace

Use policy and workspace examples when coordination or governance is the payoff.

Choose these when repo acquisition, approved sources, or multi-repo ordering matters more than the language itself.

Start by goal

5 examples

Use this layer first when you want to prove value quickly instead of scanning every example page.

First contract for one repo

Start with one simple runtime example and prove ota doctor, ota up, and ota run on a small repo shape.

When to use it

Use this when the question is whether Ota is a credible replacement for README drift on one stack.

App repo with services

Start with service-backed contracts where readiness and task flow matter more than a single script.

When to use it

Use this when the repo runs an app, not just a build task.

Shared local topology

Use the topology material when the hard part is truthful communication across workloads, host, and execution boundaries.

When to use it

Use this when depends_on is not the real answer and topology truth is the product value.

Workspace bootstrap

Start with the workspace examples when several repos need one ordered bootstrap path.

When to use it

Use this when repo readiness is not enough and the team needs multi-repo setup.

Broad contract reference

Use the comprehensive contract example only after the smaller shapes already make sense.

When to use it

Use this when you need the widest shipped contract surface in one place.

Libraries and SDKs

1 example

A repo can be a reusable SDK and still keep readiness, linting, and release flow explicit.

Go SDK

A Go library contract with build, test, lint, and release tasks.

When to use it

Use this when releases matter and readiness should be visible.

Single-repo examples

10 examples

Use these when one repo owns one contract and one task flow.

Node.js

A Node contract with setup, dev, and test guidance.

When to use it

Use this for npm or pnpm repos with a clear onboarding path.

Python

A Python contract with a clean setup path and deterministic tests.

When to use it

Use this for uv or pip-based repos that should be easy to verify.

Workflow-scoped acquisition

A focused contract that keeps Corepack and command-backed tool acquisition on separate front doors.

When to use it

Use this when one repo has multiple valid setup lanes and they should not inherit each other's tools.

Rust toolchain ownership

A focused Rust contract that keeps Rustup, cargo, components, and targets under one toolchain owner.

When to use it

Use this when a Rust repo should avoid duplicating ecosystem ownership across runtimes and tools.

Windows-first adoption

A Windows-oriented starter that keeps .NET, PowerShell, and native compiler activation explicit.

When to use it

Use this when the repo is Windows-heavy and the operating model should still stay honest across platforms.

Go

A Go contract with a minimal toolchain and a clear test command.

When to use it

Use this for Go services and libraries with a short loop.

Java

A Java contract with build and test tasks.

When to use it

Use this for JVM repos that need a visible build gate.

.NET

A .NET contract with setup, build, and test tasks.

When to use it

Use this for dotnet repos with a clear boot path.

Rust

A Rust contract with a direct cargo build and test loop.

When to use it

Use this for cargo workspaces or single crates.

Script

A script-driven repo that still gets a readable readiness contract.

When to use it

Use this when scripts still need clear readiness.

Mixed and service repos

4 examples

Use these when more than one runtime or service boundary matters.

Services

A service-oriented repo with healthchecks and explicit readiness.

When to use it

Use this for apps that need startup checks first.

Mixed Node + Python

A repo that coordinates Node and Python without collapsing ownership.

When to use it

Use this when the app and API use different runtimes.

Fullstack Node + Go

A split frontend/backend repo with a clear service-test path.

When to use it

Use this when UI and service readiness stay separate.

Comprehensive contract

A representative broad contract surface with execution, environment, checks, and metadata.

When to use it

Use this when you want to see how major shipped surfaces fit together, not an exhaustive field catalog.

Focused contract surfaces

9 examples

Use these when the repo shape is already clear and the real question is which stronger Ota surface should own setup or adapter truth.

Podman Compose adapter inputs

A focused contract that keeps Podman engine, cwd, env-file, file-stack, profile, and project truth on first-class adapter surfaces.

When to use it

Use this when the real Compose lane is Podman and shell flags are hiding adapter ownership.

Typed systemd host service

A focused contract that keeps host-managed systemd lifecycle and active-state readiness on typed service-manager surfaces.

When to use it

Use this when a Linux service is owned by systemd instead of by an Ota-launched process.

Bake adapter inputs

A focused contract that keeps docker buildx bake file selection in adapter_inputs.overlays.bake.files instead of shell -f flags.

When to use it

Use this when Bake file truth belongs to one task path or one workflow overlay.

Deterministic env bootstrap

A focused contract that uses action.kind: ensure_env_file for governed .env creation, replacement, removal, and secret generation.

When to use it

Use this when env bootstrap is one deterministic host-file mutation instead of shell copy-plus-sed glue.

Bundled deterministic setup

A focused contract that uses action.kind: ensure_bundle for ordered deterministic setup actions without shell orchestration.

When to use it

Use this when one setup lane owns several deterministic setup actions and they should stay in one governed action body.

Deterministic git checkout bootstrap

A focused contract that uses action.kind: ensure_git_checkout for governed sibling or vendored Git materialization.

When to use it

Use this when setup truthfully owns cloning one repo-local checkout and should not hide that bootstrap inside setup.sh or shell git clone glue.

Deterministic git template bootstrap

A focused contract that uses action.kind: ensure_git_template for governed scaffold or factory materialization.

When to use it

Use this when setup truthfully owns cloning one Git-backed template into a fresh local repo and should not hide that bootstrap inside shell git clone, rm -rf .git, or git init glue.

Container network bootstrap

A focused contract that uses action.kind: ensure_container_network for governed external Docker network readiness.

When to use it

Use this when one setup lane owns shared Docker network bootstrap and should not hide docker network inspect/create glue in shell.

Compose service volume reset

A focused contract that uses action.kind: reset_compose_service_volume for governed destructive local data reset on one Compose-managed service.

When to use it

Use this when one local recovery lane truthfully owns stop/rm/volume-reset/restart instead of hiding that sequence in shell glue.

Execution topology examples

3 examples

Use these when the hard part is not language support but honest communication between host, workload, service contexts, and dependency storage.

Container app + Compose Postgres

A shipped topology-aware contract where the app workload joins the Compose network and reaches Postgres by service name.

When to use it

Use this when the workload is containerized and the database is another Compose-managed container.

Container app + host Postgres

A shipped topology-aware contract where the app workload reaches a host-managed database through a typed host manager plus an explicit app-context endpoint.

When to use it

Use this when the workload is containerized but the database remains host-managed.

Container app with isolated node_modules

A container-backed Node contract that keeps node_modules in Ota-managed storage instead of reusing the host tree.

When to use it

Use this when a containerized Node app needs platform-correct dependencies and should not inherit host-native binaries.

Workspace examples

2 examples

Use these when multiple repos need a shared bootstrap and execution order.

Workspace basics

A multi-repo workspace with ordered member readiness.

When to use it

Use this when several repos must be prepared together.

Workspace acquire

A workspace that acquires child repos from git before bootstrap.

When to use it

Use this when repos need to be pulled into place first.

Policy and provisioning

2 examples

Use these when you want to show how repo intent and org policy meet in one contract pair.

Provisioning policy probe

A repo contract plus policy file that resolves approved provisioning sources.

When to use it

Use this when you want a concrete provisioning example to copy into a real repo.

Container provisioning

A real container-backed provisioning example that installs a missing tool inside the container and then runs the task there.

When to use it

Use this when you want the cleanest proof that the container path provisions before setup.

Advanced examples

1 example

This repo lives on GitHub, and the card below is meant to stand apart as a proven pattern to copy and adapt.

GitHub repo

Advanced examples

Browse the maintained repo and reuse the patterns that fit your stack.

When to use it

Use this when you want a proven pattern to copy and adapt instead of starting from scratch.

Copy examples and adapt them to your repo.

Open on GitHub

Next steps

Repo ReadinessContract ReferenceField Notes