cx-viewer 1.0.2 → 1.0.4

package/concepts/pl/Teammate.md

@@ -1,26 +1,26 @@
 # Teammate
 
-## Definicja
+## Definition
 
-Teammate to agent współpracujący w trybie Claude Code Agent Team. Gdy główny agent tworzy zespół za pomocą `TeamCreate` i generuje teammate'ów przy użyciu narzędzia `Agent`, każdy teammate działa jako niezależny proces agenta z własnym oknem kontekstu i zestawem narzędzi, komunikując się z członkami zespołu za pośrednictwem `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.
 
-## Różnice w porównaniu z SubAgent
+## Differences from SubAgent
 
-| Cecha | Teammate | SubAgent |
-|-------|----------|----------|
-| Cykl życia | Trwały, może odbierać wiele wiadomości | Jednorazowe zadanie, niszczony po zakończeniu |
-| Komunikacja | SendMessage — wiadomości dwukierunkowe | Rodzic→dziecko — wywołanie jednokierunkowe, zwraca wynik |
-| Kontekst | Niezależny pełny kontekst, zachowywany między turami | Izolowany kontekst zadania |
-| Model współpracy | Współpraca zespołowa, wzajemna komunikacja | Struktura hierarchiczna, interakcja tylko z agentem nadrzędnym |
-| Typ zadania | Złożone zadania wieloetapowe | Pojedyncze zadania, takie jak wyszukiwanie i eksploracja |
+| 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 |
 
-## Zachowanie
+## Behavior
 
-- Tworzony przez głównego agenta (team lead) za pomocą narzędzia `Agent` z przypisanym `team_name`
-- Współdzieli listę zadań przez `TaskList` / `TaskGet` / `TaskUpdate`
-- Po każdej rundzie wykonania przechodzi w stan idle i czeka na przebudzenie przez nowe wiadomości
-- Może zostać elegancko zakończony za pomocą `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`
 
-## Opis panelu statystyk
+## Stats Panel Description
 
-Panel statystyk teammate'ów wyświetla liczbę wywołań API dla każdego teammate'a. Kolumna `Name` to nazwa teammate'a (np. `reviewer-security`, `reviewer-pipeline`), a kolumna `Liczba` to łączna liczba żądań API wygenerowanych przez danego teammate'a.
+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/pl/ToolsFirst.md

@@ -1,77 +1,71 @@
-# Dlaczego Tools są wyświetlane jako pierwsze?
+# Why Are Tools Listed First?
 
-W panelu kontekstu cc-viewer **Tools pojawiają się przed System Prompt i Messages**. Ta kolejność dokładnie odzwierciedla **sekwencję prefiksu KV-Cache w 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.
 
-## Sekwencja prefiksu KV-Cache
+## Request Context Layout
 
