Modules

Modules

Définition

Un module est l’unité fonctionnelle atomique de Context Compiler.

Un module fait une chose précise, dans un moment précis du pipeline, avec une responsabilité claire et réutilisable.

On peut résumer l’idée ainsi :

Un module = une capacité

Ce qu’un module apporte

Un module peut par exemple :

• lire une source
• enrichir des données
• composer une partie du prompt
• produire une vue
• écrire un artefact
• appliquer une logique métier spécialisée

Le point important est qu’un module n’est pas censé être une “solution complète”. Il apporte une brique ciblée que le runtime peut orchestrer avec d’autres.

Caractéristiques attendues

Dans Context Compiler, un module est pensé pour être :

• atomique : responsabilité limitée
• stateless : pas d’état global métier persistant
• branchable : inséré dans un pipeline ou une phase précise
• réutilisable : utilisable dans plusieurs packs ou blueprints
• packagé : distribuable via NuGet

Exemples concrets dans le repo

Readers

Ces modules lisent des formats d’entrée :

• ContextCompiler.Modules.Readers.Markdown
• ContextCompiler.Modules.Readers.Text
• ContextCompiler.Modules.Readers.Pdf
• ContextCompiler.Modules.Readers.Excel

Prompt composers

Ces modules composent des sections du prompt :

• ContextCompiler.Modules.Prompt.Composers.General
• ContextCompiler.Modules.Prompt.Composers.Objectives
• ContextCompiler.Modules.Prompt.Composers.Constraints
• ContextCompiler.Modules.Prompt.Composers.Views

Views

Ces modules structurent ou rendent des vues :

• ContextCompiler.Modules.Views
• ContextCompiler.Modules.Views.View.Index.Json

Personas et engineering

Ces modules injectent du cadrage ou de la spécialisation :

• ContextCompiler.Modules.Personas.Developers.DotNet
• ContextCompiler.Modules.Personas.Analysts.Business
• ContextCompiler.Modules.Engineering.DotNet

Rôle dans le pipeline

Un module n’existe pas “à côté” du système. Il intervient à un endroit du pipeline.

Selon sa nature, il peut par exemple participer à :

• la lecture des entrées
• l’ingénierie ou l’enrichissement
• la composition du prompt
• le rendu de sorties

Le pipeline reste le mécanisme d’orchestration. Le module reste la capacité spécialisée.

Traduction technique

Techniquement, un module Context Compiler est généralement :

• un package ContextCompiler.Modules.*
• un projet packable NuGet
• une implémentation d’un contrat du runtime
• une brique découverte et chargée au runtime

Quelques idées importantes :

• les modules sont des plugins de première classe
• ils sont distribués comme packages NuGet
• ils sont chargés dynamiquement par le système

Cela permet d’étendre le comportement sans recompiler tout l’hôte.

Ce qu’un module n’est pas

Un module n’est pas :

• un bundle de capacités hétérogènes
• une solution métier complète
• un scénario d’usage de bout en bout

Quand on commence à regrouper plusieurs modules cohérents, on entre dans la notion de pack.

Quand créer un module

Créer un module est pertinent quand :

• une capacité est clairement isolable
• elle doit être réutilisable indépendamment
• elle peut vivre seule dans un package
• elle s’insère naturellement dans le pipeline existant

Quand ne pas créer un module

Créer un module séparé est moins pertinent quand :

• il ne fait qu’agréger d’autres modules sans logique propre
• il représente un scénario d’usage complet
• il sert surtout à simplifier l’installation

Dans ces cas-là, il faut plutôt regarder du côté des packs ou des blueprints.

Résumé

• Un module est une capacité atomique
• Il fait une seule chose
• Il s’insère dans le pipeline
• Il se distribue comme package NuGet
• Il sert de brique de base pour les packs et les blueprints

Suite logique : Packs