Container provisioning

• contract declares a missing tool and a container backend
• org policy approves apt as the provisioning source
• persistent container keeps the install available for setup

• it turns a repo pattern into something humans, CI, and agents can read the same way
• it makes the next command obvious instead of implied by README drift
• it keeps readiness, setup, and execution explainable in receipts and diagnostics

Use this when you want ota to make the container ready instead of asking every developer machine to carry the setup cost.

The example mirrors the real fixture: the repo asks for pv, policy approves apt, and the container gets the missing tool before setup runs.

The result is a cleaner first run, a reproducible install path, and one contract that works for local container work and CI.

version: 1project:  name: container-apt-probeexecution:  preferred: container  lifecycle: persistent  backends:    container:      image: rust:1.94-bookworm      engines:        - dockertools:  pv: "1.6.20-1"tasks:  setup:    internal: true    run: pv --version > prepared.txt

policies:  provisioning:    pv:      source: apt      package: pv      approved_versions:        - "1.6.20-1"

What you get: new contributors can run the repo without installing the missing tool first. The approved source stays visible in policy instead of hidden in a script. The same contract works in CI and local container execution.

Why this matters: the container carries the setup cost, the repo stays honest about what it needs, and policy keeps the source approved and reviewable.