-Gdy Anthropic API buduje KV-Cache, łączy kontekst w prefiks w tej **stałej kolejności**:
+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)   │
 └─────────────────────────────────────────────────┘
 ```
 
-Oznacza to, że **Tools znajdują się przed System Prompt na samym początku prefiksu 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.
 
-## Dlaczego Tools mają większy wpływ na cache niż System?
+## Why Tools Often Matter Most
 
-W dopasowywaniu prefiksu KV-Cache **wcześniejsza treść jest bardziej krytyczna** — każda zmiana unieważnia wszystko, co po niej następuje:
+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. **Dopasowywanie prefiksu zaczyna się od początku**: KV-Cache porównuje bieżące żądanie z zbuforowanym prefiksem token po tokenie od początku. W momencie znalezienia niezgodności cała późniejsza treść zostaje unieważniona.
+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. **Zmiana Tools = cały cache unieważniony**: Ponieważ Tools są na pierwszym miejscu, każda zmiana w definicjach narzędzi (nawet dodanie lub usunięcie jednego MCP tool) **przerywa prefiks od samego początku**, unieważniając cały zbuforowany System Prompt i Messages.
+2. **Tool schemas can dominate request size**: MCP and dynamic tools often have detailed JSON Schemas with descriptions, enums, and nested parameters.
 
-3. **Zmiana System = cache Messages unieważniony**: System Prompt znajduje się w środku, więc jego zmiany unieważniają tylko następującą po nim część 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. **Zmiana Messages = dotyczy tylko końca**: Messages są na końcu, więc dołączanie nowych wiadomości unieważnia jedynie niewielki końcowy segment — cache Tools i System pozostaje nienaruszony.
+## Practical Impact
 
-## Praktyczny wpływ
+| 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 |
 
-| Typ zmiany | Wpływ na cache | Typowy scenariusz |
-|------------|---------------|-------------------|
-| Tool dodane/usunięte | **Pełne unieważnienie** | Połączenie/rozłączenie serwera MCP, włączenie/wyłączenie wtyczki IDE |
-| Zmiana System Prompt | Utrata cache Messages | Edycja CLAUDE.md, wstrzyknięcie system reminder |
-| Nowa wiadomość dodana | Tylko przyrost końcowy | Normalny przepływ rozmowy (najczęstszy, najtańszy) |
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-Dlatego `tools_change` w [CacheRebuild](CacheRebuild.md) jest zazwyczaj najdroższym powodem przebudowy — przerywa łańcuch prefiksu na samym początku.
+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.
 
-## Dlaczego definicje narzędzi są umieszczone przed "mózgiem"?
+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.
 
-Z perspektywy cache'owania, umieszczenie Tools na pierwszym miejscu jest faktem technicznym. Ale z perspektywy projektowania kognitywnego ta kolejność jest równie logiczna — **Tools to ręce i nogi, System Prompt to mózg**.
+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.
 
-Przed podjęciem działania człowiek musi rozpoznać, jakie kończyny i narzędzia ma do dyspozycji. Niemowlę nie rozumie najpierw zasad świata (System), a potem uczy się chwytać — najpierw wyczuwa, że ma ręce i nogi, a następnie stopniowo rozumie zasady przez interakcję ze środowiskiem. Podobnie LLM musi wiedzieć, jakie narzędzia może wywołać (czytanie plików, pisanie kodu, wyszukiwanie, wykonywanie poleceń) przed otrzymaniem instrukcji zadania (System Prompt), aby móc dokładnie ocenić "co mogę zrobić" i "jak powinienem to zrobić" podczas przetwarzania instrukcji.
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-Gdyby było odwrotnie — najpierw powiedzieć modelowi "twoim zadaniem jest refaktoryzacja tego modułu", potem "masz narzędzia Read, Edit, Bash" — modelowi brakowałoby kluczowych informacji o granicach swoich możliwości przy rozumieniu zadania, co mogłoby prowadzić do nierealistycznych planów lub pominięcia dostępnych podejść.
+## Why Are MCP Tools Also in This Position?
 
-**Poznaj swoje karty zanim zdecydujesz, jak grać.** To jest logika kognitywna stojąca za umieszczeniem Tools przed 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.
 
-## Dlaczego narzędzia MCP również znajdują się na tej pozycji?
+### MCP Advantages
 
-Narzędzia MCP (Model Context Protocol), podobnie jak narzędzia wbudowane, są umieszczone na samym początku obszaru Tools. Zrozumienie pozycji MCP w kontekście pomaga ocenić jego realne korzyści i koszty.
+- **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
 
-### Zalety 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
 
-- **Rozszerzenie możliwości**: MCP pozwala modelom na dostęp do usług zewnętrznych (zapytania do baz danych, wywołania API, operacje IDE, sterowanie przeglądarką itp.), przekraczając granice narzędzi wbudowanych
-- **Otwarty ekosystem**: Każdy może zaimplementować serwer MCP; model zyskuje nowe możliwości bez ponownego trenowania
-- **Ładowanie na żądanie**: Serwery MCP mogą być selektywnie łączone/rozłączane w zależności od scenariusza, elastycznie komponując zestawy narzędzi
+### Practical Recommendations
 
-### Koszty 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 |
 
-- **Zabójca cache'u**: Definicja JSON Schema każdego narzędzia MCP jest dołączana na samym początku prefiksu KV-Cache. Dodanie lub usunięcie jednego narzędzia MCP = **cały cache unieważniony od początku**. Częste łączenie/rozłączanie serwerów MCP drastycznie obniża współczynnik trafień cache'u
-- **Puchnięcie prefiksu**: Schematy narzędzi MCP są typowo większe niż narzędzia wbudowane (szczegółowe opisy parametrów, wartości enum itp.). Wiele narzędzi MCP znacząco zwiększa liczbę tokenów w obszarze Tools, zmniejszając przestrzeń kontekstu dostępną dla Messages
-- **Narzut opóźnienia**: Wywołania narzędzi MCP wymagają komunikacji międzyprocesowej (JSON-RPC przez stdio/SSE), o rząd wielkości wolniejszej niż wywołania wbudowanych funkcji
-- **Ryzyko stabilności**: Serwery MCP to procesy zewnętrzne, które mogą się zawiesić, przekroczyć limit czasu lub zwrócić nieoczekiwane formaty, wymagając dodatkowej obsługi błędów
-
-### Praktyczne rekomendacje
-
-| Scenariusz | Rekomendacja |
-|-----------|-------------|
-| Długie rozmowy, częsta interakcja | Minimalizować liczbę narzędzi MCP, aby chronić stabilność prefiksu cache'u |
-| Krótkie zadania, jednorazowe operacje | Swobodnie używać narzędzi MCP; wpływ na cache jest ograniczony |
-| Częste dodawanie/usuwanie serwerów MCP | Każda zmiana wywołuje pełną przebudowę cache'u; rozważyć ustalenie zestawu narzędzi |
-| Zbyt duże Tool Schemas | Skrócić opisy i enumy, aby zmniejszyć zużycie tokenów prefiksu |
-
-W panelu Context cc-viewer narzędzia MCP są wyświetlane obok narzędzi wbudowanych w obszarze Tools, dając jasny widok na rozmiar Schema każdego narzędzia i jego wkład w prefiks cache'u.
+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/pl/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## Kontekst
 
-CC-Viewer zawiera wbudowaną funkcję tłumaczenia (`POST /api/translate`) opartą na Anthropic Messages API. We wczesnej implementacji żądania tłumaczenia ponownie wykorzystywały buforowane dane uwierzytelniające z sesji Claude Code — w tym zarówno nagłówki `x-api-key`, jak i `authorization`. Powodowało to subtelny, ale poważny problem: wyniki tłumaczeń często zwracały nieistotną treść.
+CC-Viewer zawiera wbudowaną funkcję tłumaczenia (`POST /api/translate`) opartą na Anthropic Messages API. We wczesnej implementacji żądania tłumaczenia ponownie wykorzystywały buforowane dane uwierzytelniające z sesji Codex — w tym zarówno nagłówki `x-api-key`, jak i `authorization`. Powodowało to subtelny, ale poważny problem: wyniki tłumaczeń często zwracały nieistotną treść.
 
 ## Przyczyna źródłowa
 
@@ -13,24 +13,24 @@ Anthropic API obsługuje dwie metody uwierzytelniania:
 | Metoda | Nagłówek | Typowe źródło | Charakterystyka |
 |--------|----------|---------------|-----------------|
 | Klucz API | `x-api-key: sk-ant-...` | Zmienna środowiskowa / Console | Bezstanowy, każde żądanie jest niezależne |
-| Token OAuth | `authorization: Bearer sessionToken` | Logowanie subskrypcyjne Claude Code | Powiązany z sesją, serwer utrzymuje powiązanie kontekstu |
+| Token OAuth | `authorization: Bearer sessionToken` | Logowanie subskrypcyjne Codex | Powiązany z sesją, serwer utrzymuje powiązanie kontekstu |
 
 Kluczowa różnica: **Klucze API są bezstanowe** — każde żądanie jest całkowicie niezależne; natomiast **tokeny sesji OAuth są stanowe** — serwer Anthropic wiąże żądania używające tego samego tokena z tym samym kontekstem sesji.
 
 ### Łańcuch zanieczyszczenia
 
-Gdy Claude Code używa logowania subskrypcyjnego OAuth, przepływ uwierzytelniania wygląda następująco:
+Gdy Codex używa logowania subskrypcyjnego OAuth, przepływ uwierzytelniania wygląda następująco:
 
 ```
