Agent Bridge MCP

agent-bridge-mcp es un servidor local del Model Context Protocol (MCP) que ofrece a un host MCP una forma controlada de delegar tareas entre los CLI de agentes de codificación locales y la API de Manus. Intencionadamente no es un orquestador de agentes con acceso ambiental al sistema de archivos: las instalaciones normales requieren configuración, las raíces de proyecto están en una lista permitida, el modo de ejecución predeterminado es de solo lectura y la autoridad seleccionada por el llamador no puede superar el techo configurado.

Qué está implementado en v0.3.0-rc.8

Gemini y Manus están deshabilitados por defecto. Manus debe habilitarse deliberadamente después de configurar su credencial y el reconocimiento de capacidades de la cuenta. La transmisión remota de indicaciones está, por separado, deshabilitada por defecto y requiere una lista permitida de agente/raíz/clase de datos, allow_remote_egress=true, una data_classification y una aprobación de remote_egress de alcance exacto consumida en cada llamada. Cada llamada remota directa también requiere una aprobación distinta de paid_or_unknown_cost porque un cero proporcionado por el llamador no puede probar que el costo del proveedor sea cero. Ambas categorías son siempre registros nuevos y de un solo uso; los registros reutilizables se rechazan antes de cualquier lanzamiento del proveedor. Un disyuntor opcional policy.cumulativeRemoteCost reserva atómicamente el máximo aprobado en céntimos de USD enteros antes del lanzamiento en cada sesión. Los casos de desconocido, cero, fracciones de céntimo, superación del límite, libro mayor corrupto/faltante y sobresuscripción concurrente fallan antes de la llamada al proveedor. Las reservas persistidas nunca se reponen después de éxito, error, tiempo de espera, cancelación o bloqueo del proceso porque el puente no puede probar que una solicitud aceptada no fue facturada. La reserva precede intencionadamente al consumo de la aprobación, por lo que un fallo local posterior puede quemar presupuesto de forma conservadora sin llamar al proveedor. Esto es contabilidad de costo aprobado, no conciliación de facturas del proveedor; la durabilidad ante pérdida abrupta de energía/SO aún depende del sistema de archivos del host. list_agents informa de accesibilidad/autenticación/capacidades y disposición cooperativa; es una sonda de salud, no una prueba de que una tarea de pago pueda completarse o de que un agente remoto pueda acceder al espacio de trabajo solicitado.

Las referencias a tareas de Manus se aceptan solo cuando coinciden con el contrato de ID de tarea alfanumérico de 22 caracteres del proveedor. Después de task.create, RC6 permite un período de gracia de visibilidad limitado a 15 segundos: un 404 de task.listMessages se verifica contra task.detail antes de clasificarlo. Una tarea confirmada por detalle cuyos mensajes siguen sin estar disponibles se informa como unknown y es reanudable; solo una tarea ausente de ambas superficies durante el período de gracia se convierte en not_found y no reanudable. Los resultados públicos exponen solo correlaciones de solicitud SHA-256, nunca IDs de solicitud sin procesar del proveedor ni IDs de tarea nativos.

Antes de previsualizar aprobaciones o consumir autoridad, el puente realiza una verificación previa local de Manus: debe existir una credencial configurada no vacía, deben reconocerse las capacidades predeterminadas de la cuenta, el modelo debe ser uno de los perfiles de Manus admitidos y la indicación finalizada debe caber en un techo conservador de 4.500 bytes UTF-8. Esta verificación previa no realiza ninguna solicitud al proveedor. La continuación ordinaria envía un mensaje nuevo solo a una tarea del proveedor cuyo estado persistido es stopped. Una tarea waiting debe usar la ruta especializada de acción de espera. Para un resultado persistido timed_out, aborted, error o unknown, reconcile_manus_task requiere consentimiento de egreso remoto, clasificación de datos y la revisión de sesión actual, y luego realiza sondeo del proveedor solo con GET sin enviar un mensaje de usuario. Un tiempo de espera de reconciliación local registra la tarea como aún no resuelta y nunca envía una solicitud de detención al proveedor; una vez que la reconciliación alcanza stopped, la continuación ordinaria vuelve a estar disponible.

