cx-viewer 1.0.3 → 1.0.4

package/concepts/da/Teammate.md

@@ -2,25 +2,25 @@
 
 ## Definition
 
-Teammate er en samarbejdende agent i Claude Code Agent Team-tilstand. Når hoved-agenten opretter et team via `TeamCreate` og genererer teammates ved hjælp af `Agent`-værktøjet, kører hver teammate som en uafhængig agent-proces med sit eget kontekstvindue og værktøjssæt og kommunikerer med teammedlemmer via `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.
 
-## Forskelle fra SubAgent
+## Differences from SubAgent
 
-| Egenskab | Teammate | SubAgent |
-|----------|----------|----------|
-| Livscyklus | Vedvarende, kan modtage flere beskeder | Engangsopgave, destrueres efter fuldførelse |
-| Kommunikation | SendMessage tovejsbeskeder | Forælder→barn envejskald, returnerer resultat |
-| Kontekst | Uafhængig fuld kontekst, bevares på tværs af ture | Isoleret opgavekontekst |
-| Samarbejdsmodel | Teamsamarbejde, kan kommunikere indbyrdes | Hierarkisk struktur, interagerer kun med forælder-agent |
-| Opgavetype | Komplekse flertrinsopgaver | Enkeltopgaver som søgning og udforskning |
+| 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 |
 
-## Adfærd
+## Behavior
 
-- Oprettes af hoved-agenten (team lead) via `Agent`-værktøjet og tildeles et `team_name`
-- Deler opgaveliste via `TaskList` / `TaskGet` / `TaskUpdate`
-- Går i idle-tilstand efter hver udførelsesrunde og venter på at blive vækket af nye beskeder
-- Kan afsluttes elegant via `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`
 
-## Forklaring af statistikpanelet
+## Stats Panel Description
 
-Teammate-statistikpanelet viser antallet af API-kald for hver teammate. Kolonnen `Name` er teammate-navnet (f.eks. `reviewer-security`, `reviewer-pipeline`), og kolonnen `Antal` er det samlede antal API-anmodninger genereret af den pågældende 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/da/ToolsFirst.md

@@ -1,77 +1,71 @@
-# Hvorfor vises Tools først?
+# Why Are Tools Listed First?
 
-I cc-viewers kontekstpanel vises **Tools før System Prompt og Messages**. Denne rækkefølge afspejler præcist **Anthropic API's KV-Cache-præfikssekvens**.
+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-præfikssekvens
+## Request Context Layout
 
-Når Anthropic's API opbygger KV-Cache, sammensætter den konteksten til et præfiks i denne **faste rækkefølge**:
+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)   │
 └─────────────────────────────────────────────────┘
 ```
 
-Det betyder, at **Tools befinder sig før System Prompt helt i begyndelsen af cache-præfikset**.
+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.
 
-## Hvorfor har Tools større cache-vægt end System?
+## Why Tools Often Matter Most
 
-Ved KV-Cache-præfiksmatchning er **tidligt indhold mere kritisk** — enhver ændring ugyldiggør alt efterfølgende indhold:
+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. **Præfiksmatchning starter fra begyndelsen**: KV-Cache sammenligner den aktuelle anmodning med det cachede præfiks token for token fra starten. I det øjeblik en uoverensstemmelse opdages, ugyldiggøres alt efterfølgende indhold.
+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 ændres = hele cache ugyldiggøres**: Da Tools kommer først, vil enhver ændring i værktøjsdefinitioner (selv tilføjelse eller fjernelse af et enkelt MCP-tool) **bryde præfikset helt fra starten** og ugyldiggøre al cachet System Prompt og 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 ændres = Messages-cache ugyldiggøres**: System Prompt befinder sig i midten, så dens ændringer ugyldiggør kun den efterfølgende Messages-del.
+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 ændres = kun halen påvirkes**: Messages er i slutningen, så tilføjelse af nye beskeder ugyldiggør kun et lille afsluttende segment — Tools- og System-cache forbliver intakt.
+## Practical Impact
 
