cx-viewer 1.0.3 → 1.0.4

package/concepts/fr/Teammate.md

@@ -2,25 +2,25 @@
 
 ## Definition
 
-Un Teammate est un agent collaboratif dans le mode equipe de Claude Code Agent. Lorsque l'agent principal cree une equipe via `TeamCreate` et genere des teammates a l'aide de l'outil `Agent`, chaque teammate s'execute en tant que processus d'agent independant avec sa propre fenetre de contexte et son propre ensemble d'outils, communiquant avec les membres de l'equipe via `SendMessage`.
+A Teammate is a collaborative agent in Codex Agent Team mode. The main agent discovers the available multi-agent tools through `tool_search`; when those tools are available, each teammate runs as an independent agent process with its own context window and toolset.
 
-## Differences avec SubAgent
+## Differences from SubAgent
 
-| Caracteristique | Teammate | SubAgent |
-|-----------------|----------|----------|
-| Cycle de vie | Persistant, peut recevoir plusieurs messages | Tache unique, detruit a la fin |
-| Communication | Messagerie bidirectionnelle avec SendMessage | Appel unidirectionnel parent→enfant, retourne le resultat |
-| Contexte | Contexte complet independant, conserve entre les tours | Contexte de tache isole |
-| Collaboration | Collaboration en equipe, peuvent communiquer entre eux | Structure hierarchique, interagit uniquement avec l'agent parent |
-| Type de tache | Taches complexes en plusieurs etapes | Taches individuelles comme la recherche et l'exploration |
+| Feature | Teammate | SubAgent |
+|---------|----------|----------|
+| Lifecycle | Persistent, can receive multiple messages | One-off task, destroyed upon completion |
+| Communication | Team messaging through the available multi-agent toolset | Parent→child unidirectional call, returns result |
+| Context | Independent full context, retained across turns | Isolated task context |
+| Collaboration | Team collaboration, can communicate with each other | Hierarchical structure, only interacts with parent agent |
+| Task Type | Complex multi-step tasks | Single tasks such as search and exploration |
 
-## Comportement
+## Behavior
 
-- Cree par l'agent principal (team lead) via l'outil `Agent` et assigne a un `team_name`
-- Partage les listes de taches via `TaskList` / `TaskGet` / `TaskUpdate`
-- Entre en etat idle apres chaque tour, en attente d'etre reveille par un nouveau message
-- Peut etre termine de maniere elegante via `shutdown_request`
+- Created by the main agent (team lead) through available multi-agent tooling and assigned a team identity
+- Shares task state through the available multi-agent task/status tools
+- Enters idle state after each turn, waiting to be woken by a new message
+- Can be gracefully terminated via `shutdown_request`
 
-## Description du panneau de statistiques
+## Stats Panel Description
 
-Le panneau de statistiques Teammate affiche le nombre d'appels API pour chaque teammate. La colonne `Name` indique le nom du teammate (par exemple, `reviewer-security`, `reviewer-pipeline`), et la colonne `Count` indique le nombre total de requetes API generees par ce teammate.
+The Teammate stats panel displays the number of API calls for each teammate. The `Name` column shows the teammate's name (e.g., `reviewer-security`, `reviewer-pipeline`), and the `Count` column shows the total number of API requests generated by that teammate.

package/concepts/fr/ToolsFirst.md

@@ -1,77 +1,71 @@
-# Pourquoi les Tools sont-ils listés en premier ?
+# Why Are Tools Listed First?
 
-Dans le panneau Context de cc-viewer, **les Tools apparaissent avant le System Prompt et les Messages**. Cet ordre reflète précisément la **séquence de préfixe KV-Cache de l'API Anthropic**.
+In CX Viewer's Context panel, **Tools appear before Instructions and Input**. For Codex, this is a diagnostic layout: tool definitions are a large, high-impact part of the request shape, so they are shown first before the instructions and conversation context they constrain.
 
-## Séquence de préfixe KV-Cache
+## Request Context Layout
 
