cx-viewer 1.0.2 → 1.0.4

package/concepts/pt-BR/Teammate.md

@@ -1,26 +1,26 @@
 # Teammate
 
-## Definicao
+## Definition
 
-Um Teammate e um agent colaborativo no modo Team do Claude Code Agent. Quando o agent principal cria um time com `TeamCreate` e gera teammates usando a ferramenta `Agent`, cada teammate e executado como um processo agent independente, com sua propria janela de contexto e conjunto de ferramentas, comunicando-se com os membros do time atraves 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.
 
-## Diferencas em relacao ao SubAgent
+## Differences from SubAgent
 
-| Caracteristica | Teammate | SubAgent |
-|----------------|----------|----------|
-| Ciclo de vida | Persiste, pode receber multiplas mensagens | Tarefa unica, destruido ao concluir |
-| Comunicacao | SendMessage mensagens bidirecionais | Chamada unidirecional pai->filho, retorna resultado |
-| Contexto | Contexto completo independente, mantido entre turnos | Contexto de tarefa isolado |
-| Modo de colaboracao | Colaboracao em equipe, comunicacao mutua possivel | Estrutura hierarquica, interacao apenas com o agent pai |
-| Tipo de tarefa | Tarefas complexas de multiplas etapas | Tarefas unicas como busca, exploracao |
+| 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 |
 
-## Comportamento
+## Behavior
 
-- Criado pelo agent principal (team lead) atraves da ferramenta `Agent` e atribuido a um `team_name`
-- Compartilha a lista de tarefas via `TaskList` / `TaskGet` / `TaskUpdate`
-- Entra em estado idle apos cada turno de execucao, aguardando novas mensagens para reativacao
-- Pode ser encerrado de forma ordenada 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`
 
-## Descricao do painel de estatisticas
+## Stats Panel Description
 
-O painel de estatisticas do Teammate exibe o numero de chamadas de API para cada teammate. A coluna `Name` contem o nome do teammate (ex.: `reviewer-security`, `reviewer-pipeline`), a coluna `Contagem` indica o numero total de requisicoes de API geradas por aquele 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/pt-BR/ToolsFirst.md

@@ -1,77 +1,71 @@
-# Por que os Tools são listados primeiro?
+# Why Are Tools Listed First?
 
-No painel Context do cc-viewer, **os Tools aparecem antes do System Prompt e dos Messages**. Essa ordenação reflete precisamente a **sequência de prefixo KV-Cache da API da 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.
 
-## Sequência de prefixo KV-Cache
+## Request Context Layout
 
-Quando a API da Anthropic constrói o KV-Cache, ela concatena o contexto em um prefixo nesta **ordem fixa**:
+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)   │
 └─────────────────────────────────────────────────┘
 ```
 
-Isso significa que **os Tools ficam antes do System Prompt, bem no início do prefixo 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.
 
-## Por que os Tools têm maior peso de cache do que System?
+## Why Tools Often Matter Most
 
-Na correspondência de prefixo KV-Cache, **o conteúdo anterior é mais crítico** — qualquer alteração invalida tudo o que vem depois:
+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. **A correspondência de prefixo começa pelo início**: O KV-Cache compara a requisição atual com o prefixo em cache token por token desde o início. No momento em que uma divergência é encontrada, todo o conteúdo subsequente é 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. **Alteração nos Tools = cache inteiro invalidado**: Como os Tools vêm primeiro, qualquer alteração nas definições de tool (mesmo adicionar ou remover um único MCP tool) **quebra o prefixo desde o início absoluto**, invalidando todos os System Prompt e Messages em cache.
+2. **Tool schemas can dominate request size**: MCP and dynamic tools often have detailed JSON Schemas with descriptions, enums, and nested parameters.
 
-3. **Alteração no System = cache de Messages invalidado**: O System Prompt fica no meio, então suas alterações invalidam apenas a porção de Messages que o segue.
+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. **Alteração nos Messages = apenas o final é afetado**: Os Messages ficam no final, então adicionar novos messages invalida apenas um pequeno segmento final — os caches de Tools e System permanecem intactos.
+## Practical Impact
 
-## Impacto prático
-
-| Tipo de alteração | Impacto no cache | Cenário típico |
+| Change Type | Cache Impact | Typical Scenario |
 |-------------|-------------|-----------------|
