cx-viewer 1.0.3 → 1.0.4

package/concepts/ko/Teammate.md

@@ -1,26 +1,26 @@
 # Teammate
 
-## 정의
+## Definition
 
-Teammate는 Claude Code Agent Team 모드에서의 협업 agent입니다. 메인 agent가 `TeamCreate`로 팀을 생성하고 `Agent` 도구로 teammate를 생성하면, 각 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 통계 패널은 각 teammate의 API 호출 횟수를 표시합니다. `Name` 열은 teammate 이름(예: `reviewer-security`, `reviewer-pipeline`)이며, `횟수` 열은 해당 teammate가 발생시킨 API 요청 총 수입니다.
+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/ko/ToolsFirst.md

@@ -1,77 +1,71 @@
-# Tools가 왜 먼저 나열되는가?
+# Why Are Tools Listed First?
 
-cc-viewer의 Context 패널에서 **Tools는 System Prompt와 Messages보다 앞에 표시됩니다**. 이 순서는 **Anthropic API의 KV-Cache 프리픽스 시퀀스**를 정확히 반영한 것입니다.
+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
 
-Anthropic의 API가 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 단위로 비교합니다. 불일치가 발견되는 순간, 이후의 모든 콘텐츠가 무효화됩니다.
+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는 마지막에 있으므로, 새로운 message 추가는 작은 끝부분 세그먼트만 무효화합니다 — Tools와 System 캐시는 그대로 유지됩니다.
+## Practical Impact
 
-## 실제 영향
-
-| 변경 유형 | 캐시 영향 | 일반적인 시나리오 |
+| Change Type | Cache Impact | Typical Scenario |
 |-------------|-------------|-----------------|
-| Tool 추가/제거 | **전체 무효화** | MCP 서버 연결/연결 해제, IDE 플러그인 전환 |
-| System Prompt 변경 | Messages 캐시 손실 | CLAUDE.md 편집, system reminder 삽입 |
-| 새 message 추가 | 끝부분 증분만 | 일반적인 대화 흐름 (가장 일반적, 가장 저렴) |
-
-이것이 [CacheRebuild](CacheRebuild.md)에서 `tools_change`가 가장 비용이 많이 드는 리빌드 이유가 되기 쉬운 이유입니다 — 프리픽스 체인을 맨 앞에서부터 깨뜨리기 때문입니다.
-
-## 왜 도구 정의가 "두뇌"보다 먼저 배치되는가?
+| 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
 
