DEV Community: Bobai Kato

mise Resolves Tools. Ota Governs Repository Acceptance.

Bobai Kato — Mon, 27 Jul 2026 12:25:30 +0000

Overview

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.

What mise Is Good At

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.

Where Environment Resolution Stops

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 Is A Different Contract

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 Strongest Shape: mise For Tools, Ota For Acceptance

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.

Why This Matters For AI Agents

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.

Safe Environment Resolution Is Not Safe Execution

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.

How Ota Uses mise Evidence

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.

What This Looks Like In Practice

In a serious repo, the flow should feel boring:

ota doctor
ota tasks --use
ota up
ota 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 Clear Boundary

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.

When To Use Ota With mise

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.

Originally posted here: https://ota.run/blog/mise-resolves-tools-ota-governs-repository-acceptance

AI Agent Contracts Cannot Define Repository Acceptance

Bobai Kato — Sat, 25 Jul 2026 17:00:13 +0000

The Missing Half Of An Agent Contract

Most agent contracts answer an important question:

How should an agent change this repository?

They can protect sensitive directories, ask for smaller diffs, require a handoff, and tell an
agent when to stop and ask a human.

But a repository has a second question:

What must happen before this change counts as accepted?

That is not a writing-style question. It is an execution question: the setup path, the selected
services, the canonical verification lane, the execution mode, and the evidence a green result
actually carries.

An agent contract can guide edits. It cannot, by itself, define repository acceptance.

The Failure Mode

Consider an agent contract that says:

- Do not edit generated clients.
- Keep migrations small and explain them.
- Run tests before handoff.
- Ask before changing infrastructure.

Those are good contribution rules. They do not answer whether “run tests” means pnpm test, a
service-backed workflow, a container lane, or CI's actual verification closure. They do not say
whether dependencies are materialized, a database is ready, or a zero exit proves more than one
narrow check.

The dangerous outcome is a plausible handoff: the agent followed the instructions, ran a command,
and reported success. Nobody can tell whether it used the accepted path.

Ota Defines The Acceptance Path

Ota gives that operational truth a machine-readable home in ota.yaml:

tasks:
  setup:
    prepare:
      kind: dependency_hydration
      medium: package_dependencies
      source:
        kind: node_package_manager
        manager: pnpm
        mode: install
        frozen_lockfile: true

  verify:
    command:
      exe: pnpm
      args: [test]
    depends_on: [setup]
    safe_for_agent: true

agent:
  safe_tasks: [verify]
  verify_after_changes: [verify]

That is not an instruction to “remember to install dependencies.” It declares one accepted setup
and verification path that Ota can inspect, dry-run, execute, and record.

An agent can discover the declared surface, then execute it through the enforced lane:

ota doctor
ota tasks --safe --use
ota run verify --agent

The important distinction is that --agent asks Ota to resolve the selected task closure before
anything starts. If the requested task, dependency, or workflow path is outside the effective safe
surface, Ota refuses it and emits a structured result rather than relying on the agent to obey
prose.

The Boundary Is Real, But Scoped

Ota does not claim to sandbox every process an agent could launch. An agent with unrestricted shell
access can still bypass Ota by not using it.

The enforcement point is the Ota runner boundary: ota run <task> --agent and, for an
agent-admitted workflow, ota up --workflow <name> --agent. That gives developers and CI fast,
inspectable execution control now. A stronger organization-wide boundary comes when CI gates and
agent harnesses consume the same contract truth.

That honesty matters. A declared safe task is useful; a runner that refuses an unsafe closure is
stronger; an org-level harness or merge gate that requires the same result is stronger again.

Two Contracts, Two Jobs

Use an agent contract for contribution behavior:

editing and review rules
sensitive files and escalation
coding conventions and handoff expectations

Use Ota for repository acceptance:

dependency hydration and setup order
services, readiness, tasks, and workflows
native or container execution selection
agent-admitted execution paths
receipts, proof boundaries, and CI drift checks

Neither replaces the other. A repository with only agent guidance still asks the agent to infer
how the software runs. A repository with only Ota can still need human collaboration rules.

The durable model is simple: let the agent contract govern edits, and let Ota govern whether the
repository was prepared, verified, and evidenced through an accepted path.

Originally posted here: https://ota.run/blog/ai-agent-contracts-cannot-define-repository-acceptance

Testing the Proof System: Negative Controls and Dependency Evidence in Ota

Bobai Kato — Fri, 24 Jul 2026 14:37:52 +0000

A green call does not prove the dependency mattered

A service can be reachable without being exercised. An application can call a dependency without
proving the dependency shaped the tested obligation. A control can fail for an unrelated reason.

Flatten those outcomes into one green or red status and a proof system will eventually claim more
than it observed.

Ota 1.6.24 separates three levels:

reachable: the selected path reached a declared dependency boundary;
exercised: a finite observer recovered evidence produced through that dependency in the current proof transaction;
fault_tested: a separate control proved the same obligation failed for the declared missing-effect reason.

Each level answers a different question. None may be inferred from a command label or exit code.

The contract names the seam and the control

The runtime workflow declares the positive observation and the negative control independently:

workflows:
  app-proof:
    run:
      task: app
    readiness:
      surfaces: [app]
    proof:
      seam_observations:
        - id: postgres-marker
          dependency: postgres
          producer_task: proof:marker-produce
          task: proof:marker-observe
          marker_env: OTA_PROOF_DEPENDENCY_MARKER
      negative_controls:
        - id: postgres-unavailable
          dependency: postgres
          obligation: postgres-marker
          task: proof:postgres-unavailable
          intervention:
            kind: dependency_endpoint_override
          expected_failure: dependency_unavailable

Run the ordinary proof first. Select the control explicitly when the causal claim is required:

ota proof runtime --workflow app-proof --json --archive
ota proof runtime --workflow app-proof \
  --negative-control postgres-unavailable \
  --json --archive

Ota does not silently inject failure into every runtime check. Negative controls are separate proof
runs because they answer a stronger question and may mutate or disrupt the selected dependency.

`exercised` requires current-transaction evidence

The do-nothing observer is the first adversary.

If an observer can exit zero without reading evidence from the dependency, it has not proved the
seam was exercised. If it can reuse a value from yesterday's run, it has not proved this execution
used the seam.

For marker-bound observations, Ota creates an opaque marker and gives it only to the declared
producer. The observer receives the transaction context but not the marker. It must recover the
marker through the dependency and write the runner-owned attestation.

Ota verifies the observation identity, transaction identity, marker, and evidence digest before it
emits level: exercised. The transient marker is then removed. A clean observer exit, guessed
value, stale record, or caller-side trace cannot earn that level.

`fault_tested` requires the right red

The negative control has its own adversary: an unrelated failure.

A broken setup step, timeout, DNS failure, crash, or generic non-zero exit may turn the lane red. It
does not prove that removing PostgreSQL invalidated the same obligation that passed in the green
run.

Ota promotes the seam only when the canonical control record is:

bound to the same proof transaction and obligation;
run under the declared intervention;
classified as expected_missing_effect;
backed by a matching failure-attestation digest;
emitted with status: validated and outcome: expected_obligation_failed.

The dependency record carries only a derived projection of that canonical control. This prevents a
nested object from becoming a second, weaker authority.

{
  "dependency_evidence": [
    {
      "dependency_id": "service:postgres",
      "proof_obligation_id": "postgres-marker",
      "level": "fault_tested",
      "observation": {
        "origin": "round_trip_effect",
        "evidence_class": "attested"
      },
      "negative_control": {
        "status": "validated",
        "same_obligation": true,
        "failure_mode": "expected_missing_effect",
        "failure_attestation_digest": "sha256:..."
      }
    }
  ]
}

