cc-viewer 1.6.182 → 1.6.183

package/concepts/fr/Tool-Bash.md

@@ -1,167 +1,39 @@
 # Bash
 
-## Définition
+Exécute une commande shell dans un répertoire de travail persistant et renvoie sa sortie standard / erreur. À réserver aux opérations qu'aucun outil Claude Code dédié ne peut exprimer, comme l'exécution de git, npm, docker ou de scripts de build.
 
-Exécute des commandes shell avec une configuration de délai d'attente optionnelle. Le répertoire de travail persiste entre les commandes, mais l'état du shell (variables d'environnement, etc.) ne persiste pas.
+## Quand l'utiliser
 
-## Paramètres
-
-| Paramètre | Type | Requis | Description |
-|-----------|------|--------|-------------|
-| `command` | string | Oui | Commande bash à exécuter |
-| `description` | string | Non | Description brève de la commande |
-| `timeout` | number | Non | Délai d'attente (millisecondes), maximum 600000, par défaut 120000 |
-| `run_in_background` | boolean | Non | Si la commande s'exécute en arrière-plan |
-
-## Cas d'utilisation
-
-**Adapté pour :**
-- Opérations git (commit, push, branch, etc.)
-- Commandes de gestion de paquets npm/yarn
-- Opérations docker
-- Commandes de compilation et de build
-- Lister le contenu des répertoires (`ls`)
-- Autres commandes système nécessitant une exécution shell
-
-**Non adapté pour :**
-- Lire des fichiers — utiliser Read
-- Rechercher des noms de fichiers — utiliser Glob
-- Rechercher du contenu de fichiers — utiliser Grep
-- Éditer des fichiers — utiliser Edit
-- Écrire des fichiers — utiliser Write
-- Afficher des informations à l'utilisateur — afficher directement dans le texte de réponse
-- Processus de longue durée (dev server, mode watch) — recommander à l'utilisateur d'exécuter manuellement
-
-## Notes
-
-- Les chemins contenant des espaces doivent être entre guillemets doubles
-- La sortie dépassant 30000 caractères sera tronquée
-- Les commandes en arrière-plan obtiennent leurs résultats via TaskOutput
-- Utiliser de préférence des chemins absolus, éviter `cd`
-- Les commandes indépendantes peuvent exécuter plusieurs Bash en parallèle
-- Les commandes avec des dépendances sont chaînées avec `&&`
-- L'environnement shell est initialisé à partir du profile de l'utilisateur (bash ou zsh)
-
-## Texte original
-
-<textarea readonly>Executes a given bash command and returns its output.
-
-The working directory persists between commands, but shell state does not. The shell environment is initialized from the user's profile (bash or zsh).
+- Exécuter des opérations git (`git status`, `git diff`, `git commit`, `gh pr create`)
+- Lancer des gestionnaires de paquets et outils de build (`npm install`, `npm run build`, `pytest`, `cargo build`)
+- Démarrer des processus de longue durée (serveurs de dev, watchers) en arrière-plan avec `run_in_background`
+- Invoquer des CLI spécifiques à un domaine (`docker`, `terraform`, `kubectl`, `gh`) sans équivalent intégré
+- Enchaîner des étapes dépendantes avec `&&` lorsque l'ordre compte
 
-IMPORTANT: Avoid using this tool to run `find`, `grep`, `cat`, `head`, `tail`, `sed`, `awk`, or `echo` commands, unless explicitly instructed or after you have verified that a dedicated tool cannot accomplish your task. Instead, use the appropriate dedicated tool as this will provide a much better experience for the user:
-
- - File search: Use Glob (NOT find or ls)
- - Content search: Use Grep (NOT grep or rg)
- - Read files: Use Read (NOT cat/head/tail)
- - Edit files: Use Edit (NOT sed/awk)
- - Write files: Use Write (NOT echo >/cat <<EOF)
- - Communication: Output text directly (NOT echo/printf)
-While the Bash tool can do similar things, it’s better to use the built-in tools as they provide a better user experience and make it easier to review tool calls and give permission.
-
-# Instructions
- - If your command will create new directories or files, first use this tool to run `ls` to verify the parent directory exists and is the correct location.
- - Always quote file paths that contain spaces with double quotes in your command (e.g., cd "path with spaces/file.txt")
- - Try to maintain your current working directory throughout the session by using absolute paths and avoiding usage of `cd`. You may use `cd` if the User explicitly requests it.
- - You may specify an optional timeout in milliseconds (up to 600000ms / 10 minutes). By default, your command will timeout after 120000ms (2 minutes).
- - You can use the `run_in_background` parameter to run the command in the background. Only use this if you don't need the result immediately and are OK being notified when the command completes later. You do not need to check the output right away - you'll be notified when it finishes. You do not need to use '&' at the end of the command when using this parameter.
- - Write a clear, concise description of what your command does. For simple commands, keep it brief (5-10 words). For complex commands (piped commands, obscure flags, or anything hard to understand at a glance), include enough context so that the user can understand what your command will do.
- - When issuing multiple commands:
-  - If the commands are independent and can run in parallel, make multiple Bash tool calls in a single message. Example: if you need to run "git status" and "git diff", send a single message with two Bash tool calls in parallel.
-  - If the commands depend on each other and must run sequentially, use a single Bash call with '&&' to chain them together.
-  - Use ';' only when you need to run commands sequentially but don't care if earlier commands fail.
-  - DO NOT use newlines to separate commands (newlines are ok in quoted strings).
- - For git commands:
-  - Prefer to create a new commit rather than amending an existing commit.
-  - Before running destructive operations (e.g., git reset --hard, git push --force, git checkout --), consider whether there is a safer alternative that achieves the same goal. Only use destructive operations when they are truly the best approach.
-  - Never skip hooks (--no-verify) or bypass signing (--no-gpg-sign, -c commit.gpgsign=false) unless the user has explicitly asked for it. If a hook fails, investigate and fix the underlying issue.
- - Avoid unnecessary `sleep` commands:
-  - Do not sleep between commands that can run immediately — just run them.
-  - If your command is long running and you would like to be notified when it finishes – simply run your command using `run_in_background`. There is no need to sleep in this case.
-  - Do not retry failing commands in a sleep loop — diagnose the root cause or consider an alternative approach.
-  - If waiting for a background task you started with `run_in_background`, you will be notified when it completes — do not poll.
-  - If you must poll an external process, use a check command (e.g. `gh run view`) rather than sleeping first.
-  - If you must sleep, keep the duration short (1-5 seconds) to avoid blocking the user.
-
-# Committing changes with git
-
-Only create commits when requested by the user. If unclear, ask first. When the user asks you to create a new git commit, follow these steps carefully:
-
-Git Safety Protocol:
-- NEVER update the git config
-- NEVER run destructive git commands (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) unless the user explicitly requests these actions. Taking unauthorized destructive actions is unhelpful and can result in lost work, so it's best to ONLY run these commands when given direct instructions 
-- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it
-- NEVER run force push to main/master, warn the user if they request it
-- CRITICAL: Always create NEW commits rather than amending, unless the user explicitly requests a git amend. When a pre-commit hook fails, the commit did NOT happen — so --amend would modify the PREVIOUS commit, which may result in destroying work or losing previous changes. Instead, after hook failure, fix the issue, re-stage, and create a NEW commit
-- When staging files, prefer adding specific files by name rather than using "git add -A" or "git add .", which can accidentally include sensitive files (.env, credentials) or large binaries
-- NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive
-
-1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel, each using the Bash tool:
-  - Run a git status command to see all untracked files. IMPORTANT: Never use the -uall flag as it can cause memory issues on large repos.
-  - Run a git diff command to see both staged and unstaged changes that will be committed.
-  - Run a git log command to see recent commit messages, so that you can follow this repository's commit message style.
-2. Analyze all staged changes (both previously staged and newly added) and draft a commit message:
-  - Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.). Ensure the message accurately reflects the changes and their purpose (i.e. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.).
-  - Do not commit files that likely contain secrets (.env, credentials.json, etc). Warn the user if they specifically request to commit those files
-  - Draft a concise (1-2 sentences) commit message that focuses on the "why" rather than the "what"
-  - Ensure it accurately reflects the changes and their purpose
-3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands:
-   - Add relevant untracked files to the staging area.
-   - Create the commit with a message ending with:
-   Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
-   - Run git status after the commit completes to verify success.
-   Note: git status depends on the commit completing, so run it sequentially after the commit.
-4. If the commit fails due to pre-commit hook: fix the issue and create a NEW commit
-
-Important notes:
-- NEVER run additional commands to read or explore code, besides git bash commands
-- NEVER use the TodoWrite or Agent tools
-- DO NOT push to the remote repository unless the user explicitly asks you to do so
-- IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.
-- IMPORTANT: Do not use --no-edit with git rebase commands, as the --no-edit flag is not a valid option for git rebase.
-- If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit
-- In order to ensure good formatting, ALWAYS pass the commit message via a HEREDOC, a la this example:
-<example>
-git commit -m "$(cat <<'EOF'
-   Commit message here.
-
-   Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
-   EOF
-   )"
-</example>
+## Paramètres
 
