Overview
lead-quorum was a strong pilot repo because it was small enough to reason about and real enough to fail honestly.
It has:
re...
For further actions, you may consider blocking this person and/or reporting abuse
Repo author here. The ordering gap is the one I would expect to bite first: probing repo-local executables before the .venv is materialized asserts on a state that does not exist yet, the exact failure mode I build lead-quorum to refuse at runtime. Observe the environment in the order the runtime builds it, not the order that is convenient to probe. And projecting the bind from the canonical listener declaration is the right call, host and port duplicated across two places drift the moment someone edits one.
Exactly. The contract was truthful; Ota was observing it in the wrong order.
We fixed the selected native path, so setup materializes the repo-owned environment before Ota probes
.venv/bin/python. We also made the declared runtime listener canonical, with Uvicorn bind arguments projected from that truth instead of duplicated.Thanks for designing lead-quorum with those failure boundaries clearly exposed. It made both Ota gaps impossible to dismiss as repo noise.
Curious whether you’ve seen the same ordering or duplicated-runtime-truth problem in other repos. What setup or runtime assumption still causes the most avoidable failures for contributors or CI?
The one that bites most, in my experience, is ambient state: setup and tests that pass because the author's machine already has something a fresh CI runner or a new contributor does not. A warmed venv, a model already downloaded, an env var exported three weeks ago, a service already running, a migration applied by hand once and never again. The ordering gap Ota hit is a special case of it, asserting on a .venv that exists on your box because you built it last Tuesday, not because setup built it this run.
The discipline that kills the whole class is the same one you just applied: build every dependency explicitly, in the order the runtime needs it, and assert only against state this run created, never state that happens to be lying around. The cheapest way to prove you did it is to run setup and the suite in a clean container or a fresh runner from nothing, because a cold start is the only honest test of a setup contract. The related one, and the reason the bind fix matters, is duplicated truth: a host, a port, a path repeated in two places is a bug with a delay on it. It passes until someone edits one copy. Projecting from a single canonical declaration is how you stop paying that later.
Ambient state is the dangerous setup state: it passes because it already existed, not because the contract created it.
Ota is adding explicit execution freshness:
cold_start_verified,persistent_state_reused, orunknown. A green run will only claim cold-start verification when Ota can prove an isolated boundary created the needed prerequisites.The same principle applies to runtime binds: declare the listener once and project command flags from it.
What single receipt field would make you trust a green setup was genuinely cold: created artifacts, boundary identity, or reused-state disclosure?
Created artifacts, but only in one specific form: a per-prerequisite creation record, the digest minted by the setup step at the moment it built the thing, re-verified at assertion time. If every artifact the assertions touch matches a digest this run minted, the run was cold with respect to everything it tested, and that is the only cold that matters.
Why I pick it over the other two. Boundary identity tells me where the run happened, but a fresh boundary is itself a claim: cache mounts, volumes, and fetched warmed state all survive a pristine image digest, so it is a strong witness and a weak proof. Reused-state disclosure is honest but self-declared, which puts it in the same family as the flags we already agreed not to trust: it reports intent, not fact.
The creation-record form also has a second payoff for your tri-state. It turns the run-level flag into a per-artifact verdict: instead of one cold_start_verified over the whole run, the receipt can state exactly which prerequisites were minted by this run and which were inherited, computed from digest comparison rather than declared. Cold stops being a property of the machine and becomes a property of each dependency's provenance, and that version you can enforce.
That distinction is useful. We’re shaping this as runner-authored provenance per prerequisite, not a global cold flag.
Ota will separate target freshness from derivation posture: a clean
.venvornode_modulesrebuilt this run can becold_start_verifiedeven when a package cache assisted reconstruction. Each consumer assertion must bind to the producer identity it actually relied on; anything Ota cannot verify remainsunknown.The harder next boundary is services, databases, and volumes. What identity would you trust there: initialized-state digest, migration lineage, or adapter-authored attestation?