If Ota cannot validate that chain, the control remains invalid or unrun. An unclassified red
never upgrades evidence to fault_tested.

Strong seam proof is still bounded proof

A PostgreSQL marker round trip can establish that the selected obligation depended on PostgreSQL.
It cannot establish that PostgreSQL shaped every response, migration, query result, or user-visible
output in the repository.

Ota therefore retains the obligation-scoped boundary:

{
  "proof_verdict": "passed_with_unproven_boundaries",
  "not_proved": [
    {
      "kind": "dependency_output_shaping_not_proved",
      "proof_obligation_id": "postgres-marker"
    }
  ]
}

This is not a caveat hidden in prose. It travels with the artifact so CI and agents cannot honestly
turn one controlled seam into repo-global proof.

Athena API supplied the real pressure

athena-api forced this model through a Rails and
PostgreSQL runtime rather than a synthetic fixture. Its released Ota 1.6.24 matrix
run #29572074325 proved native and
container lanes while keeping Windows intentionally static. The later PostgreSQL pressure retained
dependency_output_shaping_not_proved even after the marker-bound seam and matching control became
stronger.

Read the full engineering note: Pressure-testing Ota on athena-api.

The design rule

Proof must be able to fail its own strongest claim.

Reachability proves contact. Transaction-bound observation proves the selected seam was exercised.
A validated same-obligation control proves the dependency was necessary for that obligation. Ota
keeps those claims separate because automation becomes dangerous when evidence levels collapse into
one optimistic green.

References

Originally published here: https://ota.run/blog/testing-the-proof-system-negative-controls-and-dependency-evidence

Ota 1.6.24: Replayable Proof for Real Repository Execution

Bobai Kato — Wed, 22 Jul 2026 20:49:31 +0000

A rerun is not automatically a replay

Running the same command twice does not prove that the same execution happened twice.

The contract may have changed. A lockfile may have moved. CI may have selected another backend. A
live API may have returned different state. Even a green result can describe a different operational
world.

Ota 1.6.24 takes a strict position: replay is a comparison against an archived execution witness,
not a synonym for rerun.

The selected workflow, backend, provider, lifecycle, contract snapshot, and captured inputs must be
comparable before Ota will call the result verified.

The command starts from an archived witness

Archive the original execution receipt, then select it as the replay baseline:

ota up --workflow verify --json
ota receipt --json --archive
ota up --workflow verify --replay-baseline latest --json

The replay result is explicit:

replay_verified: the selected scope reconciled with the baseline;
replay_failed: comparable execution produced material drift or failure;
replay_unavailable: Ota could not make an honest comparison.

replay_unavailable is not a weak error message. It is a trust boundary. A baseline from another
workflow, backend, provider, remote target, or lifecycle must not be promoted to last-known-good
evidence for the selected lane.

Declare inputs separately from observed behavior

Ota contracts can name the repo-owned artifacts that define a replay lane:

tasks:
  gate:
    replay_inputs:
      - id: recorded_sql
        kind: static_file
        path: data/fixture.jsonl
      - id: frozen_store
        kind: static_file
        path: data/store.db
      - id: runtime-presentation
        kind: presentation_profile
        path: replay/presentation-profile.yaml
      - id: equivalence
        kind: comparator_profile
        path: replay/comparator-profile.yaml
    witnessed_observations:
      query_traces:
        - id: recorded_queries
          path: evidence/query-trace.jsonl

These are not interchangeable fields.

replay_inputs[] records what the selected lane consumed before execution.
witnessed_observations.query_traces[] records behavior observed from an execution.

If observed SQL is silently treated as a current-run input, the replay can confirm itself. Ota
keeps the evidence linked but separate so a later comparison can distinguish changed inputs from
changed behavior.

In 1.6.24, Ota captures the observed SHA-256 identity of each declared replay input. That tells a
later replay exactly which bytes the original lane used and exposes identity drift between receipts.
It does not let the 1.6.24 contract declare an expected digest that blocks the very first execution.
That distinction matters: observed identity is execution evidence, not a maintainer-authored pin.

What a verified replay actually says

A verified replay says that Ota reconciled the selected execution scope and the named evidence it
knows how to compare. It does not automatically mean the lane was hermetic.

Matching static inputs remain scoped evidence. Undeclared environment state, live services, remote
APIs, clocks, randomness, and other ambient inputs can still matter. Ota therefore reports replay
posture and hermeticity separately instead of turning one matching hash into a repo-wide claim.

The machine consumer should inspect:

{
  "replay": {
    "posture": "replay_verified",
    "hermeticity": "partly_ambient",
    "baseline": {
      "last_known_good": "replay_verified"
    }
  }
}

The exact payload contains more scope and comparison detail. The important point is that
replay_verified and partly_ambient can both be true. One describes the comparison Ota completed;
the other prevents that result from claiming the rest of the world was frozen.

Bedrock made the distinction concrete

Bedrock, created by Vinicius Pereira, is a natural-language
to SQL stability harness. Its deterministic lane consumes a recorded SQL fixture, a frozen SQLite
store, and a defended baseline. The SQL records also contain useful witnessed query behavior.

That repo forced the product question: should historical model output become a replay input, or
remain witnessed evidence?

Ota keeps both roles explicit. The released-version pressure matrix passed native Ubuntu, macOS,
Windows, and the container replay lane in
run #29572073749. That matrix proves
the bounded offline replay path. It does not prove Bedrock's live model-recording lane or a live
database.

Read the full engineering note: Pressure-testing Ota on Bedrock: query identity as replay
evidence.

The operational rule

Use replay when you need to answer:

Did this selected execution still hold against the archived contract, scope, and named inputs?

Do not use it to imply:

Nothing outside this receipt could have affected the result.

That distinction is why Ota archives execution evidence, preserves semantic contract identity, and
publishes unavailable or partly ambient outcomes instead of manufacturing certainty.

References

Originally posted here: https://ota.run/blog/ota-v1-6-24-replayable-proof-for-real-repository-execution

Why ok: true Is Not Enough for AI Agent Execution

Bobai Kato — Tue, 21 Jul 2026 12:26:17 +0000

A successful command is not broad authorization

ok: true answers one useful question:

Did the selected Ota execution complete successfully?

It does not answer:

Did this lane prove every dependency mattered?
Did it cover every workflow in the repository?
Did it exercise a live external integration?
Is an agent now authorized to publish, deploy, or migrate?

Humans often carry those distinctions in context. Automated systems usually do not. If the only
machine signal is a Boolean, a narrow green result will eventually be consumed as a broader claim.

Ota 1.6.24 keeps execution success, proof breadth, and remaining uncertainty separate.

Read the proof carrier, not one field

Run the declared workflow through Ota's proof boundary:

ota proof runtime --workflow app --json --archive

A successful but bounded result can look like this:

{
  "ok": true,
  "phase": "readiness",
  "proof_verdict": "passed_with_unproven_boundaries",
  "proof_scope": {
    "kind": "runtime_path",
    "proof_class": "slice_proof",
    "workflow": "app",
    "task": "serve"
  },
  "not_proved": [
    {
      "kind": "broader_repo_completion_not_proved",
      "relative_to": "runtime_path"
    }
  ]
}

These fields are intentionally different:

ok reports selected execution success;
phase says where that result was established;
proof_verdict reports the derived proof posture;
proof_scope names the lane the artifact can speak for;
not_proved[] carries material boundaries that remain outside the claim.

An agent that reads only ok is not consuming the Ota proof contract correctly.

Why a qualified pass is not a failure

Suppose Ota starts an API and verifies its declared HTTP listener. That is useful runtime evidence.
It may prove the selected service became ready on the declared path.

It does not automatically prove:

a neighbouring release workflow;
a live payment or model API;
production data behavior;
a database's complete output-shaping role;
repository-wide completion.