-| Tool adicionado/removido | **Invalidação completa** | Conexão/desconexão de servidor MCP, ativação/desativação de plugin de IDE |
-| Alteração no System Prompt | Cache de Messages perdido | Edição de CLAUDE.md, injeção de system reminder |
-| Novo message adicionado | Apenas incremento de cauda | Fluxo de conversa normal (o mais comum, o mais barato) |
-
-É por isso que `tools_change` no [CacheRebuild](CacheRebuild.md) tende a ser o motivo de reconstrução mais custoso — ele quebra a cadeia de prefixo bem na frente.
-
-## Por que as definições de ferramentas vêm antes do "cérebro"?
+| 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 |
 
-Do ponto de vista do cache, o fato de Tools estar em primeiro é um fato técnico. Mas do ponto de vista do design cognitivo, essa ordem é igualmente lógica — **Tools são as mãos e os pés, System Prompt é o cérebro**.
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-Antes de agir, uma pessoa precisa perceber quais membros e ferramentas tem disponíveis. Um bebê não entende primeiro as regras do mundo (System) para depois aprender a agarrar — ele primeiro percebe que tem mãos e pés, e gradualmente entende as regras pela interação com o ambiente. Da mesma forma, um LLM precisa saber quais ferramentas pode chamar (ler arquivos, escrever código, pesquisar, executar comandos) antes de receber as instruções da tarefa (System Prompt), para poder avaliar com precisão "o que posso fazer" e "como devo fazer" ao processar as instruções.
+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.
 
-Se fosse invertido — primeiro dizer ao modelo "sua tarefa é refatorar este módulo", depois "você tem as ferramentas Read, Edit, Bash" — o modelo não teria informações cruciais sobre os limites de suas capacidades ao entender a tarefa, potencialmente produzindo planos irrealistas ou negligenciando abordagens disponíveis.
+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.
 
-**Conhecer as cartas que se tem antes de decidir como jogar.** Esta é a lógica cognitiva por trás de Tools preceder 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 que as ferramentas MCP também estão nesta posição?
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-Ferramentas MCP (Model Context Protocol), assim como ferramentas integradas, são posicionadas no início da área Tools. Entender a posição do MCP no contexto ajuda a avaliar seus reais benefícios e custos.
+## Why Are MCP Tools Also in This Position?
 
-### Vantagens do 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.
 
-- **Extensão de capacidades**: MCP permite que modelos acessem serviços externos (consultas a bancos de dados, chamadas API, operações IDE, controle de navegador, etc.), ultrapassando os limites das ferramentas integradas
-- **Ecossistema aberto**: Qualquer pessoa pode implementar um servidor MCP; o modelo ganha novas capacidades sem retreinamento
-- **Carregamento sob demanda**: Servidores MCP podem ser conectados/desconectados seletivamente conforme o cenário, compondo conjuntos de ferramentas flexíveis
+### MCP Advantages
 
-### Custos do 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
 
-- **Assassino de cache**: A definição JSON Schema de cada ferramenta MCP é concatenada no início do prefixo KV-Cache. Adicionar ou remover uma ferramenta MCP = **todo o cache invalidado desde o início**. Conectar/desconectar servidores MCP com frequência reduz drasticamente a taxa de acerto do cache
-- **Inchaço do prefixo**: Schemas de ferramentas MCP são tipicamente maiores que ferramentas integradas (descrições detalhadas de parâmetros, valores enum, etc.). Muitas ferramentas MCP aumentam significativamente a contagem de tokens na área Tools, reduzindo o espaço de contexto disponível para Messages
-- **Overhead de latência**: Chamadas de ferramentas MCP requerem comunicação entre processos (JSON-RPC via stdio/SSE), uma ordem de magnitude mais lenta que chamadas de funções integradas
-- **Risco de estabilidade**: Servidores MCP são processos externos que podem falhar, expirar ou retornar formatos inesperados, necessitando tratamento de erros 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
 
-### Recomendações práticas
+### Practical Recommendations
 
-| Cenário | Recomendação |
-|---------|-------------|
-| Conversas longas, interação frequente | Minimizar a quantidade de ferramentas MCP para proteger a estabilidade do prefixo de cache |
-| Tarefas curtas, operações pontuais | Usar ferramentas MCP livremente; impacto no cache é limitado |
-| Adição/remoção frequente de servidores MCP | Cada mudança dispara reconstrução completa do cache; considerar fixar o conjunto de ferramentas |
-| Schemas de ferramentas superdimensionados | Reduzir descriptions e enums para diminuir o consumo de tokens no prefixo |
+| 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 |
 
