Paramètres du projet

Les Paramètres du projet sont l’endroit où vous configurez les valeurs par défaut et les intégrations au niveau du projet qui affectent toutes les sandboxes, tous les workflows et toutes les issue sessions. La page des paramètres est organisée en onglets, chacun couvrant un aspect différent de la configuration du projet. L’accès aux paramètres nécessite le rôle Admin ou Owner.

Accédez aux Paramètres du projet depuis le bas de la barre latérale (l’icône de clé à molette) ou directement à /p/{projectId}/settings.

Configuration des clés API

CodeCourier nécessite des clés API pour les services externes avec lesquels il s’intègre. Les clés sont configurées par projet, ce qui signifie que différents projets peuvent utiliser différents comptes API. Toutes les clés sont chiffrées au repos dans la base de données et seuls les quatre derniers caractères sont affichés dans l’interface.

Clés requises

Clés facultatives

Configuration du prompt système

Le Prompt système de la sandbox est un prompt par défaut injecté dans chaque session de sandbox du projet. Il établit le comportement de base pour tous les agents IA, y compris les instructions pour travailler dans l’environnement de sandbox E2B, les préférences de gestion de paquets, les conventions de système de fichiers et les règles de workflow Git.

Le prompt système par défaut inclut des instructions critiques spécifiques à la sandbox comme :

• Lier les serveurs de dev à 0.0.0.0 pour l’accessibilité publique
• Démarrer les serveurs en arrière-plan avec nohup
• Utiliser le répertoire de base /home/user/
• Construire l’URL publique à partir de l’ID de la sandbox et du port
• Conventions de commit Git et configuration de l’authentification

Vous pouvez personnaliser le prompt système pour ajouter des règles spécifiques au projet qui devraient s’appliquer à toutes les sessions, quelle que soit la persona ou le workflow en cours d’exécution.

Modèle CLAUDE.md

Le champ CLAUDE.md vous permet de définir un modèle pour le fichier CLAUDE.md qui est écrit dans chaque sandbox. Ce fichier fournit un contexte de niveau projet à l’agent IA, y compris les décisions d’architecture, les standards de codage, les préférences de dépendances et d’autres connaissances qui devraient persister d’une session à l’autre.

Considérez CLAUDE.md comme la « connaissance institutionnelle » du projet à laquelle chaque agent devrait avoir accès, quelle que soit la tâche.

Prompt de découverte d’issues

Le Prompt de découverte d’issues configure les instructions par défaut utilisées par les issue sessions. Ce prompt est injecté lorsqu’un agent IA commence à analyser la base de code à la recherche d’issues. Personnalisez-le pour refléter les conventions de triage d’issues de votre projet, les préférences de priorité et les domaines de découverte prioritaires.

Variables d’environnement

Vous pouvez définir des variables d’environnement qui sont injectées dans chaque session de sandbox. Elles sont utiles pour les valeurs de configuration dont votre base de code a besoin à l’exécution :

• Clé - Le nom de la variable d’environnement (par exemple, DATABASE_URL)
• Valeur - La valeur de la variable
• Indicateur secret - Si la valeur doit être masquée dans l’interface

La page des paramètres prend en charge deux ensembles de variables d’environnement :

• Variables d’env de sandbox - Injectées dans les sessions de sandbox de développement
• Variables d’env de déploiement - Utilisées pendant les opérations de déploiement

Skills et Commands

Les paramètres du projet incluent la possibilité de sélectionner quels skills et commands sont disponibles à l’échelle du projet. Les skills sont des packages de connaissances métier (fichiers de référence, bonnes pratiques, docs API) et les commands sont des modèles de prompt réutilisables. Les sélectionner au niveau du projet les rend disponibles pour toutes les personas et sessions du projet.

Vous pouvez également sélectionner des scripts - des scripts shell exécutables qui peuvent être injectés dans les environnements de sandbox pour des tâches de configuration courantes.

Configuration du learning

Le système de learning capture les patterns, les pièges et les bonnes pratiques des sessions de sandbox et les rend disponibles pour les runs futurs. Les paramètres du projet contrôlent :

• ID du template de learning - Le template de sandbox utilisé pour l’extraction des learnings
• Modèle de learning - Quel modèle IA extrait les learnings des transcriptions de session
• ID du template de merging - Le template utilisé pour fusionner les changements de code des runs terminés
• Modèle de merging - Quel modèle gère les opérations de merge

Configuration Git

Pour les projets qui créent des commits Git et des pull requests, vous pouvez configurer :

• URL du dépôt GitHub - Le dépôt lié à ce projet (défini au niveau du projet)
• Nom de commit Git - Le nom d’auteur utilisé dans les commits créés par l’agent IA
• E-mail de commit Git - L’e-mail d’auteur utilisé dans les commits

Ces paramètres garantissent que tous les commits générés par l’IA sont correctement attribués et suivent les conventions Git de votre équipe.

Clés Convex

Si votre projet utilise Convex comme backend (comme le fait CodeCourier lui-même), vous pouvez configurer :

