Merge branch 'main' into fix/130-broken-e2e-testids

Author: EtienneLescot

.claude/launch.json

@@ -26,6 +26,12 @@
       "runtimeExecutable": "npm",
       "runtimeArgs": ["--prefix", "website", "run", "serve", "--", "--port", "3111"],
       "port": 3111
+    },
+    {
+      "name": "docs-dev",
+      "runtimeExecutable": "npm",
+      "runtimeArgs": ["--prefix", "website", "run", "dev", "--", "--port", "3112"],
+      "port": 3112
     }
   ]
 }

.github/workflows/build.yml

@@ -224,18 +224,42 @@ jobs:
           VERSION="$(node -e "console.log(require('./package.json').version)")"
           echo "version=$VERSION" >> "$GITHUB_OUTPUT"
 
+      # `--${{ matrix.arch }}` above does NOT restrict the architecture: the
+      # `arch` list in electron-builder.json5's `mac.target` names both x64 and
+      # arm64 and the config wins, so BOTH bundles are produced in every job —
+      # x64 in release/<ver>/mac/, arm64 in release/<ver>/mac-arm64/. The old
+      # `find release/<ver> ... | head -n1` took whichever came first in
+      # directory order (x64, in practice), so the arm64 job could package the
+      # x64 bundle into a DMG named `-arm64-`. Nothing downstream compared the
+      # name against the contents, so that would have published silently.
       - name: Find .app bundle
         id: find_app
         run: |
           VERSION="${{ steps.version.outputs.version }}"
-          APP_BUNDLE="$(find "release/${VERSION}" -maxdepth 4 -name "*.app" -type d | head -n1)"
+          if [[ "${{ matrix.arch }}" == "arm64" ]]; then ARCH_DIR="mac-arm64"; else ARCH_DIR="mac"; fi
+          APP_BUNDLE="$(find "release/${VERSION}/${ARCH_DIR}" -maxdepth 2 -name "*.app" -type d | head -n1)"
           if [[ -z "$APP_BUNDLE" ]]; then
-            echo "::error::No .app bundle found in release/${VERSION}/"
+            echo "::error::No .app bundle found in release/${VERSION}/${ARCH_DIR}/"
             find "release/${VERSION}" -maxdepth 4 -print || true
             exit 1
           fi
           echo "app_bundle=$APP_BUNDLE" >> "$GITHUB_OUTPUT"
 
+      # The guard for the above: refuse to build a DMG whose name would not
+      # match its contents. An Intel bundle on an Apple Silicon Mac runs under
+      # Rosetta 2 — compositor, encoder and whisper all translated — which is
+      # slow enough to be unusable, so a mislabelled DMG is a real user harm.
+      - name: Verify .app architecture matches the job
+        run: |
+          BIN="${{ steps.find_app.outputs.app_bundle }}/Contents/MacOS/Openscreen"
+          if [[ "${{ matrix.arch }}" == "arm64" ]]; then EXPECTED="arm64"; else EXPECTED="x86_64"; fi
+          ACTUAL="$(lipo -archs "$BIN")"
+          echo "job arch=${{ matrix.arch }}  expected=${EXPECTED}  actual=${ACTUAL}"
+          if [[ " ${ACTUAL} " != *" ${EXPECTED} "* ]]; then
+            echo "::error::The ${{ matrix.arch }} job produced a '${ACTUAL}' bundle — refusing to publish a mislabelled DMG"
+            exit 1
+          fi
+
       - name: Verify .app code signature
         if: steps.signing.outputs.enabled == 'true'
         run: codesign --verify --deep --strict "${{ steps.find_app.outputs.app_bundle }}"
@@ -245,7 +269,17 @@ jobs:
         run: |
           VERSION="${{ steps.version.outputs.version }}"
           ARCH="${{ matrix.arch }}"