-Lorsque l'API Anthropic construit le KV-Cache, elle concatène le contexte en un préfixe dans cet **ordre fixe** :
+Codex traffic can arrive from OpenAI Responses API calls, Codex app-server events, or SDK stream events. CX Viewer normalizes those sources into a consistent context view:
 
 ```
 ┌─────────────────────────────────────────────────┐
-│ 1. Tools (JSON Schema definitions)               │  ← Start of cache prefix
-│ 2. System Prompt                                 │
-│ 3. Messages (conversation history + current turn)│  ← End of cache prefix
+│ 1. Tools (JSON Schema definitions)               │  ← Capability surface
+│ 2. Instructions                                  │
+│ 3. Input (conversation history + current turn)   │
 └─────────────────────────────────────────────────┘
 ```
 
-Cela signifie que **les Tools se trouvent avant le System Prompt, tout au début du préfixe de cache**.
+This does not claim a provider-specific serialization order. It gives you a stable way to inspect what capabilities were available before reading instructions and input history.
 
-## Pourquoi les Tools ont-ils un poids de cache supérieur à System ?
+## Why Tools Often Matter Most
 
-Dans la correspondance de préfixe KV-Cache, **le contenu en début de séquence est plus critique** — toute modification invalide tout ce qui suit :
+Tool definitions are often the largest static part of an agent request. A small UI toggle can add, remove, or reshape many tool schemas, which changes model behavior and request size.
 
-1. **La correspondance de préfixe commence par le début** : Le KV-Cache compare la requête actuelle au préfixe mis en cache token par token depuis le début. Dès qu'une divergence est détectée, tout le contenu suivant est invalidé.
+1. **Capability changes are semantic changes**: Adding or removing a tool changes what the agent is allowed to do, not just the token count.
 
-2. **Modification des Tools = tout le cache invalidé** : Les Tools étant en première position, toute modification des définitions de tool (même l'ajout ou la suppression d'un seul MCP tool) **brise le préfixe dès le tout début**, invalidant tous les System Prompt et Messages mis en cache.
+2. **Tool schemas can dominate request size**: MCP and dynamic tools often have detailed JSON Schemas with descriptions, enums, and nested parameters.
 
-3. **Modification de System = cache des Messages invalidé** : Le System Prompt se trouve au milieu, donc ses modifications n'invalident que la portion Messages qui suit.
+4. **Input appends are usually cheaper to inspect**: Normal conversation turns mostly add new user input and the previous assistant/tool results, while tool and instruction changes tend to be rarer and more important.
 
-4. **Modification des Messages = seule la fin est affectée** : Les Messages sont à la fin, donc l'ajout de nouveaux messages n'invalide qu'un petit segment final — les caches Tools et System restent intacts.
+## Practical Impact
 
-## Impact pratique
-
-| Type de modification | Impact sur le cache | Scénario typique |
+| Change Type | Cache Impact | Typical Scenario |
 |-------------|-------------|-----------------|
-| Tool ajouté/supprimé | **Invalidation complète** | Connexion/déconnexion d'un serveur MCP, activation/désactivation d'un plugin IDE |
-| Modification du System Prompt | Cache des Messages perdu | Édition de CLAUDE.md, injection de system reminder |
-| Nouveau message ajouté | Incrément de queue uniquement | Flux de conversation normal (le plus fréquent, le moins coûteux) |
-
-C'est pourquoi `tools_change` dans [CacheRebuild](CacheRebuild.md) tend à être la raison de reconstruction la plus coûteuse — elle brise la chaîne de préfixe dès le tout début.
-
-## Pourquoi les définitions d'outils sont-elles placées avant le « cerveau » ?
+| Tool added/removed | Request shape changes | MCP server connect/disconnect, plugin toggle |
+| Instructions change | Instructions and policy changed | `AGENTS.md` edit, developer instruction update |
+| New input appended | Normal turn growth | User input, assistant reply, tool result |
 
-Du point de vue du cache, le fait que les Tools soient en premier est un fait technique. Mais du point de vue de la conception cognitive, cet ordre est tout aussi logique — **les Tools sont les mains et les pieds, le System Prompt est le cerveau**.
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-Avant d'agir, une personne doit percevoir quels membres et outils sont à sa disposition. Un nourrisson ne comprend pas d'abord les règles du monde (System) avant d'apprendre à saisir — il perçoit d'abord qu'il a des mains et des pieds, puis comprend progressivement les règles par l'interaction avec son environnement. De même, un LLM doit savoir quels outils il peut appeler (lire des fichiers, écrire du code, rechercher, exécuter des commandes) avant de recevoir les instructions de tâche (System Prompt), afin de pouvoir évaluer précisément « que puis-je faire » et « comment dois-je procéder » lors du traitement des instructions.
+From a diagnostic perspective, putting Tools first is useful because tool definitions describe the agent's available actions before you inspect the instructions that ask the agent to act.
 