Esas aprobaciones duraderas de egreso/costo por llamada protegen las API remotas directas gestionadas por el puente, como Manus. Codex, Claude y Gemini son procesos CLI locales, pero pueden enviar indicaciones y contenido derivado del espacio de trabajo a sus proveedores alojados; sus políticas de cuenta, proveedor y CLI son un límite de confianza externo. list_agents informa directRemoteApi y offMachineEgress por separado para que un ejecutable local nunca se confunda con procesamiento solo local.

En Windows, los ejecutables directos se lanzan sin shell. Los shims .cmd canónicos estáticos generados por npm se reconocen solo cuando nombran un único punto de entrada node_modules contenido; esa entrada se lanza con el propio ejecutable de Node del puente, por lo que las indicaciones, modelos, raíces y argumentos de extensión nunca pasan por cmd.exe. Los archivos .cmd dinámicos/personalizados y todos los lanzadores .bat fallan de forma segura con UNSAFE_WINDOWS_BATCH_SHIM. Configure su .exe subyacente o use un shim .cmd canónico estático de npm. Esto evita que los metacaracteres de lote escapen de la raíz del puente, el sandbox y los límites de aprobación.

Instalar y configurar

Requiere Node.js 20+ y los CLI que habilite en PATH.

Elija la ruta que coincida con el trabajo:

• Desarrollar o verificar desde el código fuente: use los comandos a continuación y la configuración de desarrollo desde el código fuente.

• Operar una versión instalada: comience con Compilar, probar y empaquetar, incluida su secuencia inmutable de instalación/canario en Windows, luego siga Operaciones del creador. No apunte un cliente a dist del código fuente ni directamente a un directorio de versión con etiqueta.

npm ci
npm run verify
New-Item -ItemType Directory -Force "$env:USERPROFILE\.agent-bridge" | Out-Null
Copy-Item config.example.json "$env:USERPROFILE\.agent-bridge\config.json"

Los comandos anteriores crean una configuración de desarrollo desde el código fuente en %USERPROFILE%\.agent-bridge\config.json. La plantilla tiene intencionadamente una matriz allowedRoots vacía y no se iniciará hasta que la reemplace con uno o más directorios de proyecto absolutos existentes. Una versión instalada inmutable usa en cambio la configuración compartida en %USERPROFILE%\.codex\agent-bridge\config.json, y cada registro de Codex/Claude debe establecer AGENT_BRIDGE_CONFIG en ese archivo compartido al lanzar el shim estable. De lo contrario, se puede seleccionar una configuración con --config <ruta> o AGENT_BRIDGE_CONFIG; un config.json adyacente al servidor se usa solo si está presente. La configuración faltante, malformada o sin raíces se rechaza en lugar de recurrir a un directorio sin restricciones. No permita que la alternativa de desarrollo desde el código fuente y la configuración compartida instalada diverjan silenciosamente.

Los valores predeterminados en tiempo de ejecución son un tiempo de espera de 600 segundos y un sandbox de read-only. config.example.json usa deliberadamente un tiempo de espera de muestra de 900 segundos; no es el valor predeterminado en tiempo de ejecución. La precedencia del sandbox es: la solicitud por turno cuando se proporciona, de lo contrario defaults.sandbox; esa autoridad solicitada/predeterminada se restringe luego tanto por agents.<id>.sandboxCeiling como por policy.sandboxCeiling, y gana el resultado más restrictivo. Un techo de workspace-write permite un turno de escritura solicitado por separado, pero no hace que las escrituras sean el valor predeterminado por sí mismo. policy.sandboxCeiling tiene como valor predeterminado workspace-write por compatibilidad, por lo que las configuraciones heredadas aún pueden solicitar escrituras, pero ya no pueden solicitar full-access. El acceso completo requiere que la configuración diga "sandboxCeiling": "full-access" explícitamente. agents.<id>.sandboxCeiling puede reducir el límite para un backend. El cumulativeRemoteCost.maxReservedCents de muestra es un techo de reserva de por vida para todo el estado del libro mayor actual; aumentarlo es una acción explícita del operador y no hay intencionadamente una herramienta MCP de reinicio. Después de la primera reserva, un marcador de inicialización hace que la eliminación solo del libro mayor falle de forma segura. Un usuario del SO local que pueda eliminar tanto el libro mayor como el marcador puede restablecer este límite contable, así que mantenga stateDir fuera del almacenamiento compartido/del espacio de trabajo y proteja su ACL. Omita la política para deshabilitar ese disyuntor. El puente canóniza las raíces permitidas y el directorio de trabajo, y luego canóniza de nuevo inmediatamente antes del lanzamiento, por lo que un escape de unión/enlace simbólico se rechaza.

