Ota v1.6.19 Now available

v1.6.19 is an execution trust release.

Pressure-testing across real repositories exposed a recurring pattern: Ota had become much better at modeling selected execution paths, but trust still depended on small details staying honest. A dry-run could be mostly right, but miss a selected environment blocker. A toolchain could be declared, but the actual command path could drift. A task could fail, but the most useful failure excerpt could be buried under noisy test output. A container proof could pass, then be marked failed because Docker cleanup lagged for a moment.

Those details matter. Execution governance is not only about whether a repo can run. It is about whether every diagnosis, preview, proof, failure, and policy decision reflects the actual selected path.

That is the difference between a helpful contract and a misleading one.

The goal for this release was simple: make selected-path execution more trustworthy, make toolchain ownership more accurate, make failures easier to understand, and make effect governance enforceable before risky work begins.

v1.6.19 ships a focused set of trust and governance improvements.

1. Selected-path diagnosis got stricter

Ota now does a better job of following the actual selected task, workflow, mode, and backend instead of drifting into repo-global assumptions.

• shell wrappers like sh, bash, and zsh are no longer misclassified as required tools
• repo-local executables such as bin/bundle are no longer treated as missing global host tools
• workflow diagnosis now scopes service checks to the selected workflow and task closure
• host architecture constraints can now fail early with execution.contexts.<name>.only_arch
• container image acquisition failures now surface as one clear blocker instead of cascading noise

2. Toolchain ownership got more accurate

Ota is now more honest about which runtime or package manager actually owns the selected path.

• Corepack-managed tools are probed through the selected container backend in the repo workdir
• repo-scoped version-manager environments such as mise exec are preserved during probing
• toolchains.python with provider: uv now probes real Python runtime candidates
• Go, Ruby, and .NET move closer to canonical toolchain ownership
• selected-path requirement surfaces now project toolchain-owned commands earlier and block sooner when the selected backend cannot provide them

3. Runtime evidence and failure output got more trustworthy

This release also tightens what Ota records and what it shows when something goes wrong.

• concurrent ota run locks now fail fast with clearer execution context and rerun guidance
• ota run --log recreates a deleted live log file instead of silently losing log continuity
• Compose diagnosis fails from manager truth immediately when a required service is not running
• failing-task excerpts now prioritize real failure signals such as FAIL, Failed Tests, and AssertionError
• non-root container package-install failures now point operators toward image-level fixes instead of in-task apt-get

4. Policy and effect governance got more enforceable

Ota now blocks more risky or misleading behavior before execution starts.

• secret: true env requirements can no longer ship with contract defaults
• contracts can now define policies.effects with allow, warn, and deny decisions
• ota run and ota up now support per-invocation --effect-override
• governed fulfillment lanes can move beyond check-only validation when org policy allows it

5. Contract starters and service-derived inputs got cleaner

The release also improves the contract authoring path itself.

• Node starter contracts only seed dev and test tasks when the root package.json actually declares them
• Ruby starter support now includes ota init --pack ruby
• tasks can now derive environment values from declared service endpoints with env_bindings.<NAME>.from_service, including secret-safe credential handling through password_env

One recurring failure mode in real repos was simple: Ota could be mostly right, but not right enough.

For example, a repo might declare Yarn through Corepack and run inside a selected container workflow. Before this release, diagnosis could still drift toward the image default package-manager path and produce a result that looked plausible but was not actually grounded in the selected execution path.

In v1.6.19, that diagnosis now follows the selected backend, in the repo workdir, through the declared toolchain ownership model. That is a small detail on paper, but it is exactly the kind of detail that determines whether a contract is trustworthy.

Execution governance only works if the contract stays honest at the point of use.

That means:

• the selected path has to be the path Ota actually diagnoses
• the runtime or package manager Ota blames has to be the one that really owns execution
• policy has to block risky work before the repo runs, not after
• failure output has to surface the useful signal first

That matters for maintainers, new contributors, CI, and coding agents alike. If Ota cannot reliably tell what a repo needs, how it should run, and why it is blocked, it is still asking people to guess.

v1.6.19 reduces that guesswork.

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

• Get Started: Install Ota and run ota doctor first in your repo.
• Contract reference: Contract (requirements, any_of, effects, services, agent).
• Command reference: Commands (ota proof runtime, ota run, ota up, ota doctor, ota tasks).
• Workflow modeling: Workflows for readiness and execution intent.

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

If you already use Ota, upgrade and verify:

ota upgradeota --versionota validateota doctorota run <task> --dry-run --json

If you are evaluating Ota for the first time, v1.6.19 is a good place to start. The selected path is clearer, the execution evidence is more durable, and the governance model is stricter where trust matters most.