mise Resolves Tools. Ota Governs Repository Acceptance.

mise is one of the cleanest ways to make a repository's tool environment explicit.

It can tell contributors, CI, and agents which runtime versions and command environment a project expects.

That matters.

But a resolved environment is not the same thing as accepted repository execution.

mise helps answer:

Which tools and versions should this repo use?

Ota answers a different question:

Is the selected repo path ready, safe, canonical, and verified?

Those two layers work well together because they solve different parts of the same operational problem.

For modern repositories, especially ones touched by AI agents, that distinction matters. The failure is not always "wrong Node version" or "missing Python". Many repo failures happen after the right tools are already present.

The repo still needs to declare setup, task truth, readiness, verification, agent safety, runtime mode, and proof boundaries.

That is Ota's layer.

mise is good at environment and tool resolution.

It gives a repo a compact way to declare things like:

• which Node version should be used
• which Python, Go, Ruby, or other tools matter
• which tool versions should be installed or activated
• which command environment should be entered
• which repo-owned task aliases should exist

That is valuable for contributors and agents because it reduces host guesswork.

Without a tool manager, a new contributor may have the wrong runtime, a stale global binary, or an old package manager sitting on PATH.

With mise, the repo can make more of that explicit.

That is a strong foundation.

The problem starts when teams treat environment resolution as repository acceptance.

They are not the same thing.

The right tools can be installed and the repo can still be ambiguous about:

• which setup path is canonical
• whether dependencies have been hydrated
• whether services are required
• whether test, check, ci, or verify is the accepted lane
• whether local and CI execution agree
• whether a task is safe for an agent
• whether a green command proves a narrow slice or the full repo

mise can help run commands in the right environment. It does not, by itself, decide which command should count as the repo's acceptance path.

That is not a weakness in mise. It is a layer boundary.

Repository acceptance means the repo can answer:

• what must exist before work begins
• how prerequisites are materialized
• which task or workflow is canonical
• which runtime mode is selected
• what readiness means
• what proof was produced
• what was explicitly not proved
• what an AI agent is allowed to run

That is why Ota uses ota.yaml.

The contract is not just a list of commands. It is an operating model for the repo.

Ota can declare:

• toolchains
• setup and dependency hydration
• tasks and workflows
• native and container modes
• services and readiness checks
• safe tasks for agents
• protected and writable paths
• proof and receipt output
• CI drift and governance findings

That gives the repo a shared acceptance surface for humans, CI, and agents.

The mature pattern is not "Ota instead of mise."

It is:

• mise owns tool and environment resolution where the repo uses it.
• Ota owns repository readiness, canonical tasks, execution boundaries, and acceptance proof.

That lets each layer do its real job.

If a repo already uses mise.toml, Ota should not flatten that truth into vague shell glue. The contract should preserve that mise is the environment authority, then model what the repo does inside that environment.

For example:

orchestrators:  mise:    kind: mise    required: true    config_files: [mise.toml]    activation:      trust: true    prepare:      install: true toolchains:  node:    version: "22"    fulfillment:      source: mise      mode: run tasks:  verify:    description: Run the accepted verification lane    command:      exe: pnpm      args:        - test    execution:      orchestrator:        ref: mise        mode: exec    safe_for_agent: true

Here mise owns tool activation and the runner invokes pnpm test through mise exec. Ota still owns the selected verification lane and its agent-admission posture. The point is not that every repo should use this exact shape; it is that the environment authority remains explicit instead of being hidden in shell glue.

AI agents are bad at unspoken repository assumptions.

They can read many files, but reading more does not create authority.

If the repo has:

• a mise.toml
• a README command
• a package script
• a CI workflow
• an AGENTS.md instruction
• a local shell wrapper

the agent still has to decide which signal is authoritative.

That is where Ota helps. It can detect and surface repo evidence, but the Ota contract reference gives the final declared path:

• run ota doctor to inspect readiness
• run ota tasks --use to see canonical usage
• run ota up to prepare the selected path
• run ota run verify --agent when the task is admitted for agents

The agent does not have to infer from scattered signals. It follows the repo contract.

There is a safety distinction here too.

A correctly resolved environment does not make every command safe.

An agent inside the right mise environment can still run:

• a destructive migration
• a publish command
• a broad cleanup script
• a task that mutates external state
• a verification lane that assumes secrets or live services

Tool correctness is not execution permission.

Ota's agent boundary exists because safe execution needs more than the right runtime. It needs a declared safe surface and a runner that can enforce it.

That is why Ota separates:

• human command usage
• agent-admitted command usage
• safe task closure
• effects and protected paths
• proof and refusal output

mise can make the environment correct. Ota's contract declares what the selected path may claim as safe, ready, and proved; Ota evaluates that claim and carries its explicit proof boundaries.

When Ota sees mise.toml, it does not treat it as random configuration.

It treats supported tool declarations as repo-owned evidence with provenance.

That evidence can help answer:

• which toolchains are expected
• which versions are pinned or ranged
• whether the contract's declared runtime differs from the repo-owned tool source
• whether a declared task is explicitly mediated by mise
• whether supported CI and contract evidence disagree

But Ota should stay honest.

mise.toml is strong evidence for environment resolution. It is not complete evidence for repository acceptance.

That means Ota should preserve provenance:

• mise evidence can support toolchain truth and reveal runtime drift
• the contract still owns selected setup, tasks, workflows, and proof
• a task runs through mise only when its contract declares the mise orchestrator
• doctor surfaces conflicts Ota can establish from supported repo-owned sources
• unsupported or ambiguous claims should remain visible instead of inferred away

That is the difference between helpful detection and overconfident automation.

In a serious repo, the flow should feel boring:

ota doctorota tasks --useota upota run verify

If the contract declares mise as the selected task orchestrator, Ota invokes the task through mise on that path.

If the host runtime differs from a high-confidence mise.toml declaration, doctor can name that drift. It does not silently convert a host mismatch into acceptance: the selected task must still run and produce its declared evidence.

Where Ota can recover both CI and toolchain evidence, it can surface a supported conflict rather than asking an operator to reconstruct it from a later failing build.

If a task only works because a developer already has a warmed environment, Ota should not call that accepted readiness.

The goal is not more YAML for its own sake. The goal is fewer hidden assumptions.

The clean distinction is:

• mise resolves the environment.
• Ota governs repository acceptance.

That means mise can be a strong input to Ota, but it should not be forced to carry all execution meaning.

Do not overload an environment manager with:

• agent safety
• proof breadth
• readiness semantics
• CI drift governance
• protected path policy
• runtime receipts

Those are Ota concerns.

The repo needs both layers when it wants both reliable environments and trustworthy execution.

Read the Ota command reference for the doctor, preparation, and execution surfaces that apply the contract.

Use mise when the repo needs strong tool and environment resolution.

Use Ota when the repo needs to make that environment operationally useful:

• accepted setup
• canonical tasks
• safe agent lanes
• verification after changes
• local and CI alignment
• machine-readable proof
• bounded claims about what passed and what did not

For AI-agent work, that combination is stronger than either layer alone.

mise gets the agent into the declared environment. Ota tells it which lane is admitted, what that lane must prove, and where the claim ends. Environment resolution is necessary; repository acceptance is the bar.