cx-viewer 1.0.3 → 1.0.4

package/concepts/ru/Teammate.md

@@ -1,26 +1,26 @@
 # Teammate
 
-## Определение
+## Definition
 
-Teammate — это совместно работающий agent в режиме Team Claude Code Agent. Когда основной agent создаёт команду через `TeamCreate` и генерирует teammate с помощью инструмента `Agent`, каждый teammate запускается как независимый процесс agent с собственным контекстным окном и набором инструментов, взаимодействуя с членами команды через `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.
 
-## Отличия от SubAgent
+## Differences from SubAgent
 
-| Характеристика | Teammate | SubAgent |
-|------|----------|----------|
-| Жизненный цикл | Существует постоянно, может получать несколько сообщений | Одноразовая задача, уничтожается после завершения |
-| Способ коммуникации | Двусторонние сообщения через SendMessage | Однонаправленный вызов родитель→потомок, возврат результата |
-| Контекст | Независимый полный контекст, сохраняется между ходами | Изолированный контекст задачи |
-| Модель взаимодействия | Командная работа, взаимная коммуникация | Иерархическая структура, взаимодействие только с родительским agent |
-| Тип задач | Сложные многоэтапные задачи | Одиночные задачи: поиск, исследование и т.д. |
+| 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 |
 
-## Поведение
+## Behavior
 
-- Создаётся основным agent (team lead) через инструмент `Agent` с назначением `team_name`
-- Совместное использование списка задач через `TaskList` / `TaskGet` / `TaskUpdate`
-- После завершения каждого хода переходит в состояние idle, ожидая пробуждения новым сообщением
-- Может быть корректно завершён через `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`
 
-## Описание панели статистики
+## Stats Panel Description
 
-Панель статистики Teammate отображает количество API-вызовов каждого teammate. Столбец `Name` содержит имя teammate (например, `reviewer-security`, `reviewer-pipeline`), столбец `Кол-во` — общее число API-запросов, сгенерированных данным 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/ru/ToolsFirst.md

@@ -1,77 +1,71 @@
-# Почему Tools перечислены первыми?
+# Why Are Tools Listed First?
 
-В панели Context в cc-viewer **Tools отображаются раньше System Prompt и Messages**. Этот порядок точно отражает **последовательность префикса KV-Cache 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.
 
-## Последовательность префикса KV-Cache
+## Request Context Layout
 
-Когда API Anthropic формирует KV-Cache, он объединяет контекст в префикс в следующем **фиксированном порядке**:
+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)   │
 └─────────────────────────────────────────────────┘
 ```
 
-Это означает, что **Tools находятся перед System Prompt, в самом начале префикса кэша**.
+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.
 
-## Почему Tools имеют больший вес в кэше, чем System?
+## Why Tools Often Matter Most
 
-При сопоставлении префиксов KV-Cache **более ранний контент является более критичным** — любое изменение делает недействительным всё, что следует после:
+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. **Сопоставление префикса начинается с самого начала**: KV-Cache сравнивает текущий запрос с кэшированным префиксом token за token с начала. Как только обнаруживается несоответствие, весь последующий контент становится недействительным.
+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. **Изменение Tools = весь кэш недействителен**: Поскольку Tools стоят первыми, любое изменение определений tool (даже добавление или удаление одного MCP tool) **нарушает префикс с самого начала**, делая недействительными все кэшированные System Prompt и Messages.
+2. **Tool schemas can dominate request size**: MCP and dynamic tools often have detailed JSON Schemas with descriptions, enums, and nested parameters.
 
-3. **Изменение System = кэш Messages недействителен**: System Prompt находится посередине, поэтому его изменения делают недействительной только следующую за ним часть Messages.
+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. **Изменение Messages = затронут только хвост**: Messages находятся в конце, поэтому добавление новых messages делает недействительным лишь небольшой хвостовой сегмент — кэши Tools и System остаются нетронутыми.
+## Practical Impact
 
-## Практическое влияние
-
-| Тип изменения | Влияние на кэш | Типичный сценарий |
+| Change Type | Cache Impact | Typical Scenario |
 |-------------|-------------|-----------------|
