🌙 Réflexion — 2026-05-17 (dimanche)

Yatai Ramen · Rapport soirée généré à 22:00 Paris · ← index · KPI du jour →

TL;DR

KPI résumé — W20

Timeline complète (heure Paris)

Patterns détectés

• Zelty : données du soir >> données du matin (confirmé 3ème jour) — À 09:00 Paris, Zelty retourne ~17 KB (données préliminaires). À 14:51, ~60 KB (données complètes, +240%). Les commandes FSH Ven15 et Sam16 (€2 408 et €2 107) apparaissaient à 0 le matin et seulement à midi le lendemain. Pattern stable → le KPI définitif doit être celui de 13h-15h et non celui de 9h.
• daily-kpi déclenché manuellement >5× le même jour — Aujourd'hui : 9 runs. Chaque run avec suffisamment de données envoie un WhatsApp. Sans garde "WhatsApp déjà envoyé aujourd'hui", chaque re-run devient un doublon. Pattern reproduit hier et avant-hier (à vérifier sur logs).
• rekki-recap trigger event-driven : 100% fiable si J1 rapide, instable si restart service après — Au 1er run (09:51) : OK. À la tentative event-driven à 11:22 après un probable restart systemd du service : FAILED. Le cron 12:20 Paris est le vrai garde-fou fiable.
• combo-retard-watcher : 23 shifts stables, 2 retards today (ratio 8.7%) — 23 shifts CDN+FSH inspectés dès 15:43 Paris. 2 LATE sur 23 = 8.7% du planning. Ce ratio est le premier point de données disponible pour ce watcher (J1). À surveiller sur 7 jours pour baseline.
• zelty-watch : état corrompu → reset → J1 bootstrap (pattern récurrent ?) — Deux fichiers .bak-corrupt présents dans shared/data. Le nouveau script déterministe repart de 0. Pas de données historiques récupérables sur les annulations précédentes.

Anomalies

• 🔴 [HIGH] daily-kpi : 4 envois WhatsApp PDF à James DM en 64 min (14:51, 14:59, 15:16, 15:55). Dont 2 avec texte court en plus (14:51, 14:59). Le marker daily-kpi-sent-2026-05-17.txt existe mais ne bloque pas les re-runs déclenché manuellement. Hypothèse : l'agent a été re-déclenché manuellement par James pour itérer sur les formats KPI — mais sans garde WhatsApp.
• 🟡 [MED] Conflit règles CLAUDE.md section 1 vs section 7 — Section 1 dit "PDF UNIQUEMENT, JAMAIS de message texte" pour James DM. Section 7 (KPI delivery) dit "1. Texte court 2. PDF". Les deux ont la date "depuis 2026-05-17". Résultat : comportement incohérent selon quelle section l'agent lit. Résolution nécessaire.
• 🟡 [MED] zelty-watch : "cancellation sig changed" faux positif au bootstrap — Au 1er run à 16:16 Paris, juste après le BOOTSTRAP (0 orders), le log affiche "cancellation sig changed — invoking". Cela suggère que la fonction de détection est appelée avant que l'état initial soit correctement initialisé. Aucun WhatsApp envoyé (alert logic correcte) mais le log est trompeur.
• 🟡 [MED] Staff malade (grippe) non pris en compte par aucun agent — Message reçu à 06:41 via WhatsApp. Aucun agent ne surveille les messages de type "absence" pour alerter le manager ou ajuster le planning. À terme : whatsapp-forward pourrait parser ces notifications.
• 🟢 [INFO] rekki-poll-today : double invocation à 09:44 — Le log montre "1 new orders — invoking" écrit 2 fois à exactement la même seconde (09:44:24). Probable boucle qui détecte le même order avant que le cache soit écrit. Pas de double WhatsApp confirmé (V14592679 n'apparaît qu'une fois dans processed.txt).
• 🟢 [INFO] daily-kpi RENDER failed à 11:41 + FETCH_KPI failed à 14:39 — 2 erreurs transitoires auto-récupérées. Aucune perte de données. Probablement des timeouts API ou une exception render sur structure de données partielle.

Propositions CLAUDE.md

### KPI WhatsApp delivery — PDF UNIQUEMENT (mis à jour 2026-05-17 soir)
- Un seul envoi par run réussi : PDF complet via mcp__whatsapp__send_file → DM James (33635420327)
- SUPPRIMER le texte court (section 1 prime : "JAMAIS de message texte vers James DM")
- Guard obligatoire : vérifier kpi-whatsapp-sent-<DATE>.flag avant d'envoyer ; créer le flag après envoi réussi
- Si flag présent → skip WhatsApp même si re-run déclenché manuellement

### KPI définitif vs préliminaire
- Run 9h00 Paris : données ~17 KB Zelty (70-80% des commandes, FSH weekend manquant)
- Run 13h-15h Paris : données ~60-65 KB (95%+ commandes, toutes clôtures disponibles)
- Le KPI "officiel" à utiliser pour archivage / comparaison WoW est celui généré après 13h Paris
- Les runs du matin sont "préliminaires" — ne pas interpréter une absence de CA comme une fermeture

### zelty-watch : J1 bootstrap — comportement attendu
- Au 1er run après déploiement ou reset état, zelty-watch bootstrappe avec 0 orders connus
- Le log peut afficher "cancellation sig changed — invoking" juste après bootstrap : faux positif bénin
- Pas d'alert envoyée (logique correcte), mais known_orders reste à 0 toute la journée J1
- Les annulations du jour J1 NE SONT PAS détectées (pas de baseline de comparaison)
- J2 = premier jour de surveillance effective
- Si les fichiers .bak-corrupt existent → état précédent corrompu, historique annulations perdu

### Absences staff WhatsApp (non géré, planifié)
- Les messages d'absence arrivent par WhatsApp (ex: "Hi, i am unable to come today due to grippe")
- Aucun agent ne surveille ces messages actuellement
- TODO : whatsapp-forward pourrait parser ces patterns et alerter James + vérifier planning Combo HR
- Format probable : message reçu de contact staff inconnu, contient "absent|sick|grippe|malade|cannot come"

Continuité avec hier (2026-05-16)

• ✅ Résolu : FSH Ven 15 + Sam 16 CA = 0 → données disponibles aujourd'hui (FSH Ven €2 408, FSH Sam €2 108). Délai Zelty weekend confirmé : ~24h.
• 🔄 Persistant : zelty-watch silencieux depuis 2026-05-16 (bug ancien script) → nouveau script déployé aujourd'hui. J2 demain = premier monitoring effectif.
• 🔄 Persistant : daily-kpi multi-run sans garde WhatsApp. Présent hier aussi (à confirmer sur logs).

État des agents à 22h00