cx-viewer 1.0.3 → 1.0.4

package/concepts/ar/Teammate.md

@@ -1,26 +1,26 @@
 # Teammate
 
-## التعريف
+## Definition
 
-Teammate هو agent تعاوني في وضع الفريق (Team Mode) الخاص بـ Claude Code 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 |
+| Feature | Teammate | SubAgent |
 |---------|----------|----------|
-| دورة الحياة | يستمر في العمل، يمكنه استقبال رسائل متعددة | مهمة لمرة واحدة، يُدمَّر عند الانتهاء |
-| طريقة التواصل | رسائل ثنائية الاتجاه عبر SendMessage | استدعاء أحادي الاتجاه من الأب إلى الابن، مع إرجاع النتيجة |
-| السياق | سياق مستقل وكامل، يُحتفظ به عبر الجولات | سياق مهمة معزول |
-| نمط التعاون | تعاون جماعي، يمكن للأعضاء التواصل فيما بينهم | هيكل هرمي، يتفاعل فقط مع الـ agent الأب |
-| نوع المهام | مهام معقدة متعددة الخطوات | مهام فردية كالبحث والاستكشاف |
+| 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/ar/ToolsFirst.md

@@ -1,77 +1,71 @@
-# لماذا تُدرج الأدوات أولاً؟
+# Why Are Tools Listed First?
 
-في لوحة السياق بـ cc-viewer، **تظهر Tools قبل System Prompt والMessages**. يعكس هذا الترتيب بدقة **تسلسل بادئة 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.
 
-## تسلسل بادئة 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 في بداية بادئة الـ cache تماماً**.
+This does not claim a provider-specific serialization order. It gives you a stable way to inspect what capabilities were available before reading instructions and input history.
 
-## لماذا تمتلك Tools وزناً أعلى في الـ Cache من 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 = إبطال كامل للـ cache**: بما أن Tools تأتي أولاً، فأي تغيير في تعريفات الأدوات (حتى إضافة أو حذف 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 = إبطال 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 |
-| تغيير System Prompt | فقدان cache الـ Messages | تعديل CLAUDE.md، حقن system reminder |
-| إضافة رسالة جديدة | زيادة طرفية فقط | تدفق المحادثة الطبيعي (الأكثر شيوعاً، الأقل تكلفة) |
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-لهذا السبب يُعد `tools_change` في [CacheRebuild](CacheRebuild.md) أغلى أسباب إعادة البناء في الغالب — لأنه يكسر سلسلة البادئة من الأمام تماماً.
+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 في المقدمة هو حقيقة تقنية. لكن من منظور التصميم المعرفي، هذا الترتيب منطقي بنفس القدر — **الأدوات هي اليدان والقدمان، و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؛ يكتسب النموذج قدرات جديدة دون إعادة التدريب
-- **التحميل عند الطلب**: يمكن توصيل/فصل خوادم MCP بشكل انتقائي حسب السيناريو، مع تركيب مرن لمجموعات الأدوات
+### 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 في بداية بادئة KV-Cache. إضافة أو إزالة أداة MCP واحدة = **إبطال التخزين المؤقت بالكامل من البداية**. التوصيل/الفصل المتكرر لخوادم MCP يقلل بشكل كبير من معدل إصابة التخزين المؤقت
-- **تضخم البادئة**: مخططات أدوات MCP عادة أكبر من الأدوات المدمجة (أوصاف مفصلة للمعاملات، قيم تعداد، إلخ). العديد من أدوات MCP يزيد بشكل ملحوظ عدد الرموز في منطقة Tools، مما يقلص مساحة السياق المتاحة للرسائل
-- **عبء التأخير**: تتطلب استدعاءات أدوات MCP اتصالاً بين العمليات (JSON-RPC عبر stdio/SSE)، وهو أبطأ بمرتبة من استدعاءات الدوال المدمجة
-- **مخاطر الاستقرار**: خوادم MCP هي عمليات خارجية قد تتعطل أو تنتهي مهلتها أو تعيد تنسيقات غير متوقعة، مما يتطلب معالجة أخطاء إضافية
-
-### توصيات عملية
-
-| السيناريو | التوصية |
-|-----------|---------|
-| محادثات طويلة، تفاعل متكرر | تقليل عدد أدوات MCP لحماية استقرار بادئة التخزين المؤقت |
-| مهام قصيرة، عمليات لمرة واحدة | استخدام أدوات MCP بحرية؛ التأثير على التخزين المؤقت محدود |
-| إضافة/إزالة متكررة لخوادم MCP | كل تغيير يؤدي إلى إعادة بناء كاملة للتخزين المؤقت؛ النظر في تثبيت مجموعة الأدوات |
-| مخططات أدوات كبيرة الحجم | تقليص الأوصاف والتعدادات لتقليل استهلاك رموز البادئة |
-
-في لوحة Context في cc-viewer، تُعرض أدوات MCP إلى جانب الأدوات المدمجة في منطقة Tools، مما يوفر رؤية واضحة لحجم مخطط كل أداة ومساهمتها في بادئة التخزين المؤقت.
+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/ar/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 @@
 | الطريقة | الرأس | المصدر النموذجي | الخصائص |
 |---------|-------|-----------------|---------|
 | مفتاح 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. **تعطل المحادثة الرئيسية بسبب طلبات الترجمة**: قد يتم حقن محتوى طلبات الترجمة (أجزاء نصوص واجهة المستخدم) في سياق المحادثة الرئيسية، مما يتسبب في انحراف استجابات Claude Code
