cx-viewer 1.0.2 → 1.0.4

package/concepts/es/Teammate.md

@@ -1,26 +1,26 @@
 # Teammate
 
-## Definicion
+## Definition
 
-Un Teammate es un agente colaborativo en el modo de equipo de Claude Code Agent. Cuando el agente principal crea un equipo mediante `TeamCreate` y genera teammates usando la herramienta `Agent`, cada teammate se ejecuta como un proceso de agente independiente con su propia ventana de contexto y conjunto de herramientas, comunicandose con los miembros del equipo a traves de `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.
 
-## Diferencias con SubAgent
+## Differences from SubAgent
 
-| Caracteristica | Teammate | SubAgent |
-|----------------|----------|----------|
-| Ciclo de vida | Persistente, puede recibir multiples mensajes | Tarea unica, se destruye al completarse |
-| Comunicacion | Mensajeria bidireccional con SendMessage | Llamada unidireccional padre→hijo, devuelve resultado |
-| Contexto | Contexto completo independiente, se conserva entre turnos | Contexto de tarea aislado |
-| Colaboracion | Colaboracion en equipo, pueden comunicarse entre si | Estructura jerarquica, solo interactua con el agente padre |
-| Tipo de tarea | Tareas complejas de multiples pasos | Tareas individuales como busqueda y exploracion |
+| 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 |
 
-## Comportamiento
+## Behavior
 
-- Creado por el agente principal (team lead) mediante la herramienta `Agent` y asignado a un `team_name`
-- Comparte listas de tareas a traves de `TaskList` / `TaskGet` / `TaskUpdate`
-- Entra en estado idle despues de cada turno, esperando ser activado por un nuevo mensaje
-- Puede ser terminado de forma elegante mediante `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`
 
-## Descripcion del panel de estadisticas
+## Stats Panel Description
 
-El panel de estadisticas de Teammate muestra el numero de llamadas API de cada teammate. La columna `Name` muestra el nombre del teammate (por ejemplo, `reviewer-security`, `reviewer-pipeline`), y la columna `Count` muestra el numero total de solicitudes API generadas por ese 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/es/ToolsFirst.md

@@ -1,77 +1,71 @@
-# ¿Por qué se listan primero los Tools?
+# Why Are Tools Listed First?
 
-En el panel Context de cc-viewer, **los Tools aparecen antes que el System Prompt y los Messages**. Este orden refleja con precisión la **secuencia de prefijo KV-Cache de la API de 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.
 
-## Secuencia de prefijo KV-Cache
+## Request Context Layout
 
-Cuando la API de Anthropic construye el KV-Cache, concatena el contexto en un prefijo en este **orden fijo**:
+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)   │
 └─────────────────────────────────────────────────┘
 ```
 
-Esto significa que **los Tools se encuentran antes del System Prompt, al comienzo del prefijo de caché**.
+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.
 
-## ¿Por qué los Tools tienen mayor peso en caché que System?
+## Why Tools Often Matter Most
 
-En la coincidencia de prefijo KV-Cache, **el contenido más temprano es más crítico** — cualquier cambio invalida todo lo que viene después:
+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 coincidencia de prefijo comienza desde el principio**: El KV-Cache compara la solicitud actual con el prefijo almacenado en caché token por token desde el inicio. En el momento en que se detecta una discrepancia, todo el contenido posterior queda invalidado.
+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. **Cambio en Tools = todo el caché invalidado**: Como los Tools están primero, cualquier cambio en las definiciones de tool (incluso agregar o eliminar un solo MCP tool) **rompe el prefijo desde el mismísimo inicio**, invalidando todo el System Prompt y los Messages almacenados en caché.
+2. **Tool schemas can dominate request size**: MCP and dynamic tools often have detailed JSON Schemas with descriptions, enums, and nested parameters.
 