-Główna rozmowa Claude Code ──(authorization: Bearer sessionToken)──→ Anthropic API
+Główna rozmowa Codex ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                         ↑
 Żądanie tłumaczenia CC-Viewer ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-Ponieważ żądania tłumaczenia ponownie wykorzystywały ten sam token sesji, serwer Anthropic może powiązać żądania tłumaczenia z kontekstem głównej rozmowy Claude Code. Powoduje to:
+Ponieważ żądania tłumaczenia ponownie wykorzystywały ten sam token sesji, serwer Anthropic może powiązać żądania tłumaczenia z kontekstem głównej rozmowy Codex. Powoduje to:
 
-1. **Wyniki tłumaczenia pod wpływem kontekstu głównej rozmowy**: Prompt systemowy żądania tłumaczenia to „jesteś tłumaczem", ale kontekst serwera nadal zawiera historię rozmów Claude Code, co może zakłócać działanie modelu
-2. **Główna rozmowa zakłócana przez żądania tłumaczenia**: Treść żądań tłumaczenia (fragmenty tekstu UI) może zostać wstrzyknięta do kontekstu głównej rozmowy, powodując odchylenia w odpowiedziach Claude Code
+1. **Wyniki tłumaczenia pod wpływem kontekstu głównej rozmowy**: Prompt systemowy żądania tłumaczenia to „jesteś tłumaczem", ale kontekst serwera nadal zawiera historię rozmów Codex, co może zakłócać działanie modelu
+2. **Główna rozmowa zakłócana przez żądania tłumaczenia**: Treść żądań tłumaczenia (fragmenty tekstu UI) może zostać wstrzyknięta do kontekstu głównej rozmowy, powodując odchylenia w odpowiedziach Codex
 3. **Nieprzewidywalne zachowanie**: Ponieważ zanieczyszczenie kontekstu jest zachowaniem po stronie serwera, klient nie może go wykryć ani kontrolować
 
 ## Wnioski
