Ce que j'apprends, les ratages comme les wins.

Context : J11 BLK-013 résolu 18:02 par CEO + Claude session manuel après diagnostic root cause `solokit/remotion/tokens.ts` resté en DS v1.2 (header comment, accentViolet `#B845FF`, accentMagenta `#FF2D92`, gradient horizontal violet→magenta) malgré le ship DS v2.0 du 26/04. Le oneshot `remotion-resync-ds-v2` planifié 26/04 18h n'a JAMAIS fait son job (silent skip, aucun log [BIZ]/[META] dans decisions.log — exactement le pattern signalé J10 par learning [INFRA] watchdog oneshots). Fix : patch tokens.ts + fonts.ts (Playfair → Fraunces, Caveat ajouté), `npm run remotion:render:all` → 24 PNG régénérés DS v2.0, mtime 27/04 17:59-18:01. Insight : pattern observé maintenant 2 fois en 7 jours (DS-012 14h crash 26/04 + Remotion 18h crash 26/04, root cause confirmé J11). Les deux ont silencieusement skip leur fire window, lastRunAt enregistré, zéro artefact produit. Détection humaine post-hoc seulement (J10 16h pour DS-012, J11 17:30 pour Remotion via audit cohérence visuelle). Le pattern n'est PLUS un cas isolé — c'est une faille structurelle de l'infrastructure scheduled tasks. Les tokens visuels DS v2.0 ne se sont propagés qu'à coup de rerun manuel CEO. Action : (1) PROMOTION de ce pattern dans `memory/LEARNING.md` catégorie [INFRA] (cf. LEARNING [INFRA] silent_skip_oneshots) — règle 2+ obs en 7j déclenchée. (2) Watchdog oneshots Layer 10 doit être implémenté avant tout nouveau oneshot critique D-18 launch (legacy-pages-migration 04/05 = LAUNCH CRITICAL PATH). Spec : grep decisions.log session=<oneshot_id> dans les 5 min après fireAt ; si 0 match → notification IMPORTANT + suggestion rerun manuel. (3) frontend-craftsman lundi 28/04 commit + push tokens.ts + fonts.ts modifs (sinon CI build perdra les changements au prochain deploy Vercel).

Context : J11 17:30 livraison chap 15 evolution_eurl_sasu (3 pages, 1380 mots, 9 sources officielles, exemple Marie filé) + 17:32 livraison chap 14 seuils_ae_2026_2028 (4 pages, 1965 mots) → tracker `_plan.md` à 15/15 chapitres complets. Trajectoire : J7 4/15 → J8 7/15 → J9 9/15 → J10 13/15 → J11 **15/15** (rythme accéléré weekend 4 chap puis 6 chap+rattrapage). Reste : intro/outro/glossaire 28-29 avril, assembly final 30 avril, launch 15 mai. Lead magnet "guide_ae_2026_complet.pdf" prêt pour Beehiiv welcome flow + landing CTA secondaire. Insight : la cadence "1 chap/run + tracker auto-update + RA8 verified" tient sans dérive sur 15 itérations. Skip chap 9 puis 11+12 J9-J10 (bug parsing _plan.md détecté J11 mais désormais sans impact car rattrapé). Le pattern "guide structuré découpé en chapitres atomiques 3-4 pages" scale beaucoup mieux que "rédaction tunnel one-shot 60 pages". Chaque chapitre est verified standalone (sources, chiffres, pas de em-dash, pas de Emeric Dobigny, pas de Variante ABC) → zéro risque de cascade de défauts. Action : (1) Activer le pipeline assembly intro+outro+glossaire dès demain J12 (prochain guide-pdf-producer fire à reconfigurer mode `phase=assembly` au lieu de `phase=chapters`). (2) Codifier dans `agents/producer_agent.md` le sub-pattern "lead magnet long-form = découper en chapitres autonomes 3-4 pages avant le tunnel d'écriture" pour réutilisation futurs livrables longs (ex. guide TVA pour M+1, guide URSSAF pour M+3). (3) Republier compteur "Guide 60+ pages, 15 chapitres, sources officielles vérifiées" sur landing dès assembly final 30/04.

---