-## Praktisk betydning
+| 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 |
 
-| Ændringstype | Cache-påvirkning | Typisk scenarie |
-|--------------|-----------------|-----------------|
-| Tool tilføjet/fjernet | **Fuld ugyldiggørelse** | MCP server tilslut/frakobl, IDE-plugin til/fra |
-| System Prompt ændring | Messages-cache tabt | CLAUDE.md redigering, system reminder-injektion |
-| Ny besked tilføjet | Kun hale-tilvækst | Normal samtalegång (mest almindelig, billigst) |
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-Det er derfor `tools_change` i [CacheRebuild](CacheRebuild.md) typisk er den dyreste genopbygningsårsag — det bryder præfikskæden helt forrest.
+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.
 
-## Hvorfor placeres værktøjsdefinitioner før "hjernen"?
+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.
 
-Fra et caching-perspektiv er det en teknisk kendsgerning, at Tools kommer først. Men fra et kognitivt designperspektiv er denne rækkefølge lige så logisk — **Tools er hænder og fødder, System Prompt er hjernen**.
+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.
 
-Før man handler, skal man opfatte, hvilke lemmer og værktøjer man har til rådighed. Et spædbarn forstår ikke først verdens regler (System) og lærer derefter at gribe — det opfatter først, at det har hænder og fødder, og forstår gradvist reglerne gennem interaktion med omgivelserne. På samme måde skal en LLM vide, hvilke værktøjer den kan kalde (læse filer, skrive kode, søge, udføre kommandoer) før den modtager opgaveinstruktioner (System Prompt), så den præcist kan vurdere "hvad kan jeg gøre" og "hvordan skal jeg gøre det" ved behandling af instruktionerne.
+**Know what cards you hold before deciding how to play.** This is the cognitive logic behind Tools preceding Instructions.
 
-Hvis det var omvendt — først fortælle modellen "din opgave er at refaktorere dette modul", derefter "du har Read, Edit, Bash-værktøjer" — ville modellen mangle kritisk information om sine kapabilitetsgræenser ved forståelse af opgaven, hvilket potentielt kunne føre til urealistiske planer eller overseelse af tilgængelige tilgange.
+## Why Are MCP Tools Also in This Position?
 
-**Kend dine kort før du beslutter, hvordan du spiller.** Dette er den kognitive logik bag at Tools placeres før 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.
 
-## Hvorfor er MCP-værktøjer også på denne position?
+### MCP Advantages
 
-MCP-værktøjer (Model Context Protocol) placeres ligesom indbyggede værktøjer helt i starten af Tools-området. At forstå MCPs position i konteksten hjælper med at vurdere de reelle fordele og omkostninger.
+- **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-fordele
+### 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
 
-- **Kapabilitetsudvidelse**: MCP lader modeller tilgå eksterne tjenester (databaseforespørgsler, API-kald, IDE-operationer, browserstyring osv.), og overgår grænserne for indbyggede værktøjer
-- **Åbent økosystem**: Enhver kan implementere en MCP-server; modellen opnår nye kapabiliteter uden gentræning
-- **On-demand-indlæsning**: MCP-servere kan selektivt tilsluttes/frakobles efter opgavescenario, med fleksibel sammensætning af værktøjssæt
+### Practical Recommendations
 
-### MCP-omkostninger
+| 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 |
 
