Reflection — 2026-09-04

Vendredi W36 · J5 CDN réouverture · Stack 15/15 MCPs OK · 22:00 Paris  ·  ← index  ·  KPI →

TL;DR — 3 points clés

KPI du jour

€3 446
CDN W36 Net HT (Lun 31 + Mar 1 + Mer 2)
Lun: €78/h 2.9/h · Mar: €80/h 3.3/h · Mer: €90/h 3.2/h
€6 329
FSH W36 Net HT (Lun 31 + Mar 1 + Mer 2)
Lun: €59/h 2.5/h · Mar: €54/h 1.8/h · Mer: €55/h 1.8/h
€9 775
Groupe W36 (partiel) vs S-1 €12 949 (−24%) / vs N-1 €34 726 (−71%)
42.8%
MS/CA — distorsion semaine partielle (labor Jeu–Sam planifié, CA = 3j seulement)
14/15 agents OK · 15/15 MCPs · whatsapp-ocr KO J55

Note : label S-1 = "W19" dans le KPI = bug cosmétique persistant (J26+). Les valeurs S-1 sont correctes.

Timeline

Heure (Paris)Agent / SourceÉvénementRésultat
01:09disputes-dailyScan litiges Uber/DeliverooSTALE Uber 892h J37+ · soumissions=3 (Deliveroo OK) · disputables=0
04:02justifs-sweeperBatch justificatifs nuitexit=0 · fetch_free+sfr rc=1 · Alan + Uber Eats traités
04:49amazon-justifsAmazon → Pennylane backfillexit=0 · factures 2024–2025 ychateaudun traitées
06:01hermes-resto-briefBrief Asian Smash + opsexit=0 · blockers Orange Pro + Enedis + recrutement 0%
06:04–06:12WA James → équipeCA fourchettes midi/soir · CDN 2 cuistots 1 serveur / soir 1-1 · MS réduite"Nan / 1200-1400 midi / 900-1200 les soirs / Mais j'ai réduit la MS"
07:03daily-kpiKPI W36 J5 (Ven) publié — Mer 2 apparaît (J+2 carryover)exit=0 · CDN +€1 288 · FSH +€2 064 vs hier
07:05hermes-managerMonitoring stackexit=0 · 0 FAILED · 0 restart
07:52–08:54WA James → équipeInstructions mangues Labo — peel, freeze, étiquette décongélation"Peel all mango / Freeze maximum / Dont forget the desfrost date"
09:44–09:45WA JamesAu Labo · départ Pagode de Vincennes · "semaine vraiment short"1er signal Pagode de Vincennes (festival?) · confirme ramp-up réduit W36
10:00combo-retardDébut surveillance pointages0 alertes · 21–22 shifts/run (Labo uniquement) · CDN+FSH service fermés Ven 4
12:01*rekki-poll-todayTRIGGER Choiseul+Bastille pour 05/09 (10:01 UTC)Dans fenêtre étendue 12h00–12h15 Paris · cron 12:20 non déclenché
12:20rekki-recap-13hRECAP 2026-09-04 · 6 orders · PDF 9507Bexit=0 · 2ème run = skip idempotent (flag existe)
15:21WA entrant (JID inconnu)Question sortie de secours porte arrièreJID 162513123549260 (artisan/architecte Asian Smash?)
18:00WA James → équipe2 images + "Il faut prendre les 7 + 15 cartons comme ça aussi"Coordination logistique Labo / livraisons
20:00hermes-yatai-waMonitoring WhatsAppexit=0 · 15/15 MCPs OK
20:00whatsapp-ocrTest décisif Ven 04/09 (mentionné hier)exit=1 J55 bug LAST_SEEN unbound · prochain run Sam 05/09
20:00hermes-resto-reflectBrief Asian Smash + Yataiexit=0

* rekki-poll-today log UTC 10:01 = Paris 12:01

Patterns détectés