-          DMG_NAME="Openscreen-Mac-${ARCH}-${VERSION}.dmg"
+          # Name the DMG after the machine, not the instruction set. "x64" reads
+          # to most people as "the normal 64-bit one" and "arm64" as the exotic
+          # variant, which is exactly backwards on any Mac sold since 2020 — and
+          # picking the wrong one silently costs Rosetta 2. `Intel` and
+          # `Apple-Silicon` are what About This Mac shows the user.
+          case "$ARCH" in
+            arm64) ARCH_LABEL="Apple-Silicon" ;;
+            x64)   ARCH_LABEL="Intel" ;;
+            *)     ARCH_LABEL="$ARCH" ;;
+          esac
+          DMG_NAME="Openscreen-macOS-${ARCH_LABEL}-${VERSION}.dmg"
           RELEASE_DIR="release/${VERSION}"
           DMG_OUTPUT="${RELEASE_DIR}/${DMG_NAME}"
           STAGING="${RELEASE_DIR}/dmg-staging"
@@ -473,3 +507,64 @@ jobs:
               --latest \
               --title "$TAG"
           fi
+
+      - name: Refresh the docs /download page
+        # Only a stable release changes what /releases/latest resolves to, so a
+        # pre-release would rebuild the site to byte-identical output.
+        #
+        # Dispatched against main on purpose: the github-pages environment only
+        # permits `main` to deploy, so docs.yml's old `on: release` trigger ran
+        # with a tag ref and failed its deploy every time. See docs.yml.
+        if: ${{ steps.release.outputs.is_prerelease == 'false' }}
+        timeout-minutes: 20
+        env:
+          GH_TOKEN: ${{ secrets.OPENSCREEN_RELEASE_TOKEN }}
+        run: |
+          latest_dispatch() {
+            gh run list \
+              --repo "$GITHUB_REPOSITORY" \
+              --workflow docs.yml \
+              --event workflow_dispatch \
+              --branch main \
+              --limit 1 \
+              --json databaseId \
+              --jq '.[0].databaseId // empty'
+          }
+
+          # `gh workflow run` prints nothing we can key off, so remember which
+          # dispatch was newest beforehand and wait for a different one to appear.
+          PREVIOUS_RUN_ID="$(latest_dispatch)"
+          gh workflow run docs.yml --ref main --repo "$GITHUB_REPOSITORY"
+
+          RUN_ID=""
+          for _ in $(seq 1 30); do
+            sleep 5
+            CANDIDATE="$(latest_dispatch)"
+            if [[ -n "$CANDIDATE" && "$CANDIDATE" != "$PREVIOUS_RUN_ID" ]]; then
+              RUN_ID="$CANDIDATE"
+              break
+            fi
+          done
+
+          if [[ -z "$RUN_ID" ]]; then
+            echo "::error::Dispatched docs.yml but no new run appeared within 150s"
+            exit 1
+          fi
+
+          gh run watch "$RUN_ID" --repo "$GITHUB_REPOSITORY" --interval 15 || true
+
+          CONCLUSION="$(gh run view "$RUN_ID" --repo "$GITHUB_REPOSITORY" --json conclusion --jq '.conclusion')"
+          case "$CONCLUSION" in
+            success)
+              echo "Docs rebuilt and deployed by run $RUN_ID"
+              ;;
+            cancelled)
+              # docs.yml cancels in-flight runs sharing a ref, so a push to main
+              # landing right now replaces this rebuild with a newer one.
+              echo "::warning::Docs run $RUN_ID was cancelled, most likely superseded by a newer main run"
+              ;;
+            *)
+              echo "::error::Docs run $RUN_ID concluded '$CONCLUSION' - /download may still list the previous release"
+              exit 1
+              ;;
+          esac

.github/workflows/bump-nix-package.yml

@@ -10,9 +10,10 @@ on:
         required: true
         type: string
 
+# GITHUB_TOKEN only pushes the branch here — the PR itself is opened with the
+# PAT below, so no `pull-requests: write` is needed (and it never worked).
 permissions:
   contents: write
