# Codex Suite Premium · roadmap canónico

> Corte técnico: **8 de agosto de 2026**.
>
> Este documento es la fuente canónica del orden futuro. Describe capacidades verificadas, deuda, fases y criterios de aceptación. No convierte una idea en funcionalidad ni autoriza cambios fuera de `cursor-mobile-bridge`.
>
> Estado vigente: [CODEX-SUITE-STATUS.md](CODEX-SUITE-STATUS.md) · uso: [CODEX-SUITE-MANUAL.md](CODEX-SUITE-MANUAL.md) · estrategia: [CODEX-SUITE-BUSINESS-PLAN.md](CODEX-SUITE-BUSINESS-PLAN.md) · seguridad: [CODEX-SUITE-SECURITY-BACKLOG.md](CODEX-SUITE-SECURITY-BACKLOG.md).

## 1. Cómo leer este roadmap

Estados:

- **Completado**: backend real, interfaz o contrato público, seguridad mínima, pruebas ejecutadas y documentación.
- **Parcial v1**: aporta valor real, pero todavía carece de alguna garantía necesaria para considerarse premium o comercial.
- **Pendiente**: no existe implementación funcional completa.
- **Investigación**: hipótesis que necesita prueba técnica o de producto antes de comprometer arquitectura.
- **Bloqueado**: depende de una decisión, autorización o infraestructura externa.

Prioridades:

- **P0**: fiabilidad, compatibilidad o seguridad estructural; condiciona el resto.
- **P1**: núcleo diferencial y funciones solicitadas de alto valor.
- **P2**: ampliación profesional.
- **P3**: plataforma colaborativa o comercial futura.

Cada bloque debe terminar con código, pruebas, evidencia y documentación sincronizada. No se inicia el siguiente bloque si el anterior deja una migración a medias.

### Brainstorming premium 1–11 (10 ago 2026)

Checklist operativo en [CODEX-SUITE-STATUS.md](CODEX-SUITE-STATUS.md). Oleadas A–D entregaron APIs + Control Excelencia + Diff Guardian; captajaus Oleada B en repo hermano.

## 2. Fotografía real del producto

### 2.1 Inventario demostrado

| Elemento | Estado observado |
| --- | --- |
| Producto anfitrión | Cursor Mobile Bridge, puerto principal 8095 |
| Aplicación integrada | `/codex-suite`, registrada como vecina en `/apps` |
| API propia | 85 rutas autenticadas bajo `/api/codex/*` |
| Backend Codex | 32 módulos `lib/codex-*.js` |
| Frontend | HTML, CSS y módulos ES nativos; PWA `codex-suite-shell-v36` |
| Controles principales | 15 vistas: acciones, recursos, modelos, workspace, marketplace, complementos, seguridad, comandos, eventos, misiones, twin, staging, contratos, ajustes y pruebas |
| Pruebas | 29 archivos; última batería ejecutada: 123/123 |
| App Server | Proceso persistente por `stdio`, Windows sin `shell: true` |
| Acceso | Mismo origen, sesión del bridge, LAN y Tailscale |
| Deuda de tamaño | `server.js` ~84.9 KB; entrypoint `app.js` 281 bytes; módulos principales: composition ~42 KB, control ~43 KB y chat ~48.6 KB; `style.css` ~56.9 KB |
| Control de versiones | `.git` existe, pero Git informa que no es un repositorio válido |

### 2.2 Capacidades completadas

- Sesión `HttpOnly`, bootstrap autenticado, tokens en URL rechazados y mutaciones con origen validado.
- Threads: listar, crear, reanudar, bifurcar, renombrar, archivar, borrar, objetivos y compactación.
- Turns: iniciar, streaming SSE, steer, cancelar, recuperar y observar varios threads activos.
- Watchdog de turnos con fase, duración, silencio y recuperación explícita.
- Metadatos efectivos por turno: modelo, proveedor, esfuerzo, tier y modo de selección, sin guardar secretos ni razonamiento privado.
- Aprobaciones de herramientas, comandos, cambios y permisos mediadas por backend.
- Checkpoints, diff, explicación objetiva y aceptar/rechazar por archivo o en bloque.
- Adjuntos, imágenes `localImage`, mentions, drag and drop y explorador confinado.
- Memoria básica, áreas de trabajo e instrucciones `AGENTS.md` por proyecto.
- Catálogo de modelos, skills, MCP, plugins, apps, hooks y perfiles del App Server.
- Router FCC con smoke tests, evals básicos por workspace, circuit breaker, presupuesto y selección automática opt-in.
- MCP/plugins explicados en español con análisis y registro por workspace.
- Complementos propios por stack, sin depender de VS Code.
- Mission Contracts, gates y bloqueo backend de aceptación cuando existe incumplimiento.
- Evidence Ledger redactado, panel de Misiones y eventos por workspace.
- Workspace Twin v1 con snapshots de metadatos y comparación temporal.
- Preflight Staging v1 no ejecutable con integridad, límites, secretos redactados, JSON y sintaxis JavaScript.
- Deploy FTP/FTPS/SFTP de archivos aceptados con credenciales protegidas mediante DPAPI.
- Centro de Seguridad de solo lectura y Centro de Pruebas integrado.
- Manual buscable e interactivo dentro del frontend.
- PWA responsive comprobada mediante Chrome/CDP en 1440×900 y 390×844.