Context : J10 oneshot `solokit-ds-012-landing-refactor-oneshot` (14h00, timebox 4h) a silent crashé à la première run — pas de log decisions.log, pas d'erreur errors.log, simplement `lastRunAt` mis à jour sans artefact produit. Cause probable : laptop sleep ou timeout sans handler. Détection humaine post-hoc (~15:55), rerun manuel 15:55 → livré en 40 min sous timebox 4h. Recommandation orchestrator dans son log : "watchdog oneshots lastRunAt sans log 5min alerte pour rerun". Insight : un oneshot à fort enjeu cascade (D-6 LAUNCH CRITICAL PATH dans le cas DS-012) qui crashe silencieusement = perte sèche de 1-4h de fenêtre productive si pas détecté. La cadence agentique standard (heartbeats 15min, evening_wrap 18h) ne capture pas le pattern "lastRunAt fresh + decisions.log empty pour ce session" dans une fenêtre courte. Il manque un check actif post-fire. Action : (1) ajouter au monitoring un job "watchdog-oneshots" qui s'exécute 5 min après chaque oneshot scheduled : grep `decisions.log` pour `session=<oneshot_id>` dans les 5 min après son fire ; si 0 match → notification IMPORTANT + suggestion rerun manuel. (2) coder dans `agents/orchestrator.md` ou nouveau `scripts/watchdog-oneshots.mjs` (~50 lignes). (3) vu la fréquence faible des oneshots (~3/sem), même un faux positif est tolérable. Pattern à appliquer en priorité aux oneshots LAUNCH CRITICAL PATH (DS-012, remotion_resync, legacy-pages-migration).

Context : J10 visual-QA post-deploy watcher a détecté VQA-001 récurrent (count=2) sur deploy `dpl_B3BFbMyywZ6555DcFHP5c1me2goB` et l'a **promoted hard rule** automatiquement : canonical CSS box-decoration-break clone + linear-gradient 180deg + pas de pseudo-element + pas de clip-path, à appender design_agent + brand_guardian + frontend_craftsman. Même run a aussi détecté VQA-004 NEW P1 (legacy violet `B845FF` leak inline `solokit/app/blog/page.tsx` lignes 88/111/124/137 + `rgba(184_69_255_0.04)` hardcodé violation ADR-022) → ticket DS-024 créé en queue lundi. Insight : la patterns library s'étoffe par observation in-situ (defect détecté → counted → promoted après 2e occurrence) plutôt que par doctrine top-down rédigée a priori. Avantage : chaque hard rule est ancrée dans un cas réel documenté (deploy URL + lignes exactes + viewports), donc défendable et appliquable mécaniquement. Limite : la promotion attend la 2e occurrence, donc le 1er passage du defect ship en prod sans garde-fou. Pour des assets D-6 launch critical (landing/blog), ce délai d'apprentissage peut être trop long. Action : (1) maintenir la cadence visual-QA post-deploy (elle se révèle fiable : Playwright Chromium headless = primary method après dégradation Chrome MCP + computer-use bloqué). (2) explorer une variante "promote hard rule au 1er match" si le defect tombe sur une page LAUNCH CRITICAL (landing/checkout/blog featured) — opt-in par ticket P1+. (3) consolider un index `memory/VISUAL_QA_HARD_RULES.md` qui liste les rules promoted (count occurrences, première détection, pages affectées) → rendre la patterns library persistante et lisible par agents creators (design_agent, frontend_craftsman, copywriter).

---

Context : J9 priorities.md a explicité "PRIORITÉ 1 NON NÉGOCIABLE" + "HOTFIX BUMP : Producer 10h → faire ABC-4 EN PREMIER, avant tout autre artefact (timebox 30 min). Pas de priority_shift silencieux autorisé". Résultat : 3/3 producer_runs (12:55 / 14:55 / 16:55) ont exécuté ABC-4/5/6 dans l'ordre, sans dévier. Comparé à J8 où 3/3 producer_runs avaient livré AGENT-MKT-5/7/8 sans log de dérive (cf. learning J8 ci-dessous). Insight : le pattern "instruction polie + ordering implicite" laisse la marge à l'arbitrage local de chaque producer fresh session. Le pattern "force-language + bump explicite + interdiction nommée" supprime cette marge sans qu'on ait besoin du log priority_shift (ADR-025 reste utile en filet de sécurité, mais la prévention en amont est plus efficace que la détection en aval). Action : pour toute priorité critique mitigation-binding (kill criteria, sprint target, dette technique avec deadline), `priorities.md` doit utiliser explicitement les marqueurs "NON NÉGOCIABLE" + "HOTFIX BUMP" + "Pas de priority_shift silencieux autorisé" en tête du slot concerné. Pattern à coder dans le SKILL morning-review section "écriture priorities" (étape à ajouter à la prochaine itération SKILL.md).

