agent-ecosystem/landing/product-docs/fr/reference/contributor-architecture.md
777genius 95e0f34d31 docs(product-docs): add zh, es, ja, fr, de doc translations
Localize the VitePress docs into Simplified Chinese, Spanish, Japanese,
French and German (18 pages each), mirroring the existing en/ru structure.

- generate the 5 new locales in config.ts from a single strings table
  (nav, sidebar, search, footer, docFooter, outline, editLink) with
  locale-prefixed links
- rework DocsCardGrid from the binary isRu check to a per-locale map so
  the home cards render translated copy and prefixed links for every locale
2026-05-31 17:50:54 +03:00

4.5 KiB
Raw Blame History

title description lang
Architecture pour les contributeurs Documentation Agent Teams Guide du contributeur sur l'organisation des fonctionnalités, les frontières runtime/fournisseur, les garde-fous stricts et les documents d'architecture canoniques. fr-FR

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 dev pour 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:fix larges 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.

Pages connexes