Nabil a identifie le fix cote formulaire DSM (HTTP 1.0 au lieu de 1.1 en
version backend du reverse-proxy). Reteste avec succes en conditions
reelles : SSE + les 4 outils bout-en-bout via l'URL publique.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Le flux SSE reste bloque quand le client negocie HTTP/2 via ALPN sur la
nouvelle regle DSM baserow-schema.bolbol.tn -- fonctionne en HTTP/1.1 force.
Cause probable cote DSM (config divergente de baserow.bolbol.tn qui marche).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Documente le nouveau service compagnon (create_table/delete_table/create_field/
delete_field) et les 4 pieges rencontres (JWT obligatoire sur ces routes,
API bas niveau SseServerTransport instable entre versions mcp, DNS-rebinding
protection allowed_hosts=[] par defaut, 409 transitoire apres link_row).
Resync complet de common/ports-registry.md (plusieurs semaines de derive).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Promu en runbook common/ transverse -- rencontre 2 fois en contextes
differents (transfert git bundle, deploiement fichier partage 3 instances),
n'avait jusque-la qu'une note de session etroite (nas-deploy-ops, scopee au
seul cas du git bundle nas-runbooks).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Documente les deux pieges de la fenetre de backfill mail (12-16/08) : 444 messages
perdus en silence (18%) sur HTTP 429 embeddings jamais reessaye + max_tokens
partage avec le raisonnement mimo-v2.5, corrige avec compteur d'echecs remonte au
bilan (0 perte en tranche finale) ; et 122 error_404 qui mesuraient un resolveur
de chemin perime (bugs corriges le 10/08) plutot que des dossiers reellement
absents (105/122 recuperables). Regle generale versee pour les 3 instances.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cause de fond du bug D : go_to_folder_path confondait l'expansion d'un dossier
et sa selection. Seules les feuilles etaient reellement selectionnees ; tout
dossier a enfants laissait le dossier courant sur la Boite de reception, d'ou
un /search en HTTP 200 sur le mauvais perimetre. 63 dossiers sur 336 concernes.
Correctif : segments intermediaires = expansion seule ; dernier segment = clic
sur la ligne + confirmation par aria-selected, sinon 502 explicite.
Bug C corrige dans le meme passage (premier segment resolu aussi parmi les
freres de niveau 2, apres la Boite de reception pour retrocompatibilite).
Pollution induite mesuree et purgee : 46 notes sur 399, sur 10 dossiers tous
conteneurs. 399 -> 353 notes, 0 incoherence residuelle.
Bug E decouvert par les tests : sur un dossier sans message direct, OWA elargit
lui-meme la recherche a toute la boite. Politique du garde-fou inversee --
l'heterogeneite bloque desormais l'ingestion au lieu de la laisser passer.
Garde-fou : /search renvoie parfois le contenu de la Boite de reception pour un
folder_path donne, en HTTP 200 sans erreur (bug D, cause non corrigee cote serveur).
Verifie avant d'implementer qu'AUCUN signal structure n'existe dans la reponse
(top-level query/count/items ; par item raw_text/aria_label/elem_id/attrs) -- en
exposer un imposerait de modifier hermes-mail-browser, donc session dediee.
Signal retenu faute de mieux : la derniere ligne de raw_text porte le libelle du
dossier. Fiabilite mesuree sur 5 dossiers de types differents avant implementation :
uniforme a 100% dans les 5 cas (81/81, 37/37, 6/6, 84/84, 77/77), correspondant dans
les 4 cas sains, divergent dans le seul cas verole -- fiable ET discriminant, ce qui
justifie un blocage dur plutot qu'un simple avertissement.
Conception conservatrice : ne bloque que sur preuve positive de mauvaise portee ;
journalise et laisse passer quand il ne peut pas conclure (aucun item, libelles
heterogenes, noyau comparable vide). Un faux positif bloquerait une ingestion
legitime, ce qui serait pire que le defaut couvert. HermesFolderScopeError herite de
HermesMailClientError -> comportement correct chez les deux appelants de production
sans les modifier (checkpoint 'error' cote pipeline, None cote download_attachments).
Verifie en conditions reelles depuis le container : dossier sain 81 items ingeres,
dossier verole bloque. Non-regression du mock de test verifiee.
Timeout : effet de bord du fix B (plafond 20 -> 200). La duree de /search croit avec
le volume demande (scroll progressif) -- 40 a 240 s mesures, contre timeout=60 code en
dur. Les gros dossiers echouaient en timeout. SEARCH_TIMEOUT_S = 300.
+ 1 regle PROTOCOL-INFRA (plafond de pagination et timeout sont couples).
A - glyphe de zone privee Unicode seul en ligne 0 de raw_text decalant tout le
decoupage positionnel : sender, subject ET date faux ensemble. 295/399 notes
avaient un received_date qui n'est pas une date. 11 points de code PUA distincts
recenses sur 40 dossiers, dont 7 hors de la plage Fluent UI habituelle -> retenir
U+E000-U+F8FF. Correctif : nettoyage en amont du decoupage, date par motif,
normalisation ISO 8601 au jour, message_id sur champs normalises + conversation_id
comme discriminant. Corrige aussi checkpoint.last_processed_date (meme source).
B - search_folder() ne transmettait pas limit a /search -> plafond serveur silencieux
a 20 items, dossier marque done comme s'il etait complet.
C - dossiers hors Reception inatteignables : 3 chemins de navigation, 3 defauts deja
resolus ailleurs dans le meme fichier. Diagnostique, non corrige.
D - NON RESOLU, BLOQUANT BACKFILL : /search renvoie le contenu de la Boite de reception
pour certains folder_path, en HTTP 200. Invalide la methode d'audit de completude
et remet en question le classement des 399 notes existantes.
+ 3 regles generales dans PROTOCOL-INFRA.md (glyphe/emoji cassant tout matching de
texte naif sur OWA ; valeur par defaut serveur non transmise = troncature silencieuse ;
verifier la portee d'un resultat scope, pas seulement son code HTTP).
Ajout B5 a common/rotation-secrets-inventaire.md, redige selon la doctrine A1 (empreinte
sha256:bbd43b3e, valeur JAMAIS en clair). Sweep unique grep -rlI sur /volume1/docker (08/08/2026)
= ~30 fichiers : ~10 remotes git (.git/config), 7 .env desactives/backups, et DEJA en clair dans le
repo nas-runbooks lui-meme (HEBERGEMENT-SITES-STATIQUES.md, n8n-skills-officiels.md,
tap-gitea-hermes-skills.md, telegram-flood-control-...gitea-deploy-token.md) + context-hub/MEMORY/log.
Liveness NON re-verifiee (172.17.0.1 injoignable hors NAS, test Tailscale non concluant) -> traiter
comme potentiellement vivant. Remediation (rotation + reecriture remotes + scrub historique) = session
dediee, hors perimetre du chantier message_id.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- hermes-tt/nyora-notes-tt-message-id-elem-id-volatile-08-08-2026.md : cycle complet --
hypothese elem_id stable, test insuffisant (1 msg position 0, appels rapproches) qui l'a
faussement valide, test rigoureux (19 msg, ensembles disjoints, 0/20 meme index) qui
l'infirme, cause (id de rendu DOM volatile), decision (message_id reste hash SHA256 stable,
conservation conversation_id data-convid niveau thread + fix retry /search count:0), garde-fou
dedup (399 notes en dossiers 'done' jamais re-scannes -> pas de doublon).
- PROTOCOL-INFRA.md : regle "id DOM d'un SPA jamais presume stable" (tester >=2 rendus reels +
plusieurs echantillons) + fix /search count:0 transitoire + piege split('|') sur attrs.
- _INDEX.md : entree ajoutee.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
bolbol
hermes-nyora
Nabil.Derouiche