-Si l'ordre était inversé — dire d'abord au modèle « ta tâche est de refactoriser ce module », puis lui dire « tu disposes des outils Read, Edit, Bash » — le modèle manquerait d'informations cruciales sur les limites de ses capacités lors de la compréhension de la tâche, produisant potentiellement des plans irréalistes ou omettant des approches disponibles.
+Before taking action, a person needs to perceive what limbs and tools are available. An infant doesn't first understand the rules of the world (Instructions), then learn to reach and grab — they first sense that they have hands and feet, then gradually understand rules through interaction with the environment. Similarly, an LLM needs to know what tools it can call (read files, write code, search, execute commands) before receiving task instructions, so it can accurately assess "what can I do" and "how should I do it" when processing the instructions.
 
-**Connaître ses cartes avant de décider comment jouer.** Voilà la logique cognitive derrière le placement des Tools avant le System.
+If reversed — first telling the model "your task is to refactor this module", then telling it "you have shell_command, apply_patch, and tool_search" — the model would lack critical capability boundary information when understanding the task, potentially producing unrealistic plans or overlooking available approaches.
 
-## Pourquoi les outils MCP sont-ils aussi à cette position ?
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-Les outils MCP (Model Context Protocol), comme les outils intégrés, sont placés tout au début de la zone Tools. Comprendre la position de MCP dans le contexte aide à évaluer ses véritables avantages et coûts.
+## Why Are MCP Tools Also in This Position?
 
-### Avantages de MCP
+MCP (Model Context Protocol) tools, like built-in tools, are placed at the very front of the Tools area. Understanding MCP's position in the context helps evaluate its real benefits and costs.
 
-- **Extension des capacités** : MCP permet aux modèles d'accéder à des services externes (requêtes base de données, appels API, opérations IDE, contrôle de navigateur, etc.), dépassant les limites des outils intégrés
-- **Écosystème ouvert** : N'importe qui peut implémenter un serveur MCP ; le modèle acquiert de nouvelles capacités sans réentraînement
-- **Chargement à la demande** : Les serveurs MCP peuvent être connectés/déconnectés sélectivement selon le scénario, composant des ensembles d'outils flexibles
+### MCP Advantages
 
-### Coûts de MCP
+- **Capability extension**: MCP lets models access external services (database queries, API calls, IDE operations, browser control, etc.), breaking beyond built-in tool boundaries
+- **Open ecosystem**: Anyone can implement an MCP server; the model gains new capabilities without retraining
+- **On-demand loading**: MCP servers can be selectively connected/disconnected based on task scenario, flexibly composing tool sets
 
-- **Tueur de cache** : La définition JSON Schema de chaque outil MCP est concaténée au tout début du préfixe KV-Cache. Ajouter ou supprimer un seul outil MCP = **tout le cache est invalidé depuis le début**. Connecter/déconnecter fréquemment des serveurs MCP réduit considérablement le taux de succès du cache
-- **Gonflement du préfixe** : Les Schemas des outils MCP sont généralement plus volumineux que ceux des outils intégrés (descriptions détaillées des paramètres, énumérations, etc.). De nombreux outils MCP augmentent significativement le nombre de tokens de la zone Tools, réduisant l'espace de contexte disponible pour les Messages
-- **Surcoût de latence** : Les appels d'outils MCP nécessitent une communication inter-processus (JSON-RPC via stdio/SSE), un ordre de grandeur plus lent que les appels de fonctions intégrées
-- **Risque de stabilité** : Les serveurs MCP sont des processus externes qui peuvent planter, expirer ou retourner des formats inattendus, nécessitant une gestion d'erreurs supplémentaire
+### MCP Costs
+- **Prefix bloat**: MCP tool Schemas are typically larger than built-in tools (containing detailed parameter descriptions, enums, etc.). Many MCP tools significantly increase the Tools area's token count, squeezing the context space available for Input
+- **Latency overhead**: MCP tool calls require cross-process communication (JSON-RPC over stdio/SSE), an order of magnitude slower than built-in function calls
+- **Stability risk**: MCP servers are external processes that may crash, timeout, or return unexpected formats, requiring additional error handling
 
