cx-viewer 1.0.3 → 1.0.4

package/concepts/no/Teammate.md

@@ -1,26 +1,26 @@
 # Teammate
 
-## Definisjon
+## Definition
 
-Teammate er en samarbeidende agent i Claude Code Agent Team-modus. Når hovedagenten oppretter et team via `TeamCreate` og genererer teammates ved hjelp av `Agent`-verktøyet, kjører hver teammate som en uavhengig agentprosess med sitt eget kontekstvindu og verktøysett, og kommuniserer 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.
 
-## Forskjeller fra SubAgent
+## Differences from SubAgent
 
-| Egenskap | Teammate | SubAgent |
-|----------|----------|----------|
-| Livssyklus | Vedvarende, kan motta flere meldinger | Engangsoppgave, destrueres etter fullførelse |
-| Kommunikasjon | SendMessage toveismeldinger | Forelder→barn enveiskall, returnerer resultat |
-| Kontekst | Uavhengig fullstendig kontekst, bevares på tvers av runder | Isolert oppgavekontekst |
-| Samarbeidsmodell | Teamsamarbeid, kan kommunisere innbyrdes | Hierarkisk struktur, interagerer kun med foreldreagent |
-| Oppgavetype | Komplekse flertrinnsoppgaver | Enkeltoppgaver som søk og utforskning |
+| 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 |
 
-## Atferd
+## Behavior
 
-- Opprettes av hovedagenten (team lead) via `Agent`-verktøyet og tildeles et `team_name`
-- Deler oppgaveliste via `TaskList` / `TaskGet` / `TaskUpdate`
-- Går i idle-tilstand etter hver utførelsesrunde og venter på å bli vekket av nye meldinger
-- Kan avsluttes 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 av statistikkpanelet
+## Stats Panel Description
 
-Teammate-statistikkpanelet viser antall API-kall for hver teammate. Kolonnen `Name` er teammate-navnet (f.eks. `reviewer-security`, `reviewer-pipeline`), og kolonnen `Antall` er det totale antallet API-forespørsler generert av den aktuelle teammatien.
+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/no/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 rekkefølgen gjenspeiler nøyaktig **Anthropic API-ens KV-Cache-prefiks-sekvens**.
+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-prefiks-sekvens
+## Request Context Layout
 
