First

Réponse Directe¶

Il semble probable que vous puissiez créer un workflow MFO pour automatiser les revues de PR sur GitHub, similaire à Qodo Merge, avec des analyses supplémentaires.
La recherche suggère que MFO prend en charge les webhooks, les appels API et les interactions avec les LLM, ce qui est essentiel pour ce projet.
Les preuves penchent vers la possibilité d'ajouter des fonctionnalités comme l'analyse des issues et la génération de descriptions structurées pour les agents IA.

Configuration du Workflow¶

Pour commencer, configurez un webhook GitHub pour déclencher le workflow MFO lors de la création ou de la mise à jour d'une PR. Cela permettra à MFO de réagir aux événements en temps réel.

Tâches Principales¶

Le workflow inclura des tâches pour : - Récupérer les détails de la PR via l'API GitHub. - Effectuer une revue de code, décrire les changements et suggérer des améliorations à l'aide d'un modèle de langage (LLM). - Analyser les issues liées en profondeur (analyse de premier principe) et mapper ces issues au code modifié. - Générer une description structurée de la PR pour un agent IA, par exemple en JSON.

Exemple Simplifié¶

Imaginez un processus où MFO reçoit une notification, analyse le code avec un LLM comme GPT-4, et publie un commentaire sur GitHub avec les résultats. Par exemple, il pourrait dire : "Revue : Améliorer la documentation. Analyse de l'issue : Problème de base lié à la gestion des erreurs."

Points à Noter¶

Assurez-vous d'avoir un jeton GitHub sécurisé pour les appels API et configurez les conditions pour gérer les PR sans issues liées. Cela pourrait nécessiter des ajustements selon les limites de tokens des LLM ou les restrictions de l'API GitHub.

Note Détaillée¶

Cette note explore en profondeur la création d'un workflow détaillé avec MFO MindFlight AI Orchestrator pour automatiser les revues de pull requests (PR) sur GitHub, en reproduisant les fonctionnalités de Qodo Merge (anciennement PR-Agent) tout en ajoutant des spécificités comme l'analyse de premier principe des issues, la correspondance entre issues et codebase, et une description automatique de la structure de la PR adaptée pour un agent IA codeur. Nous examinerons les capacités de MFO, la conception du workflow, et les détails techniques nécessaires pour sa mise en œuvre.

Contexte et Objectifs¶

Qodo Merge est un plugin qui s'intègre à GitHub et GitLab pour automatiser les revues de PR, offrant des commandes comme /review, /describe, et /improve pour des analyses automatiques ou des suggestions d'amélioration. Votre objectif est de créer un workflow MFO qui accomplisse le même travail sur GitHub, avec des ajouts spécifiques : - Analyse de premier principe des issues, c'est-à-dire décomposer les problèmes en leurs composantes fondamentales. - Correspondance entre une issue et la codebase, en identifiant les parties du code modifiées liées à l'issue. - Description automatique de la structure de la PR, adaptée pour un agent IA codeur, par exemple sous forme JSON.

MFO, selon la documentation disponible sur Mindflight AI Documentation, est une plateforme pour orchestrer des workflows AI, en particulier ceux impliquant des modèles de langage (LLM) et des applications de bots. Elle prend en charge la définition de workflows en YAML, l'intégration de webhooks, et l'utilisation d'outils comme ceux de LangChain pour des tâches variées.

Analyse des Capacités de MFO¶

MFO offre plusieurs fonctionnalités clés pour ce projet, comme détaillé dans la documentation : - Intégration de Webhooks : MFO peut recevoir des notifications de services externes comme GitHub via des webhooks, déclenchant des workflows pour des événements comme la création ou la mise à jour d'une PR. Par exemple, la documentation mentionne des URL comme https://slop.internal.net/webhooks/github/repo_push pour des événements GitHub, avec vérification de sécurité via X-Hub-Signature-256. - Moteur de Taskflow : Les workflows sont définis en YAML et exécutés via go-taskflow (voir go-taskflow sur GitHub), permettant l'orchestration de tâches comme des appels API, des interactions LLM, et des exécutions d'outils. - Outils et Tâches : MFO prend en charge des types de tâches comme mfo_api_tool_execute pour exécuter des outils (par exemple, system_http_request pour des appels HTTP) et mfo_api_chat_send pour interagir avec des LLM. Les outils peuvent inclure ceux de LangChain, comme des outils de recherche web, d'exécution de code, ou de traitement de texte. - Gestion des Données : Les tâches passent des données entre elles via des clés de sortie (e.g., ${task_id.output_key}), facilitant un flux de travail fluide.

Un exemple donné dans la documentation, process_email_workflow.yml, montre l'utilisation de mfo_api_chat_send avec un fournisseur comme OpenAI pour analyser des emails, ce qui est similaire à ce que nous ferons pour analyser les PR.

Conception du Workflow¶