-| Tool добавлен/удалён | **Полная инвалидация** | Подключение/отключение сервера MCP, включение/выключение плагина IDE |
-| Изменение System Prompt | Кэш Messages утерян | Редактирование CLAUDE.md, внедрение system reminder |
-| Добавлено новое message | Только хвостовой инкремент | Обычный ход разговора (самый частый, самый дешёвый) |
-
-Вот почему `tools_change` в [CacheRebuild](CacheRebuild.md) как правило является наиболее дорогостоящей причиной перестройки — она нарушает цепочку префикса с самого начала.
-
-## Почему определения инструментов размещаются перед «мозгом»?
+| 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 |
 
-С точки зрения кэширования, размещение Tools на первом месте — это технический факт. Но с точки зрения когнитивного дизайна этот порядок также логичен — **Tools — это руки и ноги, System Prompt — это мозг**.
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-Перед тем как действовать, человеку нужно осознать, какие конечности и инструменты ему доступны. Младенец не сначала понимает правила мира (System), а потом учится хватать — он сначала ощущает, что у него есть руки и ноги, а затем постепенно понимает правила через взаимодействие с окружающей средой. Аналогично, LLM должна знать, какие инструменты она может вызвать (чтение файлов, написание кода, поиск, выполнение команд) до получения инструкций (System Prompt), чтобы точно оценить «что я могу сделать» и «как мне это сделать» при обработке инструкций.
+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.
 
-Если бы порядок был обратным — сначала сказать модели «твоя задача — рефакторить этот модуль», потом «у тебя есть инструменты Read, Edit, Bash» — модели не хватало бы критической информации о границах своих возможностей при понимании задачи, что могло бы привести к нереалистичным планам или упущению доступных подходов.
+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.
 
-**Узнай, какие карты на руках, прежде чем решать, как играть.** Это когнитивная логика размещения Tools перед 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.
 
-## Почему инструменты MCP тоже находятся на этой позиции?
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-Инструменты MCP (Model Context Protocol), как и встроенные инструменты, размещаются в самом начале области Tools. Понимание позиции MCP в контексте помогает оценить его реальные преимущества и издержки.
+## Why Are MCP Tools Also in This Position?
 
-### Преимущества 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.
 
-- **Расширение возможностей**: MCP позволяет моделям обращаться к внешним сервисам (запросы к базам данных, API-вызовы, операции IDE, управление браузером и т.д.), выходя за границы встроенных инструментов
-- **Открытая экосистема**: Любой может реализовать MCP-сервер; модель получает новые возможности без переобучения
-- **Загрузка по требованию**: MCP-серверы можно подключать/отключать выборочно в зависимости от задачи, гибко составляя наборы инструментов
+### MCP Advantages
 
-### Издержки 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
 
-- **Убийца кэша**: JSON Schema каждого MCP-инструмента конкатенируется в самое начало префикса KV-Cache. Добавление или удаление одного MCP-инструмента = **весь кэш инвалидируется с самого начала**. Частое подключение/отключение MCP-серверов резко снижает процент попаданий в кэш
-- **Раздувание префикса**: Schemas MCP-инструментов обычно больше встроенных (подробные описания параметров, перечисления и т.д.). Большое количество MCP-инструментов значительно увеличивает количество токенов в области Tools, сокращая пространство контекста для Messages
-- **Накладные расходы на задержку**: Вызовы MCP-инструментов требуют межпроцессного взаимодействия (JSON-RPC через stdio/SSE), на порядок медленнее вызовов встроенных функций
-- **Риск стабильности**: MCP-серверы — это внешние процессы, которые могут аварийно завершиться, вызвать таймаут или вернуть неожиданный формат, требуя дополнительной обработки ошибок
+### 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
 
-### Практические рекомендации
+### Practical Recommendations
 
