[iPoower]

La restauration locale doit conserver progression, Daily Five et historiques en un seul instantané confirmé, y compris après quota, relecture perdue ou accès multi-onglets. Cette PR rassemble les correctifs de #26 et #27 ; aucune fusion intermédiaire de #26 n’est nécessaire.

Périmètre et traçabilité

• Base main : 21a4ad7, incluant docs(learning): raccord Drive, instantanés et certification à confirmer — 24/10 #28 et test(learning): attendre la navigation achevée avant le contrôle du focus #29.
• Têtes sources : fix(P0): NOESIS 4.0 — restauration locale atomique et vérifiée #26 300f11f, ancêtre de fix(P0): compléter #26 — onglets, restauration et historiques préservés #27 706e204.
• Tête consolidée : d00a3b4 ; arbre e9c502d68c5d5549eaeeebcf6e41d9e2ca6753bb. Les deux lignées sont des parents/ancêtres ; branches sources intactes.
• app.js et workflow de tests identiques à fix(P0): compléter #26 — onglets, restauration et historiques préservés #27 ; les neuf fichiers de docs(learning): raccord Drive, instantanés et certification à confirmer — 24/10 #28/test(learning): attendre la navigation achevée avant le contrôle du focus #29 identiques au main courant. Aucun changement secondaire ni activation externe.

Diff avec la preuve #30

#30 n’est ni fusionnée ni utilisée comme parent. Par rapport à son arbre 38b5b090eb022876c9009777d29fe08add15457d : sa note temporaire n’est pas reprise ; docs/NOESIS_CONSOLIDATED_RESTORE_20261024.md explique cette consolidation, les conditions et le rollback ; trois assertions supplémentaires dans deux tests interdisent un faux message de succès après échec quota/relecture/restauration cloud. Tous les autres fichiers sont identiques. Aucun test retiré ou affaibli.

Validation

Local : 16 scénarios atomiques, cohérence pédagogique et dossier, crypto, 15 contre-tests cloud, 20 tests de provenance réussis. CI complète vérifiée avec succès sur cette tête exacte : https://github.com/iPoower/Reconversion-Control/actions/runs/40068608055 — provenance, Chromium et WebKit. Les deux moteurs passent 31 groupes mobiles et 21 groupes pédagogiques, les scénarios de stockage natif et les assertions renforcées de refus de faux succès ; Chromium passe aussi 12 groupes de service worker. Le vert de #30 n’a pas été réutilisé. WebKit ne vaut pas un iPhone physique ; fournisseur cloud synthétique uniquement.

Condition bloquante de publication

GO fusion conditionnel reçu ; GO déploiement absent. Le workflow Pages publie après CI verte de push main. Lecture publique de l’environnement github-pages : uniquement branch_policy pour main, aucun approbateur obligatoire, can_admins_bypass:true. La barrière humaine n’existe pas actuellement. La politique permet main ; aucun required_reviewers n’est configuré. Le catalogue Cloudflare accessible (4 projets, pagination complète) ne présente aucun projet Reconversion Control ; les webhooks GitHub restent non vérifiables faute d’accès administratif. Ne pas fusionner avant preuve d’un blocage effectif de toutes les publications ou GO déploiement distinct. Aucune configuration administrative ou workflow de publication modifié. Les webhooks non lisibles ne sont pas réputés absents.

Récupération / rollback

Conserver V3, miroirs historiques et exports complets. Aucun effacement ni downgrade aveugle vers un lecteur ignorant V3. Incident : bloquer les écritures, exporter les saisies mémoire et récupérer dans un profil isolé avec comparaison exhaustive progression/Daily Five/labs/preuves/carrière. Revert de code par nouvelle PR validée, barrière de publication maintenue ; il ne restaure pas les données.

Les PR #26, #27 et #30 restent ouvertes ; aucune suppression de branche. Aucune fusion, publication, donnée personnelle ou activation Supabase effectuée. Après CI, main reste 21a4ad7… ; aucun déploiement n’est retourné pour le SHA consolidé ; le dernier déploiement Pages observé reste celui de main 21a4ad7… antérieur à cette mission. La décision reste BLOQUÉE jusqu’au GO de barrière ou de déploiement distinct.