Repository navigation
Handoff
⭐ Lire en début de session. État courant + prochaine action. Historique daté →
JOURNAL.md· Outils/roadmap →STACK.md⚠️ Ce fichier était resté figé au 16 août 2026 (tout le contenu ci-dessous à partir de « Fusion Guide-Linux-Commandes.md » date de cette période ou d'avant) alors queJOURNAL.md/STACK.mdont continué d'être tenus à jour — exactement le type d'écart documenté dansJOURNAL.md(entrée 2026-09-05 : « Handoff en retard »). Le suivi actif de session vit en pratique dans~/riemann_handoff/Handoff.md(local, hors dépôt) — section « REPRISE ICI » — c'est lui qui contient le détail à jour. Resynchronisé ce jour à titre de pointeur court.Mis à jour : 16 octobre 2026 (nuit) — voir « REPRENDRE ICI — résumé au 16/10/2026 (nuit) » ci-dessous ; l'état du 15/10 (soir) est archivé juste après ; l'état du 10/10 est archivé juste après ; l'état du 06/10 (soir) est archivé juste après ; l'ancien état du 27/09 (chantier MCP OmniRoute clos, Vagues V1-V3 plan skills/MCP) est archivé en historique ci-dessous. État antérieur encore plus ancien (« 16 août 2026 (session courte, clôturée) ») — Fusion dans
Guide-Linux-Commandes.mddes commandes de la session d'administration à distance du 15/08/2026 (~/Téléchargements/Ajout-Guide-Linux-Commandes-20260815.md: SSH+doas non-interactif, syspatch/pkg_add OpenBSD, apt PC2/PC3, vérification des users du cluster, désactivation auto-login, prompt ksh PS1, aide-mémoire vi, arrêt de process par tty, extinction/reboot OpenBSD, navigation consoles virtuelles). Contenu intégré sans duplication dans les sections existantes (§4 SSH — piège TTY doas/sudo ; §6 OpenBSD — Patches/Paquets enrichis + 4 nouvelles sous-sections prompt ksh/tty/extinction/consoles) et 3 nouvelles sections créées (§23 apt PC2/PC3, §24 users cluster + auto-login, §25 vi) ; 3 lignes ajoutées au tableau « Leçons importantes apprises ». Diff vérifié avant commit (244 insertions, aucune suppression). En-tête/pied de page du guide resynchronisés (1316 lignes exactes). Commit166b7ba(wiki/master) poussé surorigin/master. Fichier temporaire supprimé après confirmation de la fusion.Session précédente (9 août 2026, clôturée) — Harmonisation des fichiers dupliqués + enrichissement du site public (liens explicatifs), colonne Analyse passée à 100% PDF SANS AUCUNE EXCEPTION, tous les liens du tableau v1→v16 vérifiés un par un, 2 erreurs factuelles corrigées (v8), ligne v6 manquante ajoutée — tableau désormais 15 lignes complètes. Recensement complet des fichiers en plusieurs copies (wiki/
docs/.claude/skills/skills_export/racine) : fusion deFormules_zeta.md(§31 v16 ajouté, manquant côté wiki), propagation des versions à jour partout, suppression de 3 fichiers orphelins (JOURNAL.mdracine — contenu unique fusionné dans le wiki avant suppression —,handoff/Handoff.mdhors-git,docs/phase-c-illinois-SKILL.mdmal placé) + 2 doublons PDF orphelins trouvés a posteriori dansdocs/pdf/(octet pour octet identiques à des fichiers déjà corrects danspdf/optimisation/, supprimés). Règle permanente ajoutée (ce fichier +STACK.md) : vérifier la synchro des copies avant de travailler dessus. Site public enrichi : colonne « Formule principale » du tableau v1→v16 rendue cliquable + nouvelle colonne « Analyse » (rapportsanalyse_problemes_vN_vN+1, 100% en PDF, 0 exception — dernière,v7→v8, résorbée par génération du PDF depuis le wiki viascripts/build_pdf_riemann_CM. sh). 3 liens morts détectés et corrigés (v2→v3, v3→v4 — pages wiki jamais créées ; colonne entière repassée en PDF sur décision hprzeta pour fiabilité). 2 erreurs factuelles trouvées et corrigées sur la ligne v8 (vérification demandée des colonnes Algorithme clé/Gain contreSTACK.md/Formules_zeta.md) : « 64→80 bits » → « 116→80 bits » (confirmé par 2 sources), Gain « — » → « ×1.06 vs v7 » (documenté mais absent du site). Ligne v6 manquante ajoutée (vérification demandée des colonnes Temps/Ver. : v4 et v11 légitimement absents — v4 défaillant, v11 jamais implémenté — mais v6 était un jalon réel et validé, déjà référencé par la ligne v7 « ×4.2 vs v6 » sans exister lui-même) — le PDFanalyse_problemes_v6_v7.pdf(pré-existant, c'est le fichier dont le doublondocs/pdf/avait été nettoyé plus tôt) sert enfin de lien Analyse. Vérification exhaustive : les 24 puis 26 liens du tableau testés individuellement — ancres wiki comparées auxhref="#..."réels de GitHub, PDF vérifiés HTTP 200 + en-têted99d7a1,b336590,16b08d1,e981a60,e1ffb58,c1519f6,467508f,9a66372,17c54cf,56bd559(Riemann_Lab_C) ·fb18bcc,e7985fb,6e61540,2457a32,f4ed0cd,e2859a1(wiki). Aucune action bloquante en cours — chantier définitivement clos.
Détail complet : suivi privé du projet (hors dépôt) · JOURNAL.md (entrée 2026-10-16 22h30). Résumé volontairement sans détail d'infrastructure.
-
Fait (commit
2de45af, 4 branches à niveau) : le dossiermonitoring/enregistre 1 mesure/s (température, fréquence, charge, RAM) des 5 machines et génère à la fin de chaque run un rapport (3 graphiques, MD + PDF). Les 5 machines répondent ; le logger et le détecteur de runs sont actifs.zeta-scriptliste désormais les 10 commandes du monitoring ;monitoring/README.mddécrit la procédure avant / pendant / après un run. - Non vérifié : la détection et le rapport sur un vrai run (chaîne seulement validée à blanc). Test prévu demain sur un run court avant tout gros run.
-
À décider : publication du reste de
monitoring/(code + page wiki « Monitoring »), sort des anciens scripts en doublon dansscripts/. -
Non commité : plusieurs fichiers de
monitoring/,.gitignore, archives de discussion,resultats_v17/.
Détail complet : suivi privé du projet (hors dépôt) · JOURNAL.md (entrée 2026-10-15 22h00). Résumé volontairement sans détail d'infrastructure.
-
Fait (commit
c46c12b, 4 branches à niveau) :consolider()non destructif (statutsDUPLICATE_CONFIRMED/DISTINCT/AMBIGUOUS, provenance et journal de décisions), tests D1-D13 + 2 compléments (16/16 PASS), rejeu T1b et Z-sign ciblé, dansscripts_v17/ettests_v17/(nouveaux fichiers ; V16 et données brutes intacts, SHA-256 vérifiés). -
Résultat T1b : 185 821 bruts → 185 810 (ancienne dédup) → 185 814 consolidés (contrôle de cohérence, pas une preuve d'exhaustivité). 7 doublons de frontière confirmés individuellement ; 4 paires rapprochées laissées
AMBIGUOUS; le Z-sign (mpmath dps 30 et 50, 2 changements de signe stables par paire) les corrobore numériquement, sans certification. -
Corrigé en revue : la règle de distinction par
$\text{STEP}$ (R-DIST1) ignorait les rayons d'incertitude (défaut révélé par D5) ; une règle R-RAYON a été ajoutée. R-DIST1 n'est pas validée comme règle générale. -
Constats :
$\text{STEP}$ dépend de$T_{max}$ seul (constant sur l'intervalle) ; le déficit de v13 est réparti en$t$ (pas concentré dans les segments 0-1) ; le dossier du run V16 à 5M est vide (valeurs rapportées non vérifiables). - À décider : phase suivante (checkpoints périodiques, journal des exceptions, contrôles Turing/LMFDB sur sous-intervalle, conservation de bracket/résidu/rayon dans les CSV) ; certification FLINT à mesurer d'abord sur quelques zéros ; docs obsolètes à corriger après validation. Rien de lourd ne se lance sans accord.
-
Non commité :
.gitignore, archivediscusion_claude_2026-10-10.*,resultats_v17/(sorties), plusieurs scripts non suivis.
Détail complet : suivi privé du projet (hors dépôt) · JOURNAL.md (entrée 2026-10-15 17h30). Résumé volontairement sans détail d'infrastructure.
- Test T1b — déduplication de v16 (hypothèse §3.1 confirmée sur un intervalle) : scan ciblé de [4 900 000 ; 4 986 000] (33 min) : 185 821 zéros bruts, 185 810 après déduplication. Sur les 11 supprimés, 7 sont des doublons artificiels (même racine trouvée par deux segments voisins) et 4 sont de vraies paires d'écarts 0,003 à 0,008, confirmées par mpmath (dps 30). Comptage Backlund : déficit +3,56 avant correction, −0,44 après.
-
Limites : un seul intervalle de 86 000 en
$t$ ;$S(T)$ non traité ; le motif observé sur v13 (9 écarts juste au-dessus de 0,01) n'est pas reproduit. La validation Turing et le score LMFDB de v16 sont des artefacts d'intervalle partiel. -
Rapport :
analyse_problemes_v16_v17mis à jour (§3.1, §4 ligne T1, §5), 232 lignes. Rien de commité. -
À faire : décider entre étendre T1 à T=5M (avec persistance) et corriger
dedupliquer()(tolérance fine limitée à la zone de recouvrement) ; tests T2 (rayon ACB) et T3 (profilage) ; ajouter une progression dans le log des runs longs ; décisions ouvertes du 10/10 ci-dessous.
Détail complet : suivi privé du projet (hors dépôt) · JOURNAL.md (entrée 2026-10-10 13h45). Résumé volontairement sans détail d'infrastructure.
-
Clone de secours bootable (v2.3) : le démarrage depuis le disque externe est validé ; le clone se répare après chaque clonage (
update-gruben chroot). Commits01bd5b7,3681f19,bcf7f9c. -
Script
zeta_backup_toshiba.shv2.4 (b58742f,bb2b5d8) : garde-fou de sens (aucune écriture sur le clone depuis le clone), restauration inverse (option 8), préparation d'un disque neuf (option 9), restauration d'un fichier ou dossier précis (option 10), option--dry-run. Clone rafraîchi le 10/10 : 8 contrôles de bootabilité sur 8 OK. -
Option 10 validée en réel (10/10, soir) : dry-run (3 éléments, aucune suppression, garde-fous OK) puis restauration réelle d'un dossier de test, sans
--delete; fichier retrouvé et relu. -
Non testé en réel / non confirmé : dry-run global et dry-run de l'option 8 (exclusion
SAP*à vérifier), option 8 réelle jamais jouée, rsync inverse complet,grub-install/efibootmgr. Aucune restauration complète sans accord explicite. -
Branches (distant, sans
--force) :Riemann_Lab_IAetRiemann_Lab_Cbb2b5d8,main1c3bf29,Riemann_Lab_Test7b59bec. - Constat : une ancienne copie (antérieure à l'exclusion) de dossiers de travail hors projet existe sur le clone ; laissée en place, documentée.
- À faire : au prochain démarrage sur le clone, dry-run global et dry-run de l'option 8 (test de l'option 10 fait) ; suppression du dossier de test après confirmation ; rotation du jeton DNS dynamique à arbitrer ; décisions ouvertes du 06/10 ci-dessous.
Détail complet : suivi privé du projet (hors dépôt) · JOURNAL.md. Résumé volontairement sans détail d'infrastructure.
-
Session du 06/10 : sauvegarde Proton de la nuit 03→04 validée (27 fichiers sur 27) et fichier témoin retiré ; tri des 36 fichiers non suivis terminé et poussé le soir même (les 26 fichiers des groupes A à I et l'archive du jour : 9 commits sur
Riemann_Lab_IA, jusqu'à06e2367, et 1 commit surRiemann_Lab_C,2084ac1; audit global avant push : 27 fichiers audités, aucun résultat) ; alias SSH à bascule automatique maison/déplacement en place et testés dans les deux sens → Guide-WireGuard-Acces-Distant §5.1–5.2. -
Convertisseur de transcription (06/10 soir) :
scripts/zeta_jsonl_to_md.py, aliaszeta-convert-jsontomd(commit35ad4e7). Il transforme la transcription que Claude Code garde automatiquement (.jsonl) en Markdown lisible : messages et réponses conservés, sorties d'outils et raisonnement interne omis, adresses, e-mails et secrets masqués, contrôle de seconde passe qui refuse d'écrire si quelque chose subsiste ; sortie en mode 600 dans un dossier ignoré par git. Testé sur 3 sessions (la plus lourde : 11 Mo → 320 Ko). Complètecapture.sh, qui n'enregistre que le terminal où il est lancé. -
Alignement des 4 branches (06/10 soir, terminé et poussé, sans
--force) :Riemann_Lab_IAetRiemann_Lab_Csont sur09a40a4,mainsurb86cf96(arbre identique à IA),Riemann_Lab_Testsur3ca0405(IA + 2 fichiers d'expérience propres à cette branche).Riemann_Lab_Cavait du code absent de IA (persistance du CSV avant le rescan, scripts de run) ; IA avait l'infrastructure, les skills et la documentation : chacune a reçu ce qui lui manquait. Les gardes.gitignoresur les dossiers de secrets, présentes seulement sur C, ont été reportées sur IA. Audit avant chaque push : aucun résultat. GitHub Pages est servi parRiemann_Lab_IA(/docs), pas parmain; la reconstruction a été vérifiée après le push. -
Génération des PDF corrigée (06/10 nuit) : le script
scripts/build_pdf_riemann_CM.sh(commit836f873) lisait le Markdown avec un lecteur qui ne gérait pas la largeur des colonnes : la dernière colonne des tableaux était coupée dans les PDF. Il utilise maintenant le lecteurmarkdownde pandoc ; comparaison avant/après sur 7 documents : aucun contenu perdu, texte restitué dans les tableaux. Les PDF déjà publiés des anciennes archives gardent le défaut tant qu'ils ne sont pas régénérés. L'archive du 06/10 est complétée (partie B, 9 pages) et poussée avec ce correctif sur les 4 branches (c1be1b8,ded1b78,ac702b3). -
Dépôts publics nettoyés : les identifiants réseau (adresses, noms de domaine dynamique, clés publiques) ont été retirés du code et du wiki, et d'une partie de l'historique, et remplacés par des marqueurs (
[IP_PC2],[DDNS_PC4]…). Les identifiants de commit ont changé : tout autre clone doit se resynchroniser. -
RAG BrainVault : réingéré le 04/10 (1258 passages, contre 838). L'embedding tourne sur le processeur ;
rag_query.pyutilise--k 4par défaut et avertit quand le prompt dépasse la fenêtre d'Ollama (4096 tokens) ; la garde de citation reconnaît les refus « non trouvé » et « pas trouvé ». Test de fumée sur 3 questions : aucune valeur inventée, mais le modèle recopie parfois un passage hors sujet. - Sauvegardes : une sauvegarde « hors git » a été mise en place (les secrets restent chiffrés et manuels).
-
Skills et conventions :
riemann-agent-bridgeetriemann-security-reviewmis à jour ; règles de collaboration ajoutées àCLAUDE.md;STACK.mdà jour. -
À faire : arbitrer la rotation du jeton DNS dynamique ; décider s'il faut masquer quelques identifiants de disque déjà publics ; régénérer les PDF des anciennes archives avec le script corrigé et examiner l'échec de génération d'un guide ; régénérer le plan de continuité (contenu périmé) et lever la divergence de matériel entre les schémas et
STACK.md; nettoyer les sauvegardes temporaires, documenter le stockage et l'ajout d'un nouveau poste.
Détail complet : ~/riemann_handoff/Handoff.md (section REPRISE, entrée du soir) ·
JOURNAL.md (entrée 2026-09-27 21h30).
3 correctifs (Node 22 explicite, patch stdout console.debug→console.error,
ensureDbInitialized() au démarrage MCP) validés end-to-end via une vraie connexion
MCP de Claude Code. Backend HTTP OmniRoute (port 20128, indispensable même pour les vrais
appels de chat completion, pas seulement le monitoring) mis en service systemd --user
durable (~/.config/systemd/user/omniroute.service, créé manuellement — l'outil Write de
Claude Code est bloqué sur ce type de fichier par le classificateur de permission). Test
réel réussi : omniroute_route_request vers nvidia/nemotron-3-super-120b-a12b, réponse
correcte sur zeta(2) = π²/6. Documentation mise à jour et commitée sur Riemann_Lab_IA
(3e352a3, poussé) : riemann-agent-bridge/SKILL.md §1bis + .mcp.json.example.
Résiduel non bloquant : 403 AUTH_001 Invalid management token sur
get_health/check_quota/list_models_catalog (token de gestion à régénérer via le
dashboard OmniRoute si besoin de ces outils précis) ; provider aimlapi/DeepSeek non
configuré (non prioritaire, contourné avec NVIDIA).
Rien en attente sur ce chantier précis. Reprise possible côté riemann-agent-bridge (test
Codex/Ollama réel) si besoin.
📍 Historique — Vagues V1-V3 plan de mutualisation skills/MCP (27/09/2026, plus tôt), 6 points en attente avant V4/V5
Détail complet : ~/riemann_handoff/Handoff.md (section REPRISE, entrée 27/09/2026) ·
JOURNAL.md (entrée 2026-09-27) · document source synthese_skills_zeta.md (projet
claude.ai « SKILLS ZETA », copie possible pdf/audits_skills/).
4 commits sur Riemann_Lab_IA (df46f82, 9e0b203, 5e3a44d, 70e7463) : V1 = AGENTS.md
-
.mcp.json.example+handoff/(protocole Claude Code/Codex/Ollama) ; V2 = 3 nouveaux skills (riemann-agent-bridge,riemann-literature-scout,riemann-statistics-gue) ; V3 = mise à jourriemann-code-review(§8, cache RSlog_n_cache/isqrt_n_cacheconfirmé actif v13/prod) etriemann-security-review(§8, sécurité MCP). 7 skills au total, rien supprimé, cœur de calcul non touché. 6 points en attente d'arbitrage hprzeta : réingestion RAG BrainVault, « cerveau autonome zêta », anomalie 63 zéros MARGE 10.0 vs 2.0, puis Vagues V4 (tests/CI) et V5 (réorganisationphase-c-illinois/CLAUDE.md/scripts) — aucune des deux sans confirmation explicite préalable.
Attendre l'arbitrage de hprzeta sur les 6 points ci-dessus avant de lancer V4 ou V5. Le gate
empirique T=100k MARGE_SECURITE (résumé archivé ci-dessous) reste par ailleurs toujours en
attente, indépendamment de ce chantier skills.
🗄️ Historique — Sémantique MARGE_SECURITE + git blame + R6 précision (13/09/2026, suite), gate T=100k pas encore lancé
Détail complet : ~/riemann_handoff/Handoff.md (section REPRISE, entrée 13/09/2026
suite) · JOURNAL.md (entrée 2026-09-13 suite) · rapport source
rapports/marge_securite_et_precision_2026-09-12.md (dépôt de code, branche
Riemann_Lab_C, non commité).
Investigation lecture seule (verrou moteur durci — aucune constante de calibration ni
fichier du cœur de calcul modifié) confrontant MARGE_SECURITE à son historique git. 10.0
est la seule valeur avec une trace de validation empirique (bbb8a6f→00abe5c, 0
manquant sur 3 zones + pivot réel PC1+PC2, puis v16 prod T=100k Turing COMPLET/LMFDB 20/20).
3.0 a été testée spécifiquement et trouvée insuffisante (a04ea1f, T≈4,86M) — la
croyance « 3.0 = validé » (CLAUDE.md racine + les 2 documents du LAB, cf. audit ci-dessous)
est donc contredite par git lui-même, pas seulement périmée. R6 : précision Arb fixe 64
bits documentée, écart max mesuré 1,455e-11 en production (t=10⁵). Le document ne tranche
pas 3.0 vs 10.0 — un gate empirique T=100k reste à lancer pour objectiver le surcoût
réel avant tout rerun T=5M.
Lancer le gate empirique T=100k (prompt dédié, pas encore fourni par hprzeta) pour comparer
concrètement le coût de MARGE_SECURITE=10.0 avant toute décision sur le rerun T=5M. Les 5
actions de l'audit du 12-13/09 (section ci-dessous) restent par ailleurs en attente,
notamment corriger la doc MARGE_SECURITE une fois la valeur de référence confirmée par ce
gate.
Audit lecture seule (aucune écriture de code, aucun commit) confrontant au code réel de
compute_zeros_v16.py les recommandations de 3 IA externes (DeepSeek/Kimi/Grok) puis de 2
documents complémentaires du LAB (Recommandations_LAB_et_prompt.md,
Formation_Zeta_HR_Riemann_Lab.pdf). Pipeline de production confirmé = compute_zeros_v16.py
(Hardy Z/Arb, Turing-Backlund loggé, N(T) correct). Matrice de 24+30 règles : la plupart déjà
faites ou hors périmètre étape 1 ; principale découverte = MARGE_SECURITE=3.0 encore
documenté (CLAUDE.md racine + les 2 nouveaux documents) alors que 10.0 est la valeur
active dans le code — dette de documentation, pas un risque de calcul actif (le
diagnostic du déficit de zéros n'en dépend plus depuis le 06/09, voir plus bas).
- R4 — journal de calibration complet (exposer
MARGE_SECURITEdans le log/CSV v16). - Corriger la doc
MARGE_SECURITE(CLAUDE.md racine + les 2 documents externes, dont le prompt « prêt à coller » qui réinjecterait3.0s'il est réutilisé tel quel). - Script de validation échantillonnée R1 (équation fonctionnelle, dps=30, N points).
- Rerun T=5M avec Turing complet + rapport de recoupement (R2+R8), à articuler avec le test discriminant N vs R(t) du chantier déficit (voir plus bas, section 06/09).
- Nettoyer
T_SEUIL_ILLINOIS_C=300(CLAUDE.md racine, obsolète depuis v12) et legit add -Arésiduel dansscripts/push_phase0_complete.sh:36.
v17 — Odlyzko-Schönhage (long terme, non commencé, voir STACK.md) ; Anthropic Skilljar
(Claude Code 101 → MCP → Subagents → Agent Skills, non commencé) ; régénération clé
WireGuard PC4 + token DuckDNS (action hprzeta hors Claude Code, en attente de longue date).
-
06/09/2026 — Diagnostic définitif du déficit de zéros T=5M, chantier clos côté
diagnostic. L'explication historique « paires de zéros enjambées par la grille »
(répétée depuis v13, y compris dans les entrées historiques ci-dessous et l'ancien
STACK.md) est invalidée (test A/B + triple expertise mathématique,$M_1\approx0{,}08$ attendu contre 96-177 observés). Cause retenue : fragilité de Riemann-Siegel tronquée à bas$t$ ($N=\lfloor\sqrt{t/2\pi}\rfloor$ petit). Non-menace pour l'HR. Reste ouvert : test discriminant canal$N$ vs canal$R(t)$ (léger, non exécuté), v17 (long terme). Détail :JOURNAL.md2026-09-06,Formules_zeta.md§33. -
05/09/2026 — Accès distant en déplacement : cause = Proton VPN (bloque l'IPv6
nécessaire à WireGuard), pas l'opérateur mobile ;
wg_auto.shv2. -
12/09/2026 — Rendu KaTeX cassé sur tout le wiki (68 pages) : 4 causes racines
identifiées et corrigées, 8 commits, règle permanente ajoutée à
STACK.md. - 23/08/2026 — Session réseau : IP fixe PC2/PC3, nettoyage PC2.
-
16-18/08/2026 — Crash matériel isolé PC4 → migration vers Compaq CQ58 (même
hostname/IP/rôle
zeta-secure) ; pipeline backup rclone PC3→ProtonDrive réparé ; investigation intensive du déficit de zéros (invalidation initiale de « paires enjambées », confirmée définitivement le 06/09) — détail dans les sections historiques ci-dessous.
- Lu
~/Téléchargements/Ajout-Guide-Linux-Commandes-20260815.md(10 sous-thèmes issus d'une session d'administration à distance du 15/08/2026 : SSH+doas piège TTY, OpenBSD syspatch/pkg_add, apt PC2/PC3, users cluster vshprzeta, désactivation auto-login, prompt ksh PS1, aide-mémoire vi,pkill -tpar console,shutdown -p/rebootOpenBSD, consoles virtuelles) et leGuide-Linux-Commandes.mdactuel du wiki. -
Fusionné sans duplication dans les sections existantes appropriées :
- §4 SSH : nouvelle sous-section « SSH à distance avec doas/sudo — piège du
TTY » (
ssh -tobligatoire, piègessh doas host "..."interprété comme hostname). - §6 OpenBSD : enrichi « Droits et sudo » (renvoi croisé vers §4), « Patches de
sécurité » (
syspatch -lhistorique, distinction avec-c), « Paquets » (pkg_add -u -ndry-run,pkg_add -u) ; 4 nouvelles sous-sections ajoutées en fin de §6 : Prompt ksh (PS1, piège apostrophe AZERTY), Arrêter un process lié à une console (pkill -t ttyC0), Extinction/redémarrage propre (piège pile CMOS morte PC3/PC4), Consoles virtuelles. - Tableau « Leçons importantes apprises » : 3 nouvelles lignes (doas/hostname, apostrophe AZERTY, CMOS morte).
- §4 SSH : nouvelle sous-section « SSH à distance avec doas/sudo — piège du
TTY » (
-
3 nouvelles sections numérotées créées en fin de guide : §23 (apt — mise à
jour à distance PC2/PC3), §24 (Cluster — users locaux vs
hprzeta, désactivation auto-login), §25 (vi — aide-mémoire minimal). - Aucun contenu existant supprimé, format du guide conservé (blocs bash,
tableaux, notes
⚠️ /💡). - En-tête et pied de page du guide resynchronisés : MAJ 2026-08-15, 1316
lignes (recompté via
wc -laprès fusion). - Diff vérifié avant commit (
git diff --stat→ 244 insertions, 2 lignes modifiées, 0 suppression). - Commit
166b7ba(« docs(guide-linux): fusion commandes session 15/08 »), poussé surorigin/master(dépôt wiki, pas le dépôt de code). - Fichier temporaire
~/Téléchargements/Ajout-Guide-Linux-Commandes-20260815.mdsupprimé après confirmation de la fusion.
Aucune sur ce chantier — clos. Reprises possibles (inchangées depuis la session
précédente) : décision sur la suite du run T=5M v15 (voir chantier
« Run T=5M v15 arrêté » ci-dessous), v17 — Odlyzko-Schönhage (piste long terme,
non commencée, voir STACK.md), ou Anthropic Skilljar (Claude Code 101 → MCP
intro/avancé → Subagents → Agent Skills, pas commencé).
-
Recensement des fichiers dupliqués dans tout le projet (pas seulement
Formules_zeta.md/Bibliotheques.md) : wiki,docs/,.claude/skills/riemann-lab/ references/,skills_export/,pdf/optimisation/, racine repo. 12 groupes de doublons identifiés, dont 3 orphelins (à supprimer) et 2 brouillons distincts (renommés plutôt que fusionnés à tort). -
Fusion
Formules_zeta.md: le wiki avait l'historique complet §18→§30 mais pas la section v16 ; ajout du §31 (acb_dirichlet_hardy_zprécision fixe), puis propagation de la version fusionnée versdocs/,.claude/skills/,skills_export/.Bibliotheques.mdétait déjà à jour côté wiki (§18 v16 présent) → simple propagation. -
Suppressions (après vérification qu'aucun contenu unique n'était perdu) :
JOURNAL.mdracine (la seule section absente du wiki — diagnostic pipeline v4.1 du 03/06 — a été réintégrée dansRiemann_Lab.wiki/JOURNAL.mdavant suppression, conformément à la règle CLAUDE.md « JOURNAL.md vit uniquement dans le wiki ») ;handoff/Handoff.md(orphelin hors-git, périmé depuis le 13/06, le canonique est~/riemann_handoff/Handoff.md) ;docs/phase-c-illinois-SKILL.md(skill mal placé dans le dossier du site public, périmé). -
Règle permanente « fichiers dupliqués » ajoutée dans ce fichier (§ Contraintes
actives, ci-dessous) et dans
STACK.md(§ Contexte général). -
Site public (
docs/index.html) — tableau de progression v1→v16 :- Colonne « Formule principale » : chaque terme clé (Z(t), Illinois bracket,
N(T),
arb_fpwrap, cache RS,SEUIL_1NEWTON,acb_dirichlet_hardy_z, etc.) est désormais un lien discret (.formula-link, soulignement pointillé) vers la section pertinente deFormules_zeta.mdouBibliotheques.mdsur le wiki public — 14 liens, ancres vérifiées une par une en direct (pas devinées). - Nouvelle colonne « Analyse » : lien vers le rapport
analyse_problemes_vN_ vN+1correspondant à la transition depuis chaque version, quand il existe (10 liens) ; « — » sinon, pas de lien mort inventé (v1→v2, v12→v13, v14→v15, v15→v16 sans rapport dédié).v13pointe versanalyse_problemes_v13_v15(couvre aussi v14).v16pointe vers le rapport de synthèse globalv1_v16.
- Colonne « Formule principale » : chaque terme clé (Z(t), Illinois bracket,
N(T),
-
Bug détecté par hprzeta puis corrigé : les liens v2→v3 et v3→v4 pointaient vers
des pages wiki (
analyse_problemes_v2_v3_phase0,analyse_problemes_v3_v4) qui n'ont jamais existé sur le wiki (uniquement en PDF danspdf/optimisation/, confirmé viagit ls-tree origin/master). GitHub redirige silencieusement une page wiki inexistante vers la page Home (HTTP 200, pas d'erreur visible) — piège détecté en comparant le<title>de chaque page testée à celui d'une page témoin délibérément inexistante. Remplacés par des liens directs vers les PDF sur GitHub (dépôt public,blob/main/pdf/optimisation/..., testés HTTP 200). Les 8 autres liens de la colonne Analyse ont été testés un par un et confirmés valides. -
Synchronisation des 4 branches + wiki, vérifiée en ligne (1er cycle) :
Riemann_Lab_C(d99d7a1→e1ffb58, 5 commits) poussé, puis fast-forward versRiemann_Lab_IA(591033d..e1ffb58), merge propre versmain(14fb00a..ef488c9), merge propre versRiemann_Lab_Test(9ad2982..494bb3d) — aucun conflit sur les 3 merges. Wiki poussé séparément (fb18bcc,master). Build GitHub Pages suivi jusqu'àstatus: builtpuis site public re-fetché en direct pour confirmer la présence réelle de la colonne Analyse (14formula-link+ 10analyse-linkcomptés dans le HTML servi). -
Changement de stratégie « colonne Analyse » demandé par hprzeta (même session,
après retour terrain sur le lien mort v2→v3) : uniquement des liens PDF, plus de
liens wiki, pour fiabilité — un lien wiki peut sembler exister alors que GitHub
redirige silencieusement vers Home. Vérification préalable : les PDF ne sont
accessibles publiquement que via le dépôt GitHub public (
pdf/optimisation/, poussé sur les 4 branches) — pas de lien Proton Drive public (Proton Drive = backup privércloneuniquement), pas de copie systématique dansdocs/. 9 des 10 rapports liés existent en PDF → migrés versgithub.com/.../blob/main/pdf/optimisation/ NOM.pdf, chacun testé individuellement (HTTP 200, en-tête%PDF, taille en octets identique au fichier local). Exception :v7→v8n'existe qu'en page wiki (jamais généré en PDF) — flaggé avant d'agir, hprzeta a tranché : garder le lien wiki pour ce seul cas plutôt que supprimer l'info ou en générer un artificiellement. -
Synchronisation des 4 branches + wiki, vérifiée en ligne (2ᵉ cycle) :
Riemann_Lab_C(c1519f6) → fast-forwardRiemann_Lab_IA(e1ffb58..c1519f6) → mergemain(ef488c9..a6984f2) → mergeRiemann_Lab_Test(494bb3d..6c4809f), aucun conflit. Build GitHub Pages suivi jusqu'àstatus: built(commitc1519f6) puis site re-fetché : 9 liens PDF confirmés présents, seulv7→v8reste en wiki. -
Vérification des liens depuis
Formules_zeta/Bibliotheques(demande hprzeta) : les 16 ancres de la colonne Formule principale comparées directement auxhref="#..."réels générés par GitHub sur les deux pages (pas seulement "la page existe"). Piège méthodologique repéré et évité : les vraisidHTML portent un préfixeuser-content-que GitHub résout côté client — chercher unidsans ce préfixe donne un faux négatif. Les 16 ancres confirmées exactes. -
2 doublons orphelins trouvés dans
docs/pdf/(hprzeta a signalé une fausse alerte de "PDF manquants" ; vérification MD5 a montré quedocs/pdf/analyse_v6_v7. pdfetdocs/pdf/analyse_v8_v9.pdfétaient des copies octet pour octet identiques à des fichiers déjà présents et déjà utilisés sous le bon nom danspdf/optimisation/—v8→v9n'avait jamais été cassé, etv6→v7n'a pas de ligne dans le tableau). Doublon manqué au recensement initial du Chantier 1 — supprimés (docs/pdf/maintenant vide et retiré). Commit467508f, 3ᵉ cycle de sync 4 branches (a6984f2..a2b68eamain,6c4809f..99100abTest). -
Génération de
analyse_problemes_v7_v8.pdf(demande explicite hprzeta — convertir le wiki plutôt que garder l'exception) :scripts/build_pdf_riemann_CM. sh(LuaTeX + Computer Modern, moteur identique aux 9 autres rapports, confirmé viapdfinfo Producer). Piège rencontré : un caractère→dans un span de code inline (`prec_fast=64 bits → 1 limbe`) faisait planter LuaLaTeX (\lstinlinene gère pas les flèches Unicode en mode verbatim) — corrigé en->uniquement dans une copie temporaire utilisée pour la conversion, source wiki non modifiée. PDF placé danspdf/optimisation/(pasdocs/, cohérent avec les 9 autres), lien basculé du wiki vers ce PDF. Colonne Analyse : 100% PDF, 0 exception restante. Commit9a66372, 4ᵉ cycle de sync 4 branches (a2b68ea..5df1c27main,99100ab..d49fc89Test). -
Vérification exhaustive finale (demande hprzeta, ligne par ligne v1→v16) :
les 24 liens du tableau (14 Formule principale + 10 Analyse) testés
individuellement — ancres wiki vérifiées par comparaison exacte aux
href="#..."de GitHub, PDF vérifiés HTTP 200 + en-tête%PDF+ taille en octets exacte. Aucun lien mort restant. -
Vérification des colonnes Algorithme clé / Gain (demande hprzeta) contre
STACK.md(table Progression T=100k) etFormules_zeta.md§24 : 13/14 lignes exactes, 2 erreurs trouvées sur v8 — Algorithme clé disait « 64→80 bits » au lieu de « 116→80 bits » (confirmé parFormules_zeta.md:1369ETSTACK.md:391, même formulation « ×1.06 vs 116 bits ») ; Gain affichait « — » alors queSTACK.md:391documente explicitement « ×1.06 vs v7 » (aucune raison de le masquer, v10/v13 affichent des gains tout aussi faibles). Corrigé sur confirmation hprzeta. Commit17c54cf, 5ᵉ cycle de sync 4 branches (5df1c27..43bd611main,d49fc89..7bec9deTest). -
Vérification des colonnes Temps / Ver. (demande hprzeta) : Temps 14/14
exactes (recoupement zéros÷durée pour v7-v16, confirmation croisée 4 sources
indépendantes pour v15/v16 — 517 z/s et 1407 z/s exacts, pas de simple arrondi).
Ver. : 3 versions absentes du tableau —
v4(défaillant, 5 erreurs architecturales documentées, immédiatement remplacé par v4.1 : exclusion légitime) etv11(aucune trace nulle part dans le wiki — planifié « cache scan→Brent » mais jamais implémenté, directement remplacé par v12 : exclusion légitime) sont des exclusions justifiées ; maisv6était un jalon réel et validé (STACK.md:389— 130 min, 138 069 zéros, 0 manquant ✅, commitb676e88, même lignée que v7/v8 selonSTACK.md:227) — révélé par le fait que la ligne v7 référence déjà « ×4.2 vs v6 » sans que v6 existe dans le tableau. Ligne v6 ajoutée entre v5 et v7 (sur confirmation hprzeta), lien Formule principale versFormules_zeta§23 (STEP adaptatif, seule section documentantSTEP=0.010), lien Analyse verspdf/optimisation/ analyse_problemes_v6_v7.pdf— le fichier même dont le doublondocs/pdf/avait été nettoyé plus tôt dans la session, jamais utilisé jusqu'ici faute de ligne v6. Testé HTTP 200 +%PDF+ taille exacte. Tableau désormais 15 lignes. Commit56bd559, 6ᵉ cycle de sync 4 branches (43bd611..e984349main,7bec9de..c59d7ceTest).
Aucune sur ce chantier — clos, code ET site public à jour et vérifiés en ligne.
Reprises possibles : décision T=5M v15 (toujours ouverte, voir chantier ci-dessous,
accélérée par v16 si repris), ou v17 — Odlyzko-Schönhage (piste long terme, non
commencée, voir STACK.md).
-
perf recordréel surillinois_refine_arb(300 brackets représentatifs, 2 zones t~[500,5000] 2-Newton / t~[50000,150000] 1-Newton, 85 232 échantillons @4000Hz) : 91% du temps dans GMP+FLINT (viaarb_fpwrap_cdouble_hardy_z, Phase 2), dont__gmpn_mul_basecase_coreisbrseul à 16,67%, ~3,5% cumulés dans le bookkeeping des bornes d'erreur Arb (mag_add/mag_div/mag_mul/mag_set_ui). Notre propre code (illinois_arb.so, Phase 1 cache RS) ne coûte que 0,20% — confirmation chiffrée que l'architecture 2-phases est bien conçue. -
Comparaison
illinois_refine_arb(Arb/FLINT) vsillinois_refine(MPFR pur, 170 bits) sur les mêmes 300 brackets : Arb 11,88× plus rapide (2,95 ms/appel vs 35,05 ms/appel) ET ~4 ordres de grandeur plus précis (erreur 4,6e-11 vs 9,5e-5 vs mpmath dps=35 — biais structurel de la RS tronquée en MPFR pur, même à haute précision). → Piste "MPFR pur" écartée définitivement, ne pas la re-proposer. - Outils commités (
Riemann_Lab_C, commit4df0738) :c_modules/gen_brackets.py,c_modules/perf_harness.py,c_modules/compare_arb_vs_mpfr.py,c_modules/brackets.json(300 brackets réutilisables). -
Piste multi-IA (DeepSeek/Claude/Kimi via API) abandonnée :
scripts/multi_ia_query.pycréé (commitd4a1d15) puis testé — Claude/Kimi sans clé configurée, DeepSeek en échec402 Insufficient Balancemême après rechargement du compte. Décision hprzeta : coût en crédit API non justifié pour l'usage actuel. Script +.envretirés (commitdcffa49, aucune clé n'a jamais été commitée — historique git vérifié propre).
Investigation menée directement dans une session claude.ai (pas d'API tierce, conforme à la décision d'abandon multi-IA ci-dessus) :
-
Mécanisme réel de
arb_fpwrap_cdouble_hardy_zconfirmé depuis le code source FLINT (src/arb_fpwrap/fpwrap.c, version exacte de la.soruntime identifiée : FLINT 3.3.1 via le symboleflint_version) : boucle d'escaladewp=64puis doublement (64→128→256→…→8192 bits max avecflags=0), recalcul COMPLET à chaque niveau, jusqu'à certifier une précision ~1e-16 (accuracy « double complet ») — largement plus que notre besoin réel (tolérance 1e-12, ~40 bits).flags=0(déjà utilisé en production) est la variante la MOINS chère de l'APIfpwrap— aucun gain possible en jouant surflagsseul, cette piste précise est une impasse confirmée. -
Levier réel identifié et testé : fonction bas niveau
acb_dirichlet_hardy_z(res, t, G, chi, len, prec)— précision fixe explicite, UN SEUL calcul, pas d'escalade. Nécessitedirichlet_group_t/dirichlet_char_t(init une fois par worker, q=1 = caractère principal = zêta pure, pattern confirmé sur le test officiel FLINTacb_dirichlet/test/t-hardy_z.c). -
Headers FLINT 3.3.1 vendorisés (
c_modules/flint-headers-3.3.1/, commit95ea6ff, Riemann_Lab_C) — 23 headers (276 Ko) extraits par fermeture transitive réelle (gcc -M), PAS viaapt(libflint-devsystème = 3.0.1, ABI incompatible avec la.soruntime 3.3.1 pourdirichlet_group_t/dirichlet_char_t, types activement modifiés entre versions FLINT — risque de corruption mémoire silencieuse). -
Prototype
illinois_refine_arb_lowprecécrit et testé (scratchpad de session, PAS ENCORE dans le repo — en attente de la décision de précision ci-dessous) : même architecture 2-phases que la production, Phase 2 utiliseacb_dirichlet_hardy_zà précision fixe au lieu dearb_fpwrap. Balayage sur les 300 brackets (c_modules/ brackets.json) :precision ms/appel gain vs production écart vs production 24 bits 0,254 11,95× dégradé (3,1e-09) 32 bits 0,284 10,69× dégradé (1,0e-12) 40 bits 0,330 9,20× dégradé (2,3e-15) 48 bits 0,345 8,82× 0,000 — identique bit-à-bit 53 bits 0,426 7,14× identique 64 bits 0,529 5,75× identique 128 bits 2,518 1,21× identique À partir de 48 bits, résultat rigoureusement identique à la production sur les 300 brackets synthétiques (t~500-150000).
Décision hprzeta (08/08 soir) : précision retenue = 64 bits (coïncide avec
WP_INITIAL de arb_fpwrap lui-même — marge ~7 décimales au-dessus du besoin théorique
~40 bits pour tol=1e-12, contre ~2,4 décimales à 48 bits ; le delta de gain ×8,82 vs
×5,75 jugé secondaire face au risque d'un cas limite non couvert par les 300 brackets
testés).
Plan exécuté intégralement, illinois_arb.c/illinois_arb.so/compute_zeros_v15.py de
production non modifiés (git status vérifié vide sur ces 3 fichiers) :
-
Nouveaux fichiers isolés :
c_modules/illinois_arb_lowprec.c(+.so, précision en paramètre runtime) etcompute_zeros_v15_test_lowprec.py(copie quasi à l'identique du worker de production, diff minimal marqué### LOWPREC ###, précision fixée à 64 bits). -
Smoke test T=1000 puis run réel T=10000 (workflow turbo standard,
zeta_turbo_on.sh/off.sh— sudoers NOPASSWD, aucune intervention manuelle requise), et run de production T=10000 en comparaison directe (mêmes segments, même STEP,compute_zeros_v15.pyinvoqué tel quel via--t-min/--t-max, pas modifié) :Production ( arb_fpwrap)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 total 20,2 s 10,2 s Vitesse 501,12 z/s 992,13 z/s Gain bout-en-bout — ×1,98 Écart avec le ×5,75 mesuré sur les 300 brackets isolés : la phase Illinois (
arb_C) ne représente que 76,9 % du temps mur total du run réel (profil détaillé production : 124,44s cumulés / 10 130 appels = 12,28 ms/appel) — le reste (détectionscan_arb, petits t, Turing, overhead multiprocessing) est identique entre les deux runs et ne bénéficie pas de l'optimisation. ×1,98 est le chiffre honnête à retenir pour Objectif 2 (pas le ×5,75, qui isolait artificiellement la seule phase Illinois).
Décision : oui, intégrer, en suivant le protocole de validation standard du projet (même exigence que v12→v15 : T=100k COMPLET + LMFDB 20/20 avant d'adopter une version).
-
illinois_arb.cmodifié en place (convention du projet — v12→v15 déjà toutes dans ce fichier) :Z_arbréécrit avecacb_dirichlet_hardy_z+dirichlet_group_t/chitrivial (init statique par worker), précision fixe 64 bits. -
Makefile:-I flint-headers-3.3.1ajouté à la cibleillinois_arb.so. -
compute_zeros_v16.pycréé (nouveau fichier, convention du projet — un fichier par version), copie de v15 avec docstring mis à jour. -
Revalidé à T=100000 (le vrai protocole d'acceptation Objectif 2, au-delà du T=10000 du prototype) :
v15 (référence) v16 (intégré) Zéros trouvés 138 069 138 069 / 138 069 (exact, 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 réel à T=100k : ×2,75 (supérieur au ×1,98 mesuré à T=10000 — la phase Illinois pèse une part croissante du temps mur à mesure que T augmente). Objectif 2 (T=100k < 5 min) largement dépassé : 1,6 min.
-
Commit
00abe5c(Riemann_Lab_C, illinois_arb.c + Makefile + compute_zeros_v16.py),STACK.md+ skills (phase-c-illinois,riemann-lab) mis à jour et synchronisés (règle de double mise à jour,c_modules/CLAUDE.md). -
Fichiers de prototype (
compute_zeros_v15_test_lowprec.py,illinois_arb_lowprec.c/.so, commiteea9d9f) conservés comme trace de la validation isolée, désormais historiques.
Suite à l'intégration, demande hprzeta de mettre à jour toute la documentation publique/externe (pas seulement le code et le wiki interne) :
-
Site GitHub Pages (
docs/index.html,Riemann_Lab_IA) : tous les chiffres v15 remplacés par v16 (badge hero, tableau T=100k, 5 cartes stats, grille progression v1→v16, tableau algorithme détaillé, 3 cartes de synthèse, vitesse cluster PC1, footer) — vérifié qu'aucune mention orpheline de « version actuelle = v15 » ne subsiste (seules les lignes historiques v15 dans les tableaux, correctement attribuées, restent). -
Guides wiki :
Guide-Linux-Commandes.md§21 (perf record/report— sudo paranoid=4, piège segfaultctypes.c_char_pvschar[]) et §22 (compiler FLINT depuis les sources —./configure, dépendancem4, extraction headers minimale viagcc -M).Bonnes-Pratiques-Claude-Code.md: nouvelle section « Workflow de validation avant intégration production » (isolation stricte → run réel modeste → décision explicite → intégration convention projet → revalidation protocole standard) — capture la méthode suivie pour v16 comme pratique réutilisable. -
Bibliotheques.md(page wiki publique, distincte de la copie skill) §18 : mécanismearb_fpwrapdocumenté en détail,acb_dirichlet_hardy_z, nouvelle dépendance headers FLINT vendorisés, choix de précision, résultats. -
Rapport de synthèse
analyse_problemes_v1_v16.md+ PDF (8 pages, généré viascripts/build_pdf_riemann.sh, format aligné sur les rapports précédents) : trajectoire complète v1→v16 (chaque transition majeure résumée, v15→v16 développée en détail), tableau récapitulatif global, section Questions ouvertes. Poussé sur Proton Drive (protondrive:hprzeta/Riemann_Lab/backup/pdf/optimisation/, même emplacement que les rapports précédents). - Commits :
591033d(Riemann_Lab_IA— site + PDF),2bc997c(wiki — guides + Bibliotheques + rapport source). 4 branches re-synchronisées une seconde fois ce soir (après l'intégration v16, puis après cette publication) —main14fb00a,Riemann_Lab_Test9ad2982,Riemann_Lab_C51205e2, toutes à jour avecRiemann_Lab_IA.
Prochaine action prioritaire : aucune sur ce chantier — clos, code ET
documentation publique à jour. Reprises possibles : décision T=5M (toujours ouverte,
voir ci-dessous, désormais accélérée par v16), ou v17 — Odlyzko-Schönhage (piste
long terme, non commencée, voir STACK.md).
Distinct de la piste d'optimisation ci-dessus — pas introduit par ce travail, préexistant dans la production actuelle. Confirmé SANS IMPACT sur le pipeline réel (voir résolution en bas de section).
En validant le prototype illinois_refine_arb_lowprec contre test_illinois_arb.py
(20 premiers zéros LMFDB, tolérance 1e-8), découverte que la production
illinois_arb.so elle-même obtient 17/20, pas 20/20 comme l'affirme le docstring du
test et la documentation de session antérieure. Les 3 échecs (t=14,13 / 21,02 /
25,01, erreurs 2,8e-08 à 7,0e-08) sont exactement les zéros à t < 300 — cohérent
avec le seuil déjà documenté T_SEUIL_ILLINOIS_C = 300.0 (RS a besoin de N≥7 termes,
fallback mpmath légitime en dessous, cf. CLAUDE.md racine).
Confirmation que ce n'est pas un bug introduit aujourd'hui : illinois_refine_arb_lowprec
(prototype) reproduit ces 3 échecs à l'identique bit-à-bit avec illinois_refine_arb
(production) — les deux implémentations sont rigoureusement équivalentes sur ce test.
✅ Résolu (08/08 soir, run T=1000 puis T=10000) : compute_zeros_v15.py route bien
t < T_SEUIL_PETIT_T = 65.0 via un chemin séparé (arb_hardy_z + mpmath.fp.findroot,
pas illinois_refine_arb) — confirmé par les runs réels : LMFDB 20/20 < 1e-9 à
chaque fois (T=1000 et T=10000), y compris les 3 zéros t<300 qui échouaient en appel
isolé. Le 17/20 de test_illinois_arb.py est donc bien un faux problème du test
isolé (il appelle illinois_refine_arb directement sur des brackets t<65, un chemin
que le pipeline réel n'emprunte jamais) — pas une régression de production. Sujet classé,
aucune action requise. Le docstring de test_illinois_arb.py reste néanmoins inexact
(affirme 20/20) — correction mineure possible mais non prioritaire.
Le run relancé le 04/08 22:48 (PID racine 32270) a été tué manuellement par
hprzeta le 06/08, après 23h20 sans la moindre ligne de progression côté PC2
(aucune ETA fiable n'a jamais pu être établie malgré plusieurs tentatives d'estimation
— cf. JOURNAL.md entrée 04-06/08 pour le détail complet du diagnostic).
-
PC1 : COMPLET et sauvegardé, indépendamment de l'arrêt de PC2 —
calculs/v15_T14_3469744_20260804_224851/zeros_v15_T3469744_20260804_224851.csv(670 Mo, 6 749 092 zéros sur[14, 3469743.76], attendu N≈6 749 158). Les 8 workers ont fini entre 6h17 et 11h49, aucune erreur. -
PC2 : tué à la main (
pkill -f compute_zeros_v15via SSH) — ~23h20 de calcul perdues, non récupérables (aucun résultat partiel n'était sur disque). Confirmé sain avant l'arrêt (CPU actif en continu, RAM/swap ok, module Cscan_arb.sobien chargé) — juste structurellement trop lent : 2 cœurs physiques / 8 workers (oversubscription ×4, vs ×2 sur PC1) + pas de turbo + zone à t la plus élevée du run (coût de scan croissant avec t, confirmé empiriquement sur l'ordre de complétion des workers PC1). -
zeta_turbo_off.shs'est exécuté automatiquement à la sortie du script (détection de l'échec PC2, ret=255) — système confirmé restauré.
Prochaine action prioritaire — décider de la suite pour T=5M :
- Relancer tel quel en acceptant un run PC2 très long (durée réelle inconnue, aucun débit PC2 n'a jamais été mesuré) ;
- Revoir le split PC1/PC2 avant de relancer (moins — voire rien — pour PC2, ou réduire son nombre de workers pour limiter l'oversubscription) ;
- Exploiter uniquement le résultat PC1 déjà acquis pour une investigation partielle
des 96 manquants du v13, sans couvrir
[3469743.76, 5000000].
Suivi détaillé complet du run (chronologie heure par heure) : logs/suivi_run_T5M.md.
Le run T=5M v15 lancé le 02/08 20:29 a été tué par 3 redémarrages non planifiés
en moins de 24h (cause : PC1 débranché, batterie critique, HybridSleep sans
resume= configuré → dégénère en extinction sauvage). Corrigé :
CriticalPowerAction=PowerOff dans /etc/UPower/UPower.conf sur PC1. Détail complet
→ JOURNAL.md (session 04/08/2026) et Guide-Linux-Commandes.md §19.
Règle à respecter désormais pour tout run long sur PC1 (portable) : toujours
vérifier upower -i $(upower -e | grep -i AC) → online: yes (secteur branché)
avant de lancer zeta-distribute. nohup/setsid ne protègent pas d'un vrai
poweroff/reboot machine, seulement d'une fermeture de session/SSH.
-
RAG BrainVault (05/07 → 19/07/2026) : vault ChromaDB opérationnel (838 chunks),
scripts/rag_query.pyindustrialisé et durci contre l'hallucination (valeurs_non_ancrees(), commits86ab0ae/01934df/3307bad,Riemann_Lab_C). Limite connue : ne détecte pas une valeur correcte mal attribuée (seulement une valeur absente du contexte). -
Audit skills Claude Code (06/07/2026) : 2 désynchronisations corrigées
(
riemann-labrefs figées,phase-c-illinoisdivergence réelle v6-v8 vs v9-v15) — commits87ffa12,acefd4b, sync 4 branches. -
WireGuard hotspot (05/07/2026) : bug
AllowedIPsPC4 corrigé, tunnel confirmé fonctionnel via endpoint IPv6 depuis hotspot mobile. - Prochaine reprise possible (hors run T=5M) : Anthropic Skilljar — Claude Code 101 → MCP intro/avancé → Subagents → Agent Skills (pas commencé).
| Élément | État |
|---|---|
| Run T=5M v15 | ⚫ Arrêté manuellement — PC2 sans progression 23h20, tué (PID 32270) |
| PC1 | ✅ Terminé et sauvegardé — 6 749 092 zéros, [14, 3469743.76]
|
| PC2 | ❌ Tué — ~23h20 de calcul perdues, goulot d'étranglement confirmé (2 cœurs, pas de turbo, zone t la plus élevée) |
| Incident alimentation PC1 | ✅ Corrigé — CriticalPowerAction=PowerOff (UPower), secteur vérifié branché |
| Surveillance | ⚫ Arrêtée (TaskStop) |
| Doc | ✅ Guide-Linux-Commandes.md §19-20 + JOURNAL.md (04-06/08) + logs/suivi_run_T5M.md
|
| multi_ia_query.py | ❌ Retiré (08/08) — coût API non justifié, voir section « Profiling Phase C » ci-dessus |
| Élément | État |
|---|---|
| Run T=5M (v13) | ✅ Terminé — 10 016 377 / 10 016 473 zéros · 96 manquants |
| v13 | ✅ Commitée 4 branches · commit a0e6e41
|
| v14 | ✅ Commitée 4 branches · commit d4b3611 · 7.7 min T=100k |
| v15 | ✅ Commitée Riemann_Lab_C · commit adf5d2a · 4.4 min · Obj2 ✅ |
| BLOC 1 (wiki) | ✅ JOURNAL §04/07 · Formules_zeta §30 · Bibliotheques §17 · STACK v12→v15 |
| BLOC 2 (skills) | ✅ riemann-lab + phase-c-illinois mis à jour · skills_export/ commité |
| BLOC 3 (site) | ✅ docs/index.html v15 · ×28 600+ · 4.4 min · Obj2 ✅ |
| BLOC 4 (rapport) | ✅ analyse_problemes_v13_v15.md + PDF · wiki 2f845e4 · pdf fda4fb9
|
| BLOC 5 (sync) | ✅ sync 4 branches + Handoff |
| Version | Temps | Vitesse | Turing | LMFDB | Commit | Algorithme clé |
|---|---|---|---|---|---|---|
| v12 | 8.8 min | 261 z/s | COMPLET ✅ | 20/20 | f0e8430 |
Illinois Z_rs_double + 2 Newton Arb |
| v13 | 8.50 min | 271 z/s | COMPLET ✅ | 20/20 | 77efd10 |
T_SEUIL=65, TOL 1e-12 |
| v14 | 7.7 min | 299 z/s | COMPLET ✅ | 20/20 | d4b3611 |
+ cache log_n/isqrt_n 33 KB |
| v15 ⭐ | 4.4 min | 517 z/s | COMPLET ✅ | 20/20 | adf5d2a |
+ SEUIL_1NEWTON=20k |
Gain global v1 → v15 : ×28 600+ (21h → 4.4 min)
| Invariant | Valeur | Raison |
|---|---|---|
SEUIL_1NEWTON |
20 000 | biais_RS(20k) ≈ 6.4e-7 → ε 1 Newton ≈ 4e-13 < tol |
N_MAX_CACHE |
2100 | couvre T ≲ 27M, 33 KB, tient en L2 |
| Phase 2 t < 20k | 2 Newton | biais_RS grand → 1 Newton insuffisant (erreur ~1e-6) |
| Phase 2 t ≥ 20k | 1 Newton | économie 1 Z_arb · 87% des zéros T=100k |
tol Illinois |
1e-12 | cohérent avec LMFDB 20/20 |
| Fallback mpmath | t < 65 | N_RS < 3 termes → Z_rs_double imprécis |
Piège absolu : 1 Newton fixe pour TOUT t → erreur ~1.75e-6 à t≈65 (LMFDB 14/20).
Toujours utiliser int n_newton = (t_curr < SEUIL_1NEWTON) ? 2 : 1;
| Indicateur | Valeur |
|---|---|
| Zéros attendus N(5M) | 10 016 473 |
| Zéros trouvés v13 | 10 016 377 |
| Manquants | 96 |
| 0 REJECT / 0 FALLBACK | ✅ confirmé par ZETA_DEBUG_BRACKETS
|
| Cause | paires de zéros proches → pas de changement de signe visible sur grille Z_double |
| Illinois correct | oui — les brackets fournis sont tous bien affinés |
Piste : run v15 T=5M — économie 18h (35h→17h). Même STEP → manquants probablement identiques. Si réduction souhaitée : STEP/2 dans les segments déficitaires (rescan ciblé).
- Jamais
git add -Asansgit status+grep mcp .gitignoreavant -
STEPadaptatif obligatoire — ne pas revenir à STEP fixe - Turbo : toujours
zeta_turbo_on.shavant run long,zeta_turbo_off.shaprès - Ne pas modifier
compute_zeros_v2.py(référence 21h) -
mpc_zetaabsent de libmpc 1.3.1 — ne pas l'utiliser - Illinois Phase 2 : garder 2 Newton pour t < SEUIL_1NEWTON — 1 Newton fixe → erreur 1e-6 pour t < 200
-
plt.savefig()+plt.close()— jamaisplt.show()en production - PDF rapports →
pdf/optimisation/sur Riemann_Lab_IA UNIQUEMENT - SVG →
docs/images/UNIQUEMENT ; jamais dansscripts/nidocs/racine -
Fichiers dupliqués (wiki /
pdf/cours/.claude/skills) : vérifier la synchronisation AVANT de travailler dessus. Voir règle détaillée ci-dessous.
À chaque session, si un fichier existe en plusieurs copies dans le projet (wiki,
pdf/cours,.claude/skills,docs/,skills_export/, racine repo…), vérifier que toutes les copies sont synchronisées sur la version la plus récente avant de travailler dessus. Ne jamais laisser une divergence de version entre copies d'un même fichier. Comparer par date de dernier commit git (git log -1 --format=%ai -- <fichier>sur le dépôt concerné — le wiki est un dépôt séparé), pas par mtime disque. En cas de contenu réellement divergent (pas juste un arrêt dans le temps), fusionner plutôt qu'écraser. Cas traité en détail : session 09/08/2026, chantier « harmonisation des doublons » (Formules_zeta.md,Bibliotheques.md,Bonnes-Pratiques-Claude-Code.md,Guide-Git-GitHub.md,JOURNAL.mdracine supprimé après fusion dans le wiki).
| Hostname | IP | OS | Rôle |
|---|---|---|---|
zeta-lab (PC1) |
[IP_PC1] | Ubuntu · i7 4c | Calcul principal + orchestration |
zeta-calc-second (PC2) |
[IP_PC2] | Debian · Core2Duo | Calcul auxiliaire |
zeta-backup (PC3) |
[IP_PC3] | Ubuntu · Pentium | Backup rsync+rclone · auto |
zeta-secure (PC4) |
[IP_PC4] | OpenBSD 7.9 | Bastion WireGuard VPN |
| Commit | Branche | Description |
|---|---|---|
d4b3611 |
Riemann_Lab_C | feat(v14): cache log_n/isqrt_n — 7.7 min T=100k |
adf5d2a |
Riemann_Lab_C | feat(v15): SEUIL_1NEWTON=20k — 4.4 min · Obj2 ✅ |
a0864f1 |
Riemann_Lab_C | chore(skills): export skills v14/v15 |
3f28651 |
Riemann_Lab_C | feat(site): index.html v15 · ×28 600+ |
fda4fb9 |
Riemann_Lab_C | docs(rapport): analyse_problemes_v13_v15 PDF |
613c426 |
wiki/master | docs(wiki): BLOC 1 — JOURNAL/Formules/Biblio/STACK |
2f845e4 |
wiki/master | docs(analyse): rapport v13→v15 MD |
Handoff.md · 16 août 2026 · fusion Guide-Linux-Commandes.md (session admin 15/08 : SSH+doas, OpenBSD, apt PC2/PC3, users cluster, vi) · commit wiki 166b7ba · T=5M v15 toujours en attente de décision · 5 octobre 2026 (résumé d'état) · Mis à jour le 2026-10-15 — 832 lignes