Ota v1.6.17 Now available

v1.6.17 is a trust release.

Pressure-testing across real repositories exposed a recurring pattern: readiness contracts looked valid, but selected execution paths were still too easy to misread or over-assume. Host-only tools could show up in unrelated container/remote previews, task-path tool requirements could depend on duplicate global declarations, and agent-safe guarantees were not strict enough across transitive task chains.

That kind of ambiguity is expensive. Humans lose time. CI becomes noisy. Agents take riskier actions than the contract author intended.

The goal for this release was simple: make the selected path explicit, make bootstrap deterministic, and make safety boundaries enforceable.

v1.6.17 ships a focused set of platform-level improvements:

1. Scoped requirement resolution for selected task/workflow paths: container and remote paths no longer inherit host-global tools fallback when scoped requirements are present.
2. Task-scoped tool gates: tasks.<name>.requirements.tools and requirements.any_of[].tools now validate as self-contained gates without forcing duplicate top-level tool declarations.
3. Clearer dry-run context semantics: preview output now separates Task Context from Execution Context, and JSON includes additive requested_context and selected_context.
4. Stronger agent-safe validation: write-boundary checks now walk transitive task chains, so safe-task declarations fail when reachable dependencies violate protected or writable-path boundaries.
5. First-class deterministic bootstrap actions: ensure_env_file, ensure_file, and ensure_directory remove shell glue for common bootstrap cases.
6. Expanded readiness and conditional checks: checks[].kind: changed_files, services.*.readiness.kind: compose_health, and multi-surface runtime readiness via signal_probes.
7. Schema-first JSON validation in CI: ota json validate now supports both command-execution and artifact-first (--input) validation paths.

This release is about reducing hidden assumptions. Contracts now express alternative requirement branches more cleanly (any_of), readiness checks are more precise, and dry-run output is safer for both humans and automation.

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 run, ota up, ota doctor, ota tasks, ota json validate).
• Workflow modeling: Workflows for readiness and execution intent.

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

If you already use Ota, upgrade and verify:

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

If you are evaluating Ota for the first time, this is a strong version to start with: the execution path is clearer, bootstrap is more deterministic, and the agent boundary model is stricter where it matters most.