Ota v1.6.21 Now available

v1.6.21 is a shell-glue removal release.

A lot of the pressure-testing work around Ota has exposed the same underlying problem: repos often know the truth, but they hide it in weak places.

That truth ends up buried in:

• cd ... && ... command bodies
• one-off install commands
• repo-local Helm state assumptions
• CI-only workflow knowledge
• shell snippets that happen to work but do not say who owns what

That is exactly the kind of ambiguity Ota is supposed to eliminate.

Execution governance gets weaker when the contract has to point at opaque shell glue for things the product should understand structurally.

So the goal for v1.6.21 was direct: move more working-directory truth, install truth, tool acquisition truth, adapter truth, and Helm truth into first-class declared surfaces that humans, CI, and AI agents can actually trust.

v1.6.21 ships a broad set of improvements, but the release hangs together around one architectural move: Ota now owns more of the repo's real operating model directly instead of forcing authors to smuggle that truth through shell wrappers.

1. Working-directory truth became first-class

One of the ugliest forms of shell glue in real repos is fake directory switching:

cd services/api && pnpm test

That command can work, but it hides important truth:

• the repo is saying the task is rooted in a subdirectory
• that subdirectory is part of the task contract
• the preview and listing surfaces should show that fact directly

v1.6.21 fixes that by widening structured task commands with command.cwd and structured launches with launch.cwd.

That matters for more than cosmetics.

Once working-directory truth is first-class:

• contracts stop teaching fake cd ... && ... shell bodies
• previews can show the actual runnable context directly
• task listings can surface real execution posture instead of shell choreography
• service launches rooted in subdirectories stop depending on wrapper glue

This is one of the cleanest examples of Ota getting more honest about how repos really work.

2. Install source truth became explicit for agents and repos

This release also sharpens a question that has been too fuzzy for too long:

where exactly should Ota come from in a governed repo?

v1.6.21 widens agent.bootstrap.ota with first-class structured source kinds:

• version
• git_rev
• branch

That means repo contracts can now declare:

• a released proof pin
• a deterministic unreleased proof pin
• an active pressure-testing branch truth

without hiding install ownership inside raw shell strings.

That is a meaningful product improvement because install source is not incidental. It affects trust.

If a repo claims to be validating against a released Ota version while actually depending on an unreleased branch, the execution story is already drifting.

This release makes that drift much harder to hide. Ota now renders shell and PowerShell installer commands from structured source truth, validates source-specific pin semantics, and warns when branch tracking is being used as non-deterministic bootstrap drift.

That is exactly the kind of honesty a governance system should enforce.

3. Tool acquisition moved closer to the contract

v1.6.21 also expands what the repo can own about standalone CLI tools.

Ota now widens tools.<name>.acquisition in two important directions:

• first-class downloadable binaries through provider: release_asset
• package-manager-backed standalone CLI ownership across apt, brew, winget, choco, and scoop

This is a bigger deal than it sounds.

Before this, repos often had to split tool truth awkwardly:

• identity in one place
• install instructions somewhere else
• platform-specific acquisition in docs, scripts, or CI glue

Now more of that ownership can live where it belongs: in the repo contract.

The release also widens archive-backed release assets to support extraction metadata and zip archives, which closes an important Windows-style binary installation lane instead of leaving it as second-class shell teaching.

That means a repo can model exact standalone tool fulfillment much more directly, while doctor, dry-run previews, provisioning requests, and selected execution paths all stay aligned to the same declared source of truth.

4. Helm execution got less fragile and more honest

Helm is one of the better examples of how repo tooling often looks simple while depending on hidden machine state.

The old failure mode was ugly:

• cached Helm repository state could leak into chart inputs
• chart-local work could be poisoned by oversized cached index files
• helm dependency build could fail for reasons that did not actually belong to the chart
• healthy hosts could still fail generic version probing through the wrong command path

v1.6.21 tightens this substantially.

Helm dependency hydration now keeps repository state out of chart inputs while preserving deterministic per-chart isolation. Ota reads repositories from Chart.yaml, seeds them into isolated repo-owned Helm state, and runs helm dependency build . without depending on preexisting user-global helm repo add state.

This is the right direction for Ota.

The repo should not quietly depend on whatever global Helm state happened to exist on one maintainer machine.

The release also improves Helm version probing and expands first-class Helm adapter overlay ownership so tasks can declare:

• cwd
• values_files
• chart
• release_name
• namespace

as contract truth instead of hard-coding that selection in argv or shell.

That is a much better model for both humans and agents. Helm-backed work becomes more reproducible, less magical, and easier to review before execution happens.