### 2.3 Capacidades parciales v1

| Área | Lo que funciona | Límite actual |
| --- | --- | --- |
| Reconexión | Época SSE, ventana de 1.000 eventos y reconciliación | El stream completo no es durable |
| Recuperación de turns | Cancelación/recuperación conserva checkpoints | El snapshot previo pendiente vive en memoria hasta finalizar |
| Concurrencia | Revisiones optimistas, avisos de conflicto, banner de actividad en otros proyectos | Prueba física PWA+PC prolongada y locking multi-nodo fuera de v1 |
| Evidence Ledger | 5.000 registros redactados por workspace | No existe grafo causal completo, exportación firmada ni retención administrable |
| Checkpoints | 30 por thread y archivos de hasta 512 KB | Sin renombres semánticos, binarios grandes ni backup completo |
| Workspace Twin | Hasta 20 snapshots y 10.000 archivos | Sin AST, relaciones semánticas, impacto transitivo ni código histórico |
| Staging | Hasta 200 archivos y 20 MB; checks estáticos | No ejecuta tests, builds, contenedores ni navegador |
| Model Auto | Ranking y circuit breaker por workspace | Evals reducidos; coste y tool calling no están certificados para todos |
| Memoria | Texto y áreas persistentes | Sin fuentes, caducidad, contradicciones, aprobación ni trazabilidad de influencia |
| Marketplace | Catálogo, análisis e instalación | Sin firma, SBOM, reputación, health continuo ni desinstalación gobernada |
| Deploy | Publica únicamente aceptados | Sin cola, promoción, reintentos, dry-run remoto ni rollback remoto |
| PWA | Instalable y responsive | Falta matriz física iPhone/iPad, teclado, rotación y redes degradadas |
| Español | Interfaz propia mayoritariamente traducida | Metadatos externos y algunos identificadores siguen sin capa i18n completa |

## 3. Deuda y riesgos que condicionan el orden

### 3.1 Monolitos en crecimiento · P0

`server.js` y `static/codex-suite/app.js` concentran demasiados dominios. Añadir Monaco, vault, pipelines o colaboración directamente aumentaría acoplamiento, tiempos de revisión y regresiones. Deben dividirse incrementalmente conservando rutas y DOM públicos.

### 3.2 Persistencia sin esquema común · P0

Checkpoints, metadata de turns, evals, evidencias, twin y staging usan varios JSON/JSONL. Falta versionado de esquema, migraciones, locking consistente, cuotas globales y verificación de corrupción.

### 3.3 Creación heredada de proyectos · P0

El anfitrión ya expone `/api/projects/create`, pero no es todavía la función premium solicitada:

- no está integrada en Codex Suite;
- necesita confinamiento canónico reforzado frente a separadores, `..`, junctions y symlinks;
- necesita mismo origen, confirmación exacta, preflight y rollback de creación parcial;
- todavía crea `.vscode` y plantillas SFTP heredadas, conceptos que deben sustituirse por metadatos propios;
- no representa un workspace compuesto.

No debe reutilizarse sin endurecimiento.

### 3.4 Bóveda heredada que revela valores · P0

El bridge tiene `/vault` y APIs autenticadas que leen variables de `.env` y devuelven sus valores. Aunque requieran autenticación, contradicen el diseño write-only y amplían el impacto de una sesión comprometida. El futuro panel **Control → Claves APIs** no puede construirse encima de esa API.

### 3.5 Compatibilidad de aplicaciones vecinas · P0

Reinicios, sesiones, tokens o validaciones del anfitrión pueden afectar aplicaciones externas. El incidente CaptaJaus demostró que un estado PM2 `online` instantáneo no basta. Toda mutación transversal necesita inventario, preflight, health repetido y rollback.

### 3.6 Seguridad aplazada pero no eliminada · P0/P1

Continúan pendientes HTTPS administrado, retirada gradual de `X-Bridge-Token`, rotación coordinada, CSP por aplicación, vault, backups, supply chain y rate limiting. Pueden aplazarse para operación privada, pero bloquean multiusuario, exposición pública y comercialización.

### 3.7 Git no operativo · P1

Los checkpoints aportan recuperación parcial, pero no sustituyen un repositorio sano. Reparar `.git` requiere backup y decisión del administrador; no debe improvisarse con un reset destructivo.

## 4. Arquitectura objetivo

```text
PWA / escritorio / futuro cliente Flutter
                   │
          API Gateway del bridge
  sesión · roles · rate limits · mismo origen
                   │
     ┌─────────────┼──────────────────┐
     │             │                  │
Control Plane   Evidence Plane     Workspace Plane
turns/modelos   ledger/grafo       archivos/índice
políticas       pruebas/deploy     memoria/LSP
aprobaciones    checkpoints        integraciones
     │             │                  │
     └─────────────┼──────────────────┘
                   │
        Worker Plane aislado
 App Server · LSP · browser · staging · evals
   Windows local y/o Docker .16 con límites
```

Principios:

