Ota v1.6.20 Now Available

v1.6.20 is a contract-governance release.

As Ota has moved from repo readiness into broader software execution governance, the trust problem has shifted.

It is no longer enough for Ota to execute a repository successfully once.

The harder requirement is that every public execution surface stays trustworthy:

• published contract schemas
• doctor findings consumed by automation
• workflow-owned environment truth
• service topology and readiness ownership
• dependency preparation and orchestration behavior
• If those surfaces drift, Ota starts to look correct while becoming less dependable.

That is exactly the kind of failure execution governance is supposed to prevent.

So the goal for v1.6.20 was direct: make more execution truth explicit, machine-readable, versioned, and release-governed.

Feature

v1.6.20 ships a broad but coherent set of governance improvements. The main story is not “more YAML.” The story is that more of the repo’s actual operating model can now be published, validated, and trusted.

1. Contract publication became a governed release surface

Repo and workspace contract schemas are now treated as real public APIs.

That means:

• published repo and workspace schemas are generated from the Rust-owned source of truth
• release and compatibility checks now fail on schema drift
• shipped examples and canonical contract docs validate against those published schemas
• contract publication is no longer a best-effort artifact

This is a meaningful step for humans, CI systems, editors, and AI agents. Once contracts are public machine-readable surfaces, they need the same release discipline as any other API.

2. Doctor output became more stable for machine consumers

ota doctor --json now carries stronger governed identity across findings.

Instead of forcing downstream tooling to infer meaning from rendered summary text, Ota now preserves stable finding identity more consistently across:

• doctor findings
• policy-backed findings
• workflow and service findings
• env and provisioning findings
• ota explain --json
• workspace doctor/check surfaces

That means integrations can depend more on structured codes, categories, ownership, and blocker metadata, and less on brittle summary parsing.

3. Environment ownership became first-class

This release significantly expands what Ota can own around environments.

v1.6.20 adds or strengthens:

• env.profiles
• workflow-level env profile selection
• workflow-owned rendered dotenv artifacts
• richer ensure_env_file behavior
• first-class checks[].kind: env
• allowed host and URL-host assertions
• env-file overlays on task execution paths

The important shift is architectural: environment truth no longer has to be spread across shell snippets, copy commands, grep-based checks, and task-local duplication. More of that logic can now live in the contract itself.

4. Services and topology got more truthful

Service modeling also moved closer to how real systems actually work.

v1.6.20 improves:

• canonical Compose manager modeling
• structured compose_health readiness
• multi-endpoint service identity
• endpoint-specific context ownership
• endpoint-aware readiness and env bindings
• host-published Compose port detection

This matters because real repos rarely have just one flat “service URL.” They have host projections, multiple endpoints, readiness ownership, and task/service relationships that need to be modeled honestly.

5. Workflow, setup, and dependency preparation got stronger

The workflow and setup path is now much more expressive without falling back to shell glue.

This release adds or expands:

• workflow-native prepare.task for finite setup work
• first-class dependency hydration for package and image setup
• aggregate tasks as structured entrypoints
• stronger env-file and setup ownership at the workflow level

That gives contracts a better way to say:

• what must happen before the main workflow
• which setup work is finite and structural
• which verification path is canonical
• how shared preparation should be modeled without fake parent tasks

6. Ota now owns more of the execution layer itself

v1.6.20 also widens execution governance into orchestration and ownership lanes that used to be much looser.

That includes:

• first-class orchestrator modeling
• Mise as the first supported orchestrator
• stronger toolchain ownership, including Poetry under Python
• better separation between runtime/tool/package-manager owners
• better selected-path execution truth for env artifacts and requirement projection

This is one of the more important long-term shifts in the release. Ota is becoming less dependent on opaque shell mediation and more capable of governing the execution layer directly.

One concrete example

Before this release, a repo could still end up with execution truth split across several places:

• contract examples in docs
• generated schemas
• Rust contract types
• doctor JSON
• workflow-owned env behavior Each individual surface might look fine, but if they drifted from each other, machine consumers would get an unreliable picture of the repo.

v1.6.20 closes a lot of that gap.

For example, a workflow can now own environment profile selection and rendered dotenv artifacts directly, while the published contract schema, validation path, execution reporting, and proof JSON all stay aligned to that same declared model.

That is the difference between a feature existing and a feature being governable.

Taken together, these changes do not just add capabilities.

They make more of Ota’s behavior publishable, enforceable, and trustworthy as execution truth.

Docs

If you want to adopt these capabilities directly, use the live docs:

• Get Started: Install Ota and run ota doctor in your repository.
• Contract Reference: Repo contracts, workspace contracts, services, environments, workflows, orchestration, and toolchains.
• Command Reference: ota doctor, ota env, ota run, ota up, ota proof, and related execution commands.
• Environment Modeling: Environment profiles, dotenv rendering, environment checks, and ownership surfaces.
• Service Modeling: Managed services, readiness, endpoint ownership, and topology definitions.

Release

v1.6.20 is live.

If you already use Ota, upgrade and verify:

ota --version
ota validate
ota doctor
ota env
ota run <task> --dry-run --json

If you are evaluating Ota for the first time, v1.6.20 is one of the clearest releases yet for understanding where the product is going.

Ota is not only trying to make repositories runnable.

It is building governed execution truth for humans, CI systems, automation, and AI agents, where contracts, diagnostics, environments, services, toolchains, and orchestration all become explicit parts of the same operating model.
Command reference: Commands for ota doctor, ota env, ota run, ota up, and ota proof
Workflow modeling: Workflows for canonical front doors, setup, prepare, and readiness
JSON output: JSON output reference for machine-readable execution and diagnosis surfaces
Release

v1.6.20 is live here: https://ota.run/releases/v1.6.20

If you already use Ota, upgrade and verify:

VERIFY
bash
Copy
ota upgrade
ota --version
ota validate
ota doctor
ota env
ota run --dry-run --json
If you are evaluating Ota for the first time, v1.6.20 is one of the clearest releases yet for understanding where the product is going.

Ota is not only trying to make repositories runnable.

It is building governed execution truth for humans, CI systems, automation, and AI agents, where contracts, diagnostics, environments, services, toolchains, and orchestration all become explicit parts of the same operating model.