Container network bootstrap

• the repo needs one shared external Docker network before compose or container workloads start
• today the lane uses docker network inspect / docker network create shell glue
• network bootstrap should stay first-class and inspectable in the contract

• 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 shared Docker network readiness and should not disappear into shell conditionals.

The example keeps the network bootstrap as one finite native action task that workflows or other tasks can depend on directly.

version: 1project:  name: action-ensure-container-network  description: Focused example for deterministic Docker network bootstrapexecution:  default_context: host  contexts:    host:      backend: native      requirements:        tools:          docker: "*"tasks:  network:ensure:    context: host    action:      kind: ensure_container_network      name: penpot_shared    requirements:      tools:        docker: "*"workflows:  default: local-network  local-network:    prepare:      task: network:ensure

Use ensure_container_network when the setup truth is one shared external Docker network.

Keep requirements.tools.docker explicit so the contract still declares the real host prerequisite.

If the lane also owns deterministic host files, keep those as separate action tasks or an ensure_bundle; do not stretch this action into unrelated setup work.