Bibliothèque de modules intégrée

Braidrun est livré avec plus de 120 modules intégrés. Chaque module est un workflow encapsulé, doté d'un contrat d'entrée / sortie typé ; les autres workflows le référencent via une étape sub_workflow sans avoir à se soucier de son implémentation interne.

Outils généraux (environ 80)

utility-module-* préfixe, couvrant des étapes générales indépendantes du métier telles que le traitement de données, les requêtes HTTP, la recherche et l'extraction, l'IA sur texte et les vérifications de surveillance. Modules représentatifs :

Remise et notification

Sortie de notification stable en fin de workflow, le plus souvent implémentée par des étapes purement code, sans dépendre du LLM, afin d'éviter qu'une absence d'identifiant de modèle ne fasse échouer la chaîne de notification. Modules représentatifs :

Les autres modules de notification couvrent les robots de groupe Discord, Feishu, WeCom, Microsoft Teams, Mattermost, Rocket.Chat, les e-mails Mailgun / SendGrid, ainsi que les notifications push Bark, Pushover et ServerChan. Il existe en outre un module de remise de fichiers Telegram qui envoie directement dans une conversation désignée des rapports .md / .xlsx / .pdf / .csv accompagnés d'un texte explicatif, et prend en charge dedupe_key pour éviter les envois en double lors d'une réémission.

Analyse financière (environ 10)

module-* préfixe, une chaîne d'outils quantitatifs : cotations → indicateurs techniques → analyse de portefeuille → backtesting. Les modules de cotations ne requièrent pas d'API key (sources de données Tencent Finance / Yahoo Finance / CoinGecko), et les modules d'indicateurs et de backtesting sont implémentés uniquement avec la bibliothèque standard.

La même série comprend aussi des modules d'actualités boursières, de sélection d'actions sous conditions, de valorisation d'options, d'indicateurs de risque et de vue d'ensemble du marché, que l'on peut enchaîner en un pipeline complet allant des cotations au rapport.

Publicité et croissance (environ 40)

Ce lot de modules provient de l'exploitation publicitaire réelle de l'équipe d'une application par abonnement, et couvre les données Apple Search Ads, Google Ads et les revenus de l'application. Voici les principales catégories par usage :

• Récupération de rapports ASA：Quatre dimensions campaigns / keywords / adgroups / searchterms, avec harmonisation automatique des différences de nommage des champs de l'API.
• Liste des entités ASA：Récupération en masse des campagnes, groupes d'annonces, mots-clés et mots-clés négatifs.
• Outil Google Ads：Exécute une requête GAQL et renvoie un résultat structuré, avec en outre un rapport de performance des campagnes et la découverte des comptes accessibles.
• Récupération des revenus de l'application：Récupère les données de revenus et d'abonnements par fenêtre temporelle.
• Analyse de fenêtre temporelle：Convertit un nombre de jours de recul et un fuseau horaire en dates de début et de fin normalisées, afin de garantir que la sémantique de « hier / la semaine dernière » soit parfaitement cohérente au sein d'un lot de rapports.
• Assemblage de rapports：Construction d'un Excel multi-feuilles et rendu de modèles de rapport Markdown.
• Traitement par lots multi-applications：Un même sous-processus est exécuté une fois pour chaque application d'un lot, puis les résultats sont fusionnés.
• Boucle de revue qualité：Un contrôle qualité normalisé : générer → noter → réessayer si non conforme → sortir une fois conforme.

Contrat module

Chaque module déclare un contrat : les entrées sont typées (string / number / boolean / enum / path / json) et peuvent être annotées avec required, une valeur par défaut, des valeurs d'énumération et une plage de valeurs numériques ; les sorties déclarent un nom, un type et une variable source ; le contrat possède une contract_version indépendante de la version d'implémentation du workflow.

module:
  enabled: true
  display_name: Web Search
  contract_version: 1.0.0
  inputs:
    - {name: query, type: string, required: true}
    - {name: provider, type: enum, default: duckduckgo,
       allowed_values: [duckduckgo, serper]}
    - {name: max_results, type: number, default: "10", min: 1, max: 100}
  outputs:
    - {name: results_json, type: string, source: "{{var:results_json}}"}
    - {name: result_count, type: number, source: "{{var:result_count}}"}

Lors de la modification d'un contrat, la plateforme compare le nouveau contrat à l'ancien : une modification non rompante (par exemple l'ajout d'une entrée facultative) passe directement ; une modification rompante (susceptible d'affecter les référenceurs existants) est par défaut refusée à l'enregistrement, requiert une confirmation explicite et donne lieu à un numéro de version de contrat suggéré. Le contrat prend aussi en charge une marque deprecated assortie de notes de migration, pour inviter les référenceurs à basculer vers un module de remplacement.

Référencer dans un workflow

Référencez par id de module via une étape sub_workflow. Les valeurs de inputs sont toutes des chaînes (un nombre s'écrit aussi "10") et prennent en charge les modèles de variables ; outputs remappe la sortie du module vers les variables du workflow parent, pour un usage direct dans les étapes suivantes.

workflow:
  - step: fetch_metrics
    sub_workflow:
      name: utility-module-http-request
      version_strategy: latest
      inputs:
        url: "https://api.example.com/v1/metrics"
        method: GET
      outputs:
        status_code: fetch_status
        response_body: metrics_json

  - step: notify
    sub_workflow:
      name: utility-module-slack-webhook
      inputs:
        webhook_url: "{{var:slack_webhook_url}}"
        text: "Metrics updated: {{var:metrics_json}}"
      outputs:
        send_status: notify_status
    depends_on:
      - fetch_metrics
    retry:
      max_attempts: 2
      backoff: exponential

• version_strategy latest par défaut ; vous pouvez aussi épingler une version précise, de sorte qu'une mise à jour du module n'affecte pas le workflow parent déjà en production.
• Une référence pointant vers un module fonctionne en mode contrat : inputs / outputs sont validés selon le contrat ; si le module est rétrogradé en workflow ordinaire, la référence bascule en mode permissif et n'est plus validée automatiquement.
• Les modificateurs d'étape tels que retry, condition, depends_on restent applicables aux étapes sub_workflow.

Module personnalisé

N'importe quel workflow peut être promu en module : dans le panneau des réglages de workflow de l'éditeur, repérez la section « Contrat de module », renseignez le nom affiché, la description, les entrées / sorties et la version du contrat, puis cliquez sur « Enregistrer le contrat de module ». Il apparaît ensuite dans la bibliothèque de modules et les autres workflows peuvent le référencer via sub_workflow.

Lors du retrait du statut de module (rétrogradation), la plateforme effectue d'abord une vérification des dépendances inverses : s'il subsiste des workflows parents référençant ce module, elle énumère les emplacements de référence précis et bloque l'opération, afin d'éviter de casser en silence les processus d'autrui.

Comme les modèles, les modules peuvent être publiés sur le marché, avec un numéro de version, et leurs dépendances sont résolues automatiquement à l'installation.