1. Cada workspace es frontera de datos, memoria, índices, integraciones, credenciales y políticas.
2. El navegador solicita acciones; nunca ejecuta herramientas ni recibe secretos persistidos.
3. App Server sigue siendo la autoridad del ciclo agéntico; Codex Suite gobierna contexto, permisos, evidencia y UX.
4. La PWA móvil prioriza misiones, progreso, aprobaciones, cambios y recuperación. El escritorio añade densidad, edición y observación.
5. Las aplicaciones vecinas conservan APIs y procesos propios.

## 5. Secuencia de fases y subfases

## Fase 0 · Modular Foundation & Legacy Guardrails

Objetivo: poder evolucionar sin romper el anfitrión ni las aplicaciones vecinas.

### 0.1 Modularización backend · P0 · Completada

- Extraer router `/api/codex` de `server.js` por dominios: sesión/admin, workspace, integraciones, modelos, threads/turns, evidence, staging/deploy y diagnóstico.
- Introducir composición explícita de dependencias y un manejador de errores único.
- Conservar exactamente rutas, autenticación y payloads existentes.
- Resultado 0.1a–0.1g: sesión/origen, administración, workspace/contexto, modelos/capacidades, threads/turns/SSE, evidencia/publicación y composición raíz extraídos con contratos conductuales. Detalle: [CODEX-SUITE-MODULAR-FOUNDATION.md](CODEX-SUITE-MODULAR-FOUNDATION.md).
- Criterio cumplido el 5 de agosto de 2026: 87/87 pruebas, exactamente 75 rutas, error boundary único, bridge 8095, lanzador y Lliria Properties operativos.

### 0.2 Modularización frontend · P0 · Completada

- Separar estado/API, chat/runtime, control panels, revisión, explorer y settings en módulos ES nativos.
- Mantener HTML/CSS nativo inicialmente; no introducir framework por moda.
- Añadir eventos de dominio y render incremental para evitar repintados completos.
- Criterio: mismas superficies, cero overflow, tamaño de bundle medido y ausencia de duplicación de listeners.
- Resultado 0.2a–0.2f: core, ajustes/admin/diagnóstico, workspace/explorer/contexto, integraciones, control/modelos/evidencia, chat/runtime/revisión/eventos y composición extraídos; entrypoint mínimo, bindings idempotentes y boundary visual recuperable.
- Criterio cumplido el 7 de agosto de 2026: PWA v34, 115/115 pruebas y Chrome/CDP en escritorio/móvil, incluido el boundary accesible.

### 0.3 Contratos y esquemas de persistencia · P0 · Completada

- Versionar todos los stores; escrituras atómicas, locking y recuperación de JSON corrupto.
- Definir IDs estables comunes para workspace, thread, turn, checkpoint, mission, preflight y deploy.
- Crear migraciones y una herramienta de auditoría read-only.
- Resultado 8 ago 2026: `lib/codex-persistence.js`, stores cableados, `GET /api/codex/persistence/audit`, CLI `tools/audit-codex-persistence.mjs`, Cursor absorbido en el router (79 rutas), batería **123/123**.
- Criterio cumplido: registry versionado, IO atómico, cuarentena, migraciones `schemaVersion` y auditoría sin mutación por defecto.

### 0.4 Guardrails para aplicaciones vecinas · P0 · Completada

- Inventario de procesos/puertos/health y propietario.
- Preflight de variables requeridas sin revelar valores.
- Verificación posterior repetida de uptime, reinicios y HTTP.
- Registro y rollback para acciones operativas autorizadas.
- Resultado 8 ago 2026: `lib/codex-neighbor-guardrails.js` + `lib/codex-neighbor-routes.js`, política `config/neighbor-guardrails.json`, Control → Sistema → Vecinas (PWA v36), **85** rutas `/api/codex/*`, batería **126/126**.
- Criterio cumplido: inventario con propietario/puerto/health, preflight env sin valores, verify multi-ronda y catálogo con confirmación exacta + rollback.

### 0.5 Estrategia Git y recuperación · P1 · Bloqueado por decisión

- Diagnosticar `.git`, crear backup y elegir reparar, reinicializar o mantener sin Git.
- Nunca usar operaciones destructivas sin autorización explícita.

## Fase 1 · Reliability & Evidence Control Plane v2

Objetivo: que ningún turno, ventana o reinicio deje el producto en un estado ambiguo.

### 1.1 Pending Checkpoints durables · P0 · Completada

- Persistir snapshot previo, estado y lease del turno antes de llamar a App Server.
- Recuperar tras caída abrupta del bridge.
- Finalización idempotente y limpieza con retención.

### 1.2 Event Log durable y replay · P0 · Completada

- [x] Log secuencial JSONL acotado (`lib/codex-event-log.js`) con sanitizado de claves sensibles.
- [x] Cableado en `CodexAppServer` (`storage/codex-event-log/`, kind `eventLog`, window `durable`/`durableWindow`).
- [x] Cursor por cliente (`clientId` + `since` + registro `lib/codex-event-cursors.js`); APIs `GET /api/codex/events/window|cursors`.
- [x] Política de lag (`resolveStreamCursor`: `ok` / `catching_up` / `stale` / `reset`) anunciada en `bridge/streamState`.
- [x] Compaction automática al superar capacidad + evento `bridge/eventLogCompacted`.
- [x] PWA reconecta con `?since=` y recupera estado si hay reset/stale; shell **v40**.
- No persistir razonamiento privado ni deltas sensibles fuera de política.

