# Codex Suite · plan de producto y negocio vivo > Estado: documento estratégico, no constituye una garantía comercial ni autoriza cambios fuera de `cursor-mobile-bridge`. Se actualizará con cada evolución relevante. > > Última revisión: **3 de agosto de 2026**. El estado implementado se mantiene separado en [`CODEX-SUITE-STATUS.md`](CODEX-SUITE-STATUS.md) y el orden técnico canónico en [`CODEX-SUITE-ROADMAP.md`](CODEX-SUITE-ROADMAP.md). ## 1. Visión Codex Suite será el entorno de ingeniería asistida por IA del producto anfitrión Cursor Mobile Bridge: móvil primero, utilizable desde Tailscale, con ejecución local gobernada, contexto profundo por proyecto y revisión comprensible de cada efecto. No pretende convertir todo el bridge en Codex ni sustituir las aplicaciones vecinas. La propuesta diferencial no es «más herramientas». Es cerrar el ciclo completo de ingeniería: ```text contexto correcto → plan verificable → ejecución aislada → pruebas → revisión humana → despliegue controlado → observabilidad → recuperación ``` ## 2. Principios no negociables 1. Cada workspace es una frontera de datos, memoria, integraciones, credenciales y políticas. 2. El navegador no ejecuta comandos ni recibe secretos. 3. Una capacidad instalada no equivale a permiso para usarla. 4. Las afirmaciones de coste, seguridad o compatibilidad deben ser verificables; si no, se muestran como desconocidas. 5. Las acciones sensibles requieren aprobación y deben ser auditables y reversibles. 6. Cursor Mobile Bridge mantiene su identidad de producto anfitrión y sus aplicaciones vecinas siguen operativas. 7. Windows y el Docker `.16` son superficies de ejecución administradas, no extensiones implícitas del sandbox. ## 3. Estado del producto La base disponible incluye conversaciones persistentes, turnos en streaming, adjuntos, imágenes, explorador, memoria, áreas, herramientas, aprobaciones, revisión por archivo, checkpoints, rollback local, PWA, ajustes, manual, MCP, plugins, complementos nativos, despliegue de aceptados y pruebas integradas. La evolución actual añade: - fichas MCP en español con análisis por workspace; - plugins explicados antes de instalar; - registro `.codex-suite/integrations.json` sin secretos; - complementos propios, sin instalar extensiones en VS Code; - contexto automático de integraciones habilitadas; - Centro de Seguridad de solo lectura para host, proyecto, deploy y Docker remoto. ## 4. Coherencia de las diez evoluciones | Nº | Evolución | Valor | Dependencias | Riesgo principal | Orden recomendado | |---:|---|---|---|---|---:| | 1 | Índice semántico incremental | Contexto preciso y barato | exclusiones, hashes, almacenamiento, evals | indexar secretos o datos obsoletos | 1 | | 4 | Vault y rotación | Seguridad operativa real | inventario de secretos, identidades, auditoría | pérdida de acceso por rotación fallida | 2 | | 6 | Observabilidad privada | Saber qué funciona y por qué | esquema de eventos, redacción, retención | convertir telemetría en fuga de prompts | 3 | | 10 | Backups cifrados | Recuperación demostrable | inventario, claves, pruebas de restauración | backup no restaurable | 4 | | 2 | Monaco y LSP aislados | Experiencia de IDE web | índice, procesos aislados, límites | ejecución arbitraria vía servidor de lenguaje | 5 | | 3 | Cola de deploy | Entrega profesional | vault, snapshots, staging | rollback remoto incompleto | 6 | | 7 | Pipelines visuales | Calidad repetible | observabilidad, deploy, políticas | automatización sin gates fiables | 7 | | 5 | Políticas y firma | Ecosistema confiable | identidad, catálogo, SBOM, vault | falsa confianza en una firma sin revisión | 8 | | 9 | Evals y selección de modelo | Mejor calidad/coste | índice, observabilidad, datasets | optimizar métricas que no reflejan negocio | 9 | | 8 | Multiusuario y roles | Escala comercial | todo lo anterior, sesiones y tenancy | fuga entre tenants o conflicto de edición | 10 | El orden no es casual. Multiusuario antes de vault, auditoría, backups y políticas multiplicaría el riesgo. Monaco antes de aislar procesos convertiría el navegador en una fachada de ejecución demasiado amplia. El enrutado automático de modelos sin evals reales sería solo una heurística de marketing. ## 5. Arquitectura objetivo ### Plano de control · PC Windows anfitrión - autenticación y sesión del bridge; - autorización, aprobaciones y políticas; - coordinación de App Server; - registro por workspace; - revisión, checkpoints y auditoría; - acceso Tailscale y PWA. ### Plano de trabajo aislado · Docker `.16` Uso futuro recomendado, siempre configurable y con salud visible: - workers de indexación semántica; - servidores LSP por lenguaje y workspace; - MCP `stdio` de terceros en contenedores sin privilegios; - tareas de análisis pesado y evals; - almacenamiento temporal sin credenciales persistentes. El Docker remoto no debe recibir automáticamente el workspace completo. Cada tarea declara entradas, raíces, red, CPU/memoria, tiempo máximo y política de borrado. El plano de control conserva las aprobaciones. ### Datos por workspace - `.codex/config.toml`: configuración nativa confiable de Codex; - `.codex-suite/workspace-profile.json`: memoria y áreas; - `.codex-suite/integrations.json`: estado y análisis de integraciones, sin secretos; - índice semántico futuro: almacén separado, cifrado, invalidado por hash; - vault: referencias opacas, nunca valores dentro del workspace; - auditoría: eventos redactados con retención configurable. ## 6. MCP, plugins y complementos ### MCP Un MCP mejora Codex cuando aporta datos actuales o acciones externas que el modelo no tiene. Su ficha debe responder: qué aporta, qué herramientas expone, qué autenticación necesita, dónde se ejecuta, cuánto cuesta, qué datos recibe y cuándo conviene usarlo. Tras habilitarlo, Codex Suite propone casos de uso; no fuerza su invocación. ### Plugins Un plugin es un paquete de capacidades: habilidades, comandos, MCP, hooks y recursos. Antes de instalar debe mostrarse editor, procedencia, contenido, permisos, firma futura, riesgos y utilidad para el stack. La instalación actual de App Server es global; la política de uso y el análisis de Codex Suite son por workspace. La fase de políticas deberá poder bloquear un plugin global en proyectos no autorizados. ### Complementos Son capacidades propias de Codex Suite. No son VSIX y no dependen de VS Code. Un complemento puede configurar un perfil de calidad, un analizador, un LSP aislado, una conexión de datos o un pipeline, siempre con ciclo instalar/habilitar/probar/deshabilitar/eliminar por workspace. ## 7. Seguridad continua El Centro de Seguridad actual es deliberadamente de solo lectura. La evolución profesional necesita: - inventario de activos y superficies por workspace; - detección de secretos con redacción irreversible; - caducidad y rotación coordinada de credenciales; - postura de Defender, firewall, BitLocker, dependencias y Docker; - salud y permisos efectivos de MCP/plugins; - alertas priorizadas, deduplicadas y con propietario; - evidencia de resolución y prueba de no regresión. Endurecer Windows, cambiar firewall, cuentas, Defender o Docker queda fuera de una acción web normal. Debe existir un procedimiento de operaciones separado con backup, ventana de mantenimiento, simulación, aprobación y rollback. ## 8. Fases de entrega ### Fase A · Contexto y confianza 1. Índice incremental con exclusiones y borrado verificable. 2. Vault con referencias opacas y migración desde DPAPI. 3. Esquema de observabilidad con redacción por defecto. 4. Backup cifrado con prueba automatizada de restauración. ### Fase B · Entorno de ingeniería web 1. Monaco como editor y visor de diff. 2. LSP por workspace en procesos/contenedores limitados. 3. Terminal mediado por backend con políticas y aprobación. 4. Cola de deploy con staging, dry-run, reintentos y snapshots remotos. ### Fase C · Automatización gobernada 1. Pipelines visuales versionables. 2. Gates de pruebas, seguridad, revisión y despliegue. 3. Catálogo con SBOM, firma, reputación y políticas. 4. Evals por stack y enrutado de modelos basado en evidencia. ### Fase D · Plataforma colaborativa 1. Identidad por usuario y dispositivo. 2. Roles administrador, desarrollador, revisor y observador. 3. Bloqueos optimistas, comentarios y decisiones por actor. 4. Aislamiento de App Server, vault, índices y auditoría por tenant. ## 9. Indicadores de producto - porcentaje de tareas cerradas con pruebas verificadas; - tasa de aceptación/rechazo por archivo y causa; - recuperación exitosa desde checkpoints y backups; - tiempo desde petición hasta cambio aceptado; - incidentes evitados por gates y políticas; - precisión de recomendaciones MCP/plugin/complemento; - calidad y coste por modelo en evals reales; - despliegues correctos, reintentos y rollbacks; - secretos detectados, rotados y no reintroducidos; - satisfacción móvil y ausencia de overflow/errores PWA. ## 10. Estrategia comercial futura, solo documental Una posible segmentación: - **Personal**: un administrador, ejecución local y Tailscale; - **Profesional**: vault, pipelines, deploy, backups y observabilidad; - **Equipo**: roles, políticas, auditoría y colaboración; - **Empresa**: SSO, gestión central, retención, residencia y conectores privados. Antes de comercializar se necesitan términos, privacidad, soporte, actualizaciones firmadas, telemetría opcional, modelo de amenazas, recuperación, aislamiento multi-tenant y pruebas externas. Ningún nivel debe prometer seguridad absoluta ni «éxito asegurado»; la ventaja sostenible será evidencia operativa, control y recuperación. ## 11. Próxima decisión recomendada El bloque **consolidación + Evidence Ledger** ya ha comenzado: existe persistencia redactada por workspace y una primera vista de misión. El siguiente incremento debe enlazar cada misión con cambios aceptados, checkpoints, pruebas y despliegues, y separar gradualmente los dos monolitos principales por dominios. Esto reduce deuda actual y convierte el diferenciador en una capacidad verificable antes de añadir otra superficie grande. Después debe implementarse **índice semántico incremental por workspace + observabilidad privada mínima**, porque alimenta recomendaciones, contexto, evals y futuros LSP sin abrir todavía ejecución nueva. En paralelo se diseña el contrato del vault. Monaco debe comenzar después de fijar el aislamiento de LSP y el modelo de archivos aceptados. ## 12. Tesis diferencial: Evidence OS La oportunidad no es construir «otro Copilot» ni un VS Code reducido. Codex Suite puede ocupar una categoría más defendible: un sistema operativo de evidencias para agentes locales. Cada misión conserva una cadena comprensible y reproducible desde la intención hasta la recuperación. En móvil se priorizan decisiones, progreso, riesgo y control; en escritorio se añade profundidad, comparación y edición. Los elementos diferenciales son: - ledger persistente de acciones, permisos y resultados con redacción de secretos; - contratos de cambio y criterios de aceptación previos; - replay de misiones en staging y comparación de evidencias; - políticas escritas en lenguaje comprensible que compilan a gates y hooks; - gemelo temporal del workspace con código, memoria, riesgos, deploys e integraciones; - recetas de capacidades verificadas por stack y eval, no extensiones genéricas; - recuperación demostrable como característica central, no como opción avanzada. La aplicación Flutter futura debe ser un cliente separado de este plano de control, no una mezcla prematura entre entorno de ingeniería y asistente personal Android. ## 13. Registro de evolución - **2026-07-21**: se formaliza el aislamiento por workspace para integraciones, se retira la instalación de extensiones del editor del PC, se añaden análisis MCP/plugin/complemento y un Centro de Seguridad de solo lectura. - **2026-07-22 23:07 UTC+02:00**: se verifica PWA, aislamiento por thread, recuperación de turns, revisión individual y selección explícita de workspace. - **2026-07-23 00:30 UTC+02:00**: se completa auditoría honesta, se separa estado actual de estrategia, se identifica deuda de monolitos y se adopta Evidence OS como tesis diferencial recomendada. - **2026-07-23**: se implementa el primer Evidence Ledger persistente y redactado por workspace, sus APIs autenticadas y el panel responsive de Misiones; quedan fuera de este corte replay, exportación, backups cifrados y grafo completo de evidencias. - **2026-07-24**: se integra el router local FCC como fuente de alternativas de ingeniería. Se separan coste declarado, disponibilidad y capacidad; la activación requiere confirmación y conserva las herramientas mediante Codex App Server. Los evals comparativos reales siguen pendientes y son obligatorios antes de afirmar superioridad. - **2026-07-24 · verificación FCC**: de 25 proveedores y 1.046 identificadores, solo siete proveedores completan el smoke streaming inicial. El producto adopta un gate cerrado: catálogo ≠ funcionamiento, y funcionamiento ≠ calidad. La ventaja comercial futura será seleccionar mediante evidencia por workspace, no prometer acceso nominal a cientos de modelos. - **2026-08-03**: se consolida un roadmap canónico con once macrofases numeradas de 0 a 10, subfases, dependencias y Definition of Premium Ready. Se priorizan modularidad, persistencia durable y guardrails heredados antes de proyecto nuevo, vault, índice, IDE web o colaboración. # Selección de modelos como ventaja verificable La propuesta comercial no debe presentar 1.046 nombres como si fueran 1.046 alternativas equivalentes. El producto debe vender una decisión gobernada por evidencia: disponibilidad exacta, calidad por stack, latencia, fallos, coste confirmado y capacidad real de herramientas. La primera versión del router automático ya mantiene rankings separados por workspace y exige consentimiento para consumir evals o activar FCC. La evolución comercial requiere añadir tarifas normalizadas, evals end-to-end de herramientas, presupuestos, circuit breaker, privacidad por proveedor y conjuntos de regresión versionados. Ningún proveedor debe recibir tráfico por fallback si cambia coste o privacidad sin una política previamente aceptada por el administrador. ## Brainstorming premium avanzado · julio de 2026 La siguiente ventaja competitiva no debería consistir en añadir más menús, sino en reducir incertidumbre y convertir tareas complejas en misiones comprensibles. Ideas priorizadas: ### 1. Agent Reliability Control Plane Un plano de control que combine modelo, herramientas, presupuesto, circuit breaker, permisos, evals y evidencia para decidir cómo ejecutar cada misión. Métrica: porcentaje de tareas completadas sin intervención correctiva y con evidencia suficiente. ### 2. Workspace Twin temporal Mapa navegable de arquitectura, dependencias, decisiones, riesgos, conversaciones, cambios aceptados y despliegues. Debe poder responder “qué cambió, por qué y qué depende de ello” en cualquier fecha. Métrica: tiempo medio para comprender impacto y recuperar una versión. Estado: primera versión implementada. Mantiene snapshots aislados por workspace con topología de directorios, áreas, stack, dependencias declaradas, integraciones, Evidence Ledger, despliegue y señales redactadas de seguridad. Compara metadatos de archivos y dependencias sin almacenar contenido de código. Pendiente para una versión avanzada: relaciones AST/LSP, decisiones enlazadas a archivos, consultas semánticas, impacto transitivo y replay sobre staging. ### 3. Mission Contracts Antes de editar, el usuario define resultado, restricciones, pruebas y riesgo aceptable mediante una ficha sencilla. Codex convierte el contrato en gates verificables. Métrica: tareas rechazadas por criterios incumplidos antes del despliegue. Estado: primera versión implementada. Incluye contrato persistente por conversación, alcance de archivos, pruebas observadas en el thread, criterios confirmados por administrador y bloqueo backend de aceptación/despliegue. El Preflight Staging v1 añade verificaciones estáticas; quedan pendientes para una versión comercial las plantillas firmadas, políticas organizativas, dependencias entre gates y ejecución dinámica aislada. ### 4. Capability Recipes Recetas versionadas por stack que combinan modelo, MCP, plugin, habilidad, permisos y tests que ya demostraron funcionar juntos. Sustituyen una tienda genérica por soluciones verificadas. Métrica: mejora de éxito frente a configuraciones no evaluadas. ### 5. Simulador de cambios y despliegues Entorno staging o contenedor desechable que reproduzca una misión antes de aceptar archivos o publicar. Debe comparar comportamiento, seguridad y rendimiento. Métrica: regresiones detectadas antes de producción. Estado: Preflight Staging v1 implementa la base segura y verificable, aislada por workspace: paquete local no ejecutable, integridad frente al checkpoint, límites de volumen, detección redactada de secretos y validación fija de JSON/JavaScript. Bloquea en backend la aceptación afectada cuando existe un informe fallido. No ejecuta todavía el proyecto ni equivale a un entorno staging dinámico; contenedores desechables, tests autorizados, artefactos firmados, promoción y rollback remoto siguen siendo evolución futura. ### 6. Memoria gobernada Memoria por proyecto con caducidad, fuentes, contradicciones, propietario y aprobación. La IA debe explicar qué recuerdo influyó en una decisión y permitir corregirlo. Métrica: reducción de decisiones basadas en contexto obsoleto. ### 7. Explainability operativa No mostrar razonamiento privado, sino evidencias útiles: contexto utilizado, herramientas, permisos, alternativas consideradas, pruebas y límites. Métrica: porcentaje de decisiones que un administrador puede auditar sin leer logs técnicos. ### 8. Experiencia móvil por intención En móvil no intentar reproducir un IDE completo. Presentar misiones, aprobaciones, diferencias, riesgos, resultados y recuperación mediante gestos y tarjetas. Métrica: tareas administrables completamente desde PWA sin pérdida de control. ### 9. Marketplace con reputación verificable SBOM, firma, permisos, editor, mantenimiento, incidentes, coste, telemetría, compatibilidad y pruebas por workspace para cada integración. Métrica: integraciones instaladas que permanecen saludables y utilizadas. ### 10. Evals continuos privados Conjuntos de casos derivados del stack y fallos reales, redactados para no conservar código sensible. Permiten detectar degradaciones de modelos y herramientas. Métrica: tiempo de detección y sustitución de una capacidad degradada. Orden recomendado: Reliability Control Plane → Mission Contracts → Workspace Twin → staging verificable → recetas de capacidades → memoria gobernada. Multiusuario y comercialización deben llegar después de vault, backups, aislamiento y auditoría maduros. Security Hardening v1 completa el primer cierre transversal del producto anfitrión: sesión compartida HttpOnly, bootstrap sin secretos, rechazo de tokens en URL, CORS restringido, health público mínimo y controles visibles. La fase siguiente debe retirar gradualmente la cabecera heredada, migrar todas las aplicaciones vecinas que aún guardan credenciales manuales y exigir HTTPS administrado antes de identidad multiusuario o comercialización. El **Reconnection Contract v1** completa el primer incremento del Reliability Control Plane: el canal SSE declara su época y ventana de replay, y el cliente reconcilia el estado durable cuando detecta reinicio o pérdida de eventos. El siguiente incremento de fiabilidad debe enlazar Evidence Ledger con checkpoints, contratos, preflight y deploy mediante identificadores estables, y después añadir pruebas prolongadas de dos clientes y reinicios durante turns reales.