Pressure-testing Ota on EventCatalog: generated artifact lineage across sibling consumers

The finding

EventCatalog exposes a common monorepo failure mode: generated code may exist, its producer may be green, and the real downstream consumer can
still fail. Its Langium language server generates AST, grammar, module, and syntax files; a sibling VS Code extension consumes that output alongside the workspace SDK and visualiser.

The useful question is therefore not "did generation finish?" It is whether the repository can execute the complete consumer closure from declared dependency hydration through the package that needs the generated result.

The contract boundary

Ota models the generated output separately from the tasks that establish and consume it:

artifacts:
  language-server-ast:
    kind: generated_source
    producer: language-server:generate
    paths:
      - packages/language-server/src/generated/ast.ts
      - packages/language-server/src/generated/grammar.ts
      - packages/language-server/src/generated/module.ts
      - packages/language-server/syntaxes/ec.tmLanguage.json
      - packages/vscode-extension/syntaxes/ec.tmLanguage.json
    inputs:
      - packages/language-server/src/ec.langium
      - packages/language-server/langium-config.json

tasks:
  vscode-extension:build:
    depends_on:
      - language-server:generate
      - language-server:build
      - sdk:build
      - visualiser:build
    requires_artifacts:
      - language-server-ast

The setup task owns typed, frozen-lockfile pnpm hydration with the language-server package filter. That removes bespoke install shell glue without pretending the dependency path is harmless: it reaches the package registry, so the selected closure is intentionally not routine agent-safe execution. Humans and CI can run the declared verification workflow; unattended agents cannot
silently acquire that networked setup authority.

What Ota had to learn

This pressure case made two platform requirements concrete. Generated-source lineage had to remain visible at consumer admission and in execution evidence, rather than surfacing only after a build failure. And pnpm dependency hydration needed a package filter that could select a sibling package without collapsing the workspace into one opaque install-and-build command.

The resulting boundary is deliberately narrow. Ota knows which task produced the declared paths, which source inputs define that artifact, and which consumer requires it. A path merely existing is not a freshness claim, and this note does not treat it as one.

The released pressure run

Run 33167453142 passed against released Ota v1.6.26 at EventCatalog commit b593861fc84147884dcfcaf03898e490596927a0.

The native matrix ran on Ubuntu, macOS, and Windows. Each lane validated the contract, ran Doctor, listed runnable and agent-safe task surfaces, dry-ran both the consumer task and named workflow, executed the real VS Code-extension consumer closure, archived its receipt, and uploaded the resulting evidence. A separate Linux job ran ota proof runtime --workflow verify, archived the workflow receipt, and retained its proof artifact.

That is stronger than proving the generator alone: the final build consumes the generated source after Ota has resolved its producer, language-server compilation, SDK build, and visualiser build. The matrix pins the released Ota source through the contract and pins every GitHub Action revision to an immutable SHA.

Boundaries that remain

This is contract-owned and proved for one finite native language-server-to-extension build path. It does not prove the full EventCatalog workspace, every generated artifact, the semantic correctness of the generated language model, VS Code packaging or distribution, package publishing, releases, or deployment behavior.

The contract does not advertise container execution for this slice, so the three operating-system legs are native-only evidence. Package-registry availability remains an external dependency of the declared hydration lane. Those are explicit limits, not green-run implications.

Links

• Upstream project: eventcatalog/eventcatalog
• Pressure contract: fork branch ota.yaml
• Released pressure matrix: run 33167453142

Originally posted here: https://ota.run/blog/pressure-testing-ota-on-eventcatalog-generated-lineage-5m2b