### 1.3 Mission Evidence Graph · P1 · Completada v1 (12 ago 2026)

- [x] Enlazar (derive-on-read) petición, contrato, modelo, herramientas, aprobaciones, archivos, preflight, pruebas, decisiones y deploy sobre ledger + stores hermanos.
- [x] APIs `GET /api/codex/evidence/:threadId/graph?view=simple|admin` y `GET .../export` (bundle redactado + `sha256`).
- [x] Vista simple (hitos ES) y vista avanzada (nodos/aristas + sources) en Control → Misiones; botón Exportar.
- [x] Sin prompts, diffs, comandos ni secretos (misma política que el Evidence Ledger).
- Persistencia durable de edges / visualización force-graph: fuera de v1.

### 1.4 Concurrencia multi-cliente · P1 · Completada v1 (16 ago 2026)

- [x] Revisiones optimistas de checkpoints (`revision` + `expectedRevision`) con 409 `VERSION_CONFLICT` / `ALREADY_DECIDED` / `DISK_CHANGED`.
- [x] Aprobaciones concurrentes: 409 `ALREADY_RESOLVED` si ya no están pendientes.
- [x] `GET /api/codex/activity/background?excludeWorkspace=` + banner UI al cambiar de proyecto (turns/aprobaciones en otros workspaces).
- [x] Enriquecimiento de `activeTurns`/`pendingApprovals` con `workspaceId` en `/status`.
- [x] Pruebas automatizadas de carrera de decisión y contrato UI; prueba física PWA+desktop simultáneos = manual (fuera de v1 CI).
- Persistencia durable multi-nodo / locking distribuido: fuera de v1.

### 1.5 Chaos & Recovery Center · P1 · Pendiente

- Pruebas de App Server caído, SSE cortado, compactación bloqueada, proveedor 429/5xx, navegador suspendido y disco lleno simulado.
- Acciones guiadas de recuperar, reintentar, cambiar modelo o exportar evidencia.

### 1.6 Portabilidad y continuidad de conversaciones · P1 · v1 premium (9 ago 2026)

- [x] Motor Cursor en Suite con `Agent.resume` / historial IDE vía `cursor/sources` + `cursor-turns` (agentId, transcriptId, Serena).
- [x] Distinción explícita Codex App Server vs Cursor SDK vs sesión Suite vs chat IDE.
- [x] Análisis IDE/Composer documentado: [CODEX-SUITE-IDE-COMPOSER-SYNC-ANALYSIS-2026-08-09.md](CODEX-SUITE-IDE-COMPOSER-SYNC-ANALYSIS-2026-08-09.md).
- [x] Continuidad local premium: `newChat` → JSONL UUID, binding durable (`storage/codex-conversation-bindings.json`), append siempre enriquecido, picker unificado; criterio IDE = **Recargar ventana / reabrir chat**.
- [x] Índice Composer **read-only** gated (`CODEX_COMPOSER_PRIVATE=1`) — operador-only; **prohibida** escritura a `state.vscdb`.
- [ ] Sincronización en caliente misma ventana IDE: **no aplicable** (no es la misma UI; se documenta).
- [ ] Importación automática de chats cloud/externos sin `agent-transcripts` ni agentId SDK.
- Futuro comercial (WhatsApp/correo/app cotidiana): **fuera** de 1.6; no mezclar con el store privado de Cursor.

## Fase 2 · Administración segura del workspace

Objetivo: crear proyectos, workspaces y credenciales sin recurrir a ediciones manuales inseguras.

### 2.1 Crear proyecto bajo `htdocs` · P1 · Completada v2 (12 ago 2026)

- Completado en Suite: `POST /api/codex/workspaces/create` + UI **Nueva área**; bases allowlist (`HTDOCS_ROOT` ∪ `PROJECT_CREATE_BASES`); plantillas `empty|php|php-web|node|static|imported`; confirmación exacta; **sin** `.vscode` por defecto; registro inmediato vía catálogo + allowlist durable.
- Completado: vincular carpeta existente `POST|DELETE /api/codex/workspaces/attach` bajo raíces allowlist (`storage/codex-workspace-allowlist.json`).
- [x] Rechazo exhaustivo de junctions/symlinks (hoja + cadena de padres + divergencia realpath) en create/attach.
- [x] Previsualización `POST .../workspaces/create/preview` y `.../attach/preview` + rollback transaccional si la creación falla a mitad.
- [x] Plantilla `imported` + checklist de seguridad (`.codex-suite/import-checklist.json`); attach bloquea críticos salvo `forceImport`.

### 2.2 Workspaces compuestos · P1 · Completada v1 (12 ago 2026)

