m1nga/experience-pack

Experience Pack

Une phrase : chaque projet tient son propre journal d'expérience ; un test de frontière distille la partie portable ; seule la partie portable voyage entre les projets.

Fonctionne avec des entrées tapées ou dictées : les descriptions désordonnées, familières, multilingues de « ce qui vient de mal tourner » sont une matière première valable pour une entrée du journal — la compétence les structure, l'utilisateur confirme seulement.

Les deux couches

Couche	Fichier	Propriétaire	Règles de contenu
Journal	EXPERIENCE.md à la racine du projet	le projet	daté, concret, spécificités du projet autorisées ; uniquement de l'expérience de processus — jamais de vérité produit, jamais un registre de décisions
Portable	fichier de leçons portables du projet (ex. LESSONS.md) et/ou le pack de référence de cette compétence	voyage	abstrait, sans nom de produit, vrai dans un AUTRE projet lu par un inconnu

Pipeline : quelque chose se produit → entrée dans le journal (le jour même, tant que ça fait mal) → passe de distillation périodique → leçons portables. Les décisions stratégiques et produits ne voyagent jamais : l'expérience hérite, les décisions meurent.

Protocole A — ENREGISTRER (journal)

Arbitrage racine d'abord. Le journal vit à la racine du projet — donc confirmez qu'il y a BIEN une racine de projet avant d'écrire. Si le répertoire de travail actuel est un répertoire personnel, le Bureau, les Téléchargements ou tout autre emplacement non-projet, demandez à quel projet cette expérience appartient et écrivez le journal là-bas. Ne créez jamais un EXPERIENCE.md dans un répertoire personnel ou le Bureau. Si aucun répertoire de projet ne peut être établi, ou si la cible n'est pas accessible en écriture, ne supprimez pas silencieusement l'entrée : produisez l'entrée entièrement formatée sous forme de texte copiable et dites à l'utilisateur où elle devrait finalement se trouver.

Créez EXPERIENCE.md à la racine du projet dès le premier jour (ou lors de la première utilisation). Ajoutez une entrée lorsque l'un de ces événements se produit : un incident a coûté du temps/de l'argent/ de la confiance ; une méthode a visiblement fonctionné ; un relecteur indépendant a détecté quelque chose que l'auteur a manqué ; un modèle de collaboration a réussi ou échoué ; l'utilisateur a corrigé la trajectoire de l'agent.

Format de l'entrée :

### YYYY-MM-DD — titre
**Ce qui s'est passé :** faits, concrets.
**Ce que nous avons fait :** la réponse, concrète.
**Ce qui a fonctionné / ce qui a échoué :** les deux, honnêtement.
**Coût :** temps / jetons / confiance / reprise.
**Portable ?** oui → <lesson-slug> | pas encore | non (spécifique au projet).

Règles : enregistrez l'expérience de processus, pas les faits produit ; si l'espace de travail a des règles d'hygiène de contamination (noms interdits), le journal les respecte ; ne jamais antidater ou réécrire les anciennes entrées — ajoutez des corrections sous forme de nouvelles entrées. Écrivez les entrées du journal dans la langue dans laquelle le projet vit (suivez l'habitude existante de l'utilisateur ; si inconnue, demandez une fois).

Règles contraignantes (distillées des projets adoptants du pack) :

• L'enregistrement fait partie de « fait ». Un correctif d'incident ne peut être déclaré complet tant que son entrée dans le journal n'existe pas — le journal est une porte, pas un journal intime. (Un adoptant précoce a rempli 8 entrées en un jour parce que rien ne forçait l'écriture au moment de l'incident ; les combats d'incendie ne laissent jamais de temps pour les journaux intimes.)
• Les importations d'amorçage sont légitimes, l'antidatage silencieux ne l'est pas. Lors de l'adoption du pack sur un projet avec historique : datez chaque entrée par sa date d'INCIDENT et déclarez l'importation dans une note datée en haut du journal. Une entrée datée dans le passé sans importation déclarée est une falsification.
• Hygiène de distribution. Le journal contient des informations internes au projet. Dans un dépôt avec un dépôt distant public, gitignorer EXPERIENCE.md par défaut ; publiez uniquement la couche portable testée par la frontière.
• Découvrabilité. Ajoutez une ligne de pointeur vers le fichier de vérité principal du projet (CLAUDE.md / AGENTS.md / carte système / doc d'état) afin qu'un agent sans contexte puisse TROUVER le journal ; un journal non découvrable n'enregistre rien pour la session suivante.
• Un journal gitignoré a besoin d'une voie de sortie déclarée. Gitignorer le journal (règle ci-dessus) le retire également de la récupération par clone/push. Un journal gitignoré DOIT avoir un canal de sauvegarde ou de synchronisation déclaré — un dépôt ou une branche privé(e), un dossier synchronisé, une copie planifiée ; l'utilisateur choisit — enregistré comme une ligne dans la note d'en-tête du journal. Sans cela, un changement de machine ou un re-clone efface silencieusement la mémoire du projet : changer de machine devient une amnésie que personne ne remarque jusqu'à ce que le prochain incident se répète.

Protocole B — DISTILLER (test de frontière)

Pour chaque entrée de journal marquée « Portable ? oui/pas encore », exécutez les tests dans l'ordre :

1. Test de substitution — supprimez chaque nom propre et nombre spécifique. Est-ce que la déclaration enseigne encore quelque chose ? Si elle s'effondre → c'est une décision, elle meurt.
2. Mécanisme vs choix — dit-elle comment les choses fonctionnent ou échouent (mécanisme → hérite), ou qui/quoi/combien a été choisi (choix → meurt) ?
3. Test de re-dérivation — un inconnu intelligent pourrait-il la re-dériver à partir du propre contexte du nouveau projet ? Si elle ne peut venir que de la stratégie de l'ancien projet, c'est l'ancienne stratégie qui parle — elle meurt.
4. Test de coût irrécupérable — sa seule valeur est-elle que des efforts lui ont été consacrés ? Elle meurt.
5. Test de vérifiabilité — sa vérification nécessite-t-elle un nom mort ? Abstraisez-la ou laissez-la mourir.

Les survivantes sont réécrites sous la forme d'une ligne impérative abstraite + pourquoi + comment appliquer, taguée avec provenance (« projet antérieur, distillé · date »). Écrivez la couche portable en anglais (ou bilingue) : le journal peut utiliser n'importe quelle langue dans laquelle le projet vit, mais les leçons portables voyagent vers des inconnus — un idiome local au projet les bloque. Les éléments ambigus par défaut MEURENT — le journal les garde récupérables pour une passe ultérieure. RÉTROGRADATION (rare) : un artefact en forme de stratégie ne pénètre dans un autre projet que comme une HYPOTHÈSE explicite avec une condition de re-validation, et uniquement sur décision de l'utilisateur — jamais silencieusement.

Protocole C — PARTAGER / APPLIQUER (un autre projet apprend de celui-ci)

1. Dans le projet receveur : lisez references/rebuild-experience-pack.md (la saga encapsulée de cette compétence) et/ou le fichier de leçons portables du projet source — jamais le journal du projet source, ses fichiers de vérité, ou sa stratégie.
2. Amorçez le propre EXPERIENCE.md du projet receveur (Protocole A, y compris l'arbitrage racine).
3. Parcourez les cinq conseils du pack comme une liste de vérification de configuration ; adoptez ce qui s'applique ; enregistrez les écarts comme la première entrée du journal du projet receveur.
4. Les leçons adoptées entrent dans le projet receveur taguées avec provenance ; elles sont des contraintes d'ingénierie, pas des décisions utilisateur — l'utilisateur peut reclassifier n'importe laquelle d'entre elles.

Limites — ce que cette compétence ne fait jamais

• Ne copie jamais de stratégie, de faits produit, de personas, de prix, de canaux, de noms de clients ou d'identités de comptes entre les projets — dans les deux sens.
• Ne traite jamais le journal comme un registre de décisions ; les décisions vivent dans les propres fichiers de vérité/décisions du projet avec leurs propres règles de provenance.
• Ne modifie jamais d'autres compétences ou la configuration globale de l'utilisateur.
• Ne lit jamais le matériel mis en quarantaine/archivé d'un projet pour « enrichir » un pack ; l'entrée de distillation est le journal et les fichiers vivants uniquement.

Relation avec les compétences adjacentes

• conclude-rounds — examine les rounds de la conversation en cours. Un utilisateur disant « 复盘 » ou « faisons le point » sur CETTE conversation appartient à cela ; cette compétence possède les post-mortems au niveau du projet qui survivent à la conversation.
• iteration-close — clôt une itération d'une direction continue (distiller, supprimer le superflu, taguer, amorcer). Exécutez le Protocole B d'experience-pack dans le cadre de cela si les deux sont installés ; iteration-close possède le rituel de clôture. Mise en garde que les deux compétences doivent honorer : « l'historique git est l'archive » ne tient QUE pour les fichiers suivis. Le matériel non suivi/gitignoré (PI privé dans un dépôt public) n'a pas d'archive — mettez-le en quarantaine sous une règle locale explicite (par exemple _retired/) avant toute purge ; le supprimer est une perte permanente, pas un nettoyage.
• diagnose-project-rebuild — lorsqu'une direction est REMPLACÉE, le test de frontière ici est le même test utilisé pour décider ce qui survit ; la compétence de reconstruction possède les mécanismes de diagnostic et de purge, et prend UNIQUEMENT la couche portable de cette compétence comme entrée.
• Cette compétence est agnostique au produit et doit le rester : si un nom de projet apparaît jamais dans ce fichier ou ses références, c'est un défaut — retirez-le.

Notes du moteur

Rien ici ne dépend de l'environnement d'exécution d'un fournisseur. « Nouvelle session » et « sonde sans contexte » signifient toute instance d'agent démarrée sans le contexte antérieur — un nouveau chat, un sous-agent, ou un second outil. Là où un environnement d'exécution est absent, appliquez les protocoles manuellement : les formats de fichiers et les tests ci-dessus sont la compétence.

Référence

references/rebuild-experience-pack.md — l'expérience encapsulée et sans nom de provenant d'une véritable saga de contamination en cinq reconstructions : les six portes de contamination, la méthode de réinitialisation du verrou source, la pile de vérification en trois sondes, le protocole de collaboration multi-IA, et les cinq conseils de prévention.