AGENTS.md

Ces instructions s'appliquent à tout le dépôt mcp-framework.

Forge

Le dépôt est hébergé sur Gitea.

Pour les actions distantes liées au dépôt, utiliser tea plutôt qu'un autre CLI. Exemples : lire une issue, s'assigner une issue, créer une branche de travail, ouvrir une PR, commenter une PR.

Issues

Quand on commence à travailler sur une issue, il faut se l'assigner immédiatement.

Si le travail correspond directement à une issue existante :

lire l'issue
se l'assigner
créer une branche dédiée
implémenter et valider localement
pousser la branche
ouvrir une PR liée à l'issue

Branches

Préférer une branche de travail dédiée par issue ou sujet.

Nommer la branche de manière explicite, par exemple :

issue-4-structured-secrets
issue-8-update-drivers
docs-readme-installation

Quand une branche est créée pour répondre à une issue et que cette issue porte le label enhancement, nommer la branche au format feat/<issue_short_name>.

Éviter de développer directement sur main quand le changement mérite une PR ou une validation fonctionnelle.

Pull Requests

Par défaut, quand un changement doit être validé via un vrai use case, une intégration avec un autre dépôt, ou une revue fonctionnelle, ouvrir une PR plutôt que pousser directement sur main.

Le corps de PR doit en général contenir :

un résumé clair de ce qui a été implémenté
la validation locale déjà effectuée
une proposition de test manuel ou d'intégration si pertinente
le lien explicite avec l'issue, idéalement via Closes #<numéro>

Si le changement a un impact possible sur un dépôt consommateur comme graylog-mcp ou email-mcp, ajouter dans la PR ou dans un commentaire de PR un plan de validation ou d'adaptation pour ce dépôt.

Validation

Avant d'ouvrir ou de mettre à jour une PR :

exécuter les tests locaux pertinents
signaler clairement ce qui a été validé
signaler explicitement ce qui n'a pas pu être testé

Commits

Conserver des messages de commit au format conventional commits, conformément aux règles globales.

2.1 KiB Raw Blame History