cx-viewer 1.0.3 → 1.0.4

package/concepts/th/Teammate.md

@@ -1,26 +1,26 @@
 # Teammate
 
-## คำนิยาม
+## Definition
 
-Teammate คือ agent ที่ทำงานร่วมกันในโหมดทีม (Team Mode) ของ Claude Code Agent เมื่อ agent หลักสร้างทีมผ่าน `TeamCreate` และใช้เครื่องมือ `Agent` เพื่อสร้าง teammate แต่ละ teammate จะทำงานเป็นกระบวนการ agent อิสระ มี context window และชุดเครื่องมือเป็นของตัวเอง และสื่อสารกับสมาชิกในทีมผ่าน `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/th/ToolsFirst.md

@@ -1,77 +1,71 @@
-# ทำไม Tools ถึงแสดงก่อน?
+# Why Are Tools Listed First?
 
-ในแผง Context ของ cc-viewer **Tools จะปรากฏก่อน System Prompt และ Messages** ลำดับนี้สะท้อนให้เห็นถึง **ลำดับ prefix ของ KV-Cache ใน Anthropic API** อย่างแม่นยำ
+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.
 
-## ลำดับ prefix ของ KV-Cache
+## Request Context Layout
 
-เมื่อ Anthropic API สร้าง KV-Cache จะเชื่อมต่อบริบทเป็น prefix ตาม **ลำดับที่ตายตัว** นี้:
+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 ที่จุดเริ่มต้นของ cache prefix**
+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 จึงมีน้ำหนักใน cache มากกว่า System?
+## Why Tools Often Matter Most
 
-ในการจับคู่ prefix ของ 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. **การจับคู่ prefix เริ่มต้นจากจุดเริ่มต้น**: KV-Cache เปรียบเทียบคำขอปัจจุบันกับ prefix ที่แคชไว้ทีละ 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 เปลี่ยน = cache ทั้งหมดเป็นโมฆะ**: เนื่องจาก Tools อยู่ก่อน การเปลี่ยนแปลงใดๆ ในนิยามของเครื่องมือ (แม้แต่การเพิ่มหรือลบ MCP tool เพียงอันเดียว) จะ **ทำลาย prefix จากจุดเริ่มต้น** ทำให้ 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 เปลี่ยน = cache ของ 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 อยู่ท้ายสุด ดังนั้นการเพิ่มข้อความใหม่จะทำให้เฉพาะส่วนท้ายเล็กๆ เป็นโมฆะ — cache ของ Tools และ System ยังคงสมบูรณ์
+## Practical Impact
 
-## ผลกระทบในทางปฏิบัติ
+| Change Type | Cache Impact | Typical Scenario |
+|-------------|-------------|-----------------|
+| 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 |
 
-| ประเภทการเปลี่ยนแปลง | ผลกระทบต่อ cache | สถานการณ์ทั่วไป |
-|----------------------|-----------------|-----------------|
-| เพิ่ม/ลบ Tool | **เป็นโมฆะทั้งหมด** | เชื่อมต่อ/ตัดการเชื่อมต่อ MCP server, เปิด/ปิด IDE plugin |
-| เปลี่ยน System Prompt | สูญเสีย cache ของ Messages | แก้ไข CLAUDE.md, การฉีด system reminder |
-| เพิ่มข้อความใหม่ | เพิ่มเฉพาะส่วนท้ายเท่านั้น | การสนทนาปกติ (พบบ่อยที่สุด, ถูกที่สุด) |
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-นี่คือเหตุผลที่ `tools_change` ใน [CacheRebuild](CacheRebuild.md) มักเป็นเหตุผลของการสร้างใหม่ที่แพงที่สุด — มันทำลายห่วงโซ่ prefix ตั้งแต่ด้านหน้าสุด
+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.
 
-## ทำไมคำจำกัดความเครื่องมือถึงอยู่ก่อน "สมอง"?
+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 อยู่ก่อนเป็นข้อเท็จจริงทางเทคนิค แต่จากมุมมองของการออกแบบเชิงปัญญา ลำดับนี้ก็มีเหตุผลเท่าเทียมกัน — **Tools คือมือและเท้า, System Prompt คือสมอง**
+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.
 
-ก่อนลงมือทำ คนเราต้องรับรู้ก่อนว่ามีแขนขาและเครื่องมืออะไรใช้ได้บ้าง ทารกไม่ได้เข้าใจกฎของโลก (System) ก่อนแล้วค่อยเรียนรู้การหยิบจับ — พวกเขารับรู้ก่อนว่ามีมือและเท้า จากนั้นค่อยๆ เข้าใจกฎผ่านการมีปฏิสัมพันธ์กับสิ่งแวดล้อม เช่นเดียวกัน LLM ต้องรู้ว่าเรียกใช้เครื่องมืออะไรได้บ้าง (อ่านไฟล์ เขียนโค้ด ค้นหา รันคำสั่ง) ก่อนได้รับคำสั่งงาน (System Prompt) เพื่อจะได้ประเมินได้อย่างแม่นยำว่า "ฉันทำอะไรได้" และ "ฉันควรทำอย่างไร" เมื่อประมวลผลคำสั่ง
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-ถ้าสลับลำดับ — บอกโมเดลก่อนว่า "งานของคุณคือรีแฟกเตอร์โมดูลนี้" แล้วค่อยบอกว่า "คุณมีเครื่องมือ Read, Edit, Bash" — โมเดลจะขาดข้อมูลสำคัญเกี่ยวกับขอบเขตความสามารถเมื่อทำความเข้าใจงาน อาจวางแผนที่ไม่สมจริงหรือมองข้ามวิธีการที่ใช้ได้
+## Why Are MCP Tools Also in This Position?
 
-**รู้ไพ่ในมือก่อน แล้วค่อยตัดสินใจว่าจะเล่นอย่างไร** นี่คือตรรกะเชิงปัญญาที่อยู่เบื้องหลังการวาง Tools ก่อน System
+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 ก็อยู่ในตำแหน่งนี้ด้วย?
+### MCP Advantages
 
-เครื่องมือ MCP (Model Context Protocol) เช่นเดียวกับเครื่องมือในตัว ถูกวางไว้ที่ส่วนเริ่มต้นของพื้นที่ Tools การเข้าใจตำแหน่งของ 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
+### 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
 
-- **ขยายความสามารถ**: MCP ให้โมเดลเข้าถึงบริการภายนอก (คิวรีฐานข้อมูล, เรียก API, ปฏิบัติการ IDE, ควบคุมเบราว์เซอร์ ฯลฯ) ก้าวข้ามขอบเขตของเครื่องมือในตัว
-- **ระบบนิเวศเปิด**: ใครก็สามารถสร้าง MCP server ได้ โมเดลได้รับความสามารถใหม่โดยไม่ต้องเทรนใหม่
-- **โหลดตามต้องการ**: MCP server สามารถเชื่อมต่อ/ตัดการเชื่อมต่อได้ตามสถานการณ์ ประกอบชุดเครื่องมือได้อย่างยืดหยุ่น
+### Practical Recommendations
 
-### ต้นทุนของ MCP
+| 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 |
 
-- **ฆาตกรแคช**: คำจำกัดความ JSON Schema ของเครื่องมือ MCP แต่ละตัวถูกต่อเข้าที่จุดเริ่มต้นของ prefix KV-Cache การเพิ่มหรือลบเครื่องมือ MCP หนึ่งตัว = **แคชทั้งหมดถูกยกเลิกตั้งแต่ต้น** การเชื่อมต่อ/ตัดการเชื่อมต่อ MCP server บ่อยครั้งจะลดอัตราการ hit แคชอย่างมาก
-- **prefix บวม**: Schema ของเครื่องมือ MCP มักใหญ่กว่าเครื่องมือในตัว (คำอธิบายพารามิเตอร์โดยละเอียด, ค่า enum ฯลฯ) เครื่องมือ MCP จำนวนมากเพิ่มจำนวน token ในพื้นที่ Tools อย่างมาก บีบพื้นที่บริบทสำหรับ Messages
-- **ค่าใช้จ่ายด้านความหน่วง**: การเรียกเครื่องมือ MCP ต้องการการสื่อสารระหว่างโปรเซส (JSON-RPC ผ่าน stdio/SSE) ช้ากว่าการเรียกฟังก์ชันในตัวเป็นอันดับขนาด
-- **ความเสี่ยงด้านเสถียรภาพ**: MCP server เป็นโปรเซสภายนอกที่อาจล่ม หมดเวลา หรือส่งคืนรูปแบบที่ไม่คาดคิด ต้องการการจัดการข้อผิดพลาดเพิ่มเติม
-
-### คำแนะนำเชิงปฏิบัติ
-
-| สถานการณ์ | คำแนะนำ |
-|-----------|---------|
-| บทสนทนายาว, โต้ตอบบ่อย | ลดจำนวนเครื่องมือ MCP ให้น้อยที่สุดเพื่อปกป้องเสถียรภาพ prefix แคช |
-| งานสั้น, ปฏิบัติการครั้งเดียว | ใช้เครื่องมือ MCP ได้อย่างอิสระ; ผลกระทบต่อแคชจำกัด |
-| เพิ่ม/ลบ MCP server บ่อย | ทุกการเปลี่ยนแปลงทำให้แคชสร้างใหม่ทั้งหมด; พิจารณาตรึงชุดเครื่องมือ |
-| Tool Schema ขนาดใหญ่เกินไป | ลด description และ enum เพื่อลดการใช้ token ของ prefix |
-
-ในแผง Context ของ cc-viewer เครื่องมือ MCP แสดงร่วมกับเครื่องมือในตัวในพื้นที่ Tools ให้มุมมองที่ชัดเจนของขนาด Schema แต่ละเครื่องมือและการมีส่วนร่วมต่อ prefix แคช
+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/th/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## ความเป็นมา
 
-CC-Viewer มีฟีเจอร์แปลภาษาในตัว (`POST /api/translate`) ที่ขับเคลื่อนโดย Anthropic Messages API ในการพัฒนาช่วงแรก คำขอแปลภาษาใช้ข้อมูลรับรองตัวตนที่แคชไว้จากเซสชัน Claude Code ซ้ำ — รวมถึงทั้ง header `x-api-key` และ `authorization` สิ่งนี้ทำให้เกิดปัญหาที่แนบเนียนแต่ร้ายแรง: ผลลัพธ์การแปลมักส่งคืนเนื้อหาที่ไม่เกี่ยวข้อง
+CC-Viewer มีฟีเจอร์แปลภาษาในตัว (`POST /api/translate`) ที่ขับเคลื่อนโดย Anthropic Messages API ในการพัฒนาช่วงแรก คำขอแปลภาษาใช้ข้อมูลรับรองตัวตนที่แคชไว้จากเซสชัน Codex ซ้ำ — รวมถึงทั้ง header `x-api-key` และ `authorization` สิ่งนี้ทำให้เกิดปัญหาที่แนบเนียนแต่ร้ายแรง: ผลลัพธ์การแปลมักส่งคืนเนื้อหาที่ไม่เกี่ยวข้อง
 
 ## สาเหตุหลัก
 
@@ -13,24 +13,24 @@ Anthropic API รองรับสองวิธีการรับรอง
 | วิธี | Header | แหล่งที่มาทั่วไป | ลักษณะเฉพาะ |
 |------|--------|-------------------|-------------|
 | API Key | `x-api-key: sk-ant-...` | ตัวแปรสภาพแวดล้อม / Console | ไม่มีสถานะ แต่ละคำขอเป็นอิสระ |
-| OAuth Token | `authorization: Bearer sessionToken` | การเข้าสู่ระบบแบบสมัครสมาชิก Claude Code | ผูกกับเซสชัน เซิร์ฟเวอร์รักษาการเชื่อมโยงบริบท |
+| OAuth Token | `authorization: Bearer sessionToken` | การเข้าสู่ระบบแบบสมัครสมาชิก Codex | ผูกกับเซสชัน เซิร์ฟเวอร์รักษาการเชื่อมโยงบริบท |
 
 ความแตกต่างสำคัญ: **API Key ไม่มีสถานะ** — แต่ละคำขอเป็นอิสระอย่างสมบูรณ์ ในขณะที่ **OAuth session token มีสถานะ** — เซิร์ฟเวอร์ 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
 ```
 