-| Сценарий | Рекомендация |
-|----------|-------------|
-| Длинные разговоры, частое взаимодействие | Минимизировать количество MCP-инструментов для защиты стабильности префикса кэша |
-| Короткие задачи, разовые операции | Свободно использовать MCP-инструменты; влияние на кэш ограничено |
-| Частое добавление/удаление MCP-серверов | Каждое изменение вызывает полную перестройку кэша; рассмотреть фиксацию набора инструментов |
-| Слишком большие Tool Schemas | Сократить описания и enum для уменьшения расхода токенов префикса |
+| 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 |
 
-В панели Context cc-viewer инструменты MCP отображаются рядом со встроенными инструментами в области Tools, давая наглядное представление о размере Schema каждого инструмента и его вкладе в префикс кэша.
+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/ru/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## Предыстория
 
-CC-Viewer включает встроенную функцию перевода (`POST /api/translate`), работающую на основе Anthropic Messages API. В ранней реализации запросы на перевод повторно использовали кэшированные учётные данные аутентификации из сессии Claude Code — включая заголовки `x-api-key` и `authorization`. Это вызывало неочевидную, но серьёзную проблему: результаты перевода часто возвращали нерелевантное содержимое.
+CC-Viewer включает встроенную функцию перевода (`POST /api/translate`), работающую на основе Anthropic Messages API. В ранней реализации запросы на перевод повторно использовали кэшированные учётные данные аутентификации из сессии Codex — включая заголовки `x-api-key` и `authorization`. Это вызывало неочевидную, но серьёзную проблему: результаты перевода часто возвращали нерелевантное содержимое.
 
 ## Корневая причина
 
@@ -13,24 +13,24 @@ Anthropic API поддерживает два метода аутентифик
 | Метод | Заголовок | Типичный источник | Характеристики |
 |-------|-----------|-------------------|----------------|
 | API-ключ | `x-api-key: sk-ant-...` | Переменная окружения / Console | Без состояния, каждый запрос независим |
-| OAuth-токен | `authorization: Bearer sessionToken` | Вход по подписке Claude Code | Привязан к сессии, сервер поддерживает ассоциацию контекста |
+| OAuth-токен | `authorization: Bearer sessionToken` | Вход по подписке Codex | Привязан к сессии, сервер поддерживает ассоциацию контекста |
 
 Ключевое различие: **API-ключи не хранят состояние** — каждый запрос полностью независим; тогда как **OAuth-токены сессии хранят состояние** — сервер Anthropic ассоциирует запросы с одним и тем же токеном с одним и тем же контекстом сессии.
 
 ### Цепочка загрязнения
 