@@ -41,6 +41,6 @@ Ponieważ żądania tłumaczenia ponownie wykorzystywały ten sam token sesji, s
 ## Odnośniki
 
 - [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/pl/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — Najlepsza Maszyna Spełniająca Życzenia
+# UltraPlan — The Ultimate Wishing Machine
 
-## Czym jest UltraPlan
+## What is UltraPlan
 
-UltraPlan to **zlokalizowana implementacja** natywnego polecenia `/ultraplan` Claude Code przez cc-viewer. Pozwala na korzystanie z pełnych możliwości `/ultraplan` w lokalnym środowisku **bez konieczności uruchamiania oficjalnej zdalnej usługi Claude**, kierując Claude Code do realizacji złożonych zadań planowania i implementacji przy użyciu **współpracy wielu agentów**.
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
-W porównaniu ze zwykłym trybem Plan lub Agent Team, UltraPlan potrafi:
-- Automatycznie oceniać złożoność zadania i wybierać optymalną strategię planowania
-- Wdrażać wielu równoległych agentów do eksploracji bazy kodu z różnych wymiarów
-- Włączać badania zewnętrzne (webSearch) w celu poznania najlepszych praktyk branżowych
-- Automatycznie tworzyć Zespół Code Review po wykonaniu planu w celu przeglądu kodu
-- Tworzyć kompletną zamkniętą pętlę **Plan → Wykonanie → Przegląd → Naprawa**
+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
 
 ---
 
-## Ważne uwagi
+## Important Notes
 
-### 1. UltraPlan nie jest wszechmocny
-UltraPlan to potężniejsza maszyna spełniająca życzenia, ale to nie znaczy, że każde życzenie może być spełnione. Jest potężniejszy niż Plan i Agent Team, ale nie może bezpośrednio „zarabiać pieniędzy". Rozważ rozsądną granulację zadań — dziel duże cele na wykonalne średniej wielkości zadania zamiast próbować osiągnąć wszystko za jednym razem.
+### 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. Obecnie najskuteczniejszy dla projektów programistycznych
-Szablony i przepływy pracy UltraPlan są głęboko zoptymalizowane dla projektów programistycznych. Inne scenariusze (dokumentacja, analiza danych itp.) można wypróbować, ale warto poczekać na przyszłe wersje z odpowiednimi adaptacjami.
+### 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. Czas wykonania i wymagania okna kontekstu
-- Pomyślne uruchomienie UltraPlan zazwyczaj trwa **30 minut lub więcej**
-- Wymaga, aby MainAgent posiadał duże okno kontekstu (zalecany model Opus z kontekstem 1M)
-- Jeśli masz tylko model 200K, **upewnij się, że wykonasz `/clear` kontekstu przed uruchomieniem**
-- Polecenie `/compact` Claude Code działa słabo, gdy okno kontekstu jest niewystarczające — unikaj wyczerpania miejsca
-- Utrzymanie wystarczającej przestrzeni kontekstu jest kluczowym warunkiem pomyślnego wykonania 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
 
-Jeśli masz jakiekolwiek pytania lub sugestie dotyczące zlokalizowanego UltraPlan, zapraszamy do otwarcia [Issues na GitHub](https://github.com/anthropics/claude-code/issues), aby dyskutować i współpracować.
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
-## Jak to działa
+## How It Works
 
-UltraPlan oferuje dwa tryby działania:
+UltraPlan offers two operating modes:
 
-### Tryb Automatyczny
-Automatycznie analizuje złożoność zadania (wynik 4-12) i kieruje do różnych strategii:
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| Trasa | Wynik | Strategia |
-|-------|-------|-----------|
-| Trasa A | 4-6 | Lekkie planowanie z bezpośrednią eksploracją kodu |
-| Trasa B | 7-9 | Planowanie z diagramami strukturalnymi (Mermaid / ASCII) |
-| Trasa C | 10-12 | Eksploracja wieloagentowa + zamknięta pętla przeglądu |
+| 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 |
 
-### Tryb Wymuszony
-Bezpośrednio aktywuje pełny wieloagentowy przepływ pracy Trasy C:
-1. Wdrożenie do 5 równoległych agentów do jednoczesnej eksploracji bazy kodu (architektura, identyfikacja plików, ocena ryzyka itp.)
-2. Opcjonalne wdrożenie agenta badawczego do zbadania rozwiązań branżowych przez webSearch
-3. Synteza wszystkich odkryć agentów w szczegółowy plan implementacji
-4. Wdrożenie agenta przeglądowego do dokładnego zbadania planu z wielu perspektyw
-5. Wykonanie planu po zatwierdzeniu
-6. Automatyczne utworzenie Zespołu Code Review w celu walidacji jakości kodu po implementacji
+### 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/pt-BR/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Contexto
 
-O MainAgent do Claude Code utiliza um mecanismo de envio de contexto completo — cada requisição carrega o histórico completo da conversa, system prompt, definições de ferramentas, etc. Isso significa que, conforme a conversa avança, o corpo da requisição se torna cada vez maior, e visualizar o Body bruto dificulta identificar rapidamente "o que foi adicionado nesta rodada".
+O MainAgent do Codex utiliza um mecanismo de envio de contexto completo — cada requisição carrega o histórico completo da conversa, system prompt, definições de ferramentas, etc. Isso significa que, conforme a conversa avança, o corpo da requisição se torna cada vez maior, e visualizar o Body bruto dificulta identificar rapidamente "o que foi adicionado nesta rodada".
 
 O Body Diff JSON foi criado exatamente para resolver esse problema: ele compara automaticamente os bodies de duas requisições MainAgent consecutivas, extraindo a parte incremental, permitindo que você veja claramente o conteúdo efetivamente adicionado nesta requisição.
 
@@ -22,7 +22,7 @@ O Body Diff JSON foi criado exatamente para resolver esse problema: ele compara
 Em uma rodada normal de conversa, o Body Diff JSON geralmente contém apenas:
 - `messages`: 1~2 mensagens adicionadas (a entrada do usuário + a resposta do assistente da rodada anterior)
 
-Se você vir alterações em campos como `system`, `tools`, `model` no diff, significa que houve mudança de configuração nesta rodada, o que frequentemente também é a causa da reconstrução de cache.
+Se você vir alterações em campos como `system`, `tools`, `model` no diff, significa que houve mudança de configuração nesta rodada.
 
 ## Como Usar
 

package/concepts/pt-BR/BodyFields.md

@@ -1,42 +1,39 @@
-# Descrição dos campos do Request Body
+# Request Body Fields
 
-Descrição dos campos de nível superior do corpo da requisição da API Claude `/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.
 
-## Lista de campos
+## Field List
 
-| Campo | Tipo | Descrição |
-|-------|------|-----------|
-| **model** | string | Nome do modelo utilizado, como `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Histórico de mensagens da conversa. Cada mensagem contém `role` (user/assistant) e `content` (um array de blocos: texto, imagens, tool_use, tool_result etc.) |
-| **system** | array | System prompt. Contém as instruções principais do Codex, instruções de uso de ferramentas, informações do ambiente, conteúdo do CLAUDE.md etc. Blocos com `cache_control` são armazenados em cache através do prompt caching |
-| **tools** | array | Lista de definições de ferramentas disponíveis. Cada ferramenta contém `name`, `description` e `input_schema` (JSON Schema). O MainAgent tipicamente possui 20+ ferramentas, enquanto SubAgents possuem apenas algumas |
-| **metadata** | object | Metadados da requisição, tipicamente contém `user_id` para identificação do usuário |
-| **max_tokens** | number | Número máximo de tokens por resposta do modelo, como `16000`, `64000` |
-| **thinking** | object | Configuração do pensamento estendido. `type: "enabled"` ativa o modo de pensamento, `budget_tokens` controla o limite de tokens para o pensamento |
-| **context_management** | object | Configuração do gerenciamento de contexto. `truncation: "auto"` permite que o Codex trunque automaticamente históricos de mensagens muito longos |
-| **output_config** | object | Configuração de saída, como configurações de `format` |
-| **stream** | boolean | Se as respostas em streaming estão habilitadas. O Codex sempre utiliza `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 |
 
-## Estrutura de messages
+## input Structure
 
-O `content` de cada mensagem é um array de blocos com os seguintes tipos comuns:
+When `input` is an array, each input item usually contains `role` and `content`. `content` can be an array of blocks. Common types include:
 
-- **text**: Conteúdo de texto normal
-- **tool_use**: O modelo invoca uma ferramenta (contém `name`, `input`)
-- **tool_result**: Resultado da execução da ferramenta (contém `tool_use_id`, `content`)
-- **image**: Conteúdo de imagem (base64 ou URL)
-- **thinking**: Processo de pensamento do modelo (modo de pensamento estendido)
+- **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)
 
-## Estrutura de system
+## instructions Structure
 
-O array do system prompt tipicamente contém:
+`instructions` typically contains:
 
-1. **Instruções principais do agent** ("You are Codex...")
-2. **Especificações de uso de ferramentas**
-3. **Conteúdo do CLAUDE.md** (instruções em nível de projeto)
-4. **Lembretes de skills** (skills reminder)
-5. **Informações do ambiente** (OS, shell, status do git etc.) — Na verdade, o Codex depende fortemente do git. Se existir um repositório git no projeto, o Codex consegue demonstrar uma compreensão melhor do projeto, incluindo a capacidade de buscar alterações remotas e históricos de commits para auxiliar na análise
-
-Blocos marcados com `cache_control: { type: "ephemeral" }` são armazenados em cache pela API da Anthropic por 5 minutos. Quando o cache é utilizado, a cobrança é feita por `cache_read_input_tokens` (muito inferior a `input_tokens`).
-
-> **Nota**: Para clientes especiais como o Codex, o servidor da Anthropic na verdade não depende completamente do atributo `cache_control` na requisição para determinar o comportamento de cache. O servidor executa automaticamente estratégias de cache para campos específicos (como system prompt e definições de ferramentas), mesmo quando a requisição não contém explicitamente o marcador `cache_control`. Portanto, quando você não encontrar esse atributo no corpo da requisição, não há motivo para estranhamento — o servidor já realizou as operações de cache nos bastidores, sem expor essa informação ao cliente. Isso é uma espécie de entendimento tácito entre o Codex e a API da Anthropic.
+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