Versioning & supply-chain policy

Principle: always adopt the latest stable versions, but pin them deterministically so builds are reproducible and the supply chain is auditable. Dependabot proposes weekly bumps to keep pins current. This page mirrors docs/versioning-policy.md.

GitHub Actions — pin to full commit SHA

Never reference actions by mutable tags (@v4) or branches. Pin to the full 40-char commit SHA of the latest release, with a trailing comment naming the version:

- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

Resolve a tag → SHA with:

gh api repos/<owner>/<repo>/commits/<tag> --jq .sha

Actions used by the site & deploy workflows

The landing/docs and deploy surfaces added these pins:

These join the repo’s existing Phase 0 pins (github-script, cache, CodeQL, dependency-review, rust-toolchain) — the full list lives in the repository’s versioning policy.

npm

• Use the latest stable of each package; record exact versions (no ^/~).
• Commit package-lock.json; CI uses npm ci (integrity hashes enforce the pin).

The landing/docs site under site/ follows this rule with its own isolated package.json + lockfile — it is not part of the root npm workspaces, so it never churns apps/web or the root lockfile. Its dependencies are exact-pinned (Astro and the Playwright/axe test tooling) and installed with npm ci.

.NET

• Central Package Management: versions live in Directory.Packages.props, exact and pinned.
• Pin the SDK in global.json; restore is lockfile-backed (packages.lock.json).

Rust / Tauri

• Exact crate versions; commit Cargo.lock. Pin the toolchain via rust-toolchain.toml.

Containers / deploy

• Reference base images by digest (image@sha256:...), not floating tags.
• azd / IaC pin provider and module versions.

Automation

Dependabot groups updates per ecosystem and rewrites SHA pins + version comments. CI must pass on the bumped versions before a merge (human approval via Squad gates).

Found an issue in these docs?Open an issue on GitHub.