cx-viewer 1.0.3 → 1.0.4

package/concepts/tr/Teammate.md

@@ -1,26 +1,26 @@
 # Teammate
 
-## Tanım
+## Definition
 
-Teammate, Claude Code Agent'ın Takım Modu (Team Mode) altındaki iş birlikçi agent'tır. Ana agent `TeamCreate` ile bir takım oluşturup `Agent` aracını kullanarak teammate ürettiğinde, her teammate bağımsız bir agent süreci olarak çalışır, kendi bağlam penceresine ve araç setine sahiptir ve `SendMessage` aracılığıyla takım üyeleriyle iletişim kurar.
+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 ile Farkları
+## Differences from SubAgent
 
-| Özellik | Teammate | SubAgent |
+| Feature | Teammate | SubAgent |
 |---------|----------|----------|
-| Yaşam döngüsü | Kalıcıdır, birden fazla mesaj alabilir | Tek seferlik görev, tamamlandığında yok edilir |
-| İletişim yöntemi | SendMessage ile çift yönlü mesajlaşma | Üst→alt tek yönlü çağrı, sonuç döndürme |
-| Bağlam | Bağımsız ve eksiksiz bağlam, turlar arası korunur | İzole edilmiş görev bağlamı |
-| İş birliği modeli | Takım iş birliği, birbirleriyle iletişim kurabilir | Hiyerarşik yapı, yalnızca üst agent ile etkileşir |
-| Görev türü | Karmaşık çok adımlı görevler | Arama, keşif gibi tekil görevler |
+| 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 |
 
-## Davranış
+## Behavior
 
-- Ana agent (team lead) tarafından `Agent` aracıyla oluşturulur ve `team_name` atanır
-- `TaskList` / `TaskGet` / `TaskUpdate` aracılığıyla görev listesini paylaşır
-- Her tur yürütmesi tamamlandıktan sonra idle durumuna geçer, yeni bir mesajla uyandırılmayı bekler
-- `shutdown_request` ile zarif bir şekilde sonlandırılabilir
+- 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`
 
-## İstatistik Paneli Açıklaması
+## Stats Panel Description
 
-Teammate istatistik paneli, her teammate'in API çağrı sayısını gösterir. `Name` sütunu teammate adını (örneğin `reviewer-security`, `reviewer-pipeline`), `Sayı` sütunu ise o teammate'in ürettiği toplam API istek sayısını gösterir.
+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/tr/ToolsFirst.md

@@ -1,77 +1,71 @@
-# Tools Neden İlk Sırada Gösterilir?
+# Why Are Tools Listed First?
 
-cc-viewer'ın Bağlam panelinde **Tools, System Prompt ve Messages'tan önce görünür**. Bu sıralama, **Anthropic API'nin KV-Cache önek sırasını** tam olarak yansıtır.
+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 Önek Sırası
+## Request Context Layout
 
-Anthropic'in API'si KV-Cache'i oluştururken, bağlamı bu **sabit sırayla** bir önek olarak birleştirir:
+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)   │
 └─────────────────────────────────────────────────┘
 ```
 
-Bu, **Tools'un cache önekinin en başında System Prompt'tan önce yer aldığı** anlamına gelir.
+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 Neden System'dan Daha Fazla Cache Ağırlığına Sahip?
+## Why Tools Often Matter Most
 
-KV-Cache önek eşleştirmesinde **önceki içerik daha kritiktir** — herhangi bir değişiklik, sonrasındaki her şeyi geçersiz kılar:
+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. **Önek eşleştirmesi baştan başlar**: KV-Cache, mevcut isteği önbellekteki önekle baştan token token karşılaştırır. Bir uyuşmazlık bulunduğu anda, sonraki tüm içerik geçersiz kılınır.
+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 değişirse = tüm cache geçersiz**: Tools ilk sırada olduğundan, araç tanımlarındaki herhangi bir değişiklik (tek bir MCP tool eklenmesi veya kaldırılması bile) **öneki en başından bozar** ve önbelleğe alınan tüm System Prompt ile Messages'ı geçersiz kılar.
+2. **Tool schemas can dominate request size**: MCP and dynamic tools often have detailed JSON Schemas with descriptions, enums, and nested parameters.
 