• Clé de déploiement Convex - Utilisée pour déployer les fonctions Convex depuis la sandbox
• Clé de dev Convex - Utilisée pour les opérations Convex en mode développement

Ces clés permettent à l’agent IA de déployer et tester les changements de backend Convex directement depuis l’environnement de sandbox.

Identifiants d’utilisateur de test

Pour les projets qui nécessitent des tests authentifiés, vous pouvez stocker des identifiants d’utilisateur de test :

• E-mail - Adresse e-mail du compte de test
• Mot de passe - Mot de passe du compte de test

Ces identifiants sont mis à disposition des sessions de sandbox pour les tests end-to-end automatisés, permettant aux agents de se connecter à l’application et de tester les fonctionnalités authentifiées.

Configurations de session

Au-delà des valeurs par défaut globales du projet, CodeCourier fournit des onglets de configuration dédiés pour chacun des six types de session qui alimentent le pipeline de workflow IA. Chaque onglet de configuration vous permet de configurer l’outil CLI, le modèle, l’effort de réflexion, le Context Document lié et les Assets sélectionnés (Skills, Commands et Scripts) pour ce type de session spécifique. Les changements apportés à la configuration d’un type de session s’appliquent à toutes les nouvelles sessions de ce type à l’échelle du projet, sauf si une persona les remplace.

Configuration Answering

Située à /p/{id}/answering-setup. Configure l’ Answering Agent - le type de session qui répond aux questions en langage naturel sur la base de code et le projet. Champs :

• Outil CLI - Quelle CLI d’agent de codage utiliser (Claude Code, OpenCode, Codex)
• Modèle - Le modèle LLM spécifique pour les sessions answering
• Effort de réflexion - Profondeur de raisonnement (none, low, medium, high, max)
• Context - Le Context Document injecté par défaut dans les sessions answering
• Skills, Commands, Scripts - Assets par défaut disponibles pour les sessions answering

Configuration Issues

Située à /p/{id}/issues-setup. Configure l’ Issue Discovery Agent - le type de session qui analyse la base de code et génère une liste structurée d’issues, de bugs et d’opportunités d’amélioration. Champs :

• Outil CLI - Quelle CLI d’agent de codage utiliser
• Modèle - Le modèle LLM spécifique pour les sessions de découverte d’issues
• Effort de réflexion - Profondeur de raisonnement
• Context - Le Context Document injecté par défaut dans les sessions de découverte d’issues
• Skills, Commands, Scripts - Assets par défaut disponibles pour les sessions de découverte d’issues

Configuration Learning

Située à /p/{id}/learning-setup. Configure l’ Learning Extraction Agent - le type de session qui lit les transcriptions de session terminées et en extrait des enregistrements de learning structurés. Champs :

• Outil CLI - Quelle CLI d’agent de codage utiliser
• Modèle - Le modèle LLM spécifique pour l’extraction des learnings
• Effort de réflexion - Profondeur de raisonnement
• Context - Le Context Document injecté par défaut dans les sessions de learning
• Skills, Commands, Scripts - Assets par défaut disponibles pour les sessions de learning

Configuration Merging

Située à /p/{id}/merging-setup. Configure le Merge Agent - le type de session responsable de la fusion des changements de code des runs de workflow terminés dans la branche principale. Champs :

• Outil CLI - Quelle CLI d’agent de codage utiliser
• Modèle - Le modèle LLM spécifique pour les opérations de merge
• Effort de réflexion - Profondeur de raisonnement (un effort plus élevé aide à résoudre les conflits de merge complexes)
• Context - Le Context Document injecté par défaut dans les sessions de merging
• Skills, Commands, Scripts - Assets par défaut disponibles pour les sessions de merging

Configuration Evaluator

Située à /p/{id}/evaluator-setup. Configure le Quality Evaluator - un type de session qui note et évalue la sortie de l’agent par rapport à des critères de qualité définis. L’Evaluator est utilisé lorsque vous souhaitez une mesure de qualité quantitative plutôt qu’un verdict binaire réussite/échec. Champs :

• Outil CLI - Quelle CLI d’agent de codage utiliser
• Modèle - Le modèle LLM spécifique pour les sessions d’évaluation
• Effort de réflexion - Profondeur de raisonnement
• Context - Le Context Document injecté par défaut dans les sessions evaluator
• Skills, Commands, Scripts - Assets par défaut disponibles pour les sessions evaluator

Configuration Judge

Située à /p/{id}/judge-setup. Configure l’ Output Judge - un type de session qui compare plusieurs sorties d’agent côte à côte et sélectionne la meilleure. Le Judge est utilisé dans les pipelines d’évaluation où plusieurs variantes d’une solution sont générées et où vous souhaitez une sélection automatisée du gagnant. Champs :

• Outil CLI - Quelle CLI d’agent de codage utiliser
• Modèle - Le modèle LLM spécifique pour les sessions judge
• Effort de réflexion - Profondeur de raisonnement (un effort élevé est recommandé pour les comparaisons nuancées)
• Context - Le Context Document injecté par défaut dans les sessions judge
• Skills, Commands, Scripts - Assets par défaut disponibles pour les sessions judge

