# Supported Hosts And Dependencies
## Required macOS support
Every `dragginzgame` package must work on macOS under the
[engineering baseline](../DRAGGINZGAME.md#host-support). This covers dependency setup,
native tools and the applicable build, test and deployment workflows. Canister
and frontend packages retain their product runtime targets while supporting
their host workflows on macOS.
Each consumer declares its supported macOS versions and architectures, exact
prerequisites and qualification commands in its local host matrix. Missing CI
coverage or a known macOS failure is a support gap to correct. An exception
requires explicit maintainer approval with scope and reason.
Keep the required support decision separate from passing evidence for a revision.
Native CI or recorded native execution qualifies relevant host behavior; Linux
execution, cross-compilation and available download assets do not establish
macOS filesystem, process or deployment behavior. Report unqualified workflows
explicitly while retaining the macOS support requirement.
## Host-specific setup and commands
Dependency installation and CI/deployment setup may differ by host. Document
those differences at the owning boundary and preserve the same product
contracts, validation obligations, authorization, recovery and retained artifacts.
- Declare the required shell and Make implementation, system utilities and
package-manager prerequisites. Check GNU/BSD differences, filesystem modes,
paths and process handling wherever the workflow relies on them.
- Select host-appropriate dependency packages and executable assets explicitly.
Preserve reviewed versions, lockfiles and platform digests; dependency setup
does not authorize selecting newer versions or making live deployment effects.
- Exercise applicable package builds, focused tests, dependency setup and
operator tooling on the declared native macOS hosts. Deployment-tool validation
does not itself require or authorize a live deployment.
The matrix below describes Shared Tooling's own portable scripts. Consumers own
their package-specific matrices within this required support policy.
## Portable script baseline
The portable scripts target Bash 3.2 or newer and standard Unix userland.
Repository CI exercises the offline regression set on:
| Ubuntu 24.04 GitHub-hosted runner | Portable scripts, ShellCheck, workflow lint, installer downloads, and secret scan |
| macOS 15 Apple Silicon GitHub-hosted runner | Portable offline regression set, including release recovery fixtures, with Apple's Bash 3.2 |
| macOS 15 Intel GitHub-hosted runner | Same portable offline regression set with Apple's Bash 3.2 |
The table describes the intended CI contract. Passing qualification for a
revision requires its matching workflow run; adding a matrix entry does not
establish that the run passed.
Shared Tooling's portable scripts do not support Windows or non-Bash shells.
This does not prohibit a consumer from supporting additional hosts or shells
through its own qualified tooling.
## Tool-specific dependencies
| `scripts/dev/cloc.sh` | Git, Cargo, `cloc`, `jq`, `awk`, `find`, `grep`, and `sort` |
| `scripts/dev/gh-ci.sh` | Git and an authenticated GitHub CLI |
| `scripts/ci/run-validation-targets.sh` | GNU Make plus `awk`, `grep` or `rg`, `sed`, `tail`, and `tee` |
| Installer scripts | `curl`, `tar`, a SHA-256 implementation, and the archive codec used by the selected tool |
| `scripts/ci/run-sccache.sh` | An executable `sccache` binary |
| Snapshot verification | A SHA-256 implementation |
| Snapshot refresh | Git, a clean Shared Tooling checkout, and a SHA-256 implementation |
| Release runner | GNU Make, Git, `date`, explicit consumer metadata/check targets, and Bash 3.2 |
| Rust pre-commit hook and installer | Git, GNU Make, consumer-owned `fmt` prerequisites (Cargo/rustfmt and an exact `cargo-sort` version), Bash 3.2 and standard Unix file utilities |
The hook regression fixture also requires `jq` and the `cargo-sort` version from
`ci/tool-versions.env` (`2.1.4`). CI installs it before offline tests; local
validation requires it to be prepared beforehand and never installs it implicitly.
## Installer-capable platforms
The actionlint, Gitleaks, and ShellCheck installers contain asset mappings for
Linux and Darwin on x86-64 and ARM64. Branches not exercised by the repository's
installer-download CI are install-capable, not support claims.
Consumers own the exact tool versions and platform digests they admit.