act: local GitHub Actions

Step 1: Bound the run

Identify the repository, workflow file, explicit event, job IDs, dependency jobs, matrix cells, host OS/architecture, and required toolchains. Read every selected job/action before execution, including reusable workflows and local actions.
Read references/security-parity.md. Treat workflow code as executable code with local file/network access; approve deployment, publication, destructive steps, and credential exposure separately from a local test.
Inspect invocation-directory/home/XDG act configuration and .env, .vars, .input, .secrets ownership without printing secret values. Existing config can add mounts, privileges, tokens, and flags even to an apparently narrow command.
Choose a disposable workspace and minimal non-production credentials. Prefer a container with its daemon socket mount disabled unless the reviewed job needs nested Docker. Host execution is an explicit non-isolated alternative, not a Docker failure fallback.

Gate: exact execution scope, transitive actions, side effects, configuration, and credential boundary are known.

Read references/installation-runners.md. Establish act --version and installed act --help; the released binary and pinned source take precedence over stale documentation snippets.
Container path -> verify Docker daemon/API access, select an image for each exact runs-on label with -P, and establish architecture/tool availability. macOS/Windows labels do not become those operating systems inside a Linux image.
Host path -> use -P label=-self-hosted only for reviewed code on a capable host; provision required shells/Node/toolchains. Keep host results distinct from container results.
Record image tag/digest and tool versions. Supply explicit platform mappings for unattended runs rather than accepting the first-run size prompt. Preserve existing version/config ownership.

Gate: the selected runner backend executes on the intended OS/architecture; every required label/tool has a deliberate mapping.