Yatai Réflexion — 2026-05-24

Samedi · Dimanche de Pentecôte · ← index  ·  KPI du jour

TL;DR

Timeline du jour

Heure Paris Agent Événement Résultat
06:00 rekki-poll-today V14645478, U14646270, Y14646293 → livraison 25/05 ✅ PDF+confirm+mark
07:00 daily-kpi-runner Fetch Zelty (84 KB) + Combo HR (45 KB) ✅ démarré
09:07 daily-kpi-runner HTML 78 511 B écrit + PDF 142 KB généré + envoyé James ✅ exit=0
11:49 rekki-poll-today U14646806 → livraison 25/05 (4e ordre du jour) ✅ PDF+confirm+mark
11:49 rekki-poll-today TRIGGER event-driven recap — Choiseul + Bastille ont commandé pour 25/05 ✅ trigger systemctl
11:49 rekki-recap-13h Recap livraison 25/05 (pure Python) ✅ exit=0
12:10 combo-retard 1 retard détecté (ab2c6736 · CDN, 10:10 Paris) ✅ alerte envoyée
12:20 rekki-recap-13h Cron 12:20 fallback → idempotency silent skip ✅ exit=0
18h30–22h00 zelty-watch 10 runs · 0 orders inspectés (API Z-report delay structurel) ✅ normal
20h50–22h00 combo-retard 14 runs · 23 shifts · 0 nouveaux retards ✅ silence OK
22:00 yatai-reflect Réflexion nuit — reprise après 3 jours API limit ✅ en cours

Patterns détectés