-Når Anthropic's API bygger opp KV-Cache, setter den sammen konteksten til et prefiks i denne **faste rekkefølgen**:
+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)   │
 └─────────────────────────────────────────────────┘
 ```
 
-Dette betyr at **Tools befinner seg før System Prompt helt i begynnelsen av cache-prefikset**.
+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 høyere cache-vekt enn System?
+## Why Tools Often Matter Most
 
-Ved KV-Cache-prefiksmatchning er **tidlig innhold mer kritisk** — enhver endring ugyldiggjør alt som kommer etter:
+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. **Prefiksmatchning starter fra begynnelsen**: KV-Cache sammenligner den gjeldende forespørselen med det bufrede prefikset token for token fra starten. I det øyeblikket et avvik oppdages, ugyldiggjøres alt etterfølgende innhold.
+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 endres = hele cachen ugyldiggjøres**: Siden Tools kommer først, vil enhver endring i verktøydefinisjoner (selv å legge til eller fjerne ett enkelt MCP-tool) **bryte prefikset helt fra starten**, og ugyldiggjøre all bufret 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 endres = Messages-cache ugyldiggjøres**: System Prompt befinner seg i midten, så dens endringer ugyldiggjør bare den etterfølgende Messages-delen.
+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 endres = bare halen påvirkes**: Messages er på slutten, så å legge til nye meldinger ugyldiggjør bare et lite avsluttende segment — cache for Tools og System forblir 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 |
 
-| Endringstype | Cache-påvirkning | Typisk scenario |
-|--------------|-----------------|-----------------|
-| Tool lagt til/fjernet | **Full ugyldiggjøring** | MCP server tilkobling/frakobling, IDE-plugin av/på |
-| System Prompt-endring | Messages-cache tapt | CLAUDE.md-redigering, system reminder-injeksjon |
-| Ny melding lagt til | Bare hale-inkrement | Normal samtaleflyt (vanligst, billigst) |
+## Why Are Tool Definitions Placed Before the "Brain"?
 
-Dette er grunnen til at `tools_change` i [CacheRebuild](CacheRebuild.md) typisk er den dyreste gjenoppbyggingsårsaken — den bryter prefikskjeden helt fremst.
+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 plasseres verktøydefinisjoner 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 et teknisk faktum at Tools kommer først. Men fra et kognitivt designperspektiv er denne rekkefølgen like logisk — **Tools er hender og føtter, 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, må man oppfatte hvilke lemmer og verktøy man har tilgjengelig. Et spedbarn forstår ikke først reglene i verden (System) for så å lære å gripe — det oppfatter først at det har hender og føtter, og forstår gradvis reglene gjennom samspill med omgivelsene. På samme måte må en LLM vite hvilke verktøy den kan kalle (lese filer, skrive kode, søke, utføre kommandoer) før den mottar oppgaveinstruksjoner (System Prompt), slik at den nøyaktig kan vurdere "hva kan jeg gjøre" og "hvordan bør jeg gjøre det" ved behandling av instruksjonene.
+**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 fortelle modellen "oppgaven din er å refaktorere denne modulen", deretter "du har Read, Edit, Bash-verktøy" — ville modellen mangle kritisk informasjon om sine kapabilitetsgrenser ved forståelse av oppgaven, noe som potensielt kunne føre til urealistiske planer eller overseing av tilgjengelige tilnærminger.
+## Why Are MCP Tools Also in This Position?
 
-**Kjenn kortene dine før du bestemmer deg for hvordan du spiller.** Dette er den kognitive logikken bak at Tools plasseres 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-verktøy også på denne posisjonen?
+### MCP Advantages
 
-MCP-verktøy (Model Context Protocol) plasseres, som innebygde verktøy, helt i starten av Tools-området. Å forstå MCPs posisjon i konteksten hjelper med å vurdere de reelle fordelene og kostnadene.
+- **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-fordeler
+### 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
 
-- **Kapabilitetsutvidelse**: MCP lar modeller tilgå eksterne tjenester (databasespørringer, API-kall, IDE-operasjoner, nettleserstyring osv.), og overskrider grensene for innebygde verktøy
-- **Åpent økosystem**: Hvem som helst kan implementere en MCP-server; modellen oppnår nye kapabiliteter uten re-trening
-- **On-demand-lasting**: MCP-servere kan selektivt kobles til/fra etter oppgavescenario, med fleksibel sammensetning av verktøysett
+### Practical Recommendations
 
-### MCP-kostnader
+| 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-dreper**: Hvert MCP-verktøys JSON Schema-definisjon sammenkjedes i starten av KV-Cache-prefikset. Tillegg eller fjerning av ett MCP-verktøy = **hele cachen invalidert fra starten**. Hyppig tilkobling/frakobling av MCP-servere reduserer cache-treffraten drastisk
-- **Prefiks-oppblåsing**: MCP-verktøyers Schemas er typisk større enn innebygde verktøy (detaljerte parameterbeskrivelser, enum-verdier osv.). Mange MCP-verktøy øker token-antallet i Tools-området betydelig og innsnevrer kontekstrommet for Messages
-- **Latens-overhead**: MCP-verktøykall krever inter-prosesskommunikasjon (JSON-RPC over stdio/SSE), en størrelsesorden tregere enn innebygde funksjonskall
-- **Stabilitetsrisiko**: MCP-servere er eksterne prosesser som kan krasje, time ut eller returnere uventede formater, og krever ekstra feilhåndtering
-
-### Praktiske anbefalinger
-
-| Scenario | Anbefaling |
-|----------|-----------|
-| Lange samtaler, hyppig interaksjon | Minimér antallet MCP-verktøy for å beskytte cache-prefiks-stabiliteten |
-| Korte oppgaver, engangsoperasjoner | Bruk MCP-verktøy fritt; cache-påvirkningen er begrenset |
-| Hyppig tillegg/fjerning av MCP-servere | Hver endring utløser full cache-gjenoppbygging; vurder å fastlåse verktøysettet |
-| Overdimensjonerte Tool Schemas | Beskjær beskrivelser og enums for å redusere prefiks-tokenforbruk |
-
-I cc-viewers Context-panel vises MCP-verktøy sammen med innebygde verktøy i Tools-området, noe som gir et klart overblikk over hvert verktøys Schema-størrelse og bidrag til cache-prefikset.
+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/no/TranslateContextPollution.md

@@ -2,7 +2,7 @@
 
 ## Bakgrunn
 
-CC-Viewer inkluderer en innebygd oversettelsesfunksjon (`POST /api/translate`) drevet av Anthropic Messages API. I den tidlige implementeringen gjenbrukte oversettelsesforespørsler bufrede autentiseringsopplysninger fra Claude Code-sesjonen — inkludert både `x-api-key`- og `authorization`-headere. Dette forårsaket et subtilt, men alvorlig problem: oversettelsesresultater returnerte ofte irrelevant innhold.
+CC-Viewer inkluderer en innebygd oversettelsesfunksjon (`POST /api/translate`) drevet av Anthropic Messages API. I den tidlige implementeringen gjenbrukte oversettelsesforespørsler bufrede autentiseringsopplysninger fra Codex-sesjonen — inkludert både `x-api-key`- og `authorization`-headere. Dette forårsaket et subtilt, men alvorlig problem: oversettelsesresultater returnerte ofte irrelevant innhold.
 
 ## Rotårsak
 
@@ -13,24 +13,24 @@ Anthropic API støtter to autentiseringsmetoder:
 | Metode | Header | Typisk kilde | Egenskaper |
 |--------|--------|--------------|------------|
 | API-nøkkel | `x-api-key: sk-ant-...` | Miljøvariabel / Console | Tilstandsløs, hver forespørsel er uavhengig |
-| OAuth-token | `authorization: Bearer sessionToken` | Claude Code abonnementsinnlogging | Sesjonsbundet, serveren opprettholder konteksttilknytning |
+| OAuth-token | `authorization: Bearer sessionToken` | Codex abonnementsinnlogging | Sesjonsbundet, serveren opprettholder konteksttilknytning |
 
 Den avgjørende forskjellen: **API-nøkler er tilstandsløse** — hver forespørsel er fullstendig uavhengig; mens **OAuth-sesjonstokens er tilstandsbaserte** — Anthropic-serveren knytter forespørsler med samme token til samme sesjonskontekst.
 
 ### Forurensningskjede
 
-Når Claude Code bruker OAuth-abonnementsinnlogging, ser autentiseringsflyten slik ut:
+Når Codex bruker OAuth-abonnementsinnlogging, ser autentiseringsflyten slik ut:
 
 ```