Un paquete MCPB puede optar por el mismo validador sin instalar una configuración adyacente falsa estableciendo AGENT_BRIDGE_BUNDLE_MODE=1 y proporcionando AGENT_BRIDGE_ALLOWED_ROOT. El modo de paquete tiene como valor predeterminado autoridad de solo lectura, Codex y Claude habilitados, y Gemini, Manus y egreso remoto deshabilitados. El manifiesto MCPB también puede proporcionar AGENT_BRIDGE_STATE_DIR, conmutadores de backend AGENT_BRIDGE_ENABLE_*, AGENT_BRIDGE_DEFAULT_SANDBOX y AGENT_BRIDGE_SANDBOX_CEILING. Habilitar el egreso remoto requiere además Manus más AGENT_BRIDGE_REMOTE_EGRESS=true y una AGENT_BRIDGE_REMOTE_DATA_CLASS. La selección explícita de --config o AGENT_BRIDGE_CONFIG siempre gana sobre el modo de paquete.

Credencial de Manus

Ejecute el script de configuración proporcionado desde PowerShell:

.\scripts\setup-manus.ps1

Escribe la clave en %USERPROFILE%\.agent-bridge\secrets\manus-api-key con una ACL solo de usuario. Habilite agents.manus, establezca credentialFile en esa ruta y establezca acknowledgeAccountDefaultCapabilities=true más una etiqueta estable no secreta de accountCapabilityProfile solo después de revisar las habilidades predeterminadas habilitadas de la cuenta de Manus. Agent Bridge envía connectors, force_skills y referencias de tarea vacíos por mensaje en la creación y limpia los conectores en la continuación, pero la API v2 de Manus no proporciona un conmutador aplicable por el puente que demuestre que las habilidades predeterminadas de la cuenta están deshabilitadas. El reconocimiento registra la aceptación de ese límite de capacidades del lado del proveedor; no otorga acceso local al sistema de archivos ni autoriza una acción de conector. El punto final del proveedor, la versión de la política de capacidades de solicitud y la etiqueta del perfil de cuenta están vinculados en cada sobre de aprobación remota, por lo que una revisión de cuenta/capacidad cambiada requiere nuevas aprobaciones. No ponga la clave en el control de versiones ni en un manifiesto MCP. El punto final de Manus está restringido a HTTPS api.manus.ai (o sus subdominios); la anulación de desarrollo acepta solo HTTP(S) de bucle local. Manus recibe texto de tarea a través de su API y no tiene acceso local al sistema de archivos; proporcione contenidos de archivo relevantes o un artefacto accesible remotamente en su lugar.

Una clave pegada en el chat queda expuesta. La rotación es la remediación recomendada. Si el operador rechaza explícitamente la rotación, registre esa decisión como un riesgo residual aceptado, conserve la clave solo en el archivo de credenciales protegido por ACL y deje la higiene de credenciales en sí como fallida o reconocida en lugar de llamarla un aprobado.

Operaciones MCP

get_creator_status es la visión general del creador solo local. Agrega estado de configuración/tiempo de ejecución, capacidades configuradas, reservas de costo aprobadas y una muestra acotada sin mutación del estado de sesión, aprobación y tablero de trabajo sin lanzar un CLI ni contactar a un proveedor. Sus campos scanned, truncated y unreadable son evidencia de muestreo en lugar de totales sin límite; el estado incompleto exige atención. La salud del backend es intencionadamente separada a través de list_agents.

