Bobai Kato for Ota

Posted on Aug 14 • Originally published at ota.run

Pressure-testing Ota on Flagr: native and container Go verification with honest boundaries

#pressuretesting #flagr #go #containers

Overview

Flagr is a useful test of whether Ota can keep a real service
repository legible. It has a portable Go verification path, a local SQLite-backed API, a
six-instance Docker Compose integration topology, four database services, and a locally tagged
integration image. Those are different execution truths. One green test command should not flatten
them into one readiness or deployment claim.

The pressure contract pins released Ota v1.6.25, separates deterministic verification
from runtime and integration work, and gives the Compose topology a runner-owned lifecycle proof.
It also removes Windows from the selected verification surface rather than carrying an audit-only
lane that could be mistaken for execution support.

Why this repo mattered

Flagr combines several patterns that show up in mature service repositories:

a finite Go verification lane;
a long-running local service with a declared HTTP surface;
an integration topology that needs an image build, Compose startup, readiness, test execution, and teardown; and
CI that needs to distinguish a safe verification lane from deliberately external-state-mutating integration work.

The pressure question was not merely whether go test could pass. It was whether the contract
could own hydration, execution mode, runtime readiness, image construction, service dependencies,
failure cleanup, and agent refusal without hiding the important transitions in CI shell.

What the contract models

The deterministic lane uses typed Go module hydration in native and container contexts. Linux and
macOS own the native verification path; Linux also owns the container path through
golang:1.26-bookworm. The selected Go closure is intentionally unavailable on Windows.

The integration image is not a raw docker build string:

integration:image:
  description: Build the locally tagged image consumed by the six-node Compose integration topology
  category: build
  action:
    kind: build_container_image
    file: integration_tests/Dockerfile-Integration-Test
    context: .
    tag: flagr_integration_tests

The workflow split stays explicit:

verify is deterministic Go package verification;
local owns the SQLite-backed API runtime;
integration owns the image, Compose topology, readiness, integration suite, benchmark, and explicit teardown;
integration:lifecycle gives Ota ownership of service start, assertion, teardown, and archive evidence;
integration:lifecycle:failure-control intentionally fails the real assertion and verifies that teardown still completes; and
agent refusal canaries exercise the real boundary around the unsafe image task and integration workflow.

The lifecycle model includes the Flagr services and their MySQL and PostgreSQL dependencies. Each
managed service declares manager_inactive as its teardown assertion. Readiness failure is not
accepted as proof that a service stopped; the Compose manager must report the terminal state.

What Flagr exposed in Ota

Flagr exposes several real Ota boundaries without needing repository-specific workarounds.

Aggregate verification needed to remain visible as executable closure support in task discovery.
Doctor also had to stop probing repo-owned commands before their producer task had created them.
Those are ordering and discovery problems in the runner, not defects in a Go repository.

The CI pressure exposed another distinction: a finite workflow cannot stop after a
readiness-oriented ota up. Ota's provider-neutral CI projection distinguishes a finite task
closure from a service-runtime path. The finite lane executes its selected task; runtime proof owns
its own execution path.

That is why the image build matters. Ota owns the action, Dockerfile, context, local tag, and
evidence surface. Flagr still owns what the image means and how its integration system behaves.

The lifecycle lane closes the remaining shell-shaped gap. Starting Compose, probing six
Flagr endpoints, running an assertion, and calling down in a final CI step showed that readiness
was proved but transaction-owned cleanup was not. Ota's managed lifecycle surface now acquires
cleanup authority before start, runs the declared assertion, finalizes each managed service, and
archives the bounded result. The failure control matters because successful cleanup alone would not
prove that the same finalization path survives an assertion failure.

Matrix design

The released matrix is deliberately split by evidence type:

Lane	Platform and mode	Evidence
Managed `verify` projection	Linux native	Contract validation, Doctor, safe discovery, dry-run admission, real verification, receipt archive, and two refusal canaries
Managed `verify` projection	macOS native	The same finite verification and refusal boundary on the second supported host OS
Managed `verify` projection	Linux container	The same selected verification closure inside the contract-owned Go image
Native runtime proof	Ubuntu and macOS	Bounded execution of the SQLite-backed local API and its declared health surface
Container runtime and integration	Ubuntu	Container runtime proof plus the six-instance Compose suite, benchmark, receipt, and explicit teardown
Managed lifecycle pressure	Ubuntu	Successful lifecycle archive plus an assertion-failure control that must still finalize every transaction-owned service
Contract-to-CI drift	Ubuntu	The first-party Action checks that CI consumes contract-owned bootstrap and verification truth

The contract and generated workflows bind bootstrap to released v1.6.25. All three supported
managed projections are generated from the final contract, and their human-owned caller bindings
are checked against the same projection identities before hosted execution.

The complete hosted governance matrix is green in
run 31834610141 at commit
58f5263a. It executed Linux and macOS native verification, Linux container verification, both
refusal canaries in every generated lane, native runtime proof on Ubuntu and macOS, container
runtime proof, the Compose integration suite and benchmark, explicit teardown, and the
contract-to-CI drift gate.

The managed lifecycle lane is independently green in
run 31834610099. The successful
transaction acquired ownership for and finalized ten services, passed the real integration
assertion, and observed every declared teardown state. Its separate failure control sent the same
assertion to an unreachable endpoint, recorded the expected non-zero outcome, and still completed
finalization for all ten services.

That lifecycle result is deliberately passed_with_unproven_boundaries, not a bare pass. The four
database services do not declare readiness or another manager-backed start-state observer, so
service_started_state_not_proved remains attached to each database obligation. Application
output and broader repository completion also remain explicitly unproved.

The distinction between the lanes is part of the result. A refusal canary is not a successful
integration run; it proves that the real runner still rejects that path in agent mode. Runtime
readiness is not lifecycle finalization. Lifecycle finalization is not application correctness or
production deployment evidence.

Doctor stayed honest

The released contract validates with no errors, but Doctor intentionally retains two classes of
warning:

the agent-safe verification closure performs declared Go dependency hydration over the network; and
the lifecycle closure mutates Docker, MySQL, and PostgreSQL external state.

Those warnings are not noise to remove. They tell an operator that repository write boundaries do
not govern registries, the Docker engine, or database state. The managed verification lanes remain
agent-admitted because the network effect is typed as dependency hydration. The integration and
lifecycle lanes remain outside agent-safe admission.

Uncovered material behavior

The pressure result is bounded as follows:

Contract-owned and exercised

typed Go module hydration for the selected native and container verification modes;
deterministic Go package verification on Linux, macOS, and Linux container execution;
SQLite-backed local API runtime and HTTP readiness;
the locally tagged integration-image build;
the selected six-instance Compose integration suite and benchmark;
successful and assertion-failure lifecycle finalization; and
agent refusal canaries plus contract-to-CI drift detection.

Explicitly outside this proof

the UI build, browser E2E lane, actionlint job, dependency-freshness policy, and broader upstream benchmark surface remain repo-owned CI behavior outside this selected Ota pressure contract;
GitHub triggers, permissions, credentials, runner policy, and artifact retention remain provider-owned;
release publication to GHCR, multi-architecture release images, and production deployment remain outside Ota's selected execution scope; and
external production services, production data, and deployment credentials were neither selected nor proved.

Ota platform gaps

This pressure lane exercises shipped Ota surfaces without adding a repo-local workaround. Any
hosted failure must be classified before editing: contract defect, upstream Flagr behavior,
provider failure, or a new Ota platform gap. A green matrix does not erase the explicit boundaries
above.

What this did not prove

The matrix does not prove Windows execution. The contract prevents that over-read by excluding the
selected verification tasks from Windows rather than publishing a non-executing audit lane.

The selected integration topology is real local proof, but it is not evidence that every deployment
environment has the same topology or that production operations are governed by this contract. The
lifecycle archive proves only the selected Compose transaction and its declared teardown
assertions. It does not prove Flagr's application outputs, repository-wide correctness, or external
provider policy. It also does not promote the four database services to observed started state;
their command execution and terminal manager state are evidenced, while their start-state
obligations remain bounded as not_proved.

Hosted result

The hosted governance and lifecycle matrices are green on the same pressure commit and install Ota
from the contract's released v1.6.25 source. Local validation also passed Doctor, discovery,
native and container dry-run admission, real native and container verification, refusal canaries,
managed projection checks, and workflow linting. The hosted runs, not that local result, are the
publication evidence.

DEV Community