CI Standard

CI should fail fast on governance before it spends time on expensive build, hardware, platform, browser, native, or release matrices. For a single package, the first CI job should run dev-std audit .. For a workspace, the first CI job should run the workspace-level dev-std audit . so each registered package boundary is checked before downstream jobs start.

Gating Rule

Expensive jobs must depend on the governance job. A dev-std failure means the governance or documentation contract is already broken, and that should be fixed before using CI minutes on long-running tests, cross-platform builds, packaging, deployment, or hardware lanes.

GitHub Actions Shape

jobs:
  governance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v5
      - run: uvx --from wn-dev-std==2026.8.12 dev-std audit .

  test:
    needs: governance
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v5
      - run: uv run rack run --all

GitLab CI Shape

stages:
  - governance
  - test

governance:
  stage: governance
  image: ghcr.io/astral-sh/uv:python3.12-bookworm
  script:
    - uvx --from wn-dev-std==2026.8.12 dev-std audit .

test:
  stage: test
  needs: ["governance"]
  script:
    - uv run rack run --all

Version Pinning

Downstream CI should pin the released dev-std version that matches the repository's standard_version. Local development may use the workspace checkout, but shared CI should be deterministic unless a job is explicitly testing the next standard version.