-3. **Cambio en System = caché de Messages invalidado**: El System Prompt está en el medio, por lo que sus cambios solo invalidan la porción de Messages que le sigue.
+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. **Cambio en Messages = solo el final se ve afectado**: Los Messages están al final, por lo que agregar nuevos messages solo invalida un pequeño segmento final — los cachés de Tools y System permanecen intactos.
+## Practical Impact
 
-## Impacto práctico
-
-| Tipo de cambio | Impacto en caché | Escenario típico |
+| Change Type | Cache Impact | Typical Scenario |
 |-------------|-------------|-----------------|
-| Tool agregado/eliminado | **Invalidación completa** | Conexión/desconexión de servidor MCP, activación/desactivación de plugin IDE |
-| Cambio en System Prompt | Caché de Messages perdido | Edición de CLAUDE.md, inyección de system reminder |
-| Nuevo message agregado | Solo incremento de cola | Flujo de conversación normal (el más común, el más económico) |
-
-Por eso `tools_change` en [CacheRebuild](CacheRebuild.md) tiende a ser la razón de reconstrucción más costosa — rompe la cadena de prefijo desde el principio.
-
-## ¿Por qué las definiciones de herramientas se colocan antes del "cerebro"?
+| 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 |
 
-Desde la perspectiva del caché, que los Tools estén primero es un hecho técnico. Pero desde la perspectiva del diseño cognitivo, este orden es igualmente lógico — **los Tools son las manos y los pies, el System Prompt es el cerebro**.
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-Antes de actuar, una persona necesita percibir qué extremidades y herramientas tiene disponibles. Un bebé no comprende primero las reglas del mundo (System) para luego aprender a agarrar — primero percibe que tiene manos y pies, y luego comprende gradualmente las reglas a través de la interacción con el entorno. Del mismo modo, un LLM necesita saber qué herramientas puede llamar (leer archivos, escribir código, buscar, ejecutar comandos) antes de recibir las instrucciones de tarea (System Prompt), para poder evaluar con precisión "qué puedo hacer" y "cómo debo hacerlo" al procesar las instrucciones.
+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 fuera al revés — decirle primero al modelo "tu tarea es refactorizar este módulo", y luego "tienes las herramientas Read, Edit, Bash" — el modelo carecería de información crucial sobre los límites de sus capacidades al entender la tarea, produciendo potencialmente planes poco realistas u omitiendo enfoques 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.
 
-**Conocer las cartas que tienes antes de decidir cómo jugar.** Esta es la lógica cognitiva detrás de que los Tools precedan al 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.
 
-## ¿Por qué las herramientas MCP también están en esta posición?
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-Las herramientas MCP (Model Context Protocol), al igual que las herramientas integradas, se colocan al inicio de la zona Tools. Comprender la posición de MCP en el contexto ayuda a evaluar sus beneficios y costes reales.
+## Why Are MCP Tools Also in This Position?
 
-### Ventajas 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.
 
-- **Extensión de capacidades**: MCP permite a los modelos acceder a servicios externos (consultas a bases de datos, llamadas API, operaciones IDE, control del navegador, etc.), superando los límites de las herramientas integradas
-- **Ecosistema abierto**: Cualquiera puede implementar un servidor MCP; el modelo obtiene nuevas capacidades sin reentrenamiento
-- **Carga bajo demanda**: Los servidores MCP pueden conectarse/desconectarse selectivamente según el escenario, componiendo conjuntos de herramientas flexibles
+### MCP Advantages
 
-### Costes 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
 
