maximus/Simpl-Resultat
1
0
Fork 0
Code Issues 19 Pull requests 8 Projects Releases 34 Packages Wiki Activity Actions

fix(deps): refresh npm lock to clear 8 advisories #417

Merged
maximus merged 1 commit from issue-358-npm-lock-refresh into main 2026-10-12 19:32:53 +00:00
Conversation 3 Commits 1 Files changed 5 +97 -88
maximus commented 2026-10-11 01:16:11 +00:00
Owner
Copy link

Resolves #358
Resolves #317
Generated autonomously by /autopilot run of 2026-10-10

Dernier maillon, PR empilée sur #416 (#320), #415 (#345) puis #414 (#376) : elle ne montre que son propre diff.

Ce qui change

  • package-lock.json rafraîchi : les 8 vulnérabilités que remontait npm audit (5 high, 3 moderate) sont corrigées, npm audit passe à 0. package.json est inchangé : chaque correctif tient dans la borne déjà déclarée.
  • #317 se ferme avec cette PR : l'advisory react-router acceptée depuis #311 (GHSA-qwww-vcr4-c8h2) est corrigée par react-router 7.18.2, un bump de patch dans ^7.18.1, sans migration v8.
  • CLAUDE.md (section CI/CD) et docs/architecture.md (section check-frontend.yml) : plus de « 2 high en permanence », plus de renvoi à #317. Ils disent « npm audit à 0 au 2026-10-10 (#358) », présenté comme un constat daté que rien ne réévalue en CI ; la précision « aucune étape npm audit en CI » est gardée.
  • CHANGELOG EN/FR : entrée ### Security / ### Sécurité sous [Unreleased] / [Non publié], après le ### Fixed / ### Corrigé de #320.

Technique

npm 11.21.0 exactement (npx --yes npm@11.21.0), Node 22.22.0 en local. Commande, telle que planifiée :

npx --yes npm@11.21.0 update react-router-dom react-router vitest @vitest/mocker browserslist baseline-browser-mapping nanoid source-map-js --package-lock-only --ignore-scripts

lockfileVersion 3 → 3 ; 259 → 259 entrées ; entrée racine identique ; 20 entrées modifiées, aucune ajoutée ni retirée.

Paquet Avant Après Rôle
react-router 7.18.1 7.18.4 runtime, bundlé ; GHSA-qwww-vcr4-c8h2
react-router-dom 7.18.1 7.18.4 runtime, dépendance directe ; même advisory
vitest 4.1.9 4.1.11 test, dépendance directe ; GHSA-82fw-gwwq-j7x9
@vitest/mocker 4.1.9 4.1.11 test ; même advisory
@vitest/expect, @vitest/pretty-format, @vitest/runner, @vitest/snapshot, @vitest/spy, @vitest/utils 4.1.9 4.1.11 test ; compagnons de borne de vitest
chai 6.2.2 6.3.0 test ; seul dépendant @vitest/expect, borne ^6.2.2
tinyrainbow 3.1.0 3.2.0 test ; compagnon
browserslist 4.28.4 4.29.3 build ; GHSA-c83g-rgw3-j3cx, GHSA-73wf-gq98-2v4g
baseline-browser-mapping 2.10.41 2.11.28 build ; GHSA-w5vr-8v7q-w6rv
caniuse-lite 1.0.30001800 1.0.30001815 build ; compagnon de browserslist
electron-to-chromium 1.5.384 1.5.452 build ; compagnon
node-releases 2.0.50 2.0.58 build ; compagnon
update-browserslist-db 1.2.3 1.3.4 build ; compagnon
nanoid 3.3.16 3.3.20 build, via postcss ; GHSA-2v37-7h3g-55p8
source-map-js 1.2.1 1.2.2 build, via postcss et @tailwindcss/node ; GHSA-68fv-2mgg-jv7q

Écarts avec l'issue, tous dans les bornes déclarées :

  • Trois versions plus récentes que la table du 2026-09-26 : browserslist 4.29.3 (table 4.29.1 ; publiée le 09-29), baseline-browser-mapping 2.11.28 (table 2.11.26 ; publiée le 10-08), nanoid 3.3.20 (table 3.3.19 ; publiée le 10-05). La planification fixe la commande, pas les versions ; retrouver la table demanderait des overrides sur des transitives, hors périmètre.
  • 20 entrées changées contre 18 mesurées le 09-26 : source-map-js (8e advisory, ajoutée à la commande le 10-10) et chai 6.3.0, publiée le 09-30 et re-résolue par npm quand @vitest/expect, son seul dépendant, est remplacé.
  • Le titre du commit compte 8, comme npm audit (8 vulnérabilités). Elles viennent de 7 GHSA distinctes : react-router/react-router-dom partagent la leur, vitest/@vitest/mocker aussi.
  • La ligne de plus du lock (87+/86−) : l'entrée source-map-js 1.2.2 porte "license": "BSD-3-Clause", absent de l'entrée 1.2.1.

Preuves

npm audit avant (lock de la base, identique à celui de main, npm 10.9.4), résumé de npm audit --json, tous fixAvailable: true :

8 vulnerabilities (3 moderate, 5 high)
@vitest/mocker            moderate  GHSA-82fw-gwwq-j7x9
baseline-browser-mapping  moderate  GHSA-w5vr-8v7q-w6rv
browserslist              high      GHSA-c83g-rgw3-j3cx, GHSA-73wf-gq98-2v4g
nanoid                    high      GHSA-2v37-7h3g-55p8
react-router              high      GHSA-qwww-vcr4-c8h2 (>=7.12.0 <7.18.2)
react-router-dom          high      via react-router
source-map-js             high      GHSA-68fv-2mgg-jv7q
vitest                    moderate  via @vitest/mocker, GHSA-82fw-gwwq-j7x9

npm audit après, relancé juste avant le commit (2026-10-10 21:13:59 EDT), après npm ci sous npm 10.9.4 :

found 0 vulnerabilities

resolved / integrity (script Python comparant les deux locks) :

lockfileVersion 3 -> 3
entries 259 -> 259
added keys: []
removed keys: []
root entry identical: True
changed entries: 20
changed-entry problems: none

Chacune des 20 entrées modifiées a un resolved en https://registry.npmjs.org/ et un integrity sha512- différent de l'ancien. Sur tout le lock, les 6 seules entrées sans ces champs sont les dépendances embarquées (inBundle) de @tailwindcss/oxide-wasm32-wasi, livrées dans l'archive de leur parent et inchangées. En complément, npm audit signatures : « 175 packages have verified registry signatures, 71 packages have verified attestations ».