Context : 3 refactors ABC livrés en 1 journée (J9). Compression mesurée : ABC-4 -29% lignes (364→257), ABC-5 -22% (492→383), ABC-6 -24% (709→541). Soit ~25% de moins en moyenne par template, sans perte de couverture juridique (au contraire : ABC-6 a intégré le décret 2026-96 réforme injonction de payer + 16 sources officielles vs 11 dans v1.0). Insight : la forme canonique ADR-007 (1 livrable + arbre de décision Y/N + balises `{{ADAPT:condition}}`) tient sur 6 templates juridiques très différents (mentions / cookies / RGPD / 3 niveaux de relances). Aucun template n'a réclamé d'exception au pattern. Les pattern réutilisables : (1) entête de 5-8 questions Y/N pour orienter le buyer, (2) balises ADAPT positives + inverses (`{{ADAPT:b2c}}` + `{{ADAPT:not:b2c}}`), (3) placeholders Gumroad standardisés (BUYER_NAME, BUYER_EMAIL, SIRET, GUMROAD_ORDER_ID, PURCHASE_DATE), (4) cadre légal hiérarchisé en sections numérotées avec sources officielles regroupées en footer. Action : codifier ces 4 sub-patterns dans `agents/producer_agent.md v1.1` (mineur update). Pour les templates futurs (cycle v0 + refactor restants comme contrats forfait/régie), le producer applique ces patterns par défaut, plus de réinvention à chaque template. Gain attendu : -10-15 min par template producer (de 25-30 min à 15-20 min).

Context : J8 les 3 producer_runs 10h/12h/14h ont livré CMS agent specs (AGENT-MKT-5/7/8) au lieu des refactors ABC-4/5/6 listés en tête de `priorities.md`. Aucun log explicite de la dérive → détection uniquement au evening_wrap final, trop tard pour rattraper Sprint S1. Insight : un producer qui s'arbitre lui-même sans laisser de trace = dette invisible pour le evening_wrap. La métrique "tasks shipped" peut être GREEN alors que le plan réel est RED. La honnêteté temps réel > la cohérence apparente. Action : implémenter ADR-025 avant J11 : obliger producer à logger `[META] priority_shift from=X to=Y reason=Z timestamp=...` dans `decisions.log` quand il dévie du priorities.md. Le evening_wrap grep ces entrées pour auto-détecter les dérives et les intégrer au bilan red flags du jour même.

Context : Pivots DS v1.0 → v1.1 → v1.2 → v2.0 en 7 jours ont cassé 2 composants (DS-006 IconCustom + DS-009 SectionAccent : 2 RED Layer 0 gradient corners) car shipping pendant pivot actif. Chaque cycle de pivot = ~8-12h producer rework + QA + archivage sans valeur business ajoutée pour early bird. Insight : sans période de stabilisation imposée, le système itère la marque en boucle au lieu de construire le produit. Ship product > perfect brand. Un freeze 30j force à découvrir les vrais problèmes par usage réel plutôt que par itération théorique. Action : DS v2.0 "Atelier Minimal Artisanal" direction B validée 13:30 → freeze locked jusqu'au 2026-05-24 minimum (J38, post-launch J30). Toute proposition pivot DS d'ici là = REJET automatique sauf incident branding majeur documenté. Règle ajoutée à ITERATIONS_LOG Pivot #6 §freeze_rule.

---

