REVIEW.md : principes à la place des énumérations (clé de signature, identifier) et règle Feedback Hub (PR C de #462) #477

New issue

Open

opened 2026-10-20 00:01:50 +00:00 by maximus · 0 comments

maximus commented

2026-10-20 00:01:50 +00:00

Owner

Troisième des trois PR découpées de #462 (décision de Max, 2026-10-19). Vérifié sur main 6e8e157.

Contexte

Ces lignes sont dans les règles par zone de REVIEW.md, hors de la section « Niveaux » : la PR reste de niveau normal et ne demande pas de rejouer la calibration.

Clé de signature (REVIEW.md:126). La ligne énumère ce qui s'exécute avec TAURI_SIGNING_PRIVATE_KEY (beforeBuildCommand, @tauri-apps/cli, cargo-xwin, la toolchain, build.rs, macros des crates, @plugin/@config, npm ci). Le principe : tout ce qui s'exécute dans le job build-and-release (release.yml:9) atteint la clé, dont le script NodeSource (release.yml:26, non épinglé) et actions/checkout@v4 (release.yml:36, étiquette mobile), absents de la liste. La PR #469 réécrit cette ligne (cargo-xwin « épinglé depuis #449 », toolchain « sans version épinglée ») et #461 y consigne la décision « toolchain flottante » : partir de leur version.
identifier (REVIEW.md:101). La ligne énumère « les bases des profils et, sous app_data_dir(), la clé de licence, le jeton d'activation et le fichier de repli des jetons OAuth ». Le principe : changer l'identifier orpheline tout ce que l'app range sous app_config_dir() et app_data_dir(), dont profiles.json (liste des profils et pin_hash, profile_commands.rs:13-35) et tout le dossier auth/, absents de la liste.
Feedback Hub (REVIEW.md:85). La règle liste ce qui part mais ne dit rien du consentement (openFeedback, LogViewerCard.tsx:20-33, localStorage, FeedbackConsentDialog.tsx), alors que la l. 83 le fait pour les cours. À écrire au même endroit : le consentement n'est vérifié que côté front, par ce seul chemin.

Travail à faire

Prérequis : merge de la pile #468-#475 (la PR #469 réécrit la l. 126) et, de préférence, de #461 (même ligne).

REVIEW.md:126 : remplacer l'énumération par le principe « tout ce qui s'exécute dans le job build-and-release », en gardant deux ou trois exemples (NodeSource, actions/checkout@v4, cargo-xwin), et la mention de la décision sur la toolchain.
REVIEW.md:101 : le principe « tout ce qui vit sous app_config_dir() et app_data_dir() », avec profiles.json et auth/ en exemples, et la constante KEYCHAIN_SERVICE qui ne suit pas (déjà dit).
REVIEW.md:85 : le consentement du Feedback Hub, son seul chemin, et la règle « vérifié côté front seulement ».

Fichiers concernés

REVIEW.md — l. 85, 101, 126 (numéros sur main 6e8e157 ; après #469, les lignes à partir de 159 remontent de deux)

Surface de test

python3 scripts/review-levels.py --check reste vert (aucun motif ne change).

Critères d'acceptation

Les trois lignes portent un principe, des exemples, et aucune énumération présentée comme exhaustive.
--check vert ; aucun changement dans la section « Niveaux ».

Complexité estimée

Simple. Niveau de revue : normal. Parent : #462.

Troisième des trois PR découpées de #462 (décision de Max, 2026-10-19). Vérifié sur `main` `6e8e157`. ## Contexte Ces lignes sont dans les règles par zone de `REVIEW.md`, hors de la section « Niveaux » : la PR reste de niveau normal et ne demande pas de rejouer la calibration. - **Clé de signature (`REVIEW.md:126`).** La ligne énumère ce qui s'exécute avec `TAURI_SIGNING_PRIVATE_KEY` (`beforeBuildCommand`, `@tauri-apps/cli`, `cargo-xwin`, la toolchain, `build.rs`, macros des crates, `@plugin`/`@config`, `npm ci`). Le principe : tout ce qui s'exécute dans le job `build-and-release` (`release.yml:9`) atteint la clé, dont le script NodeSource (`release.yml:26`, non épinglé) et `actions/checkout@v4` (`release.yml:36`, étiquette mobile), absents de la liste. **La PR #469 réécrit cette ligne** (`cargo-xwin` « épinglé depuis #449 », toolchain « sans version épinglée ») et #461 y consigne la décision « toolchain flottante » : partir de leur version. - **`identifier` (`REVIEW.md:101`).** La ligne énumère « les bases des profils et, sous `app_data_dir()`, la clé de licence, le jeton d'activation et le fichier de repli des jetons OAuth ». Le principe : changer l'`identifier` orpheline tout ce que l'app range sous `app_config_dir()` et `app_data_dir()`, dont `profiles.json` (liste des profils et `pin_hash`, `profile_commands.rs:13-35`) et tout le dossier `auth/`, absents de la liste. - **Feedback Hub (`REVIEW.md:85`).** La règle liste ce qui part mais ne dit rien du consentement (`openFeedback`, `LogViewerCard.tsx:20-33`, `localStorage`, `FeedbackConsentDialog.tsx`), alors que la l. 83 le fait pour les cours. À écrire au même endroit : le consentement n'est vérifié que côté front, par ce seul chemin. ## Travail à faire Prérequis : merge de la pile #468-#475 (la PR #469 réécrit la l. 126) et, de préférence, de #461 (même ligne). - [ ] `REVIEW.md:126` : remplacer l'énumération par le principe « tout ce qui s'exécute dans le job `build-and-release` », en gardant deux ou trois exemples (NodeSource, `actions/checkout@v4`, `cargo-xwin`), et la mention de la décision sur la toolchain. - [ ] `REVIEW.md:101` : le principe « tout ce qui vit sous `app_config_dir()` et `app_data_dir()` », avec `profiles.json` et `auth/` en exemples, et la constante `KEYCHAIN_SERVICE` qui ne suit pas (déjà dit). - [ ] `REVIEW.md:85` : le consentement du Feedback Hub, son seul chemin, et la règle « vérifié côté front seulement ». ## Fichiers concernés - `REVIEW.md` — l. 85, 101, 126 (numéros sur `main` `6e8e157` ; après #469, les lignes à partir de 159 remontent de deux) ## Surface de test - `python3 scripts/review-levels.py --check` reste vert (aucun motif ne change). ## Critères d'acceptation - [ ] Les trois lignes portent un principe, des exemples, et aucune énumération présentée comme exhaustive. - [ ] `--check` vert ; aucun changement dans la section « Niveaux ». ## Complexité estimée Simple. Niveau de revue : normal. Parent : #462.