Pressure-testing Ota on Ollama: Go module hydration and honest source-runtime proof
How Ollama pushed Ota to model Go module hydration as a first-class preparation phase and sharpened the boundary between source-runtime proof, built binaries, and contract correction.
Overview
Ollama ended up being valuable for a narrower reason than Immich, but still for a real product reason.
The repo did not need a new orchestration model. It did not need a new multi-service app story. What it exposed was a weaker but still important Ota gap:
- Go dependency hydration was still trapped inside shell
runglue - runtime proof could easily blur built-binary truth with source-runtime truth
- some failures that looked like platform defects were actually just contract corrections
That combination made Ollama the right repo to tighten Ota's preparation surface instead of just broadening another matrix lane.
What Ollama exposed in Ota
The core lesson was simple:
go mod download is not arbitrary shell.
It is the same class of finite dependency hydration as:
pnpm installnpm cidocker compose pull ...
Before this pass, Ota already had first-class dependency hydration for:
- docker-backed image hydration
- node package-manager hydration
But Go repos still had to hide module hydration in run.
Ollama made that gap obvious.
The product change
Ota now ships a Go module dependency-hydration slice under tasks.<name>.prepare:
tasks: setup: prepare: kind: dependency_hydration medium: package_dependencies source: kind: go_modules cwd: . requirements: toolchains: - go effects: network: true network_kind: dependency_hydrationThat lets Ota execute go mod download structurally instead of requiring:
run: go mod downloadThis matters for the same reason the earlier prepare work mattered elsewhere:
- the task intent is machine-readable
- the side effects stay explicit
- setup is kept distinct from runtime startup
- Ota can classify this as dependency hydration instead of opaque shell
Why this repo was also useful for runtime-proof honesty
Ollama also forced a cleaner contract distinction around runtime proof.
The repo documents two different runtime truths:
go run . serve./ollama serve
Those are not the same claim.
One is the documented source-runtime path. The other assumes a built native payload already exists.
That sounds obvious, but it is exactly the kind of thing contracts blur when a tool only cares that "something starts."
The right contract had to be explicit about which truth it was proving.
For the current pressure slice, Ota now proves the documented Go source-runtime path honestly instead of pretending the built-binary path and the source path are interchangeable.
What this did not mean
Ollama was also a useful reminder that not every failing run is an Ota defect.
Several failures in the pressure cycle were contract corrections:
- runtime proof using the wrong serve path
- setup/run sequencing that did not match the actual documented slice
- unclear assumptions about whether proof was against a prepared workspace
Those needed to be fixed in the contract first.
That distinction matters because Ota maturity does not come from labeling every bad run a platform bug. It comes from classifying the failure correctly:
- fix contract truth when the contract is lying
- fix Ota when the platform is the thing that is weak
Ollama gave both kinds of signal, but the highest-value lasting change was still the new Go hydration slice.
What the final Ollama slice now proves
The current cleared slice proves:
- native cross-OS verification
- Go module hydration as first-class preparation
- native source build and Go test
- runtime proof against the documented local API surface
- a contract that distinguishes source-runtime proof from broader packaging or GPU claims
It still does not claim the whole Ollama world:
- not Docker deployment truth
- not GPU backend truth
- not packaged installer truth
That is the correct scope. A narrower honest slice is better than a broader vague one.
Why this repo mattered
Ollama mattered because it kept pressure on a product rule that is easy to violate:
if a setup phase has stable structure, Ota should model it directly instead of making repos hide it inside run.
This repo pushed Ota one step further in that direction by making Go module hydration a first-class preparation surface.
Links
- Contract: ollama
ota.yaml - Matrix workflow: test-ota-contract-matrix.yml
- Green run: #27135185003
Takeaway
Ollama reinforced a narrower but important Ota rule:
finite setup truth should graduate out of shell glue as soon as Ota can model it honestly.
That is what happened here for Go module hydration.
Take action