-เนื่องจากคำขอแปลภาษาใช้ session token เดียวกันซ้ำ เซิร์ฟเวอร์ Anthropic อาจเชื่อมโยงคำขอแปลภาษาเข้ากับบริบทการสนทนาหลักของ Claude Code ส่งผลให้:
+เนื่องจากคำขอแปลภาษาใช้ session token เดียวกันซ้ำ เซิร์ฟเวอร์ Anthropic อาจเชื่อมโยงคำขอแปลภาษาเข้ากับบริบทการสนทนาหลักของ Codex ส่งผลให้:
 
-1. **ผลลัพธ์การแปลได้รับอิทธิพลจากบริบทการสนทนาหลัก**: system prompt ของคำขอแปลคือ "คุณคือนักแปล" แต่บริบทของเซิร์ฟเวอร์ยังคงมีประวัติการสนทนาของ Claude Code ซึ่งอาจรบกวนโมเดล
-2. **การสนทนาหลักถูกรบกวนจากคำขอแปลภาษา**: เนื้อหาของคำขอแปล (ส่วนข้อความ UI) อาจถูกแทรกเข้าไปในบริบทการสนทนาหลัก ทำให้คำตอบของ Claude Code เบี่ยงเบน
+1. **ผลลัพธ์การแปลได้รับอิทธิพลจากบริบทการสนทนาหลัก**: system prompt ของคำขอแปลคือ "คุณคือนักแปล" แต่บริบทของเซิร์ฟเวอร์ยังคงมีประวัติการสนทนาของ 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/th/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — เครื่องอธิษฐานสุดยอด
+# UltraPlan — The Ultimate Wishing Machine
 
