OrgX para DeepSeek Harness

@useorgx/deepseek-harness-plugin añade herramientas MCP de OrgX a un perfil de DeepSeek Harness y puede ejecutar un peer de gateway de OrgX vinculado al área de trabajo a través del modo headless de Harness.

Este paquete es una vista previa para desarrolladores. La instalación de un paquete solo demuestra que el bundle está presente; no demuestra autenticación de OrgX, admisión al gateway, un envío exitoso, implementación o uso en producción.

Instalar con el asistente de OrgX

El flujo de usuario compatible es el asistente de OrgX. Detecta una instalación compatible de DeepSeek Harness, instala este paquete en el perfil headless y vincula OrgX en el navegador:

npx @useorgx/wizard@latest setup

Luego inicia una tarea a través del asistente para que pueda actualizar el token OAuth antes de que se inicie DSH:

npx @useorgx/wizard@latest deepseek "List the OrgX tools available in this workspace."

El bundle de DSH falla al iniciar si su conexión MCP o la sincronización inicial de herramientas falla. No trates la presencia del paquete como prueba de que la superficie de herramientas de OrgX está autenticada.

Related MCP server: dsh-harness-mcp-server

Instalar el bundle directamente

DeepSeek Harness está anclado a 0.1.0-rc.6. Los usuarios avanzados pueden instalar el paquete directamente con Node ^22.19.0 o >=24.0.0:

npm install --global @deepseek-ai/dsh@0.1.0-rc.6
export ORGX_MCP_ACCESS_TOKEN='your_orgx_oauth_access_token'
export DEEPSEEK_API_KEY='your_deepseek_key'
dsh plugin --profile headless add @useorgx/deepseek-harness-plugin@0.1.0
dsh --profile headless --dump-config
dsh --profile headless "List the OrgX tools available in this workspace."

Para el desarrollo de la fuente, ejecuta npm pack --ignore-scripts e instala el tarball resultante con una URL file:. Un enlace local simple no proporciona la misma garantía de instalación limpia.

El paquete incluye el cliente peer de gateway de OrgX exacto con licencia MIT de @useorgx/orgx-gateway-sdk@0.1.0-alpha.9 commit 49f3cad612954c448878dc62d0f9c6bc87fa0f79. DSH bloquea Git y otras subdependencias exóticas al instalar plugins, por lo que incluir ese cliente auditado es lo que mantiene instalable un perfil nuevo. Consulta THIRD_PARTY_NOTICES.md.

El bundle monta una instancia de @deepseek-ai/dsh-mcp-client llamada orgx. Se conecta a https://mcp.useorgx.com/mcp a través de HTTP Streamable y envía Authorization: Bearer $ORGX_MCP_ACCESS_TOKEN. Ese valor debe ser un token de acceso OAuth 2.1 de OrgX administrado por el cliente; la clave de gateway oxk_ no es válida para MCP alojado. Establece ORGX_MCP_URL para usar otro endpoint MCP de OrgX. El inicio falla cuando el token OAuth falta o la conexión MCP inicial y la sincronización de herramientas fallan. Esta vista previa no ejecuta el flujo PKCE del navegador ni actualiza tokens; reemplaza el token de acceso administrado por el cliente cuando caduque.

DeepSeek Harness 0.1.0-rc.6 solo puentea herramientas MCP. Los Recursos y Prompts de MCP no están disponibles a través de este cliente. Los bloques MCP que no son de texto también tienen una proyección hacia el modelo con pérdida, incluso cuando el resultado local de la ejecución conserva sus bloques JSON.

Ejecutar el peer de OrgX

El peer establece el cwd de ejecución dentro de ORGX_WORKSPACE_ROOT; un repositorio solicitado que se resuelva fuera de ese directorio falla antes de que se inicie Harness. Este es un límite de ruta y mutación, no un aislamiento del host. workspace-write de Harness no confina las lecturas de archivos del mismo usuario, la visibilidad de procesos o el acceso a la red, por lo que un modelo o herramienta puede observar otros datos del host o enviar datos a través de la red. Establece ORGX_DEEPSEEK_HOST_ACCESS_ACK=1 solo después de aceptar ese riesgo; el inicio y la preparación de las credenciales fallan sin el reconocimiento.

Usa una clave API con ámbito para gateway:drive y plugin:heartbeat. La respuesta de la clave de gateway de OrgX devuelve un installation_id; mantén ese valor estable con la clave y pása ambos sin cambios en cada inicio.

export ORGX_API_KEY='oxk_your_workspace_key'
export ORGX_MCP_ACCESS_TOKEN='your_orgx_oauth_access_token'
export DEEPSEEK_API_KEY='your_deepseek_key'
export ORGX_WORKSPACE_ID='your-workspace-uuid'
export ORGX_INSTALLATION_ID='install.your-stable-installation-id'
export ORGX_WORKSPACE_ROOT='/absolute/path/to/the/workspace'
export ORGX_DEEPSEEK_HOST_ACCESS_ACK='1'
dsh plugin --profile headless exec orgx-deepseek-harness-peer

Esta vista previa es un peer no administrado del protocolo de gateway v1. No implementa el ciclo de vida de activación y promoción candidato/canónico. Proporcionar ORGX_RUNNER_INSTANCE_ID, ORGX_ACTIVATION_ATTEMPT_ID u ORGX_RUNNER_ROLE falla claramente al inicio; esos campos nunca se envían en su heartbeat o URL de socket.

