Deterministic git checkout bootstrap

• setup truthfully owns one sibling or vendored repo checkout
• the lane is clone-if-missing materialization, not fetch/reset/update
• today the repo uses a helper shell script only to run git clone and optional git checkout

• 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 one setup lane honestly owns materializing a repo-local checkout and that truth should stay on a first-class deterministic action surface instead of hiding in shell bootstrap glue.

The example keeps the parent vendor directory and the Git checkout under one governed bundle, while still keeping the checkout semantics intentionally non-destructive on repeat runs.

version: 1project:  name: action-ensure-git-checkout  description: Focused example for deterministic Git checkout bootstrapexecution:  default_context: host  contexts:    host:      backend: native      requirements:        tools:          git: "*"tasks:  bootstrap:deps:    context: host    action:      kind: ensure_bundle      steps:        - kind: ensure_directory          path: vendor        - kind: ensure_git_checkout          path: vendor/wagtail          source:            git: https://github.com/wagtail/wagtail.git            ref: mainworkflows:  default: local-bootstrap  local-bootstrap:    prepare:      task: bootstrap:depsmetadata:  ota:    minimum_version: "1.6.22"

Use ensure_git_checkout when bootstrap truth is clone-if-missing, not implicit repo update or reset.

If the checkout should be operator-visible on its own, keep it as a dedicated action task instead of burying it inside a larger shell setup lane.

If setup also owns deterministic env/file prep, compose those steps through ensure_bundle instead of dropping back to shell orchestration.