-## UltraPlan คืออะไร
+## What is UltraPlan
 
-UltraPlan คือ**การนำไปใช้งานแบบ localized** ของ cc-viewer สำหรับคำสั่ง `/ultraplan` ดั้งเดิมของ Claude Code ช่วยให้คุณใช้ความสามารถทั้งหมดของ `/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 แบบ localized สามารถเปิด [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/tr/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Arka Plan
 
-Claude Code'un MainAgent'ı tam bağlam gönderme mekanizması kullanır — her istek, konuşma geçmişinin tamamını, system prompt'u, araç tanımlarını ve diğer içerikleri taşır. Bu, konuşma ilerledikçe istek gövdesinin giderek büyüyeceği anlamına gelir ve ham Body'yi doğrudan inceleyerek "bu turda tam olarak ne eklendi" sorusunu yanıtlamak zorlaşır.
+Codex'un MainAgent'ı tam bağlam gönderme mekanizması kullanır — her istek, konuşma geçmişinin tamamını, system prompt'u, araç tanımlarını ve diğer içerikleri taşır. Bu, konuşma ilerledikçe istek gövdesinin giderek büyüyeceği anlamına gelir ve ham Body'yi doğrudan inceleyerek "bu turda tam olarak ne eklendi" sorusunu yanıtlamak zorlaşır.
 
 Body Diff JSON tam olarak bu sorunu çözmek için tasarlanmıştır: ardışık iki MainAgent isteğinin gövdesini otomatik olarak karşılaştırır, artımlı kısmı çıkarır ve bu istekte gerçekten eklenen içeriği bir bakışta görmenizi sağlar.
 

package/concepts/tr/BodyFields.md

@@ -1,42 +1,39 @@
-# Request Body Alan Aciklamasi
+# Request Body Fields
 
-Claude API `/v1/messages` istek govdesinin ust duzey alan aciklamasi.
+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.
 
-## Alan Listesi
+## Field List
 
-| Alan | Tur | Aciklama |
-|------|------|------|
-| **model** | string | Kullanilan model adi, ornegin `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Konusma mesaj gecmisi. Her mesaj `role` (user/assistant) ve `content` (metin, gorsel, tool_use, tool_result gibi blok dizisi) icerir |
-| **system** | array | System prompt. Codex'un temel talimatlari, arac kullanim aciklamalari, ortam bilgileri, CLAUDE.md icerigi vb. icerir. `cache_control` isaretli bloklar prompt caching ile onbellege alinir |
-| **tools** | array | Kullanilabilir arac tanim listesi. Her arac `name`, `description` ve `input_schema` (JSON Schema) icerir. MainAgent genellikle 20'den fazla araca sahipken, SubAgent yalnizca birkacina sahiptir |
-| **metadata** | object | Istek meta verileri, genellikle kullaniciyi tanimlamak icin `user_id` icerir |
-| **max_tokens** | number | Modelin tek bir yanittaki maksimum token sayisi, ornegin `16000`, `64000` |
-| **thinking** | object | Genisletilmis dusunme yapilandirmasi. `type: "enabled"` dusunme modunu etkinlestirir, `budget_tokens` dusunme token ust sinirini kontrol eder |
-| **context_management** | object | Baglam yonetimi yapilandirmasi. `truncation: "auto"` Codex'un cok uzun mesaj gecmisini otomatik olarak kesmesine izin verir |
-| **output_config** | object | Cikis yapilandirmasi, ornegin `format` ayari |
-| **stream** | boolean | Akis yaniti etkinlestirilsin mi. Codex her zaman `true` kullanir |
+| 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 Yapisi
+## input Structure
 
