Deterministic git template bootstrap

• setup truthfully owns one scaffold or factory repo materialization lane
• the lane should clone a Git-backed template but leave a fresh local repo behind
• today the repo uses helper shell glue for git clone, inherited .git removal, and git init

• 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 turning a Git-backed scaffold into a fresh local repository and that truth should stay on a first-class deterministic action surface instead of hiding in bootstrap shell glue.

The example keeps the parent output directory and the template materialization under one governed bundle, while still keeping the scaffold semantics intentionally idempotent on repeat runs.

version: 1project:  name: action-ensure-git-template  description: Focused example for deterministic Git template bootstrapexecution:  default_context: host  contexts:    host:      backend: native      requirements:        tools:          git: "*"tasks:  scaffold:sample:    context: host    action:      kind: ensure_bundle      steps:        - kind: ensure_directory          path: .ota-pressure        - kind: ensure_git_template          path: .ota-pressure/sample-extension          source:            git: https://github.com/codyhxyz/create-chrome-extension.git            ref: mainworkflows:  default: local-bootstrap  local-bootstrap:    prepare:      task: scaffold:samplemetadata:  ota:    minimum_version: "1.6.23"

Use ensure_git_template when bootstrap truth is factory/scaffold materialization, not a vendored dependency checkout that should stay wired to an upstream remote.

Keep template materialization deterministic with source.ref for proof lanes; omitted refs remain moving-head pressure truth and should be treated that way in review.

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

If the scaffold output should be an operator-visible entrypoint on its own, keep it as a dedicated action task instead of burying it in a larger helper shell.