-Claude Code hovedsamtale ──(authorization: Bearer sessionToken)──→ Anthropic API
+Codex hovedsamtale ──(authorization: Bearer sessionToken)──→ Anthropic API
                                                                       ↑
 CC-Viewer oversettelsesforespørsel ──(authorization: Bearer sessionToken)──→ Anthropic API
 ```
 
-Siden oversettelsesforespørsler gjenbrukte det samme sesjonstokenet, kan Anthropic-serveren knytte oversettelsesforespørsler til Claude Codes hovedsamtalekontekst. Dette fører til:
+Siden oversettelsesforespørsler gjenbrukte det samme sesjonstokenet, kan Anthropic-serveren knytte oversettelsesforespørsler til Codexs hovedsamtalekontekst. Dette fører til:
 
-1. **Oversettelsesresultater påvirket av hovedsamtalens kontekst**: Oversettelsesforespørselens systemprompt er «du er en oversetter», men serverkonteksten inneholder fortsatt Claude Codes samtalehistorikk, som potensielt kan forstyrre modellen
-2. **Hovedsamtalen forstyrret av oversettelsesforespørsler**: Innhold fra oversettelsesforespørsler (UI-tekstfragmenter) kan bli injisert i hovedsamtalens kontekst, noe som får Claude Codes svar til å avvike
+1. **Oversettelsesresultater påvirket av hovedsamtalens kontekst**: Oversettelsesforespørselens systemprompt er «du er en oversetter», men serverkonteksten inneholder fortsatt Codexs samtalehistorikk, som potensielt kan forstyrre modellen
+2. **Hovedsamtalen forstyrret av oversettelsesforespørsler**: Innhold fra oversettelsesforespørsler (UI-tekstfragmenter) kan bli injisert i hovedsamtalens kontekst, noe som får Codexs svar til å avvike
 3. **Uforutsigbar oppførsel**: Siden kontekstforurensning er oppførsel på serversiden, kan klienten ikke oppdage eller kontrollere det
 
 ## Erfaringer
@@ -41,6 +41,6 @@ Siden oversettelsesforespørsler gjenbrukte det samme sesjonstokenet, kan Anthro
 ## Referanser
 
 - [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/no/UltraPlan.md

@@ -1,55 +1,55 @@
-# UltraPlan — Den Ultimate Ønskemaskinen
+# UltraPlan — The Ultimate Wishing Machine
 
-## Hva er UltraPlan
+## What is UltraPlan
 
-UltraPlan er cc-viewers **lokaliserte implementering** av Claude Codes native `/ultraplan`-kommando. Den lar deg bruke de fulle mulighetene til `/ultraplan` i ditt lokale miljø **uten å måtte starte Claudes offisielle fjerntjeneste**, og veileder Claude Code til å utføre komplekse planleggings- og implementeringsoppgaver ved hjelp av **multiagent-samarbeid**.
+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 vanlig Plan-modus eller Agent Team, kan UltraPlan:
-- Automatisk vurdere oppgavekompleksitet og velge den optimale planleggingsstrategien
-- Distribuere flere parallelle agenter for å utforske kodebasen fra ulike dimensjoner
-- Inkludere ekstern forskning (webSearch) for bransjens beste praksis
-- Automatisk sette sammen et Code Review Team etter plangjennomføring for kodegjennomgang
-- Danne en komplett lukket sløyfe **Plan → Utfør → Gjennomgå → Fiks**
+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
 
 ---
 
-## Viktige merknader
+## Important Notes
 
-### 1. UltraPlan er ikke allmektig
-UltraPlan er en kraftigere ønskemaskin, men det betyr ikke at ethvert ønske kan oppfylles. Den er kraftigere enn Plan og Agent Team, men kan ikke direkte «tjene penger for deg». Vurder rimelig oppgavegranularitet — del store mål inn i gjennomførbare mellomstore oppgaver i stedet for å prøve å oppnå alt på 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. For øyeblikket mest effektiv for programmeringsprosjekter
-UltraPlans maler og arbeidsflyter er dypt optimalisert for programmeringsprosjekter. Andre scenarier (dokumentasjon, dataanalyse osv.) kan prøves, men du bør kanskje vente på tilpasninger i fremtidige versjoner.
+### 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. Utføringstid og krav til kontekstvindu
-- En vellykket UltraPlan-kjøring tar vanligvis **30 minutter eller mer**
-- Krever at MainAgent har et stort kontekstvindu (Opus-modell med 1M kontekst anbefales)
-- Hvis du bare har en 200K-modell, **sørg for å kjøre `/clear` på konteksten før kjøring**
-- Claude Codes `/compact` fungerer dårlig når kontekstvinduet er utilstrekkelig — unngå å gå tom for plass
-- Å opprettholde tilstrekkelig kontekstplass er en kritisk forutsetning for vellykket UltraPlan-gjennomføring
+### 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 spørsmål eller forslag om den lokaliserte UltraPlan, er du velkommen til å åpne [Issues på GitHub](https://github.com/anthropics/claude-code/issues) for å diskutere og samarbeide.
+If you have any questions or suggestions about the localized UltraPlan workflow, open an issue in the CX Viewer project to discuss and collaborate.
 
 ---
 
-## Hvordan det fungerer
+## How It Works
 
-UltraPlan tilbyr to driftsmoduser:
+UltraPlan offers two operating modes:
 
-### Automatisk modus
-Analyserer automatisk oppgavekompleksitet (poengsum 4-12) og ruter til ulike strategier:
+### Auto Mode
+Automatically analyzes task complexity (score 4-12) and routes to different strategies:
 
-| Rute | Poengsum | Strategi |
-|------|----------|----------|
-| Rute A | 4-6 | Lettvektsplanlegging med direkte kodeutforskning |
-| Rute B | 7-9 | Planlegging med strukturelle diagrammer (Mermaid / ASCII) |
-| Rute C | 10-12 | Multiagent-utforskning + lukket gjennomgangssløyfe |
+| 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 modus
-Aktiverer direkte den fullstendige Rute C multiagent-arbeidsflyten:
-1. Distribuere opptil 5 parallelle agenter for å utforske kodebasen samtidig (arkitektur, filidentifikasjon, risikovurdering osv.)
-2. Valgfritt distribuere en forskningsagent for å undersøke bransjeløsninger via webSearch
-3. Syntetisere alle agentfunn til en detaljert implementeringsplan
-4. Distribuere en gjennomgangsagent for å granske planen fra flere perspektiver
-5. Utføre planen etter godkjenning
-6. Automatisk sette sammen et Code Review Team for å validere kodekvalitet etter 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/pl/BodyDiffJSON.md

@@ -2,7 +2,7 @@
 
 ## Kontekst
 
-MainAgent w Claude Code stosuje mechanizm wysyłania pełnego kontekstu — każde żądanie zawiera kompletną historię rozmowy, system prompt, definicje narzędzi itp. Oznacza to, że w miarę postępu rozmowy treść żądania staje się coraz większa, a bezpośrednie przeglądanie surowego Body utrudnia szybkie zlokalizowanie „co dokładnie zostało dodane w tej turze".
+MainAgent w Codex stosuje mechanizm wysyłania pełnego kontekstu — każde żądanie zawiera kompletną historię rozmowy, system prompt, definicje narzędzi itp. Oznacza to, że w miarę postępu rozmowy treść żądania staje się coraz większa, a bezpośrednie przeglądanie surowego Body utrudnia szybkie zlokalizowanie „co dokładnie zostało dodane w tej turze".
 
 Body Diff JSON rozwiązuje właśnie ten problem: automatycznie porównuje treści dwóch kolejnych żądań MainAgent, wyodrębnia przyrostowe zmiany i pozwala od razu zobaczyć, co faktycznie zostało dodane w bieżącym żądaniu.
 
@@ -22,7 +22,7 @@ Body Diff JSON rozwiązuje właśnie ten problem: automatycznie porównuje treś
 W normalnej turze rozmowy Body Diff JSON zazwyczaj zawiera tylko:
 - `messages`: 1–2 nowe wiadomości (dane wejściowe użytkownika + odpowiedź asystenta z poprzedniej tury)
 
-Jeśli w diff pojawiają się zmiany pól `system`, `tools`, `model` itp., oznacza to zmianę konfiguracji w bieżącej turze, co często jest również przyczyną przebudowy cache.
+Jeśli w diff pojawiają się zmiany pól `system`, `tools`, `model` itp., oznacza to zmianę konfiguracji w bieżącej turze.
 
 ## Sposób użycia
 

package/concepts/pl/BodyFields.md

@@ -1,42 +1,39 @@
-# Opis pol Request Body
+# Request Body Fields
 
-Opis pol najwyzszego poziomu w request body Claude API `/v1/messages`.
+Field descriptions for CX-Viewer's normalized Codex request body. The original source may be OpenAI Responses API traffic, Codex app-server notifications, or Codex SDK events; CX-Viewer maps them into one stable viewer shape.
 
-## Lista pol
+## Field List
 
-| Pole | Typ | Opis |
-|------|------|------|
-| **model** | string | Nazwa uzytego modelu, np. `claude-opus-4-6`, `claude-sonnet-4-6` |
-| **messages** | array | Historia wiadomosci w konwersacji. Kazda wiadomosc zawiera `role` (user/assistant) i `content` (tablica blokow: tekst, obrazy, tool_use, tool_result itp.) |
-| **system** | array | System prompt. Zawiera glowne instrukcje Codex, wskazowki dotyczace uzycia narzedzi, informacje o srodowisku, zawartosc CLAUDE.md itp. Bloki z `cache_control` sa buforowane przez prompt caching |
-| **tools** | array | Lista definicji dostepnych narzedzi. Kazde narzedzie zawiera `name`, `description` i `input_schema` (JSON Schema). MainAgent ma zwykle 20+ narzedzi, SubAgent ma tylko kilka |
-| **metadata** | object | Metadane zadania, zwykle zawiera `user_id` do identyfikacji uzytkownika |
-| **max_tokens** | number | Maksymalna liczba tokenow w pojedynczej odpowiedzi modelu, np. `16000`, `64000` |
-| **thinking** | object | Konfiguracja rozszerzonego myslenia. `type: "enabled"` wlacza tryb myslenia, `budget_tokens` kontroluje gorny limit tokenow myslenia |
-| **context_management** | object | Konfiguracja zarzadzania kontekstem. `truncation: "auto"` pozwala Codex automatycznie obcinac zbyt dluga historie wiadomosci |
-| **output_config** | object | Konfiguracja wyjscia, np. ustawienia `format` |
-| **stream** | boolean | Czy wlaczyc odpowiedzi strumieniowe. Codex zawsze uzywa `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 |
 