-3. **System değişirse = Messages cache geçersiz**: System Prompt ortada yer aldığından, değişiklikler yalnızca sonrasındaki Messages bölümünü geçersiz kılar.
+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 değişirse = yalnızca kuyruk etkilenir**: Messages en sonda yer aldığından, yeni mesajlar eklemek yalnızca küçük bir son segmenti geçersiz kılar — Tools ve System cache'i bütün kalır.
+## Practical Impact
 
-## Pratik Etki
+| 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 |
 
-| Değişiklik Türü | Cache Etkisi | Tipik Senaryo |
-|-----------------|-------------|---------------|
-| Tool eklendi/kaldırıldı | **Tam geçersizleştirme** | MCP sunucu bağlan/kes, IDE eklentisi aç/kapat |
-| System Prompt değişikliği | Messages cache kaybı | CLAUDE.md düzenleme, system reminder enjeksiyonu |
-| Yeni mesaj eklendi | Yalnızca kuyruk artışı | Normal konuşma akışı (en yaygın, en ucuz) |
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-Bu nedenle [CacheRebuild](CacheRebuild.md)'deki `tools_change`, genellikle en pahalı yeniden oluşturma nedenidir — önek zincirini en baştan kırar.
+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.
 
-## Araç tanımları neden "beyinden" önce yerleştirilir?
+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.
 
-Önbellekleme açısından, Tools'un ilk sırada olması teknik bir gerçektir. Ancak bilişsel tasarım açısından da bu sıralama mantıklıdır — **Tools eller ve ayaklardır, System Prompt beyindir**.
+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.
 
-Harekete geçmeden önce, bir kişi hangi uzuvlara ve araçlara sahip olduğunu algılamalıdır. Bir bebek önce dünyanın kurallarını (System) anlayıp sonra tutmayı öğrenmez — önce ellerinin ve ayaklarının olduğunu algılar, ardından çevreyle etkileşim yoluyla kuralları kademeli olarak anlar. Benzer şekilde, bir LLM görev talimatlarını (System Prompt) almadan önce hangi araçları çağırabileceğini (dosya okuma, kod yazma, arama, komut çalıştırma) bilmelidir, böylece talimatları işlerken "ne yapabilirim" ve "nasıl yapmalıyım" sorularını doğru değerlendirebilir.
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-Eğer tersi olsaydı — modele önce "görevin bu modülü yeniden yapılandırmak", sonra "Read, Edit, Bash araçların var" deseydiniz — model görevi anlarken yetenek sınırları hakkında kritik bilgiden yoksun olurdu, potansiyel olarak gerçekçi olmayan planlar üretebilir veya mevcut yaklaşımları gözden kaçırabilirdi.
+## Why Are MCP Tools Also in This Position?
 
-**Elindeki kartları bil, sonra nasıl oynayacağına karar ver.** Tools'un System'den önce gelmesinin arkasındaki bilişsel mantık budur.
+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 araçları neden bu konumda?
+### MCP Advantages
 
-MCP (Model Context Protocol) araçları, yerleşik araçlar gibi, Tools alanının en başına yerleştirilir. MCP'nin bağlamdaki konumunu anlamak, gerçek faydalarını ve maliyetlerini değerlendirmeye yardımcı olur.
+- **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 Avantajları
+### 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
 
-- **Yetenek genişletme**: MCP, modellerin harici hizmetlere (veritabanı sorguları, API çağrıları, IDE işlemleri, tarayıcı kontrolü vb.) erişmesini sağlar ve yerleşik araçların sınırlarını aşar
-- **Açık ekosistem**: Herkes bir MCP sunucusu uygulayabilir; model yeniden eğitim olmadan yeni yetenekler kazanır
-- **İsteğe bağlı yükleme**: MCP sunucuları görev senaryosuna göre seçici olarak bağlanabilir/bağlantısı kesilebilir, esnek araç setleri oluşturulabilir
+### Practical Recommendations
 
-### MCP Maliyetleri
+| 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 |
 
