JOURNAL

Fichier : JOURNAL.md · Dossier : wiki racine Branche : master · Auteur : hprzeta · MAJ : 2026-10-23

Riemann_Lab — Journal de bord

📓 Fichier append-only. On n'allège jamais ce fichier : on ajoute un pavé daté en haut à chaque session. Il n'est pas relu en entier au démarrage (utiliser grep ou demander à Claude de chercher dans ce fichier précis).

Le plus récent est en haut. Format de pavé : ## AAAA-MM-JJ — HHhMM — titre — commit.

2026-10-23 — Prompts Claude Code locaux (src/ia/prompts) — 9f6f501, 2c30cab, 3fdc4c1, 9f858ab, e203dcf

Prompts Claude Code des projets ZETA rangés dans src/ia/prompts/ (393 .md, un dossier par projet + README index), dossier ignoré par git (identifiants réseau) ; 16 anciens fichiers retirés de l'index. Opération reportée sur les 4 branches (IA, C, Test, main), sauvegarde dans ~/backup_prompts_ia.

2026-10-16 — 22h30 — Monitoring Zêta installé et validé à blanc, `zeta-script` étendu aux fonctions du monitoring — commit `2de45af` (4 branches à niveau)

Contexte. Un dossier monitoring/ (logger 1 s des 5 machines, détecteur de runs, rapport automatique MD + PDF avec 3 graphiques, page Monitoring-Runs.md) a été ajouté dans ~/projet_zeta/. Objectif : que chaque run de zéros ait ses graphiques.

Étape 0 (mesuré). Installation déjà faite. zeta_log_metrics.py --test : PC1 à PC5 tous OK (SSH multiplexé sans problème, PC4 OpenBSD compris ; pas de RAM sur PC4, attendu). zeta-mon-on : logger et watcher (motif compute_zeros) actifs, mesures des 5 machines relues. Aucun run réel lancé.

zeta-script (commit 2de45af, 2 fichiers). Constat : le menu ne lisait que les lignes alias de ~/.bashrc, or les commandes du monitoring sont des fonctions bash (monitoring/zeta_monitoring_alias.sh), donc invisibles. scripts/zeta_script.py (copie .bak-20261016) lit maintenant ces fonctions : 10 commandes (n° 37-46), libellés, avertissement ⚠ pour les 3 qui ouvrent une fenêtre graphique (ne pas lancer pendant un run), saisie d'arguments facultative. Test réel du lancement de zeta-mon-status via le menu : OK. monitoring/README.md : section « Menu zeta-script » + procédure avant / pendant / après un run (85 lignes).

Git. Audit avant commit : 0 résultat (secrets, IP, MAC, e-mails), sans --force. Riemann_Lab_IA et Riemann_Lab_C 2de45af ; main 9c44c2b et Riemann_Lab_Test e07feec (merges --no-ff, worktree temporaire, merge-tree sans conflit).

Non vérifié. Détection et rapport sur un vrai run (chaîne testée seulement à blanc) ; présence de reportlab dans le venv ; nom exact du script lancé par zeta_run.sh vis-à-vis du motif compute_zeros. Test prévu le 17/10 sur un run court avant tout gros run.

Reste ouvert. Publication du reste de monitoring/ (non suivi) et de la page wiki « Monitoring » ; 4 anciens scripts de monitoring en doublon dans scripts/ (non touchés) ; points du bloc précédent (sudoers, V17, jeton DuckDNS).

2026-10-16 — 20h00 — V17 `compute_zeros_v17.py` (v17-a à d) puis turbo Zêta par SESSION — commits `b4526bf` (V17) et `1a9ad0c` (turbo), 4 branches à niveau

V17 (commit b4526bf, 2 fichiers). compute_zeros_v17.py = copie de v16 durcie : journal d'échecs JSONL, validation LMFDB/Turing conditionnelle (t_min <= 14), CSV worker enrichis (provenance), checkpoints périodiques atomiques + progress_worker_NNN.json, consolider() (variante A, sans STEP, overlap 0,5) à la place de dedupliquer(0,01). Revue D1-D3, D5, D6 appliquée (ConsolidationError sans repli, dossiers consolidation_v17, _2, _3, écriture finale obligatoire). Tests : tests_v17/ 16 + 9 OK. Rejeu T1b v17 : 185 821 bruts -> 185 814 (7 DUPLICATE_CONFIRMED, 4 paires AMBIGUOUS), identique ligne à ligne au rejeu P0 ; checkpoints bruts v16/v17 identiques bit à bit ; 33,9 min (turbo non actif : gouverneur resté powersave). D4 non corrigé : la quarantaine n'apparaît ni dans le CSV principal ni dans le journal (documenté seulement).

Turbo par session (commit 1a9ad0c, 7 fichiers). Constat : auth.log ne montrait aucun appel sudo turbo sur le boot du 16/10 (turbo jamais exécuté malgré des « turbo ok »). Anciens défauts : état écrasé à chaque on, off imposant powersave, état dans /tmp, zeta_run.sh coupant le turbo après chaque run. Nouveau cycle : hook SessionStart (.claude/settings.local.json, local) -> zeta_session_turbo.sh start ; turbo CPU maintenu entre les runs ; zeta_run.sh n'arrête les 12 services que pendant le run (--services) ; restauration au « bye bye » (étape 0, zeta_session_turbo.sh end). zeta_turbo_on/off.sh réécrits (idempotents, état /run/zeta_turbo/state + flock, restauration exacte gouverneur+EPP par CPU+swappiness, relecture vérifiée), zeta_turbo_status.sh (lecture seule). Tests tests_turbo/test_zeta_turbo.py : 34 OK sur arbre sysfs factice, 9 mutations toutes détectées. Audit avant push : rien. Branches : Riemann_Lab_IA/_C 1a9ad0c, main 5f3f5c4, Riemann_Lab_Test 9e70cce.