1. CDN carryover J+2 post-réouverture — 3 data points consécutifs → règle FERME
CDN Mer 2 (€1 288) apparu dans KPI Ven 4 = J+2. Consécutif avec :
· CDN Lun 31 → visible KPI Mer 02/09 (J+2) — 1er data point
· CDN Mar 01 → visible KPI Jeu 03/09 (J+2) — 2ème data point
· CDN Mer 02 → visible KPI Ven 04/09 (J+2) — 3ème data point
Seuil 3 data points atteint → règle ferme à inscrire dans CLAUDE.md. Fusion avec la règle "1er data point 2026-09-02". La règle "CDN Ven/Sam = J+1" (auto-applied 2026-07-05) concernait les semaines normales pre-CDN-estival — les deux coexistent.
2. FSH carryover J+2 généralisé — 5ème data point (FSH Mer 2)
FSH Mer 2 (€2 064) apparu dans KPI Ven 4 = J+2. Règle déjà CONFIRMÉE dans CLAUDE.md (3 data points août 2026). W36 Mer renforce la règle. Aucune nouvelle proposition requise.
3. W36 CDN service = Lun–Mer uniquement (Jeu–Dim fermés)
Jeu 3 = fermé (attendu, règle connue). Ven 4 = fermé (zelty-watch 0 orders ×47 + api_fail=0 + combo-retard 21–22 shifts Labo seulement).
James confirme : "semaine vraiment short pour moi" (09:44). CDN staffé Lun–Mer (2 cuistots 1 serveur service, soir 1-1).
Hypothèse : ramp-up semaine 1 réouverture — service uniquement Lun–Mer pour ne pas surcharger l'équipe réduite.
La règle pré-estivale "CDN Lun–Sam" reste la cible — W37 dira si Ven/Sam reprennent.
4. Trigger Choiseul+Bastille 12:01 Paris — dans fenêtre étendue post-été
10:01 UTC = 12:01 Paris. Fenêtre documentée pour période estivale/réouverture : 12h00–12h15 (3 data points). Cron 12:20 absorbe. Pattern stable.
5. Pagode de Vincennes — 1er signal (lieu festival possible)
James 09:44 : "jpars bientot a la pagode de vincenne". Pagode de Vincennes = site événementiel dans le bois de Vincennes, Paris 12e. Coïncide avec le watch item "stand festival Asian Smash" (barnum 3x3m, menu réduit, 2026-08-17). Peut être le lieu du festival mentionné alors. 1 data point — à confirmer si James précise.
6. Sosh re-cassé J2 après self-repair — session lifetime <2j (vs 18j estimé)
Self-repair déployé 02/09 07:35 → smoke test VERT. Run 03/09 04:00 = encore rc=1. J2 seulement.
La règle "Sosh session lifetime ~18j" (confirmée sur 2 cycles) semble ne pas s'appliquer au mécanisme de "self-repair" (qui n'est peut-être pas un full login mais une opération plus légère). À distinguer : (a) cycle naturel ~18j après full login, (b) self-repair = durée inconnue <2j.

Anomalies

🔴 CRITIQUEwhatsapp-ocr J55
Le run "test décisif" Ven 04/09 20:00 échoue encore (exit=1, bug LAST_SEEN unbound). Prochain run naturel : Sam 05/09 20:00 (J56 si échoue). Backlog estimé ~170+ médias. Fix trivial : 1 ligne Python (LAST_SEEN = None) — en attente décision James.
🔴 CRITIQUEDisputes Uber STALE 892h (J37+)
soumissions=3 (Deliveroo OK), Uber = 0 depuis ~29/07. Pertes définitives sur litiges 29/07–12/08. Session uber_storage_state.json expirée ~29/07 · prochaine après réauth ~02/10 (lifecycle ~34j). Action immédiate : run headed Playwright Uber + re-save state.
🟡 MOYENSosh re-cassé J2 après self-repair (session lifetime <2j)
Self-repair 02/09 → rc=1 au run 04/09 04:00. Le mécanisme de repair ne semble pas produire la même durée de session qu'un full login. SFR également rc=1 (probablement lié). fetch_free rc=1 J90+ indépendant.
🟡 MOYENFSH "only Thu 14 evening data" bug J26+
Ligne persistante dans daily-kpi.log : "FSH: Brut HT €160 · Net HT €130 · ~81.8% livraison (only Thu 14 evening data)". Apparu 06/07, J26 consécutifs. N'affecte pas le rapport HTML (FSH correct). Fix dans fetch_kpi_data.py — priorité basse (cosmétique).
🟢 INFOW36 CDN service = Lun–Mer uniquement
Ven 4 = 0 orders + 0 shifts service + James "semaine short" → CDN n'a pas encore repris le service Ven/Sam. Attendu en ramp-up post-44j fermeture. À surveiller W37 (Ven 11/09) pour confirmation retour rythme normal.
🟢 INFODisputes soumissions=3 aujourd'hui (Deliveroo)
Premier run avec soumissions >0 depuis longtemps. Signe que le scraper Deliveroo fonctionne bien en l'absence de Uber. Bon signal.