Champs de paramètres de projet supplémentaires

Les paramètres suivants sont disponibles dans le schéma des Paramètres du projet mais ne sont pas couverts dans les sections précédentes. Ils contrôlent le déploiement, les tests, le cycle de vie et les comportements d’infrastructure avancés.

Variables d’environnement de déploiement

En plus des variables d’environnement de sandbox (utilisées dans les sessions de développement), vous pouvez définir un ensemble distinct de Variables d’environnement de déploiement pour les contextes de déploiement et de production. Celles-ci sont stockées chiffrées et ne sont injectées que dans les sessions effectuant des opérations de déploiement - elles ne sont pas visibles dans les sessions de sandbox standard.

Utilisez les variables d’env de déploiement pour les clés API de production, les URL de base de données de production, les tokens CDN et autres identifiants qui ne devraient jamais être présents dans les sandboxes de développement. Le format clé/valeur est identique aux variables d’env de sandbox, avec la même prise en charge du masquage des secrets.

Identifiants d’utilisateur de test

Pour les projets qui nécessitent des tests end-to-end authentifiés, vous pouvez stocker des Identifiants d’utilisateur de test dans les Paramètres du projet. Ceux-ci sont mis à disposition des sessions de sandbox afin que les agents puissent se connecter à l’application en tant qu’utilisateur de test et exercer les fonctionnalités authentifiées.

• E-mail - Adresse e-mail du compte de test
• Mot de passe - Mot de passe du compte de test (stocké chiffré)

Les identifiants sont injectés en tant que variables d’environnement dans la sandbox afin que les agents et les scripts de test puissent les référencer sans qu’ils soient codés en dur nulle part.

Modèle de PR

Le champ Modèle de PR accepte un modèle markdown utilisé lorsque les agents créent des pull requests à partir des runs de workflow. Le modèle suit le même format qu’un fichier GitHub .github/pull_request_template.md. Lorsqu’un agent ouvre une pull request, ce modèle est utilisé comme corps de la PR, prérempli avec le contexte pertinent du run de workflow (titre de l’issue, résumé du prompt, éléments de checklist).

## Summary
<!-- Describe what this PR does and why -->

## Changes
<!-- List the key files and components changed -->

## Testing
- [ ] Unit tests added or updated
- [ ] Build passes (`bun run build`)
- [ ] Lint clean (`bun run lint`)
- [ ] E2E tests pass (if applicable)

## Related Issues
<!-- Link to the issue or task this PR resolves -->

Clé de déploiement Convex

La Clé de déploiement Convex est utilisée par les agents pour déployer les fonctions Convex depuis une sandbox. Lorsqu’elle est définie, les agents peuvent exécuter npx convex deploy à l’intérieur de la sandbox et la clé authentifie le déploiement vers votre projet Convex. Cela permet des workflows end-to-end entièrement automatisés où l’agent écrit du code backend et le déploie en une seule session.

Générez une clé de déploiement depuis le tableau de bord Convex sous les paramètres de déploiement de votre projet. Les clés de déploiement sont limitées à un déploiement Convex spécifique et devraient utiliser les permissions minimales requises.

Clé de dev Convex

La Clé de dev Convex est utilisée pour accéder à Convex en mode développement depuis les sandboxes. Contrairement à la clé de déploiement (qui cible les déploiements de production), la clé de dev se connecte à votre déploiement de développement Convex, permettant aux agents de lire et écrire des données dans la base de données de dev pendant les sessions de développement.

Mise en pause automatique

Le commutateur Mise en pause automatique contrôle si les sandboxes inactives du projet sont automatiquement mises en pause après une période d’inactivité. Lorsqu’elle est activée, une sandbox qui n’a pas reçu d’entrée utilisateur ni produit de nouvelle sortie pendant une période configurable est automatiquement suspendue pour économiser des ressources.

Les sandboxes en pause préservent leur état de système de fichiers et peuvent être reprises. La mise en pause automatique est recommandée pour les projets où les sessions de sandbox sont fréquemment laissées en cours d’exécution par accident, car elle évite les coûts galopants dus aux sandboxes E2B inactives.

Durée maximale de pause

Le champ Durée maximale de pause définit combien de temps une sandbox en pause est conservée avant d’être définitivement arrêtée. Une fois qu’une sandbox a été mise en pause plus longtemps que cette durée, elle est automatiquement terminée et son état est supprimé. Les valeurs valides vont de quelques minutes à quelques heures, selon votre plan.

Définir une durée maximale de pause plus courte réduit les coûts en arrêtant plus tôt les sandboxes oubliées. Définir une durée plus longue donne aux membres de l’équipe plus de temps pour revenir à une sandbox en pause et reprendre le travail. La bonne valeur dépend des habitudes de travail de votre équipe.

Logo du projet

Vous pouvez téléverser un logo personnalisé pour le projet. Le logo est affiché dans le rail de projet de la barre latérale et aide à distinguer visuellement les projets lorsque vous êtes membre de plusieurs équipes. Si aucun logo n’est téléversé, le projet affiche un badge d’initiales coloré dérivé du nom du projet.

Prochaines étapes