-- **Cache-dræber**: Hvert MCP-værktøjs JSON Schema-definition sammenkædes i starten af KV-Cache-præfikset. Tilføjelse eller fjernelse af ét MCP-værktøj = **hele cachen invalideret fra starten**. Hyppig tilslutning/frakobling af MCP-servere reducerer cache-hitraten drastisk
-- **Præfiks-oppustning**: MCP-værktøjers Schemas er typisk større end indbyggede værktøjer (detaljerede parameterbeskrivelser, enum-værdier osv.). Mange MCP-værktøjer øger token-antallet i Tools-området markant og indskrænker kontekstrummet til Messages
-- **Latens-overhead**: MCP-værktøjskald kræver inter-proces-kommunikation (JSON-RPC over stdio/SSE), en størrelsesorden langsommere end indbyggede funktionskald
-- **Stabilitetsrisiko**: MCP-servere er eksterne processer, der kan crashe, timeout'e eller returnere uventede formater, og kræver ekstra fejlhåndtering
-
-### Praktiske anbefalinger
-
-| Scenarie | Anbefaling |
-|----------|-----------|
-| Lange samtaler, hyppig interaktion | Minimér antallet af MCP-værktøjer for at beskytte cache-præfiks-stabiliteten |
-| Korte opgaver, engangsoperationer | Brug MCP-værktøjer frit; cache-påvirkningen er begrænset |
-| Hyppig tilføjelse/fjernelse af MCP-servere | Hver ændring udløser fuld cache-genopbygning; overvej at fastlåse værktøjssættet |
-| Overdimensionerede Tool Schemas | Beskær beskrivelser og enums for at reducere præfiks-tokenforbrug |
-
-I cc-viewers Context-panel vises MCP-værktøjer sammen med indbyggede værktøjer i Tools-området, hvilket giver et klart overblik over hvert værktøjs Schema-størrelse og bidrag til cache-præfikset.
+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/da/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## Baggrund
 
-CC-Viewer inkluderer en indbygget oversættelsesfunktion (`POST /api/translate`) drevet af Anthropic Messages API. I den tidlige implementering genbrugte oversættelsesanmodninger cachede autentificeringsoplysninger fra Claude Code-sessionen — herunder både `x-api-key` og `authorization` headers. Dette forårsagede et subtilt men alvorligt problem: oversættelsesresultater returnerede ofte irrelevant indhold.
+CC-Viewer inkluderer en indbygget oversættelsesfunktion (`POST /api/translate`) drevet af Anthropic Messages API. I den tidlige implementering genbrugte oversættelsesanmodninger cachede autentificeringsoplysninger fra Codex-sessionen — herunder både `x-api-key` og `authorization` headers. Dette forårsagede et subtilt men alvorligt problem: oversættelsesresultater returnerede ofte irrelevant indhold.
 
 ## Grundårsag
 
@@ -13,24 +13,24 @@ Anthropic API understøtter to autentificeringsmetoder:
 | Metode | Header | Typisk kilde | Karakteristika |
 |--------|--------|--------------|----------------|
 | API-nøgle | `x-api-key: sk-ant-...` | Miljøvariabel / Console | Tilstandsløs, hver anmodning er uafhængig |
-| OAuth-token | `authorization: Bearer sessionToken` | Claude Code abonnementslogin | Sessionsbundet, serveren opretholder konteksttilknytning |
+| OAuth-token | `authorization: Bearer sessionToken` | Codex abonnementslogin | Sessionsbundet, serveren opretholder konteksttilknytning |
 
 Den afgørende forskel: **API-nøgler er tilstandsløse** — hver anmodning er fuldstændig uafhængig; mens **OAuth-sessionstokens er tilstandsbaserede** — Anthropic-serveren tilknytter anmodninger med samme token til den samme sessionskontekst.
 
 ### Forureningskæde
 
