Pressure-testing Ota on Immich: orchestrators, fulfillment, and first-class prepare

Immich turned out to be one of the highest-value pressure repos so far because it exposed multiple Ota weaknesses at once.

This was not a repo where the problem was missing commands. The repo already had a real task surface, a real tool-version surface, and a real Docker-backed local stack. The problem was that Ota did not yet have strong enough product concepts to model that truth directly.

The old shape was too weak in three places:

• toolchain ownership was too tightly coupled to fixed providers
• repo-level mise orchestration was being flattened into shell strings
• finite setup phases like Docker image hydration were still being expressed as opaque run: ... glue

Immich forced those boundaries into the open.

The biggest lesson was that Ota needed to separate three truths cleanly:

1. what a repo needs
2. how Ota fulfills or activates that requirement
3. how the repo mediates execution through its own orchestration layer

That produced three real product changes.

1. orchestrators

Immich's live contributor and CI task surface is driven by mise.

Treating that as just tools.mise plus run: mise ... would have been a contract that technically runs but still hides repo truth in shell strings.

Ota now has a first-class repo orchestration surface:

orchestrators:  mise:    kind: mise    required: true    config_files:      - mise.toml    activation:      trust: true    prepare:      install: true

That matters because trust and install are now explicit repo-level concepts instead of side effects of task text.

Just as importantly, task execution can now say how it runs through that orchestrator:

tasks:  server:verify:    run: //server:ci-unit    execution:      orchestrator:        ref: mise        mode: task

That is the missing half of the model. orchestrators.mise declares the repo-level manager truth, and tasks.<name>.execution.orchestrator declares how a selected task is mediated through it.

2. capability-first toolchains with structured fulfillment

Immich also proved that fixed provider coupling was the wrong long-term model.

The contract should say:

• this repo needs Node 24.15.0
• this repo needs pnpm 10.33.4
• Ota should fulfill that through mise on the selected path

That is now modeled directly:

toolchains:  "node":    version: "24.15.0"    package_managers:      pnpm: "10.33.4"    fulfillment:      source: mise      mode: run

That is a better boundary than pretending mise is itself the Node toolchain.

The honest nuance is that fulfillment.source: mise is still a current supported compatibility lane, not the final canonical shape for every future repo-manager surface. But for a repo whose selected execution path is genuinely mediated by mise, it is a much stronger boundary than provider-coupled toolchain ownership or raw shell glue.

3. first-class task preparation

The Immich app workflow also made another weakness obvious:

docker compose pull redis database is not service startup, and it is not just arbitrary shell.

It is finite dependency hydration.

That produced first-class executable task preparation:

tasks:  setup:docker:images:    category: setup    prepare:      kind: dependency_hydration      medium: container_images      source:        kind: docker_compose        cwd: docker        files:          - docker-compose.base.yml          - docker-compose.dev.yml        env_files:          - .env.compose      targets:        - redis        - database

That is a stronger product surface than run: cd docker && docker compose ....

Immich did not just motivate schema changes. It exposed concrete engine defects too.

Orchestrator prep ordering

Ota originally tried to fulfill toolchains before honoring orchestrator preparation.

For mise, that meant mise install ... could happen before mise trust, which is wrong.

The fix was to prepare orchestrators before source-managed toolchain fulfillment.

Backend env parity during prep

Container-backed mise execution also exposed an engine gap.

Run-path prep and fulfillment were not inheriting the effective backend env consistently. That broke container flows where MISE_CACHE_DIR, MISE_DATA_DIR, and MISE_STATE_DIR had to be writable inside the selected execution context.

That fix belonged in Ota, not in repo-local glue.

Dry-run trust on selected-path fulfillment

Once Immich used toolchains.node.fulfillment.source: mise with mode: run, Ota also had to get dry-run trust right.

The repo should not be blocked in doctor or up --dry-run just because the ambient host Node differs, when the selected path will fulfill Node through mise.

That was another real Ota fix, not a repo workaround.

Container cleanup trust

Container proof also exposed cleanup races around dependency-isolation volumes staying “in use” briefly after container removal.

That is Ota-owned lifecycle trust. If proof succeeds but cleanup flakes, users still lose confidence in the product. The correct response is to harden cleanup behavior, not to normalize manual cleanup instructions.

The cleared Immich slice is materially stronger than the original verification-only model.

It now proves:

• native verification across Ubuntu, macOS, and Windows
• container verification on Ubuntu
• a docker-backed local app workflow through the repo's mise task surface
• env materialization for the local dev stack
• external image hydration as a distinct setup phase
• runtime proof against declared HTTP surfaces
• a dedicated e2e docker workflow as a first-class path, not just an implicit side lane
• explicit teardown and post-teardown cleanliness

That is not the entire Immich universe. It is the current high-value readiness slice.

The important point is that the contract is now using stronger Ota concepts instead of hiding repo truth in task text.

Immich was valuable because it forced Ota to stop being satisfied with “the command runs” and start modeling the actual structure around the command.

This repo drove Ota toward:

• repo-level orchestration truth
• capability-first toolchains
• explicit fulfillment
• first-class preparation phases
• stronger cleanup trust

That is what pressure testing is supposed to do. The repo is not there to make a green box. It is there to reveal where the product is still too weak.

• Contract: immich ota.yaml
• Matrix workflow: test-ota-contract-matrix.yml
• Green widened run: #27104550144

Immich reinforced a rule that matters for Ota as infrastructure:

if a repo needs Ota plus unmodeled setup lore, shell glue, or manual cleanup habits to be trustworthy, the job is not done.

The correct move is to strengthen Ota until the repo truth can be modeled directly.