Le terminal interprète les `backticks`, les $variables, et les caractères spéciaux AVANT que le heredoc ne soit écrit sur le disque.
Exemples réels :
📛 data-manager API corrompu par heredoc (Claude 2)
📛 chatbot-widget.php — regex backtick /`([^`]+)`/g impossible à écrire par sed/heredoc. 6+ tentatives échouées sur 1 session complète
📛 offer-import.php corrompu
📛 registry-test.sh — les \$ échappés persistent après sed, nécessitant perl -pi -e
cat >> fichier << 'BLOC' (quotes simples autour du délimiteur)head -141 fichier.php > /tmp/fix.php echo ' ligne corrigée' >> /tmp/fix.php tail -n +143 fichier.php >> /tmp/fix.php cp /tmp/fix.php fichier.php
python3 -c "
c=open('/path/file.php').read()
c=c.replace('old','new')
open('/path/file.php','w').write(c)
"sed ne gère pas : multi-lignes, quotes imbriquées, regex avec backticks, HTML avec attributs. Chaque tentative de "fix" empire le fichier.
📛 menu.html : 4+ tentatives de sed → doublons, sections supprimées, structure HTML cassée
📛 chatbot-widget.php ligne 142 : 6 tentatives sed/heredoc/echo pour fixer une regex backtick → aucune n'a marché
open().read().replace().write()Dans registry-test.sh, les \$ persistaient après chaque tentative de sed. La solution finale : perl -pi -e 's/\\\\\\$/\\$/g'
Le CX proxy (weval-consulting.com/api/cx, key=WEVADS2026) tronque silencieusement les payloads > 4500 bytes. Le fichier semble déployé mais est incomplet.
split -b 4500 fichier.html /tmp/chunk- for f in /tmp/chunk-*; do C=$(base64 -w0 "$f") # envoyer via CX... done
Les commandes Python envoyées via CX proxy pour écrire des fichiers échouent parfois silencieusement. Le fichier existe mais est vide ou tronqué.
base64 -d CLI au lieu de Python pour écrire les fichiersxxd -r -pL'IP du container Claude est bloquée par le firewall S95. Toute exécution distante doit passer par la machine locale de Yacine ou par Sentinel whitelisté.
Les commandes SSH depuis PowerShell Windows interprètent les guillemets différemment. sed -i "s/old/new/" via SSH depuis PowerShell = résultat imprévisible.
📛 Fix l99-chat.php depuis PowerShell → bash: line 1: llama-3.3-70b/m=: No such file or directory
Le cron html-guardian tourne toutes les 10 minutes, compare les fichiers avec les GOLD, et restaure automatiquement. Si tu fais un fix et que le GOLD est l'ancien fichier → ton fix est écrasé en 10 minutes.
📛 youtube-auth.php fixé → écrasé par guardian 10 min après
📛 arsenal-auth.php fixé → écrasé par guardian
📛 Gold files dataient du 31 jan (AVANT rollback) → protégeaient l'état CASSÉ
cp fichier_fixé.php /opt/wevads/vault/fichier.php.gold md5sum fichier_fixé.php >> /opt/wevads/vault/checksums.md5
crontab -l | grep -v guardian | crontab - (puis réactiver)Layer 1: Deploy Validator (pre-deploy) · Layer 2: HTML Guardian (*/10min) · Layer 3: Sentinel V5 (*/30min) · Layer 4: Vault Guard (*/6h) · Layer 5: 743 gold files + checksums MD5
Sur Huawei Cloud avec NAT, l'IP publique n'est pas bindée localement. Les VMTAs avec smtp-source-host 0.0.0.0 crashent PMTA au restart.
📛 Template VMTA corrigé avec 0.0.0.0 sur 8 fichiers → PMTA refuse de démarrer sur SER_9
📛 pmta --config-check n'existe pas dans cette version → erreurs invisibles
SER_6: 110.239.84.121 / 192.168.0.11 SER_7: 110.239.65.64 / 192.168.0.55 SER_8: 182.160.55.107 / 192.168.0.38 SER_9: 110.239.86.68 / 192.168.0.241
Le binaire propre est dans /opt/pmta-versions/4_5r8/pmtad. Le proxy Python pmtahttpd tourne sur port 5371 (v5.0b1). Ne JAMAIS toucher ces fichiers.
Le template d'installation PMTA ne contient que localhost pour l'accès HTTP admin. Tous les nouveaux serveurs sont inaccessibles depuis le monitoring central.
http-access 0/0 monitor (ou IP WEVADS spécifique)Avril 2026 : Authentik a été supprimé après des régressions répétées (boucles redirect, callback 400, sessions corrompues, JWT redirect vide). Remplacé par auth PHP simple : /var/www/html/auth/ (login=yacine/Weval@2026, cookie HMAC 30j).
📛 Callback SSO retournait 400 en continu → sessions corrompues
📛 JWT state contenait "redirect":"" → toutes les pages redirigées vers /
📛 Sub_filter JS faisait double redirect (client + nginx) → boucle infinie
📛 @sso_retry redirigeait vers $request_uri = /outpost.goauthentik.io/callback → boucle
📛 10+ heures passées sur 3 sessions à débugger SSO
La route /auth/check retournait un return 200 nginx statique au lieu d'exécuter le PHP qui vérifie le cookie HMAC. Résultat : toutes les pages semblaient non-protégées ou protégées selon la config, mais jamais correctement.
fastcgi_pass unix:/run/php/php-fpm.sockAprès suppression d'Authentik, 19 locations nginx pointaient vers des pages qui n'existaient plus ou vers des callbacks Authentik. Nettoyées dans la session du 8 avril.
/etc/nginx/weval-consulting.gold.pre-auth-removal.8avr2026Les fichiers nginx sont marqués immutable (chattr +i) pour anti-régression. Toute tentative de modification échoue silencieusement.
sudo chattr -i fichier → modifier → tester → sudo chattr +i fichier📛 "Erreur de réponse" sur le chatbot fullscreen — la route nginx n'existait pas, le backend retournait 404
cp /etc/nginx/sites-enabled/weval-consulting /etc/nginx/sites-enabled/weval-consulting.bak.$(date +%Y%m%d)nginx -t OBLIGATOIRE avant nginx -s reloadDeux fois en 6 mois, l'intégralité du crontab (60-75 crons de production) a été écrasée par un script qui faisait echo "..." | crontab - au lieu de (crontab -l; echo "...") | crontab -.
📛 Fév 2026 : CRM worker a écrasé 60+ crons avec 5 stubs → warmup, brain, monitoring arrêtés
📛 Restauration du mauvais backup (18 lignes au lieu de 75) → 2ème perte
📛 Jan 2026 : cron même pas installé sur le container → tous les jobs perdus
echo "..." | crontab - → toujours (crontab -l; echo "...") | crontab -crontab -l > /opt/wevads/crontab-backup-$(date +%Y%m%d-%H%M).txtcrontab -l | grep -c "^\*\|^[0-9]"📛 sed sur le crontab pour switcher ethica-validator → ethica-validator-safe a corrompu le crontab → restauration backup nécessaire
crontab -e ou exporter/modifier/réimporter proprementWEVIA avait display_errors=On en production → paths serveur, credentials DB, stack traces visibles dans les réponses API.
display_errors=Off en production. Logs dans error_log.Après édition via CX proxy ou sed, des erreurs de syntaxe PHP passent inaperçues (fichier vide, quote manquante, variable non fermée). La page retourne un 500 silencieux.
php -l fichier.phpAvec 50 max_children, les requêtes concurrentes (surtout avec les LLM qui prennent 15-45s) saturaient PHP-FPM. Augmenté à 100.
Le backend chatbot fait 134KB avec 751 fonctions. Toute réécriture = régression massive. Interventions chirurgicales ONLY.
pg_hba.conf distingue connexions socket (localhost) et TCP (127.0.0.1). Certaines apps utilisent l'un, certaines l'autre. Le fix TCP a été appliqué pour Ethica.
adx_system contient le schema admin (WEVADS) et le schema ethica. adx_clients est la DB contacts. Le dblink bridge connecte les deux.
admin.table ou ethica.tableagents-archi.html utilise Three.js r170 ESM via import maps. THREE.CapsuleGeometry a été introduit en r142. Les anciens exemples Claude utilisent r128 → crash.
CylinderGeometry, SphereGeometry, ou geometries custom📛 Session 9-10 avril : suppression d'un bloc script a emporté le })(); du IIFE Bottom-Up → tout le JS de la page crashait
Le site utilise weval-enrich.js (Claude A), wevia.html (Claude B), wevia-api.php (Claude C). Chaque Claude a son domaine. Ne JAMAIS écraser les fichiers d'un autre Claude.
Le chatbot fullscreen est un seul fichier HTML de 147KB avec CSS+JS intégrés. Ne JAMAIS réécrire en entier.
Par défaut, smartRoute() envoyait TOUT (sauf consulting) sur llama3.1:8b GPU. Trop petit pour du consulting, analysis, medical, creative.
📛 "SAP vs Oracle" → réponse de 2 lignes générique au lieu d'analyse détaillée
📛 Schema/Mermaid → texte brut au lieu de diagramme (8b ignore les instructions mermaid)
applyBusinessRules() appendait des métadonnées internes dans la réponse visible au client.
rules_warning — invisible au clientLes réponses API contenaient provider: "deepseek_gpu", model: "llama3.1:8b", latency_ms: 1200. Infos internes.
provider: "WEVAL_brain". Les détails restent dans les logs serveur.Claude B = Fullscreen (wevia.html + weval-chatbot-api.php). Claude C = Widget (wevia-api.php). APIs backend différentes, frontends différents. Ne JAMAIS confondre.
3 sessions Claude ont essayé de configurer des postback URLs chez les sponsors. ADX/iResponse utilise un modèle PULL — conversions-collector.php interroge les APIs CAKE/Everflow toutes les 30 minutes.
📛 Erreur critique répétée 3 fois sur 3 sessions différentes
1. Relire mémoires → comprendre le contexte 2. Anti-Régression → chercher existant (scanner avant de créer) 3. Recul / architecture → plan 4. GOLD backup → sauvegarder l'état avant 5. git commit → git push 6. Mockup → validation Yacine EXPLICITE 7. Modifier → appliquer les changements 8. vault + checksums → mettre à jour les références 9. git add + commit + push → versionner 10. Triple verify 0 dirty → rien qui traîne
Si un problème apparaît 2 fois : STOP symptôme, identifier root cause, appliquer fix structurel. Ne JAMAIS continuer à patacher.
📛 SSO callback 400 : patchée 5 fois en surface avant d'identifier que le JWT state était vide
📛 sed/heredoc : réessayé 6 fois sur chatbot-widget.php avant d'admettre que sed ne peut pas gérer les backticks
JAMAIS supprimer les GOLD. Ils sont la dernière ligne de défense quand tout casse.
fichier.gold.pre-{action}.{date}/etc/nginx/weval-consulting.gold.pre-auth-removal.8avr2026S204 (204.168.152.13) héberge PMTA + WEVIA + Ethica. JAMAIS y déployer des fichiers Arsenal, ADX, ou autres apps non-MTA.
Ollama LOCAL = rang 1 partout. Cloud = fallback uniquement. Jamais single-vendor lock-in.
WEVIA KB = INTERNAL ONLY — jamais exposer sur site public.
Le collectiveLearn a été désactivé pour éviter la pollution de la KB par du contenu non validé. L'auto-learn reste actif pour les faits utilisateur explicites.
Le rendu Mermaid en PNG via mmdc (Puppeteer) crash quand exécuté en root sans --no-sandbox.
args: ['--no-sandbox']