-# Creating pull requests
-Use the gh command via the Bash tool for ALL GitHub-related tasks including working with issues, pull requests, checks, and releases. If given a Github URL use the gh command to get the information needed.
+- `command` (string, requis) : la commande shell exacte à exécuter.
+- `description` (string, requis) : un bref résumé à la voix active (5 à 10 mots pour les commandes simples ; plus de contexte pour les commandes avec pipes ou obscures).
+- `timeout` (number, optionnel) : délai d'expiration en millisecondes, jusqu'à `600000` (10 minutes). Par défaut `120000` (2 minutes).
+- `run_in_background` (boolean, optionnel) : lorsque `true`, la commande s'exécute détachée et vous recevez une notification à l'achèvement. N'ajoutez pas vous-même `&`.
 
-IMPORTANT: When the user asks you to create a pull request, follow these steps carefully:
+## Exemples
 
-1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel using the Bash tool, in order to understand the current state of the branch since it diverged from the main branch:
-   - Run a git status command to see all untracked files (never use -uall flag)
-   - Run a git diff command to see both staged and unstaged changes that will be committed
-   - Check if the current branch tracks a remote branch and is up to date with the remote, so you know if you need to push to the remote
-   - Run a git log command and `git diff [base-branch]...HEAD` to understand the full commit history for the current branch (from the time it diverged from the base branch)
-2. Analyze all changes that will be included in the pull request, making sure to look at all relevant commits (NOT just the latest commit, but ALL commits that will be included in the pull request!!!), and draft a pull request title and summary:
-   - Keep the PR title short (under 70 characters)
-   - Use the description/body for details, not the title
-3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands in parallel:
-   - Create new branch if needed
-   - Push to remote with -u flag if needed
-   - Create PR using gh pr create with the format below. Use a HEREDOC to pass the body to ensure correct formatting.
-<example>
-gh pr create --title "the pr title" --body "$(cat <<'EOF'
-## Summary
-<1-3 bullet points>
+### Exemple 1 : inspecter l'état du dépôt avant de committer
+Émettez `git status` et `git diff --stat` sous forme de deux appels `Bash` parallèles dans le même message pour rassembler rapidement le contexte, puis composez le commit dans un appel suivant.
 