npm ci sans réécriture : empreinte du lock identique avant et après (752e8d8…), git diff identique octet pour octet, sous npm 10.9.4 comme sous npm 11.19.0 (celui de la CI). Sous npm 11.19.0, l'avertissement npm warn install-scripts … esbuild@0.25.12 (postinstall: node install.js) reste le seul et ne change pas : esbuild n'est pas touché, et aucune entrée modifiée n'a de script d'installation.

Build et tests : npm run build vert ; npm test : 110 fichiers / 1915 tests, avant (vitest 4.1.9) comme après (vitest 4.1.11), journaux identiques hors version et durées.

diff -r dist/ : deux builds de la référence sont identiques entre eux (build déterministe). Après le lock :

Only in ref/assets: index-D8mOfrMJ.js    (1 743 044 octets)
Only in dist/assets: index-DjjeOWRp.js   (1 744 030 octets)
Files ref/index.html and dist/index.html differ    (nom du bundle seulement)

La CSS (index-CSFhII2z.css) et icon.svg sont identiques. Avec les CHANGELOG de ce commit, les copies dist/CHANGELOG*.md diffèrent aussi ; elles égalent les fichiers de la branche.

Explication de l'écart : un build intermédiaire, fait dans une copie git archive sous /tmp, (1) reproduit la référence octet pour octet sur le lock d'origine (témoin), puis (2) sur une copie du lock d'origine où seuls react-router-dom react-router sont mis à jour (même commande npm 11.21.0 ; 2 entrées, identiques à celles du lock complet), égale le build du lock complet octet pour octet. Les 18 autres mises à jour (test et build) ne changent donc rien à la sortie : tout l'écart est le code de react-router 7.18.1 → 7.18.4. Comparé instruction par instruction, identifiants minifiés neutralisés, il contient seulement :

  • les chaînes de version (en-tête de licence, window.__reactRouterVersion) ;
  • removeTrailingSlash réécrite (même résultat, plus rapide sur les longs chemins ; 7.18.3) ;
  • resolveTo, qui traite un \ initial comme un chemin absolu (7.18.3) ;
  • validateNavigationTarget et ses aides, appelée par useNavigate(), <Navigate> et la redirection RSC de la frontière d'erreur : elle lève « External navigation is not allowed » pour une cible d'une autre origine (7.18.3, « additional URL validation on client side navigations/redirects »).

Le reste n'est que des renommages du minifieur. Les archives react-router 7.18.1 et 7.18.4 récupérées par npm pack pour lire ce diff correspondent à l'integrity des deux locks. Le code RSC et serveur de ces versions (CSRF, meta refresh) et celui des data routers (startViewTransition) sont absents des deux bundles.

Navigation sous les origines de l'app : l'origine Linux tauri://localhost est opaque (URL.origin === "null"), donc j'ai vérifié le nouveau contrôle sur le code réel de 7.18.4 (script jetable, hors dépôt) : createBrowserHistory sur une fenêtre simulée, comme le construit BrowserRouter, sous 4 origines (Linux tauri://localhost avec location.origin à "null" ou en tuple, Windows http://tauri.localhost, dev http://localhost:1420), pour 24 cibles internes de la forme de celles de src/ et 3 cibles externes témoins, plus <Navigate> rendu par react-dom/server :

react-router 7.18.4 (chunk-OB3PAWPO.mjs): 120 checks, 0 failures