-### Recommandations pratiques
+### Practical Recommendations
 
-| Scénario | Recommandation |
+| Scenario | Recommendation |
 |----------|---------------|
-| Conversations longues, interactions fréquentes | Minimiser le nombre d'outils MCP pour protéger la stabilité du préfixe de cache |
-| Tâches courtes, opérations ponctuelles | Utiliser librement les outils MCP ; l'impact sur le cache est limité |
-| Ajout/suppression fréquent de serveurs MCP | Chaque changement déclenche une reconstruction complète du cache ; envisager de fixer l'ensemble d'outils |
-| Schemas d'outils surdimensionnés | Réduire les descriptions et énumérations pour diminuer l'empreinte en tokens du préfixe |
+| Long conversations, high-frequency interaction | Minimize MCP tool count to keep requests smaller and easier to inspect |
+| Short tasks, one-off operations | Use MCP tools freely; overhead is usually limited |
+| Frequently adding/removing MCP servers | Each change reshapes the request; consider fixing the tool set |
+| Oversized Tool Schemas | Trim descriptions and enums to reduce prefix token footprint |
 
-Dans le panneau Context de cc-viewer, les outils MCP sont affichés aux côtés des outils intégrés dans la zone Tools, offrant une vue claire de la taille du Schema de chaque outil et de sa contribution au préfixe de cache.
+In CX Viewer's Context panel, MCP tools are displayed alongside built-in and dynamic tools in the Tools area, giving you a clear view of each tool's Schema size and contribution to request shape.

package/concepts/fr/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## Contexte
 
-CC-Viewer intègre une fonctionnalité de traduction (`POST /api/translate`) alimentée par l'API Messages d'Anthropic. Dans l'implémentation initiale, les requêtes de traduction réutilisaient les identifiants d'authentification mis en cache de la session Claude Code — incluant les en-têtes `x-api-key` et `authorization`. Cela a provoqué un problème subtil mais grave : les résultats de traduction renvoyaient fréquemment du contenu sans rapport.
+CC-Viewer intègre une fonctionnalité de traduction (`POST /api/translate`) alimentée par l'API Messages d'Anthropic. Dans l'implémentation initiale, les requêtes de traduction réutilisaient les identifiants d'authentification mis en cache de la session Codex — incluant les en-têtes `x-api-key` et `authorization`. Cela a provoqué un problème subtil mais grave : les résultats de traduction renvoyaient fréquemment du contenu sans rapport.
 
 ## Cause profonde
 
@@ -13,24 +13,24 @@ L'API Anthropic prend en charge deux méthodes d'authentification :
 | Méthode | En-tête | Source typique | Caractéristiques |
 |---------|---------|----------------|------------------|
 | Clé API | `x-api-key: sk-ant-...` | Variable d'environnement / Console | Sans état, chaque requête est indépendante |
-| Jeton OAuth | `authorization: Bearer sessionToken` | Connexion par abonnement Claude Code | Lié à la session, le serveur maintient l'association de contexte |
+| Jeton OAuth | `authorization: Bearer sessionToken` | Connexion par abonnement Codex | Lié à la session, le serveur maintient l'association de contexte |
 
 La différence clé : **les clés API sont sans état** — chaque requête est complètement indépendante ; tandis que **les jetons de session OAuth sont avec état** — le serveur Anthropic associe les requêtes utilisant le même jeton au même contexte de session.
 
 ### Chaîne de pollution
 