-## Test plan
-[Bulleted markdown checklist of TODOs for testing the pull request...]
+### Exemple 2 : enchaîner des étapes de build dépendantes
+Utilisez un unique appel tel que `npm ci && npm run build && npm test` afin que chaque étape ne s'exécute qu'après la réussite de la précédente. N'utilisez `;` que si vous souhaitez intentionnellement que les étapes suivantes s'exécutent même après un échec.
 
-🤖 Generated with [Claude Code](https://claude.com/claude-code)
-EOF
-)"
-</example>
+### Exemple 3 : serveur de dev de longue durée
+Invoquez `npm run dev` avec `run_in_background: true`. Vous serez notifié à sa sortie. N'effectuez pas de polling avec des boucles `sleep` ; diagnostiquez les échecs au lieu de réessayer aveuglément.
 
-Important:
-- DO NOT use the TodoWrite or Agent tools
-- Return the PR URL when you're done, so the user can see it
+## Notes
 
-# Other common operations
-- View comments on a Github PR: gh api repos/foo/bar/pulls/123/comments</textarea>
+- Le répertoire de travail persiste entre les appels, mais l'état du shell (variables exportées, fonctions shell, alias) ne persiste pas. Préférez les chemins absolus et évitez `cd` sauf demande explicite de l'utilisateur.
+- Préférez les outils dédiés aux équivalents shell avec pipes : `Glob` au lieu de `find`/`ls`, `Grep` au lieu de `grep`/`rg`, `Read` au lieu de `cat`/`head`/`tail`, `Edit` au lieu de `sed`/`awk`, `Write` au lieu de `echo >` ou des heredocs, et du texte d'assistant ordinaire au lieu de `echo`/`printf` pour les sorties destinées à l'utilisateur.
+- Mettez entre guillemets doubles tout chemin contenant des espaces (par exemple `"/Users/me/My Project/file.txt"`).
+- Pour des commandes indépendantes, effectuez plusieurs appels de l'outil `Bash` en parallèle dans un même message. Ne les chaînez avec `&&` que lorsqu'une commande dépend d'une autre.
+- Toute sortie dépassant 30000 caractères est tronquée. Lorsque vous capturez de gros journaux, redirigez vers un fichier puis lisez-le avec l'outil `Read`.
+- N'utilisez jamais d'options interactives telles que `git rebase -i` ou `git add -i` ; elles ne peuvent pas recevoir d'entrée via cet outil.
+- Ne contournez pas les hooks git (`--no-verify`, `--no-gpg-sign`) et n'effectuez pas d'opérations destructrices (`reset --hard`, `push --force`, `clean -f`) sauf demande explicite de l'utilisateur.

package/concepts/fr/Tool-CronCreate.md