El servidor expone operaciones de puente secuenciales (list_agents, delegate_task, continue_session, handoff, list_sessions, get_session y get_turn_output paginable), diagnose_install pasivo, get_budget_status de solo lectura, operaciones de aprobación duraderas (request_approval, decide_approval, list_approvals), planificación remota exacta mediante preview_turn_approval y preview_recommendation_approval, reconcile_manus_task solo GET, operaciones limitadas de acciones de espera de Manus (get_manus_waiting_action, preview_manus_confirmation, confirm_manus_action), collect_recommendations independiente y operaciones cooperativas de creación, ejecución, revisión, inspección, ciclo de vida, cancelación, reintento y aprobación de elementos del tablero de trabajo. Las sesiones conservan internamente los IDs nativos del backend para reanudaciones compatibles. Cuando un agente diferente toma el control, o una reanudación nativa no está disponible o es incompatible, el puente antepone una transcripción acotada y escapada, marcada explícitamente como contexto no confiable. Una vista previa remota devuelve dos hashes diferentes: prompt_sha256 identifica el prompt saliente finalizado para comparación, mientras que payload_sha256 identifica el sobre de aprobación completo, incluidos modelo, sandbox, tiempo de espera, estado de continuidad/reanudación, revisión de sesión, política de extensión, endpoint del proveedor, versión de la política de capacidad de solicitud y perfil de capacidad de cuenta no secreto. Los registros de aprobación deben usar el hash del sobre. Pase el session_revision de la vista previa al continuar o transferir, de modo que los cambios concurrentes en la transcripción requieran una nueva vista previa. La salida del agente en línea se recorta; use el output_ref devuelto o get_turn_output para recuperar la salida completa persistida en páginas acotadas.

Acciones de espera de Manus

Las tareas de Manus pueden pausarse en un estado waiting. Agent Bridge persiste solo el ID de tarea nativo, el ID de evento y un tipo de evento conocido; las descripciones del proveedor y los esquemas dinámicos se descartan deliberadamente porque pueden contener secretos, datos personales o nueva autoridad. Las herramientas públicas nunca devuelven el ID de tarea nativo. Aunque Manus documenta muchos tipos de confirmación y puede añadir más, esta versión solo permite cuatro decisiones fijas:

Cada decisión también requiere una aprobación nueva de un solo uso remote_egress, una clase/raíz de datos permitida, el resumen exacto de la vista previa y la revisión de sesión sin cambios. La vista previa de confirmación expone un sobre de ejecución que vincula el endpoint del proveedor, la versión de la política de capacidad del conector/habilidad predeterminada y el perfil de cuenta no secreto. El adaptador vuelve a leer la acción más reciente del proveedor en vivo antes de consumir cualquier aprobación o reservar presupuesto. Solo después de que esa revalidación tenga éxito, confirma la autoridad, persiste el registro de confirmación intentada inmediatamente antes del POST no idempotente task.confirmAction, y luego exige que la respuesta diga ok=true, confirmed=true y devuelva el mismo ID de tarea. La confirmación aceptada se persiste antes de que el puente reanude el sondeo. Las acciones desconocidas, las preguntas del usuario, la selección del navegador, el envío real de correos electrónicos, el video premium, la aceptación de crédito, los secretos, los despliegues, los comandos de terminal, las acciones de calendario/marketing, la autorización de conectores y las concesiones persistentes global_allow/always_allow fallan en modo cerrado. Este contrato intencionalmente más restrictivo se asienta sobre las APIs del ciclo de vida de tareas de Manus y task.confirmAction.

Comience con docs/CREATOR_OPERATIONS.md. Su matriz de amenazas complementaria, lista de verificación de aceptación en vivo, convenciones de evidencia, límite de privacidad y ejemplos definen el flujo de trabajo de creador admitido y la evidencia requerida antes de la promoción.

Tableros de trabajo cooperativos

Un tablero de trabajo tiene estados de ciclo de vida explícitos: active, paused, completed, canceled y archived. Los elementos pueden declarar tipo, criterios de aceptación, requisitos de datos/sistema de archivos/red/capacidad, referencias inertes tipadas a artefactos/evidencia y una puerta de aprobación de flujo de trabajo. Los cambios de ciclo de vida rechazan arrendamientos activos; los reintentos limpian los resultados sin reponer intentos ni uso.