-- **Önbellek katili**: Her MCP aracının JSON Schema tanımı KV-Cache ön ekinin en başına eklenir. Bir MCP aracı eklemek/kaldırmak = **tüm önbellek baştan geçersiz kılınır**. MCP sunucularını sık sık bağlama/bağlantı kesme, önbellek isabet oranını büyük ölçüde düşürür
-- **Ön ek şişmesi**: MCP araç Şemaları genellikle yerleşik araçlardan daha büyüktür (ayrıntılı parametre açıklamaları, enum değerleri vb.). Çok sayıda MCP aracı, Tools alanındaki token sayısını önemli ölçüde artırır ve Messages için kullanılabilir bağlam alanını daraltır
-- **Gecikme yükü**: MCP araç çağrıları süreçler arası iletişim gerektirir (stdio/SSE üzerinden JSON-RPC), yerleşik fonksiyon çağrılarından bir büyüklük derecesi daha yavaştır
-- **Kararlılık riski**: MCP sunucuları çökebilen, zaman aşımına uğrayabilen veya beklenmeyen formatlar döndürebilen harici süreçlerdir ve ek hata işleme gerektirir
-
-### Pratik Öneriler
-
-| Senaryo | Öneri |
-|---------|-------|
-| Uzun konuşmalar, sık etkileşim | Önbellek ön eki kararlılığını korumak için MCP araç sayısını minimize edin |
-| Kısa görevler, tek seferlik işlemler | MCP araçlarını serbestçe kullanın; önbellek etkisi sınırlıdır |
-| Sık MCP sunucusu ekleme/kaldırma | Her değişiklik tam önbellek yeniden oluşturmayı tetikler; araç setini sabitlemeyi düşünün |
-| Aşırı büyük Tool Şemaları | Ön ek token tüketimini azaltmak için açıklamaları ve enum'ları kısaltın |
-
-cc-viewer'ın Context panelinde, MCP araçları yerleşik araçlarla birlikte Tools alanında görüntülenir ve her aracın Şema boyutunu ve önbellek ön ekine katkısını net bir şekilde gösterir.
+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/tr/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## Arka Plan
 
-CC-Viewer, Anthropic Messages API tarafından desteklenen yerleşik bir çeviri özelliği (`POST /api/translate`) içerir. Erken uygulamada, çeviri istekleri Claude Code oturumundan önbelleğe alınmış kimlik doğrulama bilgilerini yeniden kullanıyordu — hem `x-api-key` hem de `authorization` başlıkları dahil. Bu, ince ama ciddi bir soruna neden oldu: çeviri sonuçları sıklıkla alakasız içerik döndürüyordu.
+CC-Viewer, Anthropic Messages API tarafından desteklenen yerleşik bir çeviri özelliği (`POST /api/translate`) içerir. Erken uygulamada, çeviri istekleri Codex oturumundan önbelleğe alınmış kimlik doğrulama bilgilerini yeniden kullanıyordu — hem `x-api-key` hem de `authorization` başlıkları dahil. Bu, ince ama ciddi bir soruna neden oldu: çeviri sonuçları sıklıkla alakasız içerik döndürüyordu.
 
 ## Temel Neden
 
@@ -13,24 +13,24 @@ Anthropic API iki kimlik doğrulama yöntemini destekler:
 | Yöntem | Başlık | Tipik Kaynak | Özellikler |
 |--------|--------|--------------|------------|
 | API Anahtarı | `x-api-key: sk-ant-...` | Ortam değişkeni / Console | Durumsuz, her istek bağımsızdır |
-| OAuth Token | `authorization: Bearer sessionToken` | Claude Code abonelik girişi | Oturuma bağlı, sunucu bağlam ilişkilendirmesini sürdürür |
+| OAuth Token | `authorization: Bearer sessionToken` | Codex abonelik girişi | Oturuma bağlı, sunucu bağlam ilişkilendirmesini sürdürür |
 
 Temel fark: **API Anahtarları durumsuz (stateless)** — her istek tamamen bağımsızdır; oysa **OAuth oturum tokenları durumlu (stateful)** — Anthropic sunucusu aynı tokeni kullanan istekleri aynı oturum bağlamıyla ilişkilendirir.
 
 ### Kirlilik Zinciri
 