-Når Claude Code bruger OAuth-abonnementslogin, ser autentificeringsflowet sådan ud:
+Når Codex bruger OAuth-abonnementslogin, ser autentificeringsflowet sådan ud:
 
 ```
-Claude Code hovedsamtale ──(authorization: Bearer sessionToken)──→ Anthropic API
+Codex hovedsamtale ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                       ↑
 CC-Viewer oversættelsesanmodning ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-Da oversættelsesanmodninger genbrugte det samme sessionstoken, kan Anthropic-serveren tilknytte oversættelsesanmodninger til Claude Codes hovedsamtalekontekst. Dette medfører:
+Da oversættelsesanmodninger genbrugte det samme sessionstoken, kan Anthropic-serveren tilknytte oversættelsesanmodninger til Codexs hovedsamtalekontekst. Dette medfører:
 
-1. **Oversættelsesresultater påvirket af hovedsamtalens kontekst**: Oversættelsesanmodningens systemprompt er "du er en oversætter", men serverkonteksten indeholder stadig Claude Codes samtalehistorik, som potentielt kan forstyrre modellen
-2. **Hovedsamtalen forstyrret af oversættelsesanmodninger**: Indhold fra oversættelsesanmodninger (UI-tekstfragmenter) kan blive injiceret i hovedsamtalens kontekst, hvilket får Claude Codes svar til at afvige
+1. **Oversættelsesresultater påvirket af hovedsamtalens kontekst**: Oversættelsesanmodningens systemprompt er "du er en oversætter", men serverkonteksten indeholder stadig Codexs samtalehistorik, som potentielt kan forstyrre modellen
+2. **Hovedsamtalen forstyrret af oversættelsesanmodninger**: Indhold fra oversættelsesanmodninger (UI-tekstfragmenter) kan blive injiceret i hovedsamtalens kontekst, hvilket får Codexs svar til at afvige
 3. **Uforudsigelig adfærd**: Da kontekstforurening er serverside-adfærd, kan klienten ikke opdage eller kontrollere det
 
 ## Erfaringer
@@ -41,6 +41,6 @@ Da oversættelsesanmodninger genbrugte det samme sessionstoken, kan Anthropic-se
 ## Referencer
 
 - [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/da/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — Den Ultimative Onskemaskine
+# UltraPlan — The Ultimate Wishing Machine
 
-## Hvad er UltraPlan
+## What is UltraPlan
 
-UltraPlan er cc-viewers **lokaliserede implementering** af Claude Codes native `/ultraplan`-kommando. Det giver dig mulighed for at bruge de fulde funktioner i `/ultraplan` i dit lokale miljo **uden at skulle starte Claudes officielle fjerntjeneste**, og guider Claude Code til at udfoere komplekse planlaegnings- og implementeringsopgaver ved hjaelp af **multi-agent-samarbejde**.
+UltraPlan is CX Viewer's **localized planning workflow** for Codex. It guides Codex through complex planning and implementation tasks using **multi-agent collaboration**.
 
-Sammenlignet med den almindelige Plan-tilstand eller Agent Team kan UltraPlan:
-- Automatisk vurdere opgavekompleksitet og vaelge den optimale planlaegningsstrategi
-- Indsaette flere parallelle agenter til at udforske kodebasen fra forskellige dimensioner
-- Inkorporere ekstern research (webSearch) for branchens bedste praksisser
-- Automatisk sammensaette et Code Review Team efter planens udfoerelse til kodegennemgang
-- Danne en komplet **Plan → Execute → Review → Fix** lukket kredsloeb
+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
 
 ---
 
-## Vigtige Bemerkninger
+## Important Notes
 
-### 1. UltraPlan Er Ikke Almaegtigt
-UltraPlan er en mere kraftfuld onskemaskine, men det betyder ikke, at ethvert oenske kan opfyldes. Den er mere kraftfuld end Plan og Agent Team, men kan ikke direkte "tjene penge til dig". Overvej en rimelig opgavegranularitet — opdel store maal i udfoebare mellemstore opgaver i stedet for at proeve at opnaa alt paa en gang.
+### 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. Aktuelt Mest Effektiv til Programmeringsprojekter
-UltraPlans skabeloner og workflows er dybt optimeret til programmeringsprojekter. Andre scenarier (dokumentation, dataanalyse osv.) kan forsoges, men det kan vaere vaerd at vente paa tilpasninger i fremtidige versioner.
+### 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. Koerselstid og Krav til Kontekstvindue
-- En vellykket UltraPlan-koerelse tager typisk **30 minutter eller mere**
-- Kraever at MainAgent har et stort kontekstvindue (1M context Opus-modellen anbefales)
-- Hvis du kun har en 200K-model, **soerg for at `/clear` konteksten foer koerelse**
-- Claude Codes `/compact` fungerer daarligt, naar kontekstvinduet er utilstraekkeligt — undgaa at loebe toer for plads
-- At opretholde tilstraekkelig kontekstplads er en afgoerende forudsaetning for vellykket UltraPlan-udfoerelse
+### 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
 
-Hvis du har spoergsmaal eller forslag til den lokaliserede UltraPlan, er du velkommen til at aabne [Issues paa GitHub](https://github.com/anthropics/claude-code/issues) for at diskutere og samarbejde.
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
-## Saadan Fungerer Det
+## How It Works
 
-UltraPlan tilbyder to driftstilstande:
+UltraPlan offers two operating modes:
 
-### Automatisk Tilstand
-Analyserer automatisk opgavekompleksiteten (score 4-12) og dirigerer til forskellige strategier:
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| Rute | Score | Strategi |
-|------|-------|----------|
-| Rute A | 4-6 | Let planlaegning med direkte kodeudforskning |
-| Rute B | 7-9 | Planlaegning med strukturdiagrammer (Mermaid / ASCII) |
-| Rute C | 10-12 | Multi-agent-udforskning + gennemgangs-kredsloeb |
+| 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 |
 
-### Tvungen Tilstand
-Aktiverer direkte det fulde Rute C multi-agent-workflow:
-1. Indsaet op til 5 parallelle agenter til at udforske kodebasen samtidigt (arkitektur, filidentifikation, risikovurdering osv.)
-2. Valgfrit indsaette en research-agent til at undersoege brancheloesninger via webSearch
-3. Syntetisere alle agenternes fund til en detaljeret implementeringsplan
-4. Indsaette en gennemgangsagent til at granske planen fra flere perspektiver
-5. Udfoere planen efter godkendelse
-6. Automatisk sammensaette et Code Review Team for at validere kodekvaliteten efter implementering
+### 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/de/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Hintergrund
 
-Der MainAgent von Claude Code verwendet einen Vollkontext-Sendemechanismus – jede Anfrage enthält den vollständigen Gesprächsverlauf, System-Prompt, Tool-Definitionen usw. Das bedeutet, dass der Request-Body im Laufe des Gesprächs immer größer wird und es schwierig ist, im Roh-Body schnell zu erkennen, „was in dieser Runde tatsächlich neu hinzugekommen ist".
+Der MainAgent von Codex verwendet einen Vollkontext-Sendemechanismus – jede Anfrage enthält den vollständigen Gesprächsverlauf, System-Prompt, Tool-Definitionen usw. Das bedeutet, dass der Request-Body im Laufe des Gesprächs immer größer wird und es schwierig ist, im Roh-Body schnell zu erkennen, „was in dieser Runde tatsächlich neu hinzugekommen ist".
 
 Body Diff JSON löst genau dieses Problem: Es vergleicht automatisch die Bodies zweier aufeinanderfolgender MainAgent-Anfragen, extrahiert die inkrementellen Teile und zeigt auf einen Blick, welche Inhalte in dieser Anfrage tatsächlich neu sind.
 
@@ -22,7 +22,7 @@ Body Diff JSON löst genau dieses Problem: Es vergleicht automatisch die Bodies
 In einer normalen Gesprächsrunde enthält Body Diff JSON normalerweise nur:
 - `messages`: 1–2 neue Nachrichten (Benutzereingabe + Antwort des Assistenten aus der vorherigen Runde)
 
-Wenn im Diff Änderungen an Feldern wie `system`, `tools`, `model` usw. erscheinen, bedeutet dies, dass sich die Konfiguration in dieser Runde geändert hat – was oft auch der Grund für einen Cache-Rebuild ist.
+Wenn im Diff Änderungen an Feldern wie `system`, `tools`, `model` usw. erscheinen, bedeutet dies, dass sich die Request-Konfiguration in dieser Runde geändert hat.
 
 ## Verwendung
 

package/concepts/de/BodyFields.md

@@ -1,42 +1,39 @@
-# Beschreibung der Request-Body-Felder
+# Request Body Fields
 
-Beschreibung der Top-Level-Felder des Request-Bodys der 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.
 
-## Feldliste
+## Field List
 
-| Feld | Typ | Beschreibung |
-|------|-----|--------------|
-| **model** | string | Name des verwendeten Modells, z. B. `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Nachrichtenverlauf der Konversation. Jede Nachricht enthält `role` (user/assistant) und `content` (ein Block-Array aus Text, Bildern, tool_use, tool_result usw.) |
-| **system** | array | System-Prompt. Enthält die Kernanweisungen von Codex, Anweisungen zur Tool-Nutzung, Umgebungsinformationen, CLAUDE.md-Inhalte usw. Blöcke mit `cache_control` werden durch Prompt-Caching zwischengespeichert |
-| **tools** | array | Liste der verfügbaren Tool-Definitionen. Jedes Tool enthält `name`, `description` und `input_schema` (JSON Schema). Der MainAgent hat typischerweise 20+ Tools, SubAgents nur wenige |
-| **metadata** | object | Anfrage-Metadaten, enthält typischerweise `user_id` zur Benutzeridentifikation |
-| **max_tokens** | number | Maximale Token-Anzahl pro Modellantwort, z. B. `16000`, `64000` |
-| **thinking** | object | Konfiguration des erweiterten Denkens. `type: "enabled"` aktiviert den Denkmodus, `budget_tokens` steuert das Token-Limit für das Denken |
-| **context_management** | object | Konfiguration der Kontextverwaltung. `truncation: "auto"` erlaubt Codex, zu lange Nachrichtenverläufe automatisch zu kürzen |
-| **output_config** | object | Ausgabekonfiguration, z. B. `format`-Einstellungen |
-| **stream** | boolean | Ob Streaming-Antworten aktiviert sind. Codex verwendet immer `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
 
-Der `content` jeder Nachricht ist ein Block-Array mit folgenden gängigen Typen:
+When `input` is an array, each input item usually contains `role` and `content`. `content` can be an array of blocks. Common types include:
 
-- **text**: Normaler Textinhalt
-- **tool_use**: Modell ruft ein Tool auf (enthält `name`, `input`)
-- **tool_result**: Ergebnis der Tool-Ausführung (enthält `tool_use_id`, `content`)
-- **image**: Bildinhalt (Base64 oder URL)
-- **thinking**: Denkprozess des Modells (erweiterter Denkmodus)
+- **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
 
-Das System-Prompt-Array enthält typischerweise:
+`instructions` typically contains:
 
-1. **Kern-Agent-Anweisungen** ("You are Codex...")
-2. **Regeln zur Tool-Nutzung**
-3. **CLAUDE.md-Inhalte** (projektspezifische Anweisungen)
-4. **Skill-Hinweise** (Skills Reminder)
-5. **Umgebungsinformationen** (OS, Shell, Git-Status usw.) — Tatsächlich ist Codex stark von Git abhängig. Wenn ein Git-Repository im Projekt vorhanden ist, kann Codex ein besseres Verständnis des Projekts zeigen, einschließlich der Möglichkeit, Remote-Änderungen und Commit-Verläufe zur Analyse heranzuziehen
-
-Blöcke mit der Markierung `cache_control: { type: "ephemeral" }` werden von der Anthropic API 5 Minuten lang zwischengespeichert. Bei einem Cache-Treffer wird mit `cache_read_input_tokens` abgerechnet (deutlich günstiger als `input_tokens`).
-
-> **Hinweis**: Bei speziellen Clients wie Codex verlässt sich der Anthropic-Server tatsächlich nicht vollständig auf das `cache_control`-Attribut in der Anfrage, um das Caching-Verhalten zu bestimmen. Der Server führt automatisch Caching-Strategien für bestimmte Felder aus (wie System-Prompt, Tool-Definitionen), auch wenn die Anfrage keine explizite `cache_control`-Markierung enthält. Wenn Sie dieses Attribut also nicht im Request-Body sehen, brauchen Sie sich nicht zu wundern — der Server hat das Caching bereits im Hintergrund durchgeführt, ohne diese Information dem Client offenzulegen. Dies ist eine Art stillschweigende Übereinkunft zwischen Codex und der 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