Documents de contexte

Les Documents de contexte sont des artefacts de connaissance réutilisables qui sont versionnés et injectés automatiquement dans les sandboxes comme system prompts ou comme contenu CLAUDE.md. Plutôt que d’intégrer la même vue d’ensemble architecturale ou les mêmes standards de code dans les instructions de chaque persona, vous l’écrivez une seule fois comme Contexte, vous le publiez et vous le liez aux session types ou personas qui en ont besoin. Chaque fois qu’une sandbox correspondante est provisionnée, la version active de ce Contexte est injectée automatiquement.

Les Contextes se trouvent à /p/{projectId}/context et sont limités à un seul projet. Un projet peut avoir un nombre illimité de Contextes, chacun couvrant un domaine de connaissance différent - un pour les conventions architecturales, un pour la documentation API, un pour les règles de sécurité.

Ce que sont les Contextes

Fondamentalement, un Contexte est un document markdown nommé et versionné. Chaque enregistrement de Contexte stocke :

• Nom - Un libellé lisible par un humain (par ex., “Architecture du projet”, “Standards de sécurité”)
• Description - Un résumé optionnel de ce que couvre le Contexte et de quand l’utiliser
• Contenu - Le corps markdown complet injecté dans les sandboxes
• Historique des versions - Une piste d’audit complète de chaque version publiée

Les Contextes sont conçus pour le type de connaissance persistante, au niveau du projet, que chaque agent d’un type donné devrait porter. Voici quelques exemples :

• Des vues d’ensemble architecturales complètes décrivant la stack technologique, les frontières de service et le flux de données
• Des standards de code et des style guides que les agents doivent suivre en écrivant du code
• Du contenu CLAUDE.md qui est écrit dans le système de fichiers de la sandbox avant l’exécution de l’agent
• De la documentation API spécifique à un domaine ou des patterns d’intégration que les agents doivent référencer
• Des checklists de sécurité et des exigences de conformité pour les agents qui effectuent des code reviews

Cycle de vie des versions de Contexte

Chaque fois que vous modifiez le contenu d’un Contexte et publiez le changement, une nouvelle version est créée. Les versions ont deux statuts :

Le cycle de vie d’une modification de Contexte typique est :

1. Vous ouvrez l’éditeur de Contexte et modifiez le contenu markdown
2. Vous cliquez sur Publier - ceci crée une nouvelle version avec le statut active
3. La version précédemment active passe automatiquement à inactive
4. Toutes les futures sandboxes qui référencent ce Contexte reçoivent la nouvelle version active
5. L’ancienne version reste dans l’historique des versions à des fins d’audit et de rollback

Liaisons aux Session Types

Les Contextes peuvent être liés à des session typesspécifiques depuis la page des paramètres du projet. Lorsqu’une session de ce type est créée, la version active du Contexte lié est injectée automatiquement. CodeCourier définit six session types, chacun correspondant à une étape différente du pipeline de workflow IA :

Chaque session type a son propre onglet de configuration dans les paramètres du projet où vous pouvez lier exactement un Contexte. Cela permet facilement de donner, par exemple, à l’agent evaluator un ensemble de critères de qualité différent de celui de l’agent de découverte d’issues.

Override de Contexte au niveau persona

En plus des liaisons de session type, des personas individuelles peuvent se lier à un Contexte spécifique depuis leur onglet Contextesur la page de détail de la persona. Une liaison au niveau persona a priorité sur la valeur par défaut du session type - c’est-à-dire que lorsqu’une persona avec sa propre liaison de Contexte s’exécute, elle utilise le Contexte de la persona plutôt que la valeur par défaut du session type.

Ce mécanisme d’override permet un contrôle fin. Prenons un projet avec deux personas Designer - une pour le travail frontend et une pour le travail backend. Le Designer frontend est lié à un Contexte “Architecture Frontend”, tandis que le Designer backend est lié à un Contexte “Architecture Backend”. Les deux héritent de la valeur par défaut du session type comme fallback si aucune liaison au niveau persona n’est définie.

Pourquoi les Contextes sont importants

Avant les Contextes, les équipes devaient copier-coller la connaissance architecturale dans les instructions de chaque persona ou maintenir des fichiers CLAUDE.md séparés par workflow. Cela créait de la dérive : différents agents avaient des compréhensions subtilement différentes de la codebase parce que leurs instructions étaient modifiées indépendamment. Les Contextes résolvent ce problème en fournissant une source unique de vérité que tous les agents concernés partagent.

Les principaux avantages sont :

• Cohérence- Tous les agents d’un session type partagent la même connaissance à jour. Quand l’architecture change, vous mettez à jour un Contexte et toutes les futures sessions reçoivent immédiatement le changement.
• Contrôle de version - Les instructions des agents sont versionnées comme du code. Vous pouvez voir qui a publié quelle version, quand, et revenir à une version précédente si un changement provoque des régressions.
• Séparation des préoccupations - Les instructions de persona restent concentrées sur le comportement spécifique au rôle. La connaissance partagée vit dans les Contextes. Chacun a un emplacement clair.
• Auditabilité- Quand un agent produit une sortie inattendue, vous pouvez vérifier l’historique des versions pour voir exactement quelle version de Contexte était active au moment de cette session.

Étapes suivantes