-- **Asesino de caché**: La definición JSON Schema de cada herramienta MCP se concatena al inicio del prefijo KV-Cache. Añadir o eliminar una herramienta MCP = **todo el caché se invalida desde el principio**. Conectar/desconectar frecuentemente servidores MCP reduce drásticamente la tasa de aciertos del caché
-- **Inflación del prefijo**: Los Schemas de herramientas MCP suelen ser más grandes que los de herramientas integradas (descripciones detalladas de parámetros, valores de enumeración, etc.). Muchas herramientas MCP aumentan significativamente el conteo de tokens de la zona Tools, reduciendo el espacio de contexto disponible para Messages
-- **Sobrecarga de latencia**: Las llamadas a herramientas MCP requieren comunicación entre procesos (JSON-RPC sobre stdio/SSE), un orden de magnitud más lento que las llamadas a funciones integradas
-- **Riesgo de estabilidad**: Los servidores MCP son procesos externos que pueden fallar, expirar o devolver formatos inesperados, requiriendo manejo de errores adicional
+### 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
 
-### Recomendaciones prácticas
+### Practical Recommendations
 
-| Escenario | Recomendación |
-|-----------|--------------|
-| Conversaciones largas, interacción frecuente | Minimizar la cantidad de herramientas MCP para proteger la estabilidad del prefijo de caché |
-| Tareas cortas, operaciones puntuales | Usar herramientas MCP libremente; el impacto en el caché es limitado |
-| Adición/eliminación frecuente de servidores MCP | Cada cambio desencadena una reconstrucción completa del caché; considerar fijar el conjunto de herramientas |
-| Schemas de herramientas sobredimensionados | Reducir descripciones y enums para disminuir el consumo de tokens del prefijo |
+| Scenario | Recommendation |
+|----------|---------------|
+| 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 |
 
-En el panel Context de cc-viewer, las herramientas MCP se muestran junto a las herramientas integradas en la zona Tools, ofreciendo una vista clara del tamaño del Schema de cada herramienta y su contribución al prefijo de caché.
+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/es/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## Contexto
 
-CC-Viewer incluye una función de traducción integrada (`POST /api/translate`) impulsada por la API de mensajes de Anthropic. En la implementación inicial, las solicitudes de traducción reutilizaban las credenciales de autenticación almacenadas en caché de la sesión de Claude Code, incluyendo tanto los encabezados `x-api-key` como `authorization`. Esto provocó un problema sutil pero grave: los resultados de traducción devolvían con frecuencia contenido irrelevante.
+CC-Viewer incluye una función de traducción integrada (`POST /api/translate`) impulsada por la API de mensajes de Anthropic. En la implementación inicial, las solicitudes de traducción reutilizaban las credenciales de autenticación almacenadas en caché de la sesión de Codex, incluyendo tanto los encabezados `x-api-key` como `authorization`. Esto provocó un problema sutil pero grave: los resultados de traducción devolvían con frecuencia contenido irrelevante.
 
 ## Causa raíz
 
@@ -13,24 +13,24 @@ La API de Anthropic admite dos métodos de autenticación:
 | Método | Encabezado | Origen típico | Características |
 |--------|------------|---------------|-----------------|
 | Clave API | `x-api-key: sk-ant-...` | Variable de entorno / Console | Sin estado, cada solicitud es independiente |
-| Token OAuth | `authorization: Bearer sessionToken` | Inicio de sesión con suscripción de Claude Code | Vinculado a la sesión, el servidor mantiene la asociación de contexto |
+| Token OAuth | `authorization: Bearer sessionToken` | Inicio de sesión con suscripción de Codex | Vinculado a la sesión, el servidor mantiene la asociación de contexto |
 
 La diferencia clave: **las claves API son sin estado** — cada solicitud es completamente independiente; mientras que **los tokens de sesión OAuth son con estado** — el servidor de Anthropic asocia las solicitudes que usan el mismo token al mismo contexto de sesión.
 
 ### Cadena de contaminación
 