-Her mesajin `content` alani bir blok dizisidir. Yaygin turler sunlardir:
+When `input` is an array, each input item usually contains `role` and `content`. `content` can be an array of blocks. Common types include:
 
-- **text**: Duz metin icerigi
-- **tool_use**: Modelin arac cagrisi (`name`, `input` icerir)
-- **tool_result**: Arac yurutme sonucu (`tool_use_id`, `content` icerir)
-- **image**: Gorsel icerigi (base64 veya URL)
-- **thinking**: Modelin dusunme sureci (genisletilmis dusunme modu)
+- **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 Yapisi
+## instructions Structure
 
-system prompt dizisi genellikle sunlari icerir:
+`instructions` typically contains:
 
-1. **Temel ajan talimatlari** ("You are Codex...")
-2. **Arac kullanim kurallari**
-3. **CLAUDE.md icerigi** (proje duzeyi talimatlar)
-4. **Beceri hatirlaticilari** (skills reminder)
-5. **Ortam bilgileri** (OS, shell, git durumu vb.) — Aslinda Codex git'e buyuk olcude bagimlidir. Projede bir git deposu varsa, Codex projeyi daha iyi anlayabilir; uzak degisiklikleri ve commit kayitlarini cekerek analiz surecine yardimci olabilir
-
-`cache_control: { type: "ephemeral" }` ile isaretlenmis bloklar Anthropic API tarafindan 5 dakika boyunca onbellege alinir. Onbellek isabet ettiginde `cache_read_input_tokens` olarak faturalandirilir (`input_tokens`'dan cok daha dusuktur).
-
-> **Not**: Codex gibi ozel istemciler icin, Anthropic sunucusu aslinda onbellekleme davranisini belirlemek icin istekteki `cache_control` ozelligine tamamen bagimli degildir. Sunucu, istekte acikca `cache_control` isareti bulunmasa bile belirli alanlar icin (system prompt, arac tanimlari gibi) onbellekleme politikasini otomatik olarak uygular. Bu nedenle, istek govdesinde bu ozelligi gormediyseniz sasirmaniza gerek yoktur — sunucu onbellekleme islemini arka planda zaten tamamlamistir, ancak bu bilgiyi istemciye aciklamamistir. Bu, Codex ile Anthropic API arasindaki uskutulen bir anlasmadir.
+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