Propositions CLAUDE.md

FIXER section "CDN carryover J+2 post-longue-fermeture (1er data point 2026-09-02)" : ### CDN carryover J+2 post-réouverture — CONFIRMÉ (3 data points W36) - CDN Lun 31/08 → visible KPI Mer 02/09 (J+2) ✓ - CDN Mar 01/09 → visible KPI Jeu 03/09 (J+2) ✓ - CDN Mer 02/09 → visible KPI Ven 04/09 (J+2) ✓ - Règle : ne jamais conclure "CDN fermé" si KPI du lendemain affiche 0 — attendre KPI J+2 - Pattern convergent avec FSH carryover J+2 généralisé (même mécanisme Zelty) - Seuil 3 data points atteint → règle ferme (supprimer la mention "1er data point" précédente) JUSTIFICATION: 3 data points consécutifs W36 (Lun+Mar+Mer réouverture) confirment le pattern.
AJOUTER section 8 Open Issues (mise à jour whatsapp-ocr) : ### whatsapp-ocr structurellement arrêté (mise à jour 2026-09-04) - J55 depuis 11/07 · Run Ven 04/09 exit=1 · Test "décisif" mentionné dans reflect 03/09 = échoué - Prochain run naturel : Sam 05/09 20:00 (J56 de downtime si échoue encore) - Backlog estimé ~175 médias (53 connus au 27/06 + ~5.5/semaine × 23 semaines) - Fix : LAST_SEEN = None (1 ligne Python) — ESCALADE MAXIMALE, James doit décider JUSTIFICATION: test décisif Ven échoué = pas de résolution spontanée, fix manuel requis.
AJOUTER watch item section 8 ou section pertinente : ### Signal Pagode de Vincennes — festival potentiel (2026-09-04) - James 09:44 : "jpars bientot a la pagode de vincenne" - Pagode de Vincennes = site événementiel bois de Vincennes, 75012 Paris - Lien possible avec watch item "stand festival Asian Smash" (barnum 3x3m, menu réduit, 17/08) - 1 data point — documenter si James confirme lieu/date du prochain stand festival JUSTIFICATION: cohérent avec le watch item festival existant, lieu concret pour la 1ère fois.
AJOUTER section "Sosh session lifetime" (révision) : ### Sosh session lifetime — distinction full login vs self-repair - Full login : durée ~18j (2 cycles confirmés : 28/07 + ~02/09) - Self-repair : durée <2j (observé : repair 02/09 07:35 → rc=1 le 04/09 04:00) - Hypothèse : self-repair n'effectue pas un vrai login mais une opération légère (session cookie refresh ?) qui expire beaucoup plus vite qu'un login complet - À confirmer sur le prochain cycle de repair - Impact : le "self-repair" Sosh ne garantit pas 15j de service — surveiller le run J+2 après chaque repair JUSTIFICATION: 1er data point sur lifetime post-repair (vs 2 cycles sur lifetime post-full-login).

Générée à 22:00 Paris · 2026-09-04