+1. **تأثر نتائج الترجمة بسياق المحادثة الرئيسية**: موجه النظام لطلب الترجمة هو "أنت مترجم"، لكن سياق الخادم لا يزال يحتوي على سجل محادثات Codex، مما قد يتداخل مع النموذج
+2. **تعطل المحادثة الرئيسية بسبب طلبات الترجمة**: قد يتم حقن محتوى طلبات الترجمة (أجزاء نصوص واجهة المستخدم) في سياق المحادثة الرئيسية، مما يتسبب في انحراف استجابات Codex
 3. **سلوك غير متوقع**: نظراً لأن تلوث السياق هو سلوك من جانب الخادم، لا يمكن للعميل اكتشافه أو التحكم فيه
 
 ## الدروس المستفادة
@@ -41,6 +41,6 @@
 ## المراجع
 
 - [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/ar/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — آلة الأمنيات المطلقة
+# UltraPlan — The Ultimate Wishing Machine
 
-## ما هو UltraPlan
+## What is UltraPlan
 
-UltraPlan هو **التنفيذ المحلي** من 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 المحلي، لا تتردد في فتح [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/da/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Baggrund
 
-Claude Codes MainAgent bruger en mekanisme med fuld kontekstafsendelse — hver request inkluderer den komplette samtalehistorik, system prompt, værktøjsdefinitioner osv. Det betyder, at efterhånden som samtalen skrider frem, bliver request body stadigt større, og det bliver svært hurtigt at finde ud af "hvad blev der tilføjet i denne runde" ved at se på den rå Body.
+Codexs MainAgent bruger en mekanisme med fuld kontekstafsendelse — hver request inkluderer den komplette samtalehistorik, system prompt, værktøjsdefinitioner osv. Det betyder, at efterhånden som samtalen skrider frem, bliver request body stadigt større, og det bliver svært hurtigt at finde ud af "hvad blev der tilføjet i denne runde" ved at se på den rå Body.
 
 Body Diff JSON er skabt netop for at løse dette problem: den sammenligner automatisk body fra to på hinanden følgende MainAgent-requests og udtrækker den inkrementelle del, så du med ét blik kan se det faktisk tilføjede indhold i denne request.
 
@@ -22,7 +22,7 @@ Body Diff JSON er skabt netop for at løse dette problem: den sammenligner autom
 I en normal samtalerunde indeholder Body Diff JSON normalt kun:
 - `messages`: 1~2 tilføjede beskeder (brugerens input + assistentens svar fra forrige runde)
 
-Hvis du ser ændringer i felter som `system`, `tools`, `model` i diff'en, betyder det, at der er sket en konfigurationsændring i denne runde, hvilket ofte også er årsagen til cache-genopbygning.
+Hvis du ser ændringer i felter som `system`, `tools`, `model` i diff'en, betyder det, at der er sket en konfigurationsændring i denne runde.
 
 ## Brug
 

package/concepts/da/BodyFields.md

@@ -1,42 +1,39 @@
-# Beskrivelse af Request Body-felter
+# Request Body Fields
 
-Beskrivelse af topniveau-felterne 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å den anvendte model, f.eks. `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Samtalens beskedhistorik. Hver besked indeholder `role` (user/assistant) og `content` (et block-array med tekst, billeder, tool_use, tool_result osv.) |
-| **system** | array | System prompt. Indeholder Codexs kerneinstruktioner, vejledning til brug af værktøjer, miljøoplysninger, CLAUDE.md-indhold m.m. Blokke med `cache_control` cachelagres via prompt caching |
-| **tools** | array | Liste over tilgængelige værktøjsdefinitioner. Hvert værktøj indeholder `name`, `description` og `input_schema` (JSON Schema). MainAgent har typisk 20+ værktøjer, SubAgent har kun få |
-| **metadata** | object | Request-metadata, indeholder typisk `user_id` til brugeridentifikation |
-| **max_tokens** | number | Maksimalt antal tokens i et enkelt modelsvar, f.eks. `16000`, `64000` |
-| **thinking** | object | Konfiguration af udvidet tænkning. `type: "enabled"` aktiverer tænketilstand, `budget_tokens` styrer øvre grænse for tænke-tokens |
-| **context_management** | object | Konfiguration af kontekststyring. `truncation: "auto"` tillader Codex automatisk at afkorte for lange beskedhistorikker |
-| **output_config** | object | Outputkonfiguration, f.eks. `format`-indstillinger |
-| **stream** | boolean | Om streaming-svar er aktiveret. Codex bruger altid `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 beskeds `content` er et block-array med følgende almindelige 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**: Almindeligt tekstindhold
-- **tool_use**: Modellen kalder et værktøj (indeholder `name`, `input`)
-- **tool_result**: Resultatet af værktøjsudførelse (indeholder `tool_use_id`, `content`)
-- **image**: Billedindhold (base64 eller URL)
-- **thinking**: Modellens tænkeproces (udvidet tænketilstand)
+- **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 indeholder typisk:
+`instructions` typically contains:
 
-1. **Kerne-agent-instruktioner** ("You are Codex...")
-2. **Regler for brug af værktøjer**
-3. **CLAUDE.md-indhold** (projektspecifikke instruktioner)
-4. **Færdighedspåmindelser** (skills reminder)
-5. **Miljøoplysninger** (OS, shell, git-status osv.) — Codex er faktisk meget afhængig af git. Hvis projektet har et git-repository, kan Codex vise bedre forståelse af projektet, herunder hente fjernændringer og commit-historik til analyse
-
-Blokke markeret med `cache_control: { type: "ephemeral" }` cachelagres af Anthropic API i 5 minutter. Ved cache-hit faktureres de som `cache_read_input_tokens` (betydeligt billigere end `input_tokens`).
-
-> **Bemærk**: For specialiserede klienter som Codex er Anthropic-serveren faktisk ikke fuldstændigt afhængig af `cache_control`-attributten i requesten til at bestemme cacheadfærd. Serveren anvender automatisk cachestrategier for bestemte felter (som system prompt og tools-definitioner), selv når requesten ikke eksplicit indeholder `cache_control`-markering. Derfor behøver du ikke undre dig, når du ikke ser denne attribut i request body — serveren har allerede udført cacheoperationen bag kulisserne, men viser det bare ikke til klienten. Det er en stiltiende aftale mellem 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