Cardigan-AI

1. Pipeline promotion end-to-end (bug critique)

1. Support Catalog/PDP dans le pipeline

• Nouveau mode PROMOTION dans SKILL.md (Steps P0–P5) : workflow complet de génération promotion XML à partir d'un brief ou de paramètres utilisateur
• generate_xml.py enrichi : support complet des 6 types de promotions (`product-percentage`, `product-bundle-percentage`, `product-quantity-percentage`, `order-gwp`, `order-amount-off`, `shipping`). Fonctions : `render_promo_campaign()`, `render_promotion()`, `render_promotion_campaign_assignment()`, `assemble_promotions()`. Déduplication automatique des campaigns partagées.
• campaign-spec-schema.json : ajout du tableau `promotions[]` (40+ propriétés) au schéma JSON
• Nouveau template `templates/promotion.md` : référence complète des 6 types avec exemples JSON et XML
• Nouveau référentiel `agent-docs/references/promotion-patterns.md` : patterns multi-brand extraits de 5 backups + 6 briefs Wrike (tiered %, virtual bundle, GWP coupon/threshold/product-qualified, cross-sell, free shipping)

• Pre-flight token check (`wrike-pull.py`) : validation de tous les tokens (Wrike, Asana, Drive) via appel API léger AVANT de lancer le pipeline. Wrike invalide = abort immédiat avec message actionnable. Services optionnels = désactivés proprement.
• Scan TODO résiduels (`generate_xml.py`) : `_scan_todos()` parcourt récursivement le spec. Mode `--strict` transforme les warnings en erreurs bloquantes.
• Validation bilingue (`generate_xml.py`) : détection des champs `_fr` manquants quand le `_en` existe. Prévient le fallback EN silencieux sur le site FR.
• Dry-run enrichi (`generate_xml.py`) : arbre détaillé des composants avec copy EN/FR, schedules, CTAs, et warnings TODOs.
• Checklist post-génération (`generate_xml.py`) : après écriture des XMLs, affiche les étapes manuelles spécifiques (images WebDAV, imports BM, vérification campagne, QA).