Un tablero de trabajo contiene elementos de trabajo con dependencias bajo stateDir/workboards. Los tableros persistidos usan una versión de esquema explícita y se validan recursivamente al cargar/guardar. La forma original sin versión v0.3-dev se migra en memoria al leerse y se persiste en el siguiente guardado bloqueado, evitando una carrera de migración sin bloqueo. Los esquemas futuros desconocidos, los registros corruptos y las combinaciones inconsistentes de estado/entrega/revisión fallan en modo cerrado. Cada elemento tiene un presupuesto de intentos/tiempo, un arrendamiento de propiedad, una sesión de puente aislada, una entrega y una revisión independiente. El uso de tiempo de pared/turnos de ejecución y revisión se contabiliza por separado. El límite de intentos de revisión se deriva internamente de maxAttempts; las llamadas de revisión fallidas lo consumen, retienen la entrega para reintento y bloquean el elemento cuando se agota. token_budget_hint es solo informativo porque la contabilidad de tokens del backend no es comparable ni está disponible de manera consistente. Los elementos listos separados pueden ejecutarse concurrentemente hasta maxParallel, pero toda ejecución y revisión de tablero de trabajo se fuerza a read-only independientemente del valor predeterminado del puente. Los turnos cooperativos estrictos suprimen los extraArgs y extraEnv configurados, por lo que esos ajustes no pueden anular las banderas de solo lectura. Un revisor no puede ser el agente que envió el elemento. Solo las entregas aceptadas se incluyen en el resumen acotado del integrador.

Los tableros de trabajo actuales pasan un cwd local y texto, no un paquete de artefactos accesible remotamente y verificado por hash. Por lo tanto, Manus no puede ejecutar ni revisar de forma independiente un elemento de tablero de trabajo y se informa como no cooperativo para evidencia de código local. Úselo solo mediante una delegación remota directa explícitamente aprobada hasta que se implemente un flujo de trabajo de preparación de artefactos. El alcance del brief de recomendación está deliberadamente aislado a backends que no informan capacidad de sistema de archivos local; Codex y Claude deben usar el alcance workspace, mientras que Manus solo puede revisar el brief proporcionado. Este límite demuestra solo que el backend no puede inspeccionar el espacio de trabajo local a través de Agent Bridge. No impone un comportamiento de solo lectura o sin efectos secundarios en el lado del proveedor; las habilidades predeterminadas de la cuenta de Manus siguen siendo una capacidad externa reconocida. La colección registra briefSha256 para que el artefacto en línea pueda identificarse sin implicar acceso al espacio de trabajo.

Esta versión de desarrollo deliberadamente no permite trabajo de escritura cooperativo. Los bloqueos por sesión no pueden evitar que dos sesiones de agente separadas editen los mismos archivos, por lo que las escrituras paralelas seguras requieren un diseño posterior de propiedad del espacio de trabajo.

Diagnósticos pasivos

diagnose_install y --doctor --json informan la identidad de runtime/configuración, el hash del contenido de configuración cuando es legible, advertencias de alcance raíz, tamaño de estado/conteos de sesión, estado del backend saneado y sugerencias de desviación de ruta de ejecutable. Exponen intencionalmente rutas locales seleccionadas: la ruta de runtime, la ruta de estado, las rutas de ejecutables configurados/resueltos y las raíces nombradas por advertencias de alcance. Omiten bytes de configuración sin procesar, valores de entorno del agente, valores de credenciales, detalles sin procesar del proveedor/CLI, prompts y transcripciones. No incruste secretos en rutas de sistema de archivos. Un resultado de autenticación local unknown no se considera utilizable. Estos comandos sondean los backends habilitados; use scripts/inspect-install.ps1 para evidencia pasiva de registro/proceso/ACL sin iniciar ni delegar a un agente. Su resultado fallbackConfig.divergentRegistrationRisk=true significa que un registro de puente puede leer una configuración adyacente/de estado diferente a la configuración compartida instalada y es un bloqueador de transición. RC6 también reconoce cadenas TOML válidas entre comillas simples en la evidencia de registro de Codex.