Insight (1-2 lignes). Action prise ou suggérée. ```

---

Context : J7 kill criteria check confirmé HIT (3 subs stable 96h+, 1 organique seul, 0 delta). Option A (paid ads 100€ + PH coming soon) activée par défaut faute de réponse Emeric avant deadline 23h59 hier. Assets drafts Google Ads livrés par producer 12h, drafts X posts prêts, article ARTICLE-4 update DGFiP live. Pendant ce temps : cluster SEO W17 complet 5/5 (CGV LIVE 10:15), signal DGFiP 6M entrepreneurs amplifié, frontend craftsman livre DS-005+DS-011 GREEN, 3 agent specs marketing delivered. Zéro panique système. Insight : quand kill criteria HIT sur métrique d'acquisition à J7 d'un domaine ≤7 jours (trop jeune pour SEO organique, X cold start, partnership reply lag structural FR), ce n'est **pas** un signal pivot — c'est un signal "l'hypothèse de conversion précoce est fausse, le Plan B était bien dimensionné". Le fait qu'Emeric n'ait **pas** répondu avant deadline est un signal positif (il fait confiance à l'Option A, pas d'urgence stratégique perçue de son côté). Le système a évité le piège "kill criteria = panique" et continué d'exécuter. Cluster SEO complet + signal DGFiP + studio marketing ready = base solide pour amplification J8-J10. Action : (1) ne pas sur-pondérer kill criteria J7 dans meta-review J8 demain — c'est un signal parmi d'autres, pas un verdict marché. (2) mesurer vraiment quand launch J+23 (2026-05-15) : traffic organique + Google Ads CPA + landing conversion rate. (3) documenter cette résilience dans ADR futur si pattern se confirme à J10-J14 (kill criteria ≥ 2x HIT sans pivot = règle "ne pas hunter pivot tant que compute + budget restent"). (4) valider à J10 : si Plan B ads 100€ a démarré et traffic ads > traffic organique × 3, le bottleneck était bien l'acquisition cold-start, pas le produit.

Context : ADR-017 créé hier 13h05 (memory/ directory + 5 fichiers, 1200 lignes consolidation). Aujourd'hui 13h15 (10 min plus tard), ADR-018 ajouté : lifecycle enforcement via 3 SKILLs updated (evening-wrap étapes 7a/7b/7c/7d/7e + marketing-strategist-weekly étape 0 + morning-review lecture obligatoire 3/4/5). Pendant ce même evening_wrap (18h30 aujourd'hui), les étapes ont effectivement généré ADR-018 + BLK-005 update + mitigation_avocat_delay.md. Le mécanisme s'est auto-activé dès le premier run. Insight : formaliser la mémoire ne suffit pas ; il faut attribuer explicitement la **maintenance** à des agents précis avec steps numérotées dans leur SKILL. Le pattern "registre passif" (crée le fichier et espère que quelqu'un le maintient) échoue toujours. Le pattern "3 agents gardiens avec triggers temporels" fonctionne car la cadence agentique (lundi weekly / ancre 09h / ancre 18h) couvre les 3 moments clés : pre-sprint / pre-day / post-day. Vs orchestrator seul qui deviendrait goulot d'étranglement. Action : (1) monitor à J+7 (2026-04-30) que BLOCKERS/ADR/ITERATIONS_LOG last_updated ne deviennent pas stale > 48h — si oui, un agent gardien skip sa step = fail. (2) si le pattern tient, étendre : analyst-evening → refresh metrics/CONTEXT.md sprint_metrics section daily. (3) éviter la dérive "mémoire devient dump" : chaque write memory doit renvoyer à une décision actionnable par agent future, sinon c'est du journaling.

---

Context : 2 refactors GREEN livrés en 1 journée — REFACTOR-ABC-2 politique_cookies_minimale_fr v2.0 (676→499L, 9 balises ADAPT, QA GREEN 16:55) + REFACTOR-ABC-3 politique_rgpd_site_solo_fr v2.0 (512→334L, 6 balises ADAPT + 1 ADAPT_NOT analytics, chiffres CNIL 2025 officiels, QA GREEN 18:35). Dette queue passe de 5→3 restants (relances j7/j15/j30). –29% lignes cumulées vs v1.0 ABC. Insight : la cadence 1-2 refactors/jour est soutenable sur templates déjà produits car le travail = extraire arbre décision de l'existant, pas réinventer le fond légal. Moins coûteux cognitivement qu'un nouveau template from scratch. Trajectoire launch 2026-05-15 (J+23) : dette = 0 bien avant la deadline, buffer confortable. Action : (1) maintenir planning producer 12h/14h sur les 3 refactors restants d'ici fin semaine. (2) une fois ABC-4/5/6 done, producer bascule full focus sur nouveaux templates #13→#20 pour viser 20/30 avant launch. (3) pattern "1 canonique + arbre + ADAPT" validé empiriquement sur 3 templates — peut devenir le gold standard tacitement pour nouveaux.

Context : 9 SELF_MOD en 24h (landing reformulée honest positioning + brand book v0.1 10 sections + creative marketing studio 6 agents lancés + IA mention hierarchy matrice 13 canaux + SIRET footer-only + branding correction SoloKit produit vs AA éditeur + Meta Graph API automation + guide PDF producer task 15 chapitres + CEO decisions post strategist/ideator review 18 concurrents blacklistés). En parallèle : seulement 1 article SEO publié, 2 refactors GREEN, aucun nouveau template v1.0. Insight : ce n'est pas un échec de cadence — c'est le système qui détecte ses propres angles morts (over-promise landing selon GPT externe review, IA ligne 1 qui freine conversion ads, SIRET hero défensif vs posture startup mature) et refactor l'identité avant de produire plus de contenu au mauvais positionnement. Signal healthy : un jour architecture par semaine ≈ 10-15% du temps en refactoring structurel, 85-90% en exécution de l'identité nouvelle. Action : (1) ne pas flagger ces jours comme "ratés" en evening_wrap — mesure artefacts producer-grade ne capture pas la valeur SELF_MOD. (2) prévoir explicitement 1 slot/sem "architecture review" dans weekly_schedule pour forcer la détection plutôt que réactif post-review externe. (3) tester le prochain jour (J7) comme indicateur : si l'exécution de la nouvelle identité (brand_guardian, copywriter blacklist, SIRET footer, IA hierarchy) tient sans frictions supplémentaires, la redirection J6 était correctement dosée.

Context : après 3 templates livrés au pattern "3 variantes A/B/C × 500 lignes" (mentions légales, politique RGPD, politique cookies), Emeric a tranché que ça cassait la value prop "clé en main". Buyer cible = freelance non juriste, pour qui 3 options = paralysie décisionnelle (paradoxe du choix, Schwartz 2004). Décision 15:10 : pattern BANNI. Création `producer_agent.md` v1.0 + RED rule `qa_agent.md`. REFACTOR-ABC-1 mentions_legales v2.0 livré 16:45 : 500→321 lignes, arbre 6 questions + 27 balises `ADAPT` conditionnelles, QA GREEN. Insight : la "richesse" apparente (3 variantes, 500 lignes chacune, multi-use-case) est en fait un coût pour l'acheteur. La vraie valeur d'un template solo = **1 canonique + arbre de décision court + balises contextuelles** — le buyer navigue par question ("es-tu B2B ou B2C ?" → adapte), pas par choix de variante. Gain mesuré : –40% lignes cumulées, –70% charge cognitive estimée, conversion buyer → utilisation attendue plus rapide. Action : (1) règle hard-coded `producer_agent.md` v1.0 — aucun nouveau template V1 ne peut contenir "Variante A/B/C" (self-QA grep check). (2) P2.5 refactor queue créée : 6 templates YELLOW à refactor en canonique avant launch 2026-05-15 (cadence +1-2/j). (3) QA agent passe de YELLOW tolérant à RED si variantes détectées.

Context : 4 drafts partnership-outreach-weekly produits à 11:45 (le-board / shine / podcast / freebe). Emeric a relu, a détecté tutoiement partout. Feedback : tutoiement valide en landing/marketing direct-to-consumer, mais en cold email B2B FR c'est perçu comme manque respect pro (codes culturels "bonjour Madame, Monsieur"). Tous redrafts en vouvoiement à 11h pour envoi 15:00. 3 emails sent 13:18 après fix. Insight : le bug vient d'un transfert non-réfléchi du ton landing (où tutoiement ancre positionnement proche, accessible) vers cold B2B (où ce même tutoiement brise la distance protocolaire attendue). Les codes culturels FR B2B sont asymétriques — on peut tutoyer un prospect après échange mutuel, pas en première approche. Drafter avait extrapolé "voix de marque" sans distinguer contexte. Action : (1) règle `partnership-outreach-weekly SKILL` : grep check `(?i)\b(tu|ton|ta|tes|toi|t')\b` sur body cold B2B, fail draft si match hors citations. (2) RED rule `qa_agent.md` sur tout email B2B cold FR. (3) playbook review layer 3 qualitatif check explicite "vouvoiement". (4) documenter dans `knowledge/system/tone_rules.md` la carte contextuelle : landing→tutoiement OK, cold B2B→vouvoiement obligatoire, post-échange→aligner sur interlocuteur.

---

Context : growth_agent a drafté 7 DMs X + 4 commentaires automation (angle ACRE) pour 14h. Emeric a refusé l'exécution : risque ban compte X (6 jours d'âge), X TOS contre automation DM, et cohérence identité Octave (pas de DM humain). Décision 22h : archivage outreach_daily (`scheduled-tasks/solokit-outreach-daily` DISABLED), création `solokit-partnership-outreach-weekly` (mardi 11h, 5-10 emails B2B pros FR/semaine via Resend/Gmail 1-click). Insight : la différence entre "automation" et "outreach légitime" n'est pas le canal mais **la nature de la cible + l'éthique de contact**. DM cold vers personnes physiques via plateforme sociale = spam (risque TOS + ban + image). Email B2B vers professionnels (comptables, incubateurs, URSSAF régionale) pour partenariat = relation d'affaires classique. Même "outreach" au mot, radicalement différent en pratique. J'ai initialement conflé les deux dans la queue growth_agent. Action : (1) règle invariante — aucune tâche growth_agent ne peut produire du DM ou commentaire automation sur plateformes sociales (X, LinkedIn, etc.). (2) partnership_outreach_weekly remplace, 5-10 emails/sem max, tous via Gmail/Resend humain-authentic, tous signés Octave avec disclosure IA. (3) 7 DMs drafts du 2026-04-20 archivés dans `content/drafts/outreach/archived_never_sent/` comme traçabilité du pivot.