5. Dependency hydration governance got stricter

v1.6.21 also tightens one of the easiest places for repos to regress into weak shell teaching:

package-manager install commands that should really be declared as structured dependency hydration.

This release widens first-class Node dependency hydration with explicit npm force ownership via prepare.source.force: true on source.kind: node_package_manager with manager: npm and mode: install or mode: ci.

That matters because these are real repo shapes, but they are also exceptional override lanes that should not be hidden inside opaque task shell.

Once Ota owns them structurally, the repo can be much more honest about what is happening:

• the package manager is explicit
• the override is explicit
• preview, doctor, and provisioning surfaces all see the same truth

The release also sharpens governance around raw shell install bodies.

Validate and doctor now warn when a contract declares that exceptional npm force hydration lane, and they also flag raw npm install --force / npm ci --force task bodies as replaceable structured dependency hydration.

That is exactly the right kind of hardening for Ota.

It does not pretend those lanes do not exist.

It makes them legible and governable instead of teaching repos to bury them in shell.

6. Adapter ownership got broader, not just deeper

This release is not only about Helm-specific cleanup.

It also strengthens the broader adapter-overlay model.

Ota widens the public adapter contract from family-specific teaching like:

• adapter_inputs.compose.*
• adapter_inputs.bake.*

toward the canonical:

• adapter_inputs.overlays.<family>.*

while keeping compose and bake as compatibility aliases for existing contracts.

That is a bigger architectural move than it may seem.

It means adapter-owned truth is becoming more uniform across families instead of growing as a set of one-off exceptions.

The release also fixes compatibility projection for older compose alias inputs so repos do not break while the public model gets cleaner.

That is how a governance system should widen:

• strengthen the canonical model
• preserve truthful compatibility
• reduce duplicate ways to say the same thing

7. Human task output got more truthful

This release does not only improve deep contract surfaces. It also tightens what people actually see when they inspect a repo.

ota tasks now does a better job of showing:

• the effective runnable default mode
• first-class structured command bodies
• alternate runnable invocations for multi-mode tasks
• cleaner output without placeholder rows or duplicated noise

That sounds small until you look at how people and agents actually work.

If the task surface is noisy or misleading, the repo still invites wrong guesses even when the contract underneath is better.

Execution governance only works if the visible front door stays aligned with the declared model.

v1.6.21 makes that front door much cleaner.

8. The docs and GitHub install story got more coherent

This release also closes a documentation and ownership gap that mattered more than it should have.

The GitHub install path is now sharper around:

• ota-run/setup@v1 contract mode
• ota-run/action@v1 with source: contract
• the canonical setup + action install: never split
• wrapper-owned contract consumption when that is the truthful path

That helps in two ways.

First, humans and agents now get a clearer install story from the docs themselves.

Second, repos no longer need to invent a second GitHub-specific helper truth when agent.bootstrap.ota.source should already be the canonical install surface.

This is exactly the sort of cleanup Ota needs as it becomes more serious infrastructure: one install truth, reused everywhere, instead of several almost-canonical variants.

One concrete example

Imagine a repo that:

• runs a Helm-backed deployment helper from a subdirectory
• bootstraps Ota from an active unreleased branch while pretending it is using a release
• installs Helm through a one-off platform script
• teaches contributors to cd deploy/charts/api && helm dependency build

That repo may work.

It is also doing too much of its execution governance through implication.

v1.6.21 gives that repo a much better path.

The contract can now declare:

• the exact Ota bootstrap source kind and pin semantics
• the selected working directory for finite commands and structured launches
• first-class tool acquisition for Helm
• first-class Helm overlay truth and isolated dependency hydration
• stricter package-manager hydration ownership instead of raw install shell
• broader adapter-overlay ownership under one canonical model

That is the difference between "this repo has a pile of working shell" and "this repo has an explicit operating model."

That difference is where Ota becomes much more interesting than a nicer task runner.

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

• Get Started: Install Ota and begin with ota doctor
• Contract reference: Contract for agent.bootstrap.ota, tool acquisition, tasks, workflows, and agent boundaries
• Command reference: Commands for ota tasks, ota doctor, ota run, and ota up
• Workflow modeling: Workflows for prepare paths, runnable modes, command ownership, and execution context
• JSON output: JSON output reference for machine-readable previews, provisioning, and execution reporting

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

If you already use Ota, upgrade and verify:

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

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

Ota is not trying to preserve shell-era repo folklore with slightly nicer wrappers.

It is turning more of execution truth into declared, reviewable, machine-readable contract ownership.