-  pull-requests: write
 
 jobs:
   bump:
@@ -78,7 +79,13 @@ jobs:
 
       - name: Create PR
         env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          # NOT GITHUB_TOKEN: the repo has "Allow GitHub Actions to create and
+          # approve pull requests" turned off, so `gh pr create` dies with
+          # "GitHub Actions is not permitted to create or approve pull requests"
+          # — it did exactly that on v1.7.0, after pushing the branch, and #136
+          # had to be opened by hand. The PAT every other release workflow
+          # already uses has no such restriction, and its PRs trigger CI.
+          GH_TOKEN: ${{ secrets.OPENSCREEN_RELEASE_TOKEN }}
           VERSION: ${{ steps.meta.outputs.version }}
           HASH: ${{ steps.hash.outputs.hash }}
           BRANCH: ${{ steps.meta.outputs.branch }}
@@ -112,7 +119,5 @@ jobs:
           - \`npmDepsHash\` → \`${HASH}\` (computed via \`prefetch-npm-deps package-lock.json\`)
 
           Merge this so Nix users (NixOS, Home Manager, \`nix run github:${{ github.repository }}\`) pick up the new release.
-
-          > Note: PRs opened by \`GITHUB_TOKEN\` don't auto-trigger CI. The diff is two lines — review the change here, then merge. If you want CI to run, push an empty commit to this branch or close-and-reopen the PR.
           EOF
           )"

.github/workflows/ci.yml

@@ -190,6 +190,80 @@ jobs:
           cd crates
           cargo check -p openscreen-compositor -p compositor-view-napi --all-targets
 
+  # Le troisieme cote, et le dernier angle mort : le Rust Linux n'etait compile
+  # NULLE PART en CI. Les deux jobs ci-dessus couvrent macOS (test) et Windows
+  # (check) ; `compositor_linux.rs`, `pipeline_linux.rs`, `d3d_linux.rs` et les
+  # 2154 lignes du moteur wgpu ne passaient que par le poste des contributeurs.
+  #
+  # Ce que le trou cachait, trouve en ouvrant ce job : `export_timing.rs` et
+  # `output_geometry_golden.rs` ne compilaient pas sous Linux — ils appellent
+  # `probe_frame_count` / `readback_resized`, qui n'existent que cote Windows et
+  # macOS. Les fichiers de `tests/` etant compiles quelle que soit la plateforme,
+  # le crate entier etait incompilable en `--tests` sur Linux, en silence.
+  #
+  # `cargo test` et pas `check` : `mesa-vulkan-drivers` donne au runner un ICD
+  # Vulkan logiciel (lavapipe), donc `cpu_backend_linux.rs` exerce POUR DE VRAI le
+  # backend CPU, qui est la propriete que cette PR ajoute. Un runner GitHub n'ayant
+  # pas de GPU, c'est meme le seul endroit ou ce chemin est teste sans forcage.
+  rust-linux-compositor-check:
+    name: Rust test (Linux compositor)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      # Pas de ./.github/actions/setup : `fetch-ffmpeg.mjs` n'importe que des
+      # builtins node, donc `npm ci` serait une minute d'installation pour rien.
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: .nvmrc
+      # libclang-dev, pas libclang1 : bindgen a besoin de libclang pour lire les
+      #   headers ffmpeg, et c'est le paquet -dev qui apporte AUSSI les headers
+      #   built-in de clang. Sans eux bindgen echoue sur `stddef.h file not found`.
+      # mesa-vulkan-drivers : l'ICD lavapipe. Sans lui le runner n'a aucun
+      #   adaptateur Vulkan et le backend CPU serait intestable. C'est le meme
+      #   paquet que le .deb declare desormais en dependance (electron-builder.json5).
+      - name: Install libclang and the Mesa Vulkan drivers
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y --no-install-recommends libclang-dev mesa-vulkan-drivers
+      - name: Vendor the pinned ffmpeg SDK
+        run: npm run fetch:ffmpeg:sdk
+      # `crates/.cargo/config.toml` pose FFMPEG_DIR (arbre win64) et LIBCLANG_PATH
+      # (chemin Windows) dans un `[env]` GLOBAL — cargo n'a pas de
+      # `[target.<cfg>.env]`. Les deux valeurs sont donc TOUJOURS renseignees et
+      # fausses ici ; il faut les surcharger par de vraies variables
+      # d'environnement, qui gagnent (`force = false` par defaut).
+      - name: Resolve the toolchain paths
+        run: |
+          echo "FFMPEG_DIR=$GITHUB_WORKSPACE/crates/thirdparty/ffmpeg-linux64-lgpl-shared" >> "$GITHUB_ENV"
+          # `sort -V | tail -1` et pas `find | head -1` : l'image du runner embarque
+          # plusieurs LLVM, et l'ordre de parcours du systeme de fichiers n'est pas
+          # trie -- on pouvait donc tomber sur une version differente de celle
+          # qu'apt vient d'installer. Les headers built-in de clang etant lies a la
+          # version de libclang, le symptome aurait ete `stddef.h file not found`,
+          # qui ne designe pas sa cause. On prend la plus recente, deterministe.
+          libclang=$(ls -1 /usr/lib/llvm-*/lib/libclang.so 2>/dev/null | sort -V | tail -1)
+          # Echouer ici plutot que de laisser bindgen partir sur le chemin Windows
+          # et rendre une erreur qui ne designe pas la cause non plus.
+          test -n "$libclang" || { echo "libclang introuvable apres l'installation"; exit 1; }
+          echo "LIBCLANG_PATH=$(dirname "$libclang")" >> "$GITHUB_ENV"
+      - name: cargo test (compositor)
+        env:
+          # Les .so ffmpeg vendorises ne sont dans aucun chemin systeme : sans ca
+          # le binaire de test se lance puis meurt sur `libavformat.so.62`.
+          LD_LIBRARY_PATH: ${{ github.workspace }}/crates/thirdparty/ffmpeg-linux64-lgpl-shared/lib
+          # Fait ECHOUER `cpu_backend_linux.rs` s'il n'obtient pas le backend CPU,
+          # au lieu de le sauter en silence comme sur un poste sans lavapipe.
+          OPENSCREEN_REQUIRE_CPU_BACKEND: "1"
+        run: |
+          cd crates
+          cargo test -p openscreen-compositor --lib --tests
+      - name: cargo build (napi addon)
+        env:
+          LD_LIBRARY_PATH: ${{ github.workspace }}/crates/thirdparty/ffmpeg-linux64-lgpl-shared/lib
+        run: |
+          cd crates
+          cargo build -p compositor-view-napi --release
+
   semantic-pr:
     name: Validate PR title (semantic)
     runs-on: ubuntu-latest

.github/workflows/docs.yml

@@ -12,13 +12,17 @@ on:
       - "website/**"
       - ".github/workflows/docs.yml"
   # The /download page resolves the current release's assets at build time so it
-  # can link each platform to its actual file. Without this trigger that data
-  # would freeze at whatever the last website/** change saw, and the page would
-  # keep serving the previous version's binaries after every release.
-  # Pre-releases are skipped: /releases/latest ignores them, so the built output
-  # would be byte-identical.
-  release:
-    types: [published]
+  # can link each platform to its actual file. Without a post-release rebuild that
+  # data would freeze at whatever the last website/** change saw, and the page
+  # would keep serving the previous version's binaries after every release.
+  #
+  # That rebuild is a `workflow_dispatch` fired by build.yml once the release is
+  # published, NOT an `on: release` trigger. A release event runs with
+  # github.ref = refs/tags/vX.Y.Z, and the github-pages environment only allows
+  # `main` to deploy, so the deploy job failed on every stable release (it never
+  # surfaced earlier because pre-releases skipped the build entirely). Dispatching
+  # against main both satisfies that policy and publishes main's docs rather than
+  # the release branch's older snapshot.
   workflow_dispatch:
 
 # Cancel in-flight runs on the same ref so fast follow-up pushes
@@ -34,9 +38,6 @@ jobs:
   build:
     name: Build site
     runs-on: ubuntu-latest
-    # A pre-release does not change what /releases/latest resolves to, so
-    # rebuilding for one would burn a run to produce identical output.
-    if: github.event_name != 'release' || github.event.release.prerelease == false
     steps:
       - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
         with:
@@ -66,7 +67,7 @@ jobs:
     needs: build
     if: >-
       (github.event_name == 'push' && github.ref == 'refs/heads/main')
-      || github.event_name == 'release'
+      || (github.event_name == 'workflow_dispatch' && github.ref == 'refs/heads/main')
     environment:
       name: github-pages
       url: ${{ steps.deployment.outputs.page_url }}

.github/workflows/nix-check.yml

@@ -0,0 +1,72 @@
+name: Nix
+
+# nix/package.nix records `npmDepsHash`, a hash of the npm dependency set that
+# package-lock.json resolves to. The two have to agree or `nix build` fails
+# outright, and nothing here ever checked that they did.
+#
+# The only thing that refreshed the hash was bump-nix-package.yml, which fires
+# on stable releases. `src` is this repo's own tree, not a fetched tarball, so
+# every lockfile change landing between two releases left main's hash pointing
+# at dependencies that no longer existed. It last matched on 2026-07-05 (v1.6.0)
+# while package-lock.json moved ten more times, so `nix run github:…` was broken
+# for four weeks with nothing reporting it.
+#
+# Release-time bumps can't fix that — the drift starts the moment a lockfile PR
+# merges. This runs on the PR that causes it and prints the hash to paste.
+on:
+  pull_request:
+    paths:
+      - package-lock.json
+      - nix/**
+      - .github/workflows/nix-check.yml
+  # Same branch list as ci.yml, and for the reason its own comment gives: a
+  # release branch is the last place to skip a check. PRs need no filter here —
+  # the trigger above has none, so they are covered wherever they land — but a
+  # direct push or a rebase force-push onto a long-lived branch is not a PR and
+  # would otherwise go unchecked.
+  push:
+    branches: [main, feat/ai-edition, "release/**"]
+    paths:
+      - package-lock.json
+      - nix/**
+      - .github/workflows/nix-check.yml
+
+# Read-only, and stated rather than inherited: the repo default happens to be
+# `read` today, which is exactly the kind of repo-level setting that silently
+# changed this workflow's sibling out from under it.
+permissions:
+  contents: read
+
+jobs:
+  npm-deps-hash:
+    name: npmDepsHash matches package-lock.json
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: cachix/install-nix-action@v27
+        with:
+          nix_path: nixpkgs=channel:nixos-unstable
+          extra_nix_config: |
+            experimental-features = nix-command flakes
+
+      - name: Compare recorded hash against the lockfile
+        run: |
+          set -euo pipefail
+          EXPECTED=$(nix run nixpkgs#prefetch-npm-deps -- package-lock.json)
+          RECORDED=$(sed -nE 's|^[[:space:]]*npmDepsHash[[:space:]]*=[[:space:]]*"([^"]*)";|\1|p' nix/package.nix)
+
+          echo "recorded in nix/package.nix: ${RECORDED:-<none>}"
+          echo "expected from package-lock.json: $EXPECTED"
+
+          if [[ -z "$EXPECTED" ]]; then
+            echo "::error::prefetch-npm-deps returned an empty hash"
+            exit 1
+          fi
+
+          if [[ "$EXPECTED" != "$RECORDED" ]]; then
+            echo "::error file=nix/package.nix::npmDepsHash is stale — set it to $EXPECTED"
+            exit 1
+          fi
+
+          echo "In sync."