Ota v1.6.22 Now available

v1.6.22 is an orchestration-and-execution-truth release.

As Ota has matured, the pressure is no longer only about whether one repo command can run once on one machine.

The harder problem is whether the contract can honestly own:

• cross-repo workspace coordination
• multi-step setup without shell glue
• Compose-backed runtime and control lanes
• multi-instance workflow families
• execution evidence that explains contract drift against new failures

Those are not task-runner problems.

They are execution-governance problems.

That is what this release pushes forward.

v1.6.22 makes Ota stronger in five connected areas:

• workspace orchestration
• structured setup and bootstrap
• Compose ownership
• workflow-instance and attach modeling
• semantic snapshot and receipt correlation trust

The common theme is simple: more of the repo's actual operating model can now live in the contract instead of leaking into shell wrappers, CI glue, or maintainer memory.

v1.6.22 ships a broad set of improvements, but the release is coherent. It moves more execution truth onto governed public surface and tightens the machine-readable evidence around what changed.

1. Workspace orchestration became more truthful

Real workspaces rarely have perfectly uniform repos.

One repo may call the task generate-sdk. Another may call the same intent prepare-dev. A third may not expose the same verb at all.

Before this release, that mismatch pushed workspaces toward convention pressure or wrapper glue.

v1.6.22 fixes that with first-class workspace task bindings under repos.<name>.tasks.<workspace_task>.task.

That means one workspace command can now map cleanly to repo-local task names while still keeping execution receipts honest about what actually ran in each repository.

The same release also adds --progress-json across workspace doctor, check, status, receipt, diff, run, up, and refresh.

That is important because workspace orchestration is not only about control. It is also about observability.

Automation can now follow live structured progress while preserving the final JSON report on stdout. Ota is no longer asking machine consumers to infer workspace execution state from plain terminal text.

2. Structured setup widened well beyond dependency install

This release also strengthens one of the most important adoption paths in Ota: turning setup truth into structure instead of shell choreography.

prepare.kind: sequence can now combine mixed structural setup steps, including:

• dependency hydration
• tool bootstrap
• env-file materialization
• file and directory preparation
• Git checkout materialization
• container-network setup
• Compose volume reset

That matters because many real repos do not have just one setup step.

They have ordered setup truth that used to collapse back into shell scripts simply because Ota could only own one narrow lane at a time.

v1.6.22 removes more of that pressure.

The same theme shows up in the new setup surfaces:

• prepare.kind: tool_bootstrap now owns Playwright browser bootstrap through Node package-manager

and Poetry-backed paths

• action.kind: ensure_git_checkout now gives deterministic clone-if-missing checkout ownership to

the contract itself

• effects.adapter_state lets setup paths declare durable adapter-owned state such as Compose

volumes without faking those mutations as repo writes

This is exactly the direction Ota should keep taking. Setup becomes more machine-readable, reviewable, and governable, and less dependent on “run this helper and hope it means the same thing everywhere.”

3. Compose moved much deeper into first-class ownership

v1.6.22 is also one of the strongest Compose releases Ota has shipped so far.

The contract can now own more of the real Compose surface directly instead of forcing authors to hide that truth inside raw docker compose ... or podman compose ... command bodies.

This release adds or broadens:

• launch.kind: compose for long-running persistent compose up runtime starts
• structured tasks.<name>.compose lanes for exec, run, attach, up, down, build,

stop, restart, rm, logs, and ps

• compose.timeout_seconds for graceful down -t
• compose.remove_volumes: true for down -v
• ordered services.<name>.manager.files and manager.env_files
• ordered prepare.source.files and prepare.source.env_files for Compose-backed image hydration

This is more than feature count.

It closes a governance gap.

Compose stacks are one of the easiest places for repos to look structured while still hiding real behavior in argv fragments and wrapper scripts. Ota now owns much more of that behavior explicitly:

• how a stack starts
• how it is inspected
• how it is stopped
• how files and env-file overlays are selected
• how staged service-side commands execute

That means better dry-run previews, better receipts, and less split-brain between runtime truth and task truth.

4. Workflow families became more expressive

Some repos do not have just one “dev” runtime.

They have one workflow family with several honest instances:

• different ports
• different overlays
• different listeners
• different dependent instance ordering
• different attach behavior

v1.6.22 makes that model first-class.

The release adds workflow-instance selection with workflow@instance, then widens it with:

• topology.requires_instances for declared sibling-instance bring-up order
• instance-specific task runtime overlays
• structured workflow-owned rendered json and toml files with instance-aware placeholder

substitution

• workflows.<name>.attach.task plus tasks.<name>.compose.kind: attach for detached runtime

workflows that need one canonical re-attach lane

This is a meaningful architectural step.

Instead of flattening multi-instance truth into pseudo-workflows or repo-local helper scripts, Ota can now model one runtime family as one runtime family.

That improves both operator clarity and machine reasoning. Workflow selection, readiness, cleanup, proof, and attach behavior can all stay aligned to the same declared topology.

5. Semantic contract evidence became much stronger

This release also pushes Ota further beyond “command succeeded” reporting and into contract-aware execution evidence.

v1.6.22 adds the core V10 semantic snapshot and correlation path:

• semantic contract snapshot identity on receipts
• archived normalized contract snapshots
• assumption-set hashes
• semantic ota diff over normalized contract truth
• ota receipt --snapshot for archived snapshot inspection
• receipt-to-receipt drift correlation with structured contract_changes[],

likely_related_changes[], and summary.comparison.correlation

That matters because execution governance is not only about running the selected path.

It is also about answering:

• what changed in repo truth
• whether that change plausibly explains the new failure
• whether the break belongs to env, services, tasks, workflows, tools, or checks

This release makes that story much more explicit and machine-readable.

The correlation path is also intentionally honest.

It does not pretend every changed assumption is causal. Instead, it gives operators and automation one better surface for comparing semantic repo truth against execution drift without collapsing everything back into raw YAML diffs and guesswork.

6. The safety model tightened around real execution

The final release theme is safety through better selected-path ownership.

v1.6.22 tightens concurrency and proof behavior in ways that matter in actual use:

• overlapping runs now conflict on the full selected write path, not only the requested leaf task
• detached service-start proof keeps probing readiness after launcher exit instead of treating the

launcher itself as the readiness boundary

• ota proof runtime --host-port widens host-port override support for proof isolation
• Ota now preserves more backend and dependency-plane provenance in dry-run JSON and receipts

These are not flashy features, but they matter.

Execution governance gets weaker if concurrent runs can corrupt shared state, if detached runtime proof stops at the wrong boundary, or if machine-readable previews cannot explain which backend or dependency plane Ota actually selected.

This release makes those boundaries more trustworthy.

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 tasks, workflows,

services, setup, Compose, and agent boundaries

• Command reference: Commands for ota doctor,

ota check, ota run, ota up, ota proof runtime, ota receipt, and ota diff

• Workflow modeling: Workflows for workflow selection,

setup, readiness, instance overlays, and attach behavior

• Semantic snapshots and correlation:

Semantic Snapshots and Correlation for archived contract truth, snapshot inspection, and receipt-to-receipt drift correlation

• JSON output: JSON output reference for machine-readable

previews, receipts, and execution diagnostics

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

If you already use Ota, upgrade and verify:

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

If you are evaluating Ota for the first time, v1.6.22 is one of the clearest releases yet for understanding the product’s direction.

Ota is not only trying to make repositories runnable.

It is building execution governance for humans, CI systems, automation, and AI agents, where the contract becomes the authoritative source of truth for setup, services, runtime ownership, orchestration, and execution evidence.