• campaign_id propagé partout : wrike_metadata → analysis → scope → campaign-spec → qa-log → brand-learnings. Ajouté dans `build_campaign_spec.py` (lit depuis analysis.json, fallback construction) et dans le schéma scope.json
• package_webdav.py intégré comme étape 4b du pipeline `/campaign` : classification auto des images, assignation WebDAV, mise à jour campaign-spec.json
• preview_import.py systématique : étape 4e exécutée automatiquement après generate_xml (avant l'agent QA sémantique)
• Rebuild auto brand learnings après /qa : `build-brand-learnings.py --brand {brand}` s'exécute après chaque qa-log-append
• WrikeAccessDenied : exception 403 → skip + flag dans tout le pipeline (wrike-pull, ingest-historical)

• qa-log-append.py enrichi : nouveaux champs `campaign_id`, `brief_folder`, `analysis_status` pour corrélation cross-pipeline
• Rebuild auto : après chaque `/qa`, `build-brand-learnings.py --brand {brand}` recompile les learnings pour que `/brief-analyse` ait les données fraîches
• Failure categories : catégorisation automatique des échecs (copy, translation, scheduling, layout, image, promo)
• Cost tracking : estimation USD par modèle (haiku/sonnet/opus/hybrid)

Après 4 sessions QA sur 3 marques, les briefs varient énormément d'une marque à l'autre. Ceci a un impact direct sur la fiabilité du QA.

• [PROCESS] Sans brief, le QA se limite à la vérification de cohérence (traduction FR, pas de fallback EN, liens corrects) mais ne peut PAS confirmer que le contenu EN est conforme au plan original
• Action : Les rapports QA sans brief doivent explicitement mentionner les limites de couverture
• [PROCESS] Les marques L'Oréal (Armani, LRP) n'ont généralement pas de brief XLSX structuré comme Aesop. La source de vérité est souvent les commentaires Wrike + les attachments visuels (banners)
• Action : Ajout d'une section "Brief Patterns by Brand" dans le SKILL.md pour anticiper le mode QA dès l'identification de la marque
• [PROCESS] Même avec un brief XLSX (Aesop), certains champs PDP ne sont pas couverts (notes aromatiques, descriptions produit). Le brief couvre les modules de campagne, pas les fiches produit

Jusqu'ici, chaque membre devait configurer manuellement ses tokens d'accès (fichiers `~/.config/wrike/token`, variables d'environnement, etc.) pour que les scripts comme `wrike-pull.py` fonctionnent. Processus technique (~30 min/personne/outil), fragile, et source d'erreurs. Un portail web (`oauth-a

• Onboarding : un lien → 3 clics → connecté (vs 30 min de config manuelle)
• Fiabilité : tokens refresh automatiquement, plus d'expirations silencieuses
• Visibilité : l'admin voit qui est connecté à quoi dans un tableau d'équipe

• Tâche Wrike : [4389698756](https://www.wrike.com/open.htm?id=4389698756) — PROMO | SPRING OFFER + EXTENSION - MISE EN LIGNE
• Pages testées : 6 (Homepage EN/FR, Offers EN/FR, PLP EN/FR)
• Résultat : 27/30 PASS, 3 FAIL, 0 EN fallback dans le contenu principal
• Rapport : `output/reports/qa-spring-offer-lrp-2026-03-14.html`
• [NAV] LRP homepage EN est à `/` (racine), pas `/en_CA/`. Homepage FR est à `/fr_CA/home`. Les deux URLs `/en_CA` et `/fr_CA` donnent un 404. C'est un 3e pattern différent d'Aesop (`/en/`) et Armani (`/en_CA/`)

• Tâche Wrike : [4383253544](https://www.wrike.com/open.htm?id=4383253544) — GIO.CA - POY TAKEOVER
• Pages testées : 8 (Homepage, CLP EA Women, CLP EA Men, Offers, PDP POY, PDP SWY Powerfully — EN + FR chacune)
• Résultat : 48/48 PASS, 0 FAIL, 0 EN fallback détecté
• Rapport : `output/reports/qa-gio-poy-takeover-2026-03-14.html`
• [NAV] Le domaine production Armani (`armani-beauty.ca`) n'a aucun lien avec le domaine staging (`giorgioarmanibeauty.lorastagingcanada.com`). Testé 3 variantes avant de trouver. Source de vérité : `sfcc-master/brands/armani-ca.md`

• Tâche Wrike : [4316620085](https://www.wrike.com/open.htm?id=4316620085) — Aesop Scents PDP Updates
• Pages testées : 7 (1 CLP Home + 6 PDPs : Kagerou, Olous, Steorra, Ptolemy, Aganice, Callippus)
• Résultat : 56/56 PASS, 0 FAIL, 0 EN fallback détecté
• Rapport : `output/reports/qa-pdp-updates-scents-2026-03-14.html`
• [TECH] Les IDs numériques dans les URLs Wrike (`id=4316620085`) sont des permalinks, pas des IDs API. Appeler `GET /tasks/4316620085` retourne 400. Il faut d'abord résoudre via `GET /tasks?permalink=https://www.wrike.com/open.htm?id=4316620085` pour obtenir l'ID alphanumérique réel (`MAAAAAEBSmU1`)

Lors d'un QA automatisé, le token Wrike était expiré mais le système retournait silencieusement le vieux token. Les appels API échouaient 5 minutes plus tard sans message clair. Le refresh token pouvait aussi expirer par inactivité sans qu'on s'en rende compte.

• Pre-flight check : `preflight_check(conn, user, service)` est le nouveau point d'entrée unique pour les skills. Il refresh le token, le valide avec un vrai appel API (`GET /contacts?me=true` pour Wrike), et retourne un message d'erreur actionnable si ça échoue — au lieu de retourner un token mort en silence
• Fin de l'échec silencieux : `wrike-pull.py` affiche maintenant l'erreur de refresh + URL de re-auth au lieu de `except Exception: pass`
• Keep-alive : nouveau script `keep_alive.py` qui refresh et valide tous les tokens du DB. À exécuter quotidiennement via cron pour empêcher les refresh tokens d'expirer par inactivité
• Rotation de refresh token : `wrike-pull.py` sauvegarde maintenant le nouveau refresh token si Wrike le rotate lors d'un refresh

Les scripts d'automatisation comme `wrike-pull.py` lisaient les tokens depuis des fichiers locaux (`~/.config/wrike/token`, `~/.config/asana/token`, etc.). Maintenant que les tokens vivent dans la base de données du portail, il fallait un pont entre les deux mondes.

• Export de tokens : chaque carte de service a un bouton "Exporter token" qui écrit le token dans le format attendu par les scripts existants — aucune modification de scripts nécessaire
• Refresh automatique : les tokens sont rafraîchis automatiquement avant expiration (marge de 5 minutes). Plus besoin de se reconnecter manuellement quand un token expire
• Support `--user` : `wrike-pull.py` peut maintenant récupérer le token d'un utilisateur spécifique depuis la base de données avec `--user email@exemple.com`, au lieu de chercher un fichier local

L'équipe utilise 3 outils au quotidien : Wrike (briefs clients), Google Drive (assets) et Asana (gestion interne). La v1.0 ne couvrait que Wrike et Google Drive — il manquait Asana. De plus, l'onboarding d'un nouveau membre nécessitait qu'un admin lui crée un compte manuellement.

• Asana OAuth : 3e carte de connexion sur le dashboard. Même flow que Wrike et Google : un clic, autorisation, connecté
• Lien d'invitation : l'admin génère un lien unique (`/invite/xxx`) et l'envoie au nouveau membre. La personne clique, entre son email, et peut connecter ses 3 comptes immédiatement — pas besoin d'intervention admin
• Tableau d'équipe enrichi : la colonne Asana apparaît dans le tableau de statut, l'admin voit d'un coup d'œil qui a connecté quoi

Chaque membre de l'équipe devait configurer manuellement ses accès aux outils : récupérer des clés API, créer des fichiers de config, comprendre les tokens OAuth. C'était technique, fragile, et prenait ~30 minutes par personne par outil. Un portail web simple où chaque personne se connecte avec son

• Login par email : pas de mot de passe, juste l'email professionnel
• Connexion Wrike : OAuth2 avec stockage sécurisé du token + refresh token
• Connexion Google Drive : OAuth2 avec accès offline pour les scripts d'automatisation
• Dashboard : vue d'ensemble de ses connexions + statut de toute l'équipe
• Base de données : SQLite avec table générique `tokens` (supporte n'importe quel service)

• vs tout-Haiku : ~4x coût tokens, mais erreurs d'interprétation réduites significativement
• vs tout-Opus : ~4x moins cher, vitesse améliorée sur les étapes mécaniques
• Règle : Opus en entrée (comprendre) et en sortie (valider), Sonnet pour l'exécution, Haiku pour le mécanique

], ]

/campaign "lien Wrike" │

• Isolation : chaque agent démarre avec un context window vierge, son prompt contient toutes les règles nécessaires (pas de "voir PROCESS.md")
• Checkpoints : vérification JSON entre chaque étape, STOP si `status: blocked`
• Scripts directs : build_campaign_spec.py et generate_xml.py sont exécutés par l'orchestrateur (pas par un agent) — 0 tokens consommés
• Parallélisme : mode `all` peut lancer les analyses de briefs différents en parallèle
• Reprise : détecte l'état actuel (quel JSON existe déjà) et reprend à la bonne étape

Le pipeline brief → analyse → scope → génération accumule 80-130K tokens si exécuté en une session. 4 solutions appliquées : - XML bien formé (parsé par ET sans erreur)

• HPB : Heroes homepage (par ratio imageConfig 2.55, display name, ou contexte parent)
• Under-HP : Heroes "Under" (display name ou parent contenant "Under")
• Header-Banner : Content assets `header-banner-*` (scheduling via onlineFrom/onlineTo)
• CLP Slot : `clp-*`, `plp-spot*` IDs
• Promo / Cart : GWP, Private Sale, Free Sample

• T1 — Recherche automatique : Parse le backup XML pour trouver les composantes open-ended (pas de `valid_to`)
• T3 — Calcul des dates : Respecte le scheduling cluster de la brand (T04/T05/T08) et le DST EDT/EST
• T4 — XML atomique : Un seul fichier d'import contient le patch de l'existant + la création du nouveau
• T5 — Gestion du parent : 3 scénarios (content-link, section schedulée, standalone)
• T6 — Validation : 8 checks automatiques (unicité ID, préservation `valid_from`, pas d'overlap, etc.)

• 95 unique types across 8 brands: 19 universal, 9 near-universal, 20 majority, 27 minority, 20 exclusive
• tabs/tabitem CONFIRMED UNIVERSAL — previous "Armani-exclusive" designation was wrong (homepage-only analysis artifact)
• library-id absent from all 8 backup XMLs — must be specified manually at import time
• Two scheduling clusters: T04/T05 (Aesop, Armani, Beauty Outlet, Biotherm, LRP) vs T07/T08 (Lancôme, SkinC)
• Beauty Outlet: simplest library (1,427 items, 28 types, 2 locales only)