# Estado actual observado

> **ESTADO HISTÓRICO SUPERADO.** Esta fotografía corresponde a la aplicación anterior al runtime actual. La fuente vigente es `../CODEX-SUITE-STATUS.md`.

Este documento describe el entorno observado durante la preparación del paquete. Debe verificarse de nuevo en el proyecto destino.

## Interfaz observada

La ruta de desarrollo era `/codex-suite` y mostraba una página titulada `Codex Suite - Chat Integrado` con:

- Sidebar de configuración.
- Botón `Cargar` para leer configuración.
- Chat central con historial.
- Input de una línea y botón `Enviar`.
- Estado `Conectado`/`Desconectado`.

## Cliente observado

El frontend hacía peticiones a `/api/codex`:

- `GET /config`
- `GET /history?limit=30`
- `POST /message`

Usaba el header `x-bridge-token`. La implementación observada derivaba el token desde la query string, `localStorage` o un valor fallback en JavaScript. Esto es un riesgo crítico: el nuevo cliente no debe contener fallback ni token en el navegador.

El `POST /message` enviaba `{ message: string }`, esperaba una respuesta JSON completa y añadía la respuesta al historial. No era streaming ni un ciclo de herramientas visible.

## Configuración observada

El bridge exponía configuración con un proveedor compatible con Responses API, un modelo configurado y workspaces de confianza. También declaraba sandbox elevado en Windows. La configuración exacta debe leerse desde el servidor y no debe mostrarse con secretos.

## Consecuencia

La migración mínima debe conservar temporalmente el bridge actual, pero reemplazar el flujo de respuesta única por un backend de runs. Si el host tiene acceso a `codex app-server`, usar su protocolo en lugar de simular herramientas con texto.