-No painel Context do cc-viewer, ferramentas MCP são exibidas ao lado das ferramentas integradas na área Tools, oferecendo uma visão clara do tamanho do Schema de cada ferramenta e sua contribuição para o prefixo 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/pt-BR/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## Contexto
 
-O CC-Viewer inclui um recurso de tradução integrado (`POST /api/translate`) alimentado pela Anthropic Messages API. Na implementação inicial, as requisições de tradução reutilizavam credenciais de autenticação em cache da sessão do Claude Code — incluindo os cabeçalhos `x-api-key` e `authorization`. Isso causou um problema sutil, mas grave: os resultados da tradução frequentemente retornavam conteúdo irrelevante.
+O CC-Viewer inclui um recurso de tradução integrado (`POST /api/translate`) alimentado pela Anthropic Messages API. Na implementação inicial, as requisições de tradução reutilizavam credenciais de autenticação em cache da sessão do Codex — incluindo os cabeçalhos `x-api-key` e `authorization`. Isso causou um problema sutil, mas grave: os resultados da tradução frequentemente retornavam conteúdo irrelevante.
 
 ## Causa Raiz
 
@@ -13,24 +13,24 @@ A Anthropic API suporta dois métodos de autenticação:
 | Método | Cabeçalho | Origem típica | Características |
 |--------|-----------|---------------|-----------------|
 | Chave de API | `x-api-key: sk-ant-...` | Variável de ambiente / Console | Sem estado, cada requisição é independente |
-| Token OAuth | `authorization: Bearer sessionToken` | Login por assinatura do Claude Code | Vinculado à sessão, o servidor mantém associação de contexto |
+| Token OAuth | `authorization: Bearer sessionToken` | Login por assinatura do Codex | Vinculado à sessão, o servidor mantém associação de contexto |
 
 A diferença fundamental: **Chaves de API são sem estado** — cada requisição é completamente independente; enquanto **tokens de sessão OAuth são com estado** — o servidor da Anthropic associa requisições que usam o mesmo token ao mesmo contexto de sessão.
 
 ### Cadeia de poluição
 