-Claude Code abonelik OAuth girişi kullandığında, kimlik doğrulama akışı şöyle görünür:
+Codex abonelik OAuth girişi kullandığında, kimlik doğrulama akışı şöyle görünür:
 
 ```
-Claude Code ana konuşma ──(authorization: Bearer sessionToken)──→ Anthropic API
+Codex ana konuşma ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                       ↑
 CC-Viewer çeviri isteği ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-Çeviri istekleri aynı oturum tokenını yeniden kullandığından, Anthropic sunucusu çeviri isteklerini Claude Code'un ana konuşma bağlamıyla ilişkilendirebilir. Bu durum şunlara yol açar:
+Çeviri istekleri aynı oturum tokenını yeniden kullandığından, Anthropic sunucusu çeviri isteklerini Codex'un ana konuşma bağlamıyla ilişkilendirebilir. Bu durum şunlara yol açar:
 
-1. **Çeviri sonuçları ana konuşma bağlamından etkilenir**: Çeviri isteğinin sistem promptu "sen bir çevirmensin" olmasına rağmen, sunucu bağlamı hâlâ Claude Code'un konuşma geçmişini içerir ve bu modeli potansiyel olarak etkileyebilir
-2. **Ana konuşma çeviri istekleri tarafından bozulur**: Çeviri isteği içeriği (UI metin parçaları) ana konuşma bağlamına enjekte edilebilir ve Claude Code'un yanıtlarının sapmasına neden olabilir
+1. **Çeviri sonuçları ana konuşma bağlamından etkilenir**: Çeviri isteğinin sistem promptu "sen bir çevirmensin" olmasına rağmen, sunucu bağlamı hâlâ Codex'un konuşma geçmişini içerir ve bu modeli potansiyel olarak etkileyebilir
+2. **Ana konuşma çeviri istekleri tarafından bozulur**: Çeviri isteği içeriği (UI metin parçaları) ana konuşma bağlamına enjekte edilebilir ve Codex'un yanıtlarının sapmasına neden olabilir
 3. **Öngörülemeyen davranış**: Bağlam kirliliği sunucu tarafı davranışı olduğundan, istemci bunu tespit edemez veya kontrol edemez
 
 ## Çıkarılan Dersler
@@ -41,6 +41,6 @@ CC-Viewer çeviri isteği ──(authorization: Bearer sessionToken)──→ An
 ## Referanslar
 
 - [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/tr/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — Nihai Dilek Makinesi
+# UltraPlan — The Ultimate Wishing Machine
 
-## UltraPlan Nedir
+## What is UltraPlan
 
-UltraPlan, cc-viewer'in Claude Code'un yerel `/ultraplan` komutunun **yerelleştirilmiş uygulamasıdır**. `/ultraplan`'ın tüm yeteneklerini **Claude'un resmi uzak hizmetini başlatmaya gerek kalmadan** yerel ortamınızda kullanmanızı sağlar ve Claude Code'u **çoklu ajan işbirliği** kullanarak karmaşık planlama ve uygulama görevlerini yerine getirmeye yönlendirir.
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
-Normal Plan modu veya Agent Team ile karşılaştırıldığında, UltraPlan şunları yapabilir:
-- Görev karmaşıklığını otomatik olarak değerlendirip optimal planlama stratejisini seçmek
-- Kod tabanını farklı boyutlardan keşfetmek için birden fazla paralel ajan dağıtmak
-- Sektördeki en iyi uygulamalar için harici araştırma (webSearch) dahil etmek
-- Plan yürütmesinden sonra kod incelemesi için otomatik olarak bir Code Review Ekibi oluşturmak
-- Tam bir **Planla → Yürüt → İncele → Düzelt** kapalı döngüsü oluşturmak
+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
 
 ---
 
-## Önemli Notlar
+## Important Notes
 
-### 1. UltraPlan Her Şeye Kadir Değildir
-UltraPlan daha güçlü bir dilek makinesidir, ancak bu her dileğin gerçekleştirilebileceği anlamına gelmez. Plan ve Agent Team'den daha güçlüdür, ancak doğrudan "size para kazandıramaz". Makul görev ayrıntı düzeyini göz önünde bulundurun — her şeyi tek seferde başarmaya çalışmak yerine büyük hedefleri yürütülebilir orta ölçekli görevlere bölün.
+### 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. Şu Anda Programlama Projeleri İçin En Etkili
-UltraPlan'ın şablonları ve iş akışları, programlama projeleri için derinlemesine optimize edilmiştir. Diğer senaryolar (dokümantasyon, veri analizi vb.) denenebilir, ancak gelecek sürüm uyarlamalarını beklemek isteyebilirsiniz.
+### 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. Yürütme Süresi ve Bağlam Penceresi Gereksinimleri
-- Başarılı bir UltraPlan çalıştırması genellikle **30 dakika veya daha fazla** sürer
-- MainAgent'in büyük bir bağlam penceresine sahip olmasını gerektirir (1M bağlamlı Opus modeli önerilir)
-- Yalnızca 200K modeliniz varsa, **çalıştırmadan önce bağlamı `/clear` ile temizlediğinizden emin olun**
-- Claude Code'un `/compact` komutu bağlam penceresi yetersiz olduğunda kötü performans gösterir — alanın tükenmesinden kaçının
-- Yeterli bağlam alanını korumak, başarılı UltraPlan yürütmesi için kritik bir ön koşuldur
+### 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
 
-Yerelleştirilmiş UltraPlan hakkında sorularınız veya önerileriniz varsa, tartışmak ve işbirliği yapmak için [GitHub'da Issues](https://github.com/anthropics/claude-code/issues) açmaktan çekinmeyin.
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
-## Nasıl Çalışır
+## How It Works
 
-UltraPlan iki çalışma modu sunar:
+UltraPlan offers two operating modes:
 
-### Otomatik Mod
-Görev karmaşıklığını (puan 4-12) otomatik olarak analiz eder ve farklı stratejilere yönlendirir:
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| Rota | Puan | Strateji |
-|------|------|----------|
-| Rota A | 4-6 | Doğrudan kod keşfi ile hafif planlama |
-| Rota B | 7-9 | Yapısal diyagramlarla planlama (Mermaid / ASCII) |
-| Rota C | 10-12 | Çoklu ajan keşfi + inceleme kapalı döngüsü |
+| 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 |
 
-### Zorunlu Mod
-Rota C'nin tam çoklu ajan iş akışını doğrudan etkinleştirir:
-1. Kod tabanını eş zamanlı olarak keşfetmek için 5'e kadar paralel ajan dağıtma (mimari, dosya tanımlama, risk değerlendirmesi vb.)
-2. İsteğe bağlı olarak webSearch aracılığıyla sektör çözümlerini araştırmak için bir araştırma ajanı dağıtma
-3. Tüm ajan bulgularını ayrıntılı bir uygulama planında sentezleme
-4. Planı birden fazla perspektiften incelemek için bir inceleme ajanı dağıtma
-5. Onaylandıktan sonra planı yürütme
-6. Uygulamadan sonra kod kalitesini doğrulamak için otomatik olarak bir Code Review Ekibi oluşturma
+### 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/uk/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Передумови
 
-MainAgent Claude Code використовує механізм повного надсилання контексту — кожен запит містить повну історію розмови, system prompt, визначення інструментів тощо. Це означає, що в міру просування розмови тіло запиту стає дедалі більшим, і безпосередній перегляд необробленого Body ускладнює швидке визначення того, "що саме було додано в цьому раунді".
+MainAgent Codex використовує механізм повного надсилання контексту — кожен запит містить повну історію розмови, system prompt, визначення інструментів тощо. Це означає, що в міру просування розмови тіло запиту стає дедалі більшим, і безпосередній перегляд необробленого Body ускладнює швидке визначення того, "що саме було додано в цьому раунді".
 
 Body Diff JSON створений саме для вирішення цієї проблеми: він автоматично порівнює тіла двох послідовних запитів MainAgent, витягує інкрементальну частину і дозволяє одразу побачити, що саме було додано в цьому запиті.
 

package/concepts/uk/BodyFields.md

@@ -1,42 +1,39 @@
-# Опис полів Request Body
+# Request Body Fields
 
-Опис полів верхнього рівня request body 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. **Інформація про середовище** (OS, 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 та визначення tools), навіть якщо запит явно не містить позначки `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