Returning ok: false would discard the real success. Returning an unqualified pass would overstate
it. passed_with_unproven_boundaries preserves both truths.

The boundary is part of the result, not an apology after it.

What an agent should do next

An agent or CI integration should evaluate the result in this order:

Require ok: true for the selected execution.
Confirm proof_scope matches the task or workflow it intended to prove.
Read proof_verdict; do not translate every green execution into an unqualified proof pass.
Inspect not_proved[] for a boundary relevant to the next action.
Apply policy before crossing into a heavier lane such as deployment, migration, publishing, or live external effects.

That last step matters. Proof and authorization are related, but they are not the same object. A
runtime receipt can establish what happened. It should not silently grant permission for a more
dangerous task.

The verdict is derived, not narrated

Ota derives the terminal proof verdict at the decision boundary. A materially bounded proof cannot
serialize as an unqualified pass merely because an output formatter prefers a simpler status.

The same principle applies to dependency evidence. Caller-side activity, dependency readiness,
transaction-bound exercise, and negative-control causality retain different evidence levels. A
consumer does not get to upgrade them by ignoring the accompanying boundary.

That is the practical difference between execution logs and governance evidence: the artifact
carries enough structure for another system to refuse an over-broad interpretation.

What this does not solve

Ota cannot stop a general-purpose agent from bypassing Ota and invoking an arbitrary shell directly.
The repository contract is the specification; enforcement must also exist at the callable runner,
sandbox, CI, or merge-gate chokepoint.

Within Ota, agent mode restricts execution to the declared safe closure. Outside Ota, a harness must
expose Ota's governed lanes instead of handing the agent an unrestricted shell and hoping it behaves.

That boundary is important because ok: true is evidence, not a universal capability token.

The operational rule

For humans, agents, and CI:

Treat ok as execution status. Treat proof_verdict, proof_scope, and not_proved as the
authority on what that success established.

This makes a green result more useful, not less. It can safely drive automation because its limits
are available to the same machine that reads its success.

References

Originally posted here: https://ota.run/blog/why-ok-true-is-not-enough-for-ai-agent-execution

Pressure-testing Ota on Open WebUI: proof cleanup ownership, bootstrap truth, and native vs Compose runtime boundaries

Bobai Kato — Mon, 20 Jul 2026 18:43:02 +0000

Overview

Open WebUI exposed a real Ota lifecycle boundary.

This was not mainly a parsing or contract-shape repo. The contract was already strong enough to model:

source-checkout verification
packaged native runtime through uv run open-webui serve
frontend development runtime
default Docker Compose runtime

What the repo exposed was operational truth after proof:

a successful native proof still left a host workload alive
the first cleanup fix then widened too far and treated a Compose-owned runtime as the same class of host workload

That made Open WebUI a valuable pressure repo.

It forced Ota to get more precise about cleanup ownership instead of treating all successful runtime proof as one generic teardown problem.

The current pressure contract pins released Ota v1.6.24. Its latest green matrix run proves
the release surface at the exact contract and workflow revision linked below.

What Open WebUI exposed in Ota

This repo exposed four meaningful weaknesses.

1. proof success was weaker than it looked

The first issue was not that runtime proof failed.

It was that runtime proof succeeded and still left the native workload alive afterward.

In this repo, the packaged native workflow launches:

serve:native:
  launch:
    kind: command
    exe: uv
    args:
      - run
      - open-webui
      - serve
      - --host
      - 0.0.0.0
      - --port
      - "8080"

Ota proved that workflow, but the launched process tree was still alive after proof completed.

In GitHub Actions, that surfaced through setup-uv post-job cleanup, which blocked while the uv cache was still in use.

That was an Ota gap.

If proof succeeds but leaves behind repo-owned runtime state that later breaks CI cleanup, the proof surface is still incomplete.

2. native service cleanup widened past its real ownership boundary

The first core fix made Ota clean selected native service workloads after successful proof.

That was directionally correct, but Open WebUI immediately exposed the next boundary.

The Docker workflow uses a native task shape to launch Compose:

compose:up:
  launch:
    kind: command
    exe: docker
    args:
      - compose
      - up

That is a native command surface, but it is not the same kind of ownership as a host-managed runtime like uv run open-webui serve.

The first cleanup widening treated it as if Ota should reclaim the resulting listener directly like a host workload. That was too broad.

This repo made the distinction unavoidable:

host-owned native process workload
adapter-owned Compose runtime

Those are not the same cleanup family.

3. contract-owned CI bootstrap truth still matters

The workflow was already using ota-run/setup with contract mode, which is the right direction.

The contract bootstrap truth also had to stay aligned so the setup surface consumed the same install story the repo intended to publish.

That was not the original runtime bug, but it was still real governance drift.

A pressure repo should not say one thing in ota.yaml and effectively rely on another in CI.

4. mixed-runtime repos punish vague lifecycle ownership

Open WebUI combines several legitimate paths:

Python ownership through uv
Node ownership for frontend/build work
a packaged native runtime
a frontend-only runtime
a Docker Compose runtime

That combination matters because it punishes sloppy lifecycle assumptions quickly.

If Ota collapses all of that into “run a process and then stop something later,” the product boundary is still too weak.

What had to be fixed in Ota core

Open WebUI led to three real Ota fixes.

proof success-path cleanup for host-owned native workloads

Ota's proof teardown was tightened so it no longer stops only the outer ota up process.

It now also cleans selected native host service workloads that Ota actually owns for the chosen workflow.

That closes the gap where proof succeeded but left the packaged native runtime process tree alive after completion.

cleanup narrowing for Compose-owned runtime lanes

The first cleanup fix exposed a second Ota boundary, and that also had to be corrected.

Ota now skips that host-workload cleanup path for Compose-owned native service tasks such as docker compose up.

That matters because Compose runtime cleanup belongs to adapter-owned repo cleanup surfaces, not to host-process workload reclamation.

Without that distinction, Ota was overreaching past the lifecycle it actually owned.

proof cleanup now respects workflow-owned active execution scope

The last failure was subtler.

Docker proof itself was healthy, but teardown still failed because cleanup hit Ota's active execution registry and treated the proved compose:up service task as an unrelated blocker.

That was also an Ota gap.

The selected workflow had launched that runtime, proved it, and was now trying to clean up its own owned execution surface.

Ota now scopes workflow cleanup to the active execution ownership actually selected by the proof lane.

That keeps ordinary ota clean strict while allowing proof teardown to reclaim the workflow-owned execution it just created.

What changed in the contract

The final contract is stronger because it uses cleaner contract-owned truth in the same places where the product now got stronger.

The packaged native workflow stays explicit:

native:
  intent: local_development
  prepare:
    task: setup:env
  setup:
    task: setup
  run:
    task: serve:native
  readiness:
    surfaces:
      - native-web
  exposes:
    - surface: native-web

The Docker workflow stays separate instead of pretending it is the same runtime family:

docker:
  intent: packaged_runtime
  run:
    task: compose:up
  readiness:
    surfaces:
      - docker-web
  exposes:
    - surface: docker-web

That separation matters because the repo is not publishing one runtime claim.

It is publishing at least two different runtime claims with different lifecycle owners.

The contract bootstrap truth was also aligned so CI, humans, and agents all read the same Ota install intent from the repo contract.

The branch carries a 1.6.24 contract floor and structured bootstrap source, so CI, humans,
and agents use the same released Ota surface.

What the matrix now proves

The matrix does more than parse the contract, but each OS lane has an explicit scope.

All three lanes run ota validate, capture ota doctor, show task and workflow usage, inspect
execution topology, and dry-run the verify task and native workflow. They also dry-run the
finite backend-format and frontend-test tasks.

