diff --git a/.claude/skills/release/SKILL.md b/.claude/skills/release/SKILL.md
index d96d956..d5f1453 100644
--- a/.claude/skills/release/SKILL.md
+++ b/.claude/skills/release/SKILL.md
@@ -52,7 +52,7 @@ updated: 2026-10-11
    Le script (token `~/.forgejo-token`) lit la release par tag, compte les 7 artefacts **par suffixe** (`.exe` NSIS, `.deb`, `.rpm`, leurs 3 signatures `.sig`, `latest.json` — les noms exacts varient selon la version de Tauri), puis télécharge `latest.json` (il pilote l'auto-update des installations existantes) et vérifie `version` (il affiche `pub_date` et la longueur des notes), puis exige **exactement trois clés** (#320) : `linux-x86_64-deb`, `linux-x86_64-rpm` et `windows-x86_64`, sans clé générique `linux-x86_64` depuis le 2026-10-11 (`docs/qa-update-cycle.md`). Pour chacune : l'extension de l'URL (`.deb`, `.rpm`, `.exe`), une signature non vide dont le `file:` (commentaire de confiance minisign, signature décodée du base64) est le nom de fichier de l'URL, décodé, et la version dans l'URL. **Il sort en 1 sur tout écart** (`MANQUANT`, `VIDE`, `MAUVAISE VERSION`, `MAUVAISE EXTENSION`, `DIFFÉRENT`, `INATTENDUE`) et finit par `VERDICT : OK` ou `VERDICT : ÉCHEC` : pas d'annonce de la release ni d'étape 10 avant un verdict OK. Un second argument (`verify-release.sh vX.Y.Z fichier.json`) contrôle un `latest.json` local au lieu de l'asset, pour éprouver les contrôles sur un fichier fabriqué.
    **Lire aussi l'étape « Generate latest.json » du journal du run** (même route web que ci-dessous) : `scripts/build-latest-json.sh` y nomme le paquet retenu pour chaque type (`build-latest-json: .rpm <- …`), puis le `latest.json` généré est affiché. Le script et le filtre `scripts/check-latest-json.jq` passent par les tests de `check-frontend` à chaque PR ; leur appel par `release.yml` et le délimiteur aléatoire des notes ne s'exercent qu'au tag. Un manifeste refusé par le filtre arrête le job sur `ERROR: release-assets/latest.json failed scripts/check-latest-json.jq`, avant le `DELETE` : registre intact, et la release Forgejo reste créée sans mise à jour servie.
    Durée observée du run : 22 à 30 min sur les 12 dernières releases — poser le `Monitor` puis passer à autre chose.
-   **Lire aussi le Node.js du run.** `release.yml` n'est exercé qu'au tag : une montée de Node (Node 20 → 24 par #376) ne se prouve que dans ce journal. Il passe par la route web (l'API v1 des journaux répond 404). Le `run_number` vient de `/actions/tasks`, qui rend toute la liste, la plus récente en tête (le paramètre `limit` y est ignoré) :
+   **Lire aussi le Node.js du run.** `release.yml` n'est exercé qu'au tag : une montée de Node (Node 20 → 24 par #376) ne se prouve que dans ce journal. Il passe par la route web (l'API v1 des journaux répond 404). Le `run_number` vient de `/actions/tasks` : sans paramètre `page`, la route rend toute la liste, la plus récente en tête, et ignore `limit` (avec `page`, elle pagine par 30 ou par `limit`, mesuré le 2026-10-12) :
    ```bash
    TAG=vX.Y.Z
    RUN=$(curl -s -H "Authorization: token $(cat ~/.forgejo-token)" \
diff --git a/.forgejo/workflows/audit.yml b/.forgejo/workflows/audit.yml
index cbf7f30..661abe8 100644
--- a/.forgejo/workflows/audit.yml
+++ b/.forgejo/workflows/audit.yml
@@ -28,7 +28,9 @@ on:
   workflow_dispatch:
 
 # What this key does on Forgejo 8.0.3: see the comment on `concurrency` in
-# check-rust.yml (#376).
+# check-rust.yml (#376). That measurement covers push and pull_request runs;
+# this workflow only runs on schedule and workflow_dispatch, which it does
+# not cover.
 concurrency:
   group: ci-audit-${{ github.ref }}
   cancel-in-progress: true
diff --git a/src/services/reportService.test.ts b/src/services/reportService.test.ts
index a35735d..d1ea76e 100644
--- a/src/services/reportService.test.ts
+++ b/src/services/reportService.test.ts
@@ -719,7 +719,8 @@ describe("real-vs-real compare — transfer netting (Issue #243)", () => {
   // income/transfer credits are not dropped before they can count or cancel.
   //
   // There is no runnable SQLite in these unit tests (tauri-plugin-sql only
-  // exists inside the Tauri WebView, and CI runs Node 20 → no node:sqlite), so
+  // exists inside the Tauri WebView, and no harness opens node:sqlite yet:
+  // CI runs Node 24 since #376, which has it, and #392 plans that harness), so
   // the netting is pinned two ways: (1) a reference-semantics check over
   // concrete debit/credit rows that reproduces the exact per-row rule the SQL
   // encodes, and (2) structural assertions that the real query on BOTH compare