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

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.

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.

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.

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.

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.

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.”

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.

• Contract: lead-quorum ota.yaml
• Matrix workflow: test-ota-contract-matrix.yml
• Released-version pressure matrix: #29572074145