-## Struktura messages
+## input Structure
 
-`content` kazdej wiadomosci to tablica blokow, typowe typy:
+When `input` is an array, each input item usually contains `role` and `content`. `content` can be an array of blocks. Common types include:
 
-- **text**: Zwykla zawartosc tekstowa
-- **tool_use**: Model wywoluje narzedzie (zawiera `name`, `input`)
-- **tool_result**: Wynik wykonania narzedzia (zawiera `tool_use_id`, `content`)
-- **image**: Zawartosc obrazu (base64 lub URL)
-- **thinking**: Proces myslenia modelu (tryb rozszerzonego myslenia)
+- **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)
 
-## Struktura system
+## instructions Structure
 
-Tablica system prompt zwykle zawiera:
+`instructions` typically contains:
 
-1. **Glowne instrukcje agenta** ("You are Codex...")
-2. **Zasady uzycia narzedzi**
-3. **Zawartosc CLAUDE.md** (instrukcje na poziomie projektu)
-4. **Przypomnienia o umiejetnosciach** (skills reminder)
-5. **Informacje o srodowisku** (OS, shell, status git itp.) — w rzeczywistosci Codex jest bardzo zalezny od git. Jesli projekt posiada repozytorium git, Codex moze wykazac lepsze zrozumienie projektu, w tym pobierac zdalne zmiany i historie commitow do analizy
-
-Bloki oznaczone `cache_control: { type: "ephemeral" }` sa buforowane przez Anthropic API przez 5 minut. Przy trafieniu w bufor sa rozliczane jako `cache_read_input_tokens` (znacznie taniej niz `input_tokens`).
-
-> **Uwaga**: W przypadku specjalizowanych klientow takich jak Codex, serwer Anthropic w rzeczywistosci nie polega calkowicie na atrybucie `cache_control` w zadaniu do okreslenia zachowania buforowania. Serwer automatycznie stosuje strategie buforowania dla okreslonych pol (takich jak system prompt i definicje tools), nawet jesli zadanie nie zawiera jawnie znacznika `cache_control`. Dlatego nie musisz sie dziwic, gdy nie widzisz tego atrybutu w request body — serwer juz wykonal operacje buforowania za kulisami, po prostu nie ujawnia tej informacji klientowi. To milczace porozumienie miedzy Codex a 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