Bobai Kato for Ota

Posted on Jul 17 • Originally published at ota.run

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

#pressuretesting #python #uv #reporeadiness

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 pressure branch matrix is green across Ubuntu, macOS, Windows, and a Dockerfile-owned Ubuntu
container lane.

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.

DEV Community