Non vérifié / risques. Aucune activation réelle testée sur la machine (état réel INACTIF) ; hook effectif seulement à la prochaine session ; power-profiles-daemon peut défaire le gouverneur (statut DERIVE, relancer on) ; une seule session Zêta à la fois ; aucune restauration automatique après crash ; faille sudoers existante non corrigée : NOPASSWD sur scripts/zeta_turbo_on.sh/_off.sh du dépôt (modifiables par l'utilisateur, exécutés en root) -> durcissement = copies root dans /usr/local/sbin + règle sudoers, action de hprzeta ; alias ~/.bashrc zeta-turbo-* non modifiés.

2026-10-15 — 22h00 — V17 phase P0 : `consolider()` non destructif, tests D1-D13, rejeu T1b, Z-sign sur les 4 paires — commit `c46c12b` (4 branches à niveau)

Contexte. Suite du test T1b (v16, [4 900 000 ; 4 986 000]) : dedupliquer(0.01) supprime de vraies paires de zéros. Audit V16 → V17 mené d'abord en lecture seule (rapport A–M), puis phase P0 autorisée par étapes. Nouveaux fichiers seulement : V16, parallel_scanner.py et les CSV bruts n'ont pas été touchés (SHA-256 des 8 checkpoints identiques avant/après chaque rejeu).

Faits constatés dans le code (lecture) :

STEP de v16 est une fonction de T_MAX seul (constant sur tout l'intervalle et pour tous les workers) : 3,1462869e-4 à $T_{max}$ = 4 986 000 (recalculé, égal au log). La prémisse « STEP fixé à 0,010 » est fausse pour v16.
Détection : changement de signe strict de Z_double (RS C0+C1) sur une grille t_min + k·STEP ; un bracket → au plus un candidat (Illinois sur Z_rs, puis Newton Z_arb, repli mpmath non borné si hors bracket) ; except Exception: pass (l. 228, 285) et repli REJECT qui renvoie le milieu sans trace.
Déficit v13 (96 manquants à 5M) : réparti en $t$, non concentré dans les segments 0-1 ; le dossier du « run V16 5M » est vide (valeurs rapportées non vérifiables) ; aucune donnée brute v13 présente. Attendu GUE de paires < 0,01 sur [14 ; 5M] ≈ 91 (heuristique, ±20-30 %).

Livrables P0 (scripts_v17/, tests_v17/) :

consolider() : chaque groupe reçoit DUPLICATE_CONFIRMED / DISTINCT / AMBIGUOUS, avec provenance (fichier, ligne, worker, segment), règle, justification, limites ; journal JSONL, CSV consolidé, fichier des ambigus, invalides ; invariant de conservation (aucun candidat perdu) ; écriture atomique sans écrasement ; indépendance à l'ordre vérifiée sur 185 821 candidats. Règles : R-DUP1 (workers adjacents, zone de chevauchement, écart ≤ 1e-9 ≈ 1 ulp), R-RAYON (rayons fournis chevauchants → ambigu), R-PAIRE0, R-DIST1/2 (via STEP, non validée).
Tests : D1-D13 définis dans le fichier de tests (ils ne préexistaient pas dans le dépôt) + X1, X2 : 16/16 PASS. Au premier passage 4 FAIL : D3, D7, D10 = données de test (flottant, clés en collision) ; D5 = défaut réel de la règle (R-DIST1 ignorait les rayons), corrigé par R-RAYON après revue (la donnée avait d'abord été modifiée à tort).
Rejeu T1b : 185 821 lignes → 185 810 (ancienne dédup) → 185 814 consolidées (contrôle de cohérence, pas un objectif ni une preuve d'exhaustivité). 7 doublons de frontière confirmés un par un (écart exactement 0, une valeur identique par worker dans chaque zone de chevauchement) ; 4 paires (écarts 3,028e-3 ; 7,169e-3 ; 7,241e-3 ; 7,787e-3, toutes intra-worker) laissées AMBIGUOUS (variante A, décision de hprzeta).
Z-sign (4 paires, nice -n 19, 1 cœur) : rejeu du scan principal et d'illinois_refine_arb (les 8 candidats stockés retrouvés bit pour bit), mpmath dps 30 et 50 : 2 changements de signe par paire, signes stables entre dps, $|Z|$ au milieu de 3,6e-5 à 1,6e-3, racines indépendantes à ≤ 2,8e-9 des candidats. Statut : CORROBORATED_NUMERICALLY (pas certifié ; l'erreur de Z_double n'est pas bornée dans le code).

Git (sans --force, audit : 0 résultat). Commit c46c12b (4 fichiers, 1 089 lignes) ; Riemann_Lab_IA et Riemann_Lab_C c46c12b, main 1c63459, Riemann_Lab_Test abf804d (fusions par worktrees, 0 conflit). resultats_v17/ (sorties) volontairement non versionné.

Reste ouvert / décisions : choix d'une phase suivante (checkpoints périodiques et atomiques, journal des exceptions, désactivation ou réécriture de Turing/LMFDB sur sous-intervalle, conservation bracket/segment/résidu dans les CSV) ; certification FLINT (isolate_hardy_z_zero) : coût non mesuré ; compatibilité V16 sur le second poste non traitée (rien modifié) ; correction des docs obsolètes (STEP, seuil) après validation.

2026-10-15 — 17h30 — V16 : test T1b, la déduplication à `tolerance=0.01` supprime de vrais zéros (hypothèse §3.1 confirmée sur [4 900 000 ; 4 986 000]) — aucun commit

Contexte. Audit de v16 en vue de v17 et référence de performance T=100 000 (6 runs, SHA-256 identiques) consignés dans analyse_problemes_v16_v17. Hypothèse §3.1 : à grand $t$, des zéros distants de moins de 0,01 existent réellement, et dedupliquer(tolerance=0.01) (parallel_scanner.py:148) en supprime. T1b = scan v16 ciblé sur [4 900 000 ; 4 986 000], sans rescan, 8 workers.

Incident. Un premier T1b, lancé à 15h36, a été tué à 16h03 avec un distribute T=500 000 lancé à 15h41 en parallèle sur PC1 : redémarrage de la session graphique (aucune donnée récupérable, car v16 n'écrit rien avant la fin ; log muet, checkpoints/ vide). Le côté PC2 de ce distribute avait échoué dès le lancement (ImportError: cannot import name gettz, pandas, Python 3.11). Deux turbo_on consécutifs avaient écrasé l'état sauvegardé de /tmp/zeta_turbo_state.txt (sans conséquence : turbo_off remet powersave en dur). T1b a été relancé seul à 16h12 et s'est terminé à 16h45 (33,0 min, code 0) ; turbo_off du script a restauré gouverneur, swappiness et services. Sous charge, la fréquence est passée de 3,5 à 3,0 GHz (stable ensuite), package à 73–76 °C.

Résultat (mesuré). 185 821 zéros bruts (concaténation des 8 checkpoints/worker_*.csv), 185 810 après déduplication : 11 supprimés.

7 doublons artificiels : écart exactement 0, même racine trouvée par deux workers voisins (recouvrement de 0,5), un par frontière.
4 paires réelles : écarts 3,03e-3 (t = 4 926 490,100), 7,17e-3 (4 927 353,414), 7,24e-3 (4 958 530,097), 7,79e-3 (4 933 944,885). Confirmées par mpmath (siegelz, dps 30) : Z change de signe de part et d'autre d'un point intermédiaire de signe opposé, les deux racines raffinées indépendamment restent distinctes (écarts confirmés 3,028e-3 ; 7,169e-3 ; 7,241e-3 ; 7,787e-3). Zéros distincts réels : 185 814.
Comptage (Backlund, $\theta$ asymptotique, facteur $e$, $S(T)$ ignoré, _n_zeros_expected non utilisé) : $N(b)-N(a)=185,813{,}56$ ; déficit +3,56 avant correction, −0,44 après.
Motif v13 non reproduit : 0 écart ≤ 0,0100 et 0 dans [0,0100 ; 0,0105[ (minimum 0,011474) ; dans le brut, aucun écart entre 0,0078 et 0,0115.

Déduit. La validation Turing de v16 (« 9 800 393 manquants ») et le score LMFDB 0/20 sont des artefacts d'intervalle partiel (delta constant ≈ nombre de zéros avant 4,9M ; LMFDB comparé aux zéros n° 1 à 20). Hypothèse. Dédupliquer à tolérance très fine (≈ 1e-9) et seulement dans la zone de recouvrement entre workers. Limites. Un intervalle de 86 000 en $t$ ; $S(T)$ non traité (±1 à 2 zéros sur le comptage ; la preuve repose sur les signes mpmath) ; 4 cas seulement.

Documents. analyse_problemes_v16_v17.md mis à jour en deux copies identiques (232 lignes) : §3.1, ligne T1 du §4, §5. Le fichier du wiki n'est pas suivi par git. Copies .bak-20261015 conservées. Rien n'est commité. Pièges. Terminal ouvert dans ~ : sudo scripts/zeta_turbo_off.sh introuvable ; python3 -I ne voit pas le venv (utiliser zeta_env/bin/python3 -I) ; ne jamais lancer deux gros runs en même temps sur PC1.

2026-10-10 — 13h45 — Boot du clone Toshiba validé (v2.3) puis `zeta_backup_toshiba.sh` v2.4 : garde-fou de sens et restauration inverse — commits `01bd5b7`, `3681f19`, `bcf7f9c`, `b58742f`, `bb2b5d8`

Boot du clone (v2.3). Symptôme : démarré depuis le disque externe, le noyau montait la racine du disque interne. Cause constatée : le rsync de / recopie /boot/grub/grub.cfg du disque source (27 occurrences de son identifiant de volume). Correctif : fix_grub() (update-grub en chroot après chaque clonage, vérification des identifiants, démontage garanti par trap EXIT), option 6 (vérification en lecture seule, 7 contrôles dont une alerte resume), option 7 (réparation sans rsync). Boot réel validé. Test fiable pour savoir sur quel disque on est : le LABEL de la racine (+ colonne TRAN de lsblk), pas ID_BUS (il vaut ata derrière le boîtier USB→SATA). zeta-boot-id affiche une bande rouge sur le clone, verte sur le disque interne. Commits 01bd5b7 (script v2.3), 3681f19 (rapport + PDF), bcf7f9c (zeta_backup_horsgit.sh : pipefail, code retour réel en --auto ; vérifié par bash -n seulement). Propagés le 10/10 aux 4 branches (0 conflit).

Script v2.4 (b58742f). Garde-fou de sens : toute écriture sur le clone (clonage, réparation du boot, fix_fstab, fix_grub en mode clonage) exige que la racine en cours soit celle du disque de travail, sinon refus (« Sens inverse interdit », code 1, aucune écriture). Nouvelles options : 8 restauration clone → disque de travail (garde-fous, dry-run automatique, rsync --delete, fstab et GRUB inversés, grub-install + efibootmgr si la partition EFI est vide) ; 9 préparation d'un disque neuf (GPT + systèmes de fichiers par labels, nombreux refus de sécurité) ; 10 restauration d'un fichier ou dossier précis sous /home ou /mnt/data, sans suppression ; option globale --dry-run. Les fonctions de réparation sont désormais communes aux deux sens. Documentation : section « Script v2.4 » du rapport de clonage (procédure pas à pas, limites), PDF régénéré.

Constat sur les dossiers Documents/SAP* (travail hors projet, exclu du clone depuis la v2.1) : l'exclusion empêche toute nouvelle copie mais, sans --delete-excluded, ne supprime pas l'existant ; le clone garde donc une ancienne copie antérieure à l'exclusion (environ 4 Go, comptages seulement, aucun contenu lu). Décision du 10/10 : laissée en place, documentation corrigée (bb2b5d8), hors périmètre des restaurations.

Vérifié le 10/10. Clone rafraîchi à 13h26 avec le script v2.4 : dry-run relu (21 suppressions, toutes jetables : caches, journaux, copies de session), puis 8 contrôles de bootabilité sur 8 OK. Garde-fous, options 9 et 10 et arguments testés en simulation seulement (aucune écriture sur un disque). Contrôles et refus testés ; shellcheck absent du poste.

Non testé en réel. Dry-run des options 8 et 10, rsync inverse, grub-install/efibootmgr (ne sera éprouvé qu'au premier remplacement de disque). Prochaine étape : au prochain démarrage sur le clone, dry-run des options 8 et 10 puis restauration réelle d'un dossier de test avec l'option 10. Aucune restauration complète sans accord explicite.

Test de restauration (option 10, le soir du 10/10). Démarrage sur le clone, puis restauration d'un dossier de test vers le disque de travail : dry-run = 3 éléments, aucune suppression, garde-fous OK (sens clone → disque de travail) ; restauration réelle OK, sans --delete ; le fichier de test est revenu (74 octets, contenu relu). Option 10 validée en réel. Toujours non confirmés : le dry-run global et le dry-run de l'option 8 (exclusion des dossiers SAP* à vérifier) ; l'option 8 réelle n'a jamais été jouée et ne le sera pas sans accord explicite. Le dossier de test reste en place sur le disque de travail (suppression soumise à confirmation).

Branches (distant, sans --force, audit avant chaque push : aucun résultat). Riemann_Lab_IA et Riemann_Lab_C bb2b5d8 (C en fast-forward) · main 1c3bf29 · Riemann_Lab_Test 7b59bec (fusions de IA par worktrees isolés, 0 conflit ; arbre de main identique à IA, Test = IA + 2 fichiers d'expérience). docs/ inchangé (Pages non reconstruit). Détail du suivi privé : ~/riemann_handoff/Handoff.md.

2026-10-06 — 23h59 — PDF des archives : tableaux coupés corrigés, archive du 06/10 complétée (partie B), propagation sur les 4 branches

Défaut constaté. En régénérant l'archive du jour, la dernière colonne de chaque tableau était absente du PDF (déjà vrai de l'ancien PDF du 06/10 : troisième colonne du tableau « bye bye » coupée). Cause : le script de génération (scripts/build_pdf_riemann_CM.sh) lisait le Markdown avec le lecteur gfm de pandoc, qui ne calcule pas de largeur de colonne ; les cellules ne passaient donc pas à la ligne.

Correctif (836f873, une ligne de commande + commentaire) : lecteur markdown avec les extensions qui reproduisent gfm (liste sans ligne vide préalable, liens nus, texte barré, cases à cocher). Sauvegarde du script avant modification. Non-régression : comparaison mot à mot ancien/nouveau PDF sur 7 documents. Archive du 20/09 (sans tableau) : identique. Archive du 04/10 et synthèse des skills : le texte coupé est restitué (+114 et +1 109 mots), les rares « mots perdus » ne sont que des fragments tronqués de l'ancien rendu. Trois pages du wiki riches en formules : même nombre de pages, texte identique ou quasi (un en-tête de tableau se replie sur plusieurs lignes). Un guide du dépôt échoue à la génération avec l'ancien comme avec le nouveau script (non investigué).

Archive du 06/10 complétée (c1be1b8) : partie A (après-midi) conservée, partie B (soir, sections 9 à 17) ajoutée d'après le modèle du 04/10 ; 212 lignes, 9 pages (4 avant) ; audit du .md et du texte du PDF : aucun résultat. La capture brute du terminal est absente pour cette session ; la transcription automatique a été convertie avec le nouvel outil.

Propagation, sans --force, audit avant chaque push (0 résultat). Riemann_Lab_IA et Riemann_Lab_C : 09a40a4 → c1be1b8 (C en fast-forward) ; main : b86cf96 → ded1b78 et Riemann_Lab_Test : 3ca0405 → ac702b3, par fusion de IA sans conflit. Arbres : main et C identiques à IA ; Test = IA + 2 fichiers d'expérience. Le site public est servi par Riemann_Lab_IA (/docs) : reconstruction vérifiée (build réussi, HTTP 200). Worktrees et branches temporaires supprimés.

Restes. Régénérer les PDF des anciennes archives avec le script corrigé ; rotation du jeton DNS dynamique ; décision de masquage de quelques identifiants de disque déjà publics ; plan de continuité à régénérer ; divergence de matériel entre les schémas et STACK.md.

2026-10-06 — 23h00 — Alignement des 4 branches (IA, C, main, Test) : fusions sans réécriture d'historique, gardes `.gitignore` reportées, site vérifié

Constat. Les purges du 04/10 ont réécrit les historiques : mêmes contenus, SHA différents, donc la comparaison par commit (git cherry) n'était pas fiable ; la comparaison par arbres de fichiers l'était. Base commune 9c0044f (16/08). Riemann_Lab_IA était la plus avancée (infrastructure, skills, documentation), mais Riemann_Lab_C avait du code que IA n'avait pas : compute_zeros_v16.py avec checkpoints (persistance du CSV avant le rescan, ajoutée après la perte de 31 h du run T=5M), scripts de run, logs de suivi. Les gardes .gitignore sur les dossiers de secrets n'existaient que sur C.

Méthode. Fusion d'essai dans un worktree isolé (aucune branche touchée), conflits tranchés zone par zone (git merge-file --theirs, qui garde les parties fusionnées sans conflit, contrairement à checkout --theirs), validation (91 fichiers Python et 31 scripts bash sans erreur de syntaxe), audit des lignes ajoutées avant chaque push, fast-forward des branches (jamais de --force).

Résultat. IA et C : 09a40a4 (44 et 60 commits poussés). main : b86cf96 (101 commits, arbre identique à IA, vérifié). Riemann_Lab_Test : 3ca0405 (101 commits, IA + 2 fichiers d'expérience d'avril 2026 conservés). 8 conflits de purge entre C et IA (artefacts de purge côté C écartés), 8 entre main et IA, 5 entre Test et IA, tous de même nature. 14 identifiants de volume d'un rapport de clonage ont été masqués et le PDF régénéré. Le test A/B scan_arb est désormais suivi sur IA. Le correctif .gitignore (+10 lignes) a été reporté sur IA.

GitHub Pages est servi par Riemann_Lab_IA (/docs), pas par main : reconstruction vérifiée après le push (build réussi, page identique au dépôt, aucune balise de conflit).

Notés, non traités. Quelques identifiants de disque déjà publics (rapport de clonage, un script) et un DNS public utilisé comme sonde de routage restent présents sur les 4 branches ; décision de masquage à prendre. Rotation du jeton DNS dynamique toujours à arbitrer. Archive de session du 06/10 à compléter.

2026-10-06 — 22h00 — Convertisseur `.jsonl` → `.md` de la transcription Claude Code, tri des fichiers non suivis terminé (groupes A à I), push de `Riemann_Lab_IA` et `Riemann_Lab_C`

Convertisseur de transcription. Claude Code garde automatiquement chaque session dans un fichier .jsonl ; capture.sh, lui, n'enregistre que le terminal où il est lancé (la capture de l'après-midi était vide). Nouveau script scripts/zeta_jsonl_to_md.py, alias zeta-convert-jsontomd (commit 35ad4e7, poussé) : lecture seule du .jsonl ; messages et réponses conservés, appels d'outils réduits à une ligne, sorties d'outils et raisonnement interne omis ; masquage des adresses IPv4/IPv6, MAC, e-mails, noms de domaine dynamique, jetons, clés privées et des valeurs réelles du cluster (lues dans un fichier hors git) ; contrôle de seconde passe : si un nouveau masquage change encore le texte, le fichier n'est pas écrit. Sortie en mode 600 dans un dossier ignoré par git. Option --liste pour choisir la session. Test sur 3 sessions (la plus lourde : 11 Mo → 320 Ko, 4 443 lignes) : une recherche indépendante ne trouve aucune adresse ni MAC résiduelle ; il ne reste que des mots (nom du service, préfixes de jeton) dans des discussions d'audit. Limites : sorties d'outils absentes (elles restent dans le .jsonl), masquage volontairement large (un numéro de version à quatre nombres serait masqué), les 4 443 lignes n'ont pas été relues en entier.

Tri des fichiers non suivis (groupes A à I) — terminé. Chaque groupe a été audité (adresses, secrets, e-mails, chemins) puis commité séparément depuis Riemann_Lab_IA : A e21a309 (générateurs du cours), C 50af109 (3 schémas SVG ; le plan de continuité est déplacé de images/ vers pdf/, octet pour octet identique), D bfd7481 (synthèse des audits de skills), E 202a819 (2 rapports), F 127f478 (3 PDF), G fc782df (guides RAG et vault ; l'ancien Guide-RAG, qui contenait des adresses, est supprimé et remplacé par la version masquée), H 7115134 (archive du 20/09), I 85e992b (méthode de sauvegarde chiffrée, corrections wiki KaTeX), plus l'archive du 06/10 06e2367. Le groupe B (test A/B scan_arb v13 contre v16) est écrit pour la version de compute_zeros_v16.py de Riemann_Lab_C (paramètres dossier et suffixe absents du v16 de Riemann_Lab_IA, où il planterait par TypeError) : commité sur Riemann_Lab_C seulement (2084ac1), sans exécution.

Audit global avant push. 27 fichiers : lignes ajoutées, texte extrait des PDF, valeurs réelles du cluster, IPv4/IPv6, MAC, e-mails, UUID, jetons, noms de fichiers sensibles, taille. Aucun résultat. Push sans --force : Riemann_Lab_IA 35ad4e7 → 06e2367, Riemann_Lab_C 942b5e3 → 2084ac1. Les PDF n'ont pas été relus page par page.

Notés, non corrigés. Le plan de continuité (PNG) est périmé (compte de zéros ancien, emojis en carrés, faute dans l'adresse de contact) ; deux schémas utilisent context-stroke pour les flèches (affiché par les navigateurs, refusé par ImageMagick) ; les schémas de matériel (inventaire du 03/10) et STACK.md divergent toujours sur la RAM de PC2 et le modèle de PC3 ; une formulation de rapports/audit_reco_IA_2026-09-12.md est à reformuler.

Restes. Une suppression de PDF non commitée (son remplaçant est ignoré par git), le dossier des textes d'IA tierces à ignorer ou non, un script de test non suivi sur Riemann_Lab_IA, rattrapage de Riemann_Lab_C (commits d'outils du 03/10) et de main, rotation du jeton DNS dynamique, archive du 06/10 à compléter (elle date de l'après-midi).

2026-10-06 — 15h00 — Sauvegarde Proton validée, témoin retiré, tri des fichiers non suivis, alias SSH à bascule automatique maison/voyage — aucun commit de code

Sauvegarde Proton (nuit 03→04/10). Le journal de la copie nocturne montre 27 fichiers sur 27 transférés en 48,6 s, sans fichier en échec. Les avertissements 422 (« existe déjà ») et 429 (trop de requêtes) sont bénins ; des 401 (jeton expiré) apparaissent sur certaines nuits et sont rattrapés. Nuits du 05 et du 06 : « rien à transférer ». Le fichier témoin est confirmé dans l'interface web de Proton. Il a été supprimé sur PC1 et PC3 (sur PC3, le dossier appartient à un autre compte : suppression par sudo, un seul fichier, aucun droit modifié).

Tri des fichiers non suivis (analyse seule, aucun commit). 36 fichiers (23 entrées) : 28 propres, 6 à masquer ou régénérer avant commit (adresses privées ou nom de domaine dynamique), 2 à garder hors dépôt. Un jeton de mise à jour du DNS dynamique est probablement présent dans un ancien PDF de la documentation sécurité (hors git, mais copié par la sauvegarde) : rotation à arbitrer.

Alias SSH à bascule automatique. Constat : à distance (tunnel actif, qui ne route que le réseau du tunnel), les alias pointaient vers des adresses LAN et expiraient (~2 min). Correctif dans ~/.ssh/config (local, hors dépôt) : pour chaque nœud, un Match originalhost … !exec "nc -z -w1 <IP_LAN> 22" bascule en ProxyJump par le bastion si le nœud n'est pas joignable en direct ; l'alias du bastion utilise l'adresse du tunnel ([WG_PC4]) hors LAN ; ConnectTimeout 5 et keepalive sur tous les zeta-*. Test réel : à distance, les 4 alias répondent (PC4 direct par le tunnel, PC2/PC3/PC5 par saut) ; retour au LAN : les 4 repassent en direct sans saut. Procédure et bloc modèle d'ajout d'un nouveau poste → Guide-WireGuard-Acces-Distant §5.1 et §5.2.

Incident noté. nc affichait « Connection … succeeded » à chaque test et exposait des adresses LAN privées dans la sortie ; corrigé par >/dev/null 2>&1 dans les Match exec.

Limite connue. Sur un autre LAN utilisant la même plage d'adresses, une machine répondant sur le même port 22 serait contactée ; la clé d'hôte (known_hosts) la refuserait. Forcer le saut : ssh -J zeta-bastion-wg <alias>. Non testé sur un réseau réel.

2026-09-27 — 21h30 — Chantier MCP OmniRoute clos : validation end-to-end + service systemd + doc à jour — commit `3e352a3`

Contexte : reprise du chantier MCP omniroute entamé plus tôt le 27/09 (3 causes diagnostiquées en amont de cette session : mauvaise version de Node résolue via PATH (v18 système au lieu de v22 nvm requis), pollution de stdout par console.debug() (casse le framing JSON-RPC), DB (ensureDbInitialized()) jamais appelée au démarrage de startMcpStdio() — patches appliqués mais non encore validés en conditions réelles à ce stade).

Validation end-to-end :

omniroute_get_health répond en JSON valide via la vraie connexion MCP de Claude Code (plus de CONNECTION_CLOSED ni erreur DB) — les 3 patches tiennent en conditions réelles, pas seulement en standalone.
Découverte que le champ degraded (fetch failed sur health/resilience/rateLimits) n'était pas cosmétique : omniroute_route_request (chat completion réel) dépend du même backend HTTP local (OMNIROUTE_BASE_URL=http://localhost:20128) — sans lui, aucun appel provider ne fonctionne, pas seulement le monitoring.
Backend mis en service durable : la commande intégrée omniroute autostart enable a choisi un mécanisme XDG desktop (~/.config/autostart/*.desktop, ne démarre qu'en session graphique) sans option pour forcer systemd. Décision : désactivé (omniroute autostart disable) puis unit systemd --user créée manuellement (~/.config/systemd/user/omniroute.service, ExecStart = binaire Node 22 nvm + omniroute serve --no-open, Restart=on-failure).
Piège permission découvert : l'écriture directe de cette unit via l'outil Write de Claude Code a été bloquée par le classificateur de permission (motif « Unauthorized Persistence » — création d'un service à démarrage automatique). hprzeta a créé le fichier lui-même via son propre shell (!), non soumis au même classificateur. systemctl --user enable --now omniroute → actif, port 20128 en écoute sur 127.0.0.1 (cohérent avec OMNIROUTE_SERVER_HOST dans ~/.omniroute/.env), /api/monitoring/health → 200 healthy.
Test réel réussi : omniroute_route_request avec model: "nvidia/nemotron-3-super-120b-a12b" et la question « valeur de zeta(2) ? » → réponse correcte ($\pi^2/6$, Bâle/Euler), 27 tokens prompt / 612 completion, latence 8.4s. Pipeline complet validé : MCP stdio → backend HTTP systemd → provider NVIDIA → réponse. (aiml/deepseek-chat écarté — 401 No active credentials for provider: aimlapi, non configuré côté OmniRoute ; non prioritaire.)
Résiduel non bloquant : get_health/check_quota/list_models_catalog renvoient 403 AUTH_001 Invalid management token (token de gestion à régénérer via le dashboard OmniRoute si besoin de ces outils précis) — n'empêche pas le routage réel.

Documentation mise à jour et commitée (3e352a3 sur Riemann_Lab_IA, poussé sur origin ; riemann-security-review passé avant commit — verdict 🟢, aucun secret, .mcp.json réel toujours ignoré) :

riemann-agent-bridge/SKILL.md — nouvelle section §1bis (accès OmniRoute : prérequis Node 22 explicite + service systemd port 20128, préfixe provider obligatoire type nvidia/..., limitation token de gestion, règle « source de contexte pas de vérité »).
.mcp.json.example — entrée omniroute ajoutée (chemin Node 22 nvm explicite, commentaire sur le piège PATH et la dépendance au service systemd).

Leçon retenue : toute action de persistance système (unit systemd, autostart XDG, crontab) sera bloquée si tentée via l'outil Write de Claude Code — fournir directement les commandes ! à hprzeta plutôt que d'insister.

Voir aussi

Handoff — bloc REPRISE réécrasé avec cet état

2026-09-27 — 20h30 — Vague V2bis : ajout du skill riemann-proof-status (inspiré evomath-tao/research-state) — commit `8a2ef34`

Contexte : en parallèle des Vagues V1-V3 (entrée 18h00 ci-dessous), deux sources externes évaluées (synthese_skills_zeta.md §4.2bis) : le plugin mathbox (nidrissi, MIT) et le dépôt EvoScientist/EvoSkills (Apache 2.0, 436★). Aucun des deux importé tel quel — leur logique de statuts honnêtes (evomath-tao) et de registre append-only (research-state) a inspiré un 8ᵉ skill sur mesure pour Riemann_Lab.

riemann-proof-status (.claude/skills/riemann-proof-status/SKILL.md, fichier additif) formalise l'exigence déjà en place de distinguer prouvé / conjecturé / vérifié numériquement / heuristique / transmis pour toute affirmation mathématique du projet :

5 statuts stricts : PROVED, CONJECTURED, VERIFIED_NUMERICALLY, HEURISTIC, HANDED_OFF — jamais deux à la fois, jamais un glissement de langage sans preuve nouvelle.
Registre append-only proposé (docs/proof_status.md, à créer au premier usage) — un bloc par affirmation, jamais réécrit, historique de statut en ligne datée séparée.
Checklist de changement de statut : VERIFIED_NUMERICALLY ne devient jamais directement PROVED (même sur des milliards de cas) ; un résultat Ollama/RAG BrainVault ne peut jamais entrer directement en PROVED/VERIFIED_NUMERICALLY ; toute contradiction avec un résultat déjà PROVED déclenche un HANDED_OFF immédiat, jamais tranché seul.
Règle de fraîcheur : grep périodique des entrées CONJECTURED/HANDED_OFF de plus de ~2 mois avant de repartir dessus comme si rien n'avait changé (même logique que la fraîcheur RAG déjà documentée).

État des skills sur Riemann_Lab_IA : 8 au total — les 7 de l'entrée 18h00

riemann-proof-status. Fichier purement additif, diff vérifié, commit séparé (8a2ef34) et poussé sur origin/Riemann_Lab_IA.

2026-09-27 — 18h00 — Vagues V1-V3 du plan de mutualisation skills/MCP (AGENTS.md, 3 nouveaux skills, mise à jour code-review/security-review) — commits `df46f82`, `9e0b203`, `5e3a44d`, `70e7463`

Contexte : synthèse croisant 4 audits externes (Kimi, Perplexity, DeepSeek, Grok) du dépôt Riemann_Lab, complétée par des vérifications terrain (RAG BrainVault, chiffres v15/v16). Document de référence : synthese_skills_zeta.md (projet claude.ai « SKILLS ZETA », copie possible dans pdf/audits_skills/). Branche Riemann_Lab_IA.

Vague V1 (commit `df46f82`) — fichiers additifs

AGENTS.md : contrat de répartition Claude Code / Codex / Ollama.
.mcp.json.example : gabarit MCP (github, filesystem) avec ${GITHUB_TOKEN} en variable d'environnement — le vrai .mcp.json reste local et ignoré (.gitignore:40, règle pré-existante, non contournée).
handoff/claude_to_codex.md et handoff/codex_to_claude.md : templates de passation de tâches entre agents.

Vague V2 (commit `9e0b203`) — 3 nouveaux skills

riemann-agent-bridge : exploite AGENTS.md, coordination multi-agents.
riemann-literature-scout : veille arXiv + universités US/Chine/Russie.
riemann-statistics-gue : analyse statistique (Montgomery, GUE vs Poisson) — Étape 2 de la roadmap.

Vague V3 (commits `5e3a44d` puis `70e7463` correctif) — mise à jour de 2 skills existants

Contenu enrichi sans suppression :

riemann-code-review : nouvelle §8 « optimisations Arb/Flint v12→v16 » (précision fixe 64 bits, SEUIL_1NEWTON, acb_dirichlet_hardy_z, headers Flint vendorisés, distinction benchmark T=100k vs débit réel de production ~128 z/s). Le correctif 70e7463 a confirmé par lecture directe du code (illinois_arb.c:48-59/119, scan_arb.c:27-38) que le cache log_n_cache/isqrt_n_cache (Riemann-Siegel) est bien implémenté et actif en v13/production — initialisé après fork via init_rs_cache(), couvre jusqu'à T≈27M. θ(t) lui-même n'est pas mis en cache (calcul Stirling par t, non pertinent à cacher).
riemann-security-review : nouvelle §8 « sécurité MCP » (scope minimal du token GitHub, chemins exposés par le serveur filesystem, rotation de token, secrets dans logs/CSV, règles pour un futur MCP arxiv).

État des skills sur `Riemann_Lab_IA`

7 skills au total : riemann-lab, phase-c-illinois, riemann-code-review, riemann-security-review (les 4 historiques, 2 mis à jour), riemann-agent-bridge, riemann-literature-scout, riemann-statistics-gue (les 3 nouveaux). Rien supprimé, tous les changements vérifiés par diff avant commit.

Décisions ouvertes / reprises dormantes (voir `synthese_skills_zeta.md` §6, items 4-6)

Réingestion RAG BrainVault (corpus figé depuis le 25/07/2026, ~2 mois de retard : v16, T=5M, sessions/skills manquants) — timing à décider.
« Cerveau autonome zêta » (vision 23 points : agents connaissance/recovery, Obsidian, backup 3-2-1) — à décider si chantier séparé ou intégré.
Anomalie non résolue : déficit de 63 zéros entre un run MARGE_SECURITE=10.0 et un run MARGE=2.0 (contredit la monotonie attendue), ambiguïté entre deux totaux de zéros à T≈5M (10 016 377 vs 10 016 297/474) — à investiguer avant de figer une référence.

Vagues restantes du plan (non lancées, en attente de validation explicite)

V4 (risque 🟡 faible) : tests/ (pytest illinois/scan_arb/turing) + .github/workflows/ (CI légère). Nécessite de figer au préalable les E/S de illinois_refine et scan_arb.
V5 (risque 🟠 moyen, en dernier, confirmation explicite avant tout commit) : scinder phase-c-illinois (règles vs journal), fusionner CLAUDE_projet_zeta.md dans CLAUDE.md (archiver l'ancien, ne jamais supprimer), migrer les scripts via liens symboliques temporaires (contrainte .bashrc documentée par Kimi).

2026-09-13 (suite) — Sémantique MARGE_SECURITE + git blame aux jalons validés + R6 précision Arb — verrou moteur, lecture seule, non commité

Contexte : suite directe de l'audit du même jour. hprzeta fournit PROMPT_marge_securite_et_R6_2026-09-12.md : établir la sémantique exacte de MARGE_SECURITE, son historique aux jalons validés (git blame), et documenter la stratégie de précision Arb (R6) — avant tout choix de valeur et tout rerun T=5M. Verrou moteur durci : interdiction absolue de toucher au cœur de calcul, aux constantes de calibration ou aux fichiers compute_zeros_v16.py/v15.py/zeta_run.sh/ riemann_siegel_batch.py, même à titre d'essai. Seul autorisé : lecture, grep, git log/blame/show, et un script scratch jetable hors dépôt pour la vérification R6.

1. Sémantique exacte de MARGE_SECURITE (Tâche A)

MARGE_SECURITE est le diviseur final de _step_adaptatif() (compute_zeros_v16.py:707-826) : STEP(T) = min_gap(T) / MARGE_SECURITE, où min_gap est l'estimation du plus petit écart attendu entre zéros. STEP est directement le pas de la grille np.arange utilisée pour détecter un changement de signe de $Z(t)$ — pas une largeur de bracket, pas une marge de précision numérique, pas un espacement de points de Gram. Marge trop petite → grille trop grossière → deux zéros proches peuvent tomber dans le même pas et s'annuler silencieusement (mécanisme confirmé comme cause des 96 manquants). Marge plus grande → grille plus fine → surcoût quasi-linéaire en 1/MARGE_SECURITE, sans risque de fausse fusion : le dédoublonnage existant (parallel_scanner.py:148-166, tolérance 0.01) absorbe toute finesse supplémentaire, l'espacement minimal réel entre zéros (~π/ln(T/2π)) restant très supérieur à ce seuil pour T < 10⁶.

2. Git blame aux jalons validés (Tâche B)

Correction du prompt source : le commit f48da88 cité pour « v16 T=100k Turing complet » est en réalité un fix RAG sans rapport (fix(rag): rag_query.py — défaut --k 3→8, 25/07). Le commit réel est 00abe5c (08/08, intégration v16).

Commit	Date	`MARGE_SECURITE`	Résultat connu
`a0e6e41`	04/07	2.0	96 manquants T=5M
`a7fb498`	02/08	→ 3.0	restauration, jamais validée à grande échelle
`a04ea1f`	02/08	→ 15.0	3.0 testé et confirmé insuffisant à T≈4,86M
`bbb8a6f`	02/08	→ 10.0	0 manquant sur 3 zones + pivot réel PC1+PC2
`00abe5c`	08/08 (v16 prod)	10.0 (déjà actif)	T=100k Turing COMPLET, LMFDB 20/20

Conclusion : MARGE_SECURITE=10.0 est la seule valeur avec une trace de validation empirique à grande échelle (isolée et en configuration distribuée réelle). 3.0 n'a pas seulement été remplacée — elle a été testée spécifiquement et trouvée insuffisante (a04ea1f). La croyance « 3.0 = calibration validée » (CLAUDE.md racine + Recommandations_LAB_et_prompt.md + Formation_Zeta_HR_Riemann_Lab.pdf) est donc contredite par l'historique git lui-même, pas seulement périmée par rapport à la valeur active.

3. R6 — précision Arb, documentation lecture seule (Tâche C)

Précision fixe 64 bits, indépendante de $t$, confirmée à 3 niveaux de source (compute_zeros_v16.py:19-20, illinois_arb.c:94,148,156 — un seul appel acb_dirichlet_hardy_z, jamais d'escalade, contrairement à l'ancien chemin v15). Table par décade produite (t=10 à 5×10⁶) : $R(t)\approx2\sqrt{t/2\pi}$ croît en $O(\sqrt t)$ (nombre de termes RS, gouverne le coût), tandis que la précision demandée reste constante — propriété de l'arithmétique d'intervalles Arb, pas un réglage manuel par décade.

Vérification échantillonnée (script scratch hors dépôt, supprimé après usage, appel-seul via illinois_refine_arb sur des brackets réels — Z_arb étant static, non exportable sans modifier le .c, ce qui aurait violé le verrou) : écart max 6,96e-8 à t≈14,135 (hors domaine d'usage réel — le moteur route explicitement t<65 ailleurs, garde-fou déjà en place) ; 1,455e-11 au pire point effectivement en production (t=10⁵) ; 0 ailleurs. Aucune recalibration effectuée.

4. Livrable et documentation

Rapport unique : rapports/marge_securite_et_precision_2026-09-12.md (dépôt de code, branche Riemann_Lab_C, non commité). Ne tranche pas 3.0 vs 10.0 — un gate empirique T=100k (prompt suivant, pas encore lancé) décidera du surcoût réel. Aucun fichier moteur modifié, aucun commit. STACK.md (note MARGE_SECURITE renforcée avec la table de blame) et ~/riemann_handoff/Handoff.md mis à jour en conséquence (demande hprzeta « met handoff stack à jour »).

Prochaine action

Gate empirique T=100k pour objectiver le surcoût réel de MARGE_SECURITE=10.0 (ou d'une autre valeur) avant tout rerun T=5M — pas encore lancé, en attente d'un prompt dédié.

Voir aussi

Handoff local (~/riemann_handoff/Handoff.md) — section « REPRISE ICI », entrée 13/09/2026 (suite).
Entrée du 2026-09-13 ci-dessous (audit initial, matrice de 24+30 règles).

2026-09-13 — Audit lecture seule des recommandations IA externes (DeepSeek/Kimi/Grok) + 2 documents du LAB — matrice de 24+30 règles confrontées au code réel, non commité

Contexte : hprzeta fournit PROMPT_audit_reco_IA_2026-09-12.md (Téléchargements) : auditer en lecture seule (aucune écriture de code, aucun commit, aucune exécution longue) ce que 3 IA externes ont recommandé pour Riemann_Lab, sachant qu'elles n'ont lu que le wiki/README sans le contexte du moteur de production — avant de passer à l'étape 2 (VAULT/IA locale). Puis extension demandée avec Recommandations_LAB_et_prompt.md et Formation_Zeta_HR_Riemann_Lab.pdf (mêmes règles).

1. Vérité terrain (Tâche 1)

Pipeline de production réel confirmé : compute_zeros_v16.py, seul point d'entrée réel de scripts/zeta_run.sh. Preuves fichier:ligne : Hardy Z via acb_dirichlet_hardy_z/Arb (compute_zeros_v16.py:63), Turing-Backlund atteint et loggé (:964, section [6] du log), N(T) Riemann-von Mangoldt avec le facteur e correct (:93, :241).

2. Matrice d'applicabilité (24 recommandations A1-A5/R1-R15/C1-C4)

5 DÉJÀ FAIT (souvent supérieur à la reco — ex. A4 : cluster+Arb+Pool bat la parallélisation multiprocessing.Pool/float64 naïve proposée), 2 APPLICABLE, 3 À RAFFINER, 2 NE PAS TOUCHER (A3/R5 : repasser par mpmath serait une régression de perf vs Arb), 2 OBSOLÈTE, 12 ÉTAPE 2 (hors périmètre calcul — VAULT, GUE, ψ, Lean 4, cartes de phase…), 1 SANS OBJET (C1 : aucune série $\sum n^{-s}$ directe dans le pipeline, grep négatif confirmé).

Point de vigilance tranché : R1 (colonnes CSV $|\zeta(\rho)|$/$|\Lambda(\rho)-\Lambda(1-\rho)|$) — sur la droite critique cette égalité est automatique dès que $\Lambda(\rho)$ est réel ; l'intérêt réel est le contrôle de branche $\Gamma$/$\theta$, recommandation réduite à une validation échantillonnée, pas une colonne sur 10M lignes.

3. Extension avec les 2 documents du LAB (30 règles, blocs A-F)

Confirmé positivement (fichier:ligne) : to_csv() écrit avant le rescan (compute_zeros_v16.py:933-937), FLINT 3.3.1 headers vendorisés (c_modules/Makefile:27-29)

.so chargés post-fork (:147,159-160), systemd-inhibit déjà scripté (scripts/zeta_run.sh:38-40), séparation Weyl interne (_n_zeros_expected, partitionnement workers uniquement) / Turing-Backlund (validation) déjà respectée, wg0 down/up déjà automatisé (scripts/wg_auto.sh), rclone copy jamais sync (scripts/backup_cluster_map.sh:69).

Divergences trouvées : T_SEUIL_ILLINOIS_C=300 encore documenté comme règle canonique dans le CLAUDE.md racine alors que supprimé depuis v12 (Arb sans biais RS dès t≥14, confirmé par grep sur compute_zeros_v12.py à v16.py) ; scripts/push_phase0_complete.sh:36 contient un git add -A littéral (script mort de mai 2026, viole la règle « jamais git add -A ») ; CUDA_VISIBLE_DEVICES="" documenté pour le RAG mais absent de rag_query.py (appliqué manuellement au mieux, pas programmatique).

4. Divergence MARGE_SECURITE — nuancée en croisant avec ce JOURNAL

Le prompt d'audit initial et les 2 nouveaux documents affirment tous MARGE_SECURITE=3.0 « calibration validée », alors que la valeur réellement active dans le code (v15 et v16) est 10.0 (compute_zeros_v16.py:822, historique git log -S : 2.0→3.0→15.0→10.0). Mise à jour de ce Handoff/STACK en parallèle de cet audit : cette divergence est moins critique que l'audit initial ne le pensait — le diagnostic du déficit de zéros (96/177 manquants T=5M) ne dépend plus de MARGE_SECURITE depuis le 06/09/2026 (cause = fragilité RS à bas $t$, voir entrée du 06/09 ci-dessous, chantier clos côté diagnostic). Ce n'est donc pas un risque de calcul actif, mais une dette de documentation réelle (CLAUDE.md racine + Recommandations_LAB_et_prompt.md + Formation_Zeta_HR_Riemann_Lab.pdf) — le « prompt prêt à coller pour Claude Code » de Recommandations_LAB_et_prompt.md contient explicitement la valeur 3.0 et la réinjecterait dans une future session s'il est réutilisé tel quel.

5. Livrable et documentation

Rapport unique : rapports/audit_reco_IA_2026-09-12.md (dépôt de code, branche Riemann_Lab_C, non commité conformément au mode audit lecture seule). 5 tâches + bloc ## STOP avec 5 actions proposées, à valider individuellement par hprzeta. Aucune modification de code, aucun commit, aucune exécution longue — uniquement lecture de fichiers, grep, git log, rédaction. STACK.md (note « paires enjambées » du tableau T=5M et roadmap Objectif 1/Phase C) et ~/riemann_handoff/Handoff.md (bloc REPRISE) mis à jour en conséquence dans la foulée (demande hprzeta « met a jour handoff stack »).

Prochaine action

En attente de validation hprzeta sur les 5 actions du rapport (R4 journal de calibration, correction doc MARGE_SECURITE, script R1 validation échantillonnée, rerun T=5M R2+R8, nettoyage doc obsolète T_SEUIL_ILLINOIS_C/push_phase0_complete.sh). Aucune n'a été lancée.

Voir aussi

Handoff local (~/riemann_handoff/Handoff.md) — section « REPRISE ICI », entrée 13/09/2026.
Entrée du 06/09/2026 ci-dessous — diagnostic du déficit de zéros, référencé au point 4.

2026-09-12 — Correction rendu KaTeX sur l'ensemble du wiki (68 pages) — 4 causes racines distinctes identifiées et corrigées, 8 commits

Contexte : demande initiale limitée à 8 pages (\_/\# dans Formules_zeta et autour) via un prompt fourni par hprzeta. En vérifiant le rendu réel dans Chrome (claude-in-chrome), découverte que le problème était bien plus large : GitHub casse le rendu KaTeX de nombreuses façons différentes, indépendamment du bug \_/\# initial. hprzeta a validé l'extension du chantier à tout le wiki ("corrige aussi ces deux bugs" / "remplace ou recrée si tu veux").

4 causes racines identifiées empiriquement (inspection DOM, pas seulement visuelle) :

\_ \# \, \; \! \% — GitHub retire le \ devant la ponctuation ASCII même en mode math (\,/\; deviennent une virgule/point-virgule visibles, \! devient un ! visible — ex. sin!( au lieu de sin(). Fix : \,/\; → espace, \! → supprimé, \% → ％ (pleine chasse) ou déplacé hors du mode math.
Un bloc $$...$$ dont le contenu contient un retour à la ligne interne n'est jamais reconnu comme math par GitHub (document.querySelectorAll('math-renderer') vide pour ces blocs), même avec les $$ isolés sur leur propre ligne. Fix : contenu réuni sur une seule ligne.
Un | littéral (valeur absolue $|X|$ ) dans une cellule de tableau Markdown casse le découpage en colonnes (même mécanisme qu'un lien [[label|cible]] non échappé) ; une séquence ]( dans une formule (ex. notation de Mellin ℳ[f](s)) est interprétée comme un lien Markdown. Fix : \lvert X\rvert, groupe vide ]{}( .
Adjacence sans espace entre un $ et certains caractères : )$) (contenu se terminant par ) + $ fermant + )), ~$X$ (tilde collé au $ ouvrant), $A$–$B$ (deux formules séparées par un tiret cadratin sans espace), $T$* ($ collé à une étoile Markdown fermante). Fix : espace insérée ou séparateur déplacé à l'intérieur du mode math (\sim, \text{–}).

Deux pages ont nécessité une refonte complète (Analyse-Deficit-Zeros-Grille-20260906.md : 16/16 blocs $$ cassés — cause 2 quasi-systématique sur cette page ; 4 blocs résiduels dans Formules_zeta.md) : tous les $$ concernés convertis en $ inline (rendu fiable à 100 % observé sur tout le wiki durant cette investigation, contrairement à $$).

Incident en cours de route (rattrapé avant tout commit visible) : un premier script de nettoyage (suppression des doubles-espaces introduits) a été appliqué globalement au lieu d'être scopé aux insertions du script lui-même — a détruit l'alignement des colonnes de Tableau-Symboles-Mathématiques.md (376 lignes) et l'indentation de listes dans Animations.md/prompts_claude_2026-08-18.md. Détecté en revue de diff avant push (git status inattendu sur des fichiers non prévus), annulé via git checkout --, script réécrit pour ne jamais introduire de double-espace, réappliqué proprement. Le git checkout -- a aussi annulé par mégarde une correction manuelle légitime (Formules_zeta.md L619, cas $T$*) — repérée en vérification finale et réappliquée séparément.

Méthodologie de vérification : le rendu KaTeX de GitHub est asynchrone, pas seulement lent — une page fraîchement chargée sans interaction peut rester bloquée sur son état brut initial indéfiniment ; il faut un clic + scroll réel pour le déclencher (confirmé : 166 $$ bruts stables 35 s+ sans interaction → 8 en 3 s après clic+scroll). Vérification finale par comptage DOM (raw$$/single$ dans innerText) après clic+scroll+attente, pas par lecture visuelle seule.

Résultat final : Formules_zeta.md et Analyse-Deficit-Zeros-Grille-20260906.md (les deux pages nommées par hprzeta) confirmées à 0 formule brute (raw$$=0, single$=0). ~50 fichiers touchés au total sur 8 commits.

Commits (wiki, branche master) : bd5687e (8 pages, \_/\#) → afa7ae5 (fix pipe lien Structure-Projet-Complet.md) → fab47ae (34 pages, \,/\;/\!/\%) → 44c30ac (blocs $$ irréductibles → $ inline, 2 fichiers) → 44bf55f (11 spans résiduels Analyse-Deficit...) → 511c58d (dernier span résiduel) → 392bdc4 (3 motifs d'adjacence généralisés, 11 fichiers) → 73bda9e (fix L619 perdu, réappliqué).

Non traité, signalé mais hors périmètre : guidance obsolète en dur dans Analyse-Deficit-Zeros-Grille-20260906.md §8 point 5 (« échapper % en \% en mode math ») — texte historique daté (section "instructions pour Claude Code" du 06/09), volontairement non réécrit (voir raisonnement §4 de l'entrée 2026-09-06 ci-dessous sur les documents datés).

2026-09-06 — soirée — Diagnostic définitif du déficit de zéros (test A/B + triple expertise mathématique) : ULP et enjambement GUE réfutés, cause = fragilité Riemann-Siegel à bas t, non-menace HR

Contexte : poursuite directe du chantier ouvert le 18/08 (piste ULP scan_arb.c jamais testée empiriquement, cf. entrée du 05/09 ci-dessous). Test A/B expérimental (binaires v13 7914fa3 vs v16 d4b3611, grille identique STEP=0,001571/MARGE=2,0, fenêtre historique exacte segments 0-1 [14, 1 391 397]) + synthèse mathématique croisée (2 moteurs externes indépendants + Claude Code), consignée dans Analyse-Deficit-Zeros-Grille-20260906.md (wiki racine).

Test A/B — résultat net

Run A (v13, 69,8 min, 8 workers turbo) et Run B (v16, 48,8 min, mêmes paramètres) : 2 504 084 zéros chacun, diff zéro-à-zéro = 0 écart (nearest-neighbor, tolérance 1e-4, écart max mesuré 0,000e+00 — CSV identiques valeur par valeur). valider_turing() exact (θ(T)/π+1+round(S(T))) appliqué à chaque CSV : déficit strictement identique aux 5 points de contrôle, dont 18 manquants exactement à t=737 112 — reproduction fidèle du déficit v13 historique déjà validé à ce point. L'écart binaire ULP div/mult n'a aucun effet mesurable sur la détection.

Verdict mathématique

ULP div/mult : réfuté — bruit théorique $\sigma_{\Delta Z}\sim10^{-16}$ (accumulation en marche aléatoire sur la somme RS, RMS $=\varepsilon_{\text{mach}} \sqrt{\ln N+\gamma}$) contre seuil de détection $|Z|_{\text{grille,min}}\sim10^{-3}$ — ratio $10^{13}$. Confirmé par le test A/B (écart = 0), par 10 ordres de grandeur.
Enjambement de paires (loi GUE, Montgomery) : négligeable — $M_1(h)\approx 0{,}06$–$0{,}08$ zéro attendu sur la fenêtre testée, contre 18-51 observés (2 ordres de grandeur d'écart), et prédit la mauvaise localisation (croissant à haut $t$, alors que le déficit se concentre à >90 % à bas $t$) — doublement écarté.
Cause retenue : fragilité de la formule de Riemann-Siegel tronquée à bas $t$ — $N=\lfloor\sqrt{t/2\pi}\rfloor$ est petit ($t=14 \Rightarrow N=1$), donc toute erreur sur $N$ (±1, hypothèse la plus actionnable) ou sur le reste $R(t)=O(t^{-1/4})$ non négligé a un impact relatif énorme sur la somme tronquée (100–200 % à $t=14$ contre 0,25 % à $t=10^6$) — profil exactement conforme au déficit observé. Deux canaux non exclusifs, test discriminant proposé (instrumentation scan_arb.c, $N$ calculé vs $N$ exact, 5 min, aucun run long) mais non exécuté ce jour.
Non-menace pour l'HR : ce sont des zéros non détectés par une formule tronquée (limite numérique), pas des contre-exemples — ils sont bien sur la droite critique. Objectif 1 reste validé.

⚠️ Correction — l'explication "paires enjambées" (notée depuis v13) est invalidée

STACK.md (ligne de statut du run T=5M) et des mentions éparses depuis v13 attribuaient les 96 manquants à des "paires de zéros proches non détectées par la grille". Cette explication avait déjà été mise en doute le 18/08 sans chiffrage définitif (entrée ci-dessous). Chiffrage aujourd'hui : $M_1\approx0{,}08$ zéro attendu contre 96 observés — écart de 3 ordres de grandeur. L'explication est fausse, pas seulement insuffisante. STACK.md corrigé en conséquence (ligne de statut run T=5M, renvoi vers cette entrée et vers Formules_zeta §33).

Documentation mise à jour

Formules_zeta.md §33 (nouveau — condition de raté, $M_1(h)$ quantifié, corrections de rigueur), Bibliotheques.md §20 (nouveau — références Riemann-von Mangoldt, Montgomery, Gaudin, Gonek-Hughes, Farmer-Gonek-Hughes, Turing-Backlund), skill riemann-lab (mémo « pièges numériques RS à bas t »), STACK.md (statut run T=5M corrigé). Script de test A/B, CSV et calibration : calculs/ab_test_scanarb_20260906/ (repo principal Riemann_Lab_C, non versionné — données volumineuses).

Chantier "déficit de zéros bas-t" : clos côté diagnostic. Reste ouvert si repris un jour : test discriminant canal $N$ vs canal $R(t)$ (instrumentation légère, 5 min), et solution long terme v17 (schéma hybride grille grossière + raffinement local + RS haute précision pour $t\le T_0\sim10^5\text{–}10^6$, cohérent avec l'horizon Odlyzko-Schönhage).

2026-09-06 — suite — Audit cohérence site/wiki + liens cassés (.pdf/.py/.csv/.png/.svg/.md), corrections appliquées et poussées — commits `299f68e` (repo) / `b736969` (wiki)

Contexte : hprzeta demande de vérifier que le site (docs/index.html) correspond aux données déclarées dans le wiki, et de vérifier les liens .pdf/.py/.csv/.png/.svg/.md. Consigne : lister avant de corriger. Audit délégué à un fork (lecture seule, ~7 min, 25 outils), 2 volets : valeurs affichées (site vs wiki) et résolution de tous les liens.

Résultat de l'audit (liste présentée avant correction)

[Majeur] Erreur de calcul ×100 sur « Gain global v1→vN » sur tout le site et STACK.md (copié, pas un désaccord entre les deux) : v16 affichait ×78 650+ au lieu de ×787,5 réel (21h/1,6 min). Même erreur v15 (×28 600+→×286), v13 (×20 000+→×148), v10 (×5 040→×53,2), v9 (×4 500/×4 300→×47,4/×45).
[Majeur] PC2 : « 52 z/s (v13+python-flint) » — en réalité 52 z/s sans python-flint ; avec, 512,19 z/s (mesure du 02/08).
[Modéré] CPU PC3 : « Intel Pentium E2140 » partout alors que lscpu distant (JOURNAL 18/08) a confirmé AMD Athlon II X2 215.
[Modéré] Tableau T=10 000 : ligne « v2 » affichait en fait les valeurs de v1 ; ligne v4.1+Arb (2,60 min, ×484) absente du site.
[Mineur] En-tête « Gain vs v7 » trompeur ; doublon de titre ## §17 dans Bibliotheques.md.
Liens cassés : 5 dans le wiki (fichiers compute_zeros_v1/v2.py et CSV déplacés vers docs/archive/... sans mise à jour) — aucun dans docs/index.html lui-même.
Liens wiki [[...]] dangereux : 5 pointant vers des pages jamais créées.

Corrections appliquées (hprzeta a validé « Tout corriger et retester »)

docs/index.html : toutes les valeurs corrigées (×787,5, 512 z/s, AMD Athlon II X2 215, ligne v1 renommée + v4.1+Arb ajoutée, en-tête « Gain vs préc. »). STACK.md : mêmes corrections + note datée. Architecture-Cluster-Zeta.md : CPU corrigé. Bibliotheques.md : second ## §17 renommé §17bis (pas de cascade de renumérotation, pour ne pas casser les références externes à §18/§19). Découverte en cours de route : docs/Bibliotheques.md/docs/Formules_zeta.md sont des copies figées du wiki (mirroring pour le site), manquant §17bis/§19/§32 — resynchronisées. Liens cassés (5) corrigés dans Etape-1-Calcul-des-zéros-non-triviaux.md et Interprétation-des-résultats-de-tests.md. Liens [[...]] dangereux (5) redirigés ou résolus (2 pages retrouvées en staging local non versionné, copiées dans le wiki sans rien inventer) ; 3 liens [[Étape-2/3/4]] laissés tels quels (roadmap « à venir », pas une erreur).

Volontairement NON touché — même bug ×100 trouvé ailleurs, mais dans des documents datés : JOURNAL.md, Handoff.md du wiki, Roadmap.md, tous les analyse_problemes_v*.md. Ce sont des comptes-rendus/journaux datés, pas des références vivantes — les réécrire changerait un historique plutôt que corriger un état courant. Décision explicitement laissée à hprzeta pour une prochaine session.

Retest : parsing HTML sans erreur, comptage <tr>/<td> cohérent, existence sur disque de toutes les cibles corrigées, grep des anciennes valeurs → 0 résidu. Commits : repo principal 299f68e (poussé 92b346b..299f68e), wiki b736969 (poussé a73ed56..b736969, incluant 2 pages ajoutées analyse_math_deficit_2026-08-18.md et prompts_claude_2026-08-18.md).

2026-09-06 — clôture nettoyage 16 fichiers non commités (héritage 05/09) : commit scripts + vérification secrets + purge vers `secrets_local` — commits `4db06de`/`92b346b` (Riemann_Lab_C)

Contexte : poursuite directe de la session du 05/09 soir (ci-dessous) — les 16 fichiers alors listés comme non commités, plus le zip Pass-... déjà identifié comme sensible.

zeta_monitor.py/zeta_tmux.sh (jump-host bastion [WG_PC4]) : diff relu (aucun secret), bug mineur corrigé (condition ping dupliquée, code mort). Committé 4db06de.
Fichiers usage privé (BOX-SFR-GR140IG-Addendum-20260823.md, RAPPORT-SESSION-RESEAU-20260823-v2.md) : déplacés vers ~/riemann_handoff/secrets_local/ (choix hprzeta, hors repo plutôt que gitignoré sur place).
Zip Pass-20260819...zip : jamais ouvert par Claude Code (instruction explicite), déplacé tel quel — confirmé par ailleurs (commentaire .gitignore préexistant, daté 05/09) qu'il contient la clé privée WireGuard du pair téléphone ([WG_TEL]).
Vérification sécurité des 5 autres .zip + 7 .bak* : extraction complète + grep (password/token/secret/clé privée/passphrase/BEGIN PRIVATE KEY) — rien trouvé. Zeta-20260819...zip (182 Mo) : inspection visuelle de 4 captures WireGuard Android, confirmé que l'app ne montre que la clé publique en vue lecture seule. Un fichier Box fibre.html contient une IPv6 publique réelle dans une règle NAT — même catégorie que BOX-SFR-..., signalé, non extrait séparément.
Décision finale hprzeta (« tout ce que je ne commit pas met le dans secret_local jamais comité ») : 13 fichiers déplacés vers secrets_local/ (6 .zip + 7 .bak*). git status de ~/projet_zeta redevenu propre (0 non suivi, 0 modifié).
Garde-fou .gitignore : règle secrets_local//**/secrets_local/ ajoutée en défense en profondeur. Committé 92b346b, poussé sur origin/Riemann_Lab_C.

Bilan ~/riemann_handoff/secrets_local/ : 17 fichiers au total (incluant ceux déjà présents avant cette session) — voir liste complète dans le Handoff local.

2026-09-05 — 20h49 — Accès distant en déplacement : fausse piste opérateur mobile, vraie cause Proton VPN, `wg_auto.sh` v2 — commit `23dce34`

Contexte : accès distant au cluster injoignable en déplacement (hotspot mobile Port_Armel). Diagnostic mené par étapes successives, avec un revirement de décision en cours de session — documenté ici tel quel, y compris la fausse piste, car la leçon méthodologique compte autant que la correction finale.

1. Neutralisation puis restauration de `wg_auto.sh`

Le matin, wg_auto.sh (bascule auto maison/déplacement + auto-réparation + notify-send, en place depuis le 30/08) a été neutralisé sur demande, avec wg-quick@wg0.service désactivé et le dispatcher NetworkManager 99-wg-auto rendu non exécutable, suite à un spam de notifications "tunnel MORT / échec réparation". hprzeta est revenu sur cette décision dans la foulée : l'accès distant automatique fonctionnait depuis le portable au travail et devait être conservé. Restauration complète à l'état du 30/08 (wg_auto.sh.bak-20260905, backup pris avant neutralisation), réactivation du service et du dispatcher.

2. Diagnostic IPv6 — fausse piste initiale

Test du tunnel depuis le hotspot (Port_Armel, confirmé par le wiki comme étant le hotspot mobile lui-même, pas un réseau distinct) : ping [WG_PC4] en échec, aucune IPv6 globale sur wlp2s0 (ip -6 addr ne montrait que du fe80:: lien-local), DNS AAAA de [DDNS_PC4] pourtant cohérent et à jour. Hypothèse retenue à ce stade : absence d'IPv6 côté opérateur mobile. Un redémarrage complet du partage de connexion (déconnexion/reconnexion Wi-Fi confirmée dans les logs noyau, nouveau bail IPv4 obtenu) n'a rien changé — toujours aucune IPv6 globale ensuite. Hypothèse invalidée par ce test, mais la cause réelle n'a été découverte qu'après, par hprzeta lui-même.

3. Cause racine réelle — Proton VPN

hprzeta a identifié que Proton VPN, actif sur le portable (invisible depuis PC1), bloquait l'IPv6 — comportement anti-fuite classique des VPN commerciaux. Preuve : coupure de Proton → IPv6 globale immédiatement présente ([IPV6]), handshake WireGuard réussi, ping [WG_PC4] → 0 % perte, ~58 ms. Le hotspot fournissait l'IPv6 depuis le début ; la piste "opérateur mobile" était fausse. Détail complet et preuve par élimination : Diagnostic-WireGuard-Hotspot §9.

4. Correctif — `wg_auto.sh` v2 (garde IPv6)

Le spam de notifications de la soirée ne venait pas d'un bug du script : il réparait fidèlement un tunnel structurellement injoignable (pas d'IPv6, donc pas de handshake possible par construction) sans savoir que la cause était un VPN tiers. Ajout d'une garde en tête du bloc déplacement : si aucune IPv6 globale, sortie silencieuse (pas de wg-quick, pas de notify-send, une seule ligne de log). Diff montré et validé avant application, backup wg_auto.sh.bak-20260905-avant-v2 créé, comportement vérifié (tunnel déjà OK → silencieux en --quiet, notif unique sinon ; pas d'IPv6 → silencieux). Committé sur Riemann_Lab_C : 23dce34 fix(scripts): wg_auto.sh — auto-réparation handshake + garde IPv6 avant notif/action.

5. Documentation wiki

Nouveau guide de référence Guide-WireGuard-Acces-Distant (page publique, placeholders <...>, TL;DR + niveaux débutant→expert + procédure de dépannage + commandes). Diagnostic-WireGuard-Hotspot complété (§9, table des occurrences, "Voir aussi") plutôt que dupliqué. Guide-Linux-Commandes §28 ajouté (commandes de diagnostic IPv6 vs VPN tiers). STACK : avertissement Proton VPN ajouté à la fiche cluster.

Voir aussi

Guide-WireGuard-Acces-Distant — procédure de référence à jour
Diagnostic-WireGuard-Hotspot §9 — détail complet de l'incident

2026-09-05 — Diagnostic lecture seule run MARGE=10.0 (déjà résolu 18/08, Handoff en retard) + diff binaire réel `scan_arb.c` v13/v16 — piste confirmée mais partielle

Contexte : reprise de l'Objectif 1 (calcul des zéros) après une parenthèse infra (session réseau du 23/08, rangement branches du 30/08). Consigne explicite de hprzeta : diagnostic en lecture seule uniquement, rien à relancer ni tuer. Objectif final inchangé : comprendre l'écart 96 (v13) → 177 (v16) zéros manquants sur T=5M.

1. Statut du run MARGE=10.0 segments 0-1 `[14, 1 391 397]` — mort, et déjà résolu

Le Handoff indiquait ce run comme "statut inconnu depuis le 18/08". Vérification en 4 axes indépendants (pgrep/ps, tmux ls, systemd-inhibit --list, logs) : aucun process actif, aucune session tmux de calcul, aucun verrou système — run définitivement arrêté.

En réalité, ce test A/B était déjà allé jusqu'au bout et avait été rapporté dans ce JOURNAL le 18/08 à 22h30 (voir entrée correspondante ci-dessous) : MARGE=2.0 → 2 504 087 zéros, MARGE=10.0 → 2 504 024 (−63, comparaison 70/7 zéros divergents). Le Handoff n'avait simplement jamais été resynchronisé avec cette information après le 18/08 — pas une anomalie de calcul, une dette de documentation.

Les dossiers de résultats (calculs/margeB2, margeB10, margeC2, margeC10, seg01_marge2, seg01_marge10) restent introuvables (disparition déjà constatée le 19/08, cause jamais élucidée) — confirmé toujours absents ce jour. Seuls les chiffres agrégés du JOURNAL survivent ; aucun CSV brut disponible pour creuser plus loin les 77 zéros divergents.

2. Diff binaire réel `scan_arb.c`/`.so` entre v13 et v16 — la piste laissée ouverte le 18/08

Le 18/08 (entrée 18h00) identifiait comme piste non testée : « le détecteur C partagé scan_arb.c a été modifié entre le run v13 (avant commit d4b3611) et le run v16 (après) — jamais comparé binaire contre binaire. » Traité cette session.

Méthode : scan_arb.so s'est avéré versionné dans git aux côtés du .c — comparaison binaire réelle possible (pas une simple hypothèse de diff source). v13 (run 27-29/06) a tourné avec l'état du commit 7914fa3 (26/06) ; v16 (run 16-17/08) avec l'état du commit d4b3611 (04/07, inchangé depuis). Binaires confirmés distincts (SHA-256 différents, 16 104 vs 16 216 octets).

Changement fonctionnel trouvé : d4b3611 (« cache log_n/isqrt_n RS ») remplace, dans la boucle Riemann-Siegel de Z_double(), une division directe x / sqrt(n) par une multiplication par un inverse précalculé et mis en cache x * (1.0/sqrt(n)). En IEEE-754, a/b et a*(1/b) ne garantissent pas le même résultat au dernier bit — bruit de quelques ULP introduit sur chaque évaluation de Z(t) sur tout le run (le cache couvre N≤2100, soit T≤~27M, donc actif sur l'intégralité de [14, 5M], pas seulement à bas T). Le reste du diff est cosmétique (constante PI explicite au lieu de acos(-1.0), commentaires) — aucun autre écart de comportement.

Portée : ce mécanisme correspond précisément à l'hypothèse de bruit de phase du signe Z_double évoquée le 18/08 22h30 (biais numérique documenté ~10⁻³ à 10⁻⁷ selon t, Formules_zeta §30) — désormais rattachée à une ligne de code et un commit précis, alors qu'elle n'était qu'une conjecture non vérifiée jusqu'ici.

Limite non résolue : ce bruit s'applique uniformément sur toute la plage T (division vs multiplication réciproque, actif partout), alors que le déficit anormal (96→177) reste concentré à >90 % dans les segments 0-1 (bas T) — les segments 2-7 étant quasi identiques entre v13 et v16. Ce candidat ne suffit donc pas seul à expliquer la concentration observée ; il reste une cause partielle plausible, pas une clôture du dossier.

Prochaine action proposée (non lancée, en attente d'accord hprzeta)

Test A/B ciblé binaire 7914fa3 (division directe, comportement v13) vs d4b3611 (cache réciproque, comportement v16) sur les segments 0-1 exacts du run T=5M, pour mesurer si le retour à la division directe change le compte de zéros — trancherait la contribution réelle de ce candidat.

Voir aussi

Handoff local (~/riemann_handoff/Handoff.md) — section « REPRISE ICI », entrée 05/09/2026.
Entrées du 18/08 ci-dessous (12h00, 18h00, 19h00, 20h00, 22h30) — chronologie complète de l'investigation du déficit.

2026-08-30 — Écart Handoff comblé (18/08→30/08) + rangement branches (gitignore secrets + commit docs(clone)) — commits `9c72133`/`3b32969` (cherry-pick), `.gitignore` sur 4 branches

Contexte : point projet en début de session — le bloc REPRISE du Handoff local n'avait pas été mis à jour depuis le 18/08 (19:37), alors que Riemann_Lab_C avait avancé de 2 commits supplémentaires entretemps (9734011 le 23/08, 9c72133 le 30/08) et que 25 fichiers restaient non commités (sessions du 19/08 au 30/08). hprzeta a confirmé que 9c72133 est correct et complet, et qu'il n'était pas nécessaire d'investiguer le détail de l'écart 18/08→24/08 — non fait, contenu de ces fichiers non vérifié.

Décisions prises et exécutées :

Commit 9c72133 (docs(clone): resync PC1 state + regenerate toshiba backup script v2.0, session du 30/08) — contenu = rapport doc + script bash, aucun lien avec la Phase C. Cherry-pické sur Riemann_Lab_IA (nouveau hash 3b32969), conformément à la répartition CLAUDE.md (IA = Python/wiki/docs, C = Phase C uniquement). Conservé aussi sur Riemann_Lab_C (pas de réécriture d'un historique déjà publié) — les deux branches portent donc le même contenu sous 2 hash différents.
.gitignore — règles secrets ajoutées le 18/08 (docs/archive/zeta-secure- backup.tgz, docs/archive/*-backup.tgz, commit aaff309) et le 23/08 (docs/archive/BOX-SFR-*.pdf, commit 9734011) n'avaient jamais été propagées hors Riemann_Lab_C. Cherry-pické sans conflit sur main (3242b63), Riemann_Lab_IA (inclus dans fead161/7e57df6) et Riemann_Lab_Test (88aa58c), puis poussé. Les 4 branches protègent désormais les mêmes fichiers sensibles.

Reste ouvert (hérité du 18/08, explicitement non retouché sur demande hprzeta) : Bloc B (fiabilité PC1) / Bloc C (déficit 177 vs 96 zéros v16) — statut inconnu, non revérifié ; clé WireGuard PC4/token DuckDNS — régénération toujours en attente (action hprzeta) ; run MARGE=10.0 segments 0-1 — statut réel non vérifié cette session (résolu plus tard, voir entrée du 05/09 ci-dessus) ; backup PC3 — dernière confirmation le 17/08, jamais reconfirmée.

Toujours non commité sur Riemann_Lab_C à l'issue de cette session (25 fichiers, non triés) : docs/archive/ (discussions/PDF/zips divers), 2 SVG docs/images/, 2 fichiers logs/suivi_run_T5M*.md, pdf/clone/ (rapport clonage + script), 2 scripts zeta_point_maj.sh/zeta_temp_monitor.py.

Hash de fin de session : Riemann_Lab_C = 9c72133 (HEAD reste en avance de 3 commits jamais propagés : 52ba8d9, 1fa1319, 36c7f77) · Riemann_Lab_IA = 3b32969 (poussé) · main = 3242b63 (poussé) · Riemann_Lab_Test = 88aa58c (poussé) · Wiki master inchangé, f03604c — pas touché cette session.

2026-08-23 — Session réseau et remise en état : IP fixe PC2/PC3, DHCP box réduit, nettoyage PC2 (CTparental, comptes hérités) — commits `9ad3f41` (wiki) / `9734011` (.gitignore, Riemann_Lab_C)

Contexte : session de suivi de l'incident WireGuard/IPv6 du 22/08 (voir Diagnostic-WireGuard-Hotspot). Cinq objectifs : IP fixe PC3, DNS harmonisé sur les 4 nœuds, suppression des IPv6 temporaires de PC4, désinstallation du contrôle parental CTparental sur PC2, suppression des comptes hérités de PC2. Détail complet dans RAPPORT-SESSION-RESEAU-20260823-v2.md (local, non versionné — contient des adresses MAC et l'IPv6 publique).

Box SFR — plage DHCP réduite

Impossible de créer une réservation DHCP pour PC3 ([IP_PC3]) : la box refuse la saisie même pour la MAC déjà propriétaire de l'IP (table d'équipements en cache, non rafraîchie — le menu déroulant affichait encore zêta-saut au lieu de zeta-backup). Solution retenue : réduire la plage DHCP de [IP_LAN]→253 à [IP_LAN]→253, ce qui rend toute réservation inutile. Zone .2→.99 désormais réservée aux IP fixes du cluster.

Effet de bord : sauvegarder la section Service DHCP de la box fait rebondir le bridge LAN (~3 s de coupure filaire, PC1 en Wi-Fi épargné) — à ne jamais faire pendant un run ou un rsync.

PC2 (`zeta-calc-second`) et PC3 (`zeta-backup`) — IP fixe

Passage en Manual via NetworkManager (connexions renommées zeta-calc-second-LAN2 et zeta-backup-LAN3), DNS harmonisé sur 109.0.66.10 / 109.0.66.20. Piège rencontré sur PC2 : un nmcli con reload seul ne suffit pas à appliquer un profil modifié — il faut nmcli con up.

PC2 — désinstallation de CTparental (machine de récupération Emmaüs)

PC2 s'est révélé être une machine récupérée chez Emmaüs, préconfigurée avec le contrôle parental CTparental (ruleset nftables de 20 146 lignes — blacklist université de Toulouse). Aucun risque pour SSH identifié avant désinstallation (policy accept partout, port 22 non filtré). Désinstallation via CTparental -u (le script se termine en erreur mais fait l'essentiel ; finalisé à la main) : nftables → 0 ligne, dnscrypt-proxy purgé, dépôt APT du média live (file:/run/live/medium, [trusted=yes]) neutralisé. ~516 Mo libérés au total. Effet indésirable : le désinstalleur a aussi supprimé dnsutils (réinstallé).

Comptes hérités identifiés : emmabuntus (1000, admin distro — contenait un projet_zeta de 124 Mo, config/ et scripts/ récupérés, src confirmé moins avancé que la version hprzeta), fille (1004), garçon (1005) — anciens propriétaires. Archive de sécurité créée (recup-emmabuntus-src-20260823.tar.gz) avant toute suppression. Suppression effectuée et vérifiée le 23/08/2026 — seul hprzeta (1003) subsiste comme compte humain sur PC2, /home/ ne contient plus que hprzeta et lost+found (§7.3 du rapport source, marquée faite).

PC4 (`zeta-secure`) — nettoyage

IPv6 temporaires désactivées (inet6 autoconf -temporary dans /etc/hostname.re0 — AUTOCONF6TEMP n'était pas exploité par duck.sh, qui filtre déjà correctement, mais la source du risque est supprimée). resolvd désactivé (réécrivait /etc/resolv.conf à chaque RA de la box) au profit d'un DNS statique 109.0.66.10 / 109.0.66.20.

Incohérence documentaire corrigée

Le wiki Architecture-Cluster-Zeta §11 affichait une adresse IPv6 de PC4 périmée (...ad39:37b9:a638:126c), jamais mise à jour depuis la migration matérielle du 16/08 ni l'incident du 22/08. Corrigée vers l'adresse courante (...3fee:331d:c08b:1956), cohérente avec la règle box WireGuard-ipV6-Newpc4 (vérifiée Activée, correspondance confirmée 23/08/2026).

Reste à faire (rapport source §12)

Vérifier le 24/08 ~18h que le bail résiduel de PC3 a expiré dans la box
PC2 : MAJ Thunderbird, tri de recup-emmabuntus-*, décision pare-feu local
Uniformiser IdentitiesOnly yes dans ~/.ssh/config (PC1)

Voir aussi

Architecture-Cluster-Zeta — fiches PC2/PC3/PC4 mises à jour, §15 Leçons apprises complétée
Diagnostic-WireGuard-Hotspot — incident du 22/08, non affecté par cette session (règle box inchangée)

2026-08-18 — 22h30 — Test A/B segments 0-1 (bas T) : PREMIÈRE différence réelle entre MARGE=2.0 et MARGE=10.0, mais qui viole la monotonie attendue

Contexte : dernier test A/B de la journée, sur [14, 1 391 397] (segments 0-1, là où le déficit réel v13→v16 était concentré : +18→+51 et +9→+49). Contrairement aux deux tests précédents ([4,8M;5M], [4,9M;5M]), qui donnaient des résultats strictement identiques entre les deux marges, celui-ci diverge.

Résultat

	MARGE=2.0	MARGE=10.0
Zéros trouvés	2 504 087	2 504 024
Durée	47,9 min	185,6 min

MARGE=10.0 (grille 5× plus fine) trouve 63 zéros de MOINS que MARGE=2.0 — contraire à l'argument de monotonie (une grille plus fine devrait trouver autant ou plus, jamais moins, une grille de pas h/k étant un raffinement strict d'une grille de pas h).

Comparaison zéro à zéro — asymétrique, pas une simple perte

Alignement par plus proche voisin (tolérance 1e-4, largement au-dessus du bruit numérique habituel ~1e-7) :

70 zéros présents dans MARGE=2.0, absents de MARGE=10.0
7 zéros présents dans MARGE=10.0, absents de MARGE=2.0
Net : -63, conforme au différentiel de comptage

Répartition par worker (aucune troncature — chaque worker de MARGE=10.0 atteint bien sa borne finale des deux côtés) :

Worker	Bornes (t)	MARGE=2.0	MARGE=10.0	déficit
0	[14, 208 959]	313 016	313 015	1
1	[208 959, 391 759]	313 012	313 003	9
2	[391 759, 566 789]	313 007	312 999	8
3	[566 789, 737 113]	313 008	312 996	12
4	[737 113, 904 093]	313 009	312 992	17
5	[904 093, 1 068 499]	313 012	313 009	3
6	[1 068 499, 1 230 820]	313 011	313 003	8
7	[1 230 820, 1 391 397]	313 012	313 007	5

Pertes dispersées sur les 8 workers, pas concentrées — signature différente de tout ce qui a été observé jusqu'ici dans la session.

Hypothèses vérifiées et écartées

max_brackets (buffer scan_arb.c) — écarté. Chaque worker MARGE=10.0 atteint sa borne de fin exacte (dernier t à ~0,5 unité de la borne théorique) : aucun signe de troncature anticipée du buffer.
Dérive flottante cumulative sur t — écarté par lecture de code (scan_arb.c : k est un long, t_curr = t_min + (double)k * step recalculé depuis t_min à chaque itération, pas d'accumulation). Précision résiduelle de t (~3×10⁻¹⁰ à cette hauteur) six ordres de grandeur plus fine que STEP — pas limitant.

Hypothèse ouverte, non confirmée

Le test de détection (z_prev * z_curr < 0.0 dans scan_arb.c) repose sur le signe brut de Z_double, dont le biais numérique propre est documenté (~10⁻³ à 10⁻⁷ selon t, Formules_zeta §30). Si le vrai Z(t) près d'un zéro est plus petit que ce biais, le signe calculé peut devenir sensible aux points d'échantillonnage exacts — qui diffèrent entre les deux marges. Ce serait un bruit de phase asymétrique, pas une perte de résolution monotone — cohérent avec le motif observé (pertes dans les deux sens, dispersées). Non vérifié — nécessiterait un scan indépendant très fin sur un échantillon des 77 zéros divergents.

Portée

Ce résultat ne remet pas en cause les conclusions déjà établies aujourd'hui (le déficit historique 96→177 reste inexpliqué par ce mécanisme, l'écart mesuré ici — 63 zéros sur 2,5M, ~2,5×10⁻⁵ — est trop petit et de mauvais signe pour l'expliquer) mais c'est la première preuve empirique reproductible que MARGE_SECURITE a un effet mesurable quelque part dans le pipeline, quoique dans une direction et une ampleur inattendues. Piste à creuser dans une session dédiée.

Voir aussi

Handoff — section « REPRISE ICI ».

2026-08-18 — 20h00 — Analyse mathématique complète du déficit — documents `analyse_math_deficit` et `prompts_claude`, guides propagés

Contexte : clôture formelle de l'investigation du déficit de zéros (entrées 12h00, 18h00, 19h00 ci-dessous). hprzeta a produit deux documents de référence : analyse_math_deficit_2026-08-18 (démonstrations complètes : loi en STEP³, argument de monotonie, les deux formules d'attendu, variance de Selberg, test de forme L(t)³, rendement du rescan) et prompts_claude_2026-08-18 (recueil des prompts + leçons de conduite de session).

Vérification numérique des calculs (mpmath + dérivation analytique fermée)

∫L(t)⁴dt sur [14, 5×10⁶] : 1,2982×10¹¹ — conforme à la valeur proposée (1,2980×10¹¹, écart < 0,02%).
∫L(t)⁴dt sur [14, 737 112] (segment 0) : 1,00121×10¹⁰ — conforme (1,0011×10¹⁰, écart < 0,01%).
M(STEP=0,010) = 91,3 zéros — conforme, accord à moins de 5% avec les 96 manquants de v13.

Écart trouvé — l'hypothèse de clôture historique ne tient pas

Hypothèse testée : l'explication "paires enjambées" (voir entrée du 4 juillet ci-dessous) était vraie à l'époque où le pipeline tournait à STEP=0,010 fixe, puis transportée par inertie documentaire jusqu'à devenir fausse. Réfutée : le commit a0e6e41 (04/07, à l'origine de cette explication) fixe déjà MARGE_SECURITE=2.0 dans la formule adaptative (STEP≈0,00157), pas un pas fixe. Le pipeline à STEP=0,010 avait été abandonné le 17/06, soit 17 jours avant l'écriture de l'explication. L'explication était déjà fausse le jour où elle a été écrite — pas seulement devenue fausse plus tard.

Guides propagés (5 fichiers, diffs revus avant application)

Formules_zeta §32 — résolution de grille et comptage (δ(t), loi GUE, formule maîtresse M, N(T) développement complet, variance de Selberg).
STACK — ligne v6 (STEP=0.010 fixe ⚠️ VESTIGE), note sur la formule adaptative réelle et le suréchantillonnage ×17 à bas t.
Bibliotheques §19 — les deux estimateurs N_exact/_n_zeros_expected et leur incompatibilité.
Bonnes-Pratiques-Claude-Code — 6 leçons de conduite de session (tmux, jamais Ctrl+Z, chiffrer avant de lancer, vérifier s_min, lecture de code avant calcul, exiger PROUVÉ/MESURÉ/CONJECTURE).
Guide-Linux-Commandes §26 — commandes de post-mortem crash machine.

KaTeX vérifié sur les 3 fichiers contenant des formules avant publication (aucun \operatorname, aucun \bigl/\bigr, tous les _ dans \text{} échappés).

Voir aussi

analyse_math_deficit_2026-08-18 — démonstrations complètes
prompts_claude_2026-08-18 — recueil des prompts et leçons
Entrées du 18/08 ci-dessous (12h00, 18h00, 19h00) — chronologie complète de l'investigation

2026-08-18 — 19h00 — Validation Turing exacte windowée sur les CSV du test A/B — déficit de fond confirmé (+8/200k), indépendant de MARGE_SECURITE

Contexte : suite à la correction du récit du 02/08 (entrée 18h00), le CSV _principal du run v16 réel s'est révélé inexistant (le mécanisme de sauvegarde n'existait pas encore au moment du crash — correction déjà appliquée dans l'entrée 18h00). Alternative : appliquer la formule exacte de Riemann-von Mangoldt (N_exact(T) = ⌊θ(T)/π⌋+1+round(S(T)), turing_validation.py) — pas l'estimateur de Weyl grossier _n_zeros_expected — aux CSV déjà en main du test A/B du 18/08 ([4,8M;5M], MARGE=2.0 et 10.0, déjà prouvés bit-identiques entre les deux réglages).

Résultat

Fenêtre	Calculés	Attendus (exact θ+S)	Déficit
`[4 800 000 ; 4 900 000)`	215 756	215 760	+4
`[4 900 000 ; 5 000 000)`	216 081	216 085	+4
Total `[4,8M ; 5M)`	431 837	431 845	+8

Contrairement au comptage naïf (0 différence trouvée précédemment entre les deux fenêtres testées séparément avec l'estimateur global bogué sur les runs CLI --t-min non nul), cette méthode correctement windowée détecte un déficit non nul.

Contrôle de robustesse — le résultat n'est pas un artefact numérique

S(T) a été recalculé aux 3 bornes avec n_sigma = 50/100/200/400 (résolution d'intégration de l'argument de ζ) : valeur identique à 4 décimales dans tous les cas (ex. S(4 900 000) = -0.3091 invariant). Revérifié aussi avec dps=50 au lieu de 35 : identique. Le déficit +4/+4 n'est donc pas dû à une résolution insuffisante de S_T(), malgré l'avertissement du docstring ("fiabilité documentée T<10⁶", ici T≈5×10⁶ — la marge de sécurité s'avère tenir au-delà de sa plage testée à l'origine).

Interprétation

Ce déficit (+8 sur 431 837, soit ~1,9×10⁻⁵) est du même ordre de grandeur que le déficit grossier du segment 7 du run réel v16 (+14 sur 1 252 047, ~1,1×10⁻⁵) — la même zone de T. Comme MARGE=2.0 et MARGE=10.0 donnent des CSV strictement identiques dans cette zone, ce déficit de fond affecte les deux réglages de façon identique — cohérent avec la conclusion de l'entrée 18h00 (MARGE_SECURITE innocenté) et avec le fait que les segments 2-7 étaient déjà quasi identiques entre v13 et v16. Ce déficit de fond, à haut T, n'est probablement pas la cause de l'écart 96→177 — celui-ci reste concentré dans les segments 0-1 (bas T), jamais testés par cette méthode faute de données. Test lancé sur ces segments dans la foulée (voir entrée suivante).

Voir aussi

Handoff — section « REPRISE ICI ».

2026-08-18 — 18h00 — Correction : l'explication "paires enjambées par la grille" (récit du 02/08) est invalidée — aucun commit, investigation pure

Contexte : suite au post-mortem du run T=5M v16 (177 manquants avant crash, cf. entrée 12h00 ci-dessous), tentative de trancher si MARGE_SECURITE (2.0 dans v13 → 10.0 dans v16) explique l'écart avec les 96 manquants de v13. Deux tests A/B directs (MARGE=2.0 vs 10.0, compute_zeros_v16.py avec --skip-rescan, fenêtres [4,9M;5M] puis [4,8M;4,9M], cette dernière englobant T≈4 862 705 — la zone précise où l'investigation du 02/08 affirmait que MARGE=3.0 échouait) donnent des résultats strictement identiques dans les deux configurations : 431 837 zéros au total, 0 différence, y compris dans la zone du 02/08 (confirmé par un scan indépendant 5× plus fin que MARGE=10, arb_hardy_z, qui retrouve exactement les mêmes zéros).

Calcul théorique — ferme définitivement la piste résolution de grille

Nombre de paires enjambées attendu sous la loi GUE des petits écarts, intégré sur [14, 5 000 000] :

STEP=0,000314 (v16, MARGE=10) → M ≈ 0,003 zéro
STEP=0,00157 (v13, MARGE=2) → M ≈ 0,33 zéro

Observé : 177 et 96 — soit respectivement ~5×10⁴ fois et ~3×10² fois la prédiction théorique. Ni les 177 ni les 96 ne sont des paires de zéros proches enjambées par la grille de scan. L'explication inscrite au JOURNAL depuis v13 ("paires de zéros proches dont les signes se compensent") est fausse pour ces deux cas précis — à corriger dans toute documentation qui la reprend telle quelle (Formules_zeta.md, skills, STACK.md si applicable).

Découverte plus importante en cours de route : les deux déficits ne sont pas comparables

Lecture des journaux d'exécution réels (pas de nouveau calcul) :

v13 (27-29/06) : valider_turing() a tourné jusqu'au bout du run. Verdict réel, journalisé : ❌ INCOMPLET, 96 zéros manquants confirmés par la méthode exacte (θ(T)/π + 1 + S(T), pas par l'estimateur grossier). Le 96 est donc validé.
v16 (16-17/08) : recherche exhaustive de "VALIDATION TURING-BACKLUND" dans les 563 953 lignes du log réel → 0 occurrence. Le run a été tué par le crash PC1 (03h12) exactement au point "8 segment(s) en déficit → rescan parallèle...", avant d'atteindre valider_turing(). Le "177" n'a jamais été validé par la méthode de référence du projet — c'est uniquement la sortie de _n_zeros_expected(), un estimateur de Weyl tronqué (sans les termes correctifs de Stirling ni la correction S(T)), utilisé en interne pour décider quels segments rescanner, jamais recoupé par le calcul exact pour ce run.

Distribution du déficit par segment — la vraie anomalie

Segment	Bornes (t)	v13 (réel, validé)	v16 (réel, non validé)
0	[14, 737 112]	+18	+51
1	[737 112, 1 391 397]	+9	+49
2	[1 391 397, 2 020 448]	+10	+16
3–7	[2 020 448, 5 000 000]	13/10/9/14/14	13/10/9/14/14

Les segments 2 à 7 sont quasi identiques entre les deux versions (le code de segmentation, comptage et fusion est d'ailleurs prouvé bit-identique par diff direct entre compute_zeros_v13.py et compute_zeros_v16.py — aucune différence fonctionnelle). Toute l'augmentation du déficit (96→177) est concentrée à plus de 90% dans les segments 0 et 1 (bas T) — une signature incompatible avec un mécanisme dépendant de T (grille, GUE, ou autre), qui prédirait l'inverse (déficit croissant avec T, pas concentré en bas de plage).

Conclusion

MARGE_SECURITE est innocenté — ni pour v13 ni pour v16. L'origine réelle du déficit v16 reste ouverte, concentrée sur les segments 0-1 ; piste non testée à date : le détecteur C partagé scan_arb.c a été modifié entre le run v13 (avant commit d4b3611, cache log_n/isqrt_n) et le run v16 (après) — jamais comparé binaire contre binaire.

Correction (18/08, plus tard le même jour) : suggestion initiale de relancer valider_turing() sur le CSV _principal du run v16 — erronée. Vérifié : calculs/v16_T5000000_20260816_193618/ est vide. Le mécanisme _principal (commit 2f2047a) a été ajouté après l'incident ; il n'existait pas au moment du run réel, qui n'a donc jamais rien écrit sur disque (cf. entrée 12h00 — 31h37 perdues, rien récupérable). Le run T=5M v16 réel reste donc définitivement non vérifiable : ni ses zéros ni son verdict Turing-Backlund ne pourront jamais être obtenus a posteriori. Seule option restante pour trancher la complétude de v16 : un nouveau run T=5M complet (~21h) avec le code corrigé, ou une validation Turing correctement windowée sur les échantillons [4,8M;5M] déjà en main (données du test A/B du même jour) en utilisant la formule exacte θ(T)+S(T), pas l'estimateur de Weyl grossier.

Voir aussi

Handoff — section « REPRISE ICI ».

2026-08-18 — 12h00 — Run T=5M v16 : résultat perdu (crash pendant rescan) — post-mortem + correctifs — commit `2f2047a`/`a391beb`

Contexte : run T=5M v16 lancé le 16/08 19h35 sur PC1 seul (PC2 écarté : FLINT système 2.9.0 vs 3.3.1 requis pour v16). Segmentation adaptative sur 8 workers, [14, 5 000 000], N attendu ≈ 10 016 474 zéros.

Bilan du run principal — succès

Terminé le 17/08 à 17h14, en 21h38 (1298,5 min), soit 128,56 z/s. 10 016 297 / 10 016 474 zéros trouvés (déficit de 177), 99,9% via arb_C (précision native FLINT/Arb, quasiment aucun fallback). Résultat conforme aux attentes du pipeline v16.

Incident — résultat intégralement perdu

À 17h14, rescan_segments_deficit() démarre automatiquement : re-scan à step/2 sur la largeur complète des 8 segments (pas seulement les zones en déficit), via Pool.map() synchrone. Aucun CSV n'avait encore été écrit à ce stade.

Le 18/08 à 03h12, PC1 s'éteint — arrêt qui apparaît propre côté log système, cause non identifiée (voir Bloc B ci-dessous, journal non persistant à l'époque des faits). Une cascade de 6 reboots courts entre 06h19 et 06h30 suit, non expliquée.

Conséquence : les 10 016 297 zéros du run principal, pourtant complets et valides en RAM depuis 17h14 la veille, n'ont jamais été écrits sur disque. 31h37 d'exécution cumulée (run + début de rescan), rien de récupérable.

Cause racine : sauvegarder_csv() n'était appelé qu'après le retour de rescan_segments_deficit() dans compute_zeros_v16.py — un rescan interrompu entraînait donc la perte du run principal lui-même, alors que celui-ci était déjà terminé et exploitable.

Précédent identique (v13, T=5M, 27-29/06) : même stratégie de rescan intégral, ~18,8h de calcul pour +1 zéro net sur 96 manquants — rendement ~1%, déjà documenté comme peu rentable, jamais corrigé avant cet incident.

Anomalie non résolue à date : le déficit v16 (177 zéros manquants) est quasiment le double du déficit v13 (96 zéros manquants) pour le même intervalle T=5M. Cause non tranchée — investigation en cours (test empirique v15 vs v16 à T=100k).

Correctifs appliqués — branche `Riemann_Lab_C`

2f2047a — compute_zeros_v16.py : le CSV principal est désormais écrit immédiatement après le run principal, avant tout appel à rescan_segments_deficit() (livrable autonome, survit à un rescan interrompu). Chaque worker écrit en plus son propre CSV de checkpoint dès sa fin (Pool.map → Pool.imap_unordered) : un arrêt à mi-parcours du run principal laisse désormais les segments déjà terminés exploitables au lieu de tout perdre. Nouveau flag --skip-rescan pour lancer le run principal seul.
a391beb — scripts/zeta_run.sh pointait encore sur compute_zeros_v13.py depuis juin (jamais mis à jour malgré l'usage réel de v16 depuis le 16/08) → corrigé. Ajout de systemd-inhibit --what=shutdown:sleep:idle --mode=block autour du calcul, pour empêcher toute extinction/veille système pendant un run.

Bloc B — fiabilité matérielle de PC1 pour un run de 21h : INDÉTERMINÉ

Diagnostic mené sans créer de règle sudoers dédiée (commandes root lancées à la main par hprzeta) :

Journal systemd non persistant avant le boot du 18/08 08h19 — journalctl --list-boots ne remonte pas avant cette heure, aucune trace du crash 03h12 ni de la cascade 06h19-06h30, irrécupérable.
/var/log/apt/history.log : dernière MAJ le 15/08 (firmware, pas de noyau), 3 jours avant le crash — probablement non causal.
Batterie : 753 cycles, capacité 70,2% (usure notable) — état instantané seulement, rien sur l'état réel à 03h12.
smartctl/dmesg : nécessitent root, résultat en attente.

Conclusion acceptée telle quelle : indéterminé, la piste la plus plausible restant une batterie usée (arrêt propre suivi d'une cascade de reboots courts).

Sécurité — trouvé au passage, traité dans la foulée

docs/archive/zeta-secure-backup.tgz (non tracké) contenait une clé privée WireGuard de PC4 en clair. Déplacé hors du repo (~/riemann_handoff/secrets_local/), .gitignore de Riemann_Lab_C corrigé. Recherche exhaustive dans tout l'historique git (toutes branches, tous blobs) : jamais commitée, aucune fuite. Reste à propager le .gitignore aux 3 autres branches et à régénérer la clé WireGuard + le token DuckDNS de PC4 par précaution.

Voir aussi

Handoff — section « REPRISE ICI » pour l'état courant et la suite.

2026-08-17 — journée — Run T=5M v16 lancé sur PC1 seul + bug dashboard ETA corrigé (non commité) : Workers 1-7 muets après 13h, point de vigilance non tranché

Contexte : décision prise en session (question posée, réponse « PC1 seul, v16 ») après découverte que PC2 ne peut pas exécuter v16 (git absent, FLINT système 2.9.0 vs 3.3.1 requis, compute_zeros_v16.py absent sur PC2 — mise à niveau jugée hors scope). Secteur PC1 vérifié branché avant lancement (règle post-incident UPower du 04/08). scripts/zeta_run.sh corrigé au passage : pointait encore sur compute_zeros_v13.py depuis juin — fix non commité à ce stade (committé plus tard, voir entrée du 18/08 « 12h00 », commit a391beb).

Lancé via bash scripts/zeta_run.sh 5000000 en arrière-plan : PID racine 485255, log logs/run_T5000000_20260816_193542.log, 8 workers sur [14, 5 000 000], N attendu ≈ 10 016 474 zéros. Suivi créé : logs/suivi_run_T5M_v16_20260816.md (non versionné).

Point de vigilance sérieux : à ~13h d'exécution (08h19 le 17/08), seul le Worker 0 avait produit la moindre ligne de progression (segment [14, 737112.8] terminé, ~1 252 000 zéros). Les Workers 1 à 7 n'avaient toujours logué aucun checkpoint, alors que le run v15 T=5M du 04/08 montrait les autres workers actifs bien avant ce délai. Peut être une phase de scan initiale anormalement longue (déjà documentée comme silencieuse par conception), ou un vrai blocage — non tranché, run volontairement non touché (consigne explicite hprzeta : ne rien faire qui perturbe le calcul).

Dashboard `zeta_run_progress.py` — bug trouvé et corrigé (non commité à ce stade)

Le dashboard affichait une progression et une ETA totalement fausses (50%, 709,8 min) car il lisait un vieux log figé du 04/08 (run v15 distribué PC1+PC2) au lieu du run solo en cours — zeta_distribute.py (PC1+PC2) et zeta_run.sh (solo) produisent des noms de log différents, jamais réconciliés dans le dashboard jusqu'ici. Corrigé : détection automatique du mode (solo vs distribué, comparaison de mtimes des 2 familles de logs), recalcul sur le bon N total en solo, section PC2 grisée au lieu de 0%, ETA pondérée en √t (coût par zéro croissant avec t, intégrale fermée sur les bornes de segment de chaque worker) avec garde-fou si tous les workers n'ont pas encore de données. Vérifié sur les vraies données : 12,5% réel vs 50% affiché à tort.

Le reste de la journée du 17/08 (audit complétude backup, échec rclone) est documenté dans les deux entrées suivantes.

2026-08-17 — Audit complétude backup PC1→PC3 : 3 tâches (cron rsync innocenté, crontab durcie proposée, PDF cours obsolètes listés) — rien committé/installé/lancé

Contexte : suite à l'audit de complétude PC1↔PC3 (logs/pdf/wiki) demandé la veille, qui semblait montrer wiki/ et logs/ figés depuis 16/08 17h44-19h37 (ni l'un ni l'autre des 2 cron 01h50 connus) — hprzeta a demandé 3 tâches, avec pour priorité absolue de ne rien faire qui ralentisse le run T=5M v16 en cours (4 cœurs 100%, ETA ~24h).

Tâche 1 — Le cron 01h50 fonctionne-t-il ? → OUI, correction de l'audit de la veille

L'audit précédent était erroné sur ce point précis. Comparaison mtime (préservé par rsync -a depuis la source — ce que l'audit avait pris à tort pour « heure de synchro ») vs ctime (heure réelle d'écriture sur PC3, non falsifiable par rsync) :

Fichier	mtime (= état source)	ctime (écriture réelle PC3)
`wiki/JOURNAL.md`	16/08 17:44:53	17/08 01:50:03
`wiki/.git/index`, `.git/COMMIT_EDITMSG`	16/08 17:45:05	17/08 01:50:05
`pdf/cours/Bibliotheques.pdf`	05/07 13:44	06/07 01:50:17 (1ʳᵉ synchro, jamais retouché depuis — source inchangée)

Le cron écrit bien sur PC3 à 01h50:0x précisément, les 2 nuits vérifiées. Un fichier dont la source n'a pas changé depuis 17h44 la veille est censé garder ce mtime après une synchro réussie à 01h50 — ce n'était pas un échec, juste une mauvaise lecture des mtimes par l'audit initial.

Vérifications complémentaires, toutes positives :

systemctl status cron : actif en continu depuis le boot (15/08 11h13), 0 redémarrage.
uptime/journalctl : PC1 allumé sans interruption depuis le 15/08 11h13, aucun suspend/hibernate.
~/.bash_history : aucune trace de rsync manuel vers PC3 (seules entrées rsync trouvées : vers PC2, ou anciens clonages disque sans rapport).

Anomalie réelle, non résolue : logs/run_T5000000_20260816_193542.log a bien ctime=17/08 01:50:01 (écrit par ce cron) mais son contenu correspond à l'état du fichier à 19h36 la veille (1726 octets), pas à son état réel 6h+ plus tard. Seul fichier activement modifié en continu pendant la fenêtre de synchro parmi les 3 legs — la tâche 2 (logging par leg) donnera de la visibilité réelle au prochain run.

Tâche 2 — Crontab durcie proposée (PAS installée, en attente de validation hprzeta)

Fragilité identifiée : les 3 rsync du crontab sont chaînés par && — si logs/ bloque ou échoue, wiki/ et pdf/ ne partent jamais. Combiné à -aq sans aucune redirection de sortie dans le crontab original, toute erreur était silencieusement perdue (pas la faute de -q en soi, qui ne filtre que les messages non-erreur — la vraie cause du silence total était l'absence de >> log 2>&1).

Correctif proposé : && → blocs indépendants par ;, log de sortie ~/rsync_cron.log (hors de logs//wiki//pdf/ — piège rclone du 16/08 évité dès le départ), timestamp + rc=$? avant/après chaque leg. --timeout=120 proposé en option (protège contre un leg bloqué sous forte charge CPU sans se déclencher à tort sur un simple ralentissement) — pas appliqué, en attente d'accord explicite.

Tâche 3 — PDF `pdf/cours/` obsolètes : 3 à régénérer, liste prête (rien lancé)

Source `.md`	Modifié le	PDF	Généré le	Écart
`Guide-Linux-Commandes.md`	16/08 17:07	`Guide-Linux-Commandes.pdf`	05/07 13:44	42 j
`Formules_zeta.md`	09/08 16:04	`Formules_zeta.pdf`	05/07 13:44	35 j
`Bibliotheques.md`	08/08 20:45	`Bibliotheques.pdf`	05/07 13:44	34 j

Les 6 niveau-N-*.md (curriculum) sont inchangés depuis le 06/06 — leurs PDF (05/07) sont plus récents, à jour, aucun regen nécessaire. Moteur confirmé via pdfinfo (Producer: xdvipdfmx) : build_pdf_riemann.sh (xelatex), pas la variante _CM.sh (lualatex). Piège flèche Unicode dans un span de code inline vérifié sur les 3 fichiers (recherche précise, pas de faux positif inter-spans) : aucun cas trouvé, sources utilisables telles quelles. Commandes prêtes, non exécutées (LuaTeX/XeLaTeX coûteux en CPU, à lancer après la fin du run T=5M).

Aucune commande lourde exécutée sur PC1 pendant cet audit (uniquement lecture de logs, stat, grep) — run T=5M non impacté.

2026-08-17 — 02h20 — Backup rclone PC3→ProtonDrive : les 2 causes du 16/08 tiennent, mais échec cette nuit pour une 3ᵉ raison non identifiée

Contexte : vérification programmée automatiquement pour la nuit suivant le correctif du 16/08 (log sorti de ~/backup/ + downgrade rclone 1.73.5), afin de confirmer que le cron automatique de 02h00 réussirait enfin.

Résultat du cron 02h00 : zeta_backup_status.py --date 2026-08-17 → ÉCHEC.

Les 2 causes corrigées la veille tiennent — vérifié explicitement dans le log de cette nuit :

Aucune ligne Failed to copy: can't copy - source file is being updated (cause n°1 — log auto-copié).
Aucun fatal error: found bad pointer in Go heap (cause n°2 — crash Green Tea GC sur 386).

Nouveau symptôme, cause non identifiée : le process a tourné normalement (401 auto-résolu, plusieurs 422 fichier existe déjà — attendu, nettoyage de drafts orphelins en cours) puis s'est arrêté net à 02h00:33, en plein backoff 429 Too many requests, sans aucune ligne de sortie/erreur finale (ni NOTICE: Failed to copy, ni Transferred:, rien).

Pistes investiguées et écartées :

OOM killer : aucune trace dans dmesg/syslog, 4,8 Go RAM disponibles au moment du check.
Reboot : uptime continu depuis le 15/08 17h10, aucune interruption.
Session systemd tuant les process cron (hypothèse KillUserProcesses + absence de linger pour pjexosql) : invalidée après vérification — /etc/pam.d/cron inclut common-session-noninteractive, qui n'appelle PAS pam_systemd.so sur cette machine. Les jobs cron ne créent pas de session logind ici, donc pas de kill lié à la fin de session.
Espace disque : 178 Go libres, non en cause.

Aucune cause trouvée. Le process a disparu sans trace exploitable dans les logs système consultables sans root.

Relance manuelle immédiate (02h21) : rc=0, silencieux, aucune erreur — confirme que l'état est à jour sur Proton Drive malgré l'échec du cron automatique. Pas de perte de données, juste un run automatique manqué.

Aucun correctif appliqué — pas de piste solide identifiée, symptôme non reproduit à la demande. À surveiller sur les prochaines nuits : si ça se reproduit, ce sera un 3ᵉ problème distinct des 2 déjà corrigés, à investiguer plus en profondeur (accès root probablement nécessaire pour des logs plus complets, ou instrumentation du process au prochain déclenchement).

2026-08-16 — 17h41 — Backup rclone PC3→ProtonDrive réparé : jamais fonctionné depuis le 15/06, 2 causes trouvées et corrigées — commit `65e64f4`

Contexte : hprzeta pensait le problème réparé et a demandé de tester, sinon d'investiguer le crash rclone documenté depuis le 05/08 (zeta_backup_status.py, 7/7 jours en échec).

Test — résultat KO

zeta_backup_status.py a confirmé 7/7 jours en échec, y compris la nuit même (16/08, 02h00). Pas réparé.

Investigation — découverte majeure

En remontant tout l'historique de ~/backup/rclone_cron.log sur PC3 (56 628 lignes) : 0 succès depuis le tout premier run, 15/06/2026 — le job n'a jamais fonctionné une seule fois en 2 mois, bien avant la fenêtre « 7/7 jours » suivie depuis le 05/08.

Cause n°1 (chronique, 100% des runs) — le crontab écrivait le log du rclone à l'intérieur du dossier qu'il copiait :

0 2 * * * /usr/bin/rclone copy /home/pjexosql/backup/ protondrive:... >> /home/pjexosql/backup/rclone_cron.log 2>&1

rclone essayait donc de copier son propre fichier de log pendant qu'il grossissait → Failed to copy: can't copy - source file is being updated chaque nuit sans exception, laissant un upload « draft » orphelin côté Proton Drive, ce qui provoquait en cascade des 422 fichier existe déjà (556 occurrences en 2 mois) et a draft exist (124 occurrences) sur les tentatives suivantes.

Cause n°2 (intermittente, ~1 run sur 3, 38 occurrences en 2 mois) — fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?), un crash mémoire du runtime Go. rclone v1.74.3 (binaire installé le 13/06, jamais mis à jour depuis) est compilé avec go1.26.4, où le nouveau Green Tea GC est devenu le ramasse-miettes par défaut — fonctionnalité encore récente, historiquement associée à des instabilités sur architectures 32 bits (recherche web : issues golang/go sur 386, dont une explicitement titrée « on 386 FreeBSD »). Or PC3 tourne en 386/i686 (Ubuntu 16.04, noyau 4.4.0-210). GOEXPERIMENT=nogreenteagc existe mais c'est un flag de compilation, pas une variable d'environnement runtime — impossible à désactiver sans recompiler rclone.

Correctif appliqué et testé

Log sorti du périmètre sauvegardé : déplacé ~/backup/rclone_cron.log → ~/rclone_cron.log sur PC3 (historique préservé), crontab mis à jour.
Downgrade rclone : testé empiriquement plusieurs binaires 386 réels (téléchargement direct + lecture de go/version) pour trouver la bascule Go 1.25→1.26 : entre v1.73.0 (go1.25.6) et v1.74.0 (go1.26.2). Installé v1.73.5 (go1.25.9, dernier correctif encore sur Go 1.25) dans ~/bin/rclone — pas /usr/bin/rclone (root, pjexosql n'a pas de sudo non-interactif sur PC3) : aucune élévation de privilège nécessaire, binaire système laissé intact.
Test réel (commande exacte du cron, lancée à la main) : 1er run rc=0, quelques 422/429 (nettoyage des drafts orphelins accumulés en 2 mois), aucun crash Go. 2ᵉ run immédiat : nothing to transfer, 1749/1749 checks OK, 0 erreur, 34.5s.
scripts/zeta_backup_status.py mis à jour pour suivre le log à son nouvel emplacement (PC3_RCLONE_LOG).

Confirmation définitive attendue au prochain déclenchement cron automatique (17/08, 02h00) — les tests ci-dessus ont été lancés manuellement, pas via le cron lui-même.

Commit code 65e64f4 (Riemann_Lab_C). Détail complet dans STACK.md § Infrastructure backup.

2026-08-16 — Fusion Guide-Linux-Commandes.md (commandes session admin distante du 15/08) — commit `166b7ba`

Contexte : un fichier ~/Téléchargements/Ajout-Guide-Linux-Commandes-20260815.md contenait 10 sous-thèmes de commandes découvertes lors d'une session d'administration à distance du cluster le 15/08/2026 (SSH+doas vers PC4 zeta-secure, mise à jour OpenBSD, mise à jour Debian/Ubuntu PC2/PC3, gestion des users, arrêt/démarrage de PC4). Demande hprzeta : fusionner ce contenu dans Guide-Linux-Commandes.md (guide vivant du wiki) sans dupliquer les sections existantes.

Fusion réalisée

§4 SSH — nouvelle sous-section « SSH à distance avec doas/sudo — piège du TTY » : doas/sudo en mode interactif nécessitent un pseudo-terminal ; sur une commande SSH non-interactive, ssh -t <host> "doas <commande>" est obligatoire (sinon doas: a tty is required). Piège de syntaxe documenté : ssh doas host "..." est interprété par SSH comme un hostname doas, pas comme une commande — doas doit toujours être à l'intérieur des guillemets.
§6 OpenBSD — sous-sections existantes enrichies :
- « Droits et sudo » : renvoi croisé vers §4 pour le piège TTY.
- « Patches de sécurité » : ajout de syspatch -l (historique des patches déjà installés) avec distinction claire face à syspatch -c (ce qui reste à appliquer — vide = système à jour).
- « Paquets » : ajout de pkg_add -u -n (simulation de mise à jour globale, dry-run) et pkg_add -u (application).
- 4 nouvelles sous-sections ajoutées en fin de §6 : Prompt ksh — personnalisation PS1 (syntaxe $(commande) propre à ksh, piège clavier AZERTY — la touche 7 produit è au lieu de l'apostrophe ' nécessaire au shell, provoquant no closing quote) ; Arrêter un process lié à une console (doas pkill -t ttyC0, nettoyage d'une ligne ajoutée dans /etc/rc.local) ; Extinction / redémarrage propre (doas shutdown -p now/+2, doas reboot) ; Consoles virtuelles (Ctrl+Alt+F1/F2/F3).
Tableau « Leçons importantes apprises » : 3 nouvelles lignes (piège ssh doas host, apostrophe AZERTY dans PS1 ksh, pile CMOS morte).
3 nouvelles sections numérotées créées en fin de guide (pas de section correspondante existante) :
- §23 — apt : mise à jour système à distance (PC2/PC3) : apt update && apt list --upgradable puis apt upgrade -y via ssh -t. Note : PC3 (Ubuntu 14.04, Python 3.5.2 — cf. §15) déjà à jour lors du test du 15/08, aucun risque pour le fix f-string de zeta_monitor.py.
- §24 — Cluster : users locaux vs hprzeta, désactivation auto-login : boucle for h in ... ; do ssh $h whoami; done pour vérifier le user de connexion sur les 4 machines ; rappel des users locaux d'origine par machine (emmabuntus PC2, pjexosql PC3, aucun identifié sur PC4) — hprzeta doit rester identique partout (dépendance de tout le tooling cluster) ; procédure de désactivation de l'auto-login GDM3/LightDM sur PC2.
- §25 — vi : aide-mémoire minimal (G, o, dd, :wq, :q!).
Aucun contenu existant supprimé ; format du guide conservé (blocs bash, tableaux, notes ⚠️/💡).

Vérification et publication

Diff vérifié avant commit (git diff --stat → 244 insertions, 2 lignes modifiées, 0 suppression).
En-tête et pied de page du guide resynchronisés : MAJ 2026-08-15, 1316 lignes (recompté via wc -l après fusion, guide passé de 1074 à 1316 lignes).
Commit 166b7ba (« docs(guide-linux): fusion commandes session 15/08 »), poussé sur origin/master (dépôt wiki séparé).
Fichier temporaire ~/Téléchargements/Ajout-Guide-Linux-Commandes-20260815.md supprimé après confirmation de la fusion.
Handoff.md mis à jour dans la foulée (commit 136bb4b) : nouveau pointeur 📍 REPRENDRE ICI, ancien chantier du 09/08 rétrogradé en ✅ clos.

2026-08-09 — Harmonisation des fichiers dupliqués + liens explicatifs du site (6 sous-chantiers, chantier clos) — 10 commits `Riemann_Lab_C` (`d99d7a1`→`56bd559`), wiki `dc6ede9`

Contexte : session enchaînant 6 sous-chantiers sur la cohérence documentaire du projet (doublons de fichiers, tableau de progression du site public, synchronisation des 4 branches).

Recensement complet des doublons dans tout le projet (wiki, docs/, .claude/skills/riemann-lab/references/, skills_export/, pdf/optimisation/, racine repo) : 12 groupes identifiés. Fusion de Formules_zeta.md (§31 v16 ajouté, manquant côté wiki), propagation vers docs//.claude/skills//skills_export/. Suppression de 3 orphelins (JOURNAL.md racine — contenu unique réintégré dans le wiki avant suppression —, handoff/Handoff.md, docs/phase-c-illinois-SKILL.md) + 2 doublons PDF orphelins trouvés a posteriori dans docs/pdf/ (identiques octet pour octet à des fichiers déjà corrects dans pdf/optimisation/, supprimés). Règle permanente ajoutée (Handoff + STACK) : vérifier la synchro des copies dupliquées avant de travailler dessus.
Site public (docs/index.html) — tableau de progression v1→v16 : colonne « Formule principale » rendue cliquable + colonne « Analyse » (rapports analyse_problemes_vN_vN+1). 3 liens morts détectés et corrigés (v2→v3, v3→v4 — pages wiki jamais créées ; GitHub redirige silencieusement une page absente vers la Home, HTTP 200, aucune erreur visible — détecté en comparant le <title> de chaque page à une page témoin délibérément inexistante). Colonne Analyse repassée à 100% PDF sur décision hprzeta (fiabilité) — dernière exception (v7→v8, qui n'existait qu'en page wiki) résorbée en générant le PDF depuis le wiki (build_pdf_riemann_CM.sh, LuaTeX, après correction d'un piège \lstinline/flèche Unicode). Colonne Analyse : 100% PDF, 0 exception.
2 erreurs factuelles corrigées sur la ligne v8 (vérifiées contre STACK.md/Formules_zeta.md) : « 64→80 bits » → « 116→80 bits », Gain « — » → « ×1,06 vs v7 ».
Ligne v6 manquante ajoutée (v4 et v11 légitimement absents — v4 défaillant, v11 jamais implémenté — mais v6 était un jalon réel déjà référencé par la ligne v7 « ×4,2 vs v6 » sans exister lui-même). Tableau du site désormais 15 lignes.
Vérification exhaustive : 26 liens finaux du tableau (15 Formule principale + 11 Analyse) testés individuellement — ancres wiki comparées aux href="#..." réels de GitHub (piège évité : le préfixe user-content- que GitHub résout côté client donne un faux négatif si on le cherche sans), PDF vérifiés HTTP 200 + en-tête %PDF + taille exacte. Temps recoupé zéros÷durée pour les 14 lignes historiques, concordant partout (517 z/s et 1407 z/s de v15/v16 confirmés par 4 citations indépendantes).
Synchronisation en ligne (6 cycles) : Riemann_Lab_C → fast-forward Riemann_Lab_IA → merge main → merge Riemann_Lab_Test, 0 conflit sur les 18 opérations de merge/ff. Build GitHub Pages suivi jusqu'à status: built puis site public re-fetché en direct après chaque cycle. État final : Riemann_Lab_C/ Riemann_Lab_IA = 56bd559 · main = e984349 · Riemann_Lab_Test = c59d7ce. Wiki master = dc6ede9.

Chantier définitivement clos. Règle de méthode confirmée : jamais git add -A, fichier par fichier ; en-tête/pied de page standard sur chaque .md (date + hprzeta + nombre de lignes).

Rappel — run T=5M v15 toujours arrêté à cette date

Relancé 04/08 22h48, tué à la main le 06/08 après 23h20 sans progression côté PC2 (goulot confirmé : 2 cœurs physiques / 8 workers + pas de turbo + zone à t la plus élevée du run). PC1 : résultat complet et sauvegardé (calculs/ v15_T14_3469744_20260804_224851/, 670 Mo, 6 749 092 zéros sur [14, 3469743.76]). PC2 : ~23h20 de calcul perdues, non récupérables. GPU (PC1 GTX 960M sm_50, PC2 sans CuPy) confirmé non exploitable — mur matériel. Décision de suite non tranchée à cette date (accélérée depuis par v16, voir entrées du 16-18/08 ci-dessus).

2026-08-06 (nuit) — Run T=5M v15 arrêté manuellement (PC2 jamais abouti, 23h20 sans progression) + multi_ia_query.py créé

PC2 — 23h20 sans la moindre ligne de progression, aucune ETA jamais atteignable

Suite de la session du 04-05/08 (run relancé après l'incident alimentation PC1, cf. entrée ci-dessous). Pendant toute la surveillance du 05/08 au 06/08 :

PC1 a fini l'intégralité de ses 8 workers entre 6h17 (Worker 0) et 11h49 (Worker 7) — 6 749 092 zéros sur [14, 3469743.76] (attendu N≈6 749 158), 0 erreur. CSV sauvegardé : calculs/v15_T14_3469744_20260804_224851/ zeros_v15_T3469744_20260804_224851.csv (670 Mo).
PC2 n'a produit STRICTEMENT AUCUNE ligne de progression du lancement (04/08 22h48) jusqu'à l'arrêt (06/08), soit 23h20 de calcul continu. Vérifié en profondeur à plusieurs reprises : les 8 process restaient en état R, ~23,7-24% CPU chacun (cohérent avec 2 cœurs physiques / 8 workers), RAM/swap sains, ELAPSED en croissance continue (pas figé), module C scan_arb.so confirmé chargé (pas de fallback Python lent). PC2 n'était donc pas bloqué — juste structurellement incapable de finir dans un temps raisonnable.
Tentative de chiffrer un ordre de grandeur par comparaison avec le Worker 7 de PC1 (segment le plus proche en t) : volume de grille PC2/worker ≈ 56% de celui du Worker 7 (qui a mis 11h49) → un débit identique aurait dû donner ~6h30, or on était déjà à plus de 3,5× ce chiffre sans qu'aucun worker PC2 n'ait fini ne serait-ce que sa phase de scan. Écart attribué à 3 facteurs cumulés (tous structurels) : pas de turbo sur PC2, oversubscription ×4 (vs ×2 sur PC1), coût de scan par point plus élevé (zone à t la plus haute du run). Aucune ETA fiable n'a jamais pu être établie — 0 point de débit réel mesuré sur PC2 du début à la fin.

Décision — arrêt manuel (hprzeta, 06/08 nuit)

Après confirmation explicite de la portée (« tout tuer », option retenue face au risque de perdre le calcul PC2 en cours vs. laisser tourner indéfiniment sans ETA) :

PC2 tué via SSH (pkill -f compute_zeros_v15) — confirmé arrêté, plus aucun process python3. ~23h20 de calcul PC2 perdues, non récupérables (aucun résultat partiel n'était écrit sur disque, les workers n'écrivent qu'à la fin).
L'orchestrateur local (zeta_distribute.py, PID 32270/32273) s'était déjà auto-terminé au moment du kill : la commande SSH bloquante vers PC2 (PID 32465) a remonté un code retour 255 (connexion coupée), correctement détecté et journalisé par le script : [PC2] terminé en 1415.33 min (ret=255) → ❌ PC2 a échoué (code 255).
zeta_turbo_off.sh s'était déjà exécuté automatiquement à la sortie du script — système confirmé restauré (scaling_governor=powersave sur les 4 cœurs, swappiness=10, bluetooth/avahi-daemon actifs). Rien à restaurer manuellement.
/tmp/zeta_distribute.pid nettoyé, surveillance (Monitor Claude Code) arrêtée.

PC1 reste exploitable seul pour une investigation partielle des 96 manquants du run v13 si besoin, sans attendre PC2. Décision sur la suite (relancer tel quel / revoir le split PC1-PC2 / se contenter du résultat PC1) pas encore prise — cf. Handoff.md § REPRENDRE ICI. Détail chronologique complet (heure par heure) → logs/suivi_run_T5M.md.

Architecture scan-puis-affinage documentée dans le skill phase-c-illinois : chaque worker scanne tout son segment en un bloc avant la moindre ligne de progression — un silence prolongé n'est pas en soi un signe de blocage (à vérifier via ps, pas via l'absence de logs).

multi_ia_query.py — orchestrateur Claude/DeepSeek/Kimi créé et testé

scripts/multi_ia_query.py : interroge les 3 IA en parallèle (ThreadPoolExecutor), gestion d'erreur indépendante par IA, rapport Markdown versionné dans pdf/optimisation/Voie_b_5/md_to_claude/ (staging déjà exclu de git). DeepSeek et Kimi via le SDK openai (API compatible OpenAI, base_url dédiée) ; Claude via le SDK anthropic officiel. Secrets dans .env (jamais committé).

Gap de sécurité corrigé au passage : .env était absent des .gitignore des 4 branches — ajouté et poussé partout (Riemann_Lab_C, main, Riemann_Lab_IA, Riemann_Lab_Test). .env.example créé comme modèle (committé).

Testé sans clés API (aucune disponible actuellement) : les 3 IA échouent proprement en parallèle, rapport généré correctement (0/3 succès affiché, message d'erreur clair par IA). --skip validé. Tests avec clés réelles reportés — clés Anthropic/DeepSeek/Kimi pas encore fournies par hprzeta.

Commits : 201f621→1a89619 (.gitignore × 4 branches), d4a1d15 (multi_ia_query.py + .env.example, Riemann_Lab_C).

2026-08-05 — zeta_backup_status.py créé — échec systématique de la sauvegarde cloud PC3→ProtonDrive découvert (7/7 jours)

Contexte : pendant la surveillance du run T=5M v15 (cf. entrée du 04/08 ci-dessous), demande d'un outil de vérification quotidienne de l'activité de PC3 (zeta-backup), jusqu'ici jamais contrôlée sur le fond (statut « ✅ auto » de la mémoire de session reposait uniquement sur la présence du cron, pas sur son résultat réel).

Script créé

scripts/zeta_backup_status.py + alias zeta-backup-status (~/.bashrc, aucun conflit de nom trouvé) — deux tableaux :

PC1→PC3 (rsync) : déclenchement du cron via /var/log/syslog(.1) (le job -aq ne journalise rien lui-même) + atterrissage réel via la fraîcheur des fichiers sous ~/backup/{logs,wiki,pdf} côté PC3 (find -newermt).
PC3→ProtonDrive (rclone) : parsing de ~/backup/rclone_cron.log — succès (ligne Transferred:), échec (ERROR/fatal error: Go), ou sauté.

Piège trouvé en écrivant le script : l'alias zeta-backup (~/.ssh/config) connecte en tant qu'utilisateur hprzeta, mais le dossier ~/backup/ n'existe que sous le compte pjexosql (même machine, [IP_PC3]) — c'est ce dernier qu'utilise la crontab de sauvegarde (rsync ... pjexosql@[IP_PC3]:~/backup/...). Le script SSH explicitement en pjexosql avec la clé ~/.ssh/id_acer, indépendamment de l'alias cluster.

Testé (sans --date = 7 derniers jours, puis --date 2026-08-04 et --date 2026-08-05) : fonctionne, gère un PC3 injoignable proprement (timeout SSH → message clair, pas de crash — vérifié en pointant temporairement vers une IP injoignable, script non touché).

Découverte — sauvegarde cloud en échec systématique

7 jours sur 7 testés (30/07 → 05/08) : ÉCHEC côté rclone. Crash Go répété chaque nuit vers 02h00 :

fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)

(certains jours : found pointer to free object), précédé systématiquement de 401 Invalid access token et de conflits 422 (« Un fichier ou un dossier portant ce nom existe déjà »). Aucune ligne Transferred: de succès trouvée dans l'intégralité du log (rclone_cron.log, 50 539 lignes, ~3,5 MB) — la synchronisation cloud ne fonctionne peut-être pas depuis bien plus longtemps que cette semaine, pas juste depuis l'incident d'alimentation PC1.

Cause probable, non confirmée : rclone_cron.log est lui-même à l'intérieur du périmètre sauvegardé (~/backup/) et grossit pendant que rclone le copie — logs observés : Failed to copy: can't copy - source file is being updated (size changed from X to Y). Sur un PC3 32 bits (i686, Pentium E2140, 3 GB DDR2), ce conflit pourrait dégénérer en corruption mémoire (le crash Go bad pointer/pointer to free object est un symptôme classique de heap corruption, pas juste un timeout réseau). Aucune investigation menée cette session — juste documenté, cf. STACK.md § Infrastructure backup et Handoff.md (local, section PROMPT_REPRISE) pour la priorité de la prochaine session.

Point positif : l'étape 1 (rsync PC1→PC3) atterrit correctement quand elle se déclenche (fichiers reçus confirmés côté PC3 pour 02/08 et 04/08 sur la période testée) — le problème est bien localisé à l'étape 2 (rclone→cloud), pas à l'ensemble du pipeline.

Documentation : Guide-Linux-Commandes.md §20 (wiki).

Session du 4 août 2026 — Incident alimentation PC1 (3 redémarrages) + correctif UPower + relance run T=5M v15

Contexte — run T=5M v15 introuvable au retour

Point projet demandé avant absence : le run T=5M v15 lancé le 02/08 à 20:29 (PID supposé 200788, investigation des 96 manquants du run v13, cf. session 27/06) était censé tourner ~13h sans interruption. Au retour : aucun process actif, dossier de résultats calculs/v15_distribue_T5000000_20260802_202921/ vide.

Diagnostic — reconstitution via `sar` (le journal systemd est volatile, un seul boot conservé)

Heure	Événement
02/08 20:40	CPU → 98 % (run en cours)
03/08 00:45	`LINUX RESTART` non planifié — run tué après ~4h, aucun résultat écrit
03/08 10:38–19:10	Machine idle (rien relancé)
03/08 19:19	2ᵉ `LINUX RESTART`
03/08 23:34 → 04/08 18:19	Machine éteinte ~18h45 (trou total syslog)

3 redémarrages/extinctions non commandés en moins de 24h — pas un incident isolé.

Cause racine identifiée : PC1 tournait sur batterie, débranché (2 alertes "Running on LOW Battery" le 03/08). CriticalPowerAction=HybridSleep configuré à 5 % de batterie (action forcée à 2 %) dans /etc/UPower/UPower.conf, mais aucun resume= câblé (absent de /proc/cmdline et de /etc/initramfs-tools/conf.d/resume), malgré une swapfile de 16G disponible (/mnt/data/swapfile — un fichier, pas une partition, donc nécessiterait en plus un resume_offset= précis). La veille hybride ne peut donc pas reprendre proprement et dégénère en redémarrage/extinction sauvage au lieu d'une vraie mise en veille. Confirmé : débranchement manuel accidentel, pas une panne matérielle récurrente.

Correctif appliqué (04/08/2026, PC1 uniquement)

sudo sed -i 's/CriticalPowerAction=HybridSleep/CriticalPowerAction=PowerOff/' \
  /etc/UPower/UPower.conf
sudo systemctl restart upower

Vérifié après coup : AC0 online: yes, CriticalPowerAction=PowerOff actif en mémoire (démon redémarré après l'édition du fichier), aucune veille GNOME/logind automatique résiduelle (sleep-inactive-*=nothing, idle-delay=0, IdleAction=ignore). Seul point résiduel non modifié : HandleLidSwitch=suspend (défaut logind) — éviter de fermer le capot pendant un run.

Audit veille des 4 machines du cluster — aucune politique de veille automatique active nulle part : PC2/PC3 sur défauts systemd sans IdleAction, PC4 (OpenBSD) sans démon apmd actif. PC2/PC3/PC4 sont alimentés en continu, seul PC1 (portable) était concerné.

Documentation : Guide-Linux-Commandes.md §19 (wiki, commit ed4b48c).

Leçon durable : nohup/setsid protègent un process d'une fermeture de session ou d'une déconnexion SSH, pas d'un vrai poweroff/reboot — seul un secteur branché en continu garantit la survie d'un run long sur un portable.

Relance du run T=5M v15 (04/08/2026 22:48)

Feu vert donné après vérification secteur branché. Relancé via zeta-distribute 5000000 (= scripts/zeta_distribute_run.sh) :

PID racine 32270, horodatage 20260804_224851
PC1 (local, 8 workers) : [14.0, 3469743.76] → N≈6 749 158
PC2 (SSH zeta-calc-second, 8 workers) : [3469743.76, 5000000] → N≈3 267 315
Durées prévues : PC1 136,8 min · PC2 106,3 min
Logs : logs/distribute_T5000000_nohup_20260804_224841.log, distribute_pc1_20260804_224851.log, distribute_pc2_20260804_224851.log
Surveillance automatique active pendant l'absence (progression + détection d'erreur/interruption toutes les 5 min).

Prochaine action au retour : vérifier le rapport de distribution final (calculs/v15_distribue_T5000000_20260804_224851/rapport_distribution_*.txt), Turing complet + nombre de manquants vs les 96 du run v13.

Suite (05/08/2026, nuit) — surveillance en direct, goulot PC2 identifié

Architecture scan-puis-affinage découverte en observant l'absence de progression : chaque worker (compute_zeros_v15.py) exécute scan_arb() sur l'intégralité de son segment en un seul appel bloquant, PUIS affine les brackets trouvés (boucle qui produit les lignes [Worker N] zéro #...). Aucune ligne n'apparaît donc tant que le scan n'est pas terminé — confirmé sur la tentative du 02/08 elle-même (0 ligne en 4h+ avant d'être tuée). Ce n'est pas un bug de zeta_run_progress.py (dashboard touche d) : son parse_worker_progress() ne peuple un worker dans l'affichage détail qu'une fois sa première ligne de progression émise — comportement voulu, pas une régression.

PC2 identifié comme goulot d'étranglement probable : après 7h+ de run, PC1 a déjà terminé son Worker 0 (843 000 zéros en ~377 min) et bien avancé le Worker 1 (~111 z/s en affinage), mais PC2 n'a produit aucune ligne de progression, bien que ses 8 process SSH soient actifs (R, ~24 % CPU chacun). Cause à double pénalité : (1) seulement 2 cœurs physiques pour 8 workers (oversubscription ×4, contre 4 cœurs dédiés sur PC1) ; (2) le segment PC2 [3,47M–5M] est la zone à t la plus élevée de tout le run — or le coût de scan par point croît avec t (plus de termes Riemann-Siegel), confirmé empiriquement sur PC1 où les workers terminent leur scan dans l'ordre croissant de t. Note ajoutée dans STACK.md (§Cluster) pour reconsidérer le split PC1/PC2 avant un prochain run à grande échelle.

ETA du 02/08 (~13h, méthode √t) invalidée : calibrée quand MARGE_SECURITE valait encore 3.0 ; le run réel tourne à MARGE=10.0 (STEP ~3,3× plus fin depuis les commits a04ea1f/bbb8a6f du 02/08 soir, donc scan ~3,3× plus coûteux). Aucune estimation fiable de durée totale tant que PC2 n'a pas produit de données réelles.

GPU confirmé non exploitable — mur matériel : logs de lancement, PC1 : GPU NVIDIA GeForce GTX 960M (sm_50) : Compute Capability < 6.0 non supportée par CUDA 12.x NVRTC → mode CPU ; PC2 : CuPy absent, CPU aussi. Calcul 100 % CPU sur les deux machines par construction — cohérent avec l'investigation GPU/CuPy interrompue le 16/05/2026 (cf. mémoire de session), rien de nouveau à optimiser dans l'immédiat.

2026-08-02 (soir) — Cause racine des 96 manquants v13 trouvée, MARGE/κ recalibrés, cluster PC1+PC2 revalidé, run T=5M v15 distribué lancé — commits `a7fb498`·`63de0f2`·`a04ea1f`·`38c2b36`·`bbb8a6f` (Riemann_Lab_C)

Contexte : préparation d'un nouveau run T=5M (v15) pour investiguer les 96 zéros manquants du run v13 du 27-29/06. Incident réseau PC2/PC4 résolu en cours de session (câble Ethernet PC2 débranché ; alias SSH obsolètes renommés zeta-hp/zeta-acer/zeta-del → zeta-calc-second/zeta-backup/zeta-secure, alignés sur le renommage du 16/06).

Cause racine des 96 manquants — enfin identifiée

MARGE_SECURITE avait été abaissée de 3.0 à 2.0 juste avant le run T=5M du 27-29/06 (travail non commité alors, formalisé a posteriori dans a0e6e41), annulant sans le documenter le correctif du 23/06 (7914fa3) déjà posé après que le run T=500000 distribué avait donné 8 manquants avec marge=2.0. Le rescan STEP/2 ajouté en compensation n'a récupéré que +1 zéro sur 96. Commit a7fb498 : MARGE_SECURITE restaurée à 3.0.

Recalibration κ — tentative rejetée, puis mesure non censurée décisive

Tentative de recalibrer κ sur 3 points réels (CSV T=100k/500k/5M) : rejetée (63de0f2) — l'"espacement min" logué est censuré par le pouvoir de résolution du scan lui-même, pas une mesure fiable du vrai écart minimal. Mesure non censurée à la place : rescan ciblé fin (arb_hardy_z, STEP/10) sur 3 zones réelles → MARGE=3.0 confirmée insuffisante à T≈4,86M (2 manquants directement observés). Bisection : MARGE≈12 = seuil de suffisance mesuré. MARGE_SECURITE relevée à 15.0 (a04ea1f), puis reredescendue à 10.0 après tests complémentaires à MARGE=6/8/10 sur les 3 zones (10 = plus basse valeur qui passe partout).

Distribution PC1+PC2 — portage v15 + découverte python-flint sur PC2

zeta_distribute.py (jamais adapté depuis v13) porté vers compute_zeros_v15.py — chemins, conventions de nommage CSV, alias SSH (commit 38c2b36). zeta_sync_pc2.sh exécuté pour la première fois : sync + recompilation de illinois_arb.so/scan_arb.so sur PC2 (obsolètes, sans le code SEUIL_1NEWTON de v15).

Découverte majeure : python-flint 0.8.0 est installé sur PC2 — absent lors de la mesure historique (52 z/s) qui fondait le split 92,3%/7,7% (ratio ×12 supposé). Remesuré à neuf (v15, T=1000) : PC1=822,48 z/s, PC2=512,19 z/s → ratio réel ×1,6, pas ×12. Nouveau split appliqué : PC1 67,4% / PC2 32,6% de N(T).

Validation du pivot — non censurée, à deux niveaux

Run distribué réel T=50000, MARGE=15 : Turing COMPLET (0 manquant) + vérification indépendante (arb_hardy_z, STEP/10) à la frontière : 14/14 zéros identiques.
Idem à MARGE=10, puis re-testé précisément au vrai T_PIVOT du run T=5M cible (T≈3 469 744, fenêtre de 40 unités, PC1 local + PC2 SSH + supplément pivot réels) : 84 zéros fusionnés, 0 manquant vs référence indépendante. 3 écarts apparents identifiés comme des faux négatifs du script de vérification (dérive d'arrondi np.arange sur ~1,1M points), pas des zéros manqués par le pipeline — confirmé en évaluant arb_hardy_z directement aux 3 points (changements de signe nets). Commit bbb8a6f : MARGE_SECURITE = 10.0, validée solo + distribué.

Run T=5M v15 distribué — lancé

Lancé le 02/08/2026 20h29 via zeta_distribute_run.sh 5000000 (turbo, dashboard tmux zeta-progress, nohup). PID 200788. Log logs/distribute_T5000000_nohup_20260802_202916.log. Segmentation : PC1 [14, 3469743.76] (N≈6749158, 67,4%) · PC2 [3469743.76, 5000000] (N≈3267315, 32,6%). ETA empirique ~13h (méthode √t validée sur ce chantier — l'ETA naïve affichée par zeta_distribute.py/le dashboard au lancement, ~2,3h, sous-estime largement : elle ignore la croissance du coût par zéro avec t). Rescan non applicable (non câblé en mode distribué, non requis à MARGE=10 validée).

Limite connue non résolue : validations faites sur zones réduites (quelques dizaines d'unités en t), pas sur la totalité de [14, 5M] — pas de garantie absolue, pas de filet de rattrapage automatique si Turing global révèle un manquant en fin de run.

Prochaine action : vérifier le résultat Turing complet à la fin du run (~13h après 20h29 le 02/08, soit ~09h30 le 03/08).

Suite (04-05/08/2026) : ce run (PID 200788) n'a jamais atteint cette vérification — tué par 3 redémarrages non planifiés causés par une extinction batterie critique mal gérée sur PC1 (UPower CriticalPowerAction=HybridSleep sans resume= configuré). Corrigé (CriticalPowerAction=PowerOff) et run relancé le 04/08 22h48 (PID 32270). Détail complet, découverte du goulot d'étranglement PC2 et état du nouveau run → entrée du 04/08/2026 ci-dessus.

2026-08-02 — fix rag_query.py — embedding forcé sur CPU (incompatibilité torch/Maxwell) — commit `e01bb1d` (Riemann_Lab_C)

Contexte : lors du test RAG génératif du 25/07/2026 (voir plus bas, « Session du 19 juillet 2026 » — le compte-rendu complet du 25/07 vit dans Handoff.md), l'embedding de la requête (sentence-transformers, all-MiniLM-L6-v2) plantait en CUDA avec CUDA error: no kernel image is available for execution on the device. Cause : torch 2.11.0+cu130 a abandonné le support de l'architecture Maxwell (compute capability 5.0) de la GTX 960M. Contournement manuel posé ce jour-là : export CUDA_VISIBLE_DEVICES="" avant chaque appel — fonctionnel mais pas automatisé.

Fix : dans retrieval() (scripts/rag_query.py), l'appel SentenceTransformer(...) force désormais explicitement device="cpu" :

modele = SentenceTransformer(MODELE_EMBEDDING, device="cpu")

mathstral n'est pas concerné (moteur CUDA natif d'ollama/llama.cpp, indépendant de torch) — seul l'embedding de la requête tournait sur torch/CUDA.

Vérification : /mnt/vault_rag monté, python scripts/rag_query.py "Quel est le seuil SEUIL_1NEWTON ?" --no-llm --k 3 → chargement modèle 3.43 s, embedding 0.876 s, recherche HNSW 0.224 s, aucune erreur CUDA, 3 chunks retrouvés normalement.

Diffusion : commit e01bb1d sur Riemann_Lab_C, mergé (commits ort standards, historiques divergents entre branches) et poussé sur les 4 branches : main 92fe8a7, Riemann_Lab_IA 0692938, Riemann_Lab_Test fe4142b. Documenté aussi dans Guide-Ollama-Pratique.md §7-B (résolution de l'incident torch/Maxwell) et Handoff.md (bloc PROMPT_REPRISE).

2026-06-27 — 16h02 — Rescan ciblé v13 + run T=5 000 000 lancé + stratégie optimisation Illinois hybride

Feature : rescan ciblé par déficit dans `compute_zeros_v13.py` (branche `Riemann_Lab_C`)

Contexte : les 5 manquants du run T=500k (run #4) ont été définitivement attribués le 26/06 aux ratés du scan Z_double (phase de grille). L'affinage illinois_refine_arb est parfait (0 REJECT / 0 FALLBACK sur 818 406 appels). Nouvelle approche : rescan STEP/2 après le run principal sur les segments en déficit.

Implémentation :

calculer_zeros_v13() → 4-tuple (zeros, stats, profil, segments) (segments exposé pour rescan)
rescan_segments_deficit(zeros, segments, T_MAX, step) — Section 3b — nouveau
- Identifie les segments worker avec n_trouvés < N(t_hi) - N(t_lo)
- Relance les segments en déficit en parallèle (multiprocessing.Pool) avec STEP/2
- Retourne zeros bruts pour fusion par dedupliquer() dans main()
- Worker IDs 100+i pour distinguer dans les logs
ecrire_log() → paramètre rapport_rescan=None, section [7] RESCAN CIBLÉ dans le log
main() : rescan uniquement en mode local (_cli.t_min is None), pas en mode distribué
MARGE_SECURITE revertée 2.0 (était 3.0 dans le working copy — modifications non commitées)

Validation T=1000 : Turing COMPLET ✅ · LMFDB 20/20 ✅ · rescan parallèle 0.2s · 0 nouveau zéro net (aucun vrai manquant à T=1000, déficits = artefacts N(T))

Non commité → en attente du résultat du run T=5M pour valider.

Run T=5 000 000 lancé à 16h02 (PC1, 8 workers, turbo)

Paramètre	Valeur
T_MAX	5 000 000
N(T) attendus	~10 016 473 zéros
STEP	0.001571 (adaptatif, ×2.8 plus fin qu'à T=500k)
MARGE_SECURITE	2.0
Mode	PC1 local (rescan ciblé actif) — pas distribué
PID principal	46040 · workers 46085-46092
Log	`logs/run_v13_T5M.log`
Dossier résultats	`calculs/v13_T5000000_20260627_160257/`
Durée estimée	~24h (ETA 28/06 ~15h30)

Note sur la durée : l'estimation initiale de 8.6h était fausse — elle ne tenait pas compte du facteur de ralentissement Arb à haute valeur de T. N_RS ≈ √(T/2π) = 892 termes à T=5M vs 282 à T=500k → ×3.16 de ralentissement par zéro. Avec N(5M)/N(500k) = ×12.2 et l'overhead scan ×2.8, durée totale ≈ 24h. À 17h50 (1h48 écoulées) : ~7.6% estimé.

Stratégie d'optimisation identifiée pour les runs longs

Niveau	Optimisation	Gain estimé	Effort	Cible
1a	Distribution PC1+PC2 (`zeta_distribute.py`)	×2	immédiat	T=5M si relancé
1b	TOL_ARB 1e-12 → 1e-9	×1.4	30 min	T=5M
2	Illinois hybride Z_double→Arb dans `illinois_arb.c`	×8	2 jours	v14 — priorité
3	Odlyzko-Schönhage (sous-linéaire)	×50+	semaines	v15+

Principe Illinois hybride (Niveau 2) : dans illinois_refine_arb, utiliser Z_double (rapide, O(N_RS) amortized avec C0+C1) pour les premières itérations jusqu'à |b-a| < 1e-6, puis basculer sur Arb uniquement pour les 2-3 dernières iterations de précision finale. Réduit les appels Arb coûteux de ~25 à ~3 par zéro → ×8 estimé sur le goulot.

Matériel — upgrade RAM PC1 décidé

+16 Go SO-DIMM DDR4 2133 MHz dans le slot libre de l'ASUS ZenBook UX510UWK. (8 Go soudés + 1 slot libre → 24 Go total après upgrade) Motivation : éliminer l'usage du swap sous charge 8 workers (actuellement 16 Go swap nécessaires).

2026-06-26 — 15h58 — Instrumentation debug + 2 bugs corrigés + conclusion zéros manquants — commits 7914fa3, 2b94b9f

Tâches accomplies

1. zeta_sync_pc2.sh validé (PC2 accessible) Fix : ldconfig absent du PATH SSH → PATH=/sbin:/usr/sbin:$PATH ldconfig. Les 3 .so compilent sans erreur sur PC2 (scan_arb.so, illinois_mpfr.so, illinois_arb.so).

2. Instrumentation ZETA_DEBUG_BRACKETS — commit 7914fa3

scan_arb.c : scan_set_debug_log — log chaque bracket BRACKET t_a t_b Z(a) Z(b)
illinois_arb.c : arb_set_debug_log — log REJECT, FALLBACK_ZRS, NEWTON_FINAL
scan_arb_wrapper.py : scan_enable_debug_log / scan_disable_debug_log
compute_zeros_v13.py : activation via ZETA_DEBUG_BRACKETS=<répertoire>, per-worker

3. Bug max_brackets découvert + corrigé — commit 2b94b9f Run debug #1 (MARGE=3.0) : 16 107 manquants. Chaque scan_wN.log = exactement 100 000 lignes. Cause : max_brackets=100 000 figé alors que T=500k demande ~102 302 brackets/worker. Fix : max_brackets = max(150_000, int((N(t_end) - N(t_start)) × 2)) calculé dans le worker.

4. Conclusion définitive sur les zéros manquants — run debug #2 (MARGE=2.0)

818 406 / 818 414 zéros (8 manquants), LMFDB 20/20 ✅
0 REJECT, 0 FALLBACK_ZRS sur 818 406 appels à illinois_refine_arb
Brackets scan : 818 406 lignes (pas de troncature)
CONCLUSION : les manquants sont 100 % des ratés du scan Z_double (phase de grille) illinois_refine_arb est parfaitement fiable. La voie REJECT/FALLBACK est éliminée. 8 manquants ici vs 5 dans run #4 : frontières workers différentes = phase de grille différente.

Prochaine piste (si on veut éliminer les manquants)

Scan adaptatif : détecter les extrema locaux de |Z(t)| proches de zéro pendant le scan, même sans changement de signe détecté. Nécessite de modifier scan_arb.c en profondeur.

2026-06-22 (soir) — Correction rapport clonage (Micron vs Samsung) + WeasyPrint installé — commits `a6a6cda` · `93ad97a` (Riemann_Lab_IA)

Résultat : pdf/clone/rapport_clonage_zeta.md corrigé (le vault RAG concerne le Micron 1100, pas le Samsung 500 Go comme l'avait affirmé à tort un prompt externe) + PDF régénéré.

Action	Résultat
Vérification branches	`pdf/clone/` existe uniquement sur `Riemann_Lab_IA` — pas de `ops/clonage-2026-06`
Correction §2 + nouvelle §11 Phase F	Tableau disque Micron mis à jour, section complète (contexte, paramètres, commandes, piège `vfat`, arborescence) — commit `a6a6cda`
`pip install weasyprint markdown` dans `zeta_env`	✅ — dépendances système (pango/cairo/gdk_pixbuf, Noto Color Emoji) déjà présentes
Bug découvert	CSS `font-family: "DejaVu Sans", "Noto Color Emoji"` sur le `body` → tous les chiffres disparaissent du PDF rendu (Noto Color Emoji avale les glyphes numériques)
Correctif	Retirer la police emoji de la `font-family` du texte courant ; fallback fontconfig automatique suffit pour les emojis
PDF régénéré + vérifié visuellement	72 pages, 5,88 Mo — commit `93ad97a`, script réutilisable `pdf/clone/generate_pdf.py`

Leçon retenue : ne jamais lister une police emoji explicitement dans la font-family du corps de texte avec WeasyPrint — elle peut capturer des caractères non-emoji (chiffres) si le moteur de fallback la priorise mal.

2026-06-22 — Vault RAG Micron 1100 mis en service + convention PDF clarifiée — commit `69a55f7` wiki

Résultat : SSD Micron 1100 256 Go formaté ext4 et monté sur /mnt/vault_rag pour ChromaDB/LlamaIndex (Objectif 2). Confusion identifiée et corrigée dans pdf/clone/rapport_clonage_zeta.md (Riemann_Lab_IA) : ce disque y était documenté comme « exclu, non touché » (Windows/BitLocker) au 21 juin — statut à mettre à jour suite à son reformatage.

Action	Résultat
Partitionnement + formatage `/dev/sdb1`	`mkfs.ext4 -i 8192 -m 1 -L vault_rag`, UUID `9476fad5-8512-4e0d-8cd4-50c9acae01c2`
Montage permanent	`/mnt/vault_rag`, `fstab` `defaults,noatime`, confirmé `rw,noatime`
Arborescence	`chromadb/` · `corpus/` · `llamaindex_cache/` · `agent_logs/`, propriétaire `riemann:riemann`
Piège résolu	`blkid` simple affichait une signature `vfat` périmée (cache) après le formatage ext4 réussi — confirmé propre via `blkid -p` et `wipefs` (sondage direct, sans cache)
`Handoff.md` + `STACK.md`	Section « Stockage — vault RAG (Objectif 2) » ajoutée, commit `69a55f7`

Confusion détectée : un prompt externe a décrit ce disque comme un « Samsung M2 Portable 500 Go USB3 » (réutilisant l'UUID et les commandes réelles du Micron). Vérification du rapport rapport_clonage_zeta.md : le Samsung 500 Go y est un disque distinct, dédié au clone Kali bootable — sans rapport avec le vault RAG. Correction du rapport de clonage (§2 + nouvelle section Phase F) prévue en session suivante sur Riemann_Lab_IA.

Convention clarifiée — emplacement des PDF de cadrage/rapports : vivent dans pdf/<sujet>/ (ex. pdf/clone/) sur la branche Riemann_Lab_IA, jamais dans une branche ops/* séparée ni dans docs/ (réservé au site GitHub Pages). Toujours vérifier git ls-tree -r --name-only origin/<branche> | grep pdf avant de supposer un chemin.

2026-06-17 — 02h14 — MILESTONE : Distribution PC1+PC2 T=100k — commits 98de98e / 1a4f2b3

PC1 [14, 94119] : 129 041 zéros — 8.50 min
PC2 [94119, 100000] : 9 028 zéros — 8.50 min
Fusion : 138 069 zéros uniques, Turing COMPLET ✅, 0 manquant
Marge pivot −15% : PC1+PC2 synchronisés à la seconde près (8.50 min chacun)
python-flint 0.8.0 installé PC2 → ARB_DISPONIBLE=True
zeta_distribute.py opérationnel : pivot N(T), SSH, scp, fusion CSV, Turing global
compute_zeros_v13.py : mode CLI --t-min --t-max --horodatage (non-interactif)
zeta_run.sh mis à jour : v12 → v13
4 branches synchronisées : Riemann_Lab_C · Riemann_Lab_IA · main · Riemann_Lab_Test
Site mis à jour : section Cluster Zeta 4 machines + tableau perf v13 distribué
Prochaine étape : T=500k distribué, puis v14 avec PC3

2026-06-16 — Renommage hostnames architecture officielle

Nouveaux noms (alias SSH `zeta-hp`/`zeta-acer`/`zeta-del` inchangés)

Machine	Ancien hostname	Nouveau hostname	Rôle	Statut
PC2	`zeta-hp3647h`	`zeta-calc-second`	Nœud calcul secondaire	✅ Appliqué
PC3	`zeta-livermore8`	`zeta-backup`	Backup/monitoring	✅ Appliqué
PC4	`zeta-del.local`	`zeta-secure`	Bastion VPN/pare-feu OpenBSD	✅ Appliqué

Vérifié par ssh {alias} hostname — 3/3 confirmés.

Documentation mise à jour

Handoff.md · Architecture-Cluster-Zeta.md · STACK.md · JOURNAL.md : noms mis à jour
docs/images/topo_machines_zeta.svg · docs/images/backup_cluster_map.svg : labels SVG mis à jour
Historique 13/06 (zeta-hp3647h, zeta-livermore8) conservé dans les notes de bas de page

2026-06-13 — zeta_run.sh → compute_zeros_v12.py — commit `33205f2`

scripts/zeta_run.sh mis à jour : lance désormais compute_zeros_v12.py (était v4_1)
v12 = Illinois hybride Z_rs+Newton-Arb — validée T=100k (8.8 min, 0 manquant, Turing COMPLET)
zeta-run 100000 est maintenant le point d'entrée officiel pour v12
4 branches synchronisées : Riemann_Lab_IA · main · Riemann_Lab_Test · Riemann_Lab_C

2026-06-13 — Infrastructure cluster & backup automatique

Pipeline backup nocturne

Étape	Machine	Heure	Commande
1 — rsync local→Acer	`zeta-icor7`	01h50 (cron)	`rsync -aq -e 'ssh -i ~/.ssh/id_acer' logs/ wiki/ pdf/ pjexosql@[IP_PC3]:~/backup/`
2 — rclone Acer→ProtonDrive	`zeta-livermore8`	02h00 (cron)	`/usr/bin/rclone copy ~/backup/ protondrive:hprzeta/Riemann_Lab/backup/`

Clé SSH id_acer (ed25519) sans passphrase — connexion automatique zeta-icor7 → zeta-livermore8
Répertoires sauvegardés : logs/ · wiki/ · pdf/
Destination cloud : ProtonDrive hprzeta/Riemann_Lab/backup/

Renommage hostnames (préfixe `zeta-` uniforme)

Ancien nom	Nouveau nom	Matériel	IP	Réseau
`hp3647h`	`zeta-hp3647h`	HP Compaq 8000 Elite CMT · Core2Duo E8400 3GHz · 4 GB DDR3 · Carte mère HP 3647h	[IP_LAN]	Gigabit ETH
`pcfix2`	`zeta-livermore8`	Compaq-Presario SG3210FR · Pentium E2140 1.6 GHz · 3 GB DDR2 · Carte mère ECS Livermore8	[IP_PC3]	100 Mbit ETH
`zeta-icor7`	`zeta-icor7` (inchangé)	Machine principale de calcul	[IP_PC1]	WiFi

Diagrammes SVG générés

scripts/backup_cluster_map.sh — script qui génère les 2 SVGs suivants :
- backup_cluster_map.svg — pipeline backup (flux rsync + rclone)
- topo_machines_zeta.svg — topologie matérielle du cluster
SVGs déplacés dans docs/images/ (branche Riemann_Lab_IA)

2026-06-13 — Run v12 T=100 000 : COMPLET ✅

Version : v12 illinois_refine_arb (Illinois hybride 2-phases : Z_rs_double Phase 1 + 2 Newton Z_arb Phase 2)
Résultat : ~138 080 zéros · 0 manquant · 8.8 min · ×16.9 vs v10 (benchmark T=10k) · ×2.69 direct T=100k
Turing-Backlund : COMPLET ✅ (aucun zéro manqué dans [0, 99999.70])
LMFDB : 20/20 ✅
Coût moyen : ~4.7 ms/zéro (Phase 1 ~0.015 ms, Phase 2 ~7 ms, overhead scan)
Documentation : analyse_problemes_v9_v10.md + analyse_problemes_v10_v12.md créés dans le wiki
Wiki mis à jour : Home, Etape-1, STACK, Bibliotheques, Formules_zeta, Plancher-Hardware-Architecture
Site : docs/index.html mis à jour — v12 dans le tableau de progression

2026-06-12 (après-midi) — v9 T=100k validée — 28.0 min · ×1.80 vs v8

Résultat : 138 069 zéros · 28.0 min · 82.15 z/s · Turing COMPLET · LMFDB 19/20 · Gain ×1.80 vs v8.

Indicateur	Valeur
Zéros	138 069 / 138 069 · 0 manquant
Durée	28.0 min (1 680.7 s) — sans turbo
Débit	82.15 z/s
Brent_C	99.9% (137 934/138 069) · 37.84 ms/appel
Gain vs v8	×1.80 (conditions identiques — sans turbo)
v9 + turbo (projection)	~17 min · ~135 z/s
PDFs	`analyse_v6_v7.pdf` recompilé · `analyse_v8_v9.pdf` généré

Cohérence benchmark : gain mesuré ×1.80 vs benchmark prédictif ×1.78 — excellent accord.

2026-06-12 (matin) — v9 Brent C/mpfr — benchmark + validation T=10k + run T=100k lancé

Résultat : Brent implémenté, validé T=10k, run T=100k lancé. Gain ×1.78 sur benchmark.

Action	Résultat
`benchmark_methodes.py`	500 zéros [1000,100000] — 128.9 ms/appel Illinois (mesure complète)
`brent_mpfr.c`	Implémentation Brent 2-phases (64→80 bits), compilé dans illinois_mpfr.so
`compute_zeros_v9.py`	ITER_SWITCH=3, MAX_ITER=50, brent_refine_adaptive + fallback illinois
`test_brent.py`	Tous tests PASS — ×1.78 gain confirmé — GO pour T=100k
T=10k v9	10 142 zéros, 16.6 s, 609 z/s, 0 manquant, Turing COMPLET, LMFDB 19/20
T=100k v9	Lancé PID 43732 — 28.0 min (résultat ci-dessus)
`analyse_problemes_v8_v9.md`	Wiki créé — benchmark complet, décision go/no-go

Découverte : benchmark_v8.py sous-estimait le coût Illinois (mesurait t ∈ [1000,3000] → 0.416 ms). Mesure correcte sur [1000,100000] : 128.9 ms/appel (coût croît avec N_full = ⌊√(t/2π)⌋).

2026-06-11 (fin de soirée) — Documentation v7 complète + animation prec_mpfr — commits `0838e2a` `fc7914b`

Résultat : Documentation exhaustive v7 poussée sur toutes les branches. Animation interactive créée.

Action	Résultat
`analyse_problemes_v6_v7.md`	Créé dans wiki — analyse complète LaTeX→MD
`Bonnes-Pratiques-Claude-Code.md`	+2 sections : règle précision mpfr + règle benchmark
`SKILL.md phase-c-illinois`	v0.4.0 — état Phase C 11 juin, v7 leçon, v8 options A/B
`SKILL.md riemann-lab`	Section 9 état courant 11 juin ajoutée
`animation_prec_mpfr.html`	Créé docs/ — dark theme, 3 sliders, KaTeX, barres animées
Sync 4 branches	Riemann_Lab_C `0838e2a` · Riemann_Lab_IA `fc7914b` · main `8c06632`
`handoff/Handoff.md`	Mis à jour — benchmark T=100k, PROCHAINE ACTION v8

2026-06-11 (soir) — v7 illinois_refine_adaptive — commits `49ed8b7` `8637098`

Résultat : v7 implémentée, validée T=5k/T=10k, run T=100 000 terminé en 30.9 min (vs 113 min v6 → ×3.7).

Action	Résultat
Rangement — commit `49ed8b7`	`pdf_to_md_voie_b5.sh` racine → `scripts/`, log run déplacé `logs/`
Benchmark T=5000 v6	illinois_C = 77.5%, 23.50 ms/appel, 136 z/s
`Z_rs_mpfr_ntermes()` ajoutée	Z(t) RS avec N_termes imposé (pas ⌊√(t/2π)⌋)
`illinois_refine_adaptive()`	2 phases : prec_fast=64 bits (iter_switch=8) → prec_full=116 bits
Décision N_full (pas N_fast)	N_fast=N_full/4 invalide les signes Z_rs → N_full conservé, gain vient de 64 bits (1 limb mpfr → SIMD ultra-rapide)
Benchmark v7 T=5000	1808 z/s, 1.47 ms/appel → ×16 vs v6
Validation T=10 000	10 142 zéros, 0 manquant, Turing COMPLET ✅, 408 z/s
Run T=100 000 v7	138 069 zéros · 0 manquant · Turing COMPLET · 30.9 min · 74.49 z/s
Log T=100k	`logs/run_T100k_v7_20260611_1424.log` · dir `calculs/v4_1_T100000_20260611_142434/`
Commit + push	`8637098` sur `Riemann_Lab_C` ✅

Profil phases T=100 000 v7 :

Phase	Temps cumulé	ms/appel	% mur×W
illinois_C	5799.66s	42.05	78.2%
detection	37.80s	9450	0.5%
turing	22.05s	22046	0.3%
mpmath_petit_t	0.78s	5.65	0.0%

Comparaison v6 vs v7 T=100 000 :

Métrique	v6 (170 bits)	v7 (64→116 bits)	Gain
Durée	~113 min	30.9 min	×3.7
Vitesse	~20 z/s	74.49 z/s	×3.6
illinois_C ms/appel	~130 ms	42.05 ms	×3.1

Insight technique : le gain décroît avec t (×16 à T=5k → ×3.7 à T=100k) car la boucle for n=1..N_full est linéaire en $N \approx \sqrt{t/2\pi}$ et domine à grand t.

2026-06-10 — 16h42 — STEP v3 0.05/0.010 + lancement run T=100 000 v3 — commit `181fdd1`

Résultat : STEP adaptatif corrigé (0.05/0.010 au lieu de 0.1/0.05/0.02). Run T=100 000 v3 lancé en nohup. Wiki mis à jour (Formules_zeta §23, STACK, SKILL phase-c-illinois).

Action	Résultat
Analyse run T=100 000 v2	138 039 zéros · 105.1 min · 68 manquants ❌ — STEP=0.02 insuffisant à t≥50k
Gap min mesuré	0.01940 à t=66678 — preuve directe que STEP=0.02 trop grand
Fix STEP v3 — commit `181fdd1`	`step_pour_t()` : 0.05 (t<5k) / 0.010 (t≥5k)
Run T=100 000 v3 lancé	PID 311769 (nohup) · log `calculs/run_T100k_step_adaptatif_20260610_1642.log`
MAJ wiki Formules_zeta.md §23	Tableau STEP v3 + résultats T=100k v1/v2 ajoutés
MAJ wiki STACK.md	Progression v4.1+Arb corrigée (0.05/0.010), run v3 EN COURS
MAJ skill phase-c-illinois	STEP v3 + tableau résultats T=100k

2026-06-10 (après-midi) — nettoyage + MAJ docs wiki + analyse run T=100 000 v2

Résultat : Run T=100 000 v2 terminé (138 039 zéros, 68 manquants Turing). Wiki mis à jour (arbre, Home, archive, Étape-1, bonnes pratiques). Archive compute_zeros_v4_1.py.bak.

Action	Résultat
Run T=100 000 v2 (STEP adaptatif, 10h51)	138 039 zéros · 105.1 min · 21.89 z/s
Turing-Backlund T=100 000 v2	❌ INCOMPLET — 68 manquants (STEP 0.02 insuffisant à t ≥ 50 000)
LMFDB 20 premiers	19/20 ✅ (zéro #20 : 8.06e-10 ⚠️)
Affinage illinois_C	137 909 appels (99.9%) · 85.16 ms/appel
MAJ wiki Arbre_dossiers_projet.md	Refonte complète (structure juin 2026)
MAJ wiki Home.md	Stats run v2, logo header SVG
MAJ wiki Archive-Fichiers-Obsoletes.md	Ajout `compute_zeros_v4_1.py.bak`
MAJ wiki Étape-1	Sections Phase C / v4.1 / v5 + tableau résultats ajoutés
MAJ wiki Bonnes-Pratiques	Section "Gestion des sessions" ajoutée, note finale nettoyée
Archive docs/archive/	`compute_zeros_v4_1.py.bak` déplacé

2026-06-10 — run T=100 000 analysé + fix STEP adaptatif + test T=10 000

Résultat : 137 904 zéros calculés (356 manquants — STEP=0.1 trop grand à grand t). Fix appliqué. GPU nvrtc error corrigé. Test T=10 000 lancé pour validation.

Action	Résultat
Lecture logs `execution_v4_1_T100000_20260610_073115.log`	99.35 min · 23.14 z/s · STEP=0.1 fixe
Analyse Turing-Backlund	356 manquants — tous à T > 29 126 (STEP trop grand)
Fix `compute_zeros_v4_1.py` — `step_pour_t()`	STEP 0.1/0.05/0.02 selon tranche t
Fix `compute_zeros_v4_1.py` — `_partitionner_adaptatif()`	Segmentation 1/√t — charge équilibrée entre workers
Fix `riemann_siegel_batch.py` — GPU nvrtc	Détection CC < 6.0 → forcer CPU numpy (GTX 960M sm_50 déprécié CUDA 12.x)
Création `scripts/zeta_turbo_on.sh` + `off.sh` + `zeta_run.sh`	Scripts absents retrouvés + recréés
Test T=10 000 lancé avec `nohup`	PID 210280 · log `run_T10000_test_20260610_100553.log`

Profil run T=100 000 :

illinois_C : 76.3 % du temps — 137 770 appels à 132 ms/appel (coût O(√t) attendu)
turing : 19 627 ms (1 seul appel — validation globale 137 904 zéros, normal)
LMFDB : 19/20 ✅ (zéro #20 : 8.06e-10 — cas limite stable)

Tests T=10 000 et diagnostic :

Test	STEP	Overlap	Zéros	Manquants	Turing
v1 (10h06)	0.1 fixe pour t<10k	×4 STEP	10 137	6	❌ INCOMPLET
v2 (10h34)	0.05 pour t≥5k	fixe 2.0	10 141	0	✅ COMPLET

Diagnostic v1 : espacement moyen $\delta(10 000) \approx 0.73$, mais espacement min mesuré $= 0.038$ — des paires de zéros proches exigent STEP $< \pi / \ln(t/2\pi)$. Formule de non-manquant : $\text{STEP}(t) < \pi / \ln(t/2\pi)$ (§23 Formules_zeta.md).

Commit v2 : 50837f7 — Riemann_Lab_C (STEP 0.1/0.05/0.02 + overlap=2.0)

2026-06-09 — documentation complète + arb_wrapper ×27 + run T=100 000 (ÉCHEC) — commits `f9e7061` · `8358cdb` · `b563db2` · `89ad1c4` · `7932e15`

Résultat : session documentation + intégration arb_wrapper sur Riemann_Lab_C + Riemann_Lab_IA. Benchmark Arb ×27 validé. Run T=100 000 lancé SANS nohup → process mort, 0 zéros produits.

Action	Commit / Résultat
Wiki `Formules_zeta.md` — §18 Benchmark Arb ×27 (0.77 ms vs 21.13 ms, erreur < 2.2e-16)	`f9e7061` wiki
Wiki `Bibliotheques.md` — §12 mis à jour VALIDÉ ×27 (tableau paramètres + pattern arb_hardy_z)	`f9e7061` wiki
Wiki `STACK.md` — Progression v1→v5 (×1 260, ~1 min vs 21h)	`f9e7061` wiki
Skill `phase-c-illinois/SKILL.md` — section "Mur de latence RÉSOLU (2026-06-09)"	`8358cdb` Riemann_Lab_C
`arb_wrapper.py` intégré `compute_zeros_v4_1.py` — fallbacks mpmath.siegelz → arb_hardy_z (×27)	`b563db2` Riemann_Lab_C
`docs/index.html` — section PROGRESSION V1→V5 (5 cartes + tableau + 3 métriques)	`89ad1c4` Riemann_Lab_IA
`scripts/ia_prompts/ia_prompts_riemann_lab_complet.md` — résultats session + prompt consolidé	`89ad1c4` Riemann_Lab_IA
Merge `Riemann_Lab_IA` → `main`	`7932e15` main
Sync `main` → `Riemann_Lab_C` + `Riemann_Lab_Test`	`ee3518a` C · `3dc998e` Test
Run T=100 000 lancé sans nohup → ÉCHEC : process mort, 0 zéros produits	⚠️ aucun fichier résultat

Animations interactives (7 total) :

animation_theta.html — 6 sections de cours (Stirling, Backlund…) — commit 411111d IA
animation_series_dirichlet.html, animation_produit_eulerien.html, animation_plan_complexe.html, animation_gamma.html, animation_distribution_zeros.html — commit 7363241 IA
animation_zeros_non_triviaux.html — badge HR actif
Header SVG header_riemann_lab.svg déployé README + index

Benchmark Arb (speedup ×27) : affinage_arb.py → 0.77 ms vs 21.13 ms mpmath.findroot — erreur < 2.2e-16 (flottant IEEE). Source : src/benchmark/affinage_arb.py, commit 074aef0.

Leçon : toujours lancer les runs longs avec nohup … &. Sans nohup, SIGHUP tue le process dès déconnexion du terminal.

2026-06-06 — vérifications rendu GitHub (README · wiki · STACK)

Résultat : rendu vérifié sur GitHub via WebFetch + curl HEAD. Toutes les pages sont correctes. Sidebar "Uh oh!" identifiée comme artefact JS WebFetch (inoffensif en navigateur réel).

Vérification	Résultat
PNG local (`docs/images/logo_riemann_lab.png`)	✅ 500×235 px, RGBA, affiché
HTTP HEAD `raw.githubusercontent.com/main/` logo	✅ 200 · `image/png` · 11 Ko
README GitHub main — balise `<img>` PNG ligne 1	✅ correct
Wiki `Home.md` — logo PNG en tête (URL absolue)	✅ affiché
Wiki `STACK.md` — ligne Logo PNG + roadmap + date	✅ cohérent
Sidebar wiki "Uh oh!"	artefact JS WebFetch — inoffensif
`Formules_zeta.md` — 22 sections, 929 lignes	✅ intact

2026-06-06 — logo PNG statique + sync 4 branches + wiki — commits `196af4e` · `f178b03` · `f49fb74` · `71357e0` · `8090d5e`

Résultat : remplacement du logo SVG animé par un PNG statique 500×235 px dans le README et le wiki. SVG bloqué par la CSP GitHub — PNG exporté via cairosvg, vérifié HTTP 200 sur raw.githubusercontent.com. Les 4 branches synchronisées.

Action	Commit / Résultat
Conversion SVG → PNG via cairosvg (`--output-width 500`)	`docs/images/logo_riemann_lab.png` — 11 Ko
README.md : `<img>` SVG → PNG	`196af4e` IA
Merge `Riemann_Lab_IA` → `main`	`f178b03` main
Logo PNG en tête de `Home.md` wiki (URL absolue raw.githubusercontent.com)	`f49fb74` wiki/master
Merge `main` → `Riemann_Lab_C`	`71357e0` C
Merge `main` → `Riemann_Lab_Test`	`8090d5e` Test
Handoff.md mis à jour (2 commits)	`fa77842` · `6ac70d2` wiki/master

Vérifications : rendu PNG affiché localement ✅ · HTTP 200 raw.githubusercontent.com/main/ ✅ · README GitHub main ✅ · wiki Home.md GitHub ✅

2026-06-06 — logo SVG animé + note wiki — commits `320b9e3` · `ce9b874` · `aa0be8b`

Résultat : ajout du logo SVG animé Riemann Lab sur Riemann_Lab_IA, mergé sur main puis synchronisé sur les 4 branches. Note ajoutée dans le wiki (Home.md).

Action	Commit / Résultat
Création `docs/images/logo_riemann_lab.svg` + intégration README	`320b9e3` IA
Merge IA → `main`	`ce9b874`
Merge `main` → `Riemann_Lab_Test`	`2b0a000`
Merge `main` → `Riemann_Lab_C`	`3b89500`
Merge `main` → `Riemann_Lab_IA` (retour sync)	`bbb03f9`
Note logo dans `Home.md` wiki	`aa0be8b` wiki/master

Logo : fond sombre #0d1117, ζ doré (88 px), ligne critique Re(s)=½ cyan animée (drift), 6 zéros pulsants aux valeurs exactes 14.13 · 21.02 · 25.01 · 30.42 · 32.93 · 37.58. Animations CSS actives hors GitHub (sandbox <img>). Taille : 2 444 octets.

2026-06-06 — documentation : README complet + fix lien wiki — commits `3974a87` · `f564bd8` · `bfbd9fc` IA → main → 4 branches

Résultat : session documentation sur Riemann_Lab_IA. Création du README racine, correction du lien wiki dans docs/index.html, puis restauration du README complet depuis le backup mai 2026 avec stats v4.1. Les 4 branches synchronisées sur main.

Action	Commit / Résultat
Création `README.md` minimaliste (6 lignes)	`3974a87` IA
Fix lien wiki `docs/index.html` (ligne 573 : page spécifique → racine wiki)	`f564bd8` IA
Restauration README complet backup mai 2026 + section "État actuel — juin 2026"	`bfbd9fc` IA
Merge IA → `main`	`e586839`
Merge `main` → `Riemann_Lab_C`	`790d641`
Merge `main` → `Riemann_Lab_Test`	`c6f3c5a`

README final : 19 432 octets — SHA 9e5bf81 — identique sur les 4 branches. Section ajoutée : 10 142 zéros validés Turing-Backlund · v4.1 · Illinois_C (170 bits) + Newton · ~41 z/s · GPU CuPy.

2026-06-06 — 18h45 — maintenance : instrumentation v4.1 + gitignore + pdf_to_md_voie_b5 — commits `d6541e5` · `0deda6c` · `b41b448` IA

Résultat : session maintenance sur Riemann_Lab_IA. Vérification que les fichiers d'instrumentation v4.1 (chrono_phases.py, compute_zeros_v4_1.py) sont bien sur origin/Riemann_Lab_C (confirmé : d26ed12 est ancêtre de 191d60a). Nettoyage .gitignore, ajout 8 PDFs de cours et script pdf_to_md_voie_b5.sh, regénération de 13 MD Voie_b_5.

Action	Commit / Résultat
Vérif. instrumentation v4.1 sur `Riemann_Lab_C`	`d26ed12` déjà présent ✅
`.gitignore` : `calculs/` + `test-results/`	`d6541e5` IA
8 PDFs cours + `pdf_to_md_voie_b5.sh`	`0deda6c` IA
13 MD Voie_b_5 regénérés + doublon supprimé	`b41b448` IA — 28 fichiers MD

2026-06-06 — animations interactives + sync 4 branches — commits `411111d` · `7363241` · `11cfad0` · `6bc2fb2` IA→main · `244875a` Test

Résultat : session docs/animations sur Riemann_Lab_IA. Six fichiers HTML créés ou enrichis dans docs/, vérifiés Playwright headless (0 erreur JS, 0 erreur KaTeX, canvas dessinés, sliders réactifs). Toutes les branches synchronisées sur main en fin de session.

Animations créées / enrichies (branche `Riemann_Lab_IA`)

Commit	Fichier	Contenu
`411111d`	`animation_theta.html`	Réécriture complète — 6 sections de cours (def. Γ, Stirling, eq. fonctionnelle ζ=e^{−iθ}Z, détection zéros, formule de Backlund), animation combinée slider t → θ(t) + Z(t) + plan complexe simultanés
`7363241`	`animation_series_dirichlet.html`	Convergence Σ1/nˢ selon Re(s), frontière σ=1, série η alternée (prolongement analytique), sliders σ + N termes
`7363241`	`animation_produit_eulerien.html`	Π(1−p⁻ˢ)⁻¹ premier par premier, preuve infinité des premiers, produit de Hadamard, slider σ + nb de premiers (jusqu'à p₂₅=97), tableau des contributions
`7363241`	`animation_plan_complexe.html`	Heatmap \|ζ(σ+it)\| (grille 80×110, série η, 50 termes), pôle s=1, bande critique, zéros LMFDB, coupes verticale/horizontale, sliders σ + t
`7363241`	`animation_gamma.html`	Γ(x) réel (Lanczos g=7), pôles aux entiers négatifs, formule de réflexion, \|Γ(½+it)\|=√(π/cosh(πt)) exact vs Lanczos, lien ξ(s)
`7363241`	`animation_distribution_zeros.html`	N(T) von Mangoldt vs comptage escalier LMFDB, espacements normalisés, histogramme GUE (Wigner) vs Poisson, table 20 spacings

index.html mis à jour (`11cfad0` IA)

Grille animations : 6 nouveaux pavés links-grid (∑ ∏ ℂ Γ ⊞ θ) sous la hero-card θ
Grille cours : 5 nouvelles cartes ANIMATION (série Dirichlet, produit eulérien, plan complexe, Gamma, distribution des zéros) — total 15 cartes
Chaque animation référencée 2 fois : pavé (haut) + carte cours (bas)

Vérification Playwright (headless Chromium, serveur localhost:8765)

Page	KaTeX	Canvas	JS errors	Slider
`animation_theta`	62 / 0 err	2/2	aucune	✅ θ(t), Z(t), plan ℂ mis à jour
`animation_series_dirichlet`	61 / 0 err	2/2	aucune	✅ σ=3.25, S_N→ζ(σ)
`animation_plan_complexe`	31 / 0 err	3/3	aucune	✅ σ=1.50, \|ζ\|=0.9540
`animation_gamma`	56 / 0 err	3/3	aucune	✅ x=3.65, Γ(3.65)=3.9358
`animation_produit_eulerien`	43 / 0 err	1/1	aucune	✅ σ=4.10, écart=0.000000
`animation_distribution_zeros`	25 / 0 err	2/2	aucune	✅ T=117, N=37 vs 36.83
`animation_zeros_non_triviaux`	37 / 0 err	1/1	aucune	✅ badge HR `✓`→`✗ violée`
`index.html`	48 / 0 err	—	aucune	✅ 9 pavés, 15 cartes, 5 liens ×2

Synchronisation branches

Opération	Branche	Commit
merge IA → main (animations)	`main`	`6bc2fb2`
merge main → Riemann_Lab_Test	`Riemann_Lab_Test`	`244875a`
Handoff.md + JOURNAL.md mis à jour	wiki `master`	`3a6745a`

2026-06-04 — sync final 4 branches sur main — commits `4a891e0` · `191d60a` · `3fecbba` · `61e2e16`

Résultat : toutes les branches alignées sur main en fin de session.

Opération	Branche	Commit
merge Riemann_Lab_C → main	`main`	`4a891e0`
merge main → Riemann_Lab_C	`Riemann_Lab_C`	`191d60a`
merge main → Riemann_Lab_IA	`Riemann_Lab_IA`	`3fecbba`
merge main → Riemann_Lab_Test	`Riemann_Lab_Test`	`61e2e16`

2026-06-04 — documentation + site + skills sync — commits `11cc5b2` wiki · `71a13fc` main

Résultat : session de consolidation post-Option B. Pas de code modifié. Trois axes : enrichissement wiki, publication site GitHub Pages, synchronisation skills 4 branches.

Wiki — enrichissement Formules_zeta.md + Bibliotheques.md (commit `11cc5b2` master)

Fichier	Sections ajoutées
`Formules_zeta.md`	§19 Option B / illinois_refine (fa/fb, interface ctypes, résultats T=1000/T=10000)
`Formules_zeta.md`	§20 Goulot O(√t) — coût illinois_C croissant avec la hauteur (formule + mesures)
`Formules_zeta.md`	§21 Déséquilibre workers — deux causes, profil par worker, impact T=10000
`Bibliotheques.md`	§14 ctypes post-fork — interface Option B, règle arrêt si .so absent, comparatif ms/appel

Site GitHub Pages — section performances (commit `71a13fc` main)

Insertion de ~/Téléchargements/section_performances_index.html dans docs/index.html juste avant <footer> — tableau v2→v4.1 (×138 vs v2), 3 leviers (Illinois C, post-fork, Option B), métriques de validation (Turing COMPLET, LMFDB 19/20, illinois_C 98.6 %). Synchronisé sur les 4 branches :

Branche	Commit
`main`	`71a13fc`
`Riemann_Lab_IA`	`5720afb`
`Riemann_Lab_Test`	`a3b3edb`
`Riemann_Lab_C`	`6dfb282`

Skills — versionnement et sync 4 branches

phase-c-illinois mis à jour v0.2.0 → v0.3.0 (Option B, résultats T=10000, goulot O(√t)). riemann-code-review, riemann-lab, riemann-security-review versionnés depuis ~/.claude/skills/ (source de vérité) — noms canoniques riemann-* alignés. Synchronisés sur les 4 branches depuis Riemann_Lab_C.

Handoff.md — créé (commit `24d0f48` master, mis à jour `cd56081`)

Premier Handoff.md du projet : état Option B validée, goulots résiduels, prochaines actions (T=100 000, rapport v5→v4.1, Arb), rappels techniques non-négociables.

2026-06-03 — 22h56 — Option B : illinois_refine + T=1000 + T=10000 validés — commit `581e34d`

Résultat : Option B implémentée et validée. L'erreur ~0.3 (biais d'initialisation RS) est corrigée. Run T=1000 : 649/649, 16.15 z/s, Turing COMPLET, LMFDB 19/20. Run T=10 000 lancé.

Cause de l'erreur ~0.3 — diagnostic définitif

illinois_mpfr(a, b, tol) recalculait Z(a)/Z(b) en C avec Z_mpfr (RS + C₀+C₁, biais structurel ~1e-3). Si la détection Python (Z_vect_correct) et Z_mpfr donnaient des signes différents sur les bornes, Illinois cherchait un « pseudo-zéro RS » décalé de ~0.3 — sans déclencher le fallback (hors-intervalle).

Solution — Option B

Nouvelle fonction illinois_refine(a, b, fa, fb, prec_bits, tol, max_iter) :

fa = float(Z_vals[i]) et fb = float(Z_vals[i+1]) passés depuis Python (valeurs déjà calculées par Z_vect_correct lors du balayage — zéro recalcul).
Encadrement initial ancré sur les vrais zéros de $\zeta(\tfrac{1}{2}+it)$.
Itérations intermédiaires : Z_mpfr en C (correct pour t ≥ 300, N ≥ 7 termes RS).
Z_double supprimé du .so — détection entièrement côté Python.

Modifications

Fichier	Changement
`illinois_mpfr.c`	`theta_mpfr`/`Z_mpfr` paramétrées (`prec_bits`), `#include z_function.h` retiré, `illinois_refine` ajoutée
`illinois_mpfr.h`	déclaration publique `illinois_refine`
`Makefile`	`z_function.c` retiré de la compilation
`compute_zeros_v4_1.py`	binding ctypes `illinois_refine`, fa/fb depuis `Z_vals`
`test_illinois.py`, `benchmark_illinois.py`, `illinois_pyZ.py`	adaptés Option B

Résultats

Test	Résultat
`test_illinois.py` (10 LMFDB)	10/10 Illinois C pur · erreurs ~1e-13 · aucun fallback
benchmark t ∈ [500, 638]	×30.78 vs mpmath.findroot (objectif ×5–10 dépassé)
Run T=1000	649/649 · 16.15 z/s · Turing COMPLET · LMFDB 19/20 · fallback=0

Profil phases — Run T=1000

Phase	Temps cumulé	Appels	ms/appel
`mpmath_petit_t` (t < 300)	60.1 s	138	435
`illinois_C` (t ≥ 300)	30.1 s	511	58.9
`detection`	0.7 s	4	176

Goulot résiduel : mpmath_petit_t reste dominant en temps cumulé (138 zéros, 37 % du temps). Pour T=10 000, ces 138 zéros représentent ~1.4 % du total → goulot marginalisé.

Run T=10 000 (validation finale Option B)

Critère	Valeur	Statut
Zéros trouvés	10 141 (attendus 10 143)	✅
Durée	9.1 min (543.7 s)	—
Vitesse	18.65 z/s	✅
Turing	COMPLET — 0 manquant, surplus 5 (chevauchement)	✅
LMFDB 19/20	19/20 (zéro #20 = 8.06e-10, stable)	✅
illinois_C	98.6 % (10 004 zéros)	✅ objectif 90 % dépassé
mpmath_petit_t	1.4 % (138 zéros, t < 300, constant)	✅
mpmath_fallback	0	✅

Profil phases (cumulé 4 workers) :

Phase	Temps cumulé	Appels	ms/appel
`illinois_C`	1592.5 s	10 004	159 ms
`mpmath_petit_t`	79.5 s	138	576 ms
`turing`	35.0 s	1	—
`detection`	2.8 s	20	138 ms

Nouveau goulot identifié : illinois_C à grands t — 159 ms/appel pour t~~7500–10000 vs 58.9 ms à t~~500. Cause : $N_{\text{RS}} = \lfloor\sqrt{t/2\pi}\rfloor$ croît avec $t$, Z_mpfr calcule plus de termes. Worker 3 [7503–10000] = plus lent (543 s). Pour T=100 000 ($N_{\text{RS}} \approx 40$ termes), il faudra estimer l'impact.

Fichiers produits

calculs/v4_1_T1000_20260603_225629/ — CSV + log + PNG (649 zéros)
calculs/v4_1_T10000_20260603_225948/ — CSV + log + PNG (10 141 zéros)

Clôture session

Run T=100 000 non lancé (session fermée). Prochain démarrage : reprendre depuis Handoff.md.

2026-06-03 — 01h00→02h00 — Diagnostic pipeline v4.1 + 82 z/s validé

Objectif de la session

Analyser pourquoi le « 41 z/s (×39) » du benchmark unitaire ne se transmettait pas au pipeline réel (T=1000 → 1.07 z/s). Instrumenter, mesurer, corriger.

Résultats mesurés

Étape	Vitesse	Note
v3 T=10000 (référence)	1.02 z/s	pipeline séquentiel
v4.1 runs initiaux T=1000	1.07 z/s	×39 unitaire NON transmis
v4.1 + Z_vect_correct + bracket	82–84 z/s	✅ ×80 vs v3
v4.1 + workprec(50)	82 z/s	neutre (voir ci-dessous)

Instrumentation — `chrono_phases.py` (nouveau fichier)

Profileur 4+1 phases (detection / illinois_C / mpmath_petit_t / mpmath_fallback / turing). Ajouté à compute_zeros_v4_1.py via 6 insertions chirurgicales (zéro logique de calcul modifiée). Compile OK.

Profil mesuré (T=1000, version finale)

phase            temps_cumul   appels   ms/appel   % mur×W
mpmath_petit_t      11.27s      138      81.65     35.6%
illinois_C           5.22s      511      10.21     16.5%
turing               2.33s        1    2330.99      7.4%
detection            0.09s        4      21.53      0.3%

→ Illinois_C réel = 10 ms/appel (pas 24 ms supposés). Détection = négligeable. → Goulot résiduel = mpmath_petit_t (138 zéros t<300, siegelz dps=35 interne).

Correctifs validés (Claude Code + hprzeta)

Z_batch → Z_vect_correct : N(t) propre à chaque point (bug N_max fixe corrigé).
findroot(siegelz, t_mid) → findroot(siegelz, (a,b), solver="illinois") : bracket robuste, ne peut plus diverger.
workprec(50) sur mpmath_petit_t : gain marginal (~12 %) car siegelz interne force sa propre précision — le contexte workprec ne la contrôle pas.

Leçon clé — piège workprec mpmath

with _mp.workprec(50): _mp.findroot(_mp.siegelz, ...) ne passe PAS dps=15 à siegelz. siegelz re-lit mp.dps global (35). Seule façon de forcer float64 : _mp.fp.siegelz. → Prochain levier : remplacer siegelz par fp.siegelz sur t<300 → ~2 ms/appel vs 82 ms.

Hypothèse réfutée

Pas de « finition Newton dps=25 » dans compute_zeros_v4_1.py — hypothèse abandonnée après lecture du code. Bonne pratique : lire le code avant de supposer le goulot.

Git — nouvelle règle branche `session`

Handoff.md versionné sur branche orpheline session (aucun ancêtre commun). Motif **/Handoff.md dans .gitignore de toutes les branches de code. Vérifié : git ls-files | grep -ci handoff → 0 sur code, 1 sur session.

Comportement Claude Code à retenir

Modifie les fichiers sans demander si aucune règle explicite ne l'en empêche.
Timeout agent = 5 min → runs longs : printf "T\nO\n" | python script.py | tee log.
Lit le Handoff du wiki (pas la branche session) → contexte potentiellement périmé.
Rapport de vitesse sans run réel = fabrication (62.91 z/s annoncé mais timeout).

Commits de la session

Riemann_Lab_C : compute_zeros_v4_1.py instrumenté + chrono_phases.py + patch_workprec.py → 82 z/s validé, Turing COMPLET, LMFDB 19/20.
session : Handoff.md mis à jour (branche orpheline).
4 branches de code : **/Handoff.md hors suivi Git.

Prochaine action

Remplacer _mp.siegelz par _mp.fp.siegelz (float64 natif) sur le segment t<300 → 81 ms → ~2 ms/appel → pipeline estimé ~200+ z/s → run T=10000 en ~1 min.

2026-06-02 — 17h00 — Vérif A (T=300) + run T=1000 validés — commit `893f3b4`

Résultat : v4.1 validée sur deux runs successifs. Turing COMPLET sur les deux, LMFDB 19/20, 0 fallback, 0 échec. Vitesse : 1.1–1.9 z/s (goulot _newton_polish). Session arrêtée après T=1000 ; T=10 000 reporté.

Vérif A — T=300 (justesse)

138/138 zéros · Turing COMPLET (0 manquant) · LMFDB 19/20 (zéro #20 = 8.06e-10, cas limite stable)
illinois_C_polish : 0% — attendu : tous les zéros de $[14, 300[$ sont sous le seuil T_SEUIL_ILLINOIS_C
mpmath_fallback : 0 ✅ · durée : 73 s · vitesse : 1.9 z/s

Run T=1000 (confirmation)

Critère	Valeur	Statut
Zéros trouvés	649 (attendus N(T) ≈ 647)	✅
Turing	COMPLET — 0 zéro manquant	✅
LMFDB 19/20	19/20 (zéro #20 stable : 8.06e-10)	✅
illinois_C_polish	511 / 78.7%	⚠️ structurel
mpmath_petit_t	138 (t < 300, légitime)	✅
mpmath_fallback	0	✅
Vitesse	1.1 z/s	⚠️
Durée	10 min 3 s	—

illinois_C_polish à 78.7% — structurel, non un bug

Les 138 zéros $[14, 300[$ passeront toujours par mpmath_petit_t (seuil T_SEUIL_ILLINOIS_C=300). Pour T=10 000 : 138/10 142 ≈ 1.4% → 98.6% illinois_C_polish ✅ (seuil cible 90%).

Goulot vitesse identifié

_newton_polish : 3–5 appels mpmath.siegelz(dps=25) par zéro (~5–15 ms/appel). Worker 0 (plage $[14, 261]$) concentre tous les mpmath_petit_t → déséquilibre de charge. Même cause racine que session après-midi : goulot = siegelz, pas l'algorithme.

Fichiers produits

calculs/v4_1_T300_20260602_162919/ — CSV + log + PNG (138 zéros)
calculs/v4_1_T1000_20260602_163940/ — CSV + log + PNG (649 zéros)

2026-06-02 — après-midi — v4.2 finition hybride : précision parfaite, mais goulot = `siegelz` — commit `0fa22c2`

Résultat : la finition hybride (Illinois_C pré-affine + raffinage mpmath) atteint la précision parfaite ($\text{Écart}_P = 0.00$ vs LMFDB) à toutes les hauteurs. Mais aucune optimisation algorithmique du raffinage n'est possible : le goulot est mpmath.siegelz lui-même (~296 ms/appel à $t\approx 9000$), pas le solveur. Newton est réfuté (plus lent qu'Illinois). Décision de livrable en attente (vérifier HR vs cataloguer les positions).

Vérif A — comptage (✅ COMPLET)

138/138 zéros · Turing COMPLET · LMFDB 19/20 < 1e-10 (zéro #20 = cas limite 8.06e-10).
Illinois_C 0 % à T=300 : normal (tous les zéros à $t<300 = $ seuil → 100 % fallback mpmath).

Vérif B — précision des positions (3 itérations)

Itération	Méthode finale	Précision (Écart_P)	Vitesse ×4	Verdict
B v1	Illinois_C pur (racine de $Z_{\text{mpfr}}$)	1e-4 à 1e-2 ❌	41 z/s	rejeté (positions)
B v2	Illinois + polish `findroot` dps=30	0.00 ✅	0.5 z/s	juste mais lent
B v3	Newton analytique dps=25, 5 pas	0.00 ✅	0.4 z/s	plus lent qu'Illinois

Cause racine confirmée (leçon décisive)

Illinois_C pur trouve les zéros de la RS tronquée $C_0+C_1$ → biais de position $|\gamma_{\text{mpfr}}-\gamma| \approx |R(\gamma)|/|Z'(\gamma)|$, soit 1e-4 (croisement raide) à 1e-2 (croisement plat). Structurel, pas un bug (série asymptotique).
Newton ne gagne pas : siegelz(t, derivative=1) ne rend pas $Z'$ gratuitement — $\zeta'(s) = -\sum \ln(n)/n^s$ a des poids log ⇒ série plus lente ⇒ $Z'$ plus cher que $Z$. Newton (2 appels/pas, dont $Z'$) ≈ Illinois (1 appel/pas, 27 itér) en coût total.
Goulot = vitesse intrinsèque de mpmath.siegelz à grand $t$, pas le nombre d'itérations. → aucune optimisation algorithmique du raffinage tant qu'on passe par siegelz.

Distinction comptage / position (clé pour trancher)

Vérifier HR jusqu'à T = comptage Turing ($n_{\text{calc}} = N(T)$ ). Indépendant de la précision des positions → Illinois_C pur (41 z/s, ~5 min pour T=10000) suffit.
Catalogue de positions < 1e-10 = exige le polish lent (~7 h pour T=10000)… mais ce catalogue existe déjà (run v2/v3 : CSV 10 142 zéros, 50 dps).

Estimation de temps (×4 workers, mesurée/extrapolée)

Run	Zéros	Temps ×4	Note
T=300	138	~60 s (mesuré)	tout fallback mpmath
T=1000	~396	~16 min	validation complète faisable
T=10000	~10 142	~7 h	run de nuit si catalogue voulu

Git

0fa22c2 (Riemann_Lab_C) — feat(v4.1) : finition Newton analytique dps=25 après Illinois_C (2 files, +575 / −42). Poussé : 71e6774..0fa22c2.

Documentation

Formules_zeta.md enrichi (→ ~826 lignes) : §5.6 (erreur de position, perturbation 1ᵉʳ ordre), §6.4 (3 architectures d'affinage), §6.5 (finition Newton : ordre 2, dérivée analytique, dps vs LMFDB absolu), §6.5.5 (mesure : Newton réfuté, goulot siegelz), §11.1–11.2 (comptage vs position + condition de validité détection).

Prochaine action (DÉCISION DE LIVRABLE, pas technique)

Si objectif = vérifier HR jusqu'à T=10000 → lancer Illinois_C pur (~5 min), Turing COMPLET.
Si objectif = catalogue positions < 1e-10 → soit réutiliser le CSV v2/v3 existant, soit run de nuit polish T=10000 (~7 h).
Ne pas chercher d'autre solveur : le goulot est siegelz, pas l'algorithme.
(À valider avant tout abaissement de dps : tester sur $t\approx 9900$, jamais sur T=1000 — critère LMFDB absolu, cf. §6.5.3.)

2026-06-01 — nettoyage skill zeta-lab (4 branches) + sécurisation .mcp.json

Résultat : ancien skill zeta-lab (cassé) retiré de Git sur les 4 branches ; faille .mcp.json non ignoré découverte et corrigée sur main et Riemann_Lab_Test.

Skills

Audit git ls-tree : zeta-lab était commité sur les 4 branches.
Retiré via git rm -r + commit + push sur chacune : C (2a4cde4, + ancien prompt v4.1 retiré / prompt findroot ajouté) · IA (e68ebca) · main (5c08cf0) · Test (c3396b7).
Les BONS skills (riemann-lab, phase-c-illinois, riemann-code-review, riemann-security-review) sont toujours dans ~/.claude/skills/, pas encore versionnés → Phase 2 du plan.

Sécurité — .mcp.json

Découvert : le .gitignore divergeait entre branches ; .mcp.json n'était PAS ignoré sur main ni Riemann_Lab_Test.
git ls-files | grep mcp = VIDE partout → le token n'a JAMAIS été commité. Pas de révocation nécessaire (contrairement à l'incident du 31 mai).
Corrigé : echo ".mcp.json" >> .gitignore sur main et Test → PROTÉGÉ ✅.

Leçon durable

Le .gitignore n'est pas synchronisé entre branches. Après toute manip multi-branches : vérifier git check-ignore .mcp.json sur CHAQUE branche.

2026-05-31 — après-midi — fix findroot appliqué (NON validé) — commit `7f5bd02`

Affinage : callback ctypes illinois_c_exact → mpmath.findroot(solver="illinois")
dps=35 global, DPS_AFFINAGE=15 local · plus de dépendance au .so
Objectif : vrai parallélisme ×4. ⚠️ PAS ENCORE validé (aucun run effectué).
Reprise : lancer Vérif A (T=300) du prompt prompt_v4_1_findroot_20260531.md.

2026-05-31 — 02h00 — v4.1 validée (justesse) — commit `368d090` (`Riemann_Lab_C`)

Résultat : v4.1 juste mais lente (1.1 z/s). Le goulot a migré de la détection vers l'affinage.

Point d'arrêt N°1 — validation détection `Z_vect_correct`

Comparaison Z_vect_correct(t) (vectorisée) vs mpmath.siegelz(t) (référence) sur 4 plages. Critère : mêmes changements de signe (CS) ⇒ aucun zéro raté.

Plage	Écart max	Écart moyen	CS vect	CS mpm	Gain
t ∈ [14, 100]	1.38e-02	4.18e-03	29	29	×73
t ∈ [300, 400]	1.50e-03	8.49e-04	64	64	×4379
t ∈ [3000, 3100]	2.81e-04	1.46e-04	98	98	×9854
t ∈ [9900, 10000]	1.19e-04	1.07e-04	117	117	×19568

L'écart numérique max décroît avec t (1.4e-2 → 1.2e-4) : c'est l'erreur résiduelle théorique de RS tronquée à C0+C1, en $O(t^{-3/2})$. Ce n'est pas un bug. Pour la détection seul le signe compte ⇒ 0 désaccord = détection fiable.

Bug corrigé au point d'arrêt N°1

Première version Z_batch : 359 désaccords (zéros ratés). Cause : N_max FIXE $= \lfloor\sqrt{t_{\max}/2\pi}\rfloor + 1$ pour TOUS les points du batch. Or RS exige $N(t) = \lfloor\sqrt{t/2\pi}\rfloor$ propre à chaque $t$ ; les termes $n > N(t)$ faussent le signe. Correction Z_vect_correct : masque booléen mask[k,n] = (n ≤ N(t_k)) par ligne ⇒ chaque ligne n'accumule que ses $N(t_k)$ termes exacts.

Point d'arrêt N°2 — run T=300

Critère	v5 (réf.)	v4.1	OK ?
Zéros trouvés	138	138	✅
Turing COMPLET	✅	✅	✅
LMFDB 19/20 < 1e-10	✅	✅	✅
Illinois_C pur	~100 %	100 %	✅
Vitesse	~1 z/s	1.1 z/s	⚠️

Diagnostic vitesse — cause racine = affinage Illinois

Décomposition du temps pour T=300 : $$\underbrace{138}{\text{zéros}} \times \underbrace{102}{\text{appels Illinois}} \times \underbrace{1.5\ \text{ms}}_{\text{siegelz @ dps=35}} \approx 21\ \text{s séquentiel} \times \frac{1}{1.84} \approx 122\ \text{s}$$

Callback ctypes illinois_c_exact appelle mpmath.siegelz à dps=35 → 1.5–10 ms/appel.
Sérialisation partielle du callback ⇒ gain parallèle ×1.84 au lieu de ×4 (test : Pool(sleep)=×3.9 OK, Pool(worker_chunk)=×1.84).

Fix proposé (à appliquer prochaine session — pas encore fait)

Remplacer le callback ctypes par mpmath.findroot(siegelz, solver="illinois") à dps=15 dans les workers ⇒ vrai parallélisme ×4 ; dps=15 suffit pour tol=1e-12. Estimation T=10000 → ~6 z/s. Contrepartie : méthode mpmath au lieu de Illinois_C.

Fichiers ajoutés (commit `368d090`)

src/calculs/optimisation/compute_zeros_v4_1.py
src/calculs/optimisation/test_v4_1_T300.py
src/calculs/optimisation/test_zbatch_validation.py
src/ia/prompts/prompt_claude_code_phase_prompt_v4.1.md

🔐 Incident sécurité résolu

Un ancien GitHub PAT était commité en clair dans .mcp.json:7 (commit b2f579a). GitHub Push Protection (GH013) bloquait le push.

Leçon clé : .gitignore empêche les futurs commits mais ne purge pas le passé — un secret dans l'historique reste détectable tant que le commit existe.

Résolution (dans l'ordre) :

Révocation de l'ancien token sur GitHub (geste n°1, le plus urgent).
git filter-repo --path .mcp.json --invert-paths → effacé de 220 commits.
Vérification : git log --all --oneline -- .mcp.json = VIDE.
git push --force → blocage levé (afcaab3).
main vérifié : intact.
Nouveau token régénéré, remis dans .mcp.json local (ignoré par .gitignore).

Ne jamais suivre le lien « unblock-secret » de GitHub. Un secret exposé = secret mort.

2026-05-29 — 21h30 — Voie B validée — commit `b8018c0` (`Riemann_Lab_C`)

Résultat : compute_zeros_v5.py valide Illinois_C pur 100 %, biais Z_mpfr < 1e-13.

Fichiers créés / modifiés

Fichier	Rôle
`compute_zeros_v5.py`	Script principal v5 — wrapper `mpmath.siegelz`
`illinois_mpfr.c` / `.h`	Callback Python/C `illinois_mpfr_cb`
`illinois_mpfr.so`	Recompilé
`illinois_pyZ.py`	Wrapper Python pour `Z_mpfr` via mpmath
`test_illinois_v5.py`	Validation Voie B (20/20)
`docs/phase_c_voie_b_v5_plan.md`	Livrable Phase C Voie B

Validation

Run T=80 (21 zéros) :
  Illinois_C pur    : 100 %  ✅  (v4 était à 0 %)
  Turing-Backlund   : COMPLET ✅
  LMFDB             : 19/20 ✅  (zéro #20 = cas limite 8.06e-10)
  Durée             : 25.8 s
test_illinois_v5.py : 20/20 ✅ · biais Z_mpfr < 1e-13 (avant ~9e-3)

Note LMFDB 19/20 : le zéro #20 (γ₂₀ ≈ 77.1448) est un cas limite, $|Z(\gamma_{20})| = 8.6\text{e-}15$ — vrai zéro confirmé. L'écart vient de la précision de la valeur de référence (15 décimales) ou de la limite de siegelz à 35 dps. Pas un échec de méthode.

Diagnostic du biais RS (avec Copilot / GPT-4.5 + Claude)

Décomposition sur t ∈ [300, 650] :

theta  : max 2.3e-13  ✅ theta_double parfait
sum    : max 3.26e-01 ✅ normal sans correction C0+C1
fullRS : max 1.5e-03  ⚠️ biais résiduel structurel

Conclusion : le biais n'est pas un bug mais une limite mathématique — RS tronquée à C0+C1 plafonne à ~1e-3.

Méthode	Précision
RS sans correction	~1e-1
RS + C0	~1e-2
RS + C0 + C1	~1e-3 (état alors)
RS + 3–5 termes	~1e-8
`mpmath.siegelz`	~1e-12

Patches tentés et annulés : Patch 1 (π manquant dans dPsi) → biais 4e-2 ❌ ; Patch 2 (C1 analytique) → biais 2e-2 ❌ ; git checkout z_function.c → retour origine ✅.

Solution retenue : wrapper Python/C appelant mpmath.siegelz(t) depuis le .so (mpc_zeta absent de libmpc 1.3.1).

Phase C — état validé à cette date

c_modules compile : make clean && make → illinois_mpfr.so OK.
benchmark_illinois.py : gain isolé C/libmpfr ×48.73 sur t≈500–638.
5 erreurs architecturales de v4 identifiées (détection via mpmath.siegelz, parallélisme abandonné, Z_double en détection, fallback global, .so absent silencieux) → à corriger dans v4.1.
Seuil justifié : $N=\lfloor\sqrt{t/2\pi}\rfloor \Rightarrow t<300 \Rightarrow N<7$ (imprécis), $t\geq 300 \Rightarrow N\geq 7$ (fiable). D'où T_SEUIL = 300.0.
9 PDF de cadrage produits (session GPT-4.5 / Copilot) — voir STACK.md.

2026-05-23 — Correction hiérarchie CLAUDE.md

Le CLAUDE.md projet (208 lignes, Riemann) avait été copié par erreur dans ~/.claude/CLAUDE.md (global), écrasant les instructions générales. Deux fichiers distincts recréés :

Fichier	Contenu	Lignes
`~/.claude/CLAUDE.md`	Langue FR, style, règles légères	26
`~/projet_zeta/CLAUDE.md`	Contexte Riemann complet	208
`src/calculs/optimisation/CLAUDE.md`	Phase C — Illinois, ctypes	108
`.../c_modules/CLAUDE.md`	Règles C — libmpfr, PREC=170	97

2026-05-16 — Benchmark séquentiel équitable (post-reboot NVIDIA)

Tests équitables : un seul mode à la fois après reboot.

Mode	Zéros / 15 min	Vitesse	t atteint	Gain vs CPU
CPU scalaire (réf.)	~604	~0.67 z/s	944	—
BATCH_CPU	3 231	3.59 z/s	4 164	×5.3
BATCH_GPU	3 051	3.39 z/s	4 596	×5.1

Clé : BATCH_CPU ≈ BATCH_GPU — la GTX 960M n'apporte pas de gain. L'affinage Illinois (mpmath, CPU pur) = 80–90 % du temps total ; la GPU n'accélère que la détection Z(t) (10–20 %). GPU GTX 960M opérationnel depuis le 16 mai (prime-select nvidia + reboot, CuPy cupy-cuda12x).

~2026-04-24 — Objectif 1 atteint — 10 142 zéros

compute_zeros_v2.py : 10 142 zéros calculés (jusqu'à T ≈ 9998.85) en ~21 h, validés contre LMFDB. Fichier : zeros_zeta_T10000_20260424_205325.csv. Base de référence vitesse : CPU scalaire 1.4 z/s solo.

Mise à jour : 31 mai 2026 — 02h00 · JOURNAL.md (1 fichier MD modifié) · ~205 lignes · append-only

2026-06-12 — Session v9 turbo + fix sudoers

v9 validée sans turbo : 138 069 zéros, 28.0 min, 82.15 z/s, ×1.80 vs v8
MAJ index.html chiffres v9 : commit be893d1 ✅
Fix sudoers zeta_turbo : /etc/sudoers.d/zeta_turbo installé ✅
Run v9 avec turbo : 26.6 min · 86.5 z/s · 138 069 zéros · Turing COMPLET ✅
Gain turbo v9 : ×1.05 (bottleneck MPFR/mémoire, pas CPU — projection 17 min invalidée)
Gain cumulé v1→v9 avec turbo : ×4 500
analyse_problemes_v8_v9.md → wiki ✅

2026-06-12 fin de soirée — v10 W=8 forcé

compute_zeros_v10.py créé depuis v9 — seul changement : N_WORKERS = 8 (forcé)
T=10k v10 validé : 10 142 zéros · 16.2s · 624 z/s · 0 manquant ✅
Run T=100k v10 + turbo : 138 069 zéros · 23.7 min · 97.08 z/s · Turing COMPLET · LMFDB 19/20 ✅
Gain v10 vs v9 : ×1.12 (meilleur que benchmark v8 ×0.99 — Brent grand t dilue overhead HT)
Gain cumulé v1→v10 avec turbo : ×5 040 (21h → 23.7 min)
Explication W=8 > W=4 : chaque appel Brent à grand t coûte ~64 ms → context-switch HT négligeable
commit c9fad76 sur Riemann_Lab_C
docs/index.html, STACK.md, JOURNAL.md mis à jour → v10 comme version courante
Prochaine : v11 — cache (fa,fb) scan→Brent (×1.1–1.3 estimé)

Session 2026-06-13 — Infrastructure cluster & backup automatique

Actions réalisées

Pipeline backup automatique

Cron zeta-livermore8 (02h00) : rclone copy ~/backup/ → protondrive:hprzeta/Riemann_Lab/backup/
Cron zeta-icor7 (01h50) : rsync -aq -e 'ssh -i ~/.ssh/id_acer' → logs + wiki + pdf vers Acer
Cle SSH id_acer (ed25519) sans mot de passe : icor7 → Acer operationnelle
Test : OK backup logs — pipeline 100% automatique

Renommage hostnames

hp3647h → zeta-hp3647h (carte mere HP 3647h · HP Compaq 8000 Elite CMT)
pcfix2 → zeta-livermore8 (carte mere ECS Livermore8 · Compaq-Presario SG3210FR)
/etc/hosts mis a jour HP et Acer

IPs reseau local

zeta-icor7 : [IP_PC1] (wifi wlp2s0)
zeta-hp3647h : [IP_LAN] (ethernet Gigabit Intel)
zeta-livermore8 : [IP_PC3] (ethernet 100Mbit Realtek)

Documentation produite

Architecture-Cluster-Zeta.md mis a jour (commit 69d30c6)
backup_cluster_map.sh dans scripts/ → genere 2 SVGs fond blanc
backup_cluster_map.svg + topo_machines_zeta.svg dans docs/

Notes

crontab -e casse sur Acer (Python 3.5) → workaround (echo ...) | crontab -
/etc/hosts AVANT hostnamectl sinon erreur resolution hostname
Wiki vit sur icor7 uniquement, pas sur HP ni Acer

2026-06-14 — Arbitrage architecture cluster : 5 → 4 nœuds

Décision (session Claude.ai web) :

Architecture révisée : 4 nœuds (PC4 = bastion uniquement, hors périmètre calcul).
PC4 (zeta-secure, OpenBSD 7.9/i386, [IP_PC4]) : rôle VPN/pare-feu uniquement, pas de worker Python (OpenBSD/i386 non viable pour calcul mpmath).
Rôle zeta-log-dns-moni réaffecté à PC3 (zeta-livermore8, alias zeta-acer, Linux Lite 3.8/i686, [IP_PC3]) : chrony (NTP LAN), rsyslog (logs centralisés UDP 514), dnsmasq (résolution .lan), glances ou fallback script vmstat/free si Python 3.5 incompatible.
3 SVG harmonisés produits sur Claude.ai (déposés dans ~/Téléchargements/) :
- topo_machines_zeta.svg — canevas étendu 720 → 780 px, encart PC4 ajouté, date 15/06
- backup_cluster_map.svg — checklist étendue, encart PC4, date 15/06
- workflow_post_version_riemann_lab.svg — mise à jour date

Motivation :

Séparation nette : réseau/sécurité (PC4) vs supervision légère (PC3 qui fait déjà backup).
PC3 à 5,7 Go RAM libre → largement suffisant pour chrony + rsyslog + dnsmasq.

2026-06-15 — Accès distant fonctionnel : zeta-secure (PC4) opérationnel via IPv6

Contexte : finalisation de la configuration WireGuard de PC4 (zeta-secure, OpenBSD 7.9/i386, bastion VPN/pare-feu) comme point d'entrée VPN du cluster depuis l'extérieur (4G/téléphone).

Travaux réalisés :

Tunnel local PC1 ↔ PC4 (wg0) validé précédemment — handshake OK, [WG_PC1] (PC1) ↔ [WG_PC4] (PC4).
Diagnostic CGNAT IPv4 : l'IP WAN de la box ([IP_WAN_BOX]) est en plage RFC1918 — la box SFR est elle-même derrière du CGNAT côté IPv4. La règle de port forwarding UDP/51820 → [IP_PC4] était correctement configurée mais structurellement inopérante (pas d'IPv4 publique dédiée). → Bascule de stratégie vers IPv6.
IPv6 globale sur PC4 :
- La box délègue un préfixe /56 ([IPV6]/56) avec SLAAC actif sur le LAN ([IPV6]/64).
- PC4 (re0) ne recevait aucune adresse IPv6, même locale-lien : il manquait inet6 autoconf dans /etc/hostname.re0.
- Après ajout de inet6 autoconf + netstart re0 : adresse locale-lien obtenue (fe80::240:f4ff:fecc:36a0), mais toujours pas d'adresse globale → RA (Router Advertisement, ICMPv6 type 134) bloquées par pf (block in par défaut, aucune règle ICMPv6).
- Fix pf : ajout de pass in on $ext_if inet6 proto icmp6 icmp6-type {routeradv, neighbradv, neighbrsol, redir} (note : le type correct est neighbrsol, pas neighbrsolicit).
- Après ifconfig re0 down/up : adresse globale SLAAC obtenue — [IPV6] (stable, pltime/vltime≈745s, se renouvelle périodiquement) + une adresse temporary (à ignorer pour un usage serveur).
DuckDNS AAAA :
- Ajout de l'enregistrement AAAA sur [DDNS_PC4] → [IPV6].
- /etc/duckdns/duck.sh réécrit pour pousser A et AAAA à chaque exécution cron (*/5 * * * *), en extrayant l'adresse IPv6 globale non-temporary via :

     IP6=$(ifconfig re0 | awk '/inet6/ && !/fe80/ && !/temporary/ {print $2; exit}')

Test manuel : OK reçu, host -t AAAA [DDNS_PC4] confirme.

Pare-feu IPv6 de la box SFR (GR140IG) — cause racine du blocage final :
- Découverte d'une section "Réseau v6" dans Sécurité → Accès, distincte du NAT/redirection de ports IPv4. Vide par défaut = tout trafic entrant IPv6 non sollicité bloqué, indépendamment du pf de PC4.
- Création d'une règle : WireGuard-IPv6 / UDP / [IPV6] ad39:37b9:a638:126c / ports 51820-51820 / source: toute / activée.
Test bout-en-bout réussi (téléphone Android, 4G, WiFi off) :
- Tunnel zeta-vpn (clé pub [CLE_PUB_TEL], [WG_TEL]/24) → Endpoint [DDNS_PC4]:51820 (puis testé aussi en IPv6 littérale, même résultat positif).
- Handshake établi, rx/tx non nuls et croissants — premier accès VPN externe fonctionnel.
- allowed-ips du pair téléphone élargi côté PC4 à [RESEAU_WG], [LAN] pour accès complet au LAN (test ping LAN reporté à la prochaine session).

Leçons clés :

IPv4 "publique" affichée par un service externe (curl ifconfig.me) ne prouve PAS l'absence de CGNAT si elle est testée depuis l'intérieur du même réseau — il faut comparer avec l'IP WAN vue par la box elle-même.
Un /56 IPv6 délégué + SLAAC fonctionnel en interne ne garantit PAS l'accessibilité externe : un pare-feu IPv6 séparé du NAT IPv4 peut bloquer silencieusement tout trafic entrant.
Sous OpenBSD/pf, SLAAC nécessite explicitement pass in ... icmp6-type {routeradv,...} — sans ça, inet6 autoconf reste sans effet malgré les bons flags ifconfig.
WireGuard Android : rx=0 persistant + tx croissant = le paquet part mais n'arrive jamais → chercher du côté des pare-feu intermédiaires (box), pas du client.

État final : zeta-secure (PC4) est un bastion VPN WireGuard pleinement opérationnel, accessible en IPv6 depuis l'extérieur, avec DDNS auto-maintenu.

Prochaines étapes :

Test ping LAN complet depuis le téléphone (via tunnel élargi).
Vérifier rotation de l'adresse IPv6 SLAAC (~12 min) → confirmer que duck.sh suit bien le changement au prochain cycle cron.
PC3 → rôle zeta-log-dns-moni (en attente).

Compléments session 2026-06-15 (Claude Code) :

SVG harmonisés intégrés dans le repo (docs/images/, docs/, scripts/) ✅ commit sur Riemann_Lab_IA (Tâche 1 ✅).
DDNS PC4 — SSH corrigé et DDNS validé ✅ (session 16/06 00h50) :
- Cause du blocage SSH : agent présentant 3 clés avant zeta_cluster → OpenBSD atteint MaxAuthTries. Fix : IdentitiesOnly yes ajouté dans ~/.ssh/config pour l'alias zeta-del.
- Vérification : host -t AAAA [DDNS_PC4] → c10d:e4a1:c992:9918 = adresse autoconf non-temporary courante de re0 ✅
- /var/log/duckdns.log : contenu OK (2 octets), timestamp Jun 16 00:50 ✅
- L'adresse a changé depuis la session initiale (ad39:... → c10d:...) — DuckDNS a suivi, ce qui prouve que le cron */5 fonctionne en conditions réelles.
- Note : sous OpenBSD inet6 autoconf, l'adresse stable n'est PAS EUI-64 mais générée (RFC 7217). Elle change sur reboot ou changement de préfixe /56. Observer passivement en cas de renumbering box SFR.
PC3 zeta-log-dns-moni — déployé ✅ (16/06 ~23h20) :
- Prérequis manuels (hprzeta) : groupe sudo + clé SSH + NOPASSWD (/etc/sudoers.d/hprzeta_nopasswd).
- chrony : pool NTP iburst, allow [LAN], local stratum 10. Synchronisé sur ntp.viarouge.net stratum 3, err < 0.1 ms ✅
- rsyslog 8.16.0 : /etc/rsyslog.d/10-udp-receive.conf, UDP 514 ouvert, logs LAN → /var/log/remote/<hostname>/ ✅
- dnsmasq 2.75 : /etc/dnsmasq.d/zeta-cluster.conf, 4 nœuds .lan ✅
- glances : pip3 irrécupérable (Python 3.5 / pip trop récent). → Fallback : /usr/local/bin/zeta_monitor.sh (vmstat/free/df) + cron */5 ✅
§29 ajouté dans Formules_zeta.md : découpage par fenêtres T pour distribution multi-machines (v13+).
Bonnes-Pratiques enrichi : section OpenBSD/pf pièges réseau.

Session 2026-06-16 (après-midi — Claude Code) — Guide-Linux-Commandes

Objectif : créer un guide vivant des commandes Linux/BSD utilisées dans le projet.

Réalisations :

Guide-Linux-Commandes.md créé dans le wiki (500 lignes, 14 sections) : réseau (ip, ifconfig), SSH/SCP, WireGuard (Linux + OpenBSD), OpenBSD (doas, pf, syspatch, pkg_add), DuckDNS, cron, rsync, rclone, tmux, sed, divers (nc, journalctl, qrencode). Commit 4c39ca6 wiki master.
PDF pdf/cours/Guide-Linux-Commandes.pdf généré (84 Ko, lualatex) et uploadé sur Proton Drive (protondrive:hprzeta/Riemann_Lab/cours/).
Handoff.md mis à jour : lien [[Guide-Linux-Commandes]] ajouté dans la session du jour et dans la table des fichiers modifiés. Commit 1946c94.

Table des pièges documentés (leçons apprises en production) :

net.inet6.ip6.accept_rtadv n'existe pas sous OpenBSD (FreeBSD/NetBSD uniquement)
neighbrsolicit invalide dans pf → utiliser neighbrsol
NBSP (\xc2\xa0) dans config WireGuard depuis copier-coller mobile
curl -4 ifconfig.me trompeur pour détecter CGNAT depuis l'intérieur
crontab -e cassé sur Python 3.5 → workaround (crontab -l; echo ...) | crontab -
SVG → docs/images/ uniquement, pas scripts/
DuckDNS : champ A ≠ champ AAAA (remplir séparément)
pf bloque SLAAC sans règle ICMPv6 explicite (routeradv, neighbrsol, etc.)

Session 2026-06-17 (nuit — Claude Code) — v13 : fix bottleneck PC2 + benchmark cross-machine

Objectif : diagnostiquer scan_arb.so sur PC2, corriger la signature ctypes, créer v13.

Diagnostic scan_arb.c PC1 vs PC2 :

Sources identiques (diff = 0) ✅
ldd scan_arb.so → libm uniquement — correct par conception (Z_double C pur, pas libarb)
illinois_arb.so → lie libflint-arb.so.2 présent sur PC2 ✅
libflint-arb2 v2.23.0 installé sur PC2, mais python-flint absent → arb_hardy_z fallback mpmath.siegelz
Test initial (diagnostic) : signature ctypes incorrecte — 2 POINTER au lieu de 4 (brackets_a, brackets_b, fa, fb) → retourne 0 silencieusement (UB C, pas d'exception Python)

Benchmark v12 T=1000 :

Machine	Durée	Vitesse	Bottleneck
PC1 (turbo, python-flint)	3.3 s	195 z/s	Worker 0 : 2.9 s (arb_hardy_z)
PC2 (sans turbo, sans flint)	101.3 s	6.4 z/s	Worker 0 : 101.2 s (mpmath.siegelz ×18 600 évals)

Cause : T_SEUIL_PETIT_T = 200 dans v12 forçait arb_hardy_z (= mpmath.siegelz sur PC2) pour 18 600 évaluations dans [14, 200].

compute_zeros_v13.py — commit 77efd10 :

T_SEUIL_PETIT_T : 200 → 65 (N_RS=2 fiable dès t=65, confirmé empiriquement)
TOL_ARB : 1e-9 → 1e-12 (marge LMFDB, sans coût en double précision)
Itérations de correction :
- T_SEUIL=20 → LMFDB 16/20 (Z_double N_RS=2 brackets décalés à t<60)
- Re-éval fa/fb + continue → 9 vrais zéros perdus (brackets scan_arb hors-zéro = skip + vrai bracket aussi manqué)
- T_SEUIL=65 ← solution finale : couvre tous N_RS=2 (t<57) + marge

Benchmark v13 T=1000 :

Machine	Durée	Vitesse	LMFDB	Turing
PC1	1.0 s	624 z/s	20/20 ✅	COMPLET ✅
PC2	12.5 s	52 z/s	20/20 ✅	COMPLET ✅

Gains v13 vs v12 : PC1 ×3.2 · PC2 ×8.1.

Leçon scan_arb signature ctypes : 8 arguments obligatoires :

lib.scan_zeros_arb.argtypes = (
    [ctypes.c_double] * 3 +               # t_min, t_max, step
    [ctypes.POINTER(ctypes.c_double)] * 4 +  # brackets_a, brackets_b, fa, fb
    [ctypes.c_int]                          # max_brackets
)

Passer 2 POINTER au lieu de 4 → comportement indéfini C, retour 0 silencieux.

Session 2026-06-17 (après-midi — Claude Code) — STEP adaptatif corrigé + dashboard live

Objectif : lancer T=500 000 distribué PC1+PC2, puis T=1 000 000 si COMPLET ; évaluer l'ajout de PC3 (libflint-arb) pour v14.

Dashboard créé : scripts/zeta_run_progress.py — TUI curses live (répartition cible PC1/PC2, progression zéros par parsing tail des logs en croissance, CPU/RAM/disque via sonde /proc/stat+/proc/meminfo+os.statvfs locale et SSH, détail par worker). Lancé dans une session tmux dédiée zeta-progress (distincte de zeta-cluster, l'ancien moniteur 4 panneaux — confusion observée en session entre les deux). Détail complet dans claude-traitement-journalier/Process_Distribution_PC1_PC2_20260617.md (PDF généré via lualatex, recette feedback_pdf_generation).

Run T=500 000 distribué : ❌ KO — 818 408/818 414 zéros, Turing INCOMPLET (6 manquants), 39,12 min (vs ~20-25 min estimées — le modèle de pivot, calibré à T=1000-10000, sous-estime le ralentissement à grande densité de zéros).

Diagnostic STEP : _step_adaptatif() dans compute_zeros_v13.py était un STEP fixe 0.010 malgré son nom (calibré seulement à T=100000). Deux zéros dans le même pas STEP → Z(a) et Z(b) de même signe → la paire disparaît sans laisser de trace détectable dans les données (les écarts ratio≈3x cherchés comme signature se sont révélés être du bruit statistique normal, dispersé partout, pas un indicateur fiable).

Cause structurelle identifiée : l'écart minimal global décroît avec N(T) (répulsion de niveaux GUE, loi cubique near 0 ⇒ écart minimal ~ N(T)^(-1/3)), pas seulement avec l'écart moyen. Même la formule canonique du CLAUDE.md racine (min(2π/(5·ln(T/2πe)), 0.02)) reste plafonnée à 0.02 pour tout T réaliste de ce projet (le premier terme ne descend sous 0.02 qu'à T≈10²⁷) — donc pas réellement adaptative dans la plage utilisée ici.

Correctif (commit 30d05ee, Riemann_Lab_C, poussé) :

STEP(T) = κ · gap_moyen(T) · N(T)^(-1/3) / marge_securite     # κ≈1.357, marge=2.0

κ calibré sur le seul point fiable (T=100000, run Turing COMPLET).

Validation par rescan ciblé [260000, 390000] (sans relancer tout le run, ~13 min) :

224 420 zéros (ancien STEP) → 224 421 zéros (nouveau STEP)
1 zéro récupéré : t=273193.66313771, absent de l'ancien run à toute tolérance
0 régression : tous les zéros de l'ancien run présents dans le nouveau (sur-ensemble strict)
Nuance : sur cette plage Turing indiquait un swing de "6 manquants" mais seul 1 zéro réel manquait — le reste relève probablement du bruit normal de N(T) (terme S(T) oscillant).

Nouveaux STEP (vs ancien fixe 0.010) : T=1000→0.121 · T=10000→0.031 · T=100000→0.0095 (≈inchangé) · T=500000→0.0044 (×2,3 plus fin) · T=1000000→0.0032 (×3,1 plus fin).

PC3 (zeta-backup) pour v14 : ❌ indisponible. Pas de libflint-arb dans les dépôts (Ubuntu Xenial 16.04, i686 32 bits) ; libarb trouvé via apt-cache est un logiciel de bioinformatique sans rapport. CPU réel : Athlon II X2 215 2,7 GHz (pas un E2140 comme indiqué précédemment dans Architecture-Cluster-Zeta.md — à corriger). Compilation Arb depuis les sources jugée trop coûteuse pour un gain incertain sur un OS 32 bits ancien — non tentée.

Reporté à plus tard (décision utilisateur) : relancer T=500 000 distribué en nohup pour confirmer Turing COMPLET avec le STEP corrigé, avant d'envisager T=1 000 000.

Session 2026-06-23 (matin) — Incident Emergency Mode résolu (fstab nofail)

Contexte : maintenance préventive sur PC1 (riemann@zeta-lab) — écran Emergency Mode au démarrage Ubuntu, accompagné d'un bruit de disque inhabituel ; boot normal possible ensuite via Ctrl+D → login.

Symptômes observés :

Symptôme	Description
Emergency Mode au boot	Ubuntu bascule en mode urgence avant le login
Bruit disque	Son inhabituel pendant la phase de démarrage
Boot normal ensuite	Ctrl+D → login normal, système fonctionnel

Cause racine : entrée /etc/fstab bloquante pour le SSD Micron 1100 (/mnt/vault_rag, mis en service le 22/06) — systemd cherche l'UUID du SSD, time out, bascule en Emergency Mode. Le bruit de disque = HDD système sda en retry pendant ce timeout de montage (pas une défaillance du HDD).

Diagnostic disque système sda (Seagate BarraCuda ST1000LM035-1RK172, 1 To) :

SMART overall : ✅ PASSED
Reallocated/Pending/Uncorrectable : ✅ 0 / 0 / 0
Power_On_Hours : 3 547 h (~148 jours) · Température : 37 °C
Self-test court : ✅ Completed without error

Correction appliquée : ajout de l'option nofail à la ligne /etc/fstab du point de montage /mnt/vault_rag, pour éviter qu'un montage non critique bloque le boot.

Commit : 6f9e679 (wiki, MAINTENANCE_2026-06-23.md) — rapport source incomplet (s'arrête juste après l'annonce du correctif, sans citer la ligne fstab exacte ni de validation post-correctif par reboot). Log complété ici à partir du rapport disponible ; à vérifier par un reboot test si le doute revient sur ce point de montage.

Session 2026-06-23 (après-midi — Claude Code) — Diagnostic 5 zéros manquants T=500k, abandonné

Objectif : localiser précisément les 5 zéros manquants du run #4 (v13_distribue_T500000_20260617_213126, 818 409/818 414 zéros, commit 8f755eb) — tâche 1 du tableau « reste à faire » établi en début de session.

Méthode 1 — analyse statistique des écarts. Calcul de l'écart entre chaque paire de zéros consécutifs sur toute la plage [65, 500000] (818 405 écarts), normalisé par l'écart moyen local 2π/ln(t/2π). Top 150 écarts les plus anormaux (ratio jusqu'à 3.11) vérifiés un par un par échantillonnage du signe de Z(t) (formule de Hardy, theta_rapide.Z_fast, 9 points internes, dps=25) entre les deux zéros encadrants. Résultat : 0 changement de signe interne détecté — aucun des plus gros écarts ne cache un zéro raté. Réfute l'hypothèse d'une « paire serrée fusionnée » (un seul écart anormalement grand visible).

Méthode 2 — scan indépendant à phase de grille décalée. Le run original scanne avec un STEP global _step_adaptatif(500000)=0.0044316 mais des origines de grille différentes par worker (t_min_worker issu d'une recherche binaire sur N(T), pas un multiple rond de STEP). Hypothèse testée : un zéro raté à une phase donnée serait détecté à une autre phase. Re-scan complet [65, 500000] avec scan_arb (même STEP, grille ancrée à T_START=65, donc phase différente de toutes les origines de workers du run original), découpé en 25 chunks de 20 000 alignés exactement sur la grille (pas de rupture de phase aux jointures). Durée mesurée : 10.5 min (benchmark préalable sur un segment de 5000 → extrapolation 6.3 min, cohérent). 818 401 brackets trouvés, 0 candidat sans correspondance (tolérance 0.05) avec les zéros déjà calculés. La grille décalée retrouve essentiellement le même ensemble de zéros → l'hypothèse de phase de grille au niveau du scan est réfutée.

Méthode 3 — bisection sur N_exact(T). valider_turing() ne calcule le delta (attendus − calculés) qu'au dernier checkpoint ; pour localiser, calcul direct de delta(T) = N_exact(T) − n_calculé(T) sur une grille fine de T (40 points, dps=40, n_sigma=80), recherche des intervalles où delta augmente, puis bisection fine dans chacun. Piège découvert : delta(T) oscille de façon non monotone (multiples allers-retours 0 ↔ −1 sans qu'aucun zéro ne soit ajouté entre les deux bornes) — preuve que S(T) (le terme d'erreur de l'argument de ζ) franchit des seuils de demi-entier de façon générique, indépendamment de toute absence réelle de zéro. La bisection converge proprement (largeur finale < 0.4) sur 4 « candidats » — mais cette convergence nette ne distingue PAS un vrai zéro manquant d'un simple franchissement de seuil d'arrondi de S(T). Vérification des 4 candidats (45625.6-45625.99, 103467.17-103467.55, 144465.23-144465.61, 210464.60-210464.98) : dans les 4 cas, écart réel entre les zéros encadrants normal (ratio 0.45 à 1.35, dans la statistique GUE attendue) et 0 changement de signe de Z(t) entre eux. Les 4 candidats sont des faux positifs — méthode abandonnée après confirmation (arrêt de la passe restante, ~8 intervalles non traités, pour ne pas prolonger un run dont le signal s'est révélé non fiable).

Vérification de robustesse du chiffre « 5 manquants » lui-même : recalcul de N_exact(T_max=499999.67107366206) avec 5 réglages dps/n_sigma différents (35/50, 35/100, 50/100, 50/200, 60/300) → résultat identique à chaque fois (S(T)=+1.29897, loin d'un seuil de demi-entier) → le delta de +5 à T_max est robuste, donc le déficit est réel, pas un artefact de précision insuffisante à ce point précis.

Conclusion : les 5 zéros manquants existent réellement (confirmé) mais sont structurellement invisibles dans les données déjà calculées — aucune des 3 méthodes post-hoc ne peut les localiser. Le bug n'est probablement pas une question de phase de grille de scan (méthode 2 le réfute directement) mais plutôt un rejet silencieux de bracket valide dans illinois_refine_arb, ou une limite de précision de Z_double (RS C0+C1) qui empêche la détection initiale du changement de signe pour ces 5 cas précis — dans les deux cas, indétectable sans instrumenter le pipeline C lors d'un run réel.

Décision (hprzeta) : tâche 1 dépriorisée. Tâche 2 (« relancer T=500000 avec STEP validé ») : run #4 accepté comme référence officielle — pas de re-run (calcul déterministe, reproduirait exactement le même résultat 818409/818414). Documenté dans STACK.md (nouvelle table « Progression — T = 500 000 zéros ») et Handoff.md. Prochaine priorité : tâche 3 (zeta_sync_pc2.sh).

Session 2026-06-23 (soir — Claude Code) — Trou de couverture au pivot PC1/PC2 + marge STEP resserrée

Contexte : reprise de la tâche dépriorisée du run #4 (5 manquants T=500000, voir session après-midi ci-dessus), à la demande explicite de hprzeta : « lever cette limite en distribuant sur PC1 et PC2 ». PC2 (zeta-calc-second, [IP_PC2]) joignable ce soir (alias SSH local manquant — zeta-hp pointe vers la même IP que l'ancien nom, ssh direct par IP fonctionne).

Investigation — skill `riemann-code-review` + relecture `Formules_zeta.md`/`Bibliotheques.md`

Avant de relancer un calcul identique (qui aurait reproduit le même résultat 818409/818414, calcul déterministe), relecture ciblée des formules + du code C pour chercher des pistes non testées par les 3 méthodes post-hoc de l'après-midi. Deux pistes trouvées :

Piste A — trou de couverture structurel au pivot. scripts/zeta_distribute.py lance PC1 sur exactement [14.0, T_PIVOT] et PC2 sur exactement [T_PIVOT, T_MAX], sans overlap, alors que _partitionner_adaptatif() (frontières internes entre workers d'une même machine) applique un OVERLAP=0.5 explicite « pour couvrir les brackets sur les bords de segment ». Cette protection n'existe qu'en interne, jamais à la frontière PC1↔PC2. Mécaniquement, dans scan_zeros_arb (boucle while t_min+(k+1)*step <= t_max), PC1 s'arrête au dernier point de grille ≤ T_PIVOT (jamais exactement T_PIVOT) et PC2 démarre exactement à T_PIVOT en ne regardant que vers l'avant : il existe donc une fenêtre aveugle de largeur < 1 STEP (~0,0044 à T=500000) autour de T_PIVOT (~470124,8 pour le run #4) qu'aucune des deux machines ne scanne jamais. Aucun des 4 candidats vérifiés l'après-midi (bisection N_exact) ne couvre cette zone précise.

Piste B (plus incertaine) — marge de sécurité STEP basée sur un point unique. Le docstring de _step_adaptatif() (compute_zeros_v13.py, commit 30d05ee du 17/06) admet lui-même un écart minimal mesuré de 0,01281 à T≈453540 (dans la plage du run #4) contre un STEP=0,010 de l'époque → marge ×1,28, qualifiée de « quasi-échec » dans le code. La formule adaptative actuelle (κ=1,357) n'a été calibrée que sur un seul point (T=100000) puis extrapolée ×5 par une loi théorique N(T)^(-1/3), sans revalidation empirique à ce point de mesure à 453540.

Fix 1 — `OVERLAP_PIVOT=2.0` dans `zeta_distribute.py`

PC1 étendu à [14.0, T_PIVOT+2.0], PC2 étendu à [T_PIVOT-2.0, T_MAX] ; la déduplication existante (fusionner_csv, tolerance=0.01) absorbe le chevauchement (tolérance < écart minimal réel mesuré ~0,013, donc aucun risque de fusionner deux zéros distincts). Validé en --dry-run avant lancement.

Run #5 — overlap seul (MARGE_SECURITE=2.0 inchangée) : ❌ PIRE, 8 manquants

Lancé 23/06 21:39:03, durée 41,55 min mur. Fusion : 764898 (PC1) + 53514 (PC2) → 818406 zéros uniques (818412 bruts − 6 doublons dans la zone d'overlap, cohérent avec l'écart moyen mesuré ~0,56 à T≈470000 sur une fenêtre de 4,0 → ~7 zéros attendus en double — le mécanisme d'overlap/dédoublonnage fonctionne correctement). Turing : ❌ INCOMPLET, 8 manquants (vs 5 sur le run #4 de référence) :

T	Calculés	Attendus	Delta
62651,16	81840	81839	−1 (surplus)
142387,60	204601	204601	0
266310,16	409203	409204	+1
384797,81	613804	613810	+6
499999,67	818406	818414	+8

Diagnostic de la régression : comparaison des segments des 8 workers PC1 entre le run #4 (référence, logs/distribute_pc1_20260617_213126.log) et ce run (logs/distribute_pc1_20260623_213903.log) — toutes les frontières internes ont décalé (ex. Worker 3/4 : 250489,1 → 250490,3 ; Worker 6/7 : 416310,3 → 416311,4), pas seulement la frontière du pivot (+2,0 voulu). Cause : _partitionner_adaptatif() recalcule toutes les coupures par recherche binaire sur N(T) en fonction du T_MAX passé à PC1 — modifier le pivot pour corriger le trou de couverture a changé ce T_MAX, donc fait glisser en cascade les 7 frontières internes de PC1 (et pareil côté PC2). Avec la marge STEP déjà fine par endroits (piste B, ×1,28 « quasi-échec »), certaines nouvelles positions de frontière se sont révélées plus défavorables que les précédentes. Le fix du pivot (overlap) lui-même n'est pas remis en cause — il a correctement absorbé sa propre zone de chevauchement — mais il a révélé que la marge STEP globale (piste B) est le facteur dominant, pas seulement le trou de pivot.

Fix 2 — `MARGE_SECURITE` 2.0 → 3.0 dans `_step_adaptatif()`

MARGE_SECURITE = 3.0  # resserré le 23/06/2026 — voir docstring complet dans le fichier

STEP résultant à T=500000 : 0,00443 → 0,00295 (×1,5 plus fin). Fichier synchronisé sur PC2 par scp direct (sync ciblée d'un seul fichier Python, pas via zeta_sync_pc2.sh — ce script reste non testé en conditions réelles, voir tâche 3 de l'après-midi) ; valeur vérifiée sur PC2 après transfert (grep MARGE_SECURITE).

Run #6 — overlap (Option A) + MARGE×3 : ❌ 6 manquants

Lancé 23/06 22:27:23, terminé 23:13:11 (45,34 min mur), STEP=0,00304 (PC1) / 0,00295 (PC2), mêmes segments de workers que le run #5 (confirmé par diff direct des logs — la partition ne dépend que de T_MIN/T_MAX/N_WORKERS, jamais du STEP). Fusion : 764900 (PC1) + 53514 (PC2) → 818408 zéros uniques. Turing : ❌ INCOMPLET, 6 manquants (818408/818414) :

T	Calculés	Attendus	Delta
62651,16	81840	81839	−1 (surplus)
142387,98	204602	204600	−2 (surplus)
266310,16	409204	409204	0
384797,81	613806	613810	+4
499999,67	818408	818414	+6

Interprétation : à phase de grille strictement identique (run #5 = run #6), resserrer la marge (2.0→3.0) fait baisser 8→6 manquants — le mécanisme « deux zéros dans le même pas STEP » répond positivement à un STEP plus fin. Mais run #6 (marge 3.0, phase décalée) reste pire que run #4 (marge 2.0, phase originale) : 5 < 6, alors même que la marge nominale de #6 est plus grande. Conclusion à ce stade : la position exacte des frontières (la « phase » de la grille d'échantillonnage) compte au moins autant que la taille brute de la marge.

Option B (24/06, après minuit) — overlap appliqué après le partitionnement

Hypothèse testée : si on évite de perturber les frontières internes des workers (en gardant T_PIVOT exact, identique au run #4, au lieu de l'étendre de ±2,0 avant de le passer à _partitionner_adaptatif()), et qu'on comble le trou de couverture structurel par un 3e calcul séparé, minuscule, qui ne scanne que la fenêtre [T_PIVOT-2,0, T_PIVOT+2,0] (~7 zéros attendus), alors PC1 et PC2 retrouvent exactement la phase de grille du run #4, et seul ce petit supplément ajoute la correction du trou de pivot.

Implémentation (scripts/zeta_distribute.py) : lancer_pc1/lancer_pc2 reçoivent à nouveau T_PIVOT exact (pas T_PIVOT±OVERLAP_PIVOT) ; nouvelle fonction lancer_pivot_supplement() lance compute_zeros_v13.py --t-min T_PIVOT-2 --t-max T_PIVOT+2 en local, séquentiellement après PC1+PC2 (avant zeta_turbo_off.sh) ; fusionner_csv() généralisée pour accepter une liste de N CSVs (3 dans ce cas) au lieu de 2 fixes. Validé en --dry-run : PC1 [14.0, 470124.76], PC2 [470124.76, 500000] — bornes identiques (à 0,01 près) au run #4.

Run #7 — Option B (frontières originales + supplément pivot), MARGE toujours à 3.0

Lancé 24/06 00:23:46, terminé 01:07:19 (43,36 min mur, dont 42,58 min PC1+PC2 + le supplément pivot rapide). PC1 a trouvé 764893 zéros — quasiment identique au run #4 (764897), confirmant que les frontières sont bien restaurées à l'identique. Fusion : 764893 (PC1) + 53512 (PC2) + 6 (pivot) → 818405 zéros uniques. Turing : ❌ INCOMPLET, 9 manquants — pire que tous les runs précédents :

T	Calculés	Attendus	Delta
62651,16	81840	81839	−1 (surplus)
142387,60	204601	204601	0
266309,19	409202	409202	0
384796,47	613803	613807	+4
499999,67	818405	818414	+9

Diagnostic : avec des frontières quasi identiques au run #4 (PC1 764893 vs 764897 — écart de 4 seulement), la seule variable restante est MARGE_SECURITE (3.0 ici, 2.0 dans le run #4). Le résultat est pire avec la marge plus large (9 > 5) — ce qui invalide l'hypothèse « plus de marge = plus sûr » : STEP n'est pas un paramètre monotone. Chaque valeur de STEP définit une grille de points d'échantillonnage entièrement différente, et qu'une paire de zéros proches tombe dans le même pas dépend de la phase exacte de cette grille relative à la position réelle des zéros, pas seulement de sa taille. Sur 4 runs (2 jeux de frontières × 2 marges), aucune combinaison testée ne bat le run #4 d'origine (5 manquants) :

Run	Frontières	MARGE_SECURITE	Manquants
#4 (référence)	originales	2.0	5
#5	décalées (Option A)	2.0	8
#6	décalées (Option A)	3.0	6
#7	originales (Option B)	3.0	9

Décision (hprzeta, 24/06) — arrêt du tâtonnement, run #4 confirmé comme référence

Continuer à ajuster MARGE_SECURITE à l'aveugle revient à une recherche sans garantie de convergence (4 essais, aucune amélioration sur la référence). Décision : ne plus toucher MARGE_SECURITE/OVERLAP_PIVOT ce soir. Le run #4 (818409/818414, 5 manquants, 17/06) reste la référence officielle du projet pour T=500000 (déjà actée le 23/06 après-midi — voir plus haut). L'amélioration de ce déficit est reportée : seule piste jugée fiable pour aller plus loin, instrumenter scan_arb.c/illinois_refine_arb pour logger directement les brackets rejetés lors d'un run réel, plutôt que deviner via des ajustements de STEP a priori. scripts/zeta_distribute.py (Option B, fonction lancer_pivot_supplement + fusionner_csv généralisée) et compute_zeros_v13.py (MARGE_SECURITE=3.0) restent dans l'arbre de travail sur Riemann_Lab_C, non commités — la valeur 3.0 n'étant pas validée comme une amélioration, elle ne doit pas être committée en l'état (à rediscuter avant toute publication).

Note annexe — `zeta-progress`

Alias déjà présent dans ~/.bashrc (créé lors de la session du 17/06, tmux attach -t zeta-progress) — vérifié fonctionnel ce soir, pas recréé.

Session 2026-06-26 (soir — Claude Code) — Fix max_brackets dynamique + confirmation 0 REJECT/FALLBACK arb

Commits : 7914fa3 (instrumentation brackets) · 2b94b9f (max_brackets dynamique)

Contexte

Suite au run T=500k run #4 (818409/818414, 5 manquants), l'instrumentation ZETA_DEBUG_BRACKETS a été ajoutée à scan_arb.c et illinois_refine_arb.c pour tracer en production les brackets rejetés. Run de diagnostic T=50 000 lancé avec ZETA_DEBUG_BRACKETS=logs/brackets_debug/ pour identifier les causes des 5 manquants.

Fix — `max_brackets` dynamique dans `scan_arb.c`

Bug : MAX_BRACKETS = 512 fixé à la compilation → buffer saturable quand N_RS est grand (t ≥ 62000 : N_RS ≈ 99 termes Arb, densité de zéros élevée → plus de 512 brackets par segment possible). Quand le buffer est plein, les brackets supplémentaires sont silencieusement ignorés.

Fix : max_brackets alloué dynamiquement dans scan_arb_c() :

int max_brackets = (int)((t_end - t_start) / step * 2) + 64;

Allocation dynamique sur le tas (malloc/free) au lieu du tableau statique. Dépassement silencieux impossible.

Résultat

0 REJECT · 0 FALLBACK sur le run T=50k de diagnostic
Confirmé : les 5 manquants de T=500k run #4 sont dus au scan Z_double (phase de grille), pas à l'affinage illinois_refine_arb (qui est parfaitement fiable)
Décision : cause des manquants = ratés du scan, pas de l'affinage → point de départ pour v13+ rescan ciblé par déficit

Session 2026-06-27 (après-midi + soir — Claude Code) — Run T=5M + rescan v13 + P1 fp.siegelz + analyse Obj2

Run T=5 000 000 — lancé 16h02

PID principal : 46040   Workers : 46085–46092 (8 workers)
STEP = 0.001571 (adaptatif, MARGE=2.0)   N attendus ≈ 10 016 473

Lancé via : printf "5000000\nO\n" | nohup python src/calculs/optimisation/compute_zeros_v13.py > logs/run_v13_T5M.log &

ETA initiale : 28/06 ~15h30 (~24h) ETA révisée (calcul depuis checkpoints Worker 0 à 19h30) : 29/06 ~02h–11h (~35–43h)

Cause de la sous-estimation : le scan scan_arb scale en $T^{3/2}$, pas en $T$. Worker 7 [4.4M–5M] a $N_\text{RS} = \lfloor\sqrt{5\times10^6 / 2\pi}\rfloor = 892$ termes Arb par évaluation, vs ~100 à $T=500k$. Durée scan Worker 7 $\propto (5M)^{3/2} - (4.4M)^{3/2}$

durée Worker 0 → Worker 7 finit le scan vers ~01h00 le 29/06.

Mise à jour index.html (commit f25da46, Riemann_Lab_IA, poussé) : ETA corrigée.

v13 + rescan ciblé — validé T=1000

rescan_segments_deficit() implémentée dans calculer_zeros_v13() : identifie les workers en déficit ($n_\text{trouvés} < N(t_{hi}) - N(t_{lo})$ ), relance avec STEP/2. Validé T=1000 : 649 zéros · Turing COMPLET ✅ · LMFDB 20/20 ✅. Non commité — en attente fin run T=5M (contrainte : rien sur Riemann_Lab_C pendant le run).

P1 — fp.siegelz pour le bloc petit-t [14, 65]

Contexte : la note Formules_zeta.md §18.4 documente un gain ×40 (fp.siegelz vs mp.siegelz dps=35) pour l'architecture v4.1. En v13, la situation est différente :

T_SEUIL_PETIT_T = 65.0 (not 300)
Détection [14,65] : déjà via arb_hardy_z (Arb, 0.77 ms/appel) — plus rapide que fp.siegelz
Affinage [14,65] : mpmath.findroot(arb_hardy_z, ...) — Python loop avec overhead mpf

Optimisation implémentée : remplacé l'affinage par mpmath.fp.findroot(mpmath.fp.siegelz, ...) (float64 natif, sans overhead mpf). La détection reste sur arb_hardy_z (signes garantis).

Résultat T=1000 : 14 zéros dans [14,65] → précision ~1e-13 à 1e-15. Turing ✅, LMFDB 20/20. Gain réel pour T=100k : < 0.5s (seulement ~18 zéros dans [14,65]). Non commité — en attente fin T=5M.

P2 — Benchmark T=100k reporté

Impossible pendant T=5M : appeler zeta_turbo_off.sh après le run T=100k couperait les optimisations CPU pour T=5M (CPU governor → powersave, swappiness = 60). Les résultats seraient aussi biaisés par la compétition 9 processus T=5M + 8 workers T=100k sur 4 cœurs i7. À relancer après fin du run T=5M (29/06 ~02h–11h).

P3 — Analyse condition Obj2 : T=100k < 5 min

Scénario	T=100k	Atteint ?
v13 actuel (mesuré 8.50 min)	8.50 min	❌
+ P1 fp.siegelz	8.50 min (~0s gain)	❌
+ TOL 1e-12 → 1e-9 (×1.4)	~6.1 min	❌
+ v14 hybride Z_double→Arb (×8)	~1.1 min	✅

Gap actuel : ×1.70 à combler. La seule voie vers Obj2 est v14 (Illinois hybride Z_double pour Phase 1 → Arb pour 2-3 dernières itérations). Effort estimé : 2 jours. v14 ramènerait T=5M de ~35h à ~4–5h.

Checklist post-run T=5M

Ordre à suivre après confirmation fin du run :

zeta_turbo_off.sh
Analyse log logs/run_v13_T5M.log : Turing, manquants, z/s
Commit compute_zeros_v13.py + scripts/zeta_distribute.py → Riemann_Lab_C
Run T=100k benchmark (P2) — mesurer z/s et durée
Si Obj2 non atteint → démarrer v14

Session du 4 juillet 2026 — v13→v15, Objectif 2 atteint

Fin du run T=5 000 000 (v13)

Run lancé le 27/06 à 16h02, terminé le 29/06 à 00h02 (≈ 40h).

Indicateur	Valeur
Zéros trouvés	10 016 377
Attendus N(5M)	10 016 473
Manquants	96 ❌
Durée totale	115 005 s ≈ 31.9h (run) + 67 823 s ≈ 18.8h (rescan)
Rescan STEP/2	8 segments, +1 zéro net seulement
LMFDB	20/20 ✅

Commit v13 : a0e6e41 — feat(v13): fp.siegelz [14,65] + rescan ciblé déficit. Sync 4 branches effectuée.

Cause des 96 manquants : paires de zéros proches dont le changement de signe traverse deux pas STEP consécutifs (les signes se compensent). Le rescan STEP/2 n'y remédie que partiellement (+1 zéro net sur 96). Investigation reportée au prochain run T=5M avec v15.

⚠️ Correction du 18/08/2026 — cette explication est quantitativement invalidée (calcul GUE : 2 à 5 ordres de grandeur d'écart avec le déficit observé). Voir l'entrée du 18/08 ci-dessus et analyse_math_deficit_2026-08-18 pour la démonstration complète.

v14 — Cache log_n/isqrt_n (commit d4b3611)

Modification de illinois_arb.c et scan_arb.c : cache statique log_n_cache[] + isqrt_n_cache[] (N_MAX_CACHE=2100, 33 KB, init post-fork). Évite log(n) et 1/sqrt(n) répétés à chaque terme RS.

Benchmark	Valeur
T=100k durée	7.7 min (vs 8.50 min v13)
Vitesse	299 z/s
Gain vs v13	×1.10
LMFDB	20/20 ✅
Turing	COMPLET ✅

Piège documenté (04/07) : réduire Phase 2 à 1 Newton FIXE → erreur ~1e-6 pour t ≈ 65–77 (LMFDB 14/20). Cause : le biais Z_rs O(t^{-5/4}) positionne le pseudo-zéro à ~5e-3 du vrai zéro à t=65. 1 Newton quadratique depuis 5e-3 → erreur ~1.75e-6 >> tol. Solution v15 : seuil adaptatif SEUIL_1NEWTON = 20 000.

v15 — Phase 2 adaptative SEUIL_1NEWTON=20k (commit adf5d2a) ⭐

Modification de illinois_arb.c Phase 2 : n_newton = (t < 20000) ? 2 : 1.

t ≥ 20 000 : biais_RS ≈ 6.4e-7 → erreur 1 Newton ≈ 4e-13 < tol=1e-12 ✅
t < 20 000 : 2 Newton inchangé (biais_RS trop grand)

Benchmark	Valeur
T=100k durée	4.4 min ✅
Vitesse	517 z/s
Gain vs v13	×1.93
LMFDB	20/20 ✅
Turing	COMPLET ✅

CONDITION OBJECTIF 2 ATTEINTE : T=100k < 5 min ✅

Tableau de progression :

Version	T=100k	Vitesse	Algorithme clé
v12	8.8 min	261 z/s	Illinois Z_rs + 2 Newton Arb
v13	8.50 min	271 z/s	T_SEUIL=65, TOL 1e-12
v14	7.7 min	299 z/s	Cache log_n/isqrt_n
v15	4.4 min	517 z/s	Phase 2 adaptative SEUIL=20k

Invariants techniques (rappel pour les futures sessions)

TOL_ARB = 1e-12 — ne pas monter à 1e-9 (causait 16/20 LMFDB)
Phase 2 : 2 Newton early-exit pour t < 20k, 1 Newton pour t ≥ 20k
Cache RS : N_MAX_CACHE=2100, couvre T ≲ 27M
STEP adaptatif obligatoire (retour STEP fixe = zéros manquants)

Session du 5 juillet 2026 — Outillage RAG BrainVault + guide débutant + sync 4 branches

`scripts/rag_monitor.py` — surveillance du vault RAG

Script de photo instantanée (ou --watch N) de l'état du vault /mnt/vault_rag : garde de montage SSD (leçon : écriture silencieuse sur disque système si non monté), espaces disque, tailles chromadb/llamaindex_cache/agent_logs, collections ChromaDB, dernier log d'ingestion, et --test-query (latence embedding + recherche HNSW seule, sans LLM).

Test de validation :

Indicateur	Valeur
Collection	`riemann_lab_corpus`
Chunks	838 ✅
Chargement modèle (`all-MiniLM-L6-v2`)	18.4 s
Embedding question	2.04 s
Recherche HNSW	0.091 s ✅ (< 1 s)

Commité sur Riemann_Lab_C (95381e5), puis synchronisé (voir plus bas).

`Guide-RAG-BrainVault-Debutant` — MD + PDF

Guide pédagogique pour reprise à froid du RAG (BrainVault, ChromaDB, LlamaIndex).

.md → wiki racine, commit 8dd129b
.pdf → pdf/optimisation/ sur Riemann_Lab_IA, commit 9d1f25f, + copie ProtonDrive protondrive:hprzeta/Riemann_Lab/cours/

Sync 4 branches

Fusion des 3 commits Riemann_Lab_C (rag_ingest_corpus.py, rag_monitor.py, inbox_ia_liens.md) dans les 3 autres branches, sans conflit (fichiers absents des cibles) :

Branche	Commit après sync
`Riemann_Lab_C` (source)	`95381e5`
`main`	`e3ae517`
`Riemann_Lab_IA`	`0305742`
`Riemann_Lab_Test`	`7d7e866`

Les 4 branches sont à jour avec leur origin respective.

Piège RAG documenté — retrieval encore imparfait (voir aussi `Handoff.md`)

Bug confirmé et corrigé : le modèle d'embedding de la requête doit être identique à celui de l'ingestion (all-MiniLM-L6-v2) — un modèle différent (bge-small-en-v1.5 testé par erreur) donne des distances ~1.6 et des extraits hors sujet. Point non résolu : même avec le bon modèle, une requête test ne remonte pas toujours le bon chunk en top-5 (distances 1.37–1.45) — à creuser (reformulation de requête ? chunking trop grossier ?).

Session du 6 juillet 2026 — Audit des 4 skills Claude Code

Vérification systématique des skills du projet sur les 3 emplacements : global ~/.claude/skills/, repo tracké .claude/skills/, skills_export/.

`riemann-lab` — références figées, corrigé

SKILL.md identique partout. Mais references/Formules_zeta.md (500 lignes) et references/Bibliotheques.md (349 lignes) dans le repo tracké étaient restés figés au commit initial 8dc5908, alors que skills_export/global avaient les mises à jour v14/v15 + règle KaTeX (969/428 lignes). Cause : le commit 269aff5 ("aligner .claude/skills avec skills_export") n'avait en fait touché que SKILL.md, jamais les fichiers de références.

Fix : copie de skills_export/riemann-lab/references/*.md vers .claude/skills/riemann-lab/references/*.md — commit 87ffa12.

`phase-c-illinois` — vraie divergence en deux lignées, fusionné

Plus grave qu'un simple retard : depuis le 11/06, la copie repo (.claude/skills/, version frontmatter 0.4.0) avait continué avec le contenu v6/v7/v8 (leçon technique précision→SIMD ×16, benchmark v8), pendant que skills_export/global (version 0.3.0, pourtant datés plus récemment au 04/07) avaient évolué séparément avec le contenu v9 (Brent), v12-v15 (Arb, cache RS, SEUIL_1NEWTON) — chaque copie manquait le contenu unique de l'autre.

Fix : fusion manuelle des deux lignées en un document chronologique complet v4.1 → v15 (368 lignes, version 0.5.0) :

Table « État Phase C » unifiée avec tous les jalons (v6 à v15) dans l'ordre
Réordonnancement de la section v9 (Brent) qui était placée après v13-v15 par erreur
Ligne « Rapport analyse_problemes_v13_v15.md » corrigée de « à faire » à « FAIT » (elle l'était depuis le 04/07 — commit fda4fb9)
Section v8 condensée avec renvoi vers analyse_problemes_v8_v9.md (déjà documenté dans le wiki) plutôt que dupliquer le détail complet
Renvoi vers Handoff.md pour la liste des tâches restantes au lieu d'une todo-list dupliquée et obsolète

Commit acefd4b, propagé aux 3 emplacements identiques.

`riemann-code-review` et `riemann-security-review` — RAS

Identiques entre global et repo tracké (123 lignes chacun, aucun diff). Absents de skills_export/ par design (jamais exportés là — seuls phase-c-illinois et riemann-lab le sont) : pas une désynchronisation.

Sync 4 branches (les 2 fix)

Branche	Commit fix `riemann-lab`	Commit fix `phase-c-illinois`
`Riemann_Lab_C` (source)	`87ffa12`	`acefd4b`
`main`	`6a151b0`	`54e4f70`
`Riemann_Lab_IA`	`c2741f1`	`ba80b59`
`Riemann_Lab_Test`	`0771117`	`89dbff3`

Leçon retenue

La « règle de double mise à jour » (src/calculs/optimisation/CLAUDE.md) doit couvrir explicitement SKILL.md et tous les fichiers references/*.md — un commit qui ne touche que SKILL.md laisse les références dériver silencieusement, invisible tant que personne ne compare les 3 emplacements ligne à ligne.

Session du 19 juillet 2026 — rag_query.py industrialisé + durci contre l'hallucination — commits `86ab0ae`, `01934df`, `3307bad` (Riemann_Lab_C)

Industrialisation de la boucle RAG — `scripts/rag_query.py`

Contexte : chantier RAG BrainVault (Objectif 2) — étapes 1-4 déjà terminées (vault opérationnel, 838 chunks ingérés). Reste à fiabiliser la boucle retrieval + génération avant de considérer le chantier clos.

scripts/rag_query.py (commit 86ab0ae) : retrieval ChromaDB + génération mathstral en une seule commande, garde de montage SSD, avertissement RAM, log optionnel.
Détection d'hallucination sur valeurs numériques/IP ajoutée (commit 01934df).
2 faux positifs corrigés (commit 3307bad, détail plus bas).

🐛 Piège RAG — retrieval marginal mais compensé par le contexte

Pour la requête « Quel est le seuil SEUIL_1NEWTON ? », le bon chunk (analyse_problemes_v13_v15.md, distance 1.182) reste hors du top-6 (chunks génériques à 1.116–1.179 mieux classés). Cause probable : all-MiniLM-L6-v2 (généraliste anglais) discrimine mal le jargon technique français+code sur ce corpus très mathématique — bruit de fond élevé (1.1–1.6 partout). Malgré cela, la génération donne la bonne réponse (20000.0) grâce à un chunk voisin pertinent (illinois_arb.c, distance 1.179, contient la définition C). Retrieval imparfait ≠ échec systématique.

🆕 Piège RAG n°2 — hallucination malgré bon retrieval

Test de contrôle qualité (Guide-RAG-BrainVault-Debutant.md §5) : « Quelles sont les IP des 4 machines du cluster ? » → attendu .24 / .52 / .22 / .54.

Retrieval bon cette fois (distances 0.994–1.122, nettement meilleures que Q1).
Génération avec 2 erreurs sur 4 : mathstral répond .24 / .53 / .25 / .54 — PC2 et PC3 inventés (.53 au lieu de .52, .25 au lieu de .22). Différent du piège .94 (archive obsolète) déjà documenté.
Hypothèse : les 4 IP ne sont pas regroupées dans un seul chunk retrouvé (un chunk dit « Fiche technique des 3 machines », la 4ᵉ IP vient d'un autre extrait) — le modèle a pu « recomposer » en confondant des chiffres.
Leçon : un bon retrieval ne garantit pas une génération fidèle sur des données factuelles précises (IP, seuils, constantes) — vérifier systématiquement contre la source.

Mitigation testée

Tentative 1 — contraindre le prompt à citer la source exacte : échec, pire que sans consigne. Retest de la question IP cluster avec citation [fichier] obligatoire après chaque fait → .50/.51/.52/.53 (séquence plausible mais 4 valeurs sur 4 fausses, contre 2/4 sans la consigne), tout en citant correctement Architecture-Cluster-Zeta.md sur les 4 lignes. La citation donne une fausse impression de fiabilité sans réduire l'hallucination — un modèle 7B local n'est pas fiable pour s'auto-vérifier.
Tentative 2 — vérification programmatique valeurs_non_ancrees() : testée et validée. Extrait les nombres/IP de la réponse et vérifie leur présence littérale dans le texte brut des chunks récupérés, indépendamment de toute citation déclarée par le modèle. Détecte 2/2 IP fausses sur la réponse sans consigne, 3/3 sur celle avec consigne (la 4ᵉ, .52, existe dans le contexte mais mal attribuée — non détectable par cette méthode).
Bug annexe corrigé au passage : citations_douteuses() cherchait [fichier] strictement, mais mathstral produit ([fichier]) (délimiteurs doublés) — regex simplifié pour chercher le nom de fichier directement.

Confirmation croisée SEUIL_1NEWTON — 2 faux positifs trouvés et corrigés (commit `3307bad`)

Retest de la question déjà validée pour confirmer les garde-fous — a révélé 2 bugs :

citations_douteuses() comparait le nom de fichier extrait de la réponse au chemin complet stocké en métadonnée pour le code (src/.../illinois_arb.c) → faux positif « citation fabriquée » sur une source pourtant bien retrouvée. Fix : comparaison sur os.path.basename des deux côtés.
valeurs_non_ancrees() ne gérait pas les séparateurs de milliers — mathstral a répondu 20,000.0 pour la valeur correcte 20000.0 → faux positif. Fix : normaliser_separateurs_milliers() (virgule/espace suivi d'un chiffre) appliquée aux deux côtés avant comparaison.

Après correction, un 3ᵉ appel a produit 20.000 (double) — le check l'a signalé à raison : lu en notation française, 20.000 = 20 (pas 20 000), littéralement absent de la source. Le check fonctionne comme prévu : il détecte aussi un formatage ambigu qui mérite une vérification humaine. mathstral change de format à chaque appel pour la même valeur (20000.0 → 20,000.0 → 20.000) — instabilité de formatage numérique à garder en tête au-delà du seul risque d'hallucination.

Documentation

Guide-RAG-BrainVault-Debutant.md §7 (K/retrieval), §8 (hallucination mathstral), §9 (bilan) mis à jour — commit caeaf7b (wiki, Riemann_Lab_IA côté PDF a2411a7). Handoff.md (wiki) mis à jour avec les 2 pièges et la mitigation — commits b35f482, a9be73f0 (wiki).

Chantier RAG (3 blocs + mitigation hallucination) considéré clos pour cette session. Prochaine reprise : Anthropic Skilljar (Claude Code 101 → MCP intro/avancé → Subagents → Agent Skills), ou run T=5M avec v15 pour investigation des 96 manquants du run T=5M v13.

Session du 8 août 2026 — Profiling réel illinois_arb.c + piste multi-IA explorée puis abandonnée

Contexte : run T=5M v15 arrêté le 06/08 (voir Handoff.md), décision de suite non tranchée. En parallèle, reprise de l'optimisation Phase C avec des chiffres réels plutôt que des estimations.

Profiling `perf record` sur `illinois_refine_arb`

Harnais de benchmark construit (c_modules/gen_brackets.py, c_modules/perf_harness.py) : 300 brackets réels via mpmath.siegelz (dps=15, suffisant pour la détection de signe), 150 en zone t∈[500,5000] (branche Phase 2 = 2 Newton) et 150 en zone t∈[50000,150000] (branche Phase 2 = 1 Newton, SEUIL_1NEWTON=20000). perf record lancé en root (perf_event_paranoid=4 sur cette machine → sudo requis, pas de règle NOPASSWD dédiée) : 7 500 appels réels, 4000 Hz, 85 232 échantillons.

Résultat : 91% du temps total dans GMP+FLINT (libgmp 37,50% self + libflint 53,53% self), exclusivement via arb_fpwrap_cdouble_hardy_z (Phase 2 — n'est appelée que 1 à 2 fois par zéro). Notre propre code (illinois_arb.so — Phase 1 cache Z_rs_double) ne coûte que 0,20% du temps mesuré. Fonction individuelle la plus chaude : __gmpn_mul_basecase_coreisbr à 16,67% à elle seule. ~3,5% cumulés dans le bookkeeping des bornes d'erreur Arb (mag_add/mag_div/mag_mul/mag_set_ui).

Comparaison Arb vs MPFR pur — piste MPFR écartée

Script c_modules/compare_arb_vs_mpfr.py : mêmes 300 brackets passés à illinois_refine_arb (Arb/FLINT) et illinois_refine (MPFR pur, PREC=170 bits, réévalue Z_mpfr à chaque itération de la sécante au lieu de 1-2 fois). Résultat sans ambiguïté :

illinois_refine_arb : 2,95 ms/appel — erreur moyenne 4,6e-11 vs mpmath dps=35
illinois_refine (MPFR pur) : 35,05 ms/appel — erreur moyenne 9,5e-5 vs mpmath dps=35

Arb est 11,88× plus rapide ET ~4 ordres de grandeur plus précis. Le biais vient de la formule (RS tronquée C0+C1), pas de la précision arithmétique — passer en MPFR pur à haute précision n'élimine pas ce biais structurel. Piste écartée définitivement, à ne pas reproposer dans une future session d'optimisation.

Outils + dataset (brackets.json, 300 brackets réutilisables) commités Riemann_Lab_C commit 4df0738, poussé.

Piste multi-IA (DeepSeek/Claude/Kimi via API) — explorée puis abandonnée

scripts/multi_ia_query.py créé (commit d4a1d15) : orchestrateur parallèle interrogeant Claude (Anthropic), DeepSeek et Kimi (Moonshot) via leurs API respectives, avec les résultats du profiling ci-dessus comme contexte de la question posée. Deux tentatives :

ANTHROPIC_API_KEY/KIMI_API_KEY absentes de .env (attendu, Kimi déjà abandonné pour incompatibilité x86_64/Waydroid) — DeepSeek configurée mais échec 402 Insufficient Balance.
Après rechargement du compte DeepSeek par hprzeta : échec identique 402 Insufficient Balance — cause non éclaircie (délai de propagation du paiement, ou solde crédité sur un compte/solde différent de celui utilisé par l'API).

Décision hprzeta (08/08/2026) : abandon de la piste multi-IA. Coût en crédit API non justifié pour l'usage actuel — l'audit de code Phase C peut se faire directement via une session Claude Code (claude.ai), sans passer par une API tierce facturée à l'usage.

Démontage effectué :

scripts/multi_ia_query.py supprimé (commit dcffa49, Riemann_Lab_C, poussé)
.env supprimé en local (seul consommateur = script retiré, aucun autre usage détecté)
Rapports d'échec pdf/optimisation/Voie_b_5/md_to_claude/multi_ia_*.md (gitignorés) supprimés (clutter local, ne contenaient que des messages d'erreur, aucune clé)
Audit de sécurité effectué avant suppression : .env n'a jamais été tracé par git (aucune branche, tout l'historique), aucun motif de clé API trouvé dans git log --all -p, .gitignore intact (.env, .env.local) — aucune fuite constatée

Prochaine reprise : optimisation arb_fpwrap_cdouble_hardy_z (piste flags/précision réduite, voir Handoff.md § REPRENDRE ICI) via audit direct avec Claude, ou reprise de la décision T=5M v15 (toujours en attente depuis le 06/08).

Session du 8 août 2026 (soir) — Validation run réel : acb_dirichlet_hardy_z 64 bits, gain ×1,98 confirmé

Suite directe de la session du matin (profiling perf + découverte du levier acb_dirichlet_hardy_z, voir entrée précédente). Objectif : passer du chiffre synthétique (300 brackets) à une validation sur run réel, sans toucher à la production, puis choisir la précision et documenter séparément la découverte annexe du 17/20.

Vendoring des headers FLINT 3.3.1

apt install libflint-dev ne fournit que la version 3.0.1 — ABI incompatible avec la .so réellement chargée par illinois_arb.so (FLINT 3.3.1 exact, confirmé via le symbole flint_version lu en mémoire). Récupération des sources officielles (github.com/flintlib/flint tag v3.3.1), ./configure local (nécessite m4, installé par hprzeta via sudo apt install -y m4 dans un terminal réel — le préfixe ! du chat n'a pas de tty pour saisir un mot de passe, contrairement à un terminal direct) pour générer flint.h/flint-config.h corrects (FLINT_BITS=64 confirmé). Extraction minimale par fermeture transitive réelle (gcc -M sur le prototype) : 23 headers, 276 Ko, au lieu des ~800+ de FLINT complet. Vérifié exempt de tout chemin absolu machine-spécifique avant commit. Committé Riemann_Lab_C 95ea6ff (c_modules/flint-headers-3.3.1/, README.md avec provenance/licence LGPL).

Prototype et balayage de précision (300 brackets)

illinois_refine_arb_lowprec : même architecture 2 phases que la production, Phase 2 utilise acb_dirichlet_hardy_z(res, t, G, chi, len, prec) (précision fixe explicite, UN SEUL calcul, pas de boucle d'escalade) au lieu de arb_fpwrap_cdouble_hardy_z (escalade 64→8192 bits visant ~1e-16, confirmée depuis le code source FLINT src/arb_fpwrap/fpwrap.c dans la session du matin). Pattern d'init dirichlet_group_t/ dirichlet_char_t (q=1, caractère principal = zêta pure) confirmé sur le test officiel FLINT acb_dirichlet/test/t-hardy_z.c.

Balayage sur les 300 brackets (c_modules/brackets.json) : à partir de 48 bits, résultat identique bit-à-bit à la production (gain ×8,82) ; à 64 bits, identique aussi (gain ×5,75). En dessous de 48 bits, dégradation mesurable (mais toujours <1e-8).

Décision précision — 64 bits (hprzeta, 08/08 soir)

Argumentaire présenté : 64 bits coïncide avec WP_INITIAL de arb_fpwrap lui-même (point de comparaison naturel), marge ~7 décimales au-dessus du besoin théorique ~40 bits (tol=1e-12) contre ~2,4 décimales à 48 bits. hprzeta a tranché pour 64 bits — le delta de gain (×8,82 vs ×5,75) jugé secondaire face au risque d'un cas limite non couvert par l'échantillon de 300 brackets.

Validation run réel — isolation stricte de la production

Consigne explicite hprzeta : ne rien toucher en production avant validation complète. Fichiers créés (tous nouveaux, aucune modification de fichier existant) :

c_modules/illinois_arb_lowprec.c/.so — précision exposée en paramètre runtime
compute_zeros_v15_test_lowprec.py — copie quasi à l'identique du worker de compute_zeros_v15.py, diff minimal marqué ### LOWPREC ### dans le code, dossier de sortie distinct (calculs/v15_LOWPREC_TEST_*)

Smoke test T=1000 (0,7s, 20/20 LMFDB, Turing COMPLET) puis run réel T=10000 (workflow turbo standard, zeta_turbo_on.sh/off.sh — sudoers NOPASSWD dédiés, exécution directe sans intervention manuelle) :

	Production (`illinois_arb.so`)	Test lowprec (64 bits)
Zéros trouvés	10 142	10 142 (identiques)
Turing-Backlund	✅ COMPLET	✅ COMPLET
LMFDB (20 premiers)	20/20 < 1e-9	20/20 < 1e-9
Durée run	20,2 s	10,2 s
Vitesse	501,12 z/s	992,13 z/s

Gain bout-en-bout mesuré : ×1,98 — moins que le ×5,75 des 300 brackets isolés, parce que la phase Illinois ne représente que 76,9 % du temps mur du run réel (profil détaillé production : 124,44s cumulés / 10 130 appels = 12,28 ms/appel) ; le reste (détection scan_arb, petits t, Turing, overhead multiprocessing) est identique entre les deux runs et ne bénéficie pas de l'optimisation. Run de production T=10000 lancé en comparaison directe via compute_zeros_v15.py --t-min 14 --t-max 10000 (invoqué tel quel, pas modifié) pour garantir une comparaison à conditions strictement identiques.

Vérification finale : git status confirmé vide sur illinois_arb.c, illinois_arb.so, compute_zeros_v15.py — aucune modification de production.

Découverte annexe résolue — 17/20 sur `test_illinois_arb.py`

En validant le prototype, découverte que la production illinois_arb.so elle-même obtient 17/20 (pas 20/20 comme documenté) sur test_illinois_arb.py — 3 échecs à t<300 (14,13/21,02/25,01), reproduits à l'identique bit-à-bit par le prototype (donc pas un bug introduit aujourd'hui). Résolu par les runs réels T=1000/T=10000 : le pipeline compute_zeros_v15.py route déjà t<65 via arb_hardy_z+mpmath.fp.findroot, jamais via illinois_refine_arb directement — LMFDB 20/20 confirmé sur les deux runs. Le 17/20 est un faux problème du test isolé (exerce un chemin que la production n'emprunte jamais), pas une régression. Docstring de test_illinois_arb.py reste imprécis (affirme 20/20) — correction mineure non prioritaire.

État en fin de session

illinois_arb.c/illinois_arb.so/compute_zeros_v15.py de production non modifiés. Prototype validé mais pas encore intégré — décision d'intégration (Makefile + remplacement

recompilation + revalidation + commit) laissée à une prochaine session. Fichiers de test (compute_zeros_v15_test_lowprec.py, illinois_arb_lowprec.c/.so) encore non commités dans le repo à ce stade.

Session du 8 août 2026 (nuit) — v16 intégrée en production : Z_arb à précision fixe

Suite directe de la validation du prototype (entrée précédente, ×1,98 sur run réel T=10000). Question posée par hprzeta : « décide si on intègre le prototype en production. » Décision prise : oui, en suivant le protocole de validation standard du projet (T=100k COMPLET + LMFDB 20/20, comme pour chaque version v12→v15 avant elle).

Intégration

illinois_arb.c modifié en place (convention du projet — v12 à v15 sont toutes dans ce même fichier, versionnées par commentaire/commit, pas par renommage) :

Z_arb réécrit : acb_dirichlet_hardy_z(res, s, G, chi, 1, 64) au lieu de arb_fpwrap_cdouble_hardy_z(&res, arg, 0)
Nouveau init_dirichlet_trivial() (groupe/caractère q=1, statique par worker, pattern identique à init_rs_cache())
#define PREC_BITS_ARB 64
En-tête de fichier mis à jour (bloc v16 ajouté avant le bloc v14 existant)

Makefile : cible illinois_arb.so — ajout de -I flint-headers-3.3.1.

compute_zeros_v16.py créé (convention du projet : un fichier par version) — copie de compute_zeros_v15.py, renommage systématique des symboles (worker_v16, calculer_zeros_v16, etc. via sed) puis réécriture manuelle du docstring d'en-tête pour décrire le vrai changement v16 (le docstring v15 mécaniquement renommé décrivait à tort SEUIL_1NEWTON, inchangé depuis v15).

Validation — sanity checks puis T=100000 (le vrai protocole d'acceptation)

test_illinois_arb.py relancé sur le nouveau illinois_arb.so : 17/20 identique au baseline connu (cas t<300, non représentatif du pipeline réel — voir découverte annexe de la session précédente), aucune régression détectée.
Smoke test compute_zeros_v16.py --t-max 1000 : 20/20 LMFDB, Turing COMPLET.

Run réel T=100000 (workflow turbo standard, zeta_turbo_on.sh/off.sh — sudoers NOPASSWD, exécution directe) — comparaison avec la référence v15 connue (STACK.md) :

	v15 (référence documentée)	v16 (ce run)
Zéros	138 069	138 069 / 138 069 (exact, formule de Weyl)
Durée	4,4 min	1,6 min (98,1s)
Vitesse	517 z/s	1407 z/s
Turing-Backlund	COMPLET	✅ COMPLET
LMFDB	20/20	✅ 20/20 < 1e-9

Gain mesuré : ×2,75 — supérieur au ×1,98 mesuré à T=10000 (la phase Illinois, seule à bénéficier de l'optimisation, pèse une part croissante du temps mur total à mesure que T augmente ; profil détaillé du run : arb_C 334,81s cumulés / 138 061 appels = 2,43 ms/appel, contre 12,28 ms/appel en v15 — cohérent avec les mesures de la session précédente sur 300 brackets isolés).

Documentation synchronisée (règle de double mise à jour, `c_modules/CLAUDE.md`)

STACK.md : nouvelle ligne v16 dans les 2 tableaux de versions (T=100k), section Phase C, section Objectif 2. Renommage de la piste long-terme « v16 — Odlyzko- Schönhage » en v17 (collision de nom évitée). Gain global v1→v16 recalculé (×28 600 × 2,75 ≈ ×78 650, dérivé du multiplicateur v15 déjà établi × le ratio v15→v16 mesuré).
Skills phase-c-illinois et riemann-lab (+ references/Bibliotheques.md, references/Formules_zeta.md) : nouvelle section v16 dans chacun, synchronisée sur les 3 emplacements (~/.claude/skills/, .claude/skills/ du repo, skills_export/) — 2 des 3 versionnés et commités.

Commits

00abe5c (Riemann_Lab_C) : illinois_arb.c + Makefile + compute_zeros_v16.py
b45e27f (Riemann_Lab_C) : sync skills (8 fichiers, 2 emplacements versionnés)
Wiki : STACK.md + Handoff.md + cette entrée JOURNAL.md

État en fin de session

v16 est désormais la version de production active. Prototype (illinois_arb_lowprec.c/ .so, compute_zeros_v15_test_lowprec.py, commit eea9d9f) conservé comme trace historique de la validation isolée. Chantier clos. Reprises possibles : décision T=5M (toujours ouverte depuis le 06/08, désormais accélérée par v16 si le run est retenté), ou v17 — Odlyzko-Schönhage (piste long terme, non commencée).

Session du 8 août 2026 (nuit) — Sync 4 branches (backlog Riemann_Lab_C 02/08 → 08/08)

Demande hprzeta : « sync les autres branches (main, Riemann_Lab_IA, Riemann_Lab_Test). »

Backlog accumulé sur Riemann_Lab_C depuis le point de divergence commun (e01bb1d, fix RAG device=cpu, dernier point où les 4 branches étaient alignées) : 15 commits couvrant la calibration MARGE_SECURITE (02/08), le portage zeta_distribute.py v13→v15 + ratio PC1/PC2, zeta_backup_status.py, la piste multi-IA (créée puis retirée), le profiling Phase C et l'intégration v16 (sessions du jour). 49 fichiers modifiés au total (headers FLINT, illinois_arb.c, prototypes, scripts, skills).

Vérification préalable : git log origin/main..Riemann_Lab_C confirmait tout le backlog en attente ; git log Riemann_Lab_C..origin/{main,IA,Test} ne montrait que d'anciens commits de merge déjà réintégrés (pas de contenu réellement absent de Riemann_Lab_C) — cohérent avec le pattern établi du projet (tout part de Riemann_Lab_C vers les 3 autres). .gitignore (protection .mcp.json/.env) vérifié intact sur les 3 branches cibles avant merge.

Merge Riemann_Lab_C → chacune des 3 branches (--no-ff, message détaillé) :

Riemann_Lab_IA : 82bc62e (poussé)
main : b9623b8 (poussé)
Riemann_Lab_Test : 59b4d0e (poussé)

Aucun conflit sur les 3 merges. Vérification finale : contenu de illinois_arb.c (et implicitement le reste, mergé depuis le même commit) confirmé identique (MD5) sur les 4 branches. Les 4 branches sont maintenant réellement à jour entre elles — plus de désynchronisation en attente.

Session du 8 août 2026 (nuit, suite) — Publication documentation publique v16

Demande hprzeta : mettre à jour l'ensemble de la documentation publique et le site suite à l'intégration v16, en un seul bloc sans validation intermédiaire (sauf blocage réel).

Site GitHub Pages (`docs/index.html`, branche `Riemann_Lab_IA`)

Audit complet des mentions v15 (badge hero, texte d'étape, titre section performances, tableau T=100k, 5 cartes stats turing/lmfdb/phase2/commit/gain, titre

grille 12 cartes + tableau détaillé + 3 cartes de synthèse de la section « Progression v1→vN », vitesse cluster PC1, note piste T=5M, footer). Toutes les valeurs "version courante" remplacées par v16 (1.6 min, 1407 z/s, ×2.75 vs v15, ×78 650+ vs v1, commit 00abe5c) ; les lignes v15 historiques sont conservées mais démotées visuellement (perte du style "actif" ✦/gras/bordure dorée) et correctement attribuées comme version précédente, pas courante.

Guides wiki

Guide-Linux-Commandes.md §21-22 : commandes réellement utilisées cette session — perf record/report (piège perf_event_paranoid=4, le préfixe ! du chat n'a pas de tty pour sudo — nécessite un terminal réel côté hprzeta ; piège segfault ctypes.c_char_p.in_dll sur un symbole char[], doit utiliser (ctypes.c_char * N).in_dll) et compilation FLINT depuis les sources (./configure, dépendance cachée m4, extraction de la fermeture transitive minimale des headers via gcc -M plutôt que copier les 800+ headers de FLINT complet).
Bonnes-Pratiques-Claude-Code.md : nouvelle section capturant le protocole en 6 étapes suivi pour v16 (chiffrer avant de proposer → prototyper en isolation stricte → valider sur run réel modeste → décision explicite → intégrer selon la convention du projet → revalider au protocole standard avant d'adopter) — vaut comme leçon réutilisable pour tout futur remplacement touchant le cœur du calcul de production.
Bibliotheques.md (page wiki publique — distincte de la copie dans .claude/skills/riemann-lab/references/, déjà mise à jour lors de l'intégration) §18 : mécanisme arb_fpwrap détaillé, acb_dirichlet_hardy_z, dépendance headers FLINT vendorisés, tableau de choix de précision, résultats de validation.

Rapport de synthèse v1→v16

Format aligné sur analyse_problemes_v13_v15.md (lu en premier pour respecter la structure : sections par problème/cause/solution, tableaux avant/après/gain, section Questions ouvertes, en-tête/pied de page standard). Nouveau document analyse_problemes_v1_v16.md : résumé exécutif + trajectoire globale (tableau des 9 étapes majeures v1→v16), sections condensées v1→v14 (renvoyant vers les rapports dédiés existants pour le détail), section v14→v15 à détail moyen, et section v15→v16 entièrement développée (diagnostic perf record, piste MPFR pur écartée avec chiffres, mécanisme acb_dirichlet_hardy_z, dépendance FLINT, choix de précision, validation 2 étapes T=10000/T=100000), tableau récapitulatif global 14 versions, questions ouvertes, table des rapports détaillés par transition.

PDF généré via scripts/build_pdf_riemann.sh (xelatex + DejaVu, script déjà établi pour tous les rapports analyse_problemes_* précédents) — 8 pages, sans erreur. Poussé sur Proton Drive (protondrive:hprzeta/Riemann_Lab/backup/pdf/optimisation/, même emplacement que les rapports existants, confirmé par rclone lsf avant de pousser). Note : le premier appel rclone lsd de la session a affiché un NOTICE « 401 Invalid access token » puis a quand même renvoyé un listing valide — pas d'action nécessaire, auto-résolu (probablement un refresh de token en cours).

Commits et sync

591033d (Riemann_Lab_IA) : docs/index.html + pdf/optimisation/ analyse_problemes_v1_v16.pdf
2bc997c (wiki master) : guides + Bibliotheques.md + rapport source .md
4 branches re-synchronisées (2ᵉ fois de la soirée, après celle de l'intégration v16 elle-même) : main 14fb00a, Riemann_Lab_Test 9ad2982, Riemann_Lab_C 51205e2 — tous mergés depuis Riemann_Lab_IA, sans conflit.

État en fin de session

Code ET documentation publique (site, wiki, guides, rapport PDF) reflètent l'état v16. Aucune action restante sur ce chantier.

2026-08-16 — Incident : crash matériel isolé PC4

Constat initial

PC4 trouvé éteint au matin du 16/08, sans intervention connue. PC2 et PC3 (même prise/circuit électrique) trouvés allumés et sans interruption.

Investigation menée

1. Élimination des pistes évidentes

Piste	Vérification	Résultat
Arrêt volontaire (moi)	`doas grep 'Aug 15 2[0-3]:' /var/log/messages`	❌ Exclu — dernier reboot manuel tracé à 20:15:14 (`reboot: rebooted by hprzeta`), log continue proprement jusqu'à 20:58:52
Coupure secteur générale	`ssh zeta-calc-second/zeta-backup "last -x"`	❌ Exclu — PC2 : cycle `shutdown`/`reboot` propre 19:21-19:22 ; PC3 : idem 17:13-17:14 ; aucun `crash` cette nuit sur les deux
Panne récurrente connue	`ssh zeta-secure "last \| grep -i crash"`	❌ Exclu — 1 seul crash dans l'historique disponible, événement isolé (à comparer avec PC2 qui a 5 crashes documentés sur l'année)

2. Confirmation de la nature de l'arrêt

Au boot suivant (08:22:52), le noyau signale :

WARNING: / was not properly unmounted

Signature typique d'une coupure brutale (secteur, faux contact, alimentation) — un shutdown/halt logiciel démonte proprement le disque et ne produit pas ce warning.

3. Fenêtre temporelle du crash

Dernière ligne de log avant coupure : Aug 15 20:58:52 (fin d'un reorder_kernel après pkg_add -u)
Reprise du log au reboot suivant : Aug 16 08:22:52
Durée d'interruption : ~11h24
Confirmé par last : hprzeta ttyC1 Sat Aug 15 20:18 - crash (12:04)

4. Capteurs matériels

ssh zeta-secure "sysctl hw.sensors"

→ Vide. Chipset Intel 82845 (2002) trop ancien, aucun capteur température/tension exposé à l'OS — pas de monitoring hardware possible côté logiciel sur cette machine.

Conclusion

Cause probable : matérielle, isolée à PC4 (alimentation ATX vieillissante — 24 ans, Dell Dimension 4500 — ou faux contact spécifique à cette machine/prise), indépendante d'une coupure secteur générale puisque PC2/PC3 sur le même circuit n'ont montré aucune anomalie. Premier événement de ce type observé sur PC4 à ce jour.

ℹ️ Rappel contexte : un arrêt similaire de PC4 s'était déjà produit le 2 août 2026 (intervention du voisin pour redémarrer physiquement la machine). Ce jour-là, wtmp montrait un crash simultané sur PC3 et PC4 (wtmp begins Sun Aug 2 17:24:14 2026 identique sur les deux machines), sans crash sur PC2 — pattern différent de celui du 15/08 (PC4 seul cette fois). Les deux incidents ne semblent donc pas avoir exactement la même cause : coupure plus large le 02/08, panne isolée à PC4 le 15/08.

Actions de suivi

Surveiller la fréquence : si un 3ᵉ événement survient, forte présomption d'alimentation (PSU) ou de carte mère en fin de vie
Envisager remplacement préventif de l'alimentation ATX de PC4 (composant standard, faible coût)
Vérifier physiquement le branchement/la prise dédiée à PC4 (faux contact possible)
Pas de monitoring hardware automatisable sur cette machine (voir §4) — seule la détection zeta_monitor.py (machine down) reste disponible, sans diagnostic de cause

Commandes de diagnostic utilisées (référence)

# Vérifier les reboots manuels tracés dans une plage horaire
ssh -t zeta-secure "doas grep 'Aug 15 2[0-3]:' /var/log/messages"

# Historique des boots/arrêts sur les autres machines du cluster (Linux)
ssh zeta-calc-second "uptime && last -x | head -20"
ssh zeta-backup "uptime && last -x | head -20"

# Historique des crashes sur OpenBSD (syntaxe différente de Linux — pas de -x)
ssh zeta-secure "last | grep -i crash"

# Chercher le warning caractéristique d'un arrêt brutal
ssh -t zeta-secure "doas grep -B10 'not properly unmounted' /var/log/messages"

# Vérifier la présence de capteurs matériels
ssh zeta-secure "sysctl hw.sensors"

Voir aussi

Architecture-Cluster-Zeta — fiche PC4, historique WireGuard

2026-08-16 — Migration matérielle PC4 : Dell Dimension 4500 → Compaq CQ58

Suite au 2ᵉ crash matériel du jour (voir entrée ci-dessus), l'ancien PC4 est mis de côté et remplacé par un portable Compaq CQ58 (Celeron B830 dual-core) — même hostname zeta-secure, même IP [IP_PC4], même rôle. Détail complet (installation OpenBSD, restauration config, bugs résolus) : Migration-PC4-Compaq-CQ58-20260816.

JOURNAL.md · wiki racine · branche master · hprzeta · MAJ 2026-10-23 · 4 662 lignes

JOURNAL

Riemann_Lab — Journal de bord

2026-10-23 — Prompts Claude Code locaux (src/ia/prompts) — 9f6f501, 2c30cab, 3fdc4c1, 9f858ab, e203dcf

2026-10-16 — 22h30 — Monitoring Zêta installé et validé à blanc, zeta-script étendu aux fonctions du monitoring — commit 2de45af (4 branches à niveau)

2026-10-16 — 20h00 — V17 compute_zeros_v17.py (v17-a à d) puis turbo Zêta par SESSION — commits b4526bf (V17) et 1a9ad0c (turbo), 4 branches à niveau

2026-10-15 — 22h00 — V17 phase P0 : consolider() non destructif, tests D1-D13, rejeu T1b, Z-sign sur les 4 paires — commit c46c12b (4 branches à niveau)

2026-10-15 — 17h30 — V16 : test T1b, la déduplication à tolerance=0.01 supprime de vrais zéros (hypothèse §3.1 confirmée sur [4 900 000 ; 4 986 000]) — aucun commit

2026-10-10 — 13h45 — Boot du clone Toshiba validé (v2.3) puis zeta_backup_toshiba.sh v2.4 : garde-fou de sens et restauration inverse — commits 01bd5b7, 3681f19, bcf7f9c, b58742f, bb2b5d8

2026-10-06 — 23h59 — PDF des archives : tableaux coupés corrigés, archive du 06/10 complétée (partie B), propagation sur les 4 branches

2026-10-06 — 23h00 — Alignement des 4 branches (IA, C, main, Test) : fusions sans réécriture d'historique, gardes .gitignore reportées, site vérifié

2026-10-06 — 22h00 — Convertisseur .jsonl → .md de la transcription Claude Code, tri des fichiers non suivis terminé (groupes A à I), push de Riemann_Lab_IA et Riemann_Lab_C

2026-10-06 — 15h00 — Sauvegarde Proton validée, témoin retiré, tri des fichiers non suivis, alias SSH à bascule automatique maison/voyage — aucun commit de code

2026-09-27 — 21h30 — Chantier MCP OmniRoute clos : validation end-to-end + service systemd + doc à jour — commit 3e352a3

Voir aussi

2026-09-27 — 20h30 — Vague V2bis : ajout du skill riemann-proof-status (inspiré evomath-tao/research-state) — commit 8a2ef34

2026-09-27 — 18h00 — Vagues V1-V3 du plan de mutualisation skills/MCP (AGENTS.md, 3 nouveaux skills, mise à jour code-review/security-review) — commits df46f82, 9e0b203, 5e3a44d, 70e7463

Vague V1 (commit df46f82) — fichiers additifs

Vague V2 (commit 9e0b203) — 3 nouveaux skills

Vague V3 (commits 5e3a44d puis 70e7463 correctif) — mise à jour de 2 skills existants

État des skills sur Riemann_Lab_IA

Décisions ouvertes / reprises dormantes (voir synthese_skills_zeta.md §6, items 4-6)

Vagues restantes du plan (non lancées, en attente de validation explicite)

2026-09-13 (suite) — Sémantique MARGE_SECURITE + git blame aux jalons validés + R6 précision Arb — verrou moteur, lecture seule, non commité

1. Sémantique exacte de MARGE_SECURITE (Tâche A)

2. Git blame aux jalons validés (Tâche B)

3. R6 — précision Arb, documentation lecture seule (Tâche C)

4. Livrable et documentation

Prochaine action

Voir aussi

2026-09-13 — Audit lecture seule des recommandations IA externes (DeepSeek/Kimi/Grok) + 2 documents du LAB — matrice de 24+30 règles confrontées au code réel, non commité

1. Vérité terrain (Tâche 1)

2. Matrice d'applicabilité (24 recommandations A1-A5/R1-R15/C1-C4)

3. Extension avec les 2 documents du LAB (30 règles, blocs A-F)

4. Divergence MARGE_SECURITE — nuancée en croisant avec ce JOURNAL

5. Livrable et documentation

Prochaine action

Voir aussi

2026-09-12 — Correction rendu KaTeX sur l'ensemble du wiki (68 pages) — 4 causes racines distinctes identifiées et corrigées, 8 commits

2026-09-06 — soirée — Diagnostic définitif du déficit de zéros (test A/B + triple expertise mathématique) : ULP et enjambement GUE réfutés, cause = fragilité Riemann-Siegel à bas t, non-menace HR

Test A/B — résultat net

Verdict mathématique

⚠️ Correction — l'explication "paires enjambées" (notée depuis v13) est invalidée

Documentation mise à jour

2026-09-06 — suite — Audit cohérence site/wiki + liens cassés (.pdf/.py/.csv/.png/.svg/.md), corrections appliquées et poussées — commits 299f68e (repo) / b736969 (wiki)

Résultat de l'audit (liste présentée avant correction)

Corrections appliquées (hprzeta a validé « Tout corriger et retester »)

2026-09-06 — clôture nettoyage 16 fichiers non commités (héritage 05/09) : commit scripts + vérification secrets + purge vers secrets_local — commits 4db06de/92b346b (Riemann_Lab_C)

2026-09-05 — 20h49 — Accès distant en déplacement : fausse piste opérateur mobile, vraie cause Proton VPN, wg_auto.sh v2 — commit 23dce34

1. Neutralisation puis restauration de wg_auto.sh

2. Diagnostic IPv6 — fausse piste initiale

3. Cause racine réelle — Proton VPN

4. Correctif — wg_auto.sh v2 (garde IPv6)

5. Documentation wiki

Voir aussi

2026-09-05 — Diagnostic lecture seule run MARGE=10.0 (déjà résolu 18/08, Handoff en retard) + diff binaire réel scan_arb.c v13/v16 — piste confirmée mais partielle

1. Statut du run MARGE=10.0 segments 0-1 [14, 1 391 397] — mort, et déjà résolu

2. Diff binaire réel scan_arb.c/.so entre v13 et v16 — la piste laissée ouverte le 18/08

Prochaine action proposée (non lancée, en attente d'accord hprzeta)

Voir aussi

2026-08-30 — Écart Handoff comblé (18/08→30/08) + rangement branches (gitignore secrets + commit docs(clone)) — commits 9c72133/3b32969 (cherry-pick), .gitignore sur 4 branches

2026-08-23 — Session réseau et remise en état : IP fixe PC2/PC3, DHCP box réduit, nettoyage PC2 (CTparental, comptes hérités) — commits 9ad3f41 (wiki) / 9734011 (.gitignore, Riemann_Lab_C)

Box SFR — plage DHCP réduite

PC2 (zeta-calc-second) et PC3 (zeta-backup) — IP fixe

PC2 — désinstallation de CTparental (machine de récupération Emmaüs)

PC4 (zeta-secure) — nettoyage

Incohérence documentaire corrigée

Reste à faire (rapport source §12)

Voir aussi

2026-08-18 — 22h30 — Test A/B segments 0-1 (bas T) : PREMIÈRE différence réelle entre MARGE=2.0 et MARGE=10.0, mais qui viole la monotonie attendue

Résultat

Comparaison zéro à zéro — asymétrique, pas une simple perte

Hypothèses vérifiées et écartées

Hypothèse ouverte, non confirmée

Portée

Voir aussi

2026-08-18 — 20h00 — Analyse mathématique complète du déficit — documents analyse_math_deficit et prompts_claude, guides propagés

Vérification numérique des calculs (mpmath + dérivation analytique fermée)

Écart trouvé — l'hypothèse de clôture historique ne tient pas

Guides propagés (5 fichiers, diffs revus avant application)

Voir aussi

2026-10-16 — 22h30 — Monitoring Zêta installé et validé à blanc, `zeta-script` étendu aux fonctions du monitoring — commit `2de45af` (4 branches à niveau)

2026-10-16 — 20h00 — V17 `compute_zeros_v17.py` (v17-a à d) puis turbo Zêta par SESSION — commits `b4526bf` (V17) et `1a9ad0c` (turbo), 4 branches à niveau

2026-10-15 — 22h00 — V17 phase P0 : `consolider()` non destructif, tests D1-D13, rejeu T1b, Z-sign sur les 4 paires — commit `c46c12b` (4 branches à niveau)

2026-10-15 — 17h30 — V16 : test T1b, la déduplication à `tolerance=0.01` supprime de vrais zéros (hypothèse §3.1 confirmée sur [4 900 000 ; 4 986 000]) — aucun commit

2026-10-10 — 13h45 — Boot du clone Toshiba validé (v2.3) puis `zeta_backup_toshiba.sh` v2.4 : garde-fou de sens et restauration inverse — commits `01bd5b7`, `3681f19`, `bcf7f9c`, `b58742f`, `bb2b5d8`

2026-10-06 — 23h00 — Alignement des 4 branches (IA, C, main, Test) : fusions sans réécriture d'historique, gardes `.gitignore` reportées, site vérifié

2026-10-06 — 22h00 — Convertisseur `.jsonl` → `.md` de la transcription Claude Code, tri des fichiers non suivis terminé (groupes A à I), push de `Riemann_Lab_IA` et `Riemann_Lab_C`

2026-09-27 — 21h30 — Chantier MCP OmniRoute clos : validation end-to-end + service systemd + doc à jour — commit `3e352a3`

2026-09-27 — 20h30 — Vague V2bis : ajout du skill riemann-proof-status (inspiré evomath-tao/research-state) — commit `8a2ef34`

2026-09-27 — 18h00 — Vagues V1-V3 du plan de mutualisation skills/MCP (AGENTS.md, 3 nouveaux skills, mise à jour code-review/security-review) — commits `df46f82`, `9e0b203`, `5e3a44d`, `70e7463`

Vague V1 (commit `df46f82`) — fichiers additifs

Vague V2 (commit `9e0b203`) — 3 nouveaux skills

Vague V3 (commits `5e3a44d` puis `70e7463` correctif) — mise à jour de 2 skills existants

État des skills sur `Riemann_Lab_IA`

Décisions ouvertes / reprises dormantes (voir `synthese_skills_zeta.md` §6, items 4-6)

2026-09-06 — suite — Audit cohérence site/wiki + liens cassés (.pdf/.py/.csv/.png/.svg/.md), corrections appliquées et poussées — commits `299f68e` (repo) / `b736969` (wiki)

2026-09-06 — clôture nettoyage 16 fichiers non commités (héritage 05/09) : commit scripts + vérification secrets + purge vers `secrets_local` — commits `4db06de`/`92b346b` (Riemann_Lab_C)

2026-09-05 — 20h49 — Accès distant en déplacement : fausse piste opérateur mobile, vraie cause Proton VPN, `wg_auto.sh` v2 — commit `23dce34`

1. Neutralisation puis restauration de `wg_auto.sh`

4. Correctif — `wg_auto.sh` v2 (garde IPv6)

2026-09-05 — Diagnostic lecture seule run MARGE=10.0 (déjà résolu 18/08, Handoff en retard) + diff binaire réel `scan_arb.c` v13/v16 — piste confirmée mais partielle

1. Statut du run MARGE=10.0 segments 0-1 `[14, 1 391 397]` — mort, et déjà résolu

2. Diff binaire réel `scan_arb.c`/`.so` entre v13 et v16 — la piste laissée ouverte le 18/08

2026-08-30 — Écart Handoff comblé (18/08→30/08) + rangement branches (gitignore secrets + commit docs(clone)) — commits `9c72133`/`3b32969` (cherry-pick), `.gitignore` sur 4 branches

2026-08-23 — Session réseau et remise en état : IP fixe PC2/PC3, DHCP box réduit, nettoyage PC2 (CTparental, comptes hérités) — commits `9ad3f41` (wiki) / `9734011` (.gitignore, Riemann_Lab_C)

PC2 (`zeta-calc-second`) et PC3 (`zeta-backup`) — IP fixe

PC4 (`zeta-secure`) — nettoyage

2026-08-18 — 20h00 — Analyse mathématique complète du déficit — documents `analyse_math_deficit` et `prompts_claude`, guides propagés

2026-08-18 — 12h00 — Run T=5M v16 : résultat perdu (crash pendant rescan) — post-mortem + correctifs — commit `2f2047a`/`a391beb`

Correctifs appliqués — branche `Riemann_Lab_C`

Dashboard `zeta_run_progress.py` — bug trouvé et corrigé (non commité à ce stade)

Tâche 3 — PDF `pdf/cours/` obsolètes : 3 à régénérer, liste prête (rien lancé)

2026-08-16 — 17h41 — Backup rclone PC3→ProtonDrive réparé : jamais fonctionné depuis le 15/06, 2 causes trouvées et corrigées — commit `65e64f4`

2026-08-16 — Fusion Guide-Linux-Commandes.md (commandes session admin distante du 15/08) — commit `166b7ba`

2026-08-09 — Harmonisation des fichiers dupliqués + liens explicatifs du site (6 sous-chantiers, chantier clos) — 10 commits `Riemann_Lab_C` (`d99d7a1`→`56bd559`), wiki `dc6ede9`

Diagnostic — reconstitution via `sar` (le journal systemd est volatile, un seul boot conservé)

2026-08-02 (soir) — Cause racine des 96 manquants v13 trouvée, MARGE/κ recalibrés, cluster PC1+PC2 revalidé, run T=5M v15 distribué lancé — commits `a7fb498`·`63de0f2`·`a04ea1f`·`38c2b36`·`bbb8a6f` (Riemann_Lab_C)

2026-08-02 — fix rag_query.py — embedding forcé sur CPU (incompatibilité torch/Maxwell) — commit `e01bb1d` (Riemann_Lab_C)

Feature : rescan ciblé par déficit dans `compute_zeros_v13.py` (branche `Riemann_Lab_C`)

2026-06-22 (soir) — Correction rapport clonage (Micron vs Samsung) + WeasyPrint installé — commits `a6a6cda` · `93ad97a` (Riemann_Lab_IA)

2026-06-22 — Vault RAG Micron 1100 mis en service + convention PDF clarifiée — commit `69a55f7` wiki

Nouveaux noms (alias SSH `zeta-hp`/`zeta-acer`/`zeta-del` inchangés)