Pressure-testing Ota on Dagger: generated SDK lineage and bounded engine truth

Dagger is a useful pressure repository because it already has a strong execution model. Its SDKs are generated from a shared API surface, its CLI starts a Docker-backed engine, and a generated-source change has consequences beyond the command that wrote it.

The useful Ota question is narrow: can Ota govern one generated TypeScript SDK closure from declared source inputs, through the generator, to a committed and replayable output without pretending to govern every Dagger SDK, engine operation, or release artifact?

This note records the Ota contract and pressure boundary. It is intentionally a slice proof, not a claim that Dagger is globally ready or that Ota controls Dagger's managed engine.

Generated source is easy to under-model. A CI step can run a generator and exit green while the repository still carries stale output, or while a later consumer has never actually seen the generated files.

The selected Dagger shape is small enough to prove honestly:

• one source-managed Dagger CLI;
• one generator for the TypeScript SDK client;
• one declared generated-source artifact;
• one consumer that detects an uncommitted generated diff; and
• one promoted replay consumer that checks the reviewed baseline without regenerating it.

That is enough to test lineage and replay authority without converting a selected SDK path into a claim about Dagger's complete code-generation or release system.

The contract pins released Ota and declares the minimum compatible version. It models the generated output as a first-class artifact:

artifacts:  typescript-sdk-client:    kind: generated_source    producer: sdk:generate    paths:      - sdk/typescript/src/api    inputs:      - dagger.json      - toolchains/typescript-sdk-dev/ts-sdk.dang    replay:      authority_manifest: replay/typescript-sdk-client.ota.json      consumption: verify_unchanged tasks:  sdk:check-generated:    depends_on:      - sdk:generate    requires_artifacts:      - typescript-sdk-client

The producer invokes the declared Dagger release asset. The ordinary consumer depends on the producer and rejects a generated diff. The promoted consumer has no generation dependency; it must consume only the explicitly promoted authority and then verify the same output directory.

The contract assigns Ota ownership of selected tool fulfillment, contract closure, output lineage, replay admission, and receipt evidence when those stages are reached. Dagger owns the meaning of the generator, its engine lifecycle, and the module orchestration inside that engine.

The first pressure path exposed a real Ota runner defect: the declared Dagger release asset was fulfilled and version-checked, but native shell execution did not preserve the managed PATH when the generator started. The contract had named the correct tool; the runner failed to carry that truth into execution.

The fix belongs in Ota, not in Dagger-specific shell glue. Native shell execution now receives the resolved managed PATH, with regression coverage for the source-managed command path.

The same pressure also sharpened the engine boundary. Dagger starts an engine through Docker and performs package and module resolution inside that managed runtime. Ota can declare and verify the Dagger CLI and Docker requirement, but it does not independently attest the engine's internal package index, module image, or all external state used by the generator. Those facts remain bounded rather than silently promoted to repository proof.

The pressure workflow is deliberately staged. Ota must establish contract truth and admission before the repository's generator is allowed to start; generation, receipt capture, and replay are separate intended stages rather than one undifferentiated green check. This design is not itself matrix evidence.

The workflow installs Ota from the contract's released source, not from a branch or implementation revision. The generated SDK lane and promoted replay lane also remain separate: recording creates evidence, promotion selects it, and replay consumes that selection without falling back to the latest local receipt.

The released-source pressure run contains one Ubuntu job and concluded with failure. It is not Linux/macOS/Windows matrix evidence. The run is bound to exact Dagger revision 3ffcd68bad1a52011c3f08f390c0093a1e0b9787. Its retained GitHub job logs establish only the successful stages reached before that failure:

• the repository installed Ota from its declared released source;
• the contract validated without warnings;
• runnable and agent-safe surfaces were inspectable;
• the generated SDK task and workflow could be previewed; and
• workflow preparation completed before the Dagger-managed generator started.

Execution then stopped inside Dagger's managed engine. Its package resolver could not satisfy the engine-internal protobuf-dev~32 constraint from the configured repositories. This is useful pressure evidence: the contract made the boundary visible and Ota stopped at the Dagger-managed runtime failure instead of converting a partial run into generated-source or replay proof.

The generator, receipt, promotion, and replay stages were not reached. They are therefore not claimed as exercised by this run.

The selected lane does not prove:

• every Dagger SDK or generated language client;
• Dagger documentation generation or release artifacts;
• the health, package index, module image, or internal state of the Dagger-managed engine;
• production Docker policy, registry credentials, or deployment behavior;
• cross-platform or repeated matrix behavior; or
• repository-global correctness beyond the selected generated TypeScript SDK closure.

When exercised, promoted replay would not prove application correctness. It would prove only that the explicitly selected authority and output identity were consumed without the producer closure. This run did not reach that stage, and a future green replay lane would not remove the engine, release, or broader-repository boundaries above.

Contract-owned and exercised

• released Ota bootstrap;
• Dagger release-asset fulfillment and version checking;
• contract validation and task/workflow admission; and
• workflow preparation before the Dagger-managed generator started.

Contract-owned but not reached

• the selected generated TypeScript SDK producer and consumer closure;
• generated-output lineage and committed-diff detection;
• explicit replay recording and promotion; and
• promoted replay consumption without regeneration.

Repository- or runtime-owned

• Dagger engine lifecycle and internal package/module resolution;
• Docker daemon policy and image availability;
• other SDKs, documentation, release, and deployment workflows;
• GitHub triggers, permissions, credentials, runners, and artifact retention; and
• Linux, macOS, Windows, and repeated-run matrix behavior.

Ota platform gaps

The earlier pressure path exposed and led to the repair of Ota's managed-PATH runner defect. The final released-source run exposed no additional Ota platform gap; it stopped at the bounded Dagger-managed engine dependency described above. If a later run shows that Ota cannot model a material Dagger boundary cleanly, that result belongs in a named widening opportunity rather than a repository-local helper or an over-broad proof claim.

• Upstream project: dagger/dagger
• Pressure contract: ota.yaml at the exact pressure revision