specrails-desktop 2.8.0 → 2.9.0

package/docs/guide/fr/insights/1-analytics-and-cost-tracking.md

@@ -0,0 +1,78 @@
+# Analytics et suivi des coûts
+
+Chaque fois que Specrails lance une CLI IA pour vous — un job de pipeline, une spec rapide, une session Explore, un affinage IA, un résumé de fichier — il consigne ce qui s'est passé : quel modèle a tourné, combien de tokens sont entrés et sortis, combien de temps cela a pris et combien cela a coûté. La section **Analytics** transforme tout cela en un tableau de bord unique, pour que vous sachiez toujours où part votre budget IA.
+
+Ouvrez-la depuis la barre latérale droite (elle est intitulée **Analytics**). Tout ce que vous y voyez se rapporte au projet dans lequel vous vous trouvez actuellement — changez de projet et les chiffres suivent.
+
+## Ce qui compte comme dépense
+
+Specrails suit cinq types d'activité IA, appelés *surfaces*. Chacune dispose d'un code couleur cohérent sur tous les graphiques, pour que vous puissiez la repérer d'un coup d'œil :
+
+- **Job** — un rail de pipeline qui enchaîne Architect → Developer → Reviewer → Ship.
+- **Quick spec** — une spec générée par la voie rapide d'Add Spec.
+- **Explore spec** — une conversation Explore où vous façonnez une spec en discutant.
+- **AI edit** — un affinage assisté par l'IA sur un agent ou un fichier.
+- **File summary** — les résumés en langage clair qui alimentent le Code explorer.
+
+Deux activités ne sont délibérément *pas* suivies : le panneau de chat latéral et l'assistant de configuration lancent tous deux des CLI IA, mais ils n'apparaissent jamais dans vos dépenses. Le tableau de bord reflète ainsi un travail réel et reproductible plutôt que des échanges anecdotiques.
+
+## Lire le tableau de bord
+
+La page est constituée d'une série de blocs, de haut en bas :
+
+### La jauge de consommation (Hero)
+
+Le grand chiffre en haut représente votre dépense totale pour la période sélectionnée, avec un écart **vs préc.** qui vous permet de voir en un coup d'œil si la tendance est à la hausse ou à la baisse par rapport à la fenêtre précédente. Si vous venez tout juste de commencer à utiliser un projet, l'état vide vous indique quand le suivi a démarré (« Suivi démarré le YYYY-MM-DD ») — il n'y a pas de récupération rétroactive de l'historique, donc la jauge ne connaît que les exécutions survenues alors que vous étiez sur cette version.
+
+### Chronologie quotidienne
+
+Un graphique à barres empilées de la dépense par jour, ventilée par surface. Les jours sans activité s'affichent à zéro plutôt que d'être omis, pour que la silhouette de votre semaine reste honnête. C'est le moyen le plus rapide de voir *quand* un lot coûteux a tourné.
+
+### Quick vs Explore
+
+Une carte côte à côte comparant vos deux styles de création de spec. Si vous avez lancé moins de cinq sessions Explore, elle affiche un appel à l'action tout en douceur plutôt que des moyennes trompeuses — les petits échantillons ne font pas de bonnes comparaisons.
+
+### Par modèle
+
+Vos principaux modèles par dépense (jusqu'à dix). Cliquez sur n'importe quel modèle pour filtrer l'ensemble du tableau de bord sur ce seul modèle — pratique quand vous voulez savoir combien vous coûte vraiment un modèle haut de gamme en particulier.
+
+### Nuage de points coût vs tours
+
+Chaque point représente une invocation, avec le coût en fonction du nombre de tours. Les valeurs aberrantes — les exécutions coûteuses à nombreux tours — sautent aux yeux. (Le nuage affiche vos 500 points les plus récents pour rester fluide.)
+
+### Top tickets
+
+Vos dix tickets les plus coûteux, toutes *surfaces* confondues, de sorte qu'un ticket qui a coûté un peu en Explore et beaucoup dans un job affiche son vrai total. Les tickets supprimés et les exécutions non attribuées disposent de leurs propres catégories, pour que rien ne disparaisse silencieusement des totaux.
+
+### Table des invocations brutes
+
+La vérité de terrain : une ligne par invocation. Ce bloc possède ses propres filtres secondaires qui n'affectent que la table, pour que vous puissiez creuser sans perturber les graphiques au-dessus.
+
+## Filtrer
+
+L'en-tête épinglé en haut porte les deux filtres principaux — **période** et **surface** — et tous deux sont enregistrés dans l'URL de la page. Cela signifie que vous pouvez mettre en favori ou partager une vue filtrée (« 30 derniers jours, jobs uniquement ») et elle se rouvrira exactement comme vous l'aviez laissée. Les filtres de la table brute sont distincts et restent locaux à ce bloc.
+
+Un mot sur la précision : les exécutions en échec ou interrompues sont exclues des *moyennes de coût* (elles fausseraient les chiffres par exécution) mais elles comptent tout de même dans votre nombre total d'exécutions et votre taux d'échec. Les moyennes restent ainsi propres tandis que le portrait de la fiabilité reste complet.
+
+## Coût par ticket
+
+Pas besoin de passer par la page Analytics pour savoir ce qu'a coûté une spec. Ouvrez n'importe quel ticket et, s'il a une dépense rattachée, vous verrez un résumé sur une ligne juste sous le titre :
+
+> $0.42 · 6 turns · 1m 12s active · breakdown
+
+Cliquez dessus et vous arrivez sur la page Analytics déjà filtrée sur ce ticket. C'est le chemin le plus court entre « combien cette fonctionnalité m'a-t-elle coûté ? » et le détail complet.
+
+## Exporter vos données
+
+Quand vous avez besoin des chiffres en dehors de l'application — un tableur, un rapport financier, votre propre analyse — utilisez le menu déroulant **Export**. Il propose quatre formats :
+
+- **CSV résumé** — un fichier multi-sections avec les totaux, la chronologie quotidienne, la ventilation par surface, par modèle et les top tickets.
+- **JSON résumé** — le même résumé, structuré.
+- **CSV brut** — chaque ligne d'invocation (jusqu'à 10 000 ; il signale s'il a dû tronquer).
+- **JSON brut** — les mêmes lignes brutes, structurées.
+
+Les exports respectent les filtres de période et de surface actuellement appliqués, et les fichiers sont nommés de manière à se trier logiquement : `<project>-analytics-<period>-<date>.csv`. Le bouton est désactivé quand il n'y a rien à exporter, et un message d'erreur clair s'affiche si un téléchargement échoue.
+
+## Toujours à jour
+
+Pas besoin d'actualiser. Quand une nouvelle invocation est enregistrée n'importe où dans le projet, le tableau de bord ouvert se recharge discrètement un instant plus tard, pour que la jauge de consommation suive le rythme du travail à mesure qu'il se termine.

package/docs/guide/fr/insights/2-the-integrated-terminal.md

@@ -0,0 +1,46 @@
+# Le terminal intégré
+
+Specrails embarque un véritable terminal — le panneau qui remonte depuis le bas de la fenêtre, exactement comme celui de VS Code ou Cursor. Il fait tourner votre shell réel, dans le répertoire réel de votre projet, pour que vous puissiez lancer `git`, `npm`, vos tests, ou tout autre commande sans quitter l'application.
+
+## L'ouvrir et le fermer
+
+Le plus rapide passe par le clavier : **Cmd+J** (macOS) ou **Ctrl+J** (Windows/Linux) ouvre et ferme le panneau, et place le focus sur le terminal dès qu'il apparaît pour que vous puissiez taper immédiatement. Vous pouvez aussi utiliser le chevron dans la barre d'état.
+
+Le panneau a trois états :
+
+- **Masqué** — rangé hors de vue.
+- **Restauré** — le panneau normal à mi-hauteur.
+- **Agrandi** — qui prend toute la zone de travail quand vous avez besoin de place pour lire une sortie.
+
+Replier le panneau (le chevron) **n'arrête** rien — vos shells continuent de tourner en arrière-plan. La seule chose qui met réellement fin à une session, c'est de la fermer (l'icône corbeille, ou le ✕ propre à chaque onglet).
+
+## Plusieurs sessions
+
+Vous pouvez faire tourner plusieurs terminaux à la fois dans le même projet — jusqu'à dix. Chacun a son propre onglet ; vous pouvez les renommer pour ne pas confondre « dev server » et « tests ». Ils démarrent tous dans le dossier de votre projet et chargent votre profil de shell (`.zshrc`, `.bashrc`, etc.), pour que vos alias et votre PATH soient exactement ceux que vous attendez.
+
+Voici le point important : vos terminaux **survivent aux changements de projet et d'onglet**. Specrails maintient chaque session vivante et intacte en coulisses — historique de défilement, processus en cours, tout — de sorte que basculer vers Analytics puis revenir ne réinitialise pas votre shell ni n'interrompt une commande de longue durée. Les sessions ne se terminent que lorsque vous les fermez explicitement (ou lorsque vous supprimez le projet entier).
+
+## Par projet, et mémorisé
+
+Que le panneau soit ouvert, la hauteur à laquelle vous l'avez étiré, les onglets qui existent — tout cela est mémorisé **par projet**. Revenez sur un projet et il est configuré comme vous l'aviez laissé.
+
+## Les fonctionnalités premium
+
+Ce n'est pas une console minimaliste. Le terminal embarque tout le confort qu'on attend d'un terminal de premier ordre :
+
+- **Un rendu rapide et net** grâce à WebGL (avec un repli automatique pour qu'il ne casse jamais), une gestion complète de la largeur Unicode et les ligatures de police.
+- **La recherche dans l'historique de défilement** avec **Cmd+F** — idéal pour retrouver cette erreur enfouie 500 lignes plus haut.
+- **Le zoom de police** avec **Cmd+=**, **Cmd+-** et **Cmd+0** pour réinitialiser.
+- **Les raccourcis presse-papiers** — Cmd+C / Cmd+V pour copier et coller, Cmd+K pour effacer — ainsi qu'un menu contextuel au clic droit.
+- **Le glisser-déposer de chemins de fichiers** (dans l'application desktop) : déposez un fichier sur le terminal et son chemin est inséré, correctement échappé pour votre shell.
+- **Le redimensionnement fluide** — étirer la hauteur du panneau ou replier la barre latérale ne fait pas trembloter la sortie.
+- **Les images en ligne** — les terminaux qui émettent des images au format Sixel ou iTerm2 les affichent directement sur place.
+- **L'intégration au shell** — Specrails sait où commence et où finit chaque commande, ce qui lui permet de suivre votre historique de commandes et de vous prévenir quand une commande de longue durée se termine (une notification desktop, avec un repli navigateur). Si votre shell ne peut pas être instrumenté pour une raison quelconque, l'intégration se dégrade discrètement et vous le signale une seule fois.
+
+## Paramètres
+
+Les préférences du terminal vivent sur deux couches : une valeur par défaut à l'échelle de l'application et une surcharge optionnelle par projet. Le réglage par projet l'emporte lorsqu'il est présent, ce qui vous permet de conserver une apparence globale tout en ajustant un projet qui a besoin de quelque chose de différent.
+
+## Le désactiver
+
+Le terminal est activé par défaut. Si vous préférez vous en passer, vous pouvez le désactiver via les flags `VITE_FEATURE_TERMINAL_PANEL` (client) ou `SPECRAILS_TERMINAL_PANEL` (serveur) — mettez l'un ou l'autre à `false`. La plupart des gens le laisseront simplement activé.

package/docs/guide/fr/insights/3-code-explorer.md

@@ -0,0 +1,50 @@
+# Code explorer
+
+La section **Code** vous offre une fenêtre conviviale et en lecture seule sur votre dépôt — pensée tout particulièrement pour celles et ceux qui veulent comprendre ce que l'IA construit sans devoir vivre dans un éditeur. Vous disposez d'une arborescence de fichiers à gauche, d'un afficheur de code à droite, et, au-dessus du code, d'un résumé en langage clair de ce que fait réellement chaque fichier.
+
+Dans cette version, c'est strictement en lecture seule : rien de ce que vous faites ici ne modifie vos fichiers. Voyez-le comme une salle de lecture, pas comme un atelier.
+
+Ouvrez-la depuis la barre latérale droite (**Code**) et, comme tout le reste, elle se rapporte à votre projet actuel.
+
+## L'arborescence de fichiers
+
+Le volet de gauche est une arborescence virtualisée des fichiers de votre projet — rapide même sur de gros dépôts. Elle respecte votre `.gitignore` et une liste d'exclusion intégrée, pour que vous voyiez les fichiers qui comptent, et non un océan d'artefacts de build et de `node_modules`.
+
+À côté des fichiers, vous remarquerez des **pastilles de provenance** — de petits marqueurs qui vous indiquent qu'un fichier a été *touché par l'IA*. C'est le cœur du Code explorer : Specrails enregistre quels fichiers chaque job de pipeline a créés ou modifiés, et les relie au ticket qui a déclenché le travail. Vous pouvez ainsi répondre, d'un coup d'œil, à la question « est-ce l'IA qui a écrit ça, ou moi ? »
+
+En haut de l'arborescence se trouve un filtre :
+
+- **Touchés par l'IA** (par défaut) — uniquement les fichiers que l'IA a modifiés.
+- **Tous les fichiers** — l'arborescence complète.
+
+Votre choix est mémorisé par projet : si vous vous intéressez surtout aux changements produits par l'IA, vous les verrez en premier à chaque fois.
+
+## L'afficheur de code
+
+Cliquez sur un fichier et il s'ouvre dans un afficheur complet (propulsé par Monaco, le même moteur que VS Code) avec une coloration syntaxique soignée qui s'accorde au thème d'application que vous avez choisi. Quelques limites raisonnables gardent l'ensemble fluide : les fichiers binaires sont poliment refusés, et les très gros fichiers (au-delà de 2 Mo) ne se chargent pas.
+
+Le fichier en cours est enregistré dans l'URL de la page, pour que vous puissiez mettre en favori ou partager un lien direct vers un fichier précis.
+
+L'édition ne faisant pas partie de cette version, l'afficheur propose un bouton **Modifier dans un éditeur externe** qui copie le chemin absolu du fichier — collez-le dans l'éditeur de votre choix et reprenez le travail là-bas.
+
+## Les résumés IA
+
+Au-dessus du code, vous verrez un **résumé en langage clair** du fichier — à quoi il sert, ce qu'il fait — rédigé pour qu'une personne non développeuse puisse suivre. Ces résumés sont générés pour vous et mis en cache, de sorte que rouvrir un fichier déjà consulté est instantané.
+
+Les résumés savent rester à jour : ils sont indexés sur le contenu du fichier, donc lorsqu'un fichier change réellement, le résumé est régénéré, mais les fichiers inchangés ne sont pas résumés à nouveau inutilement. Si vous modifiez vous-même un fichier, son résumé est marqué comme obsolète plutôt que silencieusement régénéré — vous gardez la main sur le moment où il est rafraîchi. Une action **régénérer** est disponible quand vous voulez un nouveau résumé à la demande.
+
+Quelques garde-fous gardent les coûts raisonnables : la génération des résumés s'inscrit dans un **budget mensuel** (quelques dollars par défaut, configurable dans les Paramètres), et il existe des plafonds sur le nombre de résumés qu'un même job peut déclencher. Si un résumé est ignoré, l'application vous en dit la raison — budget atteint, plafond par job, ou fichier tout simplement introuvable.
+
+Vous pouvez aussi choisir la **langue des résumés** (anglais ou espagnol) dans les paramètres globaux, sous la rubrique *Code section*.
+
+## Relier le code aux specs
+
+Le lien de provenance fonctionne dans les deux sens. Dans le Code explorer, cliquer sur la pastille d'un ticket attachée à un fichier ouvre le détail de ce ticket. Et dans l'autre sens, la vue **détail du ticket** comporte une section *Fichiers touchés par ce ticket* — cliquez-y sur un fichier et vous atterrissez directement dans le Code explorer avec ce fichier ouvert. La boucle est ainsi bouclée entre « voici la spec que nous avons écrite » et « voici le code qui en est sorti ».
+
+## Ce qu'il ne fait pas (encore)
+
+Pour poser les attentes clairement, cette première version laisse délibérément quelques éléments de côté : l'édition dans l'application, les résumés par symbole ou par répertoire, une vue de diff narrative, et le « pose une question à l'IA sur ce fichier » conversationnel. La provenance attribue un fichier à son ticket principal uniquement. Ce sont là le genre de choses qui pourront se développer au fil du temps.
+
+## Le désactiver
+
+Le Code explorer est activé par défaut. Il peut être désactivé avec les flags `VITE_FEATURE_CODE_EXPLORER` (client) ou `SPECRAILS_CODE_EXPLORER` (serveur) — mettez l'un ou l'autre à `false`. Le désactiver laisse toutes vos données enregistrées et vos résumés sagement sur le disque, intacts, au cas où vous le réactiveriez.

package/docs/guide/fr/integrations/1-ai-providers.md

@@ -0,0 +1,64 @@
+# Fournisseurs d'IA (Claude, Codex, Gemini)
+
+Specrails n'est lié à aucune IA en particulier. Chaque endroit de l'app qui dialogue avec une IA — Explore Spec, Quick spec, les rails, le chat, l'AI Edit, le bouton « Open AI CLI » du terminal — peut passer par l'un des trois fournisseurs de premier plan. Vous choisissez ceux qu'un projet utilise, et vous pouvez même changer de fournisseur tâche par tâche.
+
+## Les trois fournisseurs
+
+| Fournisseur | CLI | Édité par | Notes |
+|---|---|---|---|
+| **Claude** | `claude` | Anthropic | Le plus complet. Seul fournisseur pour les Agents (profils), les rails Ultracode et le Contract Refine. |
+| **Codex** | `codex` | OpenAI | Nécessite codex `0.128.0+`. Lit ses serveurs MCP depuis votre fichier global `~/.codex/config.toml`. |
+| **Gemini** | `gemini` | Google | Nécessite gemini `0.11.0+`. Utilise une télémétrie native et un fichier d'instructions `GEMINI.md`. |
+
+Les trois sont **activés par défaut**. Un fournisseur apparaît dans **Ajouter un projet** dès que sa CLI est installée et présente dans votre `PATH`. La première étape est donc toujours la même : installez la CLI souhaitée et connectez-vous avec, exactement comme l'indique sa propre documentation. Dès que `claude --version` (ou `codex`, ou `gemini`) fonctionne dans votre terminal, Specrails peut l'utiliser.
+
+## Installer un fournisseur pour un projet
+
+Lorsque vous ajoutez un projet, l'assistant de configuration vous demande quel(s) fournisseur(s) installer. Choisissez-en un, déroulez l'étape d'installation, et c'est terminé. À partir de là, le projet *possède* simplement ce fournisseur — vous n'avez plus jamais à y penser. Les specs, les rails, le chat et les analytics fonctionnent de la même façon quel que soit votre choix.
+
+Si une CLI que vous voulez n'apparaît pas dans Ajouter un projet, c'est presque toujours parce qu'elle n'est pas installée ou absente de votre `PATH`. Installez-la, puis rouvrez Ajouter un projet.
+
+## Installer plusieurs fournisseurs pour un même projet
+
+Vous pouvez installer **plus d'un** fournisseur dans le même projet — par exemple Claude *et* Gemini. Dans **Ajouter un projet**, la liste des fournisseurs devient une série de cases à cocher ; cochez tout ce que vous voulez. Le premier que vous sélectionnez devient le fournisseur **principal** (par défaut) du projet ; les autres restent disponibles comme alternatives.
+
+Quelques points utiles à connaître sur les projets multi-fournisseurs :
+
+- **Avec un seul fournisseur, rien ne change.** Si un projet n'a qu'un seul fournisseur, vous ne verrez jamais de sélecteur de fournisseur où que ce soit — l'app reste épurée et simple.
+- **La barre latérale droite n'affiche que les sections prises en charge par tous les fournisseurs installés.** Comme les Agents (profils) sont un concept propre à Claude, la section **Agents** disparaît dès qu'un projet inclut un fournisseur autre que Claude. Tout le reste (Specs, Code, Analytics, Intégrations, Terminal, Chat) demeure.
+- **Le choix des fournisseurs est verrouillé après la création.** Dans cette version, vous choisissez vos fournisseurs au moment d'ajouter le projet et vous ne pouvez plus les modifier ensuite depuis les Réglages. S'il vous faut une combinaison différente, créez un nouveau projet.
+
+## Choisir un fournisseur à chaque invocation
+
+Tout l'intérêt d'un projet multi-fournisseurs, c'est de choisir l'IA la plus adaptée à chaque tâche — sans toucher au moindre réglage global. Partout où une IA s'exécute, un petit sélecteur de fournisseur apparaît (uniquement lorsque le projet en compte plusieurs) :
+
+- **Ajouter une spec** — un sélecteur de moteur vous permet d'Explorer ou de générer en Quick une spec avec le fournisseur de votre choix.
+- **En-tête de rail** — choisissez le moteur de ce rail précis avant de le lancer.
+- **Terminal** — le bouton « Open AI CLI » (Sparkles) ouvre un menu de fournisseurs pour basculer dans n'importe quelle CLI installée, dans le répertoire de ce projet.
+
+Votre choix est mémorisé par projet, avec le fournisseur principal comme valeur par défaut, pour ne pas avoir à le refaire à chaque fois.
+
+## Ce que seul Claude peut faire
+
+Une poignée de fonctionnalités sont par nature propres à Claude : elles sont donc soit masquées, soit ignorées lorsqu'un autre fournisseur est en jeu :
+
+- **Agents (profils)** — le catalogue d'agents par projet et le routage des modèles. Masqué sur tout projet incluant un fournisseur autre que Claude.
+- **Rails Ultracode** — toujours exécutés sur Claude.
+- **Contract Refine** — la passe supplémentaire « Contract Layer » sur une spec validée ne s'exécute que lorsque le fournisseur de la conversation est Claude.
+- **Modes avancés d'Ajouter une spec** (SMASH / Contract Layer) — masqués pour les moteurs autres que Claude.
+
+Tout le reste — Explore, Quick spec, le pipeline complet des rails, l'AI Edit, le chat, les analytics de coût — fonctionne avec les trois fournisseurs.
+
+## Suivi des coûts entre fournisseurs
+
+La page **Analytics** suit chaque invocation facturable, quel que soit le fournisseur. Sur les projets multi-fournisseurs, elle ajoute des puces de filtre par moteur pour comparer les dépenses par fournisseur. Claude rapporte son coût exact ; pour Codex et Gemini, Specrails estime le coût à partir d'une table de tarifs intégrée — ce sont donc des approximations proches plutôt que les montants réellement facturés.
+
+## Dépannage
+
+- **Un fournisseur que j'ai installé n'est pas proposé.** Vérifiez que la CLI est dans votre `PATH` (essayez `claude --version` / `codex --version` / `gemini --version` dans un terminal neuf). L'app sonde les CLI des fournisseurs via votre `PATH` système.
+- **Les serveurs MCP de Codex ne se chargent pas dans le chat.** Codex lit ses serveurs MCP depuis votre fichier global `~/.codex/config.toml` — enregistrez-les là avec `codex mcp add`.
+- **Désactivation d'urgence.** Un fournisseur peut être coupé à l'échelle de l'app via une variable d'environnement (`SPECRAILS_CODEX_BETA=0` ou `SPECRAILS_GEMINI_BETA=0`). Cela masque uniquement le fournisseur de la *sélection* ; c'est rarement nécessaire.
+
+## Voir aussi
+
+Les guides dédiés à chaque fournisseur entrent davantage dans le détail de chaque CLI : le guide Codex et le guide Gemini couvrent chacun l'installation, ce qui fonctionne et les particularités propres au fournisseur.

package/docs/guide/fr/integrations/2-plugins.md

@@ -0,0 +1,44 @@
+# Plugins (Intégrations)
+
+La section **Intégrations** est une place de marché par projet de modules optionnels qui étendent les capacités de l'IA. Chaque projet décide indépendamment des plugins qu'il souhaite — installer un plugin dans un projet ne touche jamais à un autre.
+
+Les plugins fonctionnent en enregistrant discrètement un **serveur MCP** (Model Context Protocol) dans votre projet, ce qui donne à l'IA de nouveaux outils à appeler pendant les rails et le chat. Pas besoin de comprendre MCP pour vous en servir : installez-le, et il sera disponible au prochain rail.
+
+## Ce qui est disponible aujourd'hui
+
+Cette version est **fournie en mode intégré uniquement** : les plugins que vous pouvez installer sont ceux qui sont embarqués dans l'app. Il n'y a pas de registre distant, pas de plugin déposé par les utilisateurs, ni de chargement de code tiers — tout ce qui figure dans le catalogue est donc vérifié et livré avec Specrails.
+
+Le plugin phare est :
+
+- **Serena** — navigation sémantique du code. Il donne à l'IA une compréhension de votre code basée sur un serveur de langage (aller à la définition, trouver les références, recherche tenant compte des symboles) plutôt qu'une simple correspondance de texte. Idéal pour les dépôts volumineux ou inconnus, lorsque vous voulez que l'agent raisonne sur de vrais symboles.
+
+  Serena requiert l'outil `uv` dans votre `PATH` (il s'exécute via `uvx`). L'app détecte automatiquement la présence de `uv` et vous prévient s'il manque.
+
+## Installer un plugin
+
+1. Ouvrez **Intégrations** depuis la barre latérale droite.
+2. Repérez le plugin dans le catalogue. Chaque carte affiche un statut : **Non installé**, **Installé**, **Dégradé** ou **Orphelin**.
+3. Cliquez sur le plugin pour **prévisualiser l'installation** — cela vous montre exactement quels fichiers vont changer avant que quoi que ce soit ne se produise.
+4. Cliquez sur **Installer**. Vous suivez la progression en direct pendant la mise en place.
+
+En coulisses, l'installation est *chirurgicale et additive* : elle n'ajoute que ses propres entrées au `.mcp.json` de votre projet (et, pour certains plugins, un fichier de fragment dans l'espace de noms protégé `.claude/agents/`). Elle ne réécrit jamais votre configuration dans son ensemble, et l'ajout d'un second plugin ne peut jamais perturber le premier. Si l'installation ne parvient pas à se vérifier comme saine, elle effectue un retour arrière propre.
+
+## Gérer les plugins installés
+
+- **Santé.** Chaque plugin dispose d'une vérification de santé à la demande. Un plugin qui s'installe correctement mais ne démarre plus ensuite est marqué **Dégradé** — il ne bloquera pas vos rails ; vous verrez simplement le badge et la raison.
+- **Désinstaller.** Retirer un plugin supprime chirurgicalement uniquement les entrées qu'il possède, en laissant le reste de votre configuration intact.
+- **Orphelins.** Si les fichiers d'un plugin subsistent sans état correct (par exemple après une modification interrompue), il apparaît comme **Orphelin** et vous pouvez le nettoyer d'un clic.
+
+## Comment les plugins interviennent dans votre travail
+
+- **Rails.** Avant qu'un rail ne s'exécute, Specrails vérifie quels plugins sont installés et sains, et rend ces outils disponibles pour l'agent sur ce job. Un plugin dégradé est simplement ignoré pour cette exécution — le rail se lance quand même normalement. Chaque job enregistre un instantané des plugins actifs, visible dans l'export de diagnostic du job.
+- **Chat.** Le chat reprend automatiquement la configuration MCP de votre projet, de sorte que les plugins installés y sont également disponibles.
+- **Configuration.** Les plugins sont ignorés tant qu'un projet est encore en cours de configuration — ils entrent en jeu une fois le projet prêt.
+
+## Notes sur les fournisseurs
+
+Les plugins tiennent compte du fournisseur. Serena et les plugins MCP similaires s'activent pour les fournisseurs qui enregistrent MCP via le `.mcp.json` du projet (Claude et Gemini). Pour les projets Codex, les serveurs MCP sont gérés via la configuration globale propre à Codex ; les entrées de plugin dans **Intégrations** sont donc filtrées en conséquence. La carte Jira dans Intégrations est indépendante du fournisseur et s'affiche pour tout le monde — voir le guide Jira.
+
+## Fichiers réservés
+
+Les plugins gèrent un petit ensemble de fichiers bien défini dans votre projet : votre `.mcp.json` (fusionné chirurgicalement), un peu d'état sous `.specrails/plugins/`, et les fragments d'agent par plugin dans `.claude/agents/custom-<plugin>.md`. Ce sont des ressources d'équipe versionnables si vous souhaitez partager une intégration avec vos coéquipiers — l'app ne les écrase jamais aveuglément.

package/docs/guide/fr/integrations/3-jira-integration.md

@@ -0,0 +1,71 @@
+# Intégration Jira
+
+Vous voulez que vos specs vivent sur un véritable **tableau Jira** plutôt qu'à l'intérieur de Specrails ? L'intégration Jira adosse les specs d'un projet à des tickets Jira, maintient les statuts synchronisés au fil des rails, et reste discrète le reste du temps. Chaque projet se synchronise avec **son propre** tableau Jira.
+
+## Comment ça marche (la version courte)
+
+Specrails agit comme une **couche de synchronisation** entre Jira et votre projet. L'idée maîtresse : votre magasin de specs local reste la référence que lit le pipeline, et Specrails se charge de le maintenir en accord avec Jira.
+
+- Lorsque vous lancez un rail, Specrails fait passer le ticket Jira lié à **En cours**.
+- Lorsqu'un job se termine, Specrails fait transitionner le ticket (vers **Terminé**, ou de nouveau vers **À faire** en cas d'échec) et publie un commentaire de clôture avec l'identifiant du job, le coût et la durée.
+- Périodiquement, Specrails **interroge** Jira pour récupérer les changements effectués par quiconque sur le tableau et les répercute dans vos specs.
+
+Toutes les écritures vers Jira passent par une file d'attente durable et résistante aux pannes : un incident Jira passager ne casse donc jamais un job — la mise à jour est simplement retentée.
+
+## Connecter un tableau
+
+La connexion se fait depuis la page **Réglages** d'un projet (il existe aussi une étape facultative « Configurer Jira » à la fin de l'assistant d'ajout de projet). L'assistant de connexion vous guide :
+
+1. **Tester** — saisissez l'URL et les identifiants de votre Jira, et Specrails vérifie la connexion.
+2. **Choisir un projet** — sélectionnez le projet Jira avec lequel synchroniser.
+3. **Association des statuts (facultatif)** — associez les statuts de votre workflow Jira aux états de Specrails si la détection automatique a besoin d'un coup de main (voir plus bas).
+4. **Connecter** — c'est fait. Vos specs reflètent désormais ce tableau.
+
+### Authentification
+
+Cette version utilise une authentification par **collage de jeton** — rapide, locale, et sans aucun backend impliqué :
+
+- **Jira Cloud :** l'e-mail de votre compte plus un jeton API.
+- **Jira Data Center / Server :** un Personal Access Token (PAT).
+
+Votre jeton est stocké **chiffré sur votre propre machine** et n'en sort jamais. L'app indique uniquement si un jeton est présent, jamais le jeton lui-même.
+
+## Association des statuts
+
+La partie la plus délicate de toute synchronisation Jira, c'est de faire correspondre *votre* workflow aux états simples de Specrails (À faire / En cours / Terminé, plus les variantes annulé/livré). Specrails résout cela en deux niveaux :
+
+1. **Votre association de statuts explicite**, si vous en définissez une dans l'assistant — toujours prioritaire.
+2. **La détection automatique** à partir de la catégorie de chaque statut (new / in-progress / done) plus une correspondance intelligente pour les statuts de type annulation et livraison.
+
+Lorsqu'il doit déplacer un ticket à travers un workflow comportant des transitions conditionnées, il trouve un chemin valide étape par étape et renseigne au passage les champs requis (comme une résolution). Si un statut est réellement inaccessible, l'opération est mise de côté en lettre morte et vous est remontée plutôt que d'échouer en silence — vous verrez un indicateur **dégradé** et pourrez réessayer.
+
+## Hot-swap : activez et désactivez en toute sécurité
+
+Le lien Jira est **par spec**, capturé au moment où vous lancez un rail — ce n'est pas un interrupteur global et tout-ou-rien sur le tableau. C'est ce qui le rend sûr à basculer :
+
+- **Activer ou désactiver** l'intégration ne déplace jamais vos specs existantes.
+- **Se déconnecter** rend à votre projet son comportement normal de specs locales.
+- Les specs déjà dotées d'un lien Jira conservent leur écriture vers Jira ; celles qui n'en ont pas sont laissées tranquilles.
+
+Vous pouvez donc expérimenter librement — activez, lancez quelques rails, désactivez — sans chambouler ni votre tableau ni vos specs locales.
+
+## Au quotidien
+
+Une fois connecté, la page Réglages du projet affiche une **carte de connexion** où vous pouvez :
+
+- **Synchroniser maintenant** — forcer une interrogation immédiate au lieu d'attendre le minuteur.
+- **Réessayer les lettres mortes** — relancer les écritures vers Jira restées bloquées.
+- **Interrupteur hot-swap** — mettre temporairement en pause / reprendre l'intégration.
+- **Se déconnecter** — détacher proprement le tableau.
+
+Les specs adossées à Jira affichent un **badge de clé Jira** (comme `PROJ-123`) sur leur carte, et un clic renvoie au ticket. Vous recevrez aussi de petites notifications lorsqu'une synchronisation s'achève, lorsqu'un jeton d'authentification expire (pour que vous puissiez le renouveler), ou lorsque l'intégration passe en état dégradé.
+
+## Bon à savoir
+
+- **Interrogation, pas webhooks.** Comme Specrails s'exécute localement, il interroge Jira pour les changements entrants plutôt que de recevoir des notifications push. Les changements apparaissent dans l'intervalle d'interrogation, pas instantanément.
+- **Un tableau par projet.** Des projets différents peuvent se synchroniser avec des tableaux différents ; un même projet se synchronise avec un seul.
+- **Le dernier qui écrit l'emporte en cas de conflit**, pour le cas rare où deux onglets modifient le même brouillon en même temps.
+
+## Désactiver l'intégration
+
+Si vous souhaitez tout arrêter, il suffit de cliquer sur **Se déconnecter** depuis les Réglages. Vos specs retrouvent leur comportement purement local, et les métadonnées Jira restent simplement inutilisées — rien n'est détruit.

package/docs/guide/fr/integrations/4-mobile-companion.md

@@ -0,0 +1,38 @@
+# L'application compagnon mobile
+
+Specrails dispose d'une application compagnon pour téléphone afin de garder un œil sur vos rails quand vous êtes loin de votre bureau — regardez les jobs s'exécuter, voyez-les se terminer et restez dans la boucle sans rester assis devant le tableau de bord.
+
+## À quoi elle sert
+
+Le compagnon est une surface de **supervision**. Il se connecte à votre app Specrails de bureau en cours d'exécution via votre réseau local et reflète sur votre téléphone l'activité en direct des projets et des jobs. Voyez-le comme une fenêtre d'un coup d'œil sur les mêmes rails que vous suivriez autrement sur le tableau de bord.
+
+## Appairer votre téléphone
+
+L'appairage repose sur un **QR code** pour ne rien avoir à saisir de fastidieux :
+
+1. Assurez-vous que votre app Specrails de bureau est en cours d'exécution et que votre téléphone est sur le **même réseau local** (même Wi-Fi).
+2. Dans l'app de bureau, ouvrez l'écran d'appairage pour afficher un QR code.
+3. Dans l'app compagnon de votre téléphone, scannez ce code.
+4. Le téléphone découvre l'app de bureau sur le réseau et s'y connecte.
+
+À partir de là, le compagnon maintient une connexion en direct et diffuse les listes de projets et les mises à jour des jobs au fur et à mesure.
+
+## Comment fonctionne la connexion
+
+L'app de bureau s'annonce sur votre réseau local pour que le téléphone puisse la trouver, et le QR code transporte les informations dont le téléphone a besoin pour se connecter de façon sécurisée. Tout reste sur votre réseau local — le compagnon dialogue directement avec votre machine, sans passer par un quelconque service cloud.
+
+Comme tout repose sur le réseau local, les deux appareils doivent pouvoir se joindre. Si l'appairage ne se fait pas :
+
+- Vérifiez que les deux appareils sont sur le **même Wi-Fi** (et que le réseau n'isole pas les clients les uns des autres).
+- Assurez-vous que l'app de bureau est **en cours d'exécution** au moment où vous scannez.
+- Rouvrez l'écran d'appairage pour rafraîchir le QR code et réessayez de le scanner.
+
+## Ce que vous verrez
+
+Une fois appairé, le compagnon fait remonter vos projets et l'activité en direct de leurs jobs : vous obtenez ainsi les mêmes mises à jour de rails en temps réel que celles qui alimentent le tableau de bord de bureau — poussées vers votre téléphone dès qu'elles surviennent. C'est le moyen le plus simple de savoir au moment précis où un rail de longue durée se termine.
+
+## À garder à l'esprit
+
+- **La supervision d'abord.** Le compagnon est conçu pour surveiller les rails, pas pour piloter l'intégralité du workflow de bureau depuis votre téléphone.
+- **Local uniquement.** Pas de compte, pas de relais cloud — votre machine et votre téléphone, sur votre réseau.
+- **Gardez le bureau éveillé.** Le compagnon reflète une app de bureau en cours d'exécution ; si votre machine se met en veille ou que l'app se ferme, les mises à jour en direct se mettent en pause jusqu'à son retour.

package/docs/guide/fr/pipeline/1-rails-and-jobs.md

@@ -0,0 +1,94 @@
+# Rails et jobs
+
+Vos specs sont sur le tableau. C'est ici qu'elles deviennent du code. Un **rail** est la voie qui fait passer une spec à travers tout le pipeline — Architect → Developer → Reviewer → Ship — en exécutant de vrais agents IA directement dans le répertoire de votre projet. Cette page couvre le lancement d'un rail, la file d'attente des jobs, et la possibilité de regarder le travail se dérouler en direct.
+
+## Ce qu'est un rail
+
+Imaginez votre écran coupé en deux :
+
+```
+SpecsBoard (gauche)         Rails (droite)
+─────────────────            ─────────────────
+#1 Login flow      ─┐
+#2 Webhook retry    │  glisser sur
+#3 Cost limits      │ ────────────►   Rail 1   ▶ Play
+#4 Audit log        │
+                    └────────────►   Rail 2   ▶ Play
+```
+
+Un rail est une **voie d'exécution**. Vous glissez une carte de spec depuis le SpecsBoard sur un rail, puis vous appuyez sur **▶ Play**. Le rail lance le pipeline et traite la spec de bout en bout, directement dans le répertoire de travail de votre projet — en modifiant des fichiers, en lançant des tests, et tout le reste.
+
+Vous pouvez avoir plusieurs rails pour organiser votre travail en voies nommées (une pour la fonctionnalité sur laquelle vous êtes concentré, une autre en attente derrière). Plus de détails sur le multi-rail et le traitement par lots dans [Batch implement et multi-fonctionnalité](batch-implement-and-multi-feature).
+
+## Lancer un rail sur une spec
+
+1. **Glissez une carte de spec** depuis le SpecsBoard sur un rail. L'ID de la spec apparaît dans la liste des specs du rail. (Vous préférez ne pas glisser ? Utilisez la fenêtre **Déplacer vers un rail** sur la carte de spec — elle affiche un point de statut par rail pour que vous ne déposiez pas votre travail sur une voie occupée.)
+2. **Choisissez un mode** si vous voulez autre chose que celui par défaut — le sélecteur segmenté dans l'en-tête du rail propose `Implement`, `Batch`, et (rails Claude uniquement) `Ultra`.
+3. **Appuyez sur ▶ Play.**
+
+C'est tout. Le rail démarre un processus de CLI IA dans votre projet et lance le pipeline.
+
+### Ce que contient un en-tête de rail
+
+| Contrôle | Ce qu'il fait |
+|---------|--------------|
+| **Pastille de statut** | `idle`, `running` ou `failed`. Il n'y a pas d'état « completed » distinct — un rail revient à `idle` lorsque son job se termine proprement. |
+| **Liste de specs** | Les ID assignés à ce rail. Glissez-en d'autres dedans, glissez-les dehors pour les détacher. |
+| **Contrôle de mode** | `Implement` / `Batch` / `Ultra` — voir le tableau ci-dessous. Mémorisé par rail. |
+| **Sélecteur de profil** | Quel profil d'agent s'exécute (rails Claude uniquement). N'apparaît qu'une fois que le projet possède au moins un profil. |
+| **Sélecteur de moteur** | Quel fournisseur installé exécute ce rail — Claude, Codex ou Gemini. Ne s'affiche que lorsque le projet possède plus d'un fournisseur. Voir [Choisir un moteur par rail](picking-an-engine-per-rail). |
+| **▶ Play / ■ Stop** | Démarrer ou annuler. |
+
+### Les trois modes de rail
+
+| Mode | Commande | Ce qu'il fait |
+|------|---------|--------------|
+| **Implement** | `/specrails:implement` | Un seul job couvrant toutes les specs du rail. Exécute le pipeline complet Architect → Developer → Reviewer → Ship. Le choix par défaut au quotidien. |
+| **Batch** | `/specrails:batch-implement` | Un seul job qui traite les specs du rail de manière séquentielle, en vagues tenant compte des dépendances. Idéal pour plusieurs specs liées. |
+| **Ultra** | Ultracode | Claude implémente chaque spec de façon autonome, en **contournant** le pipeline. Un job indépendant par spec. Claude uniquement. |
+
+Ultra fait bande à part : il saute la chaîne d'agents et confie à Claude la spec brute pour qu'il la traite avec ses outils natifs. C'est ouvert et sans contraintes, donc appuyer sur Play ouvre d'abord une confirmation, et un sélecteur de modèle par rail vous laisse choisir Haiku / Sonnet / Opus. Il n'apparaît que lorsque le moteur du rail est Claude.
+
+## La file d'attente des jobs
+
+Chaque fois que vous appuyez sur Play, l'exécution du rail devient un **job**. La règle la plus importante à intégrer :
+
+> **Un job à la fois, par projet.** Chaque projet a une seule file d'attente. Au sein d'un même projet, un seul job de rail s'exécute à la fois — les autres attendent derrière et démarrent automatiquement à mesure que des créneaux se libèrent.
+
+Cela surprend les gens qui ajoutent trois rails en s'attendant à ce qu'ils s'exécutent en parallèle. Ce ne sera pas le cas — pas au sein du même projet. Ajouter des rails *organise* votre travail en voies ; cela ne rend pas ces voies concurrentes.
+
+**Le vrai parallélisme se fait entre projets.** Chaque projet possède sa propre file d'attente indépendante, donc un rail dans le Projet A et un rail dans le Projet B s'exécutent en même temps sans se gêner. Vous voulez plus de débit ? Ouvrez plus de projets.
+
+Il n'y a aucun réglage global de concurrence à ajuster. Le seul régulateur automatique est basé sur le budget : si vous avez défini un budget quotidien (par projet ou pour toute l'application), la file se met automatiquement en pause dès que la dépense du jour atteint le plafond.
+
+## Regarder l'exécution
+
+Retrouvez chaque job sous **Jobs** dans la barre latérale droite du projet — une liste de cartes, les plus récentes en premier. Chaque carte affiche un badge de statut, le badge de profil, un badge de priorité, la durée, le coût et la commande lancée. Au-dessus de la liste :
+
+- **Puces de filtre par statut** — n'affichent que les jobs dans un statut donné.
+- **Filtre par plage de dates** — restreint à une fenêtre temporelle.
+- **Comparer** — choisissez deux jobs et affichez-les côte à côte.
+
+Cliquez sur n'importe quelle carte pour ouvrir la **vue détaillée du job**, où vivent le log en streaming et les métriques en direct. C'est la page suivante : [La vue détaillée du job](the-job-detail-view).
+
+## Annuler un job
+
+Cliquez sur **■ Stop** dans l'en-tête du rail. L'application envoie `SIGTERM` au sous-processus, attend **5 secondes** une sortie propre, puis le `SIGKILL`. Rien n'est laissé à moitié démarré.
+
+## Si un rail refuse de se lancer
+
+Si vous choisissez un moteur dont la CLI n'est pas installée sur votre machine, le lancement **échoue immédiatement** au lieu de démarrer un job cassé — rien ne démarre. Installez la CLI du fournisseur manquant ([Utiliser Codex](../integrations/using-codex), [Utiliser Gemini](../integrations/using-gemini)) et relancez. Une CLI Claude ou Codex manquante donne un message précis « *<provider> CLI not found* » ; une CLI Gemini manquante affiche aujourd'hui une erreur de lancement générique, mais le résultat est le même.
+
+## Tout arrêter
+
+Si quelque chose semble anormal :
+
+- **Un seul rail** — cliquez sur **■ Stop** dans son en-tête.
+- **Pause auto sur budget** — définissez un budget quotidien et la file se met elle-même en pause lorsque la dépense du jour atteint le plafond.
+- **Tout** — quittez l'application desktop, ou exécutez `specrails-desktop stop`.
+
+## Où aller ensuite
+
+- [La vue détaillée du job](the-job-detail-view) — phases, métriques en direct, cartes de ticket.
+- [Batch implement et multi-fonctionnalité](batch-implement-and-multi-feature) — exécuter plusieurs specs à la fois.
+- [Choisir un moteur par rail](picking-an-engine-per-rail) — Claude vs Codex vs Gemini.

package/docs/guide/fr/pipeline/2-the-job-detail-view.md

@@ -0,0 +1,90 @@
+# La vue détaillée du job
+
+Cliquez sur n'importe quelle carte de job de la page **Jobs** et vous arrivez ici : le poste de pilotage d'une exécution de rail unique. Tout repose sur une promesse — **les chiffres en direct que vous voyez sont réels, jamais des estimations.** Cette page parcourt les phases, les métriques en direct et les cartes de ticket.
+
+## La disposition
+
+Deux panneaux se trouvent au-dessus du log en streaming complet :
+
+```
+┌─────────────────────────────────────────────┐
+│  En-tête de statut (icône · durée en direct · …)  │
+├─────────────────────────────────────────────┤
+│  En-tête de ticket ( #12  #14  #15 )        │
+├─────────────────────────────────────────────┤
+│                                             │
+│  Log en streaming (auto-défilement · recherche · …)  │
+│                                             │
+└─────────────────────────────────────────────┘
+```
+
+## Les phases du pipeline
+
+Pour les jobs `Implement` et `Batch`, l'exécution traverse les phases définies par la slash command — par défaut :
+
+```
+Architect ──► Developer ──► Reviewer ──► Ship
+```
+
+Chaque phase est un agent spécialisé que le moteur du rail invoque dans le répertoire de votre projet :
+
+| Phase | Agent | Ce qu'il fait |
+|-------|-------|--------------|
+| **Architect** | `sr-architect` | Planifie l'implémentation. |
+| **Developer** | `sr-developer` | Écrit le code. |
+| **Reviewer** | `sr-reviewer` | Relit le résultat. |
+| **Ship** | (variable) | Finalisation : tests, commit, brouillon de PR. |
+
+Quel agent gère chaque phase est décidé par le **profil d'agent** du projet. Le trio de base (`sr-architect`, `sr-developer`, `sr-reviewer`) est toujours présent ; les règles de routage d'un profil peuvent ajouter des agents ou changer celui qui exécute une phase. La barre de progression des phases n'apparaît que lorsque la commande définit réellement des phases — les jobs Ultracode (qui contournent le pipeline) n'en affichent pas.
+
+## Métriques en direct — honnêtes par conception
+
+L'en-tête de statut est la vedette. Il affiche une icône de statut, une ligne d'activité décrivant ce que le job fait *en ce moment même*, un compteur des étapes effectuées, et une ligne de métriques :
+
+| Métrique | Quand vous voyez la vraie valeur |
+|--------|------------------------------|
+| **Durée** | **En direct.** Un compteur d'une seconde s'incrémente pendant l'exécution du job — c'est le seul chiffre véritablement en direct. |
+| **Tours** | Dérivés de façon incrémentale des événements d'assistant streamés à mesure qu'ils arrivent. |
+| **Tokens** | Agrégés de façon incrémentale depuis ce même flux (tolérant aux événements dépourvus de champs d'usage). |
+| **Coût** | Affiché comme `—` jusqu'à la sortie du job, puis révélé comme le `total_cost_usd` faisant autorité. |
+
+Le principe de conception : **aucun chiffre approximatif ou estimé en cours d'exécution.** La durée est réelle car ce n'est qu'une horloge. Les tours et les tokens sont accumulés à partir d'une activité réellement streamée. Le coût n'est délibérément *pas* estimé pendant l'exécution — il s'affiche comme en attente et ne se résout en son chiffre final et faisant autorité que lorsque le fournisseur le rapporte à la sortie du job. Si un chiffre semble en attente, c'est intentionnel — on vous montre la vérité, pas une projection.
+
+Le libellé et l'icône de l'en-tête correspondent au statut du job, et le panneau s'affiche aussi bien pour les jobs `running`, `completed` que `failed` — ainsi la vue détaillée d'un job terminé montre les mêmes métriques figées sur leurs valeurs finales.
+
+## Les cartes de ticket
+
+L'**en-tête de ticket** se trouve entre l'en-tête de statut et le log. C'est une carte d'identité premium qui affiche une puce pour chaque spec touchée par le job — issues de la commande lancée, donc elle reflète exactement quels tickets concernait cette exécution.
+
+- **2 à 3 tickets** — affichés sous forme de liste de puces.
+- **4 ou plus** — repliés en un mode compact `+ N de plus` avec un chevron de dépliage, pour que l'en-tête reste net.
+
+Cliquer sur une puce ouvre le détail de cette spec **par-dessus la page du job** — vous ne perdez pas votre place et ne changez pas de route. C'est un moyen rapide de relire ce qu'un job est censé livrer pendant que vous le regardez travailler. (Sur les écrans de largeur tablette, vous pouvez même glisser une fenêtre de ticket sur le côté pour comparer deux specs côte à côte.)
+
+## Le log en streaming
+
+Sous les panneaux se trouve le log complet de l'exécution, streamé en temps réel via le WebSocket :
+
+- **L'auto-défilement** garde la sortie la plus récente en vue (faites défiler vers le haut et il se met en pause pour vous laisser lire).
+- **Recherche** pour sauter à une expression.
+- **Copier** pour récupérer tout le log.
+
+C'est la vérité brute de ce que fait l'IA — chaque appel d'outil, chaque modification de fichier, chaque exécution de test.
+
+## Export de diagnostic
+
+Si la [télémétrie](../settings/customizing) était activée pour le job, un bouton **Exporter le diagnostic** apparaît dans l'en-tête. Il télécharge un ZIP contenant :
+
+- `job-metadata.json` — commande, statut, profil, plugins.
+- `telemetry.ndjson` — signaux OTLP/JSON non compressés.
+- `logs.txt` — le log en streaming complet.
+- `summary.md` — points saillants en clair.
+- `profile.json`, `plugins.json` — instantanés exacts de ce qui s'est exécuté (lorsque présents).
+
+Pratique pour partager une exécution avec un coéquipier, ou pour déposer un rapport de bug précis.
+
+## Où aller ensuite
+
+- [Rails et jobs](rails-and-jobs) — lancement et mise en file.
+- [Batch implement et multi-fonctionnalité](batch-implement-and-multi-feature) — plusieurs specs, vagues de dépendances.
+- [Suivre le coût](../analytics/tracking-cost) — transformer les coûts par job en analytics de projet.