Ubuntu is the proof lane. It additionally runs the full frontend verification aggregate, the
finite backend-format and frontend-test tasks, then proves both the packaged native runtime and
the Docker Compose runtime. It also dry-runs the Docker workflow before executing its proof lane.

macOS and Windows are deliberately audit-only: they do not claim task execution, native runtime
proof, Compose proof, or Docker-workflow coverage. That is an explicit matrix boundary, not an
implicit gap hidden behind a green OS label.

The contract also models the frontend development runtime and the Playwright-enabled Compose
overlay. Neither is runtime-proved by this matrix. GPU and API-exposure overlays remain outside the
declared pressure scope. Those are modeled paths, not evidence that every Open WebUI runtime family
has been proved.

The green v1.6.24 matrix run
proved the tightened lifecycle boundaries on Ubuntu:

the native proof succeeded and cleaned up its host-owned runtime
the Docker Compose proof succeeded and tore down without tripping over its own active execution record
the contract-owned bootstrap, real verification tasks, and runtime-proof lanes agreed

Why this repo mattered

Open WebUI mattered because it is exactly the kind of repo that exposes whether a readiness system really understands lifecycle ownership.

It is not enough to support:

Python
Node
a native service task
a Compose runtime task

The product also has to know which cleanup responsibility belongs to which path.

This repo forced Ota to answer that cleanly:

proof success should not leave host-owned native workloads behind
Compose-owned runtimes should not be reclaimed as if they were the same class of host process

That is not cosmetic polish.

That is operational trust.

If Ota says a runtime path was proved, it should also leave the repo and CI environment in a truthful post-proof state.

Remaining boundary

The pressure pass also exposed a separate dependency-hydration limitation. Open WebUI's committed
uv.lock was stale, and a normal project uv sync can rewrite it before an unrelated verification
task inspects the working tree. The contract avoids that mutation for the upstream Ruff formatting
gate by using an isolated uvx tool bootstrap.

That is a truthful contract choice, not a complete Ota solution. Ota still needs a typed uv
frozen-lockfile posture for dependency hydration so a contract can require uv to refuse stale lock
state before execution rather than relying on task-specific avoidance. This remains an Ota product
gap; it was not hidden to make the matrix green.

Pressure-testing Ota on Kylrix: Next.js runtime projection and dual-mode contributor proof

Bobai Kato — Sat, 18 Jul 2026 15:36:41 +0000

Overview

Kylrix is a large Next.js workspace with two materially different local stories:

a contributor path backed by SQLite
a self-hosted Compose topology with Appwrite and supporting services

That distinction made it a useful Ota pressure target. A contract that treated both paths as one
generic “run the app” command would either hide the contributor truth or overclaim the self-hosted
one.

The useful outcome was not more shell automation. It was a narrower contributor contract and an
honest production-topology boundary.

The contributor path needed one source of listener truth

The contributor runtime is a Next.js service on port 3005. Before this pressure pass, a contract
author had to duplicate that bind truth in two places:

Next.js launch flags
the listener used for readiness and projected URLs

That duplication drifts easily. The stronger Ota shape is to keep the listener canonical and project
known server flags from it:

surfaces:
  contributor:web:
    kind: http
    port: 3005
    path: /

tasks:
  dev:
    launch:
      kind: command
      exe: pnpm
      args: [exec, next, dev, --turbopack]
      runtime_projection:
        listener: contributor:web
        adapter: nextjs

Ota derives the supported Next.js bind flags from the declared listener. Readiness and the rendered
external URL now describe the same runtime truth as the process command.

Native and container verification should not fight over state

Kylrix also needed a real dual-mode contributor path. The finite verification workflow runs the
same SQLite-backed test, lint, and build tasks on the host or in Ota's pinned Node container.

The important detail is attachment isolation:

execution:
  backends:
    container:
      image: node@sha256:a25c9934ff6382cd4f08b6bc26c82bf4ea69b1e6f8dabfb2ead457374127c365
  contexts:
    contributor:container:
      backend: container
      lifecycle: persistent
      attachments:
        isolated_paths: [node_modules, .next, .pnpm-store]

That makes the mode boundary operational instead of cosmetic. Container verification does not reuse
or corrupt native dependency and build state, while both lanes still execute the same declared
verification closure.

The self-hosted topology is governed, but bounded

Kylrix's full self-hosted stack is not a second contributor runtime. It uses Compose to build and
launch Kylrix, Appwrite, MariaDB, Redis, and Caddy. Ota owns the interpolation env file, Compose
file selection, image build, lifecycle, and readiness surface:

selfhost:up:
  launch:
    kind: compose
    action: up
    detach: true
  runtime:
    kind: service
    surfaces: [selfhost:web]

The contract does not claim that it has provisioned Appwrite credentials, completed the interactive
setup wizard, or proved application-level self-hosted behavior. Those steps require operator
credentials and are explicitly outside this workflow.

That boundary is as important as the Compose ownership. A green lifecycle proof should not be read
as a green product deployment.

What the matrix proves

The Kylrix Ota matrix proves the narrow contributor surface across native and container lanes:

contract validation, doctor, and task discovery
safe-agent task and workflow previews
real SQLite-backed test, lint, and build verification
native and container workflow receipts
native and container runtime proof for the Next.js contributor service

The self-hosted Compose workflow is modeled and dry-run covered, but not matrix-executed. It remains
deliberately outside the contributor proof claim because its Appwrite provisioning is operator-owned.

The released v1.6.24 pressure run is #29572073845.

Why this repo mattered

Kylrix reinforced two Ota design rules:

listener truth should be declared once and projected into supported launch adapters
native, container, and self-hosted paths must be governed as distinct execution realities, not flattened into one optimistic “works locally” claim

The result is a contract that helps contributors start with the finite SQLite path, gives Ota a
truthful container equivalent, and keeps the heavier Appwrite topology visible without pretending it
has been fully proved.

Pressure-testing Ota on lead-quorum: native Python truth, repo-local fulfillment, and runtime bind projection

Bobai Kato — Fri, 17 Jul 2026 12:51:03 +0000

Overview

lead-quorum was a strong pilot repo because it was small enough to reason about and real enough to fail honestly.

It has:

repo-local Python environment ownership
pinned dependency installation
env bootstrap from example truth
a deterministic local test surface
live external verification
a local web runtime
a distributed demo path
a Docker build lane

That is exactly the kind of repo where a contract can look clean while still hiding real setup and execution drift.

Why this repo mattered

The useful pressure here was not “can Ota run one Python command.”

The useful pressure was whether Ota could stay truthful when the repo itself owns:

the .venv
the dependency install lane
the local executable path
the runtime listener truth

If Ota probes or fulfills those in the wrong order, the contract is not trustworthy even if the repo itself is valid.

That is what made lead-quorum valuable.

What the contract now models

The final contract is explicit about the repo’s real setup split.

Setup is not one opaque shell step. It is three different ownership surfaces:

copy .env from .env.example only if missing
create the repo-local virtual environment
hydrate dependencies through typed uv requirements-file installation

That looks like this in the contract:

setup:
  aggregate:
    tasks:
      - setup:env
      - setup:venv
      - setup:deps

setup:env:
  action:
    kind: copy_if_missing
    from: .env.example
    to: .env

setup:venv:
  action:
    kind: ensure_virtualenv
    path: .venv
    python: "3.12"

setup:deps:
  prepare:
    kind: dependency_hydration
    medium: package_dependencies
    source:
      kind: uv
      cwd: .
      mode: pip_requirements
      requirements_file: requirements.txt

The contract also keeps verification and external-runtime claims separate:

verify for deterministic local validation
live for Gemini-backed end-to-end testing
app for the local web service
distributed for the A2A demo path

That matters because a working local scoring test and a live distributed runtime are not the same readiness claim.