-Когда Claude Code использует OAuth-вход по подписке, поток аутентификации выглядит так:
+Когда Codex использует OAuth-вход по подписке, поток аутентификации выглядит так:
 
 ```
-Основной диалог Claude Code ──(authorization: Bearer sessionToken)──→ Anthropic API
+Основной диалог Codex ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                         ↑
 Запрос перевода CC-Viewer ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-Поскольку запросы на перевод повторно использовали тот же токен сессии, сервер Anthropic может ассоциировать запросы на перевод с контекстом основного диалога Claude Code. Это приводит к:
+Поскольку запросы на перевод повторно использовали тот же токен сессии, сервер Anthropic может ассоциировать запросы на перевод с контекстом основного диалога Codex. Это приводит к:
 
-1. **Результаты перевода под влиянием контекста основного диалога**: Системный промпт запроса на перевод — «вы переводчик», но серверный контекст всё ещё содержит историю диалогов Claude Code, что может влиять на модель
-2. **Основной диалог нарушается запросами на перевод**: Содержимое запросов на перевод (фрагменты текста UI) может быть внедрено в контекст основного диалога, вызывая отклонения в ответах Claude Code
+1. **Результаты перевода под влиянием контекста основного диалога**: Системный промпт запроса на перевод — «вы переводчик», но серверный контекст всё ещё содержит историю диалогов Codex, что может влиять на модель
+2. **Основной диалог нарушается запросами на перевод**: Содержимое запросов на перевод (фрагменты текста UI) может быть внедрено в контекст основного диалога, вызывая отклонения в ответах Codex
 3. **Непредсказуемое поведение**: Поскольку загрязнение контекста — это поведение на стороне сервера, клиент не может его обнаружить или контролировать
 
 ## Извлечённые уроки
@@ -41,6 +41,6 @@ Anthropic API поддерживает два метода аутентифик
 ## Ссылки
 
 - [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/ru/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — Идеальная Машина Желаний
+# UltraPlan — The Ultimate Wishing Machine
 
-## Что такое UltraPlan
+## What is UltraPlan
 
-UltraPlan — это **локализованная реализация** нативной команды `/ultraplan` Claude Code от cc-viewer. Он позволяет использовать полные возможности `/ultraplan` в вашем локальном окружении **без необходимости запуска официального удалённого сервиса Claude**, направляя Claude Code на выполнение сложных задач планирования и реализации с использованием **мультиагентного взаимодействия**.
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
-По сравнению с обычным режимом Plan или Agent Team, UltraPlan способен:
-- Автоматически оценивать сложность задачи и выбирать оптимальную стратегию планирования
-- Развёртывать несколько параллельных агентов для исследования кодовой базы с разных сторон
-- Использовать внешние исследования (webSearch) для получения лучших отраслевых практик
-- Автоматически формировать команду Code Review после выполнения плана для ревью кода
-- Создавать полный замкнутый цикл **План → Выполнение → Ревью → Исправление**
+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
 
 ---
 
-## Важные замечания
+## Important Notes
 
-### 1. UltraPlan не всемогущ
-UltraPlan — это более мощная машина желаний, но это не значит, что каждое желание может быть исполнено. Он мощнее, чем Plan и Agent Team, но не может напрямую «заработать вам деньги». Учитывайте разумную гранулярность задач — разбивайте большие цели на выполнимые задачи среднего размера, а не пытайтесь достичь всего за один раз.
+### 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. В настоящее время наиболее эффективен для программных проектов
-Шаблоны и рабочие процессы UltraPlan глубоко оптимизированы для программных проектов. Другие сценарии (документация, анализ данных и т.д.) можно попробовать, но возможно стоит подождать адаптации в будущих версиях.
+### 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. Время выполнения и требования к контекстному окну
-- Успешный запуск UltraPlan обычно занимает **30 минут или более**
-- Требует, чтобы MainAgent имел большое контекстное окно (рекомендуется модель Opus с контекстом 1M)
-- Если у вас только модель на 200K, **обязательно выполните `/clear` контекста перед запуском**
-- Команда `/compact` Claude Code работает плохо при недостаточном контекстном окне — не допускайте исчерпания пространства
-- Поддержание достаточного пространства контекста является критически важным условием для успешного выполнения 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
 
-Если у вас есть вопросы или предложения по локализованному UltraPlan, не стесняйтесь открывать [Issues на GitHub](https://github.com/anthropics/claude-code/issues) для обсуждения и сотрудничества.
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
-## Как это работает
+## How It Works
 
-UltraPlan предлагает два режима работы:
+UltraPlan offers two operating modes:
 
-### Автоматический режим
-Автоматически анализирует сложность задачи (оценка 4-12) и направляет к различным стратегиям:
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| Маршрут | Оценка | Стратегия |
-|---------|--------|-----------|
-| Маршрут A | 4-6 | Лёгкое планирование с прямым исследованием кода |
-| Маршрут B | 7-9 | Планирование со структурными диаграммами (Mermaid / ASCII) |
-| Маршрут C | 10-12 | Мультиагентное исследование + замкнутый цикл ревью |
+| 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 |
 
-### Принудительный режим
-Напрямую активирует полный мультиагентный рабочий процесс Маршрута C:
-1. Развёртывание до 5 параллельных агентов для одновременного исследования кодовой базы (архитектура, идентификация файлов, оценка рисков и т.д.)
-2. Опциональное развёртывание исследовательского агента для изучения отраслевых решений через webSearch
-3. Синтез всех результатов агентов в детальный план реализации
-4. Развёртывание агента-ревьюера для тщательной проверки плана с нескольких точек зрения
-5. Выполнение плана после одобрения
-6. Автоматическое формирование команды Code Review для проверки качества кода после реализации
+### 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/th/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## ภูมิหลัง
 
-MainAgent ของ Claude Code ใช้กลไกการส่งบริบทแบบเต็ม — ทุกคำร้องขอจะมีประวัติการสนทนาทั้งหมด, system prompt, คำจำกัดความเครื่องมือ ฯลฯ ซึ่งหมายความว่าเมื่อการสนทนาดำเนินไป เนื้อหาคำร้องขอจะใหญ่ขึ้นเรื่อยๆ การดู Body ดิบโดยตรงจึงยากที่จะระบุได้อย่างรวดเร็วว่า "รอบนี้เพิ่มอะไรมาบ้าง"
+MainAgent ของ Codex ใช้กลไกการส่งบริบทแบบเต็ม — ทุกคำร้องขอจะมีประวัติการสนทนาทั้งหมด, system prompt, คำจำกัดความเครื่องมือ ฯลฯ ซึ่งหมายความว่าเมื่อการสนทนาดำเนินไป เนื้อหาคำร้องขอจะใหญ่ขึ้นเรื่อยๆ การดู Body ดิบโดยตรงจึงยากที่จะระบุได้อย่างรวดเร็วว่า "รอบนี้เพิ่มอะไรมาบ้าง"
 
 Body Diff JSON ถูกสร้างขึ้นเพื่อแก้ปัญหานี้: มันเปรียบเทียบ body ของคำร้องขอ MainAgent สองรายการที่ต่อเนื่องกันโดยอัตโนมัติ สกัดส่วนที่เพิ่มขึ้น ให้คุณเห็นเนื้อหาที่เพิ่มจริงในคำร้องขอนี้ได้ทันที
 

package/concepts/th/BodyFields.md

@@ -1,42 +1,39 @@
-# คำอธิบายฟิลด์ Request Body
+# Request Body Fields
 
-คำอธิบายฟิลด์ระดับบนสุดของ request body สำหรับ `/v1/messages` ของ Claude API
+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. **ข้อมูลสภาพแวดล้อม** (OS, shell, สถานะ git ฯลฯ) — ในความเป็นจริง Codex พึ่งพา git เป็นอย่างมาก หากโปรเจกต์มี git repository Codex สามารถแสดงความเข้าใจโปรเจกต์ได้ดีขึ้น รวมถึงสามารถดึงการเปลี่ยนแปลงจากรีโมตและบันทึกคอมมิตมาช่วยในการวิเคราะห์
-
-บล็อกที่ทำเครื่องหมายด้วย `cache_control: { type: "ephemeral" }` จะถูกแคชโดย Anthropic API เป็นเวลา 5 นาที เมื่อแคชถูกเรียกใช้จะคิดค่าใช้จ่ายเป็น `cache_read_input_tokens` (ต่ำกว่า `input_tokens` มาก)
-
-> **หมายเหตุ**: สำหรับไคลเอ็นต์พิเศษอย่าง Codex เซิร์ฟเวอร์ของ Anthropic ไม่ได้พึ่งพาคุณสมบัติ `cache_control` ในคำขอทั้งหมดเพื่อกำหนดพฤติกรรมการแคช เซิร์ฟเวอร์จะดำเนินนโยบายการแคชโดยอัตโนมัติสำหรับฟิลด์เฉพาะ (เช่น system prompt, คำจำกัดความเครื่องมือ) แม้ว่าคำขอจะไม่มีเครื่องหมาย `cache_control` อย่างชัดเจน ดังนั้น เมื่อคุณไม่เห็นคุณสมบัตินี้ใน request body ไม่ต้องแปลกใจ เซิร์ฟเวอร์ได้ดำเนินการแคชเบื้องหลังแล้ว เพียงแต่ไม่ได้เปิดเผยข้อมูลนี้ให้ไคลเอ็นต์ทราบ นี่คือความเข้าใจโดยปริยายระหว่าง 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