Runtime experimental de demonio/proxy

El código fuente incluye un runtime experimental de demonio/proxy IPC local construido sobre el códec RPC enmarcado acotado y el protocolo/configuración de apretón de manos HMAC mutuo. Usa solo named pipes de Windows o sockets de dominio Unix—nunca TCP—e implementa ciclo de vida explícito, enlace de endpoint exclusivo, estado de apretón de manos estricto, correlación de solicitudes, límites de conexiones/en vuelo, cancelación de manejador al desconectarse y apagado limpio. Importarlo o construirlo no inicia nada; las pruebas usan solo endpoints desechables. No está conectado al punto de entrada de MCP ni al paquete de lanzamiento, por lo que stdio directo sigue siendo la única ruta de runtime admitida.

En Unix, el runtime aplica el modo 0600 al socket. La API net de Node no puede configurar ni verificar una ACL de named pipe de Windows solo para el usuario ni exponer la identidad del par, por lo que la evidencia de seguridad de Windows informa con veracidad esa brecha y proporciona un enganche de autorización de cierre seguro. No despliegue el demonio experimental hasta que se implementen y revisen una capa de aprovisionamiento/verificación de ACL de Windows y un adaptador de enrutamiento MCP.

Use el diagnóstico de proceso antes de añadirlo a un host MCP:

node .\dist\agent-bridge.mjs --config "$env:USERPROFILE\.agent-bridge\config.json" --doctor

--doctor sale con código distinto de cero si algún backend habilitado no es utilizable. Informa la fuente de configuración, raíces, sandbox y salud del backend; no ejecuta una tarea delegada funcional.

Datos, bloqueos y límites

El estado del puente vive bajo stateDir (por defecto %USERPROFILE%\.agent-bridge): sesiones en texto plano, tableros de trabajo, aprobaciones, reservas de presupuesto acumulativo y sus directorios de bloqueo. Las escrituras de sesión y presupuesto son escrituras atómicas de reemplazo; los bytes temporales de presupuesto se vacían antes de renombrar y el directorio padre se sincroniza donde la plataforma lo permite. Una sesión en ejecución mantiene un bloqueo; otro turno espera hasta sessionLockWaitMs y luego falla con SESSION_BUSY. El libro mayor acumulativo de remoto directo usa un bloqueo separado propiedad del token para que diferentes sesiones no puedan sobresuscribirlo. A diferencia de los bloqueos normales de sesión/tablero de trabajo, el bloqueo de gasto nunca se reclama automáticamente: un propietario anterior en pausa podría sobrescribir una reserva más nueva. Si su proceso se bloquea, los lanzamientos de remoto directo fallan en modo cerrado hasta que se detengan todos los hosts del puente y un operador elimine solo stateDir\budget-locks\cumulative-remote-cost.lock.

Las transcripciones de sesión son JSON en texto plano en reposo. Pueden contener prompts, salidas, colas de error, rutas y contexto sensible de la tarea. Proteja stateDir, no ponga secretos en los prompts y trate get_session como una divulgación de su transcripción almacenada. get_session elimina deliberadamente los IDs nativos del backend y los metadatos, y limita cada campo devuelto, pero no es cifrado ni redacción. El puente pasa un resumen de contexto en texto plano acotado entre agentes; el truncamiento puede omitir contexto anterior, por lo que las decisiones críticas deben repetirse en el prompt actual.

Compilación, pruebas y empaquetado

npm run verify
node .\scripts\package.mjs

npm run package compila primero; npm pack también compila mediante su hook prepack. El comando de release requiere un commit de Git verificado, crea un directorio nuevo .release-staging, emite agent-bridge-v<package-version>.mcpb y verifica que el server/agent-bridge.mjs empaquetado, su source map y los scripts operativos de Windows sean byte a byte idénticos a las entradas candidatas confirmadas. El bundle incluye manifest.json, el runtime, su source map, operations/ y release-metadata.json; cada payload de runtime y operativo está fijado por SHA-256 y recuento de bytes en los metadatos de release. El conjunto operativo es deliberadamente reducido: readiness, el cutover de un solo bloqueo, rollback de release inmutable, inspección pasiva, registro de clientes y sus módulos de seguridad compartidos. Rechaza una ruta de salida existente y nunca modifica un servidor MCP instalado. No instales un paquete de desarrollo sobre hosts activos; usa un nuevo directorio inmutable y difiere los cambios de registro hasta que terminen las tareas en ejecución.