-Quando o Claude Code usa login OAuth por assinatura, o fluxo de autenticação é assim:
+Quando o Codex usa login OAuth por assinatura, o fluxo de autenticação é assim:
 
 ```
-Conversa principal do Claude Code ──(authorization: Bearer sessionToken)──→ Anthropic API
+Conversa principal do Codex ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                               ↑
 Requisição de tradução do CC-Viewer ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-Como as requisições de tradução reutilizavam o mesmo token de sessão, o servidor da Anthropic pode associar as requisições de tradução ao contexto da conversa principal do Claude Code. Isso causa:
+Como as requisições de tradução reutilizavam o mesmo token de sessão, o servidor da Anthropic pode associar as requisições de tradução ao contexto da conversa principal do Codex. Isso causa:
 
-1. **Resultados de tradução influenciados pelo contexto da conversa principal**: O prompt de sistema da requisição de tradução é "você é um tradutor", mas o contexto do servidor ainda contém o histórico de conversas do Claude Code, potencialmente interferindo no modelo
-2. **Conversa principal perturbada pelas requisições de tradução**: O conteúdo das requisições de tradução (fragmentos de texto da UI) pode ser injetado no contexto da conversa principal, fazendo com que as respostas do Claude Code desviem
+1. **Resultados de tradução influenciados pelo contexto da conversa principal**: O prompt de sistema da requisição de tradução é "você é um tradutor", mas o contexto do servidor ainda contém o histórico de conversas do Codex, potencialmente interferindo no modelo
+2. **Conversa principal perturbada pelas requisições de tradução**: O conteúdo das requisições de tradução (fragmentos de texto da UI) pode ser injetado no contexto da conversa principal, fazendo com que as respostas do Codex desviem
 3. **Comportamento imprevisível**: Como a poluição de contexto é um comportamento do lado do servidor, o cliente não pode detectá-la ou controlá-la
 
 ## Lições Aprendidas
@@ -41,6 +41,6 @@ Como as requisições de tradução reutilizavam o mesmo token de sessão, o ser
 ## Referências
 
 - [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/pt-BR/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — A Máquina de Desejos Definitiva
+# UltraPlan — The Ultimate Wishing Machine
 
-## O que é UltraPlan
+## What is UltraPlan
 
-UltraPlan é a **implementação localizada** do cc-viewer para o comando nativo `/ultraplan` do Claude Code. Ele permite que você use todas as capacidades do `/ultraplan` em seu ambiente local **sem precisar iniciar o serviço remoto oficial do Claude**, guiando o Claude Code para realizar tarefas complexas de planejamento e implementação usando **colaboração multiagente**.
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
-Comparado ao modo Plan regular ou Agent Team, o UltraPlan pode:
-- Avaliar automaticamente a complexidade da tarefa e selecionar a estratégia de planejamento ideal
-- Implantar múltiplos agentes paralelos para explorar a base de código a partir de diferentes dimensões
-- Incorporar pesquisa externa (webSearch) para melhores práticas do setor
-- Montar automaticamente uma Equipe de Code Review após a execução do plano para revisão de código
-- Formar um ciclo fechado completo **Planejar → Executar → Revisar → Corrigir**
+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 não é onipotente
-O UltraPlan é uma máquina de desejos mais poderosa, mas isso não significa que todo desejo pode ser realizado. Ele é mais poderoso que o Plan e o Agent Team, mas não pode diretamente "fazer você ganhar dinheiro". Considere uma granularidade de tarefas razoável — divida grandes objetivos em tarefas de tamanho médio executáveis em vez de tentar realizar tudo de uma 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. Atualmente mais eficaz para projetos de programação
-Os modelos e fluxos de trabalho do UltraPlan são profundamente otimizados para projetos de programação. Outros cenários (documentação, análise de dados, etc.) podem ser tentados, mas você pode querer aguardar adaptações em versões 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. Tempo de execução e requisitos de janela de contexto
-- Uma execução bem-sucedida do UltraPlan normalmente leva **30 minutos ou mais**
-- Requer que o MainAgent tenha uma janela de contexto grande (modelo Opus com contexto 1M recomendado)
-- Se você tem apenas um modelo de 200K, **certifique-se de executar `/clear` no contexto antes de rodar**
-- O `/compact` do Claude Code tem desempenho ruim quando a janela de contexto é insuficiente — evite ficar sem espaço
-- Manter espaço de contexto suficiente é um pré-requisito crítico para a execução bem-sucedida do 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
 
-Se você tiver dúvidas ou sugestões sobre o UltraPlan localizado, fique à vontade para abrir [Issues no GitHub](https://github.com/anthropics/claude-code/issues) para discutir e 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
 
-O UltraPlan oferece dois modos de operação:
+UltraPlan offers two operating modes:
 
-### Modo Automático
-Analisa automaticamente a complexidade da tarefa (pontuação 4-12) e direciona para diferentes estratégias:
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| Rota | Pontuação | Estratégia |
-|------|-----------|------------|
-| Rota A | 4-6 | Planejamento leve com exploração direta de código |
-| Rota B | 7-9 | Planejamento com diagramas estruturais (Mermaid / ASCII) |
-| Rota C | 10-12 | Exploração multiagente + ciclo fechado de revisão |
+| 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 Forçado
-Ativa diretamente o fluxo de trabalho multiagente completo da Rota C:
-1. Implantar até 5 agentes paralelos para explorar a base de código simultaneamente (arquitetura, identificação de arquivos, avaliação de riscos, etc.)
-2. Opcionalmente implantar um agente de pesquisa para investigar soluções do setor via webSearch
-3. Sintetizar todas as descobertas dos agentes em um plano de implementação detalhado
-4. Implantar um agente de revisão para examinar o plano de múltiplas perspectivas
-5. Executar o plano após aprovação
-6. Montar automaticamente uma Equipe de Code Review para validar a qualidade do código após a implementação
+### 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/ru/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Контекст
 
-MainAgent в Claude Code использует механизм отправки полного контекста — каждый запрос содержит полную историю диалога, system prompt, определения инструментов и т.д. Это означает, что по мере продвижения диалога тело запроса становится всё больше, и при просмотре сырого Body сложно быстро определить, «что именно было добавлено в этом раунде».
+MainAgent в Codex использует механизм отправки полного контекста — каждый запрос содержит полную историю диалога, system prompt, определения инструментов и т.д. Это означает, что по мере продвижения диалога тело запроса становится всё больше, и при просмотре сырого Body сложно быстро определить, «что именно было добавлено в этом раунде».
 
 Body Diff JSON решает именно эту проблему: он автоматически сравнивает тела двух последовательных запросов MainAgent, извлекает инкрементную часть и позволяет сразу увидеть, что фактически было добавлено в текущем запросе.
 

package/concepts/ru/BodyFields.md

@@ -1,42 +1,39 @@
-# Описание полей Request Body
+# Request Body Fields
 
-Описание полей верхнего уровня тела запроса Claude API `/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.
 