What lead-quorum exposed in Ota

This repo exposed three real Ota gaps.

1. native repo-local fulfillment and probing were ordered incorrectly

Older Ota could still probe repo-local Python executables too early.

That is the wrong trust order for a repo that creates its own .venv as part of setup. If the repo-local interpreter path is declared as:

exe: .venv/bin/python

then Ota has to materialize the dependency/setup closure before treating that path as a fulfilled runtime command.

Otherwise a valid contract can fail just because Ota asked the question too early.

That is exactly what this repo exposed.

2. native Python candidate selection was too weak

lead-quorum also exposed a narrower but important gap in typed Python hydration.

When Ota selected a local Python candidate for setup and hydration, it could still choose the wrong host interpreter path instead of the repo’s intended environment. In practice that meant a dependency like cryptography could start building against the wrong target environment instead of the repo-owned Python lane.

That is not a repo bug. That is a readiness engine selecting the wrong execution truth.

3. runtime bind truth was duplicated between launch args and runtime listeners

The local web service made a third weakness obvious.

Before widening, the contract still had to repeat bind truth in two places:

command-line runtime args such as --host and --port
the declared runtime listener surface

That duplication is fragile.

The stronger product shape is for the runtime listener to stay canonical and for Ota to project the supported bind flags for known servers. lead-quorum became the first real repo to pressure that widening cleanly.

What changed in Ota

lead-quorum drove platform fixes, not repo-local workarounds.

native repo-local fulfillment now respects setup materialization order

Ota now runs the selected setup closure before probing repo-local backend/runtime commands that depend on that materialized state.

That closes the gap where a repo could declare a truthful .venv/bin/python lane and still fail because Ota evaluated it before the repo-local environment existed.

Python candidate selection is now stricter and more truthful

Ota also now prefers version-matching Python candidates before falling back to weaker generic host candidates.

That makes typed Python hydration much less likely to drift onto the wrong interpreter family when the contract has already declared the intended Python lane.

runtime listener truth can now project bind args

This repo also helped widen Ota’s runtime-to-launch projection.

The local web service can now declare listener truth once and let Ota project supported bind args for a known adapter:

launch:
  kind: command
  exe: .venv/bin/uvicorn
  args:
    - web.app:app
  runtime_projection:
    listener: web
    adapter: uvicorn

That is a cleaner long-term shape than duplicating --host and --port in every Python service contract.

What the matrix now proves

The released v1.6.24 pressure matrix on Ota's fork is green across Ubuntu, macOS, Windows, and
a Dockerfile-owned Ubuntu container lane. Ubuntu and macOS execute the native deterministic and
runtime-proof lanes. Windows is intentionally audit-only in this matrix: it validates the contract
and discovers the task surface, but does not execute native tasks or runtime proof.

That matters because this repo’s truth is not only “tests pass on one machine.” The matrix proves:

ota validate
ota doctor
ota tasks --use
ota tasks --safe --use
task dry-run coverage for setup, deterministic test, live test, distributed demo, and Docker build lanes
workflow dry-run coverage for verify, app, live, and distributed
real setup
real deterministic test
real verify workflow proof
real local app workflow proof
real docker:build
real verify:container workflow against the repository Dockerfile image
contract-modeled and dry-run-covered live external and distributed workflows; their real matrix execution is conditional on GOOGLE_API_KEY and was skipped in this released-version run

That is a much stronger outcome than “the contract parses.”

Why this repo was a good pilot

lead-quorum did exactly what a first pilot should do.

It did not mainly expose repo noise. It exposed trust gaps in Ota itself:

setup before probe
correct interpreter selection
one canonical runtime bind truth

Those are real product boundaries.

That is why this repo was worth pressure-testing.

It also reinforced an important standard for future pilots:

a receipt or contract is only useful if it stays aligned with the actual decision and execution path, not just with what the repo intended in prose.

lead-quorum is created and maintained by Vinicius Pereira. The
Ota integration is proposed upstream; the forked matrix below is pre-merge pressure evidence, not
evidence from the canonical repository.

Pressure-testing Ota on Bedrock: query identity as replay evidence

Bobai Kato — Fri, 17 Jul 2026 12:48:25 +0000

Overview

Bedrock, created and maintained by Vinicius Pereira, is not a
normal application test repo.

It is a natural-language-to-SQL stability harness. It records generated SQL across repeated runs,
replays the committed fixture against a frozen SQLite store, compares the results with a defended
answer key, and blocks a candidate when reliability regresses.

That made it a strong pressure target for a more specific Ota question:

when a verification lane replays prior model behavior, how should Ota distinguish the inputs that
defined the replay from observations that explain what happened?

The answer cannot be one undifferentiated receipt field.

Why Bedrock mattered

Bedrock already had the useful artifacts in its repository:

data/fixture.jsonl: one recorded SQL query per question and run
data/store.db: the frozen SQLite state
data/baseline.json: the defended regression baseline
docs/scorecard.md: the rendered stability result

Those artifacts answer different questions.

A committed fixture, store, and baseline are replay inputs. They define the deterministic lane.
A repeated SQL trace is observed behavior. It can show that one question produced different query
shapes, but it is not an input Ota used to decide whether the current command could start. In this
repo, fixture.jsonl has a valid dual role: the deterministic replay consumes it and Ota parses it
as historical query evidence. That does not make it independent corroboration; it is one captured
artifact with two explicitly separate meanings.

That distinction became the pressure boundary.

What the contract models

The deterministic gate now declares the replay inputs explicitly:

gate:
  replay_inputs:
    - id: recorded_sql
      kind: static_file
      path: data/fixture.jsonl
    - id: frozen_store
      kind: static_file
      path: data/store.db
    - id: defended_baseline
      kind: static_file
      path: data/baseline.json

Those files are captured as declared, static replay truth.

The recorded query trace is declared separately:

```yaml | Witnessed Query Trace
gate:
witnessed_observations:
query_traces:
- id: recorded_sql
path: data/fixture.jsonl




That is the important Ota boundary.

- `replay_inputs[]` says what the deterministic gate consumed
- `witnessed_observations.query_traces[]` says what behavior the fixture contains

The second must not be promoted into the first. Otherwise a receipt can make historical model
output look like a pre-execution decision input, which weakens replay and evidence semantics.

## What the replay can honestly prove

Bedrock's offline path is deliberately narrow and useful:

- replay the committed SQL fixture
- execute it against the committed SQLite store
- compare the result set with the defended answer key
- compare the candidate score with the committed baseline

The contract makes that boundary visible:



```yaml | Offline Gate
gate:
  command:
    exe: python
    args:
      - -B
      - main.py
      - gate
  safe_for_agent: true

That proves the declared fixture, store, and baseline path. It does not prove that a live model
will generate the same SQL tomorrow, or that a live database has not changed.

Those claims remain separate in the contract's record:live lane:

record:live:
  effects:
    writes:
      - data/fixture.jsonl
    network: true
    network_kind: integration_test
    external_state:
      - anthropic_api

That lane reaches a live model and rewrites the recorded fixture. It is intentionally outside the
deterministic, agent-safe replay workflow.

What Bedrock exposed in Ota

Bedrock helped close an Ota evidence-model gap.

The initial temptation was to place per-record query identity under receipt
evaluated_inputs[]. That would have been wrong. A query trace is execution evidence, not a
current-run input.

Ota now keeps the split explicit:

declared static files stay under receipt evaluated_inputs[]
historical query identities and divergence summaries live under receipt witnessed_observations.query_traces[]

That gives later comparison and correlation a cleaner foundation:

inputs can remain unchanged
observed query behavior can still diverge

Neither fact is allowed to impersonate the other.

