Recommended next

Typical signals

the repo has multiple valid workflows with different runtime and tool needs
one workflow activates pnpm through Corepack while another uses first-class uv hydration through the Python toolchain
diagnosis and preparation should only surface the acquisition lane for the selected workflow

Why it matters

it turns a repo pattern into something humans, CI, and agents can read the same way
it makes the next command obvious instead of implied by README drift
it keeps readiness, setup, and execution explainable in receipts and diagnostics

Example contract

Use this when the repo has more than one honest front door and each one should carry its own acquisition lane instead of inheriting repo-global prerequisites.

The example keeps pnpm acquisition on the web workflow through Corepack and keeps Python dependency hydration on the python workflow through Ota's first-class uv prepare surface.

ota.yamlyaml

version: 1project:  name: tool-acquisition-flow  description: Focused example for workflow-scoped tool acquisition through Corepack and structural Python hydrationtoolchains:  node:    version: "22"    package_managers:      pnpm: "10"  python:    version: "3.12"tasks:  setup:web:    prepare:      kind: dependency_hydration      medium: package_dependencies      source:        kind: node_package_manager        cwd: .        manager: pnpm        mode: install    requirements:      toolchains:        - node  test:web:    command:      exe: pnpm      args:        - test    depends_on:      - setup:web    requirements:      toolchains:        - node  setup:python:    prepare:      kind: dependency_hydration      medium: package_dependencies      source:        kind: uv        cwd: .    requirements:      toolchains:        - python    effects:      writes:        - .venv      network: true      network_kind: dependency_hydration  lint:python:    command:      exe: uv      args:        - run        - ruff        - check        - .    depends_on:      - setup:python    requirements:      toolchains:        - pythonworkflows:  default: web  web:    intent: local_development    description: Node workflow that selects only the Corepack-managed pnpm lane    setup:      task: setup:web    run:      task: test:web  python:    intent: local_development    description: Python workflow that selects only the command-backed uv acquisition lane    setup:      task: setup:python    run:      task: lint:python

Task notes

Use ota workflows . first, then compare ota doctor --workflow web . with ota doctor --workflow python . so you can see that only the selected lane appears.

Use ota up --dry-run --workflow web . when you want the Corepack path, and ota up --dry-run --workflow python . when you want the command-backed uv path. The point is not that both lanes exist; the point is that Ota keeps them separated honestly.