-Cuando Claude Code utiliza el inicio de sesión OAuth por suscripción, el flujo de autenticación es el siguiente:
+Cuando Codex utiliza el inicio de sesión OAuth por suscripción, el flujo de autenticación es el siguiente:
 
 ```
-Conversación principal de Claude Code ──(authorization: Bearer sessionToken)──→ Anthropic API
+Conversación principal de Codex ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                                   ↑
 Solicitud de traducción de CC-Viewer ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-Dado que las solicitudes de traducción reutilizaban el mismo token de sesión, el servidor de Anthropic podía asociar las solicitudes de traducción con el contexto de la conversación principal de Claude Code. Esto provoca:
+Dado que las solicitudes de traducción reutilizaban el mismo token de sesión, el servidor de Anthropic podía asociar las solicitudes de traducción con el contexto de la conversación principal de Codex. Esto provoca:
 
-1. **Los resultados de traducción se ven influenciados por el contexto de la conversación principal**: El prompt del sistema de la solicitud de traducción es "eres un traductor", pero el contexto del servidor aún contiene el historial de conversación de Claude Code, lo que puede interferir con el modelo
-2. **La conversación principal se ve perturbada por las solicitudes de traducción**: El contenido de las solicitudes de traducción (fragmentos de texto de la interfaz) puede inyectarse en el contexto de la conversación principal, causando que las respuestas de Claude Code se desvíen
+1. **Los resultados de traducción se ven influenciados por el contexto de la conversación principal**: El prompt del sistema de la solicitud de traducción es "eres un traductor", pero el contexto del servidor aún contiene el historial de conversación de Codex, lo que puede interferir con el modelo
+2. **La conversación principal se ve perturbada por las solicitudes de traducción**: El contenido de las solicitudes de traducción (fragmentos de texto de la interfaz) puede inyectarse en el contexto de la conversación principal, causando que las respuestas de Codex se desvíen
 3. **Comportamiento impredecible**: Dado que la contaminación de contexto es un comportamiento del lado del servidor, el cliente no puede detectarlo ni controlarlo
 
 ## Lecciones aprendidas
@@ -41,6 +41,6 @@ Dado que las solicitudes de traducción reutilizaban el mismo token de sesión,
 ## Referencias
 
 - [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/es/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — La Maquina de Deseos Definitiva
+# UltraPlan — The Ultimate Wishing Machine
 
-## Que es UltraPlan
+## What is UltraPlan
 
-UltraPlan es la **implementacion localizada** de cc-viewer del comando nativo `/ultraplan` de Claude Code. Te permite usar las capacidades completas de `/ultraplan` en tu entorno local **sin necesidad de iniciar el servicio remoto oficial de Claude**, guiando a Claude Code para lograr tareas complejas de planificacion e implementacion mediante **colaboracion multi-agente**.
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
-En comparacion con el modo Plan regular o Agent Team, UltraPlan puede:
-- Evaluar automaticamente la complejidad de la tarea y seleccionar la estrategia de planificacion optima
-- Desplegar multiples agentes en paralelo para explorar la base de codigo desde diferentes dimensiones
-- Incorporar investigacion externa (webSearch) sobre mejores practicas de la industria
-- Ensamblar automaticamente un Code Review Team despues de la ejecucion del plan para revision de codigo
-- Formar un ciclo cerrado completo de **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
 
 ---
 
-## Notas Importantes
+## Important Notes
 
-### 1. UltraPlan No Es Omnipotente
-UltraPlan es una maquina de deseos mas poderosa, pero eso no significa que cada deseo pueda cumplirse. Es mas poderoso que Plan y Agent Team, pero no puede directamente "hacerte ganar dinero". Considera una granularidad de tareas razonable — divide los grandes objetivos en tareas medianas ejecutables en lugar de intentar lograrlo todo de una sola vez.
+### 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. Actualmente Mas Efectivo para Proyectos de Programacion
-Las plantillas y flujos de trabajo de UltraPlan estan profundamente optimizados para proyectos de programacion. Otros escenarios (documentacion, analisis de datos, etc.) pueden intentarse, pero es recomendable esperar las adaptaciones en versiones futuras.
+### 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. Tiempo de Ejecucion y Requisitos de Ventana de Contexto
-- Una ejecucion exitosa de UltraPlan normalmente toma **30 minutos o mas**
-- Requiere que el MainAgent tenga una ventana de contexto grande (se recomienda el modelo Opus con 1M de contexto)
-- Si solo tienes un modelo de 200K, **asegurate de ejecutar `/clear` en el contexto antes de comenzar**
-- El `/compact` de Claude Code funciona mal cuando la ventana de contexto es insuficiente — evita quedarte sin espacio
-- Mantener suficiente espacio de contexto es un prerequisito critico para la ejecucion exitosa de 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 tienes preguntas o sugerencias sobre el UltraPlan localizado, no dudes en abrir [Issues en GitHub](https://github.com/anthropics/claude-code/issues) para discutir y colaborar.
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
-## Como Funciona
+## How It Works
 
-UltraPlan ofrece dos modos de operacion:
+UltraPlan offers two operating modes:
 
-### Modo Automatico
-Analiza automaticamente la complejidad de la tarea (puntuacion 4-12) y enruta a diferentes estrategias:
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| Ruta | Puntuacion | Estrategia |
-|------|------------|------------|
-| Ruta A | 4-6 | Planificacion ligera con exploracion directa de codigo |
-| Ruta B | 7-9 | Planificacion con diagramas estructurales (Mermaid / ASCII) |
-| Ruta C | 10-12 | Exploracion multi-agente + ciclo cerrado de revision |
+| 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 |
 
-### Modo Forzado
-Activa directamente el flujo de trabajo multi-agente completo de Ruta C:
-1. Desplegar hasta 5 agentes en paralelo para explorar la base de codigo simultaneamente (arquitectura, identificacion de archivos, evaluacion de riesgos, etc.)
-2. Opcionalmente desplegar un agente de investigacion para indagar soluciones de la industria mediante webSearch
-3. Sintetizar todos los hallazgos de los agentes en un plan de implementacion detallado
-4. Desplegar un agente de revision para examinar el plan desde multiples perspectivas
-5. Ejecutar el plan una vez aprobado
-6. Ensamblar automaticamente un Code Review Team para validar la calidad del codigo despues de la implementacion
+### 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/fr/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Contexte
 
-Le MainAgent de Claude Code utilise un mécanisme d'envoi de contexte complet — chaque requête inclut l'historique complet de la conversation, le system prompt, les définitions d'outils, etc. Cela signifie qu'au fur et à mesure que la conversation progresse, le corps de la requête devient de plus en plus volumineux, et il est difficile d'identifier rapidement « ce qui a été ajouté dans ce tour » en regardant le Body brut.
+Le MainAgent de Codex utilise un mécanisme d'envoi de contexte complet — chaque requête inclut l'historique complet de la conversation, le system prompt, les définitions d'outils, etc. Cela signifie qu'au fur et à mesure que la conversation progresse, le corps de la requête devient de plus en plus volumineux, et il est difficile d'identifier rapidement « ce qui a été ajouté dans ce tour » en regardant le Body brut.
 
 Body Diff JSON résout exactement ce problème : il compare automatiquement les corps de deux requêtes MainAgent consécutives, extrait la partie incrémentale et vous permet de voir d'un coup d'œil le contenu réellement nouveau dans cette requête.
 
@@ -22,7 +22,7 @@ Body Diff JSON résout exactement ce problème : il compare automatiquement les
 Dans un tour de conversation normal, le Body Diff JSON ne contient généralement que :
 - `messages` : 1~2 nouveaux messages (l'entrée de l'utilisateur + la réponse de l'assistant du tour précédent)
 
-Si vous voyez des changements dans `system`, `tools`, `model` ou d'autres champs dans le diff, cela signifie qu'un changement de configuration a eu lieu dans ce tour, ce qui est souvent aussi la cause de la reconstruction du cache.
+Si vous voyez des changements dans `system`, `tools`, `model` ou d'autres champs dans le diff, cela signifie qu'un changement de configuration a eu lieu dans ce tour.
 
 ## Utilisation
 

package/concepts/fr/BodyFields.md

@@ -1,42 +1,39 @@
-# Champs du corps de la requête (Request Body)
+# Request Body Fields
 
-Description des champs de niveau supérieur du corps de la requête `/v1/messages` de l'API Claude.
+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.
 
-## Liste des champs
+## Field List
 
-| Champ | Type | Description |
+| Field | Type | Description |
 |-------|------|-------------|
-| **model** | string | Nom du modèle à utiliser, par exemple `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Historique des messages de la conversation. Chaque message contient `role` (user/assistant) et `content` (un tableau de blocs tels que texte, image, tool_use, tool_result, etc.) |
-| **system** | array | System prompt. Contient les instructions principales de Codex, les directives d'utilisation des outils, les informations d'environnement, le contenu de CLAUDE.md, etc. Les blocs avec `cache_control` sont soumis au prompt caching |
-| **tools** | array | Liste des définitions d'outils disponibles. Chaque outil contient `name`, `description` et `input_schema` (JSON Schema). MainAgent dispose généralement de plus de 20 outils, tandis que SubAgent n'en a que quelques-uns |
-| **metadata** | object | Métadonnées de la requête, contenant généralement `user_id` pour identifier l'utilisateur |
-| **max_tokens** | number | Nombre maximum de tokens pour une réponse unique du modèle, par exemple `16000`, `64000` |
-| **thinking** | object | Configuration de la réflexion étendue. `type: "enabled"` active le mode de réflexion, `budget_tokens` contrôle la limite de tokens de réflexion |
-| **context_management** | object | Configuration de la gestion du contexte. `truncation: "auto"` permet à Codex de tronquer automatiquement les historiques de messages trop longs |
-| **output_config** | object | Configuration de sortie, comme les paramètres de `format` |
-| **stream** | boolean | Indique si les réponses en streaming sont activées. Codex utilise toujours `true` |
-
-## Structure de messages
-
-Le `content` de chaque message est un tableau de blocs. Les types courants incluent :
-
-- **text** : Contenu en texte brut
-- **tool_use** : Invocation d'outil par le modèle (contient `name`, `input`)
-- **tool_result** : Résultat de l'exécution de l'outil (contient `tool_use_id`, `content`)
-- **image** : Contenu d'image (base64 ou URL)
-- **thinking** : Processus de réflexion du modèle (mode de réflexion étendue)
-
-## Structure de system
-
-Le tableau du system prompt contient généralement :
-
-1. **Instructions principales de l'agent** ("You are Codex...")
-2. **Directives d'utilisation des outils**
-3. **Contenu de CLAUDE.md** (instructions au niveau du projet)
-4. **Rappels de compétences** (skills reminder)
-5. **Informations d'environnement** (OS, shell, état git, etc.) — En fait, Codex dépend fortement de git. Si un projet dispose d'un dépôt git, Codex démontre une meilleure compréhension du projet, y compris la capacité de récupérer les modifications distantes et l'historique des commits pour assister l'analyse
-
-Les blocs marqués avec `cache_control: { type: "ephemeral" }` sont mis en cache par l'API Anthropic pendant 5 minutes. Lorsque le cache est atteint, la facturation se fait en `cache_read_input_tokens` (nettement moins cher que `input_tokens`).
-
-> **Remarque** : Pour les clients spéciaux comme Codex, le serveur Anthropic ne se base pas entièrement sur l'attribut `cache_control` de la requête pour déterminer le comportement de mise en cache. Le serveur applique automatiquement des stratégies de cache à des champs spécifiques (comme le system prompt et les définitions de tools), même lorsque la requête ne contient pas explicitement de marqueurs `cache_control`. Par conséquent, ne soyez pas surpris si vous ne voyez pas cet attribut dans le corps de la requête — le serveur a déjà effectué la mise en cache en coulisses, il n'expose simplement pas cette information au client. C'est un accord tacite entre Codex et 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