Bedrock also made one remaining boundary clear: its live recording path depends on a generic,
unpinned pip requirements lane. Ota does not yet own that as typed dependency hydration. The
contract names it as outside the deterministic proof instead of hiding it in setup shell.

What the matrix proves

The pressure matrix is intentionally offline and cross-platform:

ota validate
ota doctor
ota tasks --use
ota tasks --safe --use
agent-mode task dry-run for the stability gate
agent-mode workflow dry-run and preparation for verify
deterministic test execution
scorecard replay against the committed SQL fixture
baseline gate execution
archived receipt for the declared workflow
native coverage on Ubuntu, macOS, and Windows
the same replay workflow in Ota's pinned Python container context

This is not a claim that Bedrock's live model lane is hermetic. It is proof that the deterministic
replay lane is explicit about its inputs, output evidence, and boundary. The contract's file checks
assert artifact presence; Ota then captures SHA-256 source identities before execution and compares
them during replay. Those observed identities are not yet contract-declared expected digests, so
they attest what the lane used rather than pinning a separate immutable contract assertion.

The released v1.6.24 pressure matrix passed across native Ubuntu, macOS, Windows, and the
container replay lane on Ota's fork: run #29572073749.

Why this repo mattered

Bedrock clarified a product rule that applies beyond AI evaluation:

do not collapse observed behavior into declared execution inputs.

For this repository, a clean replay input can narrow or acquit the input class it actually names.
A divergent query trace can explain a flap. Neither artifact should overclaim the other role.

That is the right foundation for Ota's replay and receipt model: declared truth, execution truth,
and witnessed evidence remain linked, but separate.

Ota v1.6.24 Now Available: Runtime Proof, Replay Trust, and Typed Execution

Bobai Kato — Fri, 17 Jul 2026 12:44:38 +0000

Idea

v1.6.24 is an execution-evidence release.

The pressure behind it was a trust problem: a green command is useful, but it does not automatically prove that a declared dependency shaped the result, that the same material inputs can be replayed, or that a new run still represents the same operational truth.

Ota now draws those boundaries more sharply.

This release strengthens three connected questions:

did the selected runtime start and become ready?
did the proof actually exercise the declared dependency seam?
can a later run identify and replay the material inputs that shaped the original execution?

It also moves more setup and runtime behavior from shell convention into typed contract ownership, so the evidence has stronger declared truth beneath it.

Feature

v1.6.24 strengthens six connected parts of Ota's execution-governance model.

1. Runtime proof now distinguishes readiness, exercise, and causality

Runtime proof should not overstate what a green lane established.

v1.6.24 adds a stronger evidence ladder for declared dependency seams:

reachable means the selected path reached the dependency boundary
exercised requires transaction-bound evidence that the dependency participated in the current run
fault_tested requires a separate, same-obligation negative control that fails for the declared missing-effect reason

For marker-bound seams, Ota now creates an opaque transaction marker for the producer path and requires the observer to recover it from the dependency. A clean observer exit is not enough. The evidence has to match the current transaction and declared obligation.

Negative controls are strict too. An unrelated timeout, setup failure, crash, or generic non-zero exit cannot promote a seam to fault_tested. The control must be valid, bound to the same obligation, and classified as the expected obligation failure or missing effect.

The resulting proof can remain honestly qualified:

{
  "ok": true,
  "proof_verdict": "passed_with_unproven_boundaries",
  "dependency_evidence": [
    {
      "dependency_id": "service:postgres",
      "level": "fault_tested"
    }
  ],
  "not_proved": [
    {
      "kind": "dependency_output_shaping_not_proved"
    }
  ]
}

That distinction matters. Ota can prove that a declared PostgreSQL seam was causally exercised without pretending that PostgreSQL shaped every application output or that one narrow proof covered the whole repository.

2. Replay became execution-authored instead of reconstructed later

v1.6.24 adds first-class replay against archived execution truth:

ota up --workflow verify --replay-baseline latest --json

The replay surface reports one of three explicit outcomes:

replay_verified
replay_failed
replay_unavailable

Ota compares the selected workflow, backend, provider, remote target, and lifecycle against the archived baseline before treating it as comparable execution. It also classifies last-known-good evidence as verified, stale, or unavailable rather than silently treating any old green receipt as current proof.

Receipts now retain more of the material input identity needed for honest replay and diagnosis, including clean Git state, policy rulesets, environment-source identity, lockfiles, Node runtime identity, immutable Compose image identity, and dependency-hydration provenance where available.

The evidence model also keeps inputs separate from witnessed output. Declared replay inputs belong under replay_inputs; observed query behavior belongs under witnessed_observations.query_traces. That lets later comparisons distinguish changed inputs from changed runtime behavior instead of mixing both into one evidence list.

3. Dependency provenance became more explicit

Dependency hydration is not fully described by the package-manager verb alone.

This release widens typed hydration with source posture:

uv hydration can declare a default index, ordered additional indexes, and offline intent
.NET restore records runner-resolved NuGet feed identity when it can establish it
pnpm workspace hydration can declare a first-class filter

The trust rule remains conservative. If Ota cannot recover authoritative feed identity, the evidence narrows the diagnosis; it does not become a false hermeticity claim.

This gives receipts and replay a better answer to a common drift question: not only which package manager ran, but which declared or resolved dependency source shaped the run.

4. More execution truth moved into typed contract ownership

v1.6.24 removes more reasons to hide important repo behavior in opaque shell commands.

The release adds or widens:

action.kind: build_container_image for typed image file, context, tag, and provider ownership
generated artifact lineage through declared producers, outputs, inputs, and consumer requirements
task-level only_on platform constraints
launch.runtime_projection adapters for Uvicorn and Next.js
closure-aware execution modes for tasks and aggregates
aggregate dry-run governance derived from the actual dependency closure

Execution-mode admission is stricter as well. If a task does not advertise a requested mode, Ota refuses it instead of quietly selecting a different execution path.

Together, these changes strengthen the relationship between declared contract truth, the selected runtime path, and the evidence Ota emits afterward.

5. Task discovery and execution now agree more closely

Humans and agents need to see the same callable surface that the runner will enforce.

Task discovery now reports closure-aware run guidance, including:

human execution commands
agent execution commands
agent policy posture
machine-readable use.modes[]

Ota also tightened CI verification recovery and governance reconciliation so merge-gate output can explain the required verification lanes, the cited inputs behind the decision, and the decision basis instead of publishing a verdict with weak provenance.

The result is a cleaner path from discovery to execution: task listings, dry-run governance, runtime admission, and receipts are less likely to describe competing truths.

6. Runtime cleanup and interruption became safer

Some of the most important trust work in this release is deliberately unglamorous.

v1.6.24 improves runtime correctness around interruption and cleanup:

Ctrl+C is classified consistently as an interrupted execution with exit code 130
signal forwarding targets the selected child process tree without killing the invoking shell
interrupt state is scoped to the active execution epoch
native command services publish clearer readiness and endpoint truth
runtime proof starts and stops only proof-owned Compose dependencies
services that were already running before proof are preserved
container proof cleanup follows the selected effective execution mode

This matters because evidence is only trustworthy when the runner also owns failure, interruption, and cleanup boundaries correctly.

Pressure-tested on real repositories

The release was shaped through real repository pressure rather than fixtures alone.

Athena API forced marker-bound PostgreSQL seam proof, same-obligation controls, and typed production image ownership.
Bedrock pressured replay inputs, presentation and comparator profiles, and witnessed query traces.
Lead Quorum pressured uv source posture, runtime projection, and image-build ownership.
Kylrix pressured Next.js runtime projection and truthful native/container mode admission.

Those repos exposed the places where a structurally valid contract could still produce evidence that was too broad, too weakly attributed, or too dependent on shell convention. The fixes in v1.6.24 are the product response to that pressure.

Docs

Use the live references for the shipped surface:

Get started: Install Ota
Proof semantics: Runtime Proof Evidence
Execution evidence: Execution Receipt
Contract fields: Contract Reference
Command behavior: Command Reference
Machine output: JSON Output Reference
Governance architecture: Execution Governance Loop

The published schemas and public examples have also been updated for replay inputs, witnessed query traces, dependency evidence, seam observations, negative controls, and explicit not_proved boundaries.

Release

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

Upgrade and verify the selected repo path:

ota upgrade
ota --version
ota validate
ota doctor --json
ota tasks --safe --use
ota run <task> --dry-run --json
ota proof runtime --workflow <workflow> --json

v1.6.24 moves Ota further from “the command passed” toward the stronger question: what did this execution actually prove, which inputs shaped it, and what remains unproved?

Originally posted here: https://ota.run/blog/ota-v1-6-24-release-essay

Why AI Agent PRs Get Rejected And How Repo Contracts Help

Bobai Kato — Thu, 16 Jul 2026 21:18:31 +0000

Overview

A recent study of agent-generated pull-request fixes reported
that 46.41% of fixes proposed by Copilot, Devin, Cursor, and Claude were rejected.

That number matters, but the more useful question is why.

Some rejected PRs are simple model failures: the implementation is wrong, incomplete, or low
priority.

Ota addresses a separate, avoidable class of failure:

the agent ran the wrong verification path
the repo needed a service or env var that was never declared clearly
the change passed one local command but failed the real CI lane
the repo never made safe boundaries explicit
the agent stopped at "the code compiles" instead of "the repo's declared acceptance path passed"

That is not only an intelligence problem.

It is also a repo-governance problem.

No contract can make an incorrect or low-priority implementation worth merging. It can remove the
avoidable execution uncertainty around it: whether the repo was ready, the right lane ran, the
required services existed, and the completion claim matched the repo's declared acceptance path.

The Hidden Failure Is Usually Not The Diff

When an agent opens a PR, maintainers are not only reviewing the code diff.

They are also reviewing whether the agent understood the repo well enough to:

prepare the repo correctly
choose the right workflow
run the right checks
avoid unsafe changes
prove that the change is actually complete

That is where a lot of agent PRs fall apart.

The repo may have the truth, but the truth is scattered:

setup instructions in one README
real verification logic in CI
service assumptions in Docker files
extra post-change steps in shell scripts
path sensitivity in maintainer memory

An agent sees all of that and still has to decide:

What does done mean here?

If the repo does not answer that clearly, the PR is already risky before the code review starts.

Why Rejected Agent PRs Should Be Framed As Repo Governance

The useful framing is not:

"Agents need better prompts."

The useful framing is:

"Repos need better execution truth."

A maintainer should be able to declare:

how the repo becomes ready
which tasks are canonical
which workflow should be used after a change
which services and env are required
which tasks are safe for an agent
which paths are protected
which verification lane proves completion

Without that, every agent run is partly reconstruction work.

That reconstruction cost shows up later as:

CI failures
incomplete implementations
wrong runtime assumptions
reviewer fatigue
rejected PRs that were never fully grounded in repo truth

What Ota Changes

Ota is not trying to make agents magically smarter.

Ota gives the repo an execution contract so the agent has less to guess.

That contract can declare:

toolchains and runtime requirements
dependency hydration and setup
services and readiness
tasks and workflows
safe task boundaries
protected and writable paths
verification paths after changes

Instead of asking an agent to infer "probably run tests," a repo can say what the acceptance path
actually is.

For example:

agent:
  entrypoint: verify
  default_task: verify
  safe_tasks:
    - lint
    - test
  verify_after_changes:
    - verify
  protected_paths:
    - .github/workflows
    - production/**
    - secrets/**

And:

workflows:
  default: app
  app:
    intent: local_development
    prepare:
      task: setup

And:

tasks:
  verify:
    aggregate:
      tasks:
        - lint
        - test

Now the repo is saying something operationally useful:

start from this task
these are the safe tasks
this is the post-change verification lane
these paths are not for autonomous editing

That does not guarantee the agent will write the right code.

But it does remove a large class of avoidable failure.

How This Reduces Rejected PRs

There are four concrete ways this helps.

1. The agent runs the repo's real verification path

The agent no longer has to guess whether pytest, npm test, go test, or one CI script is the
real acceptance lane.

The repo can declare the exact task or workflow that must pass.

That reduces PRs that fail because the agent validated the wrong thing.

2. The agent prepares the repo correctly before editing

A lot of wasted agent work starts before the code change:

dependencies were not hydrated correctly
a service was missing
env files were never prepared
the runtime was not actually ready

If readiness and setup are declared structurally, the agent has a better chance of operating on a
real working repo instead of a half-prepared one.

3. The agent stays inside explicit safety boundaries

Some changes should not happen autonomously.

That may include:

workflow files
deployment config
secrets surfaces
destructive tasks
data-reset lanes

If those boundaries are explicit, the agent can stop, escalate, or stay on the safe path instead
of wandering into a high-review or high-risk change set. A consuming runner or CI gate can then
enforce the same declared boundary where that enforcement is configured.

4. Reviewers get evidence, not reconstruction work

A reviewer should not have to reverse-engineer:

what the agent should have run
whether it used the right workflow
whether a failure came from code, setup drift, or missing services
whether the repo even exposed the right operational truth

Ota moves that toward explicit evidence:

contract validation
doctor output
task dry-run
workflow proof
execution receipts

That makes rejected PRs easier to understand and good PRs easier to trust.

The Real Wedge Is Not "AI Coding"

The real wedge is execution governance.

If AI agents are going to work across unfamiliar repos, those repos need a way to say:

what is required
what is safe
what should run
what success looks like

That is why this matters beyond agents.

The same contract truth helps:

new contributors
CI systems
remote sandboxes
internal automation
future maintainers

The agent use case just makes the pain impossible to ignore.

What A Better Agent PR Flow Looks Like

A stronger flow is simple:

ota doctor
ota validate .
ota tasks --use
ota up --workflow app
ota run verify

That is materially different from:

"Look around, pick some commands, and hope the repo agrees."

The first flow is governed.
The second is guesswork.

Final Point

If nearly half of agent-generated PR fixes are being rejected, the response should not only be to
measure model quality harder.

We should also ask whether repos are giving agents a trustworthy path to completion.

The stronger question is not:

"Can the agent write code?"

It is:

"Can the repo tell the agent what a correct, safe, complete change looks like?"

That is the layer Ota is built for.

Get Started With Ota

Install Ota:

curl -fsSL https://dist.ota.run/install.sh | sh

Windows:

irm https://dist.ota.run/install.ps1 | iex

Then start with:

ota doctor
ota init

Originally posted here: https://ota.run/blog/why-ai-agent-prs-get-rejected-and-how-repo-contracts-help-4h2m

AI Coding's Real Bottleneck Is Repository Execution Trust

Bobai Kato — Mon, 13 Jul 2026 20:20:02 +0000

Overview

For a while, the central question in AI coding felt obvious:

Can the model generate good code?

That is still important, but it is no longer the main bottleneck in many real workflows.

The bigger problem now is repository execution trust.

Can the agent trust the repository enough to act correctly?

Can the repository tell the agent what setup is required, what task is canonical, what workflow proves readiness, and what evidence should count when something fails?

If the answer is no, better generation alone does not solve the problem.

It just produces higher-quality guesses inside an ungoverned environment.

Generation Improved Faster Than Execution Trust

Agents are already reasonably good at many code-local tasks:

writing small features
fixing obvious bugs
updating tests
refactoring narrow modules
tracing stack-level failures

That is not where most teams feel the sharpest friction anymore.

The friction appears when the agent has to move from code generation into repository operation.

That is where questions like these start to matter:

what has to run first
which package manager is authoritative
which services need to be running
what environment values are real requirements
which task is safe to execute
which verification path is canonical
whether a failure came from code, setup, or contract drift

Those are not model-completion problems.

They are execution-trust problems.

The Hard Part Is No Longer Writing The Patch

In many repos, the hard part is no longer producing a plausible patch.

The hard part is knowing whether the patch was exercised against the right path.

An agent can write a technically good change and still fail the actual job if it:

ran the wrong test command
skipped setup that CI assumes
missed a required service
followed a stale README path
treated an environment problem as a code defect
passed a narrow local check while the real repo gate stayed unproven

When that happens, the failure is often blamed on the agent.

But the repo is usually part of the problem too.

The repo did not expose enough trustworthy execution truth for the agent to operate with confidence.

What Executable Trust Actually Means

Executable trust is the condition where a repository can answer operational questions clearly enough that humans, CI, and agents can take the same path and understand the result.

That means the repo can declare:

what it needs
how it becomes ready
what is safe to run
what should verify a change
what runtime path is primary
what evidence should be preserved
what failures mean

Without that, an agent is still reconstructing the repo from incomplete signals:

README prose
shell scripts
CI workflow fragments
package manifests
.env.example
local conventions
tribal knowledge

That reconstruction can look intelligent while still being fragile.

Bigger Context Windows Do Not Eliminate This

A larger context window helps an agent read more of the repo before deciding.

That is useful.

But it does not create authority.

If five different files imply five different setup paths, more context just lets the agent inspect more disagreement.

If CI, local scripts, and contributor docs have drifted apart, a larger window helps the agent see the drift. It does not tell the agent which path the repo actually considers correct.

This is why the bottleneck has shifted.

The question is no longer only:

Can the agent generate a good answer?

It is increasingly:

Can the repository expose a trustworthy execution path?

What Repository Execution Trust Looks Like In Practice

A repository with executable trust should make some things explicit instead of implied.

For example:

tasks:
  setup:
    prepare:
      kind: dependency_hydration
      medium: package_dependencies
      source:
        kind: node_package_manager
        manager: pnpm
        mode: install

  verify:
    aggregate:
      tasks:
        - lint
        - typecheck
        - test

workflows:
  default: verify
  verify:
    setup:
      task: setup
    run:
      task: verify

That does not just give the agent commands.

It gives the repo a declared setup path, a declared verification path, and a shared operational story for humans and automation.

And it gives Ota an executable path instead of a prose hint:

ota up --workflow verify
ota run verify
ota receipt --json --archive

That means:

ota up --workflow verify can take the declared setup path instead of guessing what must run first
ota run verify can execute the canonical verification lane instead of picking between README, CI, or shell drift
ota receipt --json --archive can preserve the execution and readiness evidence instead of leaving the result as unstructured terminal output

Now compare that with a weaker setup where the agent has to guess between:

npm test from the README
pnpm lint && pnpm test:ci from CI
a make check target that may or may not still be current
a hidden service dependency no one wrote down

That second repo does not have a generation problem first.

It has a trust problem.

Failures Need To Become Evidence

Once agents begin operating repos instead of just suggesting edits, output quality is no longer enough.

The system also needs evidence.

When setup fails, the useful artifact is not only stderr.

It is something closer to:

what contract or workflow was selected
what task actually ran
what readiness was expected
what service or env assumption was missing
whether the failure came from declared truth, hidden dependency, or drift

That is the level where repositories become governable instead of just runnable.

It is also the level where agents become more trustworthy, because their actions are bounded by declared paths and their failures are easier to interpret honestly.

This Is Why Ota Repo Contracts Matter

At Ota, this is the problem space we care about.

The value of a repo contract is not that it gives an agent one more config file to read.

The value is that it makes execution truth explicit and runnable:

setup
tasks
workflows
services
readiness
boundaries
receipts

That gives the agent something stronger than raw context.

It gives it an operating contract.

The Next Phase Of AI Coding

The next phase of AI coding is not only about larger models, longer context windows, or better patch generation.

It is about whether repositories can support trustworthy operation.

That means moving from:

"the agent can write code"

to:

"the agent can act inside a repo with clear execution truth"

Those are different maturity levels.

The first is impressive.

The second is what teams actually need if they want agents to work reliably beyond small edits.

Bottom Line

AI coding's bottleneck is no longer only generation quality.

In many real repos, the larger constraint is whether the repository can expose a trustworthy path from change to verified execution.

Until that trust layer exists, better generation will still run into the same wall:

good patches inside unclear repos.

That is why the next real improvement is not just more model capability.

It is a repo that can declare, execute, and preserve the same trustworthy path for developers, CI, and AI agents.

That is the operational layer Ota is building.

Originally posted here: https://ota.run/blog/ai-codings-real-bottleneck-is-repository-execution-trust

DEV Community: Bobai Kato

mise Resolves Tools. Ota Governs Repository Acceptance.

Overview

What mise Is Good At

Where Environment Resolution Stops

Repository Acceptance Is A Different Contract

The Strongest Shape: mise For Tools, Ota For Acceptance

Why This Matters For AI Agents

Safe Environment Resolution Is Not Safe Execution

How Ota Uses mise Evidence

What This Looks Like In Practice

The Clear Boundary

When To Use Ota With mise

AI Agent Contracts Cannot Define Repository Acceptance

The Missing Half Of An Agent Contract

The Failure Mode

Ota Defines The Acceptance Path

The Boundary Is Real, But Scoped

Two Contracts, Two Jobs

Testing the Proof System: Negative Controls and Dependency Evidence in Ota

A green call does not prove the dependency mattered

The contract names the seam and the control

exercised requires current-transaction evidence

fault_tested requires the right red

Strong seam proof is still bounded proof

Athena API supplied the real pressure

The design rule

References

Ota 1.6.24: Replayable Proof for Real Repository Execution

A rerun is not automatically a replay

The command starts from an archived witness

Declare inputs separately from observed behavior

What a verified replay actually says

Bedrock made the distinction concrete

The operational rule

References

Why ok: true Is Not Enough for AI Agent Execution

A successful command is not broad authorization

Read the proof carrier, not one field

Why a qualified pass is not a failure

What an agent should do next

The verdict is derived, not narrated

What this does not solve

The operational rule

References

Pressure-testing Ota on Open WebUI: proof cleanup ownership, bootstrap truth, and native vs Compose runtime boundaries

Overview

What Open WebUI exposed in Ota

1. proof success was weaker than it looked

2. native service cleanup widened past its real ownership boundary

3. contract-owned CI bootstrap truth still matters

4. mixed-runtime repos punish vague lifecycle ownership

What had to be fixed in Ota core

proof success-path cleanup for host-owned native workloads

cleanup narrowing for Compose-owned runtime lanes

proof cleanup now respects workflow-owned active execution scope

What changed in the contract

What the matrix now proves

Why this repo mattered

Remaining boundary

Links

Pressure-testing Ota on Kylrix: Next.js runtime projection and dual-mode contributor proof

Overview

The contributor path needed one source of listener truth

Native and container verification should not fight over state

The self-hosted topology is governed, but bounded

What the matrix proves

Why this repo mattered

Links

Pressure-testing Ota on lead-quorum: native Python truth, repo-local fulfillment, and runtime bind projection

Overview

Why this repo mattered

What the contract now models

What lead-quorum exposed in Ota

1. native repo-local fulfillment and probing were ordered incorrectly

2. native Python candidate selection was too weak

3. runtime bind truth was duplicated between launch args and runtime listeners

What changed in Ota

native repo-local fulfillment now respects setup materialization order

Python candidate selection is now stricter and more truthful

`exercised` requires current-transaction evidence

`fault_tested` requires the right red