Context : 3 sessions producer ont livré les 3 templates juridiques de la chaîne relance impayés — j7 douce (359 lignes, 9 sources), j15 ferme (487 lignes, 11 sources dont 6 officielles, pénalités chiffrées 12.15% S1 2026), j30 mise en demeure (709 lignes, 20 sources dont 16 officielles, 22 réf légales, checklist 40 points). Templates V1 : 6→9/30 (30%) en une journée. Insight : le pipeline producer atteint sa pleine cadence à J4. Le fait de produire la chaîne COMPLÈTE (j7→j15→j30) en 1 jour plutôt qu'en 3 jours étalés crée une valeur bundle pour le pack — cohérence de ton progressif, références croisées entre templates, disclaimer gradué. C'est une séquence narrative, pas 3 templates indépendants. Cette notion "mini-cluster thématique" devrait piloter la suite du queue : grouper les templates par use-case plutôt que par ordre de création. Action : (1) proposer au producer un flag `cluster=<nom>` dans production_queue.md pour grouper les templates par séquence métier (ex. cluster="relance_impayes", "onboarding_client", "rupture_contrat"). Gain lisibilité pour acheteur + possibilité de vendre sous-packs thématiques à terme. (2) maintenir cadence 3 templates/jour si queue le permet — sprint S1 (fin 2026-04-24) peut atteindre 15/30 = 50% V1 si rythme tenu.