El MCPB usa el esquema de manifiesto 0.3 y el user_config proporcionado por el host; no incrusta una configuración mutable de marcador de posición. El comando de empaquetado informa tanto los valores SHA-256 del bundle como del runtime. Valida manifest.template.json con la CLI oficial de MCPB antes de un release. En Windows, instala e inspecciona un artefacto sin tocar el puntero activo:

.\scripts\install-release.ps1 -BundlePath .\agent-bridge-v0.3.0-rc.8.mcpb -ExpectedBundleSha256 <reported-bundle-sha256>
$candidate = "$env:USERPROFILE\.codex\agent-bridge\releases\<release-id>"
& "$candidate\operations\inspect-install.ps1"
node .\scripts\canary-release.mjs --release-path "$env:USERPROFILE\.codex\agent-bridge\releases\<release-id>" --install-root "$env:USERPROFILE\.codex\agent-bridge" --expected-version 0.3.0-rc.8 --expected-runtime-sha256 <reported-runtime-sha256> --evidence-dir "<durable-private-root>\installed-canary"
node .\scripts\canary-windows-shim.mjs --release-path "$env:USERPROFILE\.codex\agent-bridge\releases\<release-id>" --install-root "$env:USERPROFILE\.codex\agent-bridge" --expected-version 0.3.0-rc.8 --expected-runtime-sha256 <reported-runtime-sha256> --evidence-dir "<durable-private-root>\windows-shim-canary"

El canario de release instalado con proveedor deshabilitado lanza el runtime inmutable absoluto con config/state/root desechables, verifica todas las herramientas MCP requeridas y la identidad de diagnóstico, y demuestra que el shim estable, la configuración compartida y el marcador de promoción no cambiaron. El canario de shim de Windows ejecuta el mismo runtime instalado con un mock CLI local detrás de un .cmd canónico de npm en una ruta con espacios; verifica la identidad del runtime, la preservación exacta de argv hostil, la delegación de solo lectura, el centinela de no inyección de shell y los archivos estables sin cambios, sin llamar a un proveedor. Crea nuevos directorios de evidencia privados y duraderos fuera de la raíz de instalación estable. Las pruebas de release respaldadas por proveedor aceptan una ruta absoluta AGENT_BRIDGE_SERVER_PATH más los requeridos AGENT_BRIDGE_INSTALL_ROOT, AGENT_BRIDGE_EXPECTED_VERSION y AGENT_BRIDGE_EXPECTED_RUNTIME_SHA256; verifican que el runtime esté exactamente bajo el releases\<release-id>\server de esa instalación. Establece AGENT_BRIDGE_LIVE_REQUIRED=1 para que los saltos de dist de origen, autenticación o cuota no puedan confundirse con una aprobación de release, y conserva cada resultado estructurado como JSON saneado.

El harness de Manus es una transacción de dos etapas, duradera y de un solo uso. Previsualízalo con node test/live-manus.mjs --evidence-dir <nuevo-directorio-privado-absoluto>; la previsualización solo realiza comprobaciones locales de identidad/credenciales, crea un nonce criptográfico y un ticket pendiente, y no hace ninguna llamada a la API de Manus ni de salud. Revisa la previsualización y luego ejecuta el comando exacto vinculado al nonce que imprime. La ejecución consume atómicamente el ticket antes del arranque del bridge, la elicitación de aprobación, las sondas de salud o el trabajo pagado; la repetición falla. Limpia las variables ambientales MANUS_API_KEY y MANUS_API_BASE_URL, requiere un estado de salida exacto y detenido, verifica el delta de presupuesto y ambas aprobaciones consumidas, y conserva la evidencia privada de config/state/work/result en lugar de eliminarla.

Los bundles ignorados RC5/RC6/RC7 y sus directorios .release-staging son solo artefactos históricos. No son entradas de RC8 y nunca deben promoverse como el candidato actual.

