feat(auth): simplifie l'auth GitHub - derive nom+email du PAT, 2 etapes claires, retry (AC-R036)

BACKLOG.md

@@ -107,7 +107,18 @@ Config MCP de référence :
 3. **Gotcha de rotation** : documenter (README) + garde-fou — un `GH_TOKEN`/email déjà persisté dans le `~/.zshenv` de la VM n'est **pas** mis à jour par un changement côté hôte (grep-guard). Prévoir un chemin de mise à jour (réécrire la ligne `~/.zshenv` de la VM, ou `agent-vm rm` documenté).
 4. **Next-steps de l'install** : mentionner l'auth GitHub dans « Prochaines étapes » (actuellement absente).
 **DoD :** sur un poste vierge, `install.sh` propose l'auth GitHub ; après acceptation, une VM fraîche pushe + ouvre une PR sans aucune édition manuelle de `runtime.sh` ; un email non-noreply est refusé avec un message clair. → `TESTS.md` S24.
-**⏳ Implémenté (06/07/2026, branche `feat/github-auth-installer`)** — sous-points 1 (prompt token dans Phase A), 2 (identité + garde-fou email noreply, 3 tentatives) et 4 (next-steps) faits ; token jamais loggé (vérifié par canari en dry-run). **Reste** : sous-point 3 (gotcha de rotation — mise à jour d'un `~/.zshenv` VM déjà écrit) → PR séparée. Validation S24 à finaliser.
+**Implémenté (06/07/2026, branche `feat/github-auth-installer`)** — sous-points 1 (prompt token dans Phase A), 2 (identité + garde-fou email noreply, 3 tentatives) et 4 (next-steps) faits ; token jamais loggé (vérifié par canari en dry-run). **Reste** : sous-point 3 (gotcha de rotation) → PR séparée. Validation S24 absorbée par T2-CH2.
+
+---
+
+### T2-CH2 🟠 Simplifier et fiabiliser l'auth GitHub du wizard `<- AC-R036`
+**But :** le bloc GitHub de `phase_a` est redondant et fragile : après la dérivation API réussie, il redemande quand même le nom et l'email (pré-remplis, donc inutiles). Et si l'utilisateur colle son token à la question o/N (cas réel bêta-testeur), le token est silencieusement ignoré.
+**Tâches :**
+1. **#1 — Supprimer les 2 prompts quand la dérivation réussit** : après curl 2xx + login + id, utiliser directement `git_name = login` et `git_email = <id>+<login>@users.noreply.github.com`. Afficher un seul récap `ok "Compte GitHub : login <email>"`. Persister GH_TOKEN, AC_GIT_USER_NAME, AC_GIT_USER_EMAIL.
+2. **#2 — Fallback uniquement si la dérivation échoue** : curl non-2xx/réseau/parsing vide → prompts manuels nom/email avec validation noreply.
+3. **#3 — Séparation visuelle** : ajouter `info "Étape suivante : colle ton PAT GitHub (scope repo)."` avant le prompt_secret du token.
+4. **#4 — Détection token collé à l'étape o/N** : regex `^(ghp_|github_pat_|gho_|ghs_|ghr_|.{31,}$)` → warn + retry. Token invalide (curl non-2xx) → warn + retry (max 3). Ne jamais persister un token non validé.
+**DoD :** dérivation OK → aucun prompt nom/email ; token collé à l'étape o/N → message clair + retry ; token invalide → message + retry ; limites à 3 tentatives. → `TESTS.md` S31, S40.
 
 ---
 

FEEDBACK.md

@@ -35,7 +35,7 @@
 | AC-R016 | 🎛️ | 🟡 | Choix de profil (beta.gouv / La Suite / IAE / Autre) déroutant pour qui n'est pas familier de cette typologie. Question posée trop tôt, avant toute configuration. La valeur « Autre » donne l'impression d'avoir choisi par défaut. | Test utilisateur S28 2026-07 | 🆕 à trier | — |
 | AC-R017 | ✨ | 🟠 | Au setup, on aimerait choisir quelles skills et MCP on branche (Y/N). La config ouverte ne donne aucun contexte de ce qu'apporte chaque brique — « est-ce que j'ai besoin de playwright pour mon projet ? » | Test utilisateur S28 2026-07 | 🆕 à trier | — |
 | AC-R018 | 🎛️ | 🟡 | Bascule FR->EN vers le wizard agent-vm : quand install.sh passe la main à `agent-vm setup`, le wizard natif d'agent-vm (en anglais) s'affiche sans prévenir. Déroutant pour un public non-tech francophone. | Dogfood install 2026-07 | ✅ traité | `BACKLOG.md` T6.5 · `TESTS.md` S30 |
-| AC-R019 | 🐛 | 🔴 | À l'étape auth GitHub, `install.sh` demande « Email noreply GitHub » avec pour défaut le vrai email de l'utilisateur, qui échoue la validation. Un utilisateur non-tech ne connaît pas son email noreply ni comment le trouver. | Dogfood install 2026-07 | 🔧 en cours (réouvert) | `BACKLOG.md` T6.6 · `TESTS.md` S31 (séd non matché, corrigé dans hotfix #2) |
+| AC-R019 | 🐛 | 🔴 | À l'étape auth GitHub, `install.sh` demande « Email noreply GitHub » avec pour défaut le vrai email de l'utilisateur, qui échoue la validation. Un utilisateur non-tech ne connaît pas son email noreply ni comment le trouver. | Dogfood install 2026-07 | ✅ traité | `BACKLOG.md` T6.6 · `BACKLOG.md` T2-CH2 · `TESTS.md` S31, S40 |
 | AC-R020 | ⚙️ | 🟠 | `agent-vm setup` installe 4 harnais (Claude Code, OpenCode, Codex, Mistral Vibe). En test réel, l'installeur Mistral Vibe a retourné HTTP 429 (rate limit) et TOUT le setup a échoué, alors qu'Albert Code n'a besoin que d'OpenCode. Un seul installeur qui rate = base non finalisée. Le retry a fonctionné (429 transitoire), mais risque de fiabilité à l'install party (plusieurs testeurs en parallèle). Dépendance upstream agent-vm. | Dogfood install 2026-07 | 📥 backlogué | `BACKLOG.md` T6.7 |
 | AC-R021 | 🐛 | 🟠 | (a) install avortée sans shim : `install.sh` a `set -e` et `install_shim` est appelé APRÈS la création fragile de la VM de base. Un échec d'`agent-vm setup` (429) fait sortir l'installeur en erreur AVANT de poser le shim -> install incomplète, aucune commande `albert-code`. (b) ancien installeur MVP écrivait une fonction shell `albert-code()` dans ~/.zshrc, qui masque le shim PATH -> le nouveau shim est ignoré. | Dogfood install 2026-07 | ✅ traité | `BACKLOG.md` T6.8 · `TESTS.md` S32 |
 | AC-R022 | 🐛 | 🔴 | Le shim `albert-code` (généré par `install_shim`) avale les prompts interactifs : il source le script avec `2>/dev/null` (avale stderr où `confirm()`/`prompt_*` écrivent) puis appelle `$name "$@"`. Résultat : `albert-code setup` affiche l'entête puis semble figé (questions MCP/skills invisibles, `read` attend). | Dogfood install 2026-07 | ✅ traité | `BACKLOG.md` T6.9 · `TESTS.md` S33 |
@@ -56,6 +56,8 @@
 | AC-R033 | 🎛️ | 🟡 | L'utilisateur ne sait pas où il en est dans le setup (Phase B) : pas de compteur d'étapes. Afficher [1/4]..[4/4] serait utile. | Feedback Leo Guillaume (Tech Lead Albert API) 2026-07 | ✅ traité | `BACKLOG.md` T6.14 · `TESTS.md` S38 |
 | AC-R034 | 🎛️ | 🟡 | En fin de setup, aucun récapitulatif des choix (MCP actifs, skills cochées, statut GitHub). Un panneau récap aide à valider avant de lancer. | Feedback Leo Guillaume (Tech Lead Albert API) 2026-07 | ✅ traité | `BACKLOG.md` T6.14 · `TESTS.md` S38 |
 
+| AC-R036 | 🎛️ | 🟠 | UX auth GitHub du wizard : après avoir collé le PAT, le wizard redemande quand même « Nom pour les commits » et « Email noreply GitHub » (pré-remplis), alors que le PAT donne tout via l'API. De plus, si l'utilisateur colle par erreur son token à la question o/N (au lieu de répondre o d'abord), le token est silencieusement ignoré sans message clair. | Feedback bêta-testeur 2026-07-07 (Romaric) | ✅ traité | `BACKLOG.md` T2-CH2 · `TESTS.md` S40 |
+
 ## Notes
 
 - **AC-R004 (prompt caching)** : à instruire avant tout scaling. Vérifier si Albert API expose du caching sur `chat/completions` ; sinon, arbitrer l'infra d'inférence. vLLM implémente le caching nativement.

TESTS.md

@@ -237,17 +237,16 @@ et le bloc marqueur a disparu.
 3. Dans `phase_run()`, répondre « oui » à la création de la VM (dry-run).
 **Attendu :** un encart `info` en français s'affiche avant `agent-vm setup`, mentionnant que le wizard est en anglais, expliquant ce qu'est agent-vm, et conseillant de valider les logiciels par défaut. Sortie identique en `check_base_vm` et `phase_run`.
 
-## S31 — Dérivation automatique email noreply GitHub (T6.6, AC-R019) ☐
+## S31 — Dérivation automatique identité GitHub (T6.6, AC-R019, T2-CH2) ☐
 **Préconditions :** un PAT GitHub valide (scope `repo`) ; `curl` disponible.
 **Étapes :**
 1. Lancer `./install.sh` (ou `albert-code install`).
 2. Répondre « oui » à l'activation push/PR GitHub.
 3. Coller le PAT.
-4. Vérifier que le prompt « Email noreply GitHub » affiche le noreply dérivé (ex. `12345+username@users.noreply.github.com`).
-5. Faire Entrée.
-6. Vérifier `~/.zshenv` : `AC_GIT_USER_EMAIL` = noreply GitHub.
-7. (Fallback) Simuler l'absence de réseau : sans `curl` ou PAT invalide, vérifier que le message FR d'aide s'affiche.
-**Attendu :** (4) le noreply est pré-rempli, l'utilisateur fait Entrée ; (6) email noreply persisté ; (7) message FR d'aide clair avec lien GitHub. Le PAT n'apparaît dans aucun log.
+4. Vérifier AUCUN prompt « Nom pour les commits » ni « Email noreply GitHub » (dérivation réussie → tout est automatique).
+5. Vérifier le récap : ok "Compte GitHub : <login> <<id>+<login>@users.noreply.github.com>"
+6. Vérifier `~/.zshenv` : `AC_GIT_USER_NAME` = login, `AC_GIT_USER_EMAIL` = noreply GitHub.
+**Attendu :** (4) pas de prompts ; (5) récap correct ; (6) identité persistée. Le PAT n'apparaît dans aucun log.
 
 ## S32 — Shim avant VM + migration ancien `albert-code()` (T6.8, AC-R021) ☐
 **Préconditions :** `install.sh` ou `bin/albert-code install` ; `albert-code()` dans un shell rc (ex. `~/.zshrc`).
@@ -301,6 +300,49 @@ et le bloc marqueur a disparu.
 6. Répéter le setup avec `CONTEXT7_API_KEY` déjà dans l'env → vérifier qu'aucun prompt Context7 n'apparaît (le MCP est activé normalement).
 **Attendu :** (2) ASCII art présent au début de Phase B. (3) `print_next_steps` raccourci, plus de « Crée la VM de base », plus de « Ouvre la bulle isolée », plus de « Parle en français ». (4) statut GitHub AVANT le ✓ final, pas après. (5) clé demandée, warning si vide. (6) pas de prompt si clé déjà présente.
 
+## S40 — Auth GitHub : dérivation OK, token collé à mauvaise étape, token invalide (T2-CH2, AC-R036) ☐
+
+**S40a — Dérivation API OK → pas de prompts nom/email, juste le récap**
+**Préconditions :** `install.sh` disponible, `curl`, PAT valide (scope repo).
+**Étapes :**
+1. Lancer `bash lib/phases.sh` (sourcer) et appeler `_github_auth` avec un vrai PAT (ou stub `api.github.com/user`).
+2. Répondre `o` au prompt d'activation, coller le PAT valide.
+3. Observer la sortie.
+**Attendu :** aucun prompt « Nom pour les commits » ni « Email noreply GitHub ». Le seul message est `✓ Compte GitHub : <login> <<id>+<login>@users.noreply.github.com>`. `AC_GIT_USER_NAME` = login, `AC_GIT_USER_EMAIL` = noreply.
+
+**S40b — Token collé à la question o/N → message d'échec + avertissement sécurité + transition vers prompt masqué**
+**Préconditions :** `install.sh` disponible, un token quelconque.
+**Étapes :**
+1. Lancer `install.sh`.
+2. Au prompt « Activer le push et les PR GitHub depuis la VM ? [o/N] », coller un token (commence par `ghp_`, `github_pat_`, ou chaîne >30 car. non reconnue comme o/n).
+3. Observer les messages.
+**Attendu :** le script affiche `! On dirait que tu as collé ton token à la mauvaise étape (réponds d'abord o).` puis `! Ce token vient d'être affiché en clair dans le terminal : pense à le révoquer` et `! et à en régénérer un (github.com/settings/tokens).` puis `? Continuer la connexion GitHub ?`. Répondre oui → on passe DIRECTEMENT au prompt masqué `prompt_secret` (ETAPE TOKEN, pas de re-demande de [o/N]). Répondre non → `! GitHub non connecté.`
+
+**S40c — Token invalide → message d'échec + retry sur prompt masqué (pas de [o/N])**
+**Préconditions :** `install.sh` disponible, un token invalide.
+**Étapes :**
+1. Lancer `install.sh`.
+2. Répondre `o` à l'activation, coller un token invalide.
+3. Observer le message.
+**Attendu :** le script affiche `! Échec : GitHub non connecté (token invalide ou API injoignable).` puis `! Tentative 1/3 — recolle ton PAT dans le champ masqué ci-dessous.` et le prompt masqué `prompt_secret` réapparaît (pas de [o/N]). Au 3e échec → fallback prompts manuels nom/email.
+
+**S40d — Token valide au 2e essai après un premier échec → connexion directe, pas de fallback**
+**Préconditions :** `install.sh` disponible, un token invalide puis un token valide.
+**Étapes :**
+1. Lancer `install.sh`.
+2. Répondre `o` à l'activation, coller un token invalide.
+3. Voir le message d'échec + prompt masqué réapparaître.
+4. Coller un token valide.
+**Attendu :** le script dérive l'identité, affiche `✓ Compte GitHub : <login> <<id>+<login>@users.noreply.github.com>` et persiste. Pas de fallback manuel, pas de prompts nom/email.
+
+**S40e — Fallback quand token invalide au 3e essai**
+**Préconditions :** `install.sh` disponible, token invalide.
+**Étapes :**
+1. Lancer `install.sh`.
+2. Répondre `o` à l'activation, coller un token invalide 3 fois (Entrée entre chaque pour abandonner).
+3. Observer les prompts manuels.
+**Attendu :** le script affiche le message d'aide FR `! Introuvable automatiquement...` puis demande le nom et l'email. Ne jamais persister GH_TOKEN.
+
 ## S36 — `install_shim` réécrit un shim obsolète + sortie sync_skills propre (T6.12, T6.13) ☐
 **Préconditions :** dossier sandbox `/tmp/ac-test`, `install.sh` disponible.
 **Étapes (install_shim) :**