@@ -0,0 +1,57 @@
+# CronCreate
+
+Planifie un prompt pour qu'il soit mis en file d'attente à un moment futur, qu'il s'agisse d'une exécution unique ou récurrente. Utilise la syntaxe cron standard à 5 champs dans le fuseau horaire local de l'utilisateur, sans conversion de fuseau horaire.
+
+## Quand l'utiliser
+
+- **Rappels ponctuels** : Lorsqu'un utilisateur souhaite être rappelé à un moment précis ("rappelle-moi demain à 15h"). Avec `recurring: false`, la tâche se supprime automatiquement après exécution.
+- **Planifications récurrentes** : Lorsqu'une action doit se répéter régulièrement ("chaque jour ouvrable à 9h", "toutes les 30 minutes"). La valeur par défaut `recurring: true` couvre ce cas.
+- **Boucles d'agent autonome** : Pour construire des flux de travail qui se re-déclenchent selon un calendrier — par exemple un résumé quotidien ou une vérification d'état périodique.
+- **Tâches persistantes** : Lorsque la planification doit survivre à un redémarrage de session. En passant `durable: true`, la tâche est écrite dans `.claude/scheduled_tasks.json`.
+- **Demandes à heure approximative** : Lorsque l'utilisateur dit "vers 9h" ou "toutes les heures", choisissez une minute décalée (p. ex. `57 8 * * *` ou `7 * * * *`) pour éviter que tous les utilisateurs se regroupent à :00 ou :30.
+
+## Paramètres
+
+- `cron` (string, obligatoire) : Expression cron à 5 champs dans le fuseau horaire local de l'utilisateur. Format : `minute heure jour-du-mois mois jour-de-la-semaine`. Exemple : `"0 9 * * 1-5"` signifie du lundi au vendredi à 9h00.
+- `prompt` (string, obligatoire) : Le texte du prompt à mettre en file d'attente lors du déclenchement du cron — le message exact qui sera soumis au REPL au moment planifié.
+- `recurring` (boolean, optionnel, défaut `true`) : Avec `true`, le job s'exécute à chaque intervalle cron correspondant et expire automatiquement après 7 jours. Avec `false`, le job s'exécute exactement une fois puis est supprimé — pour les rappels ponctuels.
+- `durable` (boolean, optionnel, défaut `false`) : Avec `false`, la planification n'existe qu'en mémoire et disparaît à la fin de la session. Avec `true`, la tâche est persistée dans `.claude/scheduled_tasks.json` et survit aux redémarrages.
+
+## Exemples
+
+### Exemple 1 : rappel ponctuel
+
+L'utilisateur dit : "Rappelle-moi demain à 14h30 d'envoyer le rapport hebdomadaire." En supposant que demain est le 21 avril :
+
+```json
+{
+  "cron": "30 14 21 4 *",
+  "prompt": "Rappel : envoie le rapport hebdomadaire maintenant.",
+  "recurring": false,
+  "durable": true
+}
+```
+
+`recurring: false` garantit que la tâche se supprime après déclenchement. `durable: true` la maintient à travers tout redémarrage préalable.
+
+### Exemple 2 : tâche matinale récurrente en semaine
+
+L'utilisateur dit : "Chaque matin de la semaine, résume mes issues GitHub ouvertes."
+
+```json
+{
+  "cron": "3 9 * * 1-5",
+  "prompt": "Résume toutes les issues GitHub ouvertes qui me sont assignées.",
+  "recurring": true,
+  "durable": true
+}
+```
+
+La minute `3` au lieu de `0` évite le pic de charge à l'heure pile. Le job expire automatiquement après 7 jours.
+
+## Notes
+
+- **Expiration automatique à 7 jours** : Les jobs récurrents sont automatiquement supprimés après 7 jours au maximum. Pour une planification plus longue, recréez la tâche avant son expiration.
+- **Déclenchement uniquement en mode inactif** : `CronCreate` met le prompt en file d'attente uniquement lorsque le REPL ne traite pas une autre requête. Si le REPL est occupé au moment du déclenchement, le prompt attend la fin de la requête en cours.
+- **Éviter les minutes :00 et :30** : Pour les demandes à heure approximative, choisissez délibérément des valeurs de minute décalées pour répartir la charge système. Réservez :00/:30 uniquement lorsque l'utilisateur spécifie cette minute exacte.
+- **Aucune conversion de fuseau horaire** : L'expression cron est interprétée directement dans le fuseau horaire local de l'utilisateur. Aucune conversion en UTC ou autre zone n'est nécessaire.

package/concepts/fr/Tool-CronDelete.md