Antes de abrir su WebSocket, el peer escribe un heartbeat de gateway con disponibilidad de transporte y envío falsa. Anuncia disponibilidad de envío solo después de que todas estas verificaciones tengan éxito:

• dsh --version demuestra que el proceso de ejecución anclado está vivo;

• el endpoint oficial anclado https://api.deepseek.com/user/balance acepta DEEPSEEK_API_KEY e informa is_available: true sin realizar una solicitud de inferencia; y

• un intercambio MCP Streamable HTTP initialize más tools/list acepta ORGX_MCP_ACCESS_TOKEN.

La presencia de secretos y un comando de versión sin credenciales nunca se tratan como autenticación. Las fallas de prueba, las credenciales rechazadas o caducadas y la evidencia faltante permanecen con cierre seguro. La evidencia exitosa se almacena en caché durante 45 segundos; el peer actualiza la presencia del gateway cada 15 segundos y escribe un heartbeat fuera de línea de mejor esfuerzo cuando el socket se cierra.

El hijo de DSH recibe la clave del proveedor y el token de acceso MCP con ámbito separado, pero no la clave del gateway. Los controles ambientales DSH_* no se reenvían excepto DSH_HOME; al hijo se le fuerza el permiso workspace-write y la telemetría está deshabilitada para que las configuraciones ambientales de acceso completo o exportación OTLP no puedan anular esas dos políticas. Estas configuraciones aún no aíslan las lecturas del host, los procesos o el acceso a la red.

Configuraciones de tiempo de ejecución opcionales:

• ORGX_BASE_URL cambia la URL base del gateway de OrgX.

• ORGX_RECEIPT_OUTBOX_PATH establece un directorio absoluto de recibos duraderos. El valor predeterminado está en el directorio de estado de OrgX del usuario actual.

• ORGX_DEEPSEEK_HARNESS_BIN cambia la ruta del ejecutable de dsh.

• ORGX_DEEPSEEK_HARNESS_PROFILE cambia el perfil de headless.

• ORGX_DEEPSEEK_HARNESS_MODEL activa el parche de modelo empaquetado para el proveedor deepseek-official. Cambia el valor predeterminado de la composición; un modelo ya guardado en la configuración de DSH aún puede tener prioridad.

La salida estándar de Harness headless contiene el texto final del asistente y un código de salida, pero no contabilidad de tokens o costos. El mensaje del cable del controlador, por lo tanto, debe llevar tokens_used: 0 y cost_estimate_cents: 0 numéricos; ambos significan desconocido en esta fuente, no gratis. OrgX canoniza el costo persistido de DeepSeek a su estimación de envío conservadora, registra la calidad de la medición y acumula esa estimación en los límites de presupuesto. Una salida de proceso cero informa outcome_kind: awaiting_review: el proceso terminó, pero el trabajo aún no está aceptado, fusionado, implementado o probado en producción.

El envío de WebSocket del SDK no tiene confirmación del servidor, por lo que la aplicación posee la durabilidad. Antes de ceder task.started, el peer escribe atómicamente un marcador de reserva previo al inicio. Si esa escritura falla, cierra el iterador interno antes de que Harness pueda generar y publica de mejor esfuerzo un recibo bloqueado. Antes de ceder cada marco task.completed posterior al inicio, escribe atómicamente el recibo HTTP v1 exacto en el buzón de salida con modo 0700 usando un archivo con modo 0600, luego lo publica en el endpoint de recibo de ejecución idempotente. Ninguna clave o token se escribe en ninguno de los archivos.

Solo una respuesta 2xx elimina un recibo terminal. Si la persistencia final falla después de que Harness ha completado, el peer intenta inmediatamente el recibo HTTP vinculado directamente y aún cede la finalización original. Un 2xx borra la reserva; si HTTP también falla, la finalización permanece en una cola de reintento en memoria y su marcador de reserva permanece. Los recibos pendientes se reintentan al inicio, la reconexión y cada tick de heartbeat de 15 segundos. Un reinicio con una reserva no resuelta falla con cierre seguro con un mensaje de reparación en lugar de arriesgar una re-ejecución.

El SDK anclado no puede recuperar de manera duradera task.failed solo por socket. Después de que una ejecución ha comenzado, este peer, por lo tanto, registra el motivo de la falla como un paso y emite outcome_kind: blocked; la cancelación emite outcome_kind: abandoned. Ambos usan el buzón de salida de la aplicación. Un duplicado rechazado antes de task.started permanece como task.failed y no puede terminalizar el envío que ya posee ese id de ejecución.

Validar

Para el desarrollo del paquete, instala las dependencias ancladas sin scripts de ciclo de vida, luego ejecuta las comprobaciones deterministas:

npm install --ignore-scripts --no-package-lock
npm run validate

El script de prueba del paquete ejecuta node:test explícitamente sobre test/*.node-test.mjs. El sufijo solo para Node mantiene estos conjuntos fuera de la detección de Vitest raíz del repositorio, preservándolos en npm run validate.

La validación verifica el bundle y el manifiesto, la preparación respaldada por evidencia, los límites del área de trabajo y del entorno hijo, las condiciones de carrera de cancelación y duplicados, los heartbeats no administrados del protocolo v1 y la recuperación de fallos HTTP en el momento de la desconexión del SDK anclado. No contacta a OrgX ni a DeepSeek.