La puissance ne vient pas du modèle mais du harnais qu'on construit par-dessus. Distinguer le modèle (poids, inférence) du harnais (loop, tools, memory) : on réplique le harnais, pas le modèle.

La brique de base : AGENT.md + loop engineering + skills conditionnels + triple mémoire + garde-fous. Le système boucle sur des seuils de preuve vérifiables, ou bascule explicitement en HITL.

• Gain annoncé par le formateur : 3 jours → 8 h — un cas auto-déclaré, ni ×9 ni ×10 calculable.
• Serveur backend local autonome (127.0.0.1:8766), transportable entre machines et entre LLM, sans clé LLM payante supplémentaire (l'OAuth Gmail reste obligatoire).
• Archi rejouable sur GLM 5.2 / Hermes — coût d'inférence réduit, pas un ×20 garanti (cf. slide 11).

Action : reformule ta doc/pitch en une phrase « système bouclé + vérifiable + portable low-cost » et liste tes 3 gains (coût, temps, contrôle) pour un cas d'usage courant.

these:
  faux:  "modele 1000x plus puissant"
  vrai:  "chatbot -> systeme agentique"
distinction:
  modele:  [poids, inference]   # pas replique
  harnais: [loop, tools, memory] # replique par-dessus
systeme:
  composants: [AGENT.md, loop_engineering, skills_conditionnels, triple_memoire, garde_fous]
  arret: "seuils_preuve_verifiables | bascule_HITL"
portabilite:
  serveur_local: "127.0.0.1:8766"
  cle_llm_payante_supplementaire: false   # OAuth Gmail: obligatoire
gain_declare: "3j -> 8h"   # non re-mesure
action: "pitch_1_phrase(systeme_boucle + verifiable + portable_low_cost)"

🤖Voici le robot qui range ta chambre. On ne le rend pas « plus intelligent » : on lui apprend une méthode — regarder, ranger, vérifier, recommencer. Un robot qui range tout seul vaut bien mieux qu'un robot qui répond juste à tes questions.

Les vieux frameworks de prompt (CO-STAR, RTF, RACE, CREATE…) structurent la génération mais n'ont ni vérification, ni outils, ni mémoire, ni correction, ni décision explicite.

Résultat : des tokens consommés sans boucle, de la dérive, aucun rollback, aucun arrêt garanti. Le loop engineering remplace ça par : observer → choisir l'action → exécuter → vérifier (tests / diff / reviewer) → décider (continuer / retry / rollback / stop).

• Automatisation = étapes fixes.
• Boucle = réévaluation à chaque tour sur un objectif vérifiable.
• Utile seulement quand la tâche est vérifiable, outillée, risquée ou agentique.

Action : prends un prompt-framework que tu utilises encore, liste ses 6 manques et mappe-les à un échec concret où la boucle aurait détecté et corrigé.

frameworks_prompt: [CO-STAR, RTF, RACE, CREATE]
manques:    [verification, outils, memoire, correction, decision_explicite]
symptomes:  [tokens_sans_boucle, derive, no_rollback, no_arret_garanti]
loop:       observe -> choisir_action -> executer -> verifier -> decider
decider_enum: [continuer, retry, rollback, stop]
automatisation: steps_fixes
boucle:         reevaluation_par_tour(objectif_verifiable)
utile_si:   [verifiable, outille, risque, agentique]

💬➡️🦾Un robot qui dit juste « range à gauche » ne range pas vraiment. Le vrai robot prend l'objet, le pose, vérifie que c'est bien rangé, puis passe au suivant. La différence : il agit et il vérifie, il ne fait pas que parler.

1. Déclencheur. cron, hook système (PreToolUse / PostToolUse, UserPromptSubmit, SessionStart, Stop), ou heartbeat (sonde de liveness).

2. Boucle de travail. Observer (contexte, logs, mémoire, objectif) → Choisir l'action → Exécuter → Vérifier (tests, typecheck, diff vs spec, second agent) → Décider → Stop sur objectif vérifiable.

3. Vérification. Seuils de preuve (déterministe ou soft) + freins d'urgence.

Action : pour ta prochaine tâche, écris noir sur blanc les 3 blocs (trigger + boucle 6 étapes + seuils + 1 frein) avant tout appel LLM.

trigger: [cron, hook, heartbeat]        # "heartbeat" (pas "Earthbit")
hooks:   [PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop]
loop:
  1_observer:  [contexte, logs, memoire, objectif]
  2_choisir_action: ...
  3_executer:  ...
  4_verifier:  [tests, typecheck, diff_vs_spec, second_agent]
  5_decider:   ...
  6_stop_si:   objectif_verifiable
verification: seuils_preuve(deterministe|soft) + freins_urgence

🔔🔁Le robot démarre quand tu dis « c'est l'heure de ranger » (le déclencheur). Ensuite il tourne en boucle : il regarde la chambre, range un objet, vérifie, recommence. Il s'arrête quand tout est bien rangé.

BOOTSTRAP (agent récursif + interdits) → CONTEXT (objectif, périmètre, E/S, contraintes, risques, critères de réussite). Doute → CLARIFY (question ciblée ou QCM, intégrer, revenir). Sinon LOOP_DESIGN : par étape → objectif + préconditions + outils + test + diagnostic + preuve + succès.

Toutes complètes → READY (créer/valider skills) → EXECUTION. Aucun bug → SELF-TEST → TERMINÉ. Bug → ISSUE (memory_temp + verrou + checkpoint) → DIAGNOSE (1 cause) → FIX (1 correction atomique) → RETEST (échec < 3 → boucle ; = 3 → BLOCKED ; succès → REGRESSION TEST → RESOLVED).

Doute > 10 % n'est pas un pourcentage calibré : c'est une heuristique qualitative (ambiguïté, action irréversible, données sensibles, jugement subjectif) — un LLM n'estime pas sa propre incertitude de façon fiable.

Action : implémente la machine dans AGENT.md en pseudo-états, avec les seuils (déclencheurs de CLARIFY, 3 tentatives, checkpoint) et le code couleur bleu/orange/vert (conception/incident/résolution).

states:
  BOOTSTRAP:  {def: agent_recursif, interdits: [modifier_projet]}
  CONTEXT:    [objectif, perimetre, io, contraintes, risques, criteres]
  CLARIFY:    si doute_qualitatif   # ambiguite|irreversible|sensible|subjectif (pas un % calibre)
  LOOP_DESIGN: par_etape[objectif, preconditions, outils, test, diagnostic, preuve, succes]
  READY -> EXECUTION
  SELF_TEST:  {ok: TERMINE, ko: ISSUE}
  ISSUE:      [memory_temp, verrou, checkpoint]
  DIAGNOSE:   1_cause
  FIX:        1_correction_atomique
  RETEST:     {echec<3: loop, echec==3: BLOCKED, ok: REGRESSION_TEST -> RESOLVED}
couleurs: {conception: bleu, incident: orange, resolution: vert}

🗺️Le robot suit une recette étape par étape. S'il n'est pas sûr de ce que tu veux, il pose une question avant de continuer. S'il casse quelque chose, il essaie de réparer. Après 3 essais ratés, il s'arrête et t'appelle.

• Itérations max : 4 / 10 / 20 selon criticité.
• Timebox : ~30 min.
• Stagnation : 2–3 tours sans progrès mesurable → stop + escalade.
• Budget : plafond de tokens / coût par jour. « Ta seule vraie limite : combien es-tu prêt à dépenser ? »
• Rollback : checkpoint par ISSUE, retour à la dernière version saine.
• HITL obligatoire : ambiguïté, action irréversible, données sensibles, jugement subjectif, budget épuisé.

Zone d'inflexion : trop de tokens de raisonnement → plus de travail utile, juste de la consommation.

Action : ajoute ces 5 lignes à AGENT.md — max_iterations: 20, timebox_min: 30, stagnation_window: 3, budget_tokens: <plafond>, hitl_triggers: [...].

guardrails:
  max_iterations: 20            # 4 | 10 | 20 selon criticite
  timebox_minutes: 30
  stagnation: {window: 3, action: rollback_then_hitl}
  budget_tokens: <plafond>
  rollback: checkpoint_per_issue
  hitl_triggers: [ambiguite, action_irreversible, donnees_sensibles, jugement_subjectif, budget_epuise]
  arret_garanti: true
zone_inflexion: "tokens_raisonnement > seuil => conso_sans_travail_utile"

🛑Sans règles, le robot rangerait toute la nuit — ou casserait tout. Alors on lui donne des limites : pas plus de 20 essais, il s'arrête après 3 échecs, et il demande avant de jeter quelque chose. Comme ça, pas de bêtise.

Ce n'est pas un fichier de prompt : c'est une orchestration. 4 composantes : objectif, environnement (répertoires : agent_root, skills_root, dependance_root, coding_skill, skillMaker_skill), outils / routing, règles (autorisations / interdits).

Structure réelle : AGENT.md (format XML-like) + memory/ + asset/ (templates, procédure-test, loop-engineering, scale-objectif, subagents-workflow, guide-formatage) + script/ (validate-structure.py, validate-coherence.py).

À distinguer : CLAUDE.md natif (mémoire projet fournie par le harnais) ≠ AGENT.md (le framework maison du formateur, posé par-dessus).

Action : crée ou refactorise ton AGENT.md en 4 sections explicites + l'arborescence memory/ asset/ script/ avec les validateurs listés.

AGENT_md:
  role: orchestrateur           # pas un simple prompt
  composantes:
    objectif: ...
    environnement: [agent_root, skills_root, dependance_root, coding_skill, skillMaker_skill]
    outils_routing: ...
    regles: {autorisations: [...], interdits: [...]}
  arborescence:
    - AGENT.md                  # format XML-like
    - memory/
    - asset/    [templates, procedure-test, loop-engineering, scale-objectif, subagents-workflow, guide-formatage]
    - script/   [validate-structure.py, validate-coherence.py]
note: "CLAUDE.md natif (memoire projet) != AGENT.md (framework maison)"

🧠Le robot a un carnet de règles : voilà ton but, voilà où sont tes affaires, voilà ce que tu as le droit de faire et ce qui est interdit. Ce carnet, c'est son cerveau : il décide quoi faire en le relisant.

Attention, deux notions distinctes sont souvent mélangées :

1. Skills natifs Anthropic (« Agent Skills » — le « agentkill » de la vidéo est une mistranscription). Dossier avec SKILL.md (majuscule), frontmatter YAML name / description. Chargement par progressive disclosure : seuls name + description sont en contexte au départ ; le corps est lu quand le modèle décide que le skill est pertinent. Limite description officielle ≈ 1024 caractères (le < 255 du formateur est sa convention perso). Le « routing » n'est pas déterministe : c'est le modèle qui sélectionne d'après les descriptions.

2. Framework maison du formateur : skills/<slug>/ (nom < 64) contient agent.md (minuscule, obligatoire) + memory/ + asset/ + script/, piloté par AGENT.md. Règles : ASCII pur, fichier < 500 lignes, jamais d'installation globale, toujours vérifier l'install et tracer OK/ÉCHEC dans memory_temp.

Action : extrais une compétence récurrente en skills/<slug>/ complet (4 dossiers + règles) et ajoute la ligne de routing correspondante dans AGENT.md.

# 1) Skills natifs Anthropic ("Agent Skills" ; "agentkill" = mistranscription)
skill_natif:
  fichier: SKILL.md             # majuscule
  frontmatter: [name, description]
  description_max: ~1024        # pas 255 (255 = convention du formateur)
  chargement: progressive_disclosure   # name+description d'abord, corps si pertinent
  selection: par_le_modele      # pas un routeur deterministe
# 2) Framework maison du formateur
skill_perso:
  path: skills/<slug>/          # nom < 64
  contient: [agent.md, memory/, asset/, script/]   # agent.md minuscule, obligatoire
  regles: [ascii_pur, fichier<500_lignes, jamais_install_global, verifier_install, tracer_OK/ECHEC->memory_temp]
routing_perso: {code: coding, skill: skillMaker, agent: generation, template: prompt_*, test: procedure-test}

🧰Le robot a une boîte à outils. Pour chaque tâche il choisit le bon outil : un pour les vêtements, un pour les jouets, un pour les livres. Il ne sort l'outil que quand il en a besoin, pas tous en même temps.

• memory.md : persistante — décisions validées, cohérence inter-sessions.
• memory_temp.md : temporaire — journal (avant plan, avant rédaction, avant debug). Pas « auto-nettoyante » : le nettoyage est une instruction donnée à l'agent (purge ou archive en fin de tâche), pas un automatisme.
• exchange.md : bus inter-agents — les sous-agents ont des fenêtres de contexte séparées, un fichier-bus a donc du sens.

Schéma exchange.md : session_id, source_agent, target_agent, task, inputs, outputs, status (EN_COURS | TERMINE | ECHEC).

Action : crée les 3 fichiers avec en-têtes standards ; force l'écriture de memory_temp avant tout DIAGNOSE/FIX et sa purge à RESOLVED.

memoire:
  memory.md:      {portee: persistante, contenu: decisions_validees}
  memory_temp.md:
    portee: temporaire
    journal: [avant_plan, avant_redaction, avant_debug]
    nettoyage: INSTRUCTION_a_l_agent   # PAS auto-nettoyant
  exchange.md:                          # bus inter-agents (contextes separes)
    schema: {session_id, source_agent, target_agent, task, inputs, outputs, status}
    status_enum: [EN_COURS, TERMINE, ECHEC]
regle: "ecrire avant action critique ; purger/archiver memory_temp a RESOLVED"

📓Le robot a trois cahiers : un grand cahier pour ce qu'il ne doit jamais oublier, une ardoise qu'il efface après chaque rangement, et une feuille de passage pour ses copains robots. Attention : l'ardoise ne s'efface pas toute seule — c'est lui qui doit l'effacer quand il a fini.

Objective : le modèle connaît déjà les tests (code : tests, typecheck, diff vs spec, CI, reviewer) → auto-validation possible.

Subjective : pas de critère du réel (analyse, fiscalité, juridique, assurance, positionnement) → le modèle ne sait pas « ce qui est bon » → HITL (Human-In-The-Loop, et non « HTL Review »).

Pas de critère mesurable, ou doute qualitatif → CLARIFY / HITL : l'humain fournit les critères, l'agent les intègre et les stocke dans memory.md comme apprentissage.

Action : pour chaque tâche, marque explicitement dans LOOP_DESIGN « objective » ou « subjective » ; si subjective, insère l'étape HITL + capture des critères dans memory.md.

verification:
  objective:  {exemples: [tests, typecheck, diff_spec, CI, reviewer], mode: auto_validation}
  subjective: {exemples: [analyse, fiscal, juridique, assurance, positionnement], mode: HITL}
bifurcation:
  si:    (pas_de_critere_mesurable) OR (doute_qualitatif)
  alors: HITL                    # Human-In-The-Loop (corrige "HTL Review")
  effet: [demander_criteres, integrer, stocker->memory.md]

🖐️Pour ranger les jouets, le robot sait tout seul si c'est bien rangé. Mais pour choisir ton dessin préféré, il ne peut pas savoir : il te le montre et te demande. Quand il ne peut pas juger seul, il appelle un humain.

• Tâche couplée / partagée → 1 agent.
• Tâches indépendantes → fan-out parallèle (SPAWN).
• Dépendantes (A → B) → séquentiel. Mixte = parallèle sur l'indépendant + séquentiel sur le dépendant.
• Règle : bénéfice de décomposition ≤ coût de coordination → reste en 1 agent. Fichier > 500 lignes = trigger d'évaluation.

exchange.md = bus (lecture/écriture, notifications). Échec d'un sous-agent → memory_temp → loop engineering (max 20 itérations) ou HITL.

Plafond pratique : 3–5 sous-agents concurrents — au-delà, la coordination coûte plus qu'elle ne rapporte (détaillé slide 13).

Action : décompose une tâche en 2 skills indépendants + 1 dépendant ; implémente le fan-out via exchange.md et l'orchestrateur qui compile les sorties.

couplage:
  couple|partage:  1_agent
  independant:     fan_out_parallele        # SPAWN
  dependant(A->B): sequentiel
  mixte:           parallele_sur_independant + sequentiel_sur_dependant
regle_decision: "benefice_decomposition <= cout_coordination => 1_agent"
trigger_eval:   "fichier > 500 lignes"
bus: exchange.md
echec_sous_agent: memory_temp -> loop(max_iter: 20) | HITL
plafond_pratique: "3-5 sous-agents concurrents"   # cf. slide 13

🤖🤖Si le rangement est trop grand, le robot appelle des copains : un range les livres, un autre les habits, en même temps. Mais s'il faut d'abord tout vider avant de ranger, ils le font l'un après l'autre. Et s'ils sont trop nombreux, c'est le bazar : mieux vaut peu de robots.

L'agent n'est pas un chatbot qui pilote une UI : le boot installe un serveur backend local autonome (ex. cleaner-server.mjs sur 127.0.0.1:8766), sans clé LLM payante supplémentaire (l'OAuth Gmail reste obligatoire) ; l'UI frontend est servie par le LLM de session.

Transportable : copie du dossier vers une autre machine, même code/archi vers un autre LLM. Démo : archi codée sur Claude, exécutée telle quelle sur GLM 5.2 / Hermes.

« 20× moins cher » : chiffre annoncé, non re-mesuré. Portable ≠ équivalent : un modèle moins cher peut échouer des boucles ou exiger plus d'itérations. Coût réel = prix token × itérations — à re-benchmarker.

Action : package un agent existant en structure boot + serveur local (.mjs + HTML statique) ; teste le portage sur un autre endpoint (Ollama, GLM…) sans modifier le core.

portabilite:
  agent_as: serveur_backend_local     # ex: cleaner-server.mjs @ 127.0.0.1:8766
  cle_llm_payante_supplementaire: false   # OAuth Gmail: obligatoire
  ui: servie_par_llm_de_session
  transport: [copie_dossier, changement_llm]   # core inchange
cout:
  claim_formateur: "20x moins cher (GLM 5.2 / Hermes)"   # non re-mesure
  realite: "portable != equivalent"
  formule: "cout = prix_token * iterations"   # re-mesurer, pas le prix affiche

📦➡️🏠Le robot n'est pas collé à ta chambre : tu peux le déménager chez papy sans rien réécrire, il emporte ses règles avec lui. On peut même lui mettre un moteur moins cher — mais parfois ce moteur se trompe plus souvent, alors il faut vérifier.

Serveur local 127.0.0.1:8766. Point d'entrée : boot-cleaner.ps1 → cleaner-server.mjs (orchestration, API locale, sécurité, logs, quota, circuit breaker).

Blocs : UI locale (HITL) → Backend → 4 branches :

• Gmail API / OAuth : extraction, action /trash (corbeille récupérable) ;
• Classification locale : règles + scoring ;
• Classification LLM optionnelle : prompt batch + fusion ;
• Apprentissage / persistance : learning, state, feedback, rules éditables.

Flux : extraction → classification hybride → revue humaine obligatoire → corbeille contrôlée. Le core Gmail fonctionne sans clé LLM.

Métriques 70 % prétriés, 200 emails / 15 s, 2500 emails : chiffres annoncés par le formateur, non re-mesurés.

Action : clone la structure (config/lib/ui/state/feedback) sur ton use-case ; implémente 1 règle locale déterministe + HITL avant toute action destructive.

gmail_cleaner:
  serveur: "127.0.0.1:8766"
  entree:  "boot-cleaner.ps1 -> cleaner-server.mjs"
  serveur_role: [orchestration, api_locale, securite, logs, quota, circuit_breaker]
  branches:
    - gmail_api_oauth:        {extract: true, action: "/trash (recuperable)"}
    - classification_locale:  {regles: true, scoring: true}
    - classification_llm:     optionnelle        # prompt_batch + fusion
    - persistance:            [learning, state, feedback, rules_editables]
  flux: "extraction -> classif_hybride -> revue_humaine(obligatoire) -> corbeille_controlee"
  core_sans_llm: true
  metriques_declarees: {pretri: "70%", debit: "200 emails / 15s", volume: "2500 emails"}  # non re-mesure

📧🗑️Le vrai projet, c'est un robot qui trie tes emails comme tes jouets. Il en range 7 sur 10 tout seul dans les bonnes boîtes. Mais avant de jeter un email, il te le montre toujours : « je jette celui-là ? » Et la poubelle n'est pas définitive — on peut ressortir l'email.

⏳ Faits datés du 5 juillet 2026 (fenêtre Fable 5, prix, préprints). Péremption : 2026-08-05 — revérifier avant toute décision fondée sur cette slide. Source de vérité à jour : wiki Zetamind.

• Coûts non linéaires MàJ juillet 2026 : ~3,2× à 5 étapes, > 30× à 50 (audits vendeur invérifiables) ; un système multi-agents consomme ≈ 15× les tokens d'un chat (Anthropic officiel). Anthropic a lancé des spend controls Enterprise le 2 juillet.
• Multi-agents MàJ juillet 2026 : 5/6 systèmes figés sous-performent l'agent unique ; seul le workflow dynamique runtime gagne (+20 pts GAIA — étude séparée ; l'avantage vient peut-être du tooling [compaction, shell, fichiers] plus que du multi-agent). La machine à états pré-câblée est un échafaudage de fiabilité, pas de performance. Plafond pratique : 3–5 sous-agents.
• Mémoire MàJ juillet 2026 : les scaffolds dégradent la perf long-horizon ; la compaction efface silencieusement les contraintes — governance decay : 0 → 30 % de violations après compaction (jusqu'à 59 %), le Constraint Pinning ramène à 0 %.
• HITL MàJ juillet 2026 : courbe en U inversé — résultat de modélisation/simulation (arXiv:2606.08919), pas d'étude terrain, qui motive une étude humaine : trop d'escalades = fatigue du reviewer, système moins sûr.
• Fable 5 MàJ juillet 2026 : redéployé le 1er juillet, fenêtre 50 % des limites hebdo jusqu'au 7 juillet puis crédits d'usage ; les tâches routinières retombent sur Opus 4.8 ; chute BridgeBench due au reroutage de 9 tâches sur 12 vers Opus 4.8, le modèle lui-même n'est pas dégradé, ~2× le prix d'Opus (Crypto Briefing) — décision à prendre avant le 7.
• Termes non sourcés ou imprécis : « 1000× », « agentkill » (→ Agent Skills), « étude Apple juillet 2026 » (→ phénomène réel de context rot / lost-in-the-middle, citation d'origine non sourcée).

Angle mort sécurité MàJ juillet 2026 : un agent avec OAuth Gmail traite du contenu non fiable — chaque email entrant est un vecteur d'injection indirecte. Le HITL avant corbeille protège des faux positifs, pas de l'exfiltration ni de l'action induite. Règles : contenu email = données, jamais instructions ; permissions minimales ; audit des actions sortantes.

Action : ajoute dans AGENT.md un budget_tokens dur + périmètre de permissions minimal + audit explicite des actions sortantes ; mesure le coût tokens réel d'une boucle de 10 itérations sur ton cas.

facts_as_of: 2026-07-05 / valid_until: 2026-08-05 / on_expiry: re-verify via wiki Zetamind before acting

maj_juillet_2026:   # absent de la video source
  couts_non_lineaires: {5_etapes: "~3.2x", 50_etapes: ">30x"}   # audits vendeur invérifiables
  multi_agents_vs_chat: "~15x tokens"        # Anthropic officiel
  spend_controls: "Anthropic Enterprise, 2 juillet"
  multi_agents:
    fige: sous_performe_agent_unique        # 5/6 systemes, chiffres confirmes
    dynamique_runtime: "+20 pts GAIA"       # etude separee ; avantage peut-etre du tooling (compaction/shell/fichiers)
    machine_a_etats: echafaudage_de_FIABILITE   # pas de performance
    plafond: "3-5"
  memoire: {scaffolds: degradent_long_horizon, governance_decay: "0->30% violations (jusqu'a 59%)", constraint_pinning: "ramene a 0%"}
  hitl: courbe_en_U_inverse_SIMULATION      # resultat de modelisation (arXiv:2606.08919), motive etude humaine
  fable5: {redeploy: "1 juillet", quota: "50% jusqu'au 7", prix: "~2x Opus", perf_agentique: "chute = reroutage 9/12 vers Opus 4.8, modele non degrade"}
  non_source: ["1000x", "agentkill -> Agent Skills", "etude Apple -> context rot / lost-in-the-middle"]
  securite_injection_indirecte:
    menace: "email = contenu NON FIABLE -> vecteur injection"
    hitl_protege: [faux_positifs]
    hitl_ne_protege_pas: [exfiltration, action_induite]
    regles: ["email = donnees, jamais instructions", permissions_minimales, audit_actions_sortantes]

⏳ Ce qu'on te raconte ici était vrai le 5 juillet 2026. Les robots changent vite : dans un mois, il faudra revérifier !

⚠️Tout n'est pas magique. Le robot d'équipe mange ≈ 15 fois plus de piles qu'un robot tout seul — et trop de copains, ça marche moins bien qu'un seul robot appliqué. Surtout : un email peut cacher un piège qui dit au robot de faire une bêtise. Le robot ne doit jamais obéir à ce qu'un email raconte — juste le trier.

1. Définir le déclencheur (cron / hook / heartbeat).
2. Analyser le contexte (objectif, périmètre, entrées, contraintes, risques, critères).
3. Vérifier la suffisance pour le loop design (objectif / outils / tests / diagnostics).
4. Si suffisant : builder la boucle et itérer (observer-agir-vérifier-ajuster) jusqu'aux seuils.
5. Si insuffisant : HITL explicite pour les critères mesurables + stockage.
6. Poser les garde-fous avant lancement (itérations, timebox, stagnation, rollback, budget).
7. Structurer l'archi : AGENT.md + skills + triple mémoire + scripts/assets.
8. Appeler les agents secondaires (diagnostic / réparation).
9. Valider sur modèle cher, puis porter tel quel sur low-cost.
10. Dupliquer le core : changer quelques lignes + assets/scripts spécifiques.

Action : exécute aujourd'hui les étapes 1 à 6 sur un petit use-case réel — déclencheur + contexte + loop design + garde-fous écrits dans un AGENT.md neuf + 1 skill squelette.

rebuild_10_etapes:
  1: definir_declencheur            # cron | hook | heartbeat
  2: analyser_contexte              # objectif, perimetre, entrees, contraintes, risques, criteres
  3: verifier_suffisance_loop_design
  4: si_suffisant:   [build_loop, iterer_jusqu_aux_seuils]
  5: si_insuffisant: [HITL_explicite, stocker_criteres]
  6: poser_garde_fous               # iterations, timebox, stagnation, rollback, budget
  7: structurer_archi               # AGENT.md + skills + triple_memoire + scripts/assets
  8: appeler_agents_secondaires     # diagnostic / reparation
  9: valider_modele_cher -> porter_low_cost
  10: dupliquer_core                # quelques lignes + assets/scripts specifiques
done_check: "etapes 1..6 ecrites dans un AGENT.md neuf + 1 skill squelette"

🎓Pour finir : apprendre au robot à ranger tout seul, c'est déclencheur + boucle + règles + demander quand il n'est pas sûr. À toi de jouer — teste le petit quiz !