Policy and provisioning

• repo declares runtime and tool versions
• org policy selects the approved source
• doctor can explain the selected backend request

• 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 the repo should declare what it needs and the organization should decide where those installs come from.

The contract stays honest about runtime and tool intent, while policy names the approved source that ota may use.

version: 1project:  name: provisioning-policy-proberuntimes:  node: "22"tools:  git: "2.46.0"checks:  - name: git-installed    kind: precondition    severity: error    run: git --versiontasks:  setup:    internal: true    run: 'true'

policies:  provisioning:    node:      source: pacman      approved_versions:        - "22"    git:      source: brew      approved_versions:        - "2.46.0"

Takeaways: the repo says what it needs, the org policy says where ota may get it, and doctor can explain the selected source back to you.

Use this pattern when you want approved installs to stay visible, auditable, and reusable instead of hiding them in setup scripts.