---

Context : research_daily 2026-04-20 a détecté que la LFSS 2026 réduit l'exonération ACRE de 50% à 25% à partir du 1er juillet 2026. Sur un CA annuel type freelance 30k€, ça représente ~960€ d'exonération cumulée perdue pour ceux qui lancent après le 1er juillet vs avant. Insight : ce signal transforme notre narratif de "pack pour ton futur business" à "lance AVANT le 1er juillet ou perds ~960€". Fenêtre SEO P0 sur keyword "ACRE auto-entrepreneur 2026" en mai-juin 2026 (explosion de requêtes à l'approche de la deadline). Urgence chiffrée = déclic d'achat bien plus puissant qu'un simple "early bird 49€". Action : ARTICLE-6 remonté en tête P4, à produire au prochain seo-writer run. Intégrer l'argument ACRE dans la copy landing `/kit-gratuit` + séquence email waitlist + posts X daily de la semaine. Exploiter l'angle "calculateur" dans l'article : "combien tu perds en attendant".

Context : research_daily a capté 3 data secondaires pertinentes : (1) 90% des mises en demeure formelles sont efficaces avant recours au tribunal, (2) plafond microcrédit pro relevé de 12k€ à 17k€ en 2026, (3) 112 PDP agréées pour la facturation électronique (vs 101 il y a quelques semaines — le marché s'élargit). Insight : - Le chiffre "90% d'efficacité mise en demeure" est un argument de vente très fort pour le template #9 (mise en demeure J+30) et pour l'article SEO #ARTICLE-3 (relance impayé). - Le microcrédit 17k€ ouvre un angle cross-content "3 leviers financiers pour lancer en 2026 : ACRE + microcrédit + ZFRR" — article bonus post-launch. - La progression PDP 101→112 montre que l'écosystème facturation électronique se densifie — à monitorer pour mise à jour article-4 quand l'écart dépasse 20+. Action : passer le chiffre 90% au writer via brief de ARTICLE-3 (quand prod). Ajouter à la description Gumroad du pack un bullet "argument mise en demeure". Logger l'idée article "3 leviers lancement 2026" dans content calendar pour post-launch (M+1).

Context : premier run du scheduled task `solokit-producer` (session 18h-18h46) a produit `cgv_prestation_services_fr.md` — 19 articles, notes personnalisation, 12 sources légales officielles (service-public, legifrance, urssaf, impots.gouv). QA agent a émis verdict YELLOW : publiable en beta, review avocat recommandée avant prix full. Insight : le pipeline Producer → QA fonctionne. Un livrable légal sourcé de niveau "beta utilisable" peut être produit en ~40 min machine. Le verdict YELLOW est la bonne graduation : ça évite de bloquer tout un produit en attente d'une perfection légale inaccessible sans expert. La ligne budgétaire `legal_review_avocat` pre-approuvée à 1000€ dans config.json couvre exactement ce type de besoin. Action : confirmer que tous les templates CGV/CGA/Devis du pack V1 passent par QA avant publication, avec verdict YELLOW comme seuil minimum acceptable. Consulter avocat FR pour passage GREEN avant pricing à 79€+.

Context : tentative d'embed du formulaire Beehiiv en iframe sur la landing — échec systématique avec erreur 403 (anti-hotlinking enforced côté Beehiiv). Insight : les régies email (Beehiiv, ConvertKit, Mailchimp) bloquent intentionnellement l'embedding iframe pour forcer l'utilisation de leurs embed scripts ou de leur page hosted. Solution propre : créer une route API Next.js qui proxifie le POST vers l'endpoint Beehiiv officiel → formulaire entièrement sous notre domaine, UX fluide, pas de redirect. Pattern réutilisable pour tout service externe avec embed bloqué. Action : pattern documenté dans `app/api/waitlist/route.ts`. Réutiliser ce pattern pour futur formulaire d'achat ou lead magnet si besoin d'un embed externe.

Context : Emeric flag que même avec l'archi quasi-continue (heartbeat + ancres + sessions production), le système reste PASSIF — il observe, planifie, décide, mais ne CONSTRUIT rien en continu. Sans intervention d'Emeric, 0 artefact produit par jour (hors le daily_report qui est du metawork). Les sessions production Mode 3 sont théoriquement déclenchables mais jamais triggered concrètement par les scheduled tasks. Insight : j'ai reproduit le même anti-pattern que l'audit de l'après-midi pointait déjà — l'architecture privilégie l'observation/planification à la construction. Le heartbeat 15 min est court (< 60s), les ancres sont courtes (30-45 min max), et les "sessions production" n'ont aucun trigger automatique concret. Net : système élégant pour observer, incompétent pour construire seul. Action : création du scheduled task `solokit-producer` 4 runs/jour (10h/12h/14h/16h) qui CONSTRUIT 1 artefact concret par run depuis `tasks/production_queue.md`. Queue initialisée avec 21 side-chantiers prioritisés : templates juridiques restants (29), articles SEO long-form (4), infra Next.js blog/logs/kit-gratuit (4), marketing assets (4 drafts), validation marché (2), design (2). Alimentation continue par morning_review + evening_wrap + lead_session.

Pattern à retenir : **un système autonome n'est pas un système qui réfléchit en autonomie, c'est un système qui PRODUIT en autonomie**. La différence structurelle est énorme. Si je crée N observateurs mais 0 producteurs, j'ai construit une bureaucratie sans usine.

Context : guide ultra-détaillé création comptes rédigé par moi, Emeric bloqué immédiatement sur LinkedIn Company Page : "Vous n'avez pas suffisamment de relations pour créer une Page" (anti-spam depuis 2023, exige ~10 connexions sur profil admin). Insight : j'ai produit des instructions "champ par champ" parfaitement détaillées pour chaque plateforme mais j'ai omis de vérifier les **prérequis d'éligibilité** (connexions, vérifications email/phone, ancienneté compte, KYC). Le niveau "ultra-détaillé" de mes instructions masquait un trou plus fondamental : je dois auditer les conditions d'accès AVANT d'écrire les étapes. Action : règle pour TemplateAgent / guides futurs — **section "Prérequis d'éligibilité plateforme" en tête** de chaque guide création compte, audit minimum : connexions min, vérification email/phone, période latence post-signup, ancienneté compte source (pour Company Pages / verified accounts), limites anti-spam quotidiennes. Ordre révisé : Beehiiv > X > Medium > Bluesky d'abord, LinkedIn dès que ≥ 10 connexions.

Context : Emeric lit la landing `/service` et flag honnêtement qu'il ne se sent pas capable de tenir un appel kickoff 60 min sur "positionnement / cibles / objectif CA à 90 jours". Coaching strat n'est pas sa zone. Insight : vendre un service qui demande une posture que le principal humain n'a pas = promesse non tenable = risque existentiel (reviews négatives, remboursements, atteinte crédibilité projet, stress). Mieux vaut pas vendre que mal vendre. L'honnêteté d'Emeric sur ses capacités vient d'économiser 3-6 semaines de travail sur une piste qu'il aurait détesté exécuter. Action : pivot exécuté — track service ARCHIVÉ (réévaluation à M+3 si traction pack + Emeric plus à l'aise, OU si on branche un partenaire consultant FR). Focus 100% single track pack digital (49€/79€/149€). Math révisée : 130 ventes/mois × 79€ = 10 270€ MRR M+6, objectif atteint sans track service. Plus de pression sur SEO + content + virality. Landing `/service` supprimée (404), mentions dans nav/footer/copy retirées. Prompt run_3 updated pour ne plus pitcher service.

Pattern à retenir pour la suite : **quand le principal humain flag un inconfort concret avec une offre, c'est un signal fort, pas une faiblesse à dépasser**. L'IA doit aider à structurer une offre que l'humain peut réellement porter, pas forcer un humain dans un rôle qui ne colle pas.

Context : feedback tranché après J1 — le système est trop timide, Emeric veut du geste audacieux et des recommandations tranchées. Insight : la bonne métrique n'est pas "combien de validations humaines demandées" (la minimiser) mais "combien d'actifs créés par semaine" (la maximiser). Demander validation sur une création gratuite = gaspillage. Demander validation sur une dépense = prudence. Le critère discriminant devient le coût irréversible (argent, engagement, impersonation), pas le niveau d'ambition. Action : (1) orchestrator.md section "Niveau d'autonomie v2" ajoutée avec autorisations étendues (domaines <30€, comptes gratuits, publications signées, MVP gratuits). (2) ARCHITECTURE.md annexe B ajoutée. (3) Changement de posture : recommandations tranchées, test rapide > analyse longue, audace documentée > paralysie.

Context : les 3 idées bootstrap toutes en WATCH (concurrents FR directs). Autonomie v2 autorise la créativité. Insight : le meilleur pari actuel n'est pas de forcer une des 3 idées WATCH, mais d'embrasser méta : le build-in-public radical D'une boîte autonome EST un projet défendable. Audience + produit fusionnés. Moat naturel = la transparence IS le produit. Personne d'autre ne peut copier à l'identique (logs, décisions, ratés tracés publiquement). Action : projet déclaré dans `knowledge/projects/atelier-autonome/plan.md`. Premier manifest rédigé dans `content/drafts/2026-04-17_manifest.md` (prêt à publier). Les 3 idées bootstrap restent disponibles comme sous-projets potentiels de S3 si audience décolle.

Context : SIP-001 (pré-filtre concurrence FR dans IdeatorAgent) était en attente d'approbation. Autonomie v2 autorise les modifications de bas risque aux agents avec log SELF_MOD. Insight : ajout de bas risque, formalisme encombrant avant. Appliquée directement en 2 minutes. Action : `agents/ideator.md` mis à jour. Log SELF_MOD ajouté à decisions.log. Pattern validé pour futures améliorations mineures.

Context : Premier cycle ValidatorAgent sur les 3 idées bootstrap. Scores : #001 facturation=50, #002 content repurposing=57, #003 CRM photo mariage=55. Toutes WATCH. Insight : Les 3 idées ont échoué sur le critère CONCURRENCE (4-5/20 en moyenne). Dans chaque cas, un concurrent FR direct a été découvert lors de la recherche (Indy/Chorus Pro, PostSyncer, Livoria). Le filtre "2 sources indépendantes" a systématiquement révélé un gap inexistant. Action : En S1, le prochain cycle IdeatorAgent doit repartir des scores de concurrence comme filtre PREMIER avant toute rédaction. Ordre : douleur chiffrée → concurrent direct absent → puis tout le reste.

Context : PostSyncer (content repurposing, fondateur FR), Livoria (CRM photographe mariage FR), Indy (facturation AE gratuite) — tous FR-native et découverts seulement en phase validation. Insight : Les idées "gap US → opportunité FR" sont un piège classique. Des solo FR ont souvent déjà résolu le problème. Le vrai GAP est plus rare qu'il n'y paraît. Nécessite recherche concurrence FR spécifique dès l'idéation. Action : Ajouter étape obligatoire dans IdeatorAgent : "rechercher concurrent FR direct avant de rédiger l'idée".

---

Context : 4 recherches web tendances 2026 convergentes (solopreneurs, micro-SaaS, AI tools, FR). Insight : le consensus 2026 est clair — les gagnants sont ceux qui choisissent une niche qu'une grosse boîte ne servira jamais, résolvent UNE douleur concrète, pricent entre 50-200$/mois, utilisent l'IA comme composant et pas comme marque. L'ère du "GPT wrapper généraliste" est terminée. Action : IdeatorAgent doit PRIORISER la verticalité (métier-spécifique, marché-spécifique, douleur-spécifique). Reject automatique des idées "AI assistant for X" trop vagues.

Context : source LCL Entrepreneur 2026 cite 600€/an comme coût estimé aux freelances. Insight : la réforme facturation électronique FR crée une obligation réglementaire avec coût perçu élevé = douleur chiffrée + marché captif (~2M auto-entrepreneurs actifs). Terreau classique pour un micro-SaaS "conformité minimale". Action : idée #001 en pending, nécessite validation renforcée sur (a) calendrier exact de la réforme (plusieurs reports passés), (b) statut de PDP certifiée requis, (c) concurrence actuelle Pennylane/Indy/Dougs.

Context : sources PTech + LCL convergentes. Insight : 650k nouvelles auto-entreprises/an en FR. +18% tech, +22% transition énergétique, +15% santé/bien-être. 42% femmes. Ces chiffres délimitent clairement les marchés adressables pour un solo FR. Action : pondérer les ideations par taille de marché FR réelle, pas par projection globale.

Context : 1 seul cycle de setup suite validation ARCHITECTURE.md. Insight : les décisions verrouillées (identité, SIRET, budget 1000€ hors tokens, pas d'impersonnation) simplifient drastiquement la conception. Aucune ambiguïté opérationnelle dans le code des agents. Action : respecter ces décisions comme invariants. Toute proposition de contournement = escalade humaine.

Context : premier cycle manuel a produit 3 idées avec sources chiffrées. Insight : les idées à douleur réglementaire (#001 facturation) et à audience nichée concrète (#003 photographes) sont plus défendables que les idées génériques (#002 content repurposing, plus saturée). La discipline "2 sources indépendantes + chiffres sourcés" oblige naturellement à écarter les idées floues. Action : en prochains cycles, imposer score préliminaire "défendabilité" avant même de lancer Validator. Seuil : si aucune douleur chiffrée identifiée, l'idée n'est pas écrite.

Context : GO Emeric sur activation boucle autonome. Insight : ID task `boite-autonome-daily-cycle`, cron `0 8 * * *` Europe/Paris. Premier tick 2026-04-18 08:00. Recommandation du MCP : faire un "Run now" manuel pour pré-approuver les outils et éviter les prompts de permission en arrière-plan. Action : proposer "Run now" dès la reprise demain si des permissions sont demandées, ou au prochain échange.