Les cibles internes passent partout, les externes sont refusées partout : quand l'origine vaut "null", react-router compare protocole et hôte. Les sources de l'app ne naviguent que vers des chemins internes (relevé de navigate(, <Navigate> et to=).

Pour relire en priorité

  1. Le seul code livré qui change est celui de react-router (prouvé par le build intermédiaire) : la validation de navigation de 7.18.3 lève une erreur sur une cible d'une autre origine. Elle est vérifiée par script, pas dans l'app lancée ; quelques clics dans l'app sous Linux et sous Windows le confirmeraient : liens de la barre latérale, lien de l'étape suivante dans le bandeau de démarrage, et les redirections /docs et /changelog (<Navigate>).
  2. baseline-browser-mapping 2.11.28 avait deux jours à la génération du lock (publiée le 2026-10-08) : données de build seulement, absentes du bundle.
  3. La CI check-frontend doit montrer npm ci sous npm 11.19.0 sans erreur, le même unique avertissement install-scripts (esbuild), le build vert et 110 fichiers / 1915 tests.
  4. STATE.md n'est pas touché : son chapeau (« 2 restantes, acceptées ») revient à la synchro post-merge, comme prévu au plan.

🤖 Generated with Claude Code

Resolves #358 Resolves #317 Generated autonomously by /autopilot run of 2026-10-10 > Dernier maillon, PR empilée sur #416 (#320), #415 (#345) puis #414 (#376) : elle ne montre que son propre diff. ## Ce qui change - `package-lock.json` rafraîchi : les 8 vulnérabilités que remontait `npm audit` (5 high, 3 moderate) sont corrigées, `npm audit` passe à 0. `package.json` est inchangé : chaque correctif tient dans la borne déjà déclarée. - #317 se ferme avec cette PR : l'advisory `react-router` acceptée depuis #311 (GHSA-qwww-vcr4-c8h2) est corrigée par `react-router` 7.18.2, un bump de patch dans `^7.18.1`, sans migration v8. - `CLAUDE.md` (section CI/CD) et `docs/architecture.md` (section `check-frontend.yml`) : plus de « 2 high en permanence », plus de renvoi à #317. Ils disent « `npm audit` à 0 au 2026-10-10 (#358) », présenté comme un constat daté que rien ne réévalue en CI ; la précision « aucune étape `npm audit` en CI » est gardée. - CHANGELOG EN/FR : entrée `### Security` / `### Sécurité` sous `[Unreleased]` / `[Non publié]`, après le `### Fixed` / `### Corrigé` de #320. ## Technique npm **11.21.0** exactement (`npx --yes npm@11.21.0`), Node 22.22.0 en local. Commande, telle que planifiée : ``` npx --yes npm@11.21.0 update react-router-dom react-router vitest @vitest/mocker browserslist baseline-browser-mapping nanoid source-map-js --package-lock-only --ignore-scripts ``` `lockfileVersion` 3 → 3 ; 259 → 259 entrées ; entrée racine identique ; 20 entrées modifiées, aucune ajoutée ni retirée. | Paquet | Avant | Après | Rôle | |---|---|---|---| | `react-router` | 7.18.1 | 7.18.4 | runtime, bundlé ; GHSA-qwww-vcr4-c8h2 | | `react-router-dom` | 7.18.1 | 7.18.4 | runtime, dépendance directe ; même advisory | | `vitest` | 4.1.9 | 4.1.11 | test, dépendance directe ; GHSA-82fw-gwwq-j7x9 | | `@vitest/mocker` | 4.1.9 | 4.1.11 | test ; même advisory | | `@vitest/expect`, `@vitest/pretty-format`, `@vitest/runner`, `@vitest/snapshot`, `@vitest/spy`, `@vitest/utils` | 4.1.9 | 4.1.11 | test ; compagnons de borne de vitest | | `chai` | 6.2.2 | 6.3.0 | test ; seul dépendant `@vitest/expect`, borne `^6.2.2` | | `tinyrainbow` | 3.1.0 | 3.2.0 | test ; compagnon | | `browserslist` | 4.28.4 | 4.29.3 | build ; GHSA-c83g-rgw3-j3cx, GHSA-73wf-gq98-2v4g | | `baseline-browser-mapping` | 2.10.41 | 2.11.28 | build ; GHSA-w5vr-8v7q-w6rv | | `caniuse-lite` | 1.0.30001800 | 1.0.30001815 | build ; compagnon de browserslist | | `electron-to-chromium` | 1.5.384 | 1.5.452 | build ; compagnon | | `node-releases` | 2.0.50 | 2.0.58 | build ; compagnon | | `update-browserslist-db` | 1.2.3 | 1.3.4 | build ; compagnon | | `nanoid` | 3.3.16 | 3.3.20 | build, via `postcss` ; GHSA-2v37-7h3g-55p8 | | `source-map-js` | 1.2.1 | 1.2.2 | build, via `postcss` et `@tailwindcss/node` ; GHSA-68fv-2mgg-jv7q | Écarts avec l'issue, tous dans les bornes déclarées : - Trois versions plus récentes que la table du 2026-09-26 : `browserslist` 4.29.3 (table 4.29.1 ; publiée le 09-29), `baseline-browser-mapping` 2.11.28 (table 2.11.26 ; publiée le 10-08), `nanoid` 3.3.20 (table 3.3.19 ; publiée le 10-05). La planification fixe la commande, pas les versions ; retrouver la table demanderait des overrides sur des transitives, hors périmètre. - 20 entrées changées contre 18 mesurées le 09-26 : `source-map-js` (8e advisory, ajoutée à la commande le 10-10) et `chai` 6.3.0, publiée le 09-30 et re-résolue par npm quand `@vitest/expect`, son seul dépendant, est remplacé. - Le titre du commit compte 8, comme `npm audit` (8 vulnérabilités). Elles viennent de 7 GHSA distinctes : `react-router`/`react-router-dom` partagent la leur, `vitest`/`@vitest/mocker` aussi. - La ligne de plus du lock (87+/86−) : l'entrée `source-map-js` 1.2.2 porte `"license": "BSD-3-Clause"`, absent de l'entrée 1.2.1. ## Preuves **`npm audit` avant** (lock de la base, identique à celui de `main`, npm 10.9.4), résumé de `npm audit --json`, tous `fixAvailable: true` : ``` 8 vulnerabilities (3 moderate, 5 high) @vitest/mocker moderate GHSA-82fw-gwwq-j7x9 baseline-browser-mapping moderate GHSA-w5vr-8v7q-w6rv browserslist high GHSA-c83g-rgw3-j3cx, GHSA-73wf-gq98-2v4g nanoid high GHSA-2v37-7h3g-55p8 react-router high GHSA-qwww-vcr4-c8h2 (>=7.12.0 <7.18.2) react-router-dom high via react-router source-map-js high GHSA-68fv-2mgg-jv7q vitest moderate via @vitest/mocker, GHSA-82fw-gwwq-j7x9 ``` **`npm audit` après**, relancé juste avant le commit (2026-10-10 21:13:59 EDT), après `npm ci` sous npm 10.9.4 : ``` found 0 vulnerabilities ``` **`resolved` / `integrity`** (script Python comparant les deux locks) : ``` lockfileVersion 3 -> 3 entries 259 -> 259 added keys: [] removed keys: [] root entry identical: True changed entries: 20 changed-entry problems: none ``` Chacune des 20 entrées modifiées a un `resolved` en `https://registry.npmjs.org/` et un `integrity` `sha512-` différent de l'ancien. Sur tout le lock, les 6 seules entrées sans ces champs sont les dépendances embarquées (`inBundle`) de `@tailwindcss/oxide-wasm32-wasi`, livrées dans l'archive de leur parent et inchangées. En complément, `npm audit signatures` : « 175 packages have verified registry signatures, 71 packages have verified attestations ». **`npm ci` sans réécriture** : empreinte du lock identique avant et après (`752e8d8…`), `git diff` identique octet pour octet, sous npm 10.9.4 comme sous npm 11.19.0 (celui de la CI). Sous npm 11.19.0, l'avertissement `npm warn install-scripts … esbuild@0.25.12 (postinstall: node install.js)` reste le seul et ne change pas : `esbuild` n'est pas touché, et aucune entrée modifiée n'a de script d'installation. **Build et tests** : `npm run build` vert ; `npm test` : 110 fichiers / 1915 tests, avant (vitest 4.1.9) comme après (vitest 4.1.11), journaux identiques hors version et durées. **`diff -r dist/`** : deux builds de la référence sont identiques entre eux (build déterministe). Après le lock : ``` Only in ref/assets: index-D8mOfrMJ.js (1 743 044 octets) Only in dist/assets: index-DjjeOWRp.js (1 744 030 octets) Files ref/index.html and dist/index.html differ (nom du bundle seulement) ``` La CSS (`index-CSFhII2z.css`) et `icon.svg` sont identiques. Avec les CHANGELOG de ce commit, les copies `dist/CHANGELOG*.md` diffèrent aussi ; elles égalent les fichiers de la branche. Explication de l'écart : un build intermédiaire, fait dans une copie `git archive` sous `/tmp`, (1) reproduit la référence octet pour octet sur le lock d'origine (témoin), puis (2) sur une copie du lock d'origine où seuls `react-router-dom react-router` sont mis à jour (même commande npm 11.21.0 ; 2 entrées, identiques à celles du lock complet), **égale le build du lock complet octet pour octet**. Les 18 autres mises à jour (test et build) ne changent donc rien à la sortie : tout l'écart est le code de react-router 7.18.1 → 7.18.4. Comparé instruction par instruction, identifiants minifiés neutralisés, il contient seulement : - les chaînes de version (en-tête de licence, `window.__reactRouterVersion`) ; - `removeTrailingSlash` réécrite (même résultat, plus rapide sur les longs chemins ; 7.18.3) ; - `resolveTo`, qui traite un `\` initial comme un chemin absolu (7.18.3) ; - `validateNavigationTarget` et ses aides, appelée par `useNavigate()`, `<Navigate>` et la redirection RSC de la frontière d'erreur : elle lève « External navigation is not allowed » pour une cible d'une autre origine (7.18.3, « additional URL validation on client side navigations/redirects »). Le reste n'est que des renommages du minifieur. Les archives `react-router` 7.18.1 et 7.18.4 récupérées par `npm pack` pour lire ce diff correspondent à l'`integrity` des deux locks. Le code RSC et serveur de ces versions (CSRF, `meta refresh`) et celui des data routers (`startViewTransition`) sont absents des deux bundles. **Navigation sous les origines de l'app** : l'origine Linux `tauri://localhost` est opaque (`URL.origin === "null"`), donc j'ai vérifié le nouveau contrôle sur le code réel de 7.18.4 (script jetable, hors dépôt) : `createBrowserHistory` sur une fenêtre simulée, comme le construit `BrowserRouter`, sous 4 origines (Linux `tauri://localhost` avec `location.origin` à `"null"` ou en tuple, Windows `http://tauri.localhost`, dev `http://localhost:1420`), pour 24 cibles internes de la forme de celles de `src/` et 3 cibles externes témoins, plus `<Navigate>` rendu par `react-dom/server` : ``` react-router 7.18.4 (chunk-OB3PAWPO.mjs): 120 checks, 0 failures ``` Les cibles internes passent partout, les externes sont refusées partout : quand l'origine vaut `"null"`, react-router compare protocole et hôte. Les sources de l'app ne naviguent que vers des chemins internes (relevé de `navigate(`, `<Navigate>` et `to=`). ## Pour relire en priorité 1. **Le seul code livré qui change est celui de react-router** (prouvé par le build intermédiaire) : la validation de navigation de 7.18.3 lève une erreur sur une cible d'une autre origine. Elle est vérifiée par script, pas dans l'app lancée ; quelques clics dans l'app sous Linux et sous Windows le confirmeraient : liens de la barre latérale, lien de l'étape suivante dans le bandeau de démarrage, et les redirections `/docs` et `/changelog` (`<Navigate>`). 2. `baseline-browser-mapping` 2.11.28 avait deux jours à la génération du lock (publiée le 2026-10-08) : données de build seulement, absentes du bundle. 3. La CI `check-frontend` doit montrer `npm ci` sous npm 11.19.0 sans erreur, le même unique avertissement `install-scripts` (`esbuild`), le build vert et 110 fichiers / 1915 tests. 4. `STATE.md` n'est pas touché : son chapeau (« 2 restantes, acceptées ») revient à la synchro post-merge, comme prévu au plan. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
maximus added 1 commit 2026-10-11 01:16:12 +00:00
fix(deps): refresh npm lock to clear 8 advisories
All checks were successful
PR Check — Frontend / frontend (pull_request) Successful in 1m53s
Details
e8306aa260 
npm audit reported 8 vulnerabilities (5 high, 3 moderate) on the lock
of main: react-router and react-router-dom (one advisory,
GHSA-qwww-vcr4-c8h2), vitest and @vitest/mocker (one advisory,
GHSA-82fw-gwwq-j7x9), browserslist, baseline-browser-mapping, nanoid
and source-map-js. Every fix sits within the range package.json
already declares, so only the lock moves; package.json is untouched.

Lock generated with npm 11.21.0 exactly:

  npx --yes npm@11.21.0 update react-router-dom react-router vitest \
    @vitest/mocker browserslist baseline-browser-mapping nanoid \
    source-map-js --package-lock-only --ignore-scripts

259 entries before and after, 20 changed, each resolved from
registry.npmjs.org with a new sha512 integrity. npm ci, under npm 10
and under npm 11.19.0, leaves the lock as is; npm audit: 0.

Only react-router 7.18.1 -> 7.18.4 changes the built app: a build from
a lock where only react-router moved equals the full build byte for
byte. Since 7.18.3, useNavigate() and <Navigate> reject a navigation
to another origin; the app only navigates to internal paths.

CLAUDE.md and docs/architecture.md no longer describe 2 high
advisories accepted for good: npm audit is at 0 on 2026-10-10, a
dated reading that nothing re-runs in CI.

Resolves #358
Resolves #317

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
maximus commented 2026-10-11 01:17:35 +00:00
Author
Owner
Copy link

Auto-revue du worker autopilot — verdict : APPROVE

Auto-revue de l'auteur, pas une revue indépendante : seul un /pr-review de la session principale peut poser status:approved.

Relu sur le diff de la PR (e8306aa, 5 fichiers, +97/−88) : chacune des 20 entrées du lock dont la version change, les deux phrases de docs et les deux entrées de CHANGELOG, contre les critères de planification de #358.

Critères de planification

Critère Preuve
Lock généré avec npm@11.21.0 exactement, version consignée Commande telle que planifiée, npx --yes npm@11.21.0, citée dans le commit et la PR (section Technique).
Chaque nouveau resolved vers https://registry.npmjs.org/ avec integrity Script : 20 entrées modifiées, aucun problème ; integrity sha512- neuf partout. Vérifié en plus à la relecture : chaque resolved modifié vaut exactement registry.npmjs.org/<nom>/-/<nom>-<version>.tgz de son entrée (0 écart), npm ls --all sort en 0, et les archives react-router 7.18.1 et 7.18.4 téléchargées correspondent à l'integrity des deux locks.
npm audit relancé juste avant le commit, 0, sortie collée « found 0 vulnerabilities » à 21:13:59 EDT, après npm ci sous npm 10.9.4 ; commit à 21:14:34. Aucune nouvelle advisory apparue entre-temps.
diff -r dist/ identique ou écart expliqué Écart = bundle JS + son nom dans index.html, entièrement dû à react-router 7.18.1 → 7.18.4 : le build d'un lock où seul react-router bouge égale le build complet octet pour octet (témoin de la copie : référence reproduite à l'identique).
Docs : « npm audit à 0 au (#358) », plus de « 2 high acceptés », plus de renvoi à #317, « aucun npm audit en CI » gardé CLAUDE.md l. 166 et docs/architecture.md l. 604 : conformes. git grep ne trouve plus de mention périmée hors STATE.md (laissé à la synchro post-merge).
CHANGELOG Security / Sécurité (aucune advisory atteignable) ; commit Resolves #358 + Resolves #317 Entrées EN/FR sous [Unreleased] / [Non publié], après Fixed / Corrigé, terminées par (#358). Les deux Resolves sont dans le commit et en tête du corps de la PR.

Critères d'origine de l'issue : package.json inchangé (empreinte identique), 259 → 259 entrées, lockfileVersion 3, npm ci (npm 10 et npm 11.19.0) sans réécriture du lock, build vert, 110 fichiers / 1915 tests en local avant et après.

Vérifié à la relecture sur mes propres affirmations

  • Les trois changements de react-router présents dans le bundle (validateNavigationTarget, removeTrailingSlash, \ initial absolu dans resolveTo) apparaissent tous en 7.18.3, contrôlé sur les archives 7.18.1 à 7.18.4 : l'attribution du commit et de la PR est exacte. Le correctif de GHSA-qwww-vcr4-c8h2 est en 7.18.2 (plage npm audit <7.18.2).
  • La phrase CHANGELOG « navigation behaves as before » repose sur le contrôle à 120 cas sous les quatre origines (0 échec) et sur le relevé des cibles de src/, toutes internes.

Ce que la CI doit encore montrer

check-frontend run 520 sur e8306aa (en attente à l'écriture) : npm ci sous Node 24 / npm 11.19.0 sans erreur, le même unique npm warn install-scripts … esbuild@0.25.12, npm run build vert, 110 fichiers / 1915 tests. Pas de check-rust attendu : rien sous src-tauri/ ni .cargo/.

Pour relire en priorité

  1. Le seul code livré qui change est celui de react-router : la validation de navigation lève une erreur pour une cible d'une autre origine. Elle est prouvée par script, pas dans l'app lancée : quelques clics sous Linux (tauri://localhost, origine opaque) et sous Windows lèveraient le dernier doute (barre latérale, lien d'étape du bandeau de démarrage, redirections /docs et /changelog).
  2. Versions plus récentes que la table de l'issue (browserslist 4.29.3, baseline-browser-mapping 2.11.28, nanoid 3.3.20) et deux compagnons de plus (source-map-js, chai 6.3.0) : tous dans les bornes, publiés après l'analyse du 09-26 ; baseline-browser-mapping 2.11.28 avait deux jours.
  3. Titre du commit à 8 (compte npm audit) pour 7 GHSA distinctes : les paires sont nommées dans le commit et la PR.
## Auto-revue du worker autopilot — verdict : APPROVE > Auto-revue de l'auteur, **pas une revue indépendante** : seul un `/pr-review` de la session principale peut poser `status:approved`. Relu sur le diff de la PR (`e8306aa`, 5 fichiers, +97/−88) : chacune des 20 entrées du lock dont la version change, les deux phrases de docs et les deux entrées de CHANGELOG, contre les critères de planification de #358. ### Critères de planification | Critère | Preuve | |---|---| | Lock généré avec `npm@11.21.0` exactement, version consignée | Commande telle que planifiée, `npx --yes npm@11.21.0`, citée dans le commit et la PR (section Technique). | | Chaque nouveau `resolved` vers `https://registry.npmjs.org/` avec `integrity` | Script : 20 entrées modifiées, aucun problème ; `integrity` `sha512-` neuf partout. Vérifié en plus à la relecture : chaque `resolved` modifié vaut exactement `registry.npmjs.org/<nom>/-/<nom>-<version>.tgz` de son entrée (0 écart), `npm ls --all` sort en 0, et les archives react-router 7.18.1 et 7.18.4 téléchargées correspondent à l'`integrity` des deux locks. | | `npm audit` relancé juste avant le commit, 0, sortie collée | « found 0 vulnerabilities » à 21:13:59 EDT, après `npm ci` sous npm 10.9.4 ; commit à 21:14:34. Aucune nouvelle advisory apparue entre-temps. | | `diff -r dist/` identique ou écart expliqué | Écart = bundle JS + son nom dans `index.html`, entièrement dû à react-router 7.18.1 → 7.18.4 : le build d'un lock où seul react-router bouge égale le build complet octet pour octet (témoin de la copie : référence reproduite à l'identique). | | Docs : « `npm audit` à 0 au <date> (#358) », plus de « 2 high acceptés », plus de renvoi à #317, « aucun `npm audit` en CI » gardé | `CLAUDE.md` l. 166 et `docs/architecture.md` l. 604 : conformes. `git grep` ne trouve plus de mention périmée hors `STATE.md` (laissé à la synchro post-merge). | | CHANGELOG Security / Sécurité (aucune advisory atteignable) ; commit `Resolves #358` + `Resolves #317` | Entrées EN/FR sous `[Unreleased]` / `[Non publié]`, après `Fixed` / `Corrigé`, terminées par `(#358)`. Les deux `Resolves` sont dans le commit et en tête du corps de la PR. | Critères d'origine de l'issue : `package.json` inchangé (empreinte identique), 259 → 259 entrées, `lockfileVersion` 3, `npm ci` (npm 10 et npm 11.19.0) sans réécriture du lock, build vert, 110 fichiers / 1915 tests en local avant et après. ### Vérifié à la relecture sur mes propres affirmations - Les trois changements de react-router présents dans le bundle (`validateNavigationTarget`, `removeTrailingSlash`, `\` initial absolu dans `resolveTo`) apparaissent tous en **7.18.3**, contrôlé sur les archives 7.18.1 à 7.18.4 : l'attribution du commit et de la PR est exacte. Le correctif de GHSA-qwww-vcr4-c8h2 est en 7.18.2 (plage `npm audit` `<7.18.2`). - La phrase CHANGELOG « navigation behaves as before » repose sur le contrôle à 120 cas sous les quatre origines (0 échec) et sur le relevé des cibles de `src/`, toutes internes. ### Ce que la CI doit encore montrer `check-frontend` run 520 sur `e8306aa` (en attente à l'écriture) : `npm ci` sous Node 24 / npm 11.19.0 sans erreur, le même unique `npm warn install-scripts … esbuild@0.25.12`, `npm run build` vert, 110 fichiers / 1915 tests. Pas de `check-rust` attendu : rien sous `src-tauri/` ni `.cargo/`. ### Pour relire en priorité 1. Le seul code livré qui change est celui de react-router : la validation de navigation lève une erreur pour une cible d'une autre origine. Elle est prouvée par script, pas dans l'app lancée : quelques clics sous Linux (`tauri://localhost`, origine opaque) et sous Windows lèveraient le dernier doute (barre latérale, lien d'étape du bandeau de démarrage, redirections `/docs` et `/changelog`). 2. Versions plus récentes que la table de l'issue (`browserslist` 4.29.3, `baseline-browser-mapping` 2.11.28, `nanoid` 3.3.20) et deux compagnons de plus (`source-map-js`, `chai` 6.3.0) : tous dans les bornes, publiés après l'analyse du 09-26 ; `baseline-browser-mapping` 2.11.28 avait deux jours. 3. Titre du commit à 8 (compte `npm audit`) pour 7 GHSA distinctes : les paires sont nommées dans le commit et la PR.
maximus added the
autopilot:pending-human
 label 2026-10-11 01:17:42 +00:00
maximus commented 2026-10-11 01:19:11 +00:00
Author
Owner
Copy link

CI lue par la session principale du run autopilot (pas une revue)

Run Commit Résultat Lu dans le journal
520 e8306aa (tête) vert, 1 min 53 s v24.21.0, npm 11.19.0, npm ci : « found 0 vulnerabilities » ; vitest v4.1.11 ; build vert ; 1915 tests (110 fichiers)

Preuve indépendante du passage de 8 à 0, lue dans la CI elle-même : le résumé d'audit de npm ci affichait « 8 vulnerabilities (3 moderate, 5 high) » aux runs 512 et 519 (lock de main), et « found 0 vulnerabilities » au run 520. L'avertissement npm warn install-scripts … esbuild@0.25.12 (postinstall) est inchangé.

Vérifié à la source, à l'appui du point 1 de « Pour relire en priorité » : le CHANGELOG de react-router 7.18.3 annonce « Add additional URL validation on client side navigations/redirects » (remix-run/react-router#15446). Le script du worker ne trouve aucun échec sur les quatre origines, mais rien n'a été vérifié dans l'app lancée : quelques navigations sous Linux (origine tauri://localhost) et sous Windows sur un build qui contient cette PR le confirmeraient.

**CI lue par la session principale du run autopilot (pas une revue)** | Run | Commit | Résultat | Lu dans le journal | |---|---|---|---| | 520 | `e8306aa` (tête) | vert, 1 min 53 s | `v24.21.0`, npm `11.19.0`, `npm ci` : « found 0 vulnerabilities » ; vitest `v4.1.11` ; build vert ; 1915 tests (110 fichiers) | Preuve indépendante du passage de 8 à 0, lue dans la CI elle-même : le résumé d'audit de `npm ci` affichait « 8 vulnerabilities (3 moderate, 5 high) » aux runs 512 et 519 (lock de `main`), et « found 0 vulnerabilities » au run 520. L'avertissement `npm warn install-scripts … esbuild@0.25.12 (postinstall)` est inchangé. Vérifié à la source, à l'appui du point 1 de « Pour relire en priorité » : le CHANGELOG de react-router 7.18.3 annonce « Add additional URL validation on client side navigations/redirects » (remix-run/react-router#15446). Le script du worker ne trouve aucun échec sur les quatre origines, mais rien n'a été vérifié dans l'app lancée : quelques navigations sous Linux (origine `tauri://localhost`) et sous Windows sur un build qui contient cette PR le confirmeraient.
maximus commented 2026-10-11 23:12:47 +00:00
Author
Owner
Copy link

Revue /pr-review — PR #417 (issue-358-npm-lock-refresh → issue-320-latest-json-keys)

Verdict : APPROVE

Résumé. Le rafraîchissement du lock tient ce que le corps annonce : npm audit passe de 8 vulnérabilités (5 high, 3 moderate) à 0, les 20 entrées modifiées correspondent au registre, et seul react-router change le bundle livré, sans effet sur la navigation de l'app. Une suggestion non bloquante porte sur une phrase de doc inexacte.

Vérifications rejouées

Copie git archive hors dépôt, Node 22.22.0, npm 10.9.4.

  1. Audit avant/après (npm audit --package-lock-only). Lock de la base, identique à celui de main (sha256 3bf42c0…) : 8 vulnerabilities (3 moderate, 5 high), les advisories du corps (react-router 7.12.0 - 7.18.1 « RSC Mode CSRF Bypass Allows Action Execution Before 400 Response », browserslist <=4.28.6, nanoid <3.3.18, baseline-browser-mapping >=2.0.0 <2.11.0, source-map-js 1.0.0 - 1.2.1, vitest et @vitest/mocker). Lock de la tête : found 0 vulnerabilities. Remettre l'ancien lock fait revenir les 8 : c'est la mutation de ce correctif.
  2. Lock contre le registre (script hors dépôt, une requête par version). lockfileVersion 3 → 3, 259 → 259 entrées, aucune ajoutée ni retirée, entrée racine identique, 20 modifiées. Pour chacune : integrity et resolved égaux à dist.integrity et dist.tarball du registre ; dependencies, optionalDependencies, peerDependencies et engines égaux au manifeste publié ; aucun script preinstall/install/postinstall/prepare ; aucune version dépréciée. Seules react-router et react-router-dom sont hors dev.
  3. Provenance. 19 des 20 versions portent une attestation SLSA qui désigne le dépôt attendu (vitest-dev/vitest, remix-run/react-router, browserslist/browserslist, browserslist/update-db, browserslist/caniuse-lite, chaijs/chai, ai/nanoid, tinylibs/tinyrainbow, web-platform-dx/baseline-browser-mapping, chicoxyzzy/node-releases, Kilian/electron-to-chromium). source-map-js 1.2.2 n'en a pas, comme la 1.2.1, et garde le même éditeur (7rulnik). Deux paquets changent d'éditeur : tinyrainbow (oreanno → publication GitHub Actions, tag v3.2.0) et update-browserslist-db (ai → publication GitHub Actions, tag 1.3.4). Leurs attestations désignent le dépôt d'origine de chacun : c'est un passage à la publication attestée, pas un changement de mains. Version la plus récente : baseline-browser-mapping 2.11.28, publiée le 2026-10-08, données de build seulement.
  4. npm ci, build, tests. npm ci rc=0 et sha256 du lock inchangé (752e8d8…) ; npm run build vert, bundle index-DjjeOWRp.js (1 744,03 kB) et CSS index-CSFhII2z.css, les mêmes noms que dans la CI ; npm test : 110 fichiers, 1915 tests verts.
  5. Seul react-router change le bundle, prouvé par le plan inverse de celui du corps. Sur l'arbre de la tête, react-router et react-router-dom remis en 7.18.1 depuis les archives du registre (intégrité égale à celle du lock de la base) : le build donne index-D8mOfrMJ.js, identique octet pour octet (cmp) au bundle construit depuis la base. Les 18 autres mises à jour ne touchent donc pas la sortie, et la CSS est identique entre base et tête.
  6. Validation de navigation de 7.18.3 et suivantes. Relu dans dist/production/chunk-Q34X6AWR.mjs : useNavigate() et <Navigate> appellent validateNavigationTarget(..., "reject"), <Navigate> pendant le rendu, avant l'effet qui navigue ; isSameOrigin compare protocole et hôte quand l'origine vaut "null". Script hors dépôt sur le vrai code 7.18.4 (createBrowserHistory sur une fenêtre simulée, resolvePath, validateNavigationTarget), avec ma propre liste de cibles relevées dans src/ : constantes de shared/constants, de onboardingChecklist et onboardingPath, /settings/users#import-export, /settings/users#gettingStarted, /reports… suivi de location.search, /reports/category?cat=…. Sous 5 origines (Linux tauri://localhost avec origine "null" ou en tuple, Windows http://tauri.localhost et https://tauri.localhost, dev http://localhost:1420), avec 3 témoins externes : 150 contrôles, 0 échec, chaque témoin refusé par « External navigation is not allowed ». Toutes les cibles de src/ sont des chemins absolus à barre unique, ou /reports suivi de location.search (vide ou commençant par ?) : aucune ne peut se résoudre vers une autre origine. Les clics manuels du point 1 du corps restent un contrôle d'appoint, pas une condition du merge.

CI (run 520, log lu par la route web) : Node 24.21.0, npm 11.19.0, npm ci avec un seul avertissement install-scripts (esbuild@0.25.12), build vert sur le même bundle index-DjjeOWRp.js, vitest 4.1.11 : 110 fichiers, 1915 tests. check-rust ne se déclenche pas (aucun fichier src-tauri/**), c'est attendu.

Fermetures. Resolves #358 et Resolves #317 figurent dans le corps et dans le message du commit, et la timeline des deux issues porte un pull_ref closes venant de #417 : les deux se fermeront au merge, par l'API comme en avance rapide.

CHANGELOG. Entrées EN et FR alignées ; ### Security / ### Sécurité après ### Fixed / ### Corrigé, dans l'ordre de Keep a Changelog ; ce titre existe déjà quatre fois plus bas, et ChangelogContent.tsx lit tout titre ### sans liste fermée. La description de l'advisory correspond au titre que donne npm audit.

Suggestions (non bloquantes)

  1. CLAUDE.md:166 et docs/architecture.md:604 : « rien ne le réévalue en CI » est inexact, et la doc d'architecture ajoute « une advisory publiée depuis n'apparaît qu'au prochain npm audit lancé à la main ». L'étape npm ci de check-frontend.yml tourne sans --no-audit et sans .npmrc : elle audite à chaque run et imprime le compte, sans faire échouer le job (run 520 : found 0 vulnerabilities, sur la ligne qui suit added 175 packages). Le Défenseur relève aussi ces findings de son côté, et #358 en vient. Formulation proposée : « npm audit à 0 au 2026-10-10 (#358), un constat daté : aucun job ne le fait échouer, npm ci en imprime seulement le compte à chaque run de check-frontend ». La correction est mineure ; elle évite à un futur lecteur de croire qu'aucun signal n'existe entre deux audits manuels.
  2. Synchro post-merge de STATE.md, prévue par le corps : la ligne 13 (« 2 restantes, acceptées ») et la mention de #317 dans les suivis d'advisories (ligne 81) deviennent fausses au merge.

Labels

#358 passe de status:review à status:approved. #317 porte status:ready, pas status:review : la procédure le laisse tel quel, et il se fermera au merge.

Actions faites

Copie hors dépôt (/tmp/pr417-review : arbres de la base et de la tête, archives react-router 7.18.1, scripts, journaux) supprimée en fin de revue. Aucun fichier du dépôt modifié.

## Revue /pr-review — PR #417 (`issue-358-npm-lock-refresh` → `issue-320-latest-json-keys`) **Verdict : APPROVE** **Résumé.** Le rafraîchissement du lock tient ce que le corps annonce : `npm audit` passe de 8 vulnérabilités (5 high, 3 moderate) à 0, les 20 entrées modifiées correspondent au registre, et seul react-router change le bundle livré, sans effet sur la navigation de l'app. Une suggestion non bloquante porte sur une phrase de doc inexacte. ### Vérifications rejouées Copie `git archive` hors dépôt, Node 22.22.0, npm 10.9.4. 1. **Audit avant/après** (`npm audit --package-lock-only`). Lock de la base, identique à celui de `main` (sha256 `3bf42c0…`) : `8 vulnerabilities (3 moderate, 5 high)`, les advisories du corps (react-router `7.12.0 - 7.18.1` « RSC Mode CSRF Bypass Allows Action Execution Before 400 Response », browserslist `<=4.28.6`, nanoid `<3.3.18`, baseline-browser-mapping `>=2.0.0 <2.11.0`, source-map-js `1.0.0 - 1.2.1`, vitest et @vitest/mocker). Lock de la tête : `found 0 vulnerabilities`. Remettre l'ancien lock fait revenir les 8 : c'est la mutation de ce correctif. 2. **Lock contre le registre** (script hors dépôt, une requête par version). `lockfileVersion` 3 → 3, 259 → 259 entrées, aucune ajoutée ni retirée, entrée racine identique, 20 modifiées. Pour chacune : `integrity` et `resolved` égaux à `dist.integrity` et `dist.tarball` du registre ; `dependencies`, `optionalDependencies`, `peerDependencies` et `engines` égaux au manifeste publié ; aucun script `preinstall`/`install`/`postinstall`/`prepare` ; aucune version dépréciée. Seules `react-router` et `react-router-dom` sont hors `dev`. 3. **Provenance.** 19 des 20 versions portent une attestation SLSA qui désigne le dépôt attendu (vitest-dev/vitest, remix-run/react-router, browserslist/browserslist, browserslist/update-db, browserslist/caniuse-lite, chaijs/chai, ai/nanoid, tinylibs/tinyrainbow, web-platform-dx/baseline-browser-mapping, chicoxyzzy/node-releases, Kilian/electron-to-chromium). `source-map-js` 1.2.2 n'en a pas, comme la 1.2.1, et garde le même éditeur (`7rulnik`). Deux paquets changent d'éditeur : `tinyrainbow` (oreanno → publication GitHub Actions, tag `v3.2.0`) et `update-browserslist-db` (ai → publication GitHub Actions, tag `1.3.4`). Leurs attestations désignent le dépôt d'origine de chacun : c'est un passage à la publication attestée, pas un changement de mains. Version la plus récente : `baseline-browser-mapping` 2.11.28, publiée le 2026-10-08, données de build seulement. 4. **`npm ci`, build, tests.** `npm ci` rc=0 et sha256 du lock inchangé (`752e8d8…`) ; `npm run build` vert, bundle `index-DjjeOWRp.js` (1 744,03 kB) et CSS `index-CSFhII2z.css`, les mêmes noms que dans la CI ; `npm test` : 110 fichiers, 1915 tests verts. 5. **Seul react-router change le bundle**, prouvé par le plan inverse de celui du corps. Sur l'arbre de la tête, react-router et react-router-dom remis en 7.18.1 depuis les archives du registre (intégrité égale à celle du lock de la base) : le build donne `index-D8mOfrMJ.js`, identique octet pour octet (`cmp`) au bundle construit depuis la base. Les 18 autres mises à jour ne touchent donc pas la sortie, et la CSS est identique entre base et tête. 6. **Validation de navigation de 7.18.3 et suivantes.** Relu dans `dist/production/chunk-Q34X6AWR.mjs` : `useNavigate()` et `<Navigate>` appellent `validateNavigationTarget(..., "reject")`, `<Navigate>` pendant le rendu, avant l'effet qui navigue ; `isSameOrigin` compare protocole et hôte quand l'origine vaut `"null"`. Script hors dépôt sur le vrai code 7.18.4 (`createBrowserHistory` sur une fenêtre simulée, `resolvePath`, `validateNavigationTarget`), avec ma propre liste de cibles relevées dans `src/` : constantes de `shared/constants`, de `onboardingChecklist` et `onboardingPath`, `/settings/users#import-export`, `/settings/users#gettingStarted`, `/reports…` suivi de `location.search`, `/reports/category?cat=…`. Sous 5 origines (Linux `tauri://localhost` avec origine `"null"` ou en tuple, Windows `http://tauri.localhost` et `https://tauri.localhost`, dev `http://localhost:1420`), avec 3 témoins externes : 150 contrôles, 0 échec, chaque témoin refusé par « External navigation is not allowed ». Toutes les cibles de `src/` sont des chemins absolus à barre unique, ou `/reports` suivi de `location.search` (vide ou commençant par `?`) : aucune ne peut se résoudre vers une autre origine. Les clics manuels du point 1 du corps restent un contrôle d'appoint, pas une condition du merge. **CI** (run 520, log lu par la route web) : Node 24.21.0, npm 11.19.0, `npm ci` avec un seul avertissement `install-scripts` (`esbuild@0.25.12`), build vert sur le même bundle `index-DjjeOWRp.js`, vitest 4.1.11 : 110 fichiers, 1915 tests. `check-rust` ne se déclenche pas (aucun fichier `src-tauri/**`), c'est attendu. **Fermetures.** `Resolves #358` et `Resolves #317` figurent dans le corps et dans le message du commit, et la timeline des deux issues porte un `pull_ref` `closes` venant de #417 : les deux se fermeront au merge, par l'API comme en avance rapide. **CHANGELOG.** Entrées EN et FR alignées ; `### Security` / `### Sécurité` après `### Fixed` / `### Corrigé`, dans l'ordre de Keep a Changelog ; ce titre existe déjà quatre fois plus bas, et `ChangelogContent.tsx` lit tout titre `### ` sans liste fermée. La description de l'advisory correspond au titre que donne `npm audit`. ### Suggestions (non bloquantes) 1. **`CLAUDE.md:166` et `docs/architecture.md:604` : « rien ne le réévalue en CI » est inexact**, et la doc d'architecture ajoute « une advisory publiée depuis n'apparaît qu'au prochain `npm audit` lancé à la main ». L'étape `npm ci` de `check-frontend.yml` tourne sans `--no-audit` et sans `.npmrc` : elle audite à chaque run et imprime le compte, sans faire échouer le job (run 520 : `found 0 vulnerabilities`, sur la ligne qui suit `added 175 packages`). Le Défenseur relève aussi ces findings de son côté, et #358 en vient. Formulation proposée : « `npm audit` à 0 au 2026-10-10 (#358), un constat daté : aucun job ne le fait échouer, `npm ci` en imprime seulement le compte à chaque run de `check-frontend` ». La correction est mineure ; elle évite à un futur lecteur de croire qu'aucun signal n'existe entre deux audits manuels. 2. **Synchro post-merge de `STATE.md`**, prévue par le corps : la ligne 13 (« 2 restantes, acceptées ») et la mention de #317 dans les suivis d'advisories (ligne 81) deviennent fausses au merge. ### Labels #358 passe de `status:review` à `status:approved`. #317 porte `status:ready`, pas `status:review` : la procédure le laisse tel quel, et il se fermera au merge. ### Actions faites Copie hors dépôt (`/tmp/pr417-review` : arbres de la base et de la tête, archives react-router 7.18.1, scripts, journaux) supprimée en fin de revue. Aucun fichier du dépôt modifié.
maximus changed target branch from issue-320-latest-json-keys to main 2026-10-12 19:32:48 +00:00
maximus merged commit e8306aa260 into main 2026-10-12 19:32:53 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
autopilot:pending-human

PR produced by /autopilot — awaits human review/merge

  
source:analyste

Créée par le Super-Analyste

  
source:defenseur

Créée par l Escouade Défenseur

  
source:human

Créée par un humain

  
source:medic

Créée par le Medic (auto-détection)

  
status:approved

PR approuvée, prête à merger

  
status:blocked

Bloquée (question, dépendance, clarification)

  
status:in-progress

Un agent (Medic/Dev) travaille dessus

  
status:needs-clarification

Issue blocked by ambiguity — Max needs to clarify before re-running autopilot

  
status:needs-fix

Reviewer demande des corrections

  
status:ready

Analysée et documentée, prête à prendre

  
status:review

PR créée, en attente du Reviewer

  
status:triage

Nouvelle issue, pas encore analysée

  
type:bug

Correction de bug → Medic

  
type:feature

Nouvelle fonctionnalité → Dev

  
type:infra

Config, CI/CD, déploiement → Dev

  
type:refactor

Refactoring / amélioration technique → Dev

  
type:schema

Modèle de données / migrations → Dev

  
type:security

Issue de sécurité → Medic ou Dev

No labels
autopilot:pending-human
source:analyste
source:defenseur
source:human
source:medic
status:approved
status:blocked
status:in-progress
status:needs-clarification
status:needs-fix
status:ready
status:review
status:triage
type:bug
type:feature
type:infra
type:refactor
type:schema
type:security
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: maximus/Simpl-Resultat#417
No description provided.
Delete branch "issue-358-npm-lock-refresh"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?