- [x] Varios roots autorizados con nombre, propietario y política independiente (`readOnly` | `workspaceWrite`).
- [x] Consentimiento explícito al añadir cada raíz (`ADD_WORKSPACE_ROOT:…`).
- [x] Contexto, memoria, explorer, tools/sandbox y deploy con scope visible (`compound-scope`, chips, write roots del turno).
- [x] Prohibir escritura en otra raíz sin `writeRootIds` del turno (`buildTurnRootScope` → `writableRoots`).
- APIs: `GET /workspaces/compound-scope`, `POST|DELETE /workspaces/roots`; perfil v2 con `roots[]`.

### 2.3 Control → Claves APIs · P0/P1 · Completado v1 (12 ago 2026)

- [x] Segunda contraseña en primer acceso con scrypt, rate limiting y bloqueo temporal.
- [x] Vault cifrado AES-GCM con alias, proveedor, ámbito, fecha, estado y última validación local.
- [x] Claves write-only; la API nunca devuelve el secreto; SEC-16 permanece 410.
- [x] Activación atómica hacia `credentialStore`/`auth.json` para freemodel/openai + reinicio App Server (`service.restartAppServer`).
- [x] Auditoría JSONL sin valores.
- [x] Limitación honesta documentada: no recarga terminales ya iniciados (sí reinicia App Server).
- Rotación avanzada / backup-recuperación offline → backlog 7.x.
- APIs: `GET|POST /keys`, `/keys/status|bootstrap|unlock|lock|audit`, `POST /keys/:id/activate|validate`, `DELETE /keys/:id`.

### 2.4 Settings Schema & Policy Studio · P1 · Completado v1 (16 ago 2026)

- [x] Catálogo schema declarativo Suite + TOML allowlist (`GET /settings/schema`).
- [x] Campos con ayuda, validación y origen efectivo (`GET /settings/effective`).
- [x] Preview/diff antes de guardar (`POST /settings/preview`) + UI Policy Studio.
- [x] Rollback Suite vía revisiones (`GET /settings/revisions`, `POST /settings/rollback` + `ROLLBACK_SETTINGS`).
- [x] Scopes honestos: global real; workspace/thread/device stubs (`GET /settings/scopes`).
- Rollback TOML completo y overlays por workspace → backlog.

## Fase 3 · Context Intelligence

Objetivo: proporcionar el contexto correcto, trazable y actualizado con menor coste.

### 3.1 Índice semántico incremental · P1 · Pendiente

- Inventario por hash, parser por lenguaje y actualización por cambios.
- Exclusión de secretos, `.gitignore`, binarios, datos personales y carpetas generadas.
- Búsqueda híbrida: texto, símbolos, dependencias y embeddings.
- Borrado verificable y métricas de frescura.
- Worker local o Docker `.16` sin recibir automáticamente el workspace completo.

### 3.2 Memoria gobernada · P1 · Pendiente

- Recuerdos con fuente, autor, alcance, fecha, caducidad y confianza.
- Detección de contradicciones y aprobación antes de promover memoria durable.
- Mostrar qué memoria influyó, sin mostrar razonamiento privado.

### 3.3 Context Composer premium · P1 · Parcial v2 (16 ago 2026)

- [x] Drag and drop, archivos e imágenes existentes.
- [x] Presupuesto visual de contexto + detección de duplicados/pesados (`POST /context/budget` + UI).
- Colecciones, símbolos, diffs, resultados de test, terminal mediado y URLs autorizadas → pendiente.
- Previsualización segura de imágenes y OCR/visión con modelo compatible → pendiente.

### 3.4 Recomendaciones por workspace · P1 · Parcial v2 (16 ago 2026)

- [x] Stack → complementos con `utilityEstimate` vs `evidence` (instalado / fit estimado).
- [x] Coste, privacidad y permisos expuestos en recomendaciones.
- Health medido por uso real y casos de uso posteriores → pendiente.

### 3.5 Internacionalización · P2 · Pendiente

- Catálogo i18n completo; español como idioma principal.
- Traducir explicaciones propias y estados externos conocidos sin alterar IDs técnicos.
- Pruebas de textos, pluralización, fechas y accesibilidad.

## Fase 4 · Agent Reliability Control Plane

Objetivo: seleccionar y gobernar modelos, herramientas y estrategias por evidencia.

### 4.1 Model Evals v2 · P1 · Parcial v1

- Datasets privados por stack y tipo de tarea.
- Calidad, coste confirmado, latencia, contexto, tool calling, visión y fallos.
- Repeticiones y comparación estadística; no decidir con una sola respuesta.
- Notificar degradación y disponibilidad recuperada del modelo predeterminado.

### 4.2 Auto Router transparente · P1 · Parcial v1

- Explicar modelo/proveedor/esfuerzo elegido y evidencia usada.
- Políticas de fallback gratuito o local aprobadas por administrador.
- Nunca cambiar silenciosamente privacidad, coste o capacidad de herramientas.
- Reintentos y circuit breaker por error, proveedor y workspace.

### 4.3 Capability Recipes · P1 · Pendiente

- Recetas versionadas que combinan modelo, MCP, plugin, skill, permisos y gates.
- Certificación real por workspace y rollback de instalación.
- Constructor gráfico de herramientas/comandos con dependencias visibles.

### 4.4 Autopilot gobernado · P1 · Parcial v1

