simonpokorny/knowledgebase

Écrivez une petite entrée propre et conforme au schéma dans le dossier .knowledgebase/ du dépôt. Si le dépôt ne contient pas de dossier .knowledgebase/, arrêtez-vous et demandez à l'utilisateur d'exécuter d'abord la commande /setup-knowledgebase.

1. Choisissez le type :

   Il s'agit de	Type	Chemin
   une affirmation sur le système, vraie et qui mérite de ne pas être redécouverte	finding	.knowledgebase/entries/finding-<sujet-kebab>.md
   une règle de comportement, généralement née d'une erreur	learning	.knowledgebase/entries/learning-<sujet-kebab>.md
   un choix entre alternatives, avec un compromis	decision	.knowledgebase/entries/decision-NNNN-<sujet-kebab>.md

2. Rédigez l'entrée. Les champs du frontmatter, les statuts, les limites et les conventions du corps sont décrits dans ENTRY-FORMAT.md ; lisez-le avant d'écrire. Des exemples concrets sont fournis dans le dossier templates/ de cette extension.

3. Vérifiez que le statut est honnête. Pour les findings et les learnings : verified uniquement lorsque vous avez vous-même prouvé l'affirmation pendant cette session, puis définissez verified-by: agent et incluez la preuve dans le corps (un lien Source ou la vérification que vous avez exécutée). Tout ce que vous n'avez pas pu prouver reste unverified ; ce sont les entrées qu'il est demandé à l'humain de vérifier lors de la relecture. Les nouvelles décisions reçoivent le statut decided et se présentent sous deux formes :

   • Décisions d'implémentation : des choix fondamentaux que vous avez faits vous-même pendant la construction. Enregistrez-les avec le pourquoi et le compromis, avec decided-by: agent.
   • Décisions de planification : prises avec l'utilisateur, non déductibles du code. Enregistrez-les aussi avec decided-by: agent, puis transmettez à l'utilisateur la ligne d'adoption du rapport de fin de session pour que l'entrée devienne decided-by: human. Ne définissez jamais decided-by: human vous-même ; seul un humain peut le faire. Dans les deux cas, une décision peut ensuite être superseded par une décision plus récente.

4. Si l'entrée est un learning qui interdit une commande, ajoutez une regex guard: pour que la règle s'applique d'elle-même. Les règles d'écriture des gardes sont dans ENTRY-FORMAT.md ; testez la regex avec grep -E avant de valider.

5. Validez l'entrée sur la même branche que la modification qui l'a produite, afin qu'elle accompagne le même commit. Ne regroupez pas les entrées pour plus tard.