Pressure-Testing Ota in Real Repos and Shipping the Fixes

This feature note comes from pressure-testing Ota in real repositories: OpenHands, Flowise, Twenty, Osiris, Cal.diy, Hoppscotch, and Supabase.

The goal was not to make contracts pass by exception. The goal was to close platform gaps that caused drift between local and CI behavior, native and container execution paths, human and agent execution safety, and one-off success versus repeatable readiness.

Across repos, the same failure patterns repeated:

1. Requirement rendering leaked global optional tools into unrelated task previews.
2. Task-level tool requirements were too coupled to top-level declarations.
3. Dry-run context output could be misread (task context versus execution context).
4. Agent-safe validation needed to follow transitive task dependencies.
5. Common bootstrap tasks still required shell glue for idempotent file and env setup.
6. Contracts needed cleaner support for alternative requirement paths.
7. Repo matrices needed stronger native and container proof symmetry.

These were platform trust issues, not repo quirks.

1) Scoped requirement resolution

Container and remote paths now resolve only requirements that apply to the selected task or workflow path.

2) Task-scoped tool gates

Task-level tool requirements now validate as self-contained gates without forcing duplicate top-level declarations.

3) any_of requirement branches

Contracts can model alternative valid paths (runtime, tools, env, checks, and more) with first-class disjunctive branches.

4) Clearer dry-run context semantics

Dry-run output and JSON now separate task context from selected execution context more clearly.

5) Stronger agent-safe boundary validation

Agent-safe validation now walks transitive dependency chains and enforces writable and protected boundaries across reachable tasks.

6) Deterministic bootstrap actions

First-class bootstrap actions cover common deterministic setup cases (file, env, and directory creation) without command-shaped shell glue.

7) Readiness checks and matrix proof shape

Pressure-test matrices were hardened to prove native and container paths where valid, with explicit unsupported-host lanes where expected.

Canonical references:

• Install Ota
• Contract reference
• Command reference
• Workflows reference

Shipped in:

• Ota v1.6.17

Quick verification path:

ota validateota tasksota run <task> --dry-runota up --workflow <name> --dry-runota doctor --workflow <name>

Machine-checkable verification:

ota run <task> --dry-run --jsonota json validate --schema command-output --input <file-or-stdin>

For CI proof shape, run matrix lanes that cover native paths, container paths where supported, and explicit unsupported-host diagnostics where intentionally expected.