- Bucle formal inspeccionar → planificar → ejecutar → probar → corregir → verificar.
- Presupuesto de tokens, tiempo, herramientas, subagentes y reintentos.
- Condiciones de parada, checkpoints intermedios y aprobación por riesgo.

### 4.5 Subagentes y ejecución paralela · P2 · Parcial v1

- Árbol persistente de delegación, cuota y estado.
- Aislamiento de contextos, consolidación de resultados y cancelación granular.
- No habilitar paralelismo cuando comparta archivos sin estrategia de conflicto.

### 4.6 Navegador administrado · P2 · Pendiente

- Sesiones aisladas, allowlist de dominios, capturas y redacción.
- Pruebas visuales locales y documentación web con evidencia.
- Sin evasión de CAPTCHAs ni protecciones de terceros.

## Fase 5 · Entorno web de ingeniería propio

Objetivo: superar el flujo de chat sin convertir la PWA móvil en un IDE ilegible.

### 5.1 Design System premium · P1 · Pendiente

- Sistema visual propio minimalista, tokens, componentes y densidades.
- Modo simple para usuarios no técnicos y modo administrador avanzado.
- Accesibilidad WCAG 2.2 AA, teclado, lector de pantalla y movimiento reducido.

### 5.2 PWA nativa sólida · P1 · Parcial v1

- Pruebas físicas en iPhone: teclado, safe areas, standalone, rotación, suspensión y actualización.
- Sincronización PWA/escritorio, notificaciones y progreso en background cuando la plataforma lo permita.
- Instalación Windows desde Chromium con actualización segura.

### 5.3 Explorer & Workbench v2 · P1 · Parcial v1

- Árbol virtualizado, búsqueda, tabs, breadcrumbs, cambios y relaciones.
- Arrastrar contexto, crear/renombrar/mover con confirmaciones y conflictos.
- Separar claramente archivos reales, propuestos y aceptados.

### 5.4 Monaco editor/diff · P2 · Pendiente

- Editor de escritorio y visor móvil adaptado.
- Edición humana versionada, autosave opcional y conflicto con el agente.
- Diff por archivo, hunk y línea; aceptar/rechazar granular.

### 5.5 LSP aislados · P2 · Pendiente

- Servidor por lenguaje/workspace con CPU, RAM, timeout, filesystem y red limitados.
- PHP, JavaScript/TypeScript, HTML/CSS y SQL como primera matriz.
- Diagnósticos enlazados al Evidence Graph.

### 5.6 Terminal mediado · P2 · Pendiente

- No ofrecer un shell arbitrario al navegador.
- Catálogo de tareas versionadas y comandos propuestos por agente con aprobación.
- Streaming, cancelación, límites y salida redactada.

## Fase 6 · Staging, pipelines y deploy transaccional

Objetivo: convertir cambios aceptados en entregas reproducibles y recuperables.

### 6.1 Dynamic Staging v2 · P1 · Pendiente

- Worker desechable local o Docker `.16`.
- Materializar únicamente archivos autorizados y dependencias necesarias.
- Ejecutar tests/builds permitidos, navegador y seguridad con límites.
- Destruir y demostrar limpieza tras la misión.

### 6.2 Pipelines visuales · P2 · Pendiente

- DAG versionado de gates; plantillas por stack.
- Evidencia de entrada/salida, aprobaciones y políticas.
- Reejecución parcial y comparación entre runs.

### 6.3 Deploy Queue · P1/P2 · Parcial v1

- Cola durable, staging, dry-run, reintentos, idempotencia y concurrencia.
- Solo archivos aceptados; hash y snapshot remoto antes de publicar.
- SFTP/FTPS preferidos; FTP señalado como compatibilidad insegura.

### 6.4 Rollback remoto · P2 · Pendiente

- Restauración por lote y por archivo con integridad.
- Verificación HTTP/funcional posterior y reversión automática gobernada.
- No prometer rollback si el destino no ofrece snapshot o backup.

## Fase 7 · Security, Observability & Recovery

Objetivo: cumplir los prerrequisitos reales de un producto comercial.

### 7.1 HTTPS y Session Migration v2 · P0 antes de exposición pública

- Tailscale Serve o proxy administrado.
- Identidades humanas y credenciales de servicio por capacidad.
- Telemetría de uso heredado sin secretos y retirada coordinada de `X-Bridge-Token`.

### 7.2 Observabilidad privada · P1 · Pendiente

- Métricas, traces y logs redactados con retención configurable.
- Salud de App Server, modelos, tools, MCP, workers, índices y deploy.
- Alertas deduplicadas con propietario y evidencia de resolución.

### 7.3 Vault profesional · P1 · Pendiente

- Completa 2.3 con rotación, expiración, referencias por entorno, revocación y recuperación.
- Integración con DPAPI/Windows Credential Manager inicialmente; backend intercambiable después.

### 7.4 Backups cifrados y restore drills · P1 · Pendiente

- Inventario, RPO/RTO, cifrado, retención y separación de claves.
- Restauración automatizada en entorno aislado y evidencia periódica.

### 7.5 Policy Engine y supply chain · P2 · Pendiente

- Políticas administradas, firma, SBOM, procedencia, permisos y revocación de plugins/recetas.
- Dependencias, licencias, advisories y actualizaciones firmadas.