@@ -0,0 +1,43 @@
+# CronDelete
+
+Annule un job cron précédemment planifié avec `CronCreate`. Le supprime immédiatement du stockage de session en mémoire. N'a aucun effet si le job a déjà été supprimé automatiquement (les jobs à exécution unique sont supprimés après déclenchement, les jobs récurrents expirent après 7 jours).
+
+## Quand l'utiliser
+
+- Un utilisateur demande d'arrêter une tâche planifiée récurrente avant son expiration automatique de 7 jours.
+- Un job à exécution unique n'est plus nécessaire et doit être annulé avant de se déclencher.
+- L'expression de planification d'un job existant doit être modifiée — le supprimer avec `CronDelete`, puis le recréer avec `CronCreate` en utilisant la nouvelle expression.
+- Nettoyer plusieurs jobs obsolètes pour garder le stockage de session en ordre.
+
+## Paramètres
+
+- `id` (string, requis) : L'identifiant de job retourné par `CronCreate` lors de la création initiale du job. Cette valeur doit correspondre exactement ; la recherche approximative ou par nom n'est pas prise en charge.
+
+## Exemples
+
+### Exemple 1 : annuler un job récurrent en cours d'exécution
+
+Un job récurrent a été créé précédemment avec l'identifiant `"cron_abc123"`. L'utilisateur demande de l'arrêter.
+
+```
+CronDelete({ id: "cron_abc123" })
+```
+
+Le job est supprimé du stockage de session et ne se déclenchera plus.
+
+### Exemple 2 : supprimer un job à exécution unique obsolète avant son déclenchement
+
+Un job à exécution unique avec l'identifiant `"cron_xyz789"` a été planifié pour s'exécuter dans 30 minutes, mais l'utilisateur a décidé qu'il n'est plus nécessaire.
+
+```
+CronDelete({ id: "cron_xyz789" })
+```
+
+Le job est annulé. Aucune action ne sera effectuée lorsque l'heure de déclenchement originale sera atteinte.
+
+## Notes
+
+- L'`id` doit être obtenu à partir de la valeur de retour de `CronCreate`. Il n'existe aucun moyen de rechercher un job par description ou par callback — conservez l'identifiant si vous pourriez avoir besoin de l'annuler ultérieurement.
+- Si le job a déjà été supprimé automatiquement (déclenché en tant que job à exécution unique, ou ayant atteint l'expiration récurrente de 7 jours), appeler `CronDelete` avec cet identifiant est une opération sans effet et ne produira pas d'erreur.
+- `CronDelete` n'affecte que la session en mémoire actuelle. Si l'environnement d'exécution ne persiste pas l'état cron entre les redémarrages, les jobs planifiés seront perdus au redémarrage, que `CronDelete` ait été appelé ou non.
+- Il n'existe pas d'opération de suppression en masse ; annulez chaque job individuellement en utilisant son propre `id`.

package/concepts/fr/Tool-CronList.md

@@ -0,0 +1,30 @@
+# CronList
+
+Liste toutes les taches cron planifiees via `CronCreate` au cours de la session en cours. Retourne un resume de chaque cron actif comprenant son `id`, l'expression cron, le `prompt` abrege, l'indicateur `recurring`, l'indicateur `durable` et la prochaine heure d'execution.
+
+## Quand l'utiliser
+
+- Pour auditer l'ensemble des taches actuellement planifiees avant d'effectuer des modifications ou de terminer une session.
+- Pour trouver le bon `id` d'une tache avant d'appeler `CronDelete` afin de la supprimer.
+- Pour deboguer pourquoi une tache attendue ne s'est jamais declenchee, en confirmant son existence et en verifiant sa prochaine heure d'execution.
+- Pour confirmer qu'une tache a execution unique (non recurrente) n'a pas encore ete declenchee et reste en attente.
+
+## Parametres
+
+Aucun.
+
+## Exemples
+
+### Exemple 1 : auditer toutes les taches planifiees
+
+Appeler `CronList` sans argument pour recuperer la liste complete de toutes les taches cron actives. La reponse comprend pour chaque tache son `id`, l'expression cron definissant son calendrier, une version tronquee du `prompt` qu'elle executera, si elle est `recurring` (recurrente), si elle est `durable` (persistante apres redemarrage) et la prochaine heure d'execution prevue.
+
+### Exemple 2 : localiser l'id d'une tache recurrente specifique
+
+Si plusieurs taches cron ont ete creees et qu'il faut en supprimer une en particulier, appeler d'abord `CronList`. Parcourir la liste retournee pour trouver la tache dont le resume du `prompt` et l'expression cron correspondent a la tache ciblee. Copier son `id` et le passer a `CronDelete`.
+
+## Notes
+
+- Seules les taches creees lors de la session en cours sont listees, sauf si elles ont ete creees avec `durable: true`, ce qui leur permet de persister apres un redemarrage de session.
+- Le champ `prompt` dans le resume est tronque ; il n'affiche que le debut du texte complet du prompt, pas son integralite.
+- Les taches a execution unique (dont `recurring` est `false`) qui se sont deja declenchees sont automatiquement supprimees et n'apparaissent plus dans la liste.

package/concepts/fr/Tool-Edit.md

@@ -1,46 +1,38 @@
 # Edit
 
-## Définition
+Effectue un remplacement exact de chaîne dans un fichier existant. C'est la méthode privilégiée pour modifier des fichiers car seul le diff est transmis, ce qui rend les modifications précises et auditables.
 
-Édite des fichiers par remplacement exact de chaînes. Remplace `old_string` par `new_string` dans le fichier.
+## Quand l'utiliser
 
-## Paramètres
+- Corriger un bug dans une fonction sans réécrire le fichier qui l'entoure
+- Mettre à jour une valeur de configuration, une chaîne de version ou un chemin d'import
+- Renommer un symbole dans un fichier avec `replace_all`
+- Insérer un bloc près d'une ancre (étendez `old_string` pour inclure du contexte voisin, puis fournissez le remplacement)
+- Appliquer de petites modifications bien cadrées dans le cadre d'un refactoring en plusieurs étapes
 
-| Paramètre | Type | Requis | Description |
-|-----------|------|--------|-------------|
-| `file_path` | string | Oui | Chemin absolu du fichier à modifier |
-| `old_string` | string | Oui | Texte original à remplacer |
-| `new_string` | string | Oui | Nouveau texte de remplacement (doit être différent de old_string) |
-| `replace_all` | boolean | Non | Si toutes les occurrences sont remplacées, par défaut `false` |
+## Paramètres
 
-## Cas d'utilisation
+- `file_path` (string, requis) : chemin absolu du fichier à modifier.
+- `old_string` (string, requis) : texte exact à rechercher. Doit correspondre caractère pour caractère, y compris espaces et indentation.
+- `new_string` (string, requis) : texte de remplacement. Doit différer de `old_string`.
+- `replace_all` (boolean, optionnel) : lorsque `true`, remplace chaque occurrence de `old_string`. Par défaut `false`, ce qui exige que la correspondance soit unique.
 
-**Adapté pour :**
-- Modifier des segments de code spécifiques dans des fichiers existants
-- Corriger des bugs, mettre à jour la logique
-- Renommer des variables (avec `replace_all: true`)
-- Tout scénario nécessitant une modification précise du contenu d'un fichier
+## Exemples
 
-**Non adapté pour :**
-- Créer de nouveaux fichiers — utiliser Write
-- Réécritures à grande échelle — peut nécessiter Write pour écraser le fichier entier
+### Exemple 1 : corriger un unique site d'appel
+Réglez `old_string` sur la ligne exacte `const port = 3000;` et `new_string` sur `const port = process.env.PORT ?? 3000;`. La correspondance étant unique, `replace_all` peut rester à sa valeur par défaut.
 
-## Notes
+### Exemple 2 : renommer un symbole dans un fichier
+Pour renommer `getUser` en `fetchUser` partout dans `api.ts`, réglez `old_string: "getUser"`, `new_string: "fetchUser"`, et `replace_all: true`.
 
-- Le fichier doit avoir été lu préalablement avec Read, sinon une erreur sera retournée
-- `old_string` doit être unique dans le fichier, sinon l'édition échoue. S'il n'est pas unique, fournir plus de contexte pour le rendre unique, ou utiliser `replace_all`
-- Lors de l'édition du texte, l'indentation originale (tab/espaces) doit être conservée, ne pas inclure le préfixe de numéro de ligne de la sortie de Read
-- Préférer l'édition de fichiers existants plutôt que la création de nouveaux
-- `new_string` doit être différent de `old_string`
+### Exemple 3 : désambiguïser un extrait répété
+Si `return null;` apparaît dans plusieurs branches, élargissez `old_string` pour inclure le contexte environnant (par exemple la ligne `if` précédente) afin que la correspondance soit unique. Sinon l'outil renvoie une erreur plutôt que de deviner.
 
-## Texte original
-
-<textarea readonly>Performs exact string replacements in files.
+## Notes
 
-Usage:
-- You must use your `Read` tool at least once in the conversation before editing. This tool will error if you attempt an edit without reading the file. 
-- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: spaces + line number + tab. Everything after that tab is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.
-- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
-- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.
-- The edit will FAIL if `old_string` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use `replace_all` to change every instance of `old_string`.
-- Use `replace_all` for replacing and renaming strings across the file. This parameter is useful if you want to rename a variable for instance.</textarea>
+- Vous devez appeler `Read` sur le fichier au moins une fois dans la session en cours avant que `Edit` n'accepte des changements. Les préfixes de numéro de ligne de la sortie de `Read` ne font pas partie du contenu du fichier ; ne les incluez pas dans `old_string` ou `new_string`.
+- Les espaces doivent correspondre exactement. Prêtez attention aux tabulations versus espaces et aux espaces de fin, en particulier dans YAML, les Makefiles et Python.
+- Si `old_string` n'est pas unique et que `replace_all` est `false`, l'édition échoue. Élargissez le contexte ou activez `replace_all`.
+- Préférez `Edit` à `Write` chaque fois que le fichier existe déjà ; `Write` écrase tout le fichier et perd le contenu sans rapport si vous n'êtes pas prudent.
+- Pour plusieurs modifications sans rapport dans le même fichier, effectuez plusieurs appels `Edit` à la suite plutôt qu'un seul gros remplacement fragile.
+- Évitez d'introduire des emojis, du texte marketing ou des blocs de documentation non demandés lors de l'édition de fichiers source.

package/concepts/fr/Tool-EnterPlanMode.md

@@ -1,128 +1,35 @@
 # EnterPlanMode
 
-## Définition
+Fait basculer la session en mode plan, une phase d'exploration en lecture seule durant laquelle l'assistant étudie la base de code et rédige un plan d'implémentation concret que l'utilisateur devra approuver avant toute modification de fichier.
 
-Bascule Claude Code en mode planification, utilisé pour explorer la base de code et concevoir un plan avant l'implémentation.
+## Quand l'utiliser
+
+- L'utilisateur demande un changement non trivial couvrant plusieurs fichiers ou sous-systèmes.
+- Les exigences sont ambiguës et l'assistant doit lire le code avant de s'engager sur une approche.
+- Un refactoring, une migration ou une mise à niveau de dépendance est proposé et le rayon d'impact n'est pas clair.
+- L'utilisateur dit explicitement « plan this », « let's plan first », ou demande une revue de conception.
+- Le risque est suffisamment élevé pour que passer directement aux modifications puisse gaspiller du travail ou endommager l'état.
 
 ## Paramètres
 
-Aucun paramètre.
+Aucun. `EnterPlanMode` ne prend aucun argument — invoquez-le avec un objet de paramètres vide.
 
-## Cas d'utilisation
+## Exemples
 
-**Adapté pour :**
-- Implémentation de nouvelles fonctionnalités — nécessite des décisions d'architecture
-- Plusieurs approches viables existent — nécessite le choix de l'utilisateur
-- Les modifications de code affectent le comportement ou la structure existante
-- Changements dans plusieurs fichiers — impliquant potentiellement 2-3 fichiers ou plus
-- Exigences peu claires — besoin d'explorer d'abord pour comprendre la portée
-- Les préférences de l'utilisateur sont importantes — l'implémentation peut avoir plusieurs directions raisonnables
+### Exemple 1 : demande de fonctionnalité majeure
 
-**Non adapté pour :**
-- Corrections d'une ligne ou de quelques lignes (fautes de frappe, bugs évidents)
-- L'utilisateur a déjà donné des instructions très spécifiques
-- Tâches purement de recherche/exploration — utiliser Task (type Explore)
+L'utilisateur demande : « Ajoute le SSO via Okta au panneau d'administration. » L'assistant appelle `EnterPlanMode`, puis passe plusieurs tours à lire le middleware d'authentification, le stockage de session, les gardes de routes et l'interface de connexion existante. Il rédige un plan décrivant les changements requis, les étapes de migration et la couverture de tests, puis soumet via `ExitPlanMode` pour approbation.
 
-## Comportement en mode planification
+### Exemple 2 : refactoring risqué
 
-Après être entré en mode planification, Claude Code :
-1. Utilise les outils Glob, Grep, Read pour explorer la base de code en profondeur
-2. Comprend les patterns et l'architecture existants
-3. Conçoit un plan d'implémentation
-4. Soumet le plan à l'utilisateur pour approbation
-5. Peut utiliser AskUserQuestion si des clarifications sont nécessaires
-6. Sort via ExitPlanMode lorsque le plan est prêt
+L'utilisateur dit : « Convertis les contrôleurs REST en tRPC. » L'assistant entre en mode plan, passe en revue chaque contrôleur, catalogue le contrat public, liste les phases de déploiement (shim, double lecture, bascule) et propose un plan de séquencement avant de toucher à un fichier.
 
 ## Notes
 
-- Cet outil nécessite le consentement de l'utilisateur pour entrer en mode planification
-- En cas de doute sur la nécessité de planifier, il est préférable de planifier — s'aligner en amont est mieux que de refaire
-
-## Texte original
-
-<textarea readonly>Use this tool proactively when you're about to start a non-trivial implementation task. Getting user sign-off on your approach before writing code prevents wasted effort and ensures alignment. This tool transitions you into plan mode where you can explore the codebase and design an implementation approach for user approval.
-
-## When to Use This Tool
-
-**Prefer using EnterPlanMode** for implementation tasks unless they're simple. Use it when ANY of these conditions apply:
-
-1. **New Feature Implementation**: Adding meaningful new functionality
-   - Example: "Add a logout button" - where should it go? What should happen on click?
-   - Example: "Add form validation" - what rules? What error messages?
-
-2. **Multiple Valid Approaches**: The task can be solved in several different ways
-   - Example: "Add caching to the API" - could use Redis, in-memory, file-based, etc.
-   - Example: "Improve performance" - many optimization strategies possible
-
-3. **Code Modifications**: Changes that affect existing behavior or structure
-   - Example: "Update the login flow" - what exactly should change?
-   - Example: "Refactor this component" - what's the target architecture?
-
-4. **Architectural Decisions**: The task requires choosing between patterns or technologies
-   - Example: "Add real-time updates" - WebSockets vs SSE vs polling
-   - Example: "Implement state management" - Redux vs Context vs custom solution
-
-5. **Multi-File Changes**: The task will likely touch more than 2-3 files
-   - Example: "Refactor the authentication system"
-   - Example: "Add a new API endpoint with tests"
-
-6. **Unclear Requirements**: You need to explore before understanding the full scope
-   - Example: "Make the app faster" - need to profile and identify bottlenecks
-   - Example: "Fix the bug in checkout" - need to investigate root cause
-
-7. **User Preferences Matter**: The implementation could reasonably go multiple ways
-   - If you would use AskUserQuestion to clarify the approach, use EnterPlanMode instead
-   - Plan mode lets you explore first, then present options with context
-
-## When NOT to Use This Tool
-
-Only skip EnterPlanMode for simple tasks:
-- Single-line or few-line fixes (typos, obvious bugs, small tweaks)
-- Adding a single function with clear requirements
-- Tasks where the user has given very specific, detailed instructions
-- Pure research/exploration tasks (use the Agent tool with explore agent instead)
-
-## What Happens in Plan Mode
-
-In plan mode, you'll:
-1. Thoroughly explore the codebase using Glob, Grep, and Read tools
-2. Understand existing patterns and architecture
-3. Design an implementation approach
-4. Present your plan to the user for approval
-5. Use AskUserQuestion if you need to clarify approaches
-6. Exit plan mode with ExitPlanMode when ready to implement
-
-## Examples
-
-### GOOD - Use EnterPlanMode:
-User: "Add user authentication to the app"
-- Requires architectural decisions (session vs JWT, where to store tokens, middleware structure)
-
-User: "Optimize the database queries"
-- Multiple approaches possible, need to profile first, significant impact
-
-User: "Implement dark mode"
-- Architectural decision on theme system, affects many components
-
-User: "Add a delete button to the user profile"
-- Seems simple but involves: where to place it, confirmation dialog, API call, error handling, state updates
-
-User: "Update the error handling in the API"
-- Affects multiple files, user should approve the approach
-
-### BAD - Don't use EnterPlanMode:
-User: "Fix the typo in the README"
-- Straightforward, no planning needed
-
-User: "Add a console.log to debug this function"
-- Simple, obvious implementation
-
-User: "What files handle routing?"
-- Research task, not implementation planning
-
-## Important Notes
-
-- This tool REQUIRES user approval - they must consent to entering plan mode
-- If unsure whether to use it, err on the side of planning - it's better to get alignment upfront than to redo work
-- Users appreciate being consulted before significant changes are made to their codebase
-</textarea>
+- Le mode plan est en lecture seule par contrat. Tant qu'il est actif, l'assistant ne doit pas exécuter `Edit`, `Write`, `NotebookEdit` ni aucune commande shell mutative. Utilisez uniquement `Read`, `Grep`, `Glob` et des commandes `Bash` non destructives.
+- N'entrez pas en mode plan pour des modifications triviales d'une seule ligne, des questions de pure recherche, ou des tâches où l'utilisateur a déjà spécifié entièrement le changement. Le surcoût nuit plus qu'il n'aide.
+- En mode Auto, le mode plan est découragé sauf si l'utilisateur le demande explicitement — le mode Auto privilégie l'action à la planification préalable.
+- Utilisez le mode plan pour réduire les corrections de trajectoire sur des travaux coûteux. Un plan de cinq minutes économise souvent une heure de modifications mal orientées.
+- Une fois en mode plan, concentrez l'investigation sur les parties du système qui vont effectivement changer. Évitez les tours exhaustifs du dépôt sans rapport avec la tâche en cours.
+- Le plan lui-même doit être écrit sur disque au chemin attendu par le harnais afin que `ExitPlanMode` puisse le soumettre. Le plan doit contenir des chemins de fichiers concrets, des noms de fonctions et des étapes de vérification, et non une intention vague.
+- L'utilisateur peut rejeter le plan et demander des révisions. Itérez en mode plan jusqu'à ce que le plan soit accepté ; ne sortez qu'à ce moment-là.