Architecture pour les contributeurs
Cette page est une carte destinée aux contributeurs. Elle pointe vers les directives canoniques du dépôt plutôt que de réénoncer chaque règle d'implémentation.
Sources canoniques
Utilisez ces fichiers comme source de vérité lorsque vous modifiez l'application :
| Besoin | Source canonique |
|---|---|
| Vue d'ensemble du dépôt et commandes | README.md |
| Conventions de travail locales | CLAUDE.md |
| Garde-fous stricts | AGENT_CRITICAL_GUARDRAILS.md |
| Organisation des fonctionnalités moyennes et grandes | docs/FEATURE_ARCHITECTURE_STANDARD.md |
| Débogage du lancement des équipes d'agents | docs/team-management/debugging-agent-teams.md |
Organisation des fonctionnalités
Les fonctionnalités moyennes et grandes doivent résider sous src/features/<feature-name>/ et suivre le standard d'architecture des fonctionnalités. Gardez les éléments internes d'une fonctionnalité derrière des points d'entrée publics, et évitez les imports profonds qui traversent les frontières entre fonctionnalités.
Pour tout nouveau travail, partez de la slice src/features/recent-projects existante comme implémentation de référence locale. Les petits correctifs peuvent rester proches du chemin de code existant lorsque créer une slice de fonctionnalité ajouterait plus de structure que de valeur.
Frontières runtime et fournisseur
Agent Teams possède l'orchestration : équipes, tâches, messages, état de lancement, interface de revue, diagnostics et persistance locale.
Le chemin runtime/fournisseur sélectionné possède l'exécution du modèle, l'authentification, la disponibilité du modèle, les limites de débit, la sémantique des outils et les preuves de transcription spécifiques au runtime. Ne faites pas en sorte que les prompts ou l'état de l'interface compensent une authentification manquante, des binaires manquants, des identifiants de modèle rejetés ou des pannes de fournisseur. Pour les détails de configuration côté utilisateur, voir Fournisseurs et runtimes.
Débogage des équipes d'agents
En cas de blocage au lancement, d'états OpenCode registered / bootstrap non confirmé, de réponses de coéquipiers manquantes ou de journaux de tâches suspects, partez du runbook de débogage dédié. Inspectez l'artefact d'échec de lancement le plus récent sous ~/.claude/teams/<team>/launch-failure-artifacts/latest.json, puis corrélez l'état de l'interface avec les fichiers persistés et les preuves spécifiques au runtime.
Évitez les nettoyages larges pendant le débogage. N'arrêtez que le processus, la lane, l'équipe ou l'exécution de smoke test que vous pouvez identifier comme appartenant au problème.
Conventions des contributeurs
- Utilisez
pnpm devpour l'application de bureau Electron pendant le développement normal. - N'utilisez pas le mode dev navigateur comme substitut au runtime de bureau, à l'IPC, au terminal, à l'authentification du fournisseur ou au comportement du cycle de vie d'une équipe.
- Gardez séparées les responsabilités d'Electron main, preload, renderer, shared et des fonctionnalités.
- Utilisez
wrapAgentBlock(text)pour les blocs réservés aux agents au lieu de concaténer manuellement les marqueurs. - Privilégiez une vérification ciblée. Évitez les
lint:fixlarges ou le brassage de formatage à moins que la tâche ne porte explicitement sur le formatage. - Traitez le parsing, le cycle de vie des tâches, la détection fournisseur/runtime, la persistance, l'IPC, Git et les flux de revue comme des zones à haut risque qui nécessitent des tests ciblés ou un chemin de vérification clair.