### 7.6 Postura del host · P2 · Investigación/autorización separada

- Defender, firewall, BitLocker, listeners, tareas y Docker.
- Diagnóstico read-only desde Codex Suite; mutaciones solo mediante runbook aprobado fuera del flujo normal.

## Fase 8 · Colaboración y plataforma

Objetivo: pasar de panel personal de administrador a producto de equipo.

### 8.1 Identidad y roles · P3 · Pendiente

- Administrador, desarrollador, revisor y observador.
- Dispositivos, sesiones revocables, MFA/SSO futuro y auditoría por actor.

### 8.2 Colaboración · P3 · Pendiente

- Comentarios, asignaciones, decisiones y presencia.
- Conflictos optimistas en threads, archivos, contratos y deploy.

### 8.3 Tenancy · P3 · Pendiente

- Aislamiento de App Server, vault, índices, eventos y backups.
- Cuotas, residencia, borrado y exportación.

### 8.4 Marketplace gobernado · P3 · Pendiente

- Editores verificados, reputación basada en evidencia, incidentes, compatibilidad y coste.
- Instalación, actualización, desactivación y eliminación reversibles.

## Fase 9 · Cliente Flutter y asistente móvil

Objetivo: preparar una familia móvil sin mezclarla prematuramente con el runtime de ingeniería.

### 9.1 SDK/API estable · P2/P3 · Pendiente

- Contrato versionado, OAuth/device flow futuro, notificaciones y sincronización.
- Nunca incluir el token raíz del bridge en la aplicación.

### 9.2 Carpeta Flutter multiplataforma · P3 · Pendiente

- Crear solo cuando existan API, identidad, vault y permisos estables.
- Android primero; iOS/desktop después según validación.

### 9.3 Asistente personal con permisos · Investigación separada

- Catálogo explícito de capacidades Android, consentimiento granular y confirmación para acciones sensibles.
- Historial, reversibilidad y límites por tarea.
- No prometer “cualquier tarea”: las capacidades dependen del sandbox móvil, APIs del sistema y políticas de tiendas.

## Fase 10 · Preparación comercial

Objetivo: convertir la ingeniería en un producto operable y defendible.

- Investigación con usuarios españoles y métricas de problema/retención.
- Onboarding no técnico, soporte, actualizaciones firmadas y canal estable/beta.
- Privacidad, términos, DPA, borrado, exportación y respuesta a incidentes.
- Modelo de costes por proveedor, infraestructura y soporte.
- Evals externos, pentest, threat model y restore drills.
- Planes Personal, Profesional, Equipo y Empresa solo después de aislar identidad, datos y costes.

## 6. Trazabilidad de las diez evoluciones originales

| Evolución solicitada | Fases que la completan |
| --- | --- |
| 1. Indexación semántica incremental | 3.1, 3.2, 7.2 |
| 2. Monaco y LSP aislados | 5.4, 5.5, 7.5 |
| 3. Cola deploy con staging/reintentos/rollback | 6.1–6.4, 7.3 |
| 4. Vault y rotación | 2.3, 7.3, 7.4 |
| 5. Políticas y firma de plugins | 4.3, 7.5, 8.4 |
| 6. Observabilidad privada | 1.3, 7.2 |
| 7. Pipelines visuales con gates | 6.1, 6.2 |
| 8. Multiusuario y roles | 7.1, 8.1–8.3 |
| 9. Evals para selección automática | 4.1, 4.2 |
| 10. Backups cifrados y recuperación | 1.1, 6.4, 7.4 |

## 7. Brainstorming avanzado: apuestas diferenciales

Estas ideas son hipótesis, no funcionalidades comprometidas.

### 7.1 Mission Cockpit de doble capa

Una vista “simple” responde qué se pidió, qué ocurre, qué riesgo existe y qué debo decidir. La vista “experta” abre eventos, modelos, herramientas, diffs y políticas. Evita obligar a un usuario no técnico a comprender un IDE.

### 7.2 Confidence Budget

Cada misión consume un presupuesto de incertidumbre. Pruebas, contratos, modelos evaluados y revisiones lo reducen; herramientas no certificadas, contexto obsoleto o deploy sin snapshot lo aumentan. El producto explica la confianza operativa mediante evidencias, no mediante una puntuación mágica.

### 7.3 Workspace Time Machine

Combinar Twin, checkpoints, decisiones, memoria y deploy para responder: “¿cómo estaba el proyecto, por qué cambió y cómo lo recupero?”. Debe distinguir metadatos observados de código realmente respaldado.

### 7.4 Project Guardian

Un agente read-only continuo detecta desviaciones: secretos nuevos, dependencias vulnerables, tests degradados, integración caída, memoria contradictoria o modelo con peor desempeño. Propone una misión; nunca corrige silenciosamente.

### 7.5 Capability Health Score

MCP, plugin, skill, modelo y pipeline muestran disponibilidad, última prueba, permisos, coste, privacidad y utilidad real para el workspace. La recomendación cambia cuando la evidencia cambia.

### 7.6 Incident-aware Engineering

Los incidentes operativos alimentan checks preventivos. El caso CaptaJaus se convertiría en un gate reutilizable: validar variables requeridas, reinicios estables y health repetido antes de cerrar una misión.

### 7.7 Human Decision Queue móvil

En iPhone, agrupar únicamente decisiones pendientes: aprobar herramienta, comparar archivos, confirmar criterio, cambiar modelo, promover staging o ejecutar rollback. El trabajo de fondo permanece visible pero no ocupa toda la pantalla.

### 7.8 Reproducible Agent Recipes

Una receta conserva versiones de modelo, capacidades, política, contexto, gates y entorno. Permite comparar el mismo objetivo con otra receta y aprender qué configuración funciona mejor sin guardar código sensible innecesario.

## 8. Orden inmediato recomendado

1. **Modular Foundation v1**: 0.1, 0.2 y 0.3, sin cambiar comportamiento.
2. **Legacy Guardrails v1**: 0.4 y contención de `/vault`/creación heredada.
3. **Pending Checkpoints + Durable Replay v2**: 1.1 y 1.2.
4. **Secure Project Creation v1**: 2.1.
5. **API Key Vault v1**: 2.3, con diseño de recuperación antes de escribir claves.
6. **Mission Evidence Graph v1**: 1.3 · **entregada** (12 ago 2026).
7. **Semantic Index v1**: 3.1.
8. **Model Evals & Auto Router v2**: 4.1 y 4.2.
9. **Design System/PWA physical QA v1**: 5.1 y 5.2.
10. **Dynamic Staging + Deploy Queue v1**: 6.1 y 6.3.

**Lab Fabric + wave16**, **2.4 Policy Studio**, **3.3/3.4 parciales** y **1.4 concurrencia v1** entregados (16 ago 2026). Siguiente: **1.5 chaos** o **3.1 índice semántico** (0.5 Git aplazado; Docker `.16` externo).

## 9. Definition of Premium Ready

Codex Suite podrá llamarse “premium comercialmente preparada” cuando, como mínimo:

- sobreviva reinicios y redes inestables sin perder estado aceptable;
- toda acción sensible tenga identidad, autorización, evidencia y rollback;
- secretos, workspaces e índices estén aislados y cifrados según su riesgo;
- PWA y escritorio se sincronicen bajo pruebas físicas prolongadas;
- modelos y herramientas se seleccionen por evals reproducibles;
- staging y deploy sean transaccionales;
- backups se restauren periódicamente;
- plugins y dependencias tengan procedencia y política;
- exista observabilidad privada, soporte e incident response;
- pruebas externas confirmen accesibilidad, seguridad y recuperación.

Hasta entonces es una plataforma privada avanzada en evolución, no un producto terminado ni una garantía de automatización universal.

## 10. Regla de actualización

Al cerrar cada bloque:

1. cambiar su estado solo con evidencia ejecutada;
2. registrar pruebas, fecha, entorno y límites en `CODEX-SUITE-STATUS.md`;
3. actualizar el uso en `CODEX-SUITE-MANUAL.md`;
4. actualizar estrategia únicamente si cambia una decisión de producto;
5. añadir nuevas ideas primero como investigación con valor, riesgo, dependencia y métrica.

## 11. Trabajo pendiente y estimación por respuestas

La lista completa pendiente son las fases 0.3–0.5 y 1–10 descritas arriba. Bajo la regla actual —un bloque completo, probado y documentado por respuesta— la estimación responsable es **74–99 respuestas de implementación**, con una referencia de planificación de **aproximadamente 82**. No es una promesa de calendario ni incluye esperas por decisiones, credenciales, servicios externos o revisiones humanas.

| Tramo pendiente | Contenido | Respuestas estimadas |
| --- | --- | ---: |
| 0.3–0.5 | Persistencia versionada, guardrails de vecinas y estrategia Git | 4–6 |
| Fase 1 | Checkpoints/eventos durables, Evidence Graph, concurrencia, chaos y portabilidad | 8–10 |
| Fase 2 | Creación segura, workspaces compuestos, claves API y Policy Studio | 6–8 |
| Fase 3 | Índice semántico, memoria, contexto, recomendaciones e idiomas | 7–9 |
| Fase 4 | Evals, router, recipes, autopilot, subagentes y navegador | 8–10 |
| Fase 5 | Design System, PWA física, workbench, Monaco, LSP y terminal | 9–12 |
| Fase 6 | Staging dinámico, pipelines, deploy queue y rollback remoto | 6–8 |
| Fase 7 | Sesiones/HTTPS, observabilidad, vault, backups, políticas y host | 9–12 |
| Fase 8 | Identidad, colaboración, tenancy y marketplace gobernado | 7–10 |
| Fase 9 | API móvil, Flutter y asistente con permisos | 5–7 |
| Fase 10 | Validación comercial, privacidad, costes y certificación externa | 5–7 |

Dependencias que pueden pausar esa secuencia: decisión sobre Git, autorización para migrar sesiones compartidas, infraestructura HTTPS/identidad, pruebas físicas iPhone/Android, credenciales de servicios, pentest externo, investigación con usuarios y decisiones comerciales. Ninguna debe simularse como completada desde una respuesta de ingeniería.