-- **캐시 킬러**: 각 MCP 도구의 JSON Schema 정의는 KV-Cache 접두사의 맨 앞에 연결됩니다. MCP 도구 1개 추가/제거 = **전체 캐시가 처음부터 무효화**됩니다. MCP 서버를 자주 연결/해제하면 캐시 적중률이 크게 떨어집니다
-- **접두사 비대화**: MCP 도구 Schema는 일반적으로 내장 도구보다 큽니다(상세한 매개변수 설명, 열거 값 등 포함). 많은 MCP 도구는 Tools 영역의 토큰 수를 크게 늘려 Messages에 사용할 수 있는 컨텍스트 공간을 압박합니다
-- **지연 오버헤드**: MCP 도구 호출은 프로세스 간 통신(JSON-RPC over 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 Schema | description과 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 |
 
-cc-viewer의 Context 패널에서 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/ko/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## 배경
 
-CC-Viewer에는 Anthropic Messages API를 활용한 내장 번역 기능(`POST /api/translate`)이 포함되어 있습니다. 초기 구현에서는 번역 요청이 Claude Code 세션에서 캐시된 인증 자격 증명(`x-api-key`와 `authorization` 헤더 모두)을 재사용했습니다. 이로 인해 미묘하지만 심각한 문제가 발생했습니다: 번역 결과에 관련 없는 콘텐츠가 빈번하게 반환되었습니다.
+CC-Viewer에는 Anthropic Messages API를 활용한 내장 번역 기능(`POST /api/translate`)이 포함되어 있습니다. 초기 구현에서는 번역 요청이 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 키는 무상태(stateless)**로 각 요청이 완전히 독립적입니다. 반면 **OAuth 세션 토큰은 상태 유지(stateful)**로, 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 @@ CC-Viewer 번역 요청 ──(authorization: Bearer sessionToken)──→ Anth
 ## 참고 자료
 
 - [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/ko/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — 궁극의 소원 머신
+# UltraPlan — The Ultimate Wishing Machine
 
-## UltraPlan이란
+## What is UltraPlan
 
-UltraPlan은 Claude Code의 네이티브 `/ultraplan` 명령에 대한 cc-viewer의 **현지화 구현**입니다. Claude의 공식 원격 서비스를 실행할 필요 없이 로컬 환경에서 `/ultraplan`의 전체 기능을 사용할 수 있으며, 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 Team을 구성하여 코드 리뷰 수행
-- 완전한 **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
 
 ---
 
-## 중요 참고사항
+## 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에 큰 컨텍스트 윈도우가 필요합니다 (1M context Opus 모델 권장)
-- 200K 모델만 있는 경우, **실행 전에 반드시 `/clear`로 컨텍스트를 정리하세요**
-- Claude Code의 `/compact`는 컨텍스트 윈도우가 부족하면 성능이 저하됩니다 — 공간이 소진되지 않도록 주의하세요
-- 충분한 컨텍스트 공간을 유지하는 것이 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에 대한 질문이나 제안이 있으시면 [GitHub Issues](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 Team을 구성하여 코드 품질 검증
+### 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/no/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Bakgrunn
 
-MainAgent i Claude Code bruker en mekanisme for sending av full kontekst — hver forespørsel inneholder komplett samtalehistorikk, system prompt, verktøydefinisjoner osv. Dette betyr at forespørselskroppen blir stadig større etter hvert som samtalen skrider frem, og det er vanskelig å raskt finne ut "hva som faktisk er nytt i denne runden" ved å se på rå Body direkte.
+MainAgent i Codex bruker en mekanisme for sending av full kontekst — hver forespørsel inneholder komplett samtalehistorikk, system prompt, verktøydefinisjoner osv. Dette betyr at forespørselskroppen blir stadig større etter hvert som samtalen skrider frem, og det er vanskelig å raskt finne ut "hva som faktisk er nytt i denne runden" ved å se på rå Body direkte.
 
 Body Diff JSON er laget for å løse dette problemet: den sammenligner automatisk to påfølgende MainAgent-forespørsler og trekker ut den inkrementelle delen, slik at du med ett blikk kan se hva som faktisk er nytt i denne forespørselen.
 
@@ -22,7 +22,7 @@ Body Diff JSON er laget for å løse dette problemet: den sammenligner automatis
 I en normal samtalerunde inneholder Body Diff JSON vanligvis:
 - `messages`: 1–2 nye meldinger (brukerens inndata + assistentens svar fra forrige runde)
 
-Hvis du ser endringer i felt som `system`, `tools` eller `model` i diffen, betyr det at en konfigurasjonsendring har skjedd i denne runden, noe som ofte er årsaken til cache-gjenoppbygging.
+Hvis du ser endringer i felt som `system`, `tools` eller `model` i diffen, betyr det at en konfigurasjonsendring har skjedd i denne runden.
 
 ## Bruk
 

package/concepts/no/BodyFields.md

@@ -1,42 +1,39 @@
-# Beskrivelse av Request Body-felt
+# Request Body Fields
 
-Beskrivelse av toppnivåfeltene i Claude API `/v1/messages` request body.
+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.
 
-## Feltliste
+## Field List
 
-| Felt | Type | Beskrivelse |
-|------|------|------|
-| **model** | string | Navnet på modellen som brukes, f.eks. `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Samtalens meldingshistorikk. Hver melding inneholder `role` (user/assistant) og `content` (et block-array med tekst, bilder, tool_use, tool_result osv.) |
-| **system** | array | System prompt. Inneholder Codexs kjerneinstruksjoner, veiledning for verktøybruk, miljøinformasjon, CLAUDE.md-innhold m.m. Blokker med `cache_control` blir cachet via prompt caching |
-| **tools** | array | Liste over tilgjengelige verktøydefinisjoner. Hvert verktøy inneholder `name`, `description` og `input_schema` (JSON Schema). MainAgent har vanligvis 20+ verktøy, SubAgent har bare noen få |
-| **metadata** | object | Request-metadata, inneholder vanligvis `user_id` for brukeridentifikasjon |
-| **max_tokens** | number | Maksimalt antall tokens i et enkelt modellsvar, f.eks. `16000`, `64000` |
-| **thinking** | object | Konfigurasjon for utvidet tenkning. `type: "enabled"` aktiverer tenkemodus, `budget_tokens` styrer øvre grense for tenke-tokens |
-| **context_management** | object | Konfigurasjon for kontekststyring. `truncation: "auto"` lar Codex automatisk avkorte for lange meldingshistorikker |
-| **output_config** | object | Utdatakonfigurasjon, f.eks. `format`-innstillinger |
-| **stream** | boolean | Om strømmende svar er aktivert. Codex bruker alltid `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-struktur
+## input Structure
 
-Hver meldings `content` er et block-array med vanlige typer:
+When `input` is an array, each input item usually contains `role` and `content`. `content` can be an array of blocks. Common types include:
 
-- **text**: Vanlig tekstinnhold
-- **tool_use**: Modellen kaller et verktøy (inneholder `name`, `input`)
-- **tool_result**: Resultatet av verktøyutførelse (inneholder `tool_use_id`, `content`)
-- **image**: Bildeinnhold (base64 eller URL)
-- **thinking**: Modellens tenkeprosess (utvidet tenkemodus)
+- **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-struktur
+## instructions Structure
 
-System prompt-arrayet inneholder vanligvis:
+`instructions` typically contains:
 
-1. **Kjerne-agent-instruksjoner** ("You are Codex...")
-2. **Regler for verktøybruk**
-3. **CLAUDE.md-innhold** (prosjektspesifikke instruksjoner)
-4. **Ferdighetspåminnelser** (skills reminder)
-5. **Miljøinformasjon** (OS, shell, git-status osv.) — Codex er faktisk svært avhengig av git. Hvis prosjektet har et git-repository, kan Codex vise bedre forståelse av prosjektet, inkludert henting av fjernendringer og commit-historikk for analyse
-
-Blokker merket med `cache_control: { type: "ephemeral" }` caches av Anthropic API i 5 minutter. Ved cache-treff faktureres de som `cache_read_input_tokens` (betydelig billigere enn `input_tokens`).
-
-> **Merk**: For spesialiserte klienter som Codex er Anthropic-serveren faktisk ikke fullstendig avhengig av `cache_control`-attributten i requesten for å bestemme cacheoppførsel. Serveren anvender automatisk cachestrategier for bestemte felt (som system prompt og tools-definisjoner), selv når requesten ikke eksplisitt inneholder `cache_control`-merking. Derfor trenger du ikke undre deg når du ikke ser denne attributten i request body — serveren har allerede utført cacheoperasjonen bak kulissene, men viser det bare ikke til klienten. Det er en stilltiende avtale mellom Codex og 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