⏱ Trigger Choiseul+Bastille 11h00–12h00 Paris (J5+ stable)
Confirmé le 24/05 (samedi) à 11h49 Paris. Données accumulées : Fenêtre stable : 11h00–12h00 Paris, y compris samedis et dimanches. 5 data points sur 8 jours. Ce pattern n'est pas encore inscrit dans CLAUDE.md malgré les propositions répétées (17, 18, 19, 20/05).
📊 Zelty watch 0 orders intra-jour (J8 consécutif)
Confirmé tous les soirs depuis le 17/05. Structurel — l'API Zelty ne retourne les orders qu'après Z-report (clôture journée). Déjà en mémoire persistante (lesson #2). Le monitoring real-time des annulations est structurellement impossible avec l'API actuelle.
🐍 daily-kpi Python pur stable (J8)
8 runs consécutifs réussis (17–24/05) à 09:00 Paris, y compris pendant les 3 jours de API limit (21–23/05). Contrairement à yatai-reflect (Claude), daily-kpi est maintenant un script Python pur qui n'est pas affecté par les limites d'usage API.
📦 rekki-recap idempotency parfaite (J8)
Le trigger event-driven (11h49 aujourd'hui) est systématiquement suivi d'un cron 12:20 qui exit=0 silencieusement. La dedup fonctionne. Le flag rekki-recap-triggered-YYYY-MM-DD.flag est créé et respecté.
🔋 Récupération post-limit API (nouveau)
Après 3 jours de You've hit your org's monthly usage limit (21–23/05), yatai-reflect est de nouveau opérationnel le 24/05. La limite semble avoir été réinitialisée ou augmentée. Aucune action visible de l'utilisateur dans les logs. Seuls les agents Claude (yatai-reflect) ont été affectés — les agents Python pur ont continué normalement.

Anomalies

🔴 Org API usage limit — 3 nuits sans réflexion (21–23/05)
Période : 2026-05-21 22:00 → 2026-05-23 22:00 (3 nuits consécutives)
Symptôme : You've hit your org's monthly usage limit · exit=1 en ~6s
Impact : 0 rapport HTML généré pour 21, 22, 23/05. Aucune détection de patterns/anomalies pendant cette période. Les agents Python pur (daily-kpi, zelty-watch, combo-retard, rekki-polls) ont continué sans interruption.
Cause probable : forte utilisation Claude API en mai (refactors, debug sessions, agents). Limite mensuelle atteinte le 21/05 soir.
Résolu : le 24/05 — probablement reset automatique de la fenêtre ou augmentation manuelle de la limite.
🔴 3 ordres Rekki jamais livrés au Labo — 2026-05-21 matin
Ordres : X14624178, U14625033, X14625186
Période échec : 04:00 → 08:38 UTC le 21/05 (4h38 de WHATSAPP_FAIL répétés toutes les 34s)
Cause : WhatsApp bridge DOWN à 04:00 UTC (6h Paris) — même bridge qui était DOWN le 20/05 à 22:00
Impact : Ces 3 ordres sont absents de rekki-poll-processed.txt → PDFs non envoyés au groupe Labo 92, non confirmés ni marqués dans Rekki.
Status : Historique (livraisons probablement 22/05) — dommage fait. V14626408 a réussi à 08:39 quand le bridge est revenu.
Risque structurel : si le bridge tombe à 04:00 pendant un poll, les ordres sont bloqués sans mécanisme de reprise automatique.
🟡 CA hebdomadaire –31% WoW — effet Pentecôte
S (W21 partiel) : €18 193 · S-1 (W20) : €26 423 · vs N-1 : €33 402 (–45.5%)
Vendredi 22/05 CDN : 24 cmdes · €521 CA · MS/CA 95.1% → quasi-perte (€496 labor pour €521 CA)
Cause : Dimanche de Pentecôte = 25/05 (demain). Week-end long → Parisiens partis.
À surveiller : rebond attendu semaine S+1 (W22, 26–31 mai).
🟡 Lundi de Pentecôte 25/05 — jour férié
Demain = Lundi de Pentecôte. 4 ordres Rekki déjà traités pour livraison 25/05 (V14645478, U14646270, Y14646293, U14646806 — probablement Choiseul + Bastille + autres). CDN et FSH sont fermés le dimanche (pas de service). Les 4 ordres sont pour les franchises (Choiseul 2e, Bastille 11e, Montparnasse).
Impact RH : Combo HR devrait montrer shifts réduits lundi. MS/CA difficile à interpréter sur les jours fériés.
🟢 Bug titre KPI renderer — non résolu (J7)
Le titre du rapport KPI affiche 2026-05-24 (dimanche fin de semaine ISO W21) au lieu de la date réelle du rapport. Première détection : 18/05. Rappelé chaque nuit dans le reflect. Aucun fix appliqué en 7 jours. Le fichier HTML est correctement nommé — seul le <title> et le <h1> sont erronés.

Propositions CLAUDE.md

PROPOSITION 1 — Section 1 (Business context) : Timing commandes Choiseul+Bastille
Cible : Section 1, sous "Trigger event-driven du recap"
Texte à ajouter : 
### Timing commandes Choiseul+Bastille (observé depuis 17/05/2026)
- Choiseul 2e et Bastille 11e commandent typiquement entre **11h00 et 12h00 Paris**,
  y compris les samedis et dimanches.
- Pattern stable sur 5+ data points (17, 18, 19, 20, 24/05).
- Trigger event-driven systématiquement déclenché 55–65 min avant le cron 12:20.
- Implication : le cron 12:20 est un pur fallback de sécurité, rarement activé.
Justification : 5 data points sur 8 jours, y compris week-end. Pattern fiable pour optimisation future.
PROPOSITION 2 — Section 8 (TODO) : Reprise auto des ordres Rekki après bridge DOWN
Cible : Section 8 "Open issues / TODO"
Texte à ajouter : 
- [ ] **Mécanisme de reprise Rekki après bridge DOWN** : si WhatsApp bridge est DOWN
  à 04:00 UTC lors du poll, les ordres X14624178/U14625033/X14625186 (21/05) n'ont pas été
  envoyés ni confirmés (4h38 de failures sans recovery). Ajouter une liste d'ordres "pending"
  dans le state, relancés automatiquement quand le bridge revient UP (via health check).
Justification : 3 ordres perdus le 21/05 à cause de 4h38 de bridge DOWN sans recovery automatique.
PROPOSITION 3 — Section 8 (TODO) : Monitoring org API usage limit
Cible : Section 8 "Open issues / TODO"
Texte à ajouter : 
- [ ] **Monitoring org API usage limit** : yatai-reflect a été DOWN 3 nuits consécutives
  (21–23/05) suite à la limite mensuelle atteinte. Ajouter une vérification périodique
  de l'usage API (via tableau de bord Anthropic ou alerte email) pour anticiper avant
  atteinte de la limite. Envisager migrer les agents non-critiques vers des scripts Python
  purs pour réduire la consommation (daily-kpi déjà migré, rekki-recap-13h candidat).
Justification : 3 jours aveugles = anomalies non détectées. La migration Python réduit la consommation.
PROPOSITION 4 — Section 3 (Zelty gotchas) : Bug titre KPI renderer
Cible : Section 8 "Open issues / TODO"
Texte à ajouter : 
- [ ] **Bug titre KPI renderer** : render_kpi.py affiche la date dimanche fin de semaine ISO
  (ex: "2026-05-24" pour W21) au lieu de la date du jour passée en paramètre. Detecté
  depuis le 18/05. Le fichier HTML est correctement nommé — seul le titre est faux.
  Priorité basse mais confusant pour l'historique. Fix : passer TODAY explicitement
  comme variable au renderer et l'utiliser dans le <title> et <h1>.
Justification : Bug non corrigé après 7 jours malgré 4 signalements dans les reflections.
Généré par yatai-reflect · 2026-05-24 20:07 Paris · lien web