-Lorsque Claude Code utilise la connexion OAuth par abonnement, le flux d'authentification se présente ainsi :
+Lorsque Codex utilise la connexion OAuth par abonnement, le flux d'authentification se présente ainsi :
 
 ```
-Conversation principale Claude Code ──(authorization: Bearer sessionToken)──→ Anthropic API
+Conversation principale Codex ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                                 ↑
 Requête de traduction CC-Viewer ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-Étant donné que les requêtes de traduction réutilisaient le même jeton de session, le serveur Anthropic pouvait associer les requêtes de traduction au contexte de la conversation principale de Claude Code. Cela entraîne :
+Étant donné que les requêtes de traduction réutilisaient le même jeton de session, le serveur Anthropic pouvait associer les requêtes de traduction au contexte de la conversation principale de Codex. Cela entraîne :
 
-1. **Les résultats de traduction sont influencés par le contexte de la conversation principale** : Le prompt système de la requête de traduction est « vous êtes un traducteur », mais le contexte serveur contient toujours l'historique de conversation de Claude Code, ce qui peut interférer avec le modèle
-2. **La conversation principale est perturbée par les requêtes de traduction** : Le contenu des requêtes de traduction (fragments de texte d'interface) peut être injecté dans le contexte de la conversation principale, provoquant des déviations dans les réponses de Claude Code
+1. **Les résultats de traduction sont influencés par le contexte de la conversation principale** : Le prompt système de la requête de traduction est « vous êtes un traducteur », mais le contexte serveur contient toujours l'historique de conversation de Codex, ce qui peut interférer avec le modèle
+2. **La conversation principale est perturbée par les requêtes de traduction** : Le contenu des requêtes de traduction (fragments de texte d'interface) peut être injecté dans le contexte de la conversation principale, provoquant des déviations dans les réponses de Codex
 3. **Comportement imprévisible** : La pollution de contexte étant un comportement côté serveur, le client ne peut ni la détecter ni la contrôler
 
 ## Leçons retenues
@@ -41,6 +41,6 @@ Requête de traduction CC-Viewer ──(authorization: Bearer sessionToken)─
 ## Références
 
 - [Anthropic API Authentication Docs](https://docs.anthropic.com/en/api/getting-started)
-- [Claude Code Authentication](https://support.claude.com/en/articles/12304248-managing-api-key-environment-variables-in-claude-code)
+- [Codex Authentication](https://support.claude.com/en/articles/12304248-managing-api-key-environment-variables-in-claude-code)
 - [Anthropic Bans Subscription OAuth in Third-Party Apps](https://winbuzzer.com/2026/02/19/anthropic-bans-claude-subscription-oauth-in-third-party-apps-xcxwbn/)
-- [Claude Code Authentication: API Keys, Subscriptions, and SSO](https://developertoolkit.ai/en/claude-code/quick-start/authentication/)
+- [Codex Authentication: API Keys, Subscriptions, and SSO](https://developertoolkit.ai/en/claude-code/quick-start/authentication/)

package/concepts/fr/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — La Machine a Voeux Ultime
+# UltraPlan — The Ultimate Wishing Machine
 
-## Qu'est-ce que UltraPlan
+## What is UltraPlan
 
-UltraPlan est l'**implementation localisee** par cc-viewer de la commande native `/ultraplan` de Claude Code. Il vous permet d'utiliser les capacites completes de `/ultraplan` dans votre environnement local **sans avoir besoin de lancer le service distant officiel de Claude**, en guidant Claude Code pour accomplir des taches complexes de planification et d'implementation en utilisant la **collaboration multi-agents**.
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
-Par rapport au mode Plan classique ou a Agent Team, UltraPlan peut :
-- Evaluer automatiquement la complexite de la tache et selectionner la strategie de planification optimale
-- Deployer plusieurs agents en parallele pour explorer la base de code sous differentes dimensions
-- Integrer la recherche externe (webSearch) pour les meilleures pratiques de l'industrie
-- Assembler automatiquement une Code Review Team apres l'execution du plan pour la revue de code
-- Former une boucle fermee complete **Plan → Execute → Review → Fix**
+Compared to regular Plan mode or Agent Team, UltraPlan can:
+- Automatically assess task complexity and select the optimal planning strategy
+- Deploy multiple parallel agents to explore the codebase from different dimensions
+- Incorporate external research (`web_search`) for industry best practices
+- Automatically assemble a Code Review Team after plan execution for code review
+- Form a complete **Plan → Execute → Review → Fix** closed loop
 
 ---
 
-## Notes Importantes
+## Important Notes
 
-### 1. UltraPlan N'est Pas Omnipotent
-UltraPlan est une machine a voeux plus puissante, mais cela ne signifie pas que chaque voeu peut etre exauce. Il est plus puissant que Plan et Agent Team, mais ne peut pas directement « vous faire gagner de l'argent ». Considerez une granularite de taches raisonnable — decomposez les grands objectifs en taches moyennes executables plutot que d'essayer de tout accomplir en une seule fois.
+### 1. UltraPlan Is Not Omnipotent
+UltraPlan is a more powerful wishing machine, but that doesn't mean every wish can be fulfilled. It's more powerful than Plan and Agent Team, but it can't directly "make you money." Consider reasonable task granularity — break large goals into executable medium-sized tasks rather than trying to accomplish everything in one shot.
 
-### 2. Actuellement Plus Efficace pour les Projets de Programmation
-Les modeles et flux de travail d'UltraPlan sont profondement optimises pour les projets de programmation. D'autres scenarios (documentation, analyse de donnees, etc.) peuvent etre tentes, mais il est conseille d'attendre les adaptations des versions futures.
+### 2. Currently Most Effective for Programming Projects
+UltraPlan's templates and workflows are deeply optimized for programming projects. Other scenarios (documentation, data analysis, etc.) can be attempted, but you may want to wait for future version adaptations.
 
-### 3. Temps d'Execution et Exigences de Fenetre de Contexte
-- Une execution reussie d'UltraPlan prend generalement **30 minutes ou plus**
-- Necessite que le MainAgent dispose d'une grande fenetre de contexte (modele Opus avec 1M de contexte recommande)
-- Si vous ne disposez que d'un modele 200K, **assurez-vous de faire `/clear` sur le contexte avant l'execution**
-- Le `/compact` de Claude Code fonctionne mal lorsque la fenetre de contexte est insuffisante — evitez de manquer d'espace
-- Maintenir un espace de contexte suffisant est un prerequis essentiel pour la reussite de l'execution d'UltraPlan
+### 3. Execution Time and Context Window Requirements
+- A successful UltraPlan run typically takes **30 minutes or more**
+- Requires MainAgent to have a large enough context window for multi-agent findings and review output
+- If your active model has a smaller context window, **make sure to `/clear` context before running**
+- Compaction is less reliable when the context window is already nearly full — avoid running out of space
+- Maintaining sufficient context space is a critical prerequisite for successful UltraPlan execution
 
-Si vous avez des questions ou des suggestions concernant l'UltraPlan localise, n'hesitez pas a ouvrir des [Issues sur GitHub](https://github.com/anthropics/claude-code/issues) pour discuter et collaborer.
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
-## Fonctionnement
+## How It Works
 
-UltraPlan propose deux modes de fonctionnement :
+UltraPlan offers two operating modes:
 
-### Mode Automatique
-Analyse automatiquement la complexite de la tache (score 4-12) et oriente vers differentes strategies :
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| Route | Score | Strategie |
-|-------|-------|-----------|
-| Route A | 4-6 | Planification legere avec exploration directe du code |
-| Route B | 7-9 | Planification avec diagrammes structurels (Mermaid / ASCII) |
-| Route C | 10-12 | Exploration multi-agents + boucle fermee de revue |
+| Route | Score | Strategy |
+|-------|-------|----------|
+| Route A | 4-6 | Lightweight planning with direct code exploration |
+| Route B | 7-9 | Planning with structural diagrams (Mermaid / ASCII) |
+| Route C | 10-12 | Multi-agent exploration + review closed loop |
 
-### Mode Force
-Active directement le flux de travail multi-agents complet de la Route C :
-1. Deployer jusqu'a 5 agents en parallele pour explorer simultanement la base de code (architecture, identification des fichiers, evaluation des risques, etc.)
-2. Optionnellement deployer un agent de recherche pour investiguer les solutions de l'industrie via webSearch
-3. Synthetiser toutes les decouvertes des agents en un plan d'implementation detaille
-4. Deployer un agent de revue pour examiner le plan sous plusieurs perspectives
-5. Executer le plan une fois approuve
-6. Assembler automatiquement une Code Review Team pour valider la qualite du code apres l'implementation
+### Forced Mode
+Directly activates the full Route C multi-agent workflow:
+1. Deploy up to 5 parallel agents to explore the codebase simultaneously (architecture, file identification, risk assessment, etc.)
+2. Optionally deploy a research agent to investigate industry solutions via `web_search`
+3. Synthesize all agent findings into a detailed implementation plan
+4. Deploy a review agent to scrutinize the plan from multiple perspectives
+5. Execute the plan once approved
+6. Automatically assemble a Code Review Team to validate code quality after implementation

package/concepts/it/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Contesto
 
-Il MainAgent di Claude Code utilizza un meccanismo di invio del contesto completo: ogni richiesta include l'intera cronologia della conversazione, il system prompt, le definizioni degli strumenti, ecc. Ciò significa che, man mano che la conversazione procede, il corpo della richiesta diventa sempre più grande, rendendo difficile individuare rapidamente "cosa è stato aggiunto in questo turno" esaminando il Body grezzo.
+Il MainAgent di Codex utilizza un meccanismo di invio del contesto completo: ogni richiesta include l'intera cronologia della conversazione, il system prompt, le definizioni degli strumenti, ecc. Ciò significa che, man mano che la conversazione procede, il corpo della richiesta diventa sempre più grande, rendendo difficile individuare rapidamente "cosa è stato aggiunto in questo turno" esaminando il Body grezzo.
 
 Body Diff JSON è stato creato proprio per risolvere questo problema: confronta automaticamente i body di due richieste MainAgent consecutive, estraendo la parte incrementale, permettendoti di vedere a colpo d'occhio il contenuto effettivamente aggiunto in questa richiesta.
 
@@ -22,7 +22,7 @@ Body Diff JSON è stato creato proprio per risolvere questo problema: confronta
 In un turno di conversazione normale, il Body Diff JSON contiene solitamente solo:
 - `messages`: 1~2 messaggi aggiunti (l'input dell'utente + la risposta dell'assistente del turno precedente)
 
-Se nel diff compaiono modifiche a campi come `system`, `tools`, `model`, significa che in questo turno si è verificata una modifica della configurazione, che spesso è anche la causa della ricostruzione della cache.
+Se nel diff compaiono modifiche a campi come `system`, `tools`, `model`, significa che in questo turno si è verificata una modifica della configurazione.
 
 ## Modalità d'uso
 

package/concepts/it/BodyFields.md

@@ -1,42 +1,39 @@
-# Descrizione dei campi del Request Body
+# Request Body Fields
 
-Descrizione dei campi di primo livello del corpo della richiesta dell'API Claude `/v1/messages`.
+Field descriptions for CX-Viewer's normalized Codex request body. The original source may be OpenAI Responses API traffic, Codex app-server notifications, or Codex SDK events; CX-Viewer maps them into one stable viewer shape.
 
-## Elenco dei campi
+## Field List
 
-| Campo | Tipo | Descrizione |
+| Field | Type | Description |
 |-------|------|-------------|
-| **model** | string | Nome del modello utilizzato, ad es. `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Cronologia dei messaggi della conversazione. Ogni messaggio contiene `role` (user/assistant) e `content` (un array di blocchi: testo, immagini, tool_use, tool_result ecc.) |
-| **system** | array | System prompt. Contiene le istruzioni principali di Codex, le istruzioni per l'uso degli strumenti, le informazioni sull'ambiente, i contenuti di CLAUDE.md ecc. I blocchi con `cache_control` vengono memorizzati nella cache tramite prompt caching |
-| **tools** | array | Elenco delle definizioni degli strumenti disponibili. Ogni strumento contiene `name`, `description` e `input_schema` (JSON Schema). Il MainAgent ha tipicamente 20+ strumenti, i SubAgent ne hanno solo pochi |
-| **metadata** | object | Metadati della richiesta, tipicamente contiene `user_id` per identificare l'utente |
-| **max_tokens** | number | Numero massimo di token per singola risposta del modello, ad es. `16000`, `64000` |
-| **thinking** | object | Configurazione del pensiero esteso. `type: "enabled"` attiva la modalità di pensiero, `budget_tokens` controlla il limite di token per il pensiero |
-| **context_management** | object | Configurazione della gestione del contesto. `truncation: "auto"` consente a Codex di troncare automaticamente cronologie di messaggi troppo lunghe |
-| **output_config** | object | Configurazione dell'output, ad es. impostazioni di `format` |
-| **stream** | boolean | Se le risposte in streaming sono abilitate. Codex utilizza sempre `true` |
-
-## Struttura di messages
-
-Il `content` di ogni messaggio è un array di blocchi con i seguenti tipi comuni:
-
-- **text**: Contenuto testuale normale
-- **tool_use**: Il modello invoca uno strumento (contiene `name`, `input`)
-- **tool_result**: Risultato dell'esecuzione dello strumento (contiene `tool_use_id`, `content`)
-- **image**: Contenuto immagine (base64 o URL)
-- **thinking**: Processo di pensiero del modello (modalità di pensiero esteso)
-
-## Struttura di system
-
-L'array del system prompt contiene tipicamente:
-
-1. **Istruzioni principali dell'agent** ("You are Codex...")
-2. **Specifiche per l'uso degli strumenti**
-3. **Contenuti di CLAUDE.md** (istruzioni a livello di progetto)
-4. **Promemoria delle skill** (skills reminder)
-5. **Informazioni sull'ambiente** (OS, shell, stato di git ecc.) — Di fatto, Codex dipende fortemente da git. Se nel progetto esiste un repository git, Codex riesce a dimostrare una migliore comprensione del progetto, inclusa la possibilità di recuperare modifiche remote e cronologie di commit per supportare l'analisi
-
-I blocchi contrassegnati con `cache_control: { type: "ephemeral" }` vengono memorizzati nella cache dall'API Anthropic per 5 minuti. Quando la cache viene utilizzata, la fatturazione avviene tramite `cache_read_input_tokens` (molto inferiore rispetto a `input_tokens`).
-
-> **Nota**: Per client speciali come Codex, il server Anthropic in realtà non si basa completamente sull'attributo `cache_control` nella richiesta per determinare il comportamento della cache. Il server esegue automaticamente strategie di caching per campi specifici (come il system prompt e le definizioni degli strumenti), anche quando la richiesta non contiene esplicitamente il marcatore `cache_control`. Pertanto, quando non vedete questo attributo nel corpo della richiesta, non c'è motivo di preoccuparsi: il server ha già eseguito le operazioni di caching dietro le quinte, senza esporre queste informazioni al client. Questa è una sorta di intesa tacita tra Codex e l'API Anthropic.
+| **model** | string | The model name selected by Codex, e.g. a `gpt-*` model |
+| **input** | string/array | OpenAI Responses API input. Codex usually uses the array form for user input, assistant history, tool results, and other context items |
+| **instructions** | string/array | OpenAI Responses API instructions. This can include Codex core directives, tool usage guidelines, environment information, and `AGENTS.md` project instructions |
+| **tools** | array | Available tool definitions or compact tool descriptors. MainAgent usually has a broader tool set than SubAgent |
+| **metadata** | object | Request metadata such as `thread_id`, `turn_id`, `cwd`, SDK/app-server source, and subAgent parent-thread information |
+| **max_tokens** | number | Maximum number of tokens for a single model response, e.g. `16000`, `64000` |
+| **reasoning_effort** | string | Reasoning effort when reported by Codex |
+| **reasoning_summary** | string | Reasoning summary mode when reported by Codex |
+| **approval_policy** | string | Codex approval policy for the turn |
+| **sandbox_policy** | object/string | Sandbox policy for the turn when available |
+| **stream** | boolean | Whether the OpenAI Responses API request used streaming; app-server/SDK entries are normalized as streamed turns |
+
+## input Structure
+
+When `input` is an array, each input item usually contains `role` and `content`. `content` can be an array of blocks. Common types include:
+
+- **text**: Plain text content
+- **tool_use**: Model tool invocation (contains `name`, `input`)
+- **tool_result**: Tool execution result (contains `tool_use_id`, `content`)
+- **image/input_image/local_image**: Image content or an attached local image reference
+- **thinking**: Model's thinking process (extended thinking mode)
+
+## instructions Structure
+
+`instructions` typically contains:
+
+1. **Core agent instructions** ("You are Codex...")
+2. **Tool usage guidelines**
+3. **AGENTS.md contents** (project-level instructions)
+4. **Skills reminders** (skills reminder)
+5. **Environment information** (OS, shell, git status, etc.) — In fact, Codex relies heavily on git. If a project has a git repository, Codex demonstrates a better understanding of the project, including the ability to pull remote changes and commit history to assist with analysis