-## Список полей
+## Field List
 
-| Поле | Тип | Описание |
-|------|------|------|
-| **model** | string | Название используемой модели, например `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | История сообщений диалога. Каждое сообщение содержит `role` (user/assistant) и `content` (массив блоков: текст, изображения, tool_use, tool_result и др.) |
-| **system** | array | System prompt. Содержит основные инструкции Codex, описание использования инструментов, информацию об окружении, содержимое CLAUDE.md и т.д. Блоки с `cache_control` кэшируются через prompt caching |
-| **tools** | array | Список определений доступных инструментов. Каждый инструмент содержит `name`, `description` и `input_schema` (JSON Schema). MainAgent обычно имеет более 20 инструментов, SubAgent — лишь несколько |
-| **metadata** | object | Метаданные запроса, обычно содержащие `user_id` для идентификации пользователя |
-| **max_tokens** | number | Максимальное количество токенов в одном ответе модели, например `16000`, `64000` |
-| **thinking** | object | Конфигурация расширенного мышления. `type: "enabled"` включает режим мышления, `budget_tokens` управляет верхним пределом токенов мышления |
-| **context_management** | object | Конфигурация управления контекстом. `truncation: "auto"` позволяет Codex автоматически усекать слишком длинную историю сообщений |
-| **output_config** | object | Конфигурация вывода, например настройка `format` |
-| **stream** | boolean | Включить ли потоковый ответ. Codex всегда использует `true` |
+| Field | Type | Description |
+|-------|------|-------------|
+| **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 |
 
-## Структура messages
+## input Structure
 
-`content` каждого сообщения — это массив блоков, распространённые типы:
+When `input` is an array, each input item usually contains `role` and `content`. `content` can be an array of blocks. Common types include:
 
-- **text**: обычное текстовое содержимое
-- **tool_use**: вызов инструмента моделью (содержит `name`, `input`)
-- **tool_result**: результат выполнения инструмента (содержит `tool_use_id`, `content`)
-- **image**: изображение (base64 или URL)
-- **thinking**: процесс мышления модели (режим расширенного мышления)
+- **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)
 
-## Структура system
+## instructions Structure
 
-Массив system prompt обычно содержит:
+`instructions` typically contains:
 
-1. **Основные инструкции агента** ("You are Codex...")
-2. **Правила использования инструментов**
-3. **Содержимое CLAUDE.md** (инструкции на уровне проекта)
-4. **Подсказки навыков** (skills reminder)
-5. **Информация об окружении** (ОС, shell, статус git и т.д.) — фактически Codex сильно зависит от git. Если в проекте есть git-репозиторий, Codex демонстрирует лучшее понимание проекта, включая возможность извлекать удалённые изменения и историю коммитов для вспомогательного анализа
-
-Блоки, помеченные `cache_control: { type: "ephemeral" }`, кэшируются Anthropic API на 5 минут; при попадании в кэш тарификация идёт по `cache_read_input_tokens` (значительно дешевле, чем `input_tokens`).
-
-> **Примечание**: для таких специальных клиентов, как Codex, серверная сторона Anthropic фактически не полностью полагается на атрибут `cache_control` в запросе для определения поведения кэширования. Сервер автоматически применяет политику кэширования к определённым полям (таким как system prompt, определения инструментов), даже если запрос не содержит явной метки `cache_control`. Поэтому, если вы не видите этот атрибут в теле запроса, не стоит удивляться — сервер уже выполнил кэширование за кулисами, просто не раскрывая эту информацию клиенту. Это своего рода негласное соглашение между Codex и Anthropic API.
+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