Después de la promoción y la aceptación del cliente reiniciado, crea un descriptor estricto a partir de el ejemplo dentro de una raíz de evidencia controlada por el operador y ejecuta npm run evidence:release -- --descriptor <descriptor-absoluto.json> --output-dir <raíz-de-evidencia>\<packet-id> --require-accepted. El nombre base del directorio de salida debe ser igual al packet ID. El exportador verifica los metadatos instalados, el marcador de promoción, la configuración compartida, el contenido del bundle, los hashes candidatos y el perfil de aceptación nombrado; acepta artefactos de entrada solo desde esa raíz de evidencia canónica, rechaza datos confidenciales/restringidos y sobrescrituras, redacta campos JSON de narrativa/ID de proveedor incluso cuando el estado privado fue renombrado, y escanea claves y valores JSON en busca de identificadores nativos de Manus antes de emitir evidence-report.json, evidence-report.md y manifest.json sincronizados. Ejecuta npm run evidence:verify -- --packet-dir <directorio-de-paquete-absoluto> para detectar archivos faltantes, adicionales o modificados. El manifiesto es una verificación cruzada de integridad, no una firma contra un editor local malicioso. Protege la ACL de Windows de la raíz de evidencia por separado. La promoción es provisional hasta que la exportación final aceptada tenga éxito. Un paquete bloqueado antes de la promoción puede exportarse sin --require-accepted; es evidencia, no aceptación.

Previsualiza la normalización de registro para Codex, Claude Code y perfiles detectados de Claude Desktop con <candidate-release>\operations\configure-clients.ps1. Es de ejecución en seco por defecto, rechaza procesos de destino activos o registros ambiguos, y admite un manifiesto de restauración de bytes exactos para archivos modificados. No uses su modo independiente -Apply para un cutover de release normal. Ejecuta las operaciones de release desde el directorio inmutable instalado del candidato, no desde un checkout de código fuente mutable.

El cutover de release es una operación deliberada de ventana de mantenimiento, no una acción de watcher desatendida. Cierra por completo Codex, Claude Code, Claude Desktop y otros hosts MCP, y luego ejecuta <candidate-release>\operations\check-cutover-readiness.ps1. Requiere muestras vacías repetidas en los nodos de Agent Bridge y familias y descendientes conocidos de hosts Codex/Claude. Usa <candidate-release>\operations\cutover-release.ps1 -ReleaseId <versión+sha7> para la transacción real de registro y release de un solo bloqueo. El watcher puede informar la preparación, pero nunca debe invocar un comando de mutación. Esto es quiescencia operativa, no una barrera de lanzamiento impuesta por el SO; un host abierto durante la ventana hace que la transacción se anule y restaure donde sea detectable.

Antes del cutover, scripts\rehearse-rollback.ps1 puede instalar bundles candidatos y anteriores de hash exacto en un nuevo fixture externo, cambiar candidato → anterior → candidato, ejercitar el shim estable del fixture y los canarios MCP deshabilitados por proveedor, y conservar un manifiesto de evidencia con hash. No acepta ninguna ruta de instalación en vivo ni de registro de clientes. El primitivo de conmutación confiable aún requiere que todos los hosts MCP estén cerrados, y esta prueba desechable no reemplaza el simulacro de rollback en vivo posterior al cutover.

<trusted-release>\operations\switch-release.ps1 es el primitivo de release/rollback de nivel inferior. Verifica el runtime instalado de destino, usa un shim de mantenimiento que rechaza, escribe el marcador de release antes de habilitar el shim en vivo, crea una copia de seguridad de rollback exacta y falla de forma cerrada en procesos activos. Usa los bytes de script operativo verificados más recientes incluso cuando su objetivo -ReleaseId es un runtime instalado más antiguo. protect-state.ps1 reemplaza las ACL heredadas del directorio de estado con acceso explícito para el usuario actual, SYSTEM y Administradores; inspecciona su objetivo antes de usar -Force.

Consulta HANDOFF.md para el procedimiento de release y rollback y SECURITY.md para el modelo de seguridad.