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

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:

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.

Links

• Upstream project: openflagr/flagr
• Pressure contract: ota.yaml at 58f5263a
• Governance matrix: run 31834610141
• Lifecycle matrix: run 31834610099

Originally posted here: https://ota.run/blog/pressure-testing-ota-on-flagr-native-container-go-5m3c