Pour reproduire Qodo Merge et ajouter les fonctionnalités demandées, le workflow doit être déclenché par un webhook GitHub et inclure les étapes suivantes, détaillées dans un tableau pour plus de clarté :

Tâche	Description	Type de Tâche	Outil/Modèle
Récupérer les détails de la PR	Appeler l'API GitHub pour obtenir les informations de la PR (titre, corps, fichiers modifiés).	`mfo_api_tool_execute`	`system_http_request`
Récupérer le diff de la PR	Obtenir le diff complet de la PR via l'API GitHub.	`mfo_api_tool_execute`	`system_http_request`
Revue de code	Analyser le diff avec un LLM pour fournir des commentaires constructifs.	`mfo_api_chat_send`	LLM (e.g., GPT-4)
Décrire les changements	Générer un résumé des changements basés sur le titre, le corps et les fichiers.	`mfo_api_chat_send`	LLM (e.g., GPT-3.5-turbo)
Suggérer des améliorations	Proposer des améliorations basées sur la revue de code.	`mfo_api_chat_send`	LLM (e.g., GPT-4)
Extraire le numéro d'issue	Extraire le numéro d'issue du corps de la PR (e.g., "fixes #123").	`mfo_api_chat_send`	LLM (e.g., GPT-3.5-turbo)
Récupérer les détails de l'issue	Appeler l'API GitHub pour obtenir les détails de l'issue, si applicable.	`mfo_api_tool_execute`	`system_http_request`
Analyse de premier principe	Décomposer l'issue en composantes fondamentales et suggérer une voie de solution.	`mfo_api_chat_send`	LLM (e.g., GPT-4)
Mapper l'issue au codebase	Relier l'issue aux fichiers modifiés en expliquant la relation.	`mfo_api_chat_send`	LLM (e.g., GPT-4)
Générer la structure de la PR	Créer une description structurée (e.g., JSON) de la PR pour un agent IA.	`mfo_api_chat_send`	LLM (e.g., GPT-3.5-turbo)
Publier un commentaire	Poster les résultats sur la PR via l'API GitHub.	`mfo_api_tool_execute`	`system_http_request`

Détails Techniques¶

Authentification : Les appels API GitHub nécessitent un jeton d'accès personnel (PAT). Ce jeton doit être stocké de manière sécurisée dans MFO, par exemple dans la mémoire ou la configuration, et utilisé dans les en-têtes HTTP comme Authorization: Bearer ${github_token}.
Gestion des Conditions : Certaines tâches, comme l'analyse de l'issue, ne s'exécutent que si une issue est liée (condition : ${extract_issue_number.issue_number} != null).
Limites et Considérations :
Les diffs de PR peuvent être volumineux, dépassant les limites de tokens des LLM. Dans ce cas, il pourrait être nécessaire de traiter les fichiers individuellement ou de résumer les changements.
Les appels API GitHub sont soumis à des limites de taux, donc il peut être utile de gérer les erreurs ou de mettre en cache les réponses.
La publication de commentaires doit respecter les limites de caractères de GitHub (65536 caractères pour un commentaire), ce qui pourrait nécessiter un résumé ou une division en plusieurs commentaires.

Exemple de Workflow en YAML¶

Voici un aperçu du workflow en YAML, basé sur les capacités de MFO et les exemples fournis :

workflows:
  - id: github_pr_review
    tasks:
      - id: fetch_pr_details
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: GET
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
        output_key: pr_details

      - id: fetch_pr_diff
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: GET
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
        output_key: pr_diff

      - id: review_code
        type: mfo_api_chat_send
        input:
          prompt: "Vous êtes un réviseur de code. Analysez les changements suivants et fournissez des commentaires constructifs :\n${fetch_pr_diff.pr_diff}"
          model: gpt-4
        output_key: review_comment

      - id: describe_changes
        type: mfo_api_chat_send
        input:
          prompt: "Résumez les changements de la PR suivante :\nTitre : ${initial_payload.pull_request.title}\nDescription : ${initial_payload.pull_request.body}\nFichiers modifiés : ${initial_payload.pull_request.changed_files}"
          model: gpt-3.5-turbo
        output_key: changes_summary

      - id: suggest_improvements
        type: mfo_api_chat_send
        input:
          prompt: "Proposez des améliorations basées sur la revue de code :\n${review_code.review_comment}"
          model: gpt-4
        output_key: improvement_suggestions

      - id: extract_issue_number
        type: mfo_api_chat_send
        input:
          prompt: "Extraire le numéro d'issue du corps de la PR suivant, s'il y en a un (format : #123) : ${initial_payload.pull_request.body}"
          model: gpt-3.5-turbo
        output_key: issue_number

      - id: fetch_issue_details
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: GET
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
        output_key: issue_details
        condition: ${extract_issue_number.issue_number} != null

      - id: first_principle_analysis
        type: mfo_api_chat_send
        input:
          prompt: "Effectuez une analyse de premier principe de l'issue suivante et suggérez une voie de solution :\n${fetch_issue_details.issue_details.body}"
          model: gpt-4
        output_key: fp_analysis
        condition: ${fetch_issue_details.issue_details} != null

      - id: map_issue_to_codebase
        type: mfo_api_chat_send
        input:
          prompt: "Reliez la description de l'issue : ${fetch_issue_details.issue_details.body} aux fichiers modifiés : ${initial_payload.pull_request.changed_files}"
          model: gpt-4
        output_key: issue_mapping
        condition: ${fetch_issue_details.issue_details} != null

      - id: generate_pr_structure
        type: mfo_api_chat_send
        input:
          prompt: "Créez un objet JSON décrivant la PR avec titre, description, fichiers modifiés, commentaire de revue et suggestions :\n${initial_payload.pull_request.title}\n${initial_payload.pull_request.body}\n${initial_payload.pull_request.changed_files}\n${review_code.review_comment}\n${suggest_improvements.improvement_suggestions}"
          model: gpt-3.5-turbo
        output_key: pr_structure_json

      - id: post_comment
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: POST
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
            Content-Type: "application/json"
          body: {
            "body": "Revue Automatisée :\n- Revue : ${review_code.review_comment}\n- Résumé : ${describe_changes.changes_summary}\n- Suggestions : ${suggest_improvements.improvement_suggestions}\n- Analyse de Premier Principe : ${first_principle_analysis.fp_analysis}\n- Correspondance Issue-Code : ${map_issue_to_codebase.issue_mapping}\n- Structure PR : ${pr_structure_json.pr_structure_json}"
          }
        output_key: comment_response

Considérations Pratiques¶

Modèles LLM : Choisissez des modèles adaptés, comme GPT-4 pour les tâches complexes (revue de code, analyse de premier principe) et GPT-3.5-turbo pour les tâches plus légères (résumé, extraction).
Sécurité : Assurez-vous que le jeton GitHub est stocké de manière sécurisée et que les webhooks sont configurés avec une vérification de signature pour éviter les attaques.
Évolutivité : Prenez en compte les limites de taux de l'API GitHub et les limites de tokens des LLM pour gérer les PR volumineuses.

Conclusion¶

Ce workflow détaillé avec MFO permet de reproduire les fonctionnalités de Qodo Merge tout en ajoutant des analyses avancées pour les issues et une description structurée pour les agents IA. Il repose sur les capacités de MFO pour les webhooks, les appels API, et les interactions LLM, offrant une solution flexible et extensible pour l'automatisation des revues de PR.

Citations Clés¶

Réponse Directe¶

Pour enrichir le workflow MFO MindFlight AI Orchestrator afin d’inclure des tâches supplémentaires avec des branches et des logiques conditionnelles, tout en appliquant une analyse de premier principe, nous allons décomposer le problème en ses composantes fondamentales et identifier toutes les branches possibles, y compris la gestion des erreurs et les notifications Slack. Le workflow existant sera étendu pour évaluer la documentation des issues, gérer différents scénarios de réponse, et intégrer des notifications Slack sur plusieurs canaux pour différentes équipes.

Analyse de Premier Principe¶

L’analyse de premier principe consiste à décomposer le problème en ses éléments de base, en éliminant les hypothèses et en reconstruisant une solution à partir de ces vérités fondamentales. Voici les composantes essentielles : 1. Objectif : Automatiser les revues de pull requests (PR) et l’analyse des issues sur GitHub, en reproduisant les fonctionnalités de Qodo Merge tout en ajoutant des analyses avancées et des interactions conditionnelles. 2. Entrées : Événements GitHub (création/mise à jour de PR ou issue), données de l’API GitHub (détails de PR, issues, diffs), et configuration MFO (jetons, webhooks, modèles LLM). 3. Sorties : Commentaires sur GitHub (remerciements, demandes de détails, notifications), structure JSON pour agents IA, notifications Slack pour les développeurs. 4. Contraintes : - Limites de l’API GitHub (taux d’appels, taille des réponses). - Limites des tokens LLM pour l’analyse de texte volumineux. - Nécessité de gérer les erreurs (échecs d’API, issues mal formées). - Séparation des notifications Slack par équipe/canal.

Nouvelles Tâches et Branches Conditionnelles¶

Nous ajoutons des tâches pour : - Évaluer la documentation de l’issue : Analyser la clarté et la complétude des informations fournies. - Commentaires conditionnels sur l’issue : - Demander plus de détails si la documentation est insuffisante, avec une structure suggérée. - Confirmer que la PR est en cours si l’issue est bien documentée. - Notifier des issues similaires ou des PR existants, avec une demande de clarification si nécessaire. - Notifications Slack : Envoyer des alertes à différents canaux Slack (par exemple, un canal pour les développeurs backend, un autre pour les frontend) pour les erreurs ou les mises à jour. - Gestion des erreurs : Gérer les échecs d’API, les issues sans numéro, ou les diffs trop volumineux.

Branches Possibles¶

Pour l’analyse de l’issue :
Documentation insuffisante → Commentaire demandant plus de détails.
Documentation suffisante → Confirmation et poursuite vers la PR.
Issue similaire détectée → Notification avec lien vers l’issue/PR existant.
Pour la PR :
PR valide → Revue, description, suggestions, et structure JSON.
PR liée à une issue non résolue → Demande de clarification.
PR sans issue liée → Analyse sans correspondance issue-codebase.
Erreurs internes :
Échec de l’API GitHub → Notification Slack au canal des ops.
Limite de tokens LLM dépassée → Notification Slack et commentaire générique.
Données mal formées (par exemple, numéro d’issue absent) → Notification Slack et commentaire demandant des corrections.

Exemple Simplifié¶

Lorsqu’une issue est créée, MFO évalue sa documentation. Si elle est insuffisante, un commentaire comme : « Merci pour votre issue ! Veuillez fournir plus de détails (logs, contexte) selon cette structure : [problème, étapes, impact]. » est publié. Si une issue similaire existe, un commentaire comme : « Une issue similaire (#456) est en cours via PR #789. Si votre cas diffère, veuillez ajouter des logs. » est ajouté. Les erreurs, comme un échec d’API, déclenchent une notification Slack au canal #ops.

Note Détaillée¶

Décomposition du Problème (First Principles)¶

Pour appliquer l’analyse de premier principe, nous identifions les vérités fondamentales du système : - Issue : Une issue est une description d’un problème ou d’une demande, avec un titre, un corps, et éventuellement des labels ou des liens. - Documentation : La qualité de l’issue dépend de la présence d’éléments clés (description du problème, étapes pour reproduire, contexte, logs, impact). - PR : Une PR est une proposition de modification du code, liée ou non à une issue, avec un titre, un corps, des fichiers modifiés, et un diff. - Interactions : Les utilisateurs attendent des retours automatisés (remerciements, demandes, confirmations), et les développeurs ont besoin de notifications pour agir. - Erreurs : Les systèmes externes (GitHub, LLM, Slack) peuvent échouer, nécessitant une gestion robuste. - Notifications : Les équipes (backend, frontend, ops) ont des responsabilités différentes, donc les notifications doivent être ciblées.

À partir de ces bases, nous reconstruisons le workflow en anticipant toutes les branches possibles.

Branches et Logiques Conditionnelles¶

Voici une liste exhaustive des branches, organisées par étape du workflow :

Déclenchement du Workflow :
Événement : Création/mise à jour d’une issue → Analyse de la documentation.
Événement : Création/mise à jour d’une PR → Revue et analyse.
Condition : Webhook mal formé → Notification Slack au canal #ops.
Analyse de l’Issue :
Évaluation de la documentation :
- Suffisante (contient problème, étapes, logs) → Confirmer et lier à une PR.
- Insuffisante → Publier un commentaire demandant des détails avec une structure suggérée.
- Absente (corps vide) → Commentaire demandant une description complète.
Recherche d’issues similaires :
- Issues similaires trouvées (via recherche API GitHub) → Commentaire avec liens et demande de clarification.
- PR existant pour une issue similaire → Commentaire notifiant la PR et demandant des détails si non résolu.
- Aucune similarité → Poursuivre l’analyse.
Erreurs :
- Échec de l’API GitHub pour récupérer les issues → Notification Slack #ops.
- Limite de tokens LLM pour l’analyse → Notification Slack #dev-general et commentaire générique.
Traitement de la PR :
Validation :
- PR liée à une issue → Vérifier la correspondance issue-codebase.
- PR sans issue → Analyse sans correspondance.
- PR mal formée (pas de fichiers modifiés) → Commentaire demandant des modifications.
Revue et analyse :
- Diff analysable → Générer revue, suggestions, et structure JSON.
- Diff trop volumineux → Résumer les changements et notifier #dev-general.
Erreurs :
- Échec de l’API GitHub pour le diff → Notification Slack #ops.
- Échec du LLM → Notification Slack #dev-general et commentaire d’erreur.
Notifications Slack :
Canaux :
- #dev-backend : Erreurs ou mises à jour liées aux fichiers backend.
- #dev-frontend : Erreurs ou mises à jour liées aux fichiers frontend.
- #ops : Erreurs d’infrastructure (API, webhooks).
- #dev-general : Problèmes généraux (LLM, issues mal formées).
Conditions :
- Fichiers modifiés dans /backend/ → Notifier #dev-backend.
- Fichiers modifiés dans /frontend/ → Notifier #dev-frontend.
- Échec systémique → Notifier #ops.

Workflow YAML Mis à Jour¶

Voici le workflow YAML enrichi, incluant les nouvelles tâches et les branches conditionnelles. Les tâches existantes sont conservées, et les nouvelles sont ajoutées avec des conditions explicites.

workflows:
  - id: github_pr_review
    tasks:
      # Tâche initiale : Vérifier le webhook
      - id: validate_webhook
        type: mfo_api_tool_execute
        tool: system_validate_webhook
        input:
          signature: "${webhook_signature}"
          payload: "${initial_payload}"
        output_key: webhook_valid
        on_error:
          - action: notify_slack
            target: "#ops"
            message: "Échec de validation du webhook : ${error_message}"

      # Récupérer les détails de la PR
      - id: fetch_pr_details
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: GET
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
        output_key: pr_details
        condition: ${validate_webhook.webhook_valid} == true
        on_error:
          - action: notify_slack
            target: "#ops"
            message: "Échec de récupération des détails de la PR : ${error_message}"

      # Récupérer le diff de la PR
      - id: fetch_pr_diff
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: GET
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
        output_key: pr_diff
        condition: ${fetch_pr_details.pr_details} != null
        on_error:
          - action: notify_slack
            target: "#ops"
            message: "Échec de récupération du diff de la PR : ${error_message}"

      # Revue de code
      - id: review_code
        type: mfo_api_chat_send
        input:
          prompt: "Vous êtes un réviseur de code. Analysez les changements suivants et fournissez des commentaires constructifs :\n${fetch_pr_diff.pr_diff}"
          model: gpt-4
        output_key: review_comment
        condition: ${fetch_pr_diff.pr_diff} != null
        on_error:
          - action: notify_slack
            target: "#dev-general"
            message: "Échec de la revue de code : ${error_message}"
          - action: post_comment
            url: "[invalid url, do not cite]
            body: "Erreur lors de la revue automatique. Veuillez vérifier le code."

      # Décrire les changements
      - id: describe_changes
        type: mfo_api_chat_send
        input:
          prompt: "Résumez les changements de la PR suivante :\nTitre : ${fetch_pr_details.pr_details.title}\nDescription : ${fetch_pr_details.pr_details.body}\nFichiers modifiés : ${fetch_pr_details.pr_details.changed_files}"
          model: gpt-3.5-turbo
        output_key: changes_summary
        condition: ${fetch_pr_details.pr_details} != null

      # Suggérer des améliorations
      - id: suggest_improvements
        type: mfo_api_chat_send
        input:
          prompt: "Proposez des améliorations basées sur la revue de code :\n${review_code.review_comment}"
          model: gpt-4
        output_key: improvement_suggestions
        condition: ${review_code.review_comment} != null

      # Extraire le numéro d’issue
      - id: extract_issue_number
        type: mfo_api_chat_send
        input:
          prompt: "Extraire le numéro d’issue du corps de la PR suivant, s’il y en a un (format : #123) : ${fetch_pr_details.pr_details.body}"
          model: gpt-3.5-turbo
        output_key: issue_number
        condition: ${fetch_pr_details.pr_details} != null

      # Récupérer les détails de l’issue
      - id: fetch_issue_details
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: GET
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
        output_key: issue_details
        condition: ${extract_issue_number.issue_number} != null
        on_error:
          - action: notify_slack
            target: "#ops"
            message: "Échec de récupération des détails de l’issue : ${error_message}"

      # Évaluer la documentation de l’issue
      - id: evaluate_issue_documentation
        type: mfo_api_chat_send
        input:
          prompt: "Évaluez la qualité de la documentation de l’issue suivante (problème, étapes, logs, contexte, impact). Retournez un score (0-10) et un commentaire : ${fetch_issue_details.issue_details.body}"
          model: gpt-4
        output_key: doc_score
        condition: ${fetch_issue_details.issue_details} != null

      # Rechercher des issues similaires
      - id: search_similar_issues
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: GET
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
        output_key: similar_issues
        condition: ${fetch_issue_details.issue_details} != null
        on_error:
          - action: notify_slack
            target: "#dev-general"
            message: "Échec de recherche d’issues similaires : ${error_message}"

      # Commentaire pour documentation insuffisante
      - id: comment_insufficient_doc
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: POST
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
            Content-Type: "application/json"
          body: {
            "body": "Merci pour votre issue ! La documentation semble insuffisante (score : ${evaluate_issue_documentation.doc_score.score}). Veuillez fournir plus de détails selon cette structure :\n- **Problème** : Description claire\n- **Étapes** : Comment reproduire\n- **Logs** : Messages d’erreur\n- **Contexte** : Environnement\n- **Impact** : Conséquences"
          }
        output_key: comment_response
        condition: ${evaluate_issue_documentation.doc_score.score} < 5

      # Commentaire pour documentation suffisante
      - id: comment_sufficient_doc
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: POST
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
            Content-Type: "application/json"
          body: {
            "body": "Merci pour votre issue bien documentée (score : ${evaluate_issue_documentation.doc_score.score}) ! Le processus de création de la PR est en cours."
          }
        output_key: comment_response
        condition: ${evaluate_issue_documentation.doc_score.score} >= 5 && ${search_similar_issues.similar_issues} == null

      # Commentaire pour issues similaires
      - id: comment_similar_issues
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: POST
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
            Content-Type: "application/json"
          body: {
            "body": "Merci pour votre issue ! Une issue similaire (${search_similar_issues.similar_issues[0].number}) est en cours via PR #${search_similar_issues.similar_issues[0].pr_number}. Si votre cas diffère, veuillez fournir des logs et un contexte supplémentaire."
          }
        output_key: comment_response
        condition: ${search_similar_issues.similar_issues} != null

      # Analyse de premier principe
      - id: first_principle_analysis
        type: mfo_api_chat_send
        input:
          prompt: "Effectuez une analyse de premier principe de l’issue suivante et suggérez une voie de solution :\n${fetch_issue_details.issue_details.body}"
          model: gpt-4
        output_key: fp_analysis
        condition: ${fetch_issue_details.issue_details} != null && ${evaluate_issue_documentation.doc_score.score} >= 5

      # Mapper l’issue au codebase
      - id: map_issue_to_codebase
        type: mfo_api_chat_send
        input:
          prompt: "Reliez la description de l’issue : ${fetch_issue_details.issue_details.body} aux fichiers modifiés : ${fetch_pr_details.pr_details.changed_files}"
          model: gpt-4
        output_key: issue_mapping
        condition: ${fetch_issue_details.issue_details} != null && ${fetch_pr_details.pr_details} != null

      # Générer la structure de la PR
      - id: generate_pr_structure
        type: mfo_api_chat_send
        input:
          prompt: "Créez un objet JSON décrivant la PR avec titre, description, fichiers modifiés, commentaire de revue, suggestions, et analyse d’issue :\n${fetch_pr_details.pr_details.title}\n${fetch_pr_details.pr_details.body}\n${fetch_pr_details.pr_details.changed_files}\n${review_code.review_comment}\n${suggest_improvements.improvement_suggestions}\n${first_principle_analysis.fp_analysis}"
          model: gpt-3.5-turbo
        output_key: pr_structure_json
        condition: ${fetch_pr_details.pr_details} != null

      # Notification Slack pour backend
      - id: notify_slack_backend
        type: mfo_api_tool_execute
        tool: system_slack_notify
        input:
          channel: "#dev-backend"
          message: "Nouvelle PR ou issue affectant le backend : ${fetch_pr_details.pr_details.title} (Fichiers : ${fetch_pr_details.pr_details.changed_files})"
        output_key: slack_response
        condition: ${fetch_pr_details.pr_details.changed_files} contains "/backend/"

      # Notification Slack pour frontend
      - id: notify_slack_frontend
        type: mfo_api_tool_execute
        tool: system_slack_notify
        input:
          channel: "#dev-frontend"
          message: "Nouvelle PR ou issue affectant le frontend : ${fetch_pr_details.pr_details.title} (Fichiers : ${fetch_pr_details.pr_details.changed_files})"
        output_key: slack_response
        condition: ${fetch_pr_details.pr_details.changed_files} contains "/frontend/"

      # Publier un commentaire final sur la PR
      - id: post_comment
        type: mfo_api_tool_execute
        tool: system_http_request
        input:
          method: POST
          url: "[invalid url, do not cite]
          headers:
            Authorization: "Bearer ${github_token}"
            Content-Type: "application/json"
          body: {
            "body": "Revue Automatisée :\n- Revue : ${review_code.review_comment}\n- Résumé : ${describe_changes.changes_summary}\n- Suggestions : ${suggest_improvements.improvement_suggestions}\n- Analyse de Premier Principe : ${first_principle_analysis.fp_analysis}\n- Correspondance Issue-Code : ${map_issue_to_codebase.issue_mapping}\n- Structure PR : ${generate_pr_structure.pr_structure_json}"
          }
        output_key: comment_response
        condition: ${fetch_pr_details.pr_details} != null

Explications des Ajouts¶

Évaluation de la documentation : La tâche evaluate_issue_documentation utilise un LLM pour attribuer un score (0-10) et fournir un commentaire, permettant des décisions conditionnelles.
Commentaires conditionnels :
comment_insufficient_doc : Déclenché si le score est inférieur à 5, avec une structure suggérée.
comment_sufficient_doc : Déclenché si le score est suffisant et aucune issue similaire n’est trouvée.
comment_similar_issues : Déclenché si des issues similaires existent, avec des liens et une demande de clarification.
Notifications Slack :
Les tâches notify_slack_backend et notify_slack_frontend ciblent des canaux spécifiques en fonction des fichiers modifiés.
Les erreurs déclenchent des notifications vers #ops ou #dev-general via les blocs on_error.
Gestion des erreurs : Chaque tâche inclut un bloc on_error pour gérer les échecs, avec des notifications Slack et des commentaires génériques si nécessaire.

Considérations Techniques¶

Sécurité : Le jeton GitHub et les identifiants Slack doivent être stockés de manière sécurisée dans MFO (par exemple, variables d’environnement ou vault).
Limites API :
GitHub : Les appels API (issues, PRs, recherche) doivent respecter les limites de taux (par exemple, 5000 appels/heure pour un PAT).
LLM : Les diffs ou descriptions volumineux peuvent nécessiter un découpage ou un résumé préalable.
Performance : Les tâches conditionnelles réduisent les appels inutiles (par exemple, ne pas analyser les issues si aucune n’est liée).
Extensibilité : Le workflow peut être étendu pour inclure d’autres canaux Slack ou des analyses supplémentaires (par exemple, détection de code dupliqué).

Conclusion¶

Ce workflow mis à jour intègre des branches conditionnelles pour gérer l’analyse des issues, des commentaires adaptés, et des notifications Slack ciblées. L’analyse de premier principe a permis d’identifier toutes les branches possibles, y compris les erreurs, assurant une automatisation robuste et flexible. Le YAML fourni est conçu pour être compatible avec MFO, en s’appuyant sur ses capacités de webhooks, d’appels API, et d’interactions LLM.

Citations Clés¶

Pour répondre à votre requête, nous allons intégrer un système RAG (Retrieval-Augmented Generation) interne dans un workflow MFO (MindFlight Orchestrator) avec trois entrées : Issues, Pull Requests et Comments, en tenant compte des relations entre ces entités et en suivant leurs statuts. Nous proposerons également une approche pour gérer la base de code en la compilant en fichiers .md, puis en utilisant des modèles à large fenêtre comme Gemini Pro ou Claude 3.7 pour identifier les zones problématiques. Enfin, nous envisagerons une conversion en embeddings pour des recherches parallèles. Voici comment cela impacte le workflow MFO, en respectant les directives des fichiers fournis (variables_usage.md, task_definitions.md, yaml-directives.mdc, slop_api_docu.mdc).

Objectifs¶

RAG interne : Récupérer et traiter les Issues, Pull Requests et Comments depuis GitHub, en liant ces entités et en suivant leurs statuts.
Base de code : Compiler le code en un ou plusieurs fichiers .md avec descriptions, puis utiliser ces fichiers pour contextualiser l’analyse des entrées RAG.
Analyse augmentée : Exploiter des modèles à large fenêtre pour identifier les zones problématiques dans le code, et à terme, utiliser des embeddings pour des recherches efficaces.

Approche proposée¶

1. Récupération des données¶

Nous utiliserons l’API GitHub pour récupérer : - Issues : Liste des problèmes ouverts ou fermés. - Pull Requests : Modifications proposées liées aux issues. - Comments : Commentaires associés aux issues ou pull requests.

Ces données seront récupérées via des tâches mfo_api_tool_execute utilisant un outil HTTP pour appeler les endpoints GitHub.

2. Traitement et relations¶

Les issues peuvent être liées à des pull requests (via des mots-clés comme "fixes #123").
Les commentaires sont rattachés à une issue ou une pull request spécifique.
Les statuts (ouvert, fermé, en cours) seront suivis en stockant les données dans la mémoire MFO ou en les mettant à jour à chaque exécution.

3. Compilation de la base de code¶

Le code sera compilé en un fichier .md (ou plusieurs si la base est volumineuse) avec des métadonnées comme les templates, URLs et descriptions.

Exemple de structure pour un fichier .md :

# Module : Authentification
## URL : /api/auth
## Description : Gestion des connexions utilisateur
## Code :
[Code source ici]

4. Analyse avec RAG¶

Les modèles à large fenêtre (Gemini Pro, Claude 3.7) analyseront les fichiers .md en combinaison avec les données des issues/pull requests/comments.
À terme, les fichiers .md seront convertis en embeddings stockés dans une table RAG, permettant des recherches parallèles pour identifier les zones de code pertinentes.

5. Intégration dans le workflow MFO¶

Le workflow sera structuré en étapes logiques avec des tâches MFO, respectant les règles de syntaxe (notation par points, pas de ${} ou {{}} dans le YAML).

Workflow MFO modifié¶

Voici un exemple de workflow YAML intégrant le RAG interne et la gestion de la base de code :

workflows:
  - id: github_rag_analysis
    name: GitHub RAG Analysis Workflow
    description: Analyse les issues, pull requests et commentaires avec un RAG interne
    version: "1.0"
    tasks:
      # Récupération des issues
      - id: fetch_issues
        type: mfo_api_tool_execute
        tool: system_http_request
        config:
          method: GET
          url: "https://api.github.com/repos/{owner}/{repo}/issues"
          headers:
            Authorization: "Bearer INPUT.github_token"
        output_key: issues

      # Récupération des pull requests
      - id: fetch_prs
        type: mfo_api_tool_execute
        tool: system_http_request
        config:
          method: GET
          url: "https://api.github.com/repos/{owner}/{repo}/pulls"
          headers:
            Authorization: "Bearer INPUT.github_token"
        output_key: prs

      # Récupération des commentaires pour la première issue
      - id: fetch_comments
        type: mfo_api_tool_execute
        tool: system_http_request
        config:
          method: GET
          url: "https://api.github.com/repos/{owner}/{repo}/issues/fetch_issues.issues[0].number/comments"
          headers:
            Authorization: "Bearer INPUT.github_token"
        output_key: comments
        condition: "fetch_issues.issues[0].number != null"

      # Compilation de la base de code en fichier .md
      - id: compile_codebase
        type: mfo_api_tool_execute
        tool: custom_compile_codebase
        config:
          repo: "{owner}/{repo}"
        output_key: codebase_md

      # Génération des embeddings pour la base de code
      - id: generate_embeddings
        type: mfo_api_tool_execute
        tool: custom_generate_embeddings
        config:
          text: "compile_codebase.codebase_md"
        output_key: embeddings

      # Stockage des embeddings dans la mémoire MFO
      - id: store_embeddings
        type: mfo_api_memory_store
        config:
          key: "codebase_embeddings"
          value: "generate_embeddings.embeddings"

      # Recherche des parties de code pertinentes pour une issue
      - id: retrieve_relevant_code
        type: mfo_api_tool_execute
        tool: custom_similarity_search
        config:
          query: "fetch_issues.issues[0].body"
          embeddings_key: "codebase_embeddings"
        output_key: relevant_code
        condition: "fetch_issues.issues[0] != null"

      # Analyse de l’issue avec RAG
      - id: analyze_issue
        type: mfo_api_chat_send
        config:
          prompt: |
            Analysez cette issue GitHub en utilisant le code pertinent :
            Titre : fetch_issues.issues[0].title
            Description : fetch_issues.issues[0].body
            Code pertinent : retrieve_relevant_code.relevant_code
          model: "gemini-pro"
        output_key: issue_analysis
        condition: "fetch_issues.issues[0] != null"

      # Publication d’un commentaire sur l’issue
      - id: post_comment
        type: mfo_api_tool_execute
        tool: system_http_request
        config:
          method: POST
          url: "https://api.github.com/repos/{owner}/{repo}/issues/fetch_issues.issues[0].number/comments"
          headers:
            Authorization: "Bearer INPUT.github_token"
            Content-Type: "application/json"
          body: "{\"body\": \"Analyse automatique : analyze_issue.issue_analysis\"}"
        output_key: comment_response
        condition: "analyze_issue.issue_analysis != null"

Explications¶

Structure du workflow¶

Récupération des données :
fetch_issues, fetch_prs, fetch_comments : Utilisent system_http_request pour appeler l’API GitHub.
Compilation de la base de code :
compile_codebase : Utilise un outil personnalisé pour générer un fichier .md.
Embeddings et RAG :
generate_embeddings et store_embeddings : Génèrent et stockent les embeddings.
retrieve_relevant_code : Recherche les parties de code pertinentes via un outil personnalisé.
Analyse :
analyze_issue : Utilise un modèle comme Gemini Pro pour analyser une issue avec le contexte du code.
Action :
post_comment : Publie l’analyse sur GitHub.

Respect des directives MFO¶

Syntaxe : Utilisation de la notation par points (ex. fetch_issues.issues[0].title) et pas de ${} ou {{}} dans le YAML.
Tâches : Basées sur task_definitions.md (ex. mfo_api_tool_execute, mfo_api_chat_send).
API SLOP : Compatible avec les endpoints décrits dans slop_api_docu.mdc (ex. /api/memory pour stocker les embeddings).

Outils personnalisés¶

custom_compile_codebase : Compile le code en .md.
custom_generate_embeddings : Génère des embeddings à partir du texte.
custom_similarity_search : Recherche les embeddings similaires.

Impact sur le workflow¶

Nouvelles tâches : Ajout de tâches pour la récupération, le traitement, et l’analyse augmentée par RAG.
Gestion des relations : Les liens entre issues, pull requests et commentaires sont préservés via les données récupérées.
Suivi des statuts : Peut être étendu en stockant les statuts dans la mémoire MFO avec mfo_api_memory_store.
Scalabilité : Pour les grandes bases de code, plusieurs fichiers .md peuvent être générés, et les embeddings permettent des recherches efficaces.

Étapes futures¶

Embeddings avancés : Implémenter une table RAG avec une base de données vectorielle pour des recherches parallèles.
Automatisation : Ajouter des conditions pour gérer dynamiquement les statuts (ex. si une issue est fermée, passer à la suivante).

Cette solution intègre le RAG interne tout en respectant les contraintes MFO et offre une base évolutive pour l’analyse de code et de données GitHub.