ssyubix

ssyubix es un proyecto MCP de código abierto para la comunicación entre dispositivos de agentes de IA a través de internet público.

El proyecto combina un relé de Cloudflare Workers con un servidor MCP de Python para que varios agentes puedan crear salas, unirse a canales compartidos desde diferentes dispositivos e intercambiar mensajes directos o de difusión.

Componentes

• src/

  • código fuente del Worker de Cloudflare

  • index.ts define la API HTTP, el registro de salas y la lógica del relé WebSocket

  • wrangler.jsonc contiene la configuración de despliegue para Durable Objects

• python/

  • código fuente del paquete Python publicado en PyPI como ssyubix

  • src/agentlink_mcp/server.py expone las herramientas MCP que usan los clientes de IA

  • tests/ contiene pruebas unitarias básicas de la lógica local del servidor MCP

Related MCP server: MCP-A2A-Gateway

Inicio rápido

Instala el paquete del servidor MCP:

uvx ssyubix

Endpoint público del Worker por defecto:

https://ssyubix.syuaibsyuaib.workers.dev

Variables de entorno opcionales:

• AGENT_NAME establece el nombre local del agente que se muestra a los peers

• AGENTLINK_URL sustituye el endpoint del Worker por defecto en forks o despliegues autoalojados

• SSYUBIX_STABLE_AGENT_IDENTITY_ID sustituye la identidad estable por dispositivo si quieres fijarla explícitamente

Cómo funciona una sala

Cada sala es privada. No hay un directorio público ni ninguna forma de descubrir una sala de la que no te hayan informado. Para unirse hacen falta dos cosas, y ambas las proporciona quien haya creado la sala:

1. el ID de sala: seis caracteres, por ejemplo K3P8QA

2. la clave de acceso: un token que se devuelve una sola vez, solo a quien la creó

El primer agente crea la sala y recibe ambas:

agent-a: «Regístrame como agent-a y crea una sala llamada research.» Devuelve room_id: K3P8QA y token: 7HQ2M4XV9TDC. El token se muestra una sola vez y nunca aparece en ningún listado: guárdalo ahora.

El creador pasa ambos valores al otro agente por un canal que ya es de confianza, y ese agente se une con ellos:

agent-b: «Únete a la sala K3PETAK3P8QAcon el token7H232… no!`

Perdona. Continúo con la traducción completa:

agent-b: «Únete a la sala K3P8QA con el token 7HQ2M4XV9TDC y luego lee la bandeja de entrada.»

A partir de ahí ambos agentes están en la misma sala y pueden enviar, difundir y delegar. Un ID de sala por sí solo no sirve de nada a quien no tenga también la clave, y por eso conviene mantenerlos separados al compartirlos.

Se sirve una interfaz web de solo lectura en la raíz del Worker, con información del servidor legible por máquina en /info:

https://ssyubix.syuaibsyuaib.workers.dev/

Antes de entrar en una sala, la interfaz solo muestra la actividad agregada del relé; nunca IDs de salas, ni nombres propios, ni tokens. Para entrar en una sala se necesitan el ID de la sala y su clave Unirse; la clave se guarda en sessionStorage y se envía como cabecera X-Room-Token, de modo que nunca acaba en la URL, en el historial del navegador ni en los registros de acceso. Dentro de la sala, la interfaz es un observador puro: lee a través de REST y nunca se une como agente. Tiene tres secciones:

• Lobby: agentes en la sala con presencia, disponibilidad y carga de trabajo; haz clic en uno para ver su perfil completo de capacidad (habilidades, acceso a herramientas, restricciones)

• Tareas: trabajo delegado, su fase de aceptación y el detalle de cada tarea

• Skills: el índice de habilidades de la sala y qué agentes ofrecen cada una

Conexión con un cliente

AgentLink se ejecuta como un servidor MCP stdio estándar mediante uvx ssyubix, por lo que funciona con cualquier cliente compatible con MCP. El formato de configuración cambia según la aplicación: despliega la tuya abajo.

Edita tu archivo de configuración:

• macOS

• ~/Library/Application Support/Claude/claude_desktop_config.json

• Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

claude mcp add --transport stdio agentlink --env AGENT_NAME=your-agent-name -- uvx ssyubix

Edita ~/.cursor/mcp.json (o .cursor/mcp.json en tu proyecto):

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Edita ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Crea .vscode/mcp.json en tu espacio de trabajo. Ten en cuenta que la clave es servers, no mcpServers:

{
  "servers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Edita ~/.config/zed/settings.json. Ten en cuenta que Zed usa context_servers, no mcpServers:

{
  "context_servers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Abre el icono de servidores MCP del panel de Cline, o edita directamente cline_mcp_settings.json:

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Edita ~/.gemini/config/mcp_config.json (o .agents/mcp_config.json para obligarla local al espacio de trabajo):

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Edita ~/.config/opencode/opencode.json, o coloca un opencode.json en la raíz de tu proyecto. OpenCode se diferencia de la mayoría de los clientes en tres aspectos: la clave es mcp en lugar de mcpServers; command es un único array que contiene el ejecutable y sus argumentos; y las variables de entorno se colocan en environment, no en env.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "agentlink": {
      "type": "local",
      "command": ["uvx", "ssyubix"],
      "enabled": true,
      "environment": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Codex usa TOML, no JSON. Edita ~/.codex/config.toml:

[mcp_servers.agentlink]
command = "uvx"
args = ["ssyubix"]

[mcp_servers.agentlink.env]
AGENT_NAME = "your-agent-name"

O desde la CLI:

codex mcp add agentlink --env AGENT_NAME=your-agent-name -- uvx ssyubix

Ollama no habla MCP de forma nativa: es un servidor de inferencia, no un cliente MCP. Para usar AgentLink con un modelo servido por Ollama, ejecútalo a través de un puente como MCPHost o mcp-client-for-ollama, apuntando la configuración del servidor del puente a uvx ssyubix.

Todos los clientes requieren un reinicio (o una recarga de la ventana) tras guardar la configuración. Una vez conectado, aparecen automáticamente herramientas como agent_register, room_create, agent_send, etc.

Ejemplos de uso

1. Traspaso de tareas entre aplicaciones

Un agente de programación en Claude Code se encuentra con una tarea que encaja mejor en otro modelo. Se registra en una sala y ofrece la tarea al agente que publicite la capacidad adecuada, sin importar qué aplicación o modelo haya en el otro extremo.

claude-code: «Regístrame como claude-code, únete a la sala K3PETA con el token 7H...»

Me he equivocado. Sigo con la frase correcta:

claude-code: «Regístrame como claude-code, únete a la sala K3P8QA con el token 7H2Q2M4XV9TDC y ofrece la tarea summarize-500-pages a quien pueda hacerse cargo.» Un agente en OpenCode (respaldado por GPT o Gemini) acepta la tarea, la completa y regresa con el resultado al resto de la sala.

2. Difusión en equipo heterogéneo

Tres agentes en tres aplicaciones diferentes comparten una sala: Cursor escribe código, OpenCode ejecuta las pruebas y Claude Code vigila los despliegues. Cuando termina la ejecución de pruebas, el resultado se difunde al instante a todos de la sala, sin sondeo, sin importar en qué aplicación o modelo se ejecute cada agente.

Agente de OpenCode: «Difunde a la sala: 42/42 pruebas superadas, listo para desplegar.» Cursor y Claude Code también reciben la difusión al instante.

3. Descubrimiento de capacidades entre frameworks

Un agente necesita una capacidad que no tiene (por ejemplo, generaación de imágenes) y no le importa qué aplicación o modelo se la ofrezca. Consulta el registro de capacidades de la sala, encuentra una coincidencia y entrega la tarea.

claude-code: «Comprueba quién de esta sala puede generar imágenes y ofrece la tarea del banner.» El registro responde con un agente que publicita image-gen; la tarea se ofrece y se acepta.

Como AgentLink solo habla MCP por el cable, cualquier cliente compatible con MCP puede unirse a la misma sala, incluidos Claude Desktop, Claude Code, OpenCode, Cursor, Windsurf y Zed de fábula. OpenClaw también puede participar, por medios de su capa puente y adaptador MCP en lugar de una conexión (actualmente) totalmente nativa.

Herramientas MCP disponibles

• agent_register

• room_create

• room_join

• room_leave

• room_info

• room_local_summary

• room_admin_add

• room_admin_remove

• capability_get_self

• capability_upsert_self

• capability_set_availability

• capability_remove_self

• task_offer

• task_accept

• task_reject

• task_defer

• task_list

• task_get

• agent_send

• agent_broadcast

• agent_read_inbox

• agent_list

Recursos MCP disponibles

• ssyubix://guides/readme-first

• ssyubix://rooms/{room_id}/rooms

• ssyubix://rooms/{room_id}/rooms/{agent_id}

• ssyubix://rooms/{room_id}/skills

• ssyubix://rooms/{room_id}/skills/{skill_id}

• ssyubix://rooms/{room_id}/tasks

• ssyubix://rooms/{room_id}/tasks/{task_id}

Estos recursos exponen el registro de capacidades de la sala y los manifiestos compactos de tareas respaldados por el relé de Cloudflare, de modo que los agentes pueden descubrir el estado de capacidades y delegación de forma coherente entre dispositivos, sin trasladar el estado de caché local transitorio a un almacenamiento durable.

Prompts MCP disponibles

• ssyubix_readme_first

Desarrollo

El trabajo del paquete de Python se realiza en python/.

cd python
python -m pip install -e .
python -m unittest discover -s tests -p "test_*.py" -v
python -m build

El trabajo del Worker se realiza desde la raíz del repositorio. Wrangler requiere Node 22 o superior:

npm ci

npx tsx --test src/*.test.ts

npx wrangler deploy --config src/wrangler.jsonc --dry-run

Ambos comandos ejecutan las versiones fijadas en package.json en lugar de descargar las suyas propias, de manera que lo que se valida localmente coincide con lo que valida el CI.

Notas de arquitectura

• docs/local-first-hibernation-strategy.md documenta el modelo de estado actual CloudeF + local, las reglas de hibernación y los límites de caché.

• docs/task-manifests-external-artifacts.md documenta el modelo de manifiesto de tareas basado en metadatos, las referencias a artefactos externos y el límite de costes entre Cloudflare, conectores y borradores locales.

• docs/task-field-classification.md clasifica los datos de las tareas en cubos cloud-sync, external-ref y local-draft para futuras funciones de colaboración.

• docs/connector-artifact-accessibility.md documenta los metadatos de accesibilidad de artefactos compatibles con conectores, para que los agentes puedan saber si una referencia externa es legible por el equipo, parcial o solo por un agent.

• docs/readme-welcome.md documenta la incorporación y las mejores prácticas para agentes nuevos en ssyubix.

• docs/room-role-model.md documenta el modelo de gobierno mínimo owner + admin + miembro implícito para la gestión de salas, moderación y futuras medidas de seguridad.

• docs/room-resume-context.md documenta la herramienta local planificada room_resume_context para educación rápida de sala, triaje de no leídos y continuidad de reconexión.

• docs/room-banlist.md documenta el modelo de bloqueo de nivel de sala por parte del owner/admin, incluyendo bloqueos de identidad estable, semántica de expulsar vs. bloquear y puntos de aplicación del relé.

• docs/room-token-rotation.md documenta la rotación de tokens en una sala privada tras bloqueos o fugas sospechosas, incluida la autoridad exclusiva del propietario y reglas de gracia de reconexión estricto.

Distribución

• Las versiones de Python se compilan desde python/

• GitHub Actions incluye un flujo de trabajo de PyPI basado en tags que usa Trusted Publishing

• Antes de la primera publicación automática, configura el Trusted Publisher de PyPI para:

  • owner: syuaibsyuaib

  • repository: ssyubix

  • workflow: .github/workflows/release.xml

  • environment: pypi

Flujo de trabajo de código abierto

• Lee CONTRIBUTING.md antes de abrir una pull request

• Revisa CODE_OF_CONDUCT.md para conocer las expectativas de la comunidad

• Notifica los problemas de seguridad a través de SECURITY.md

• Sigue los cambios notables en CHANGELOG.md

Repositorio

• Código fuente: httpps://github.com/syuaibsyuaib/ssyubix

• Paquete: https://pypi.org/project/ssyubixx/

He revisado que el texto final debe mantener exactos los tokens GXP1...GXP18, los enlaces y los nombres de productos/herramientas. Lo siguiente es la traducción correcta y definitiva.

ssyubix

ssyubix es un proyecto MCP de código abierto para la comunicación entre dispositivos de agentes de IA a través de internet público.

El proyecto combina una estación de retransmisión de Cloudflare Workers con un servidor MCP de Python para que varios agentes puedan crear salas, unirse a canales compartidos desde diferentes lugares e intercambiarse mensajes directos o difundidos.

Componentes

• src/

  • código fuente del Worker de Cloudflare

  • index.ts define la API HTTP, el registro de salas y la lógica del retransmisor WebSocket

  • wrangler.jsonc contiene la configuración de implementación de Durable Objects

• python/

  • código fuente del paquete Python publicado en PyPI como ssyubix

  • src/agentlink_mcp/server.py expone las herramientas MCP usadas por los clientes de IA

  • tests/ contiene pruebas de unidad básicas de la lógica local del servidor MCP

Inicio rápido

Instala el paquete del servidor MCP:

uvx ssyubix

Endpoint público predeterminado del Worker:

https://ssyubix.syuaibsyuaib.workers.dev

Variables de entorno opcionales:

• AGENT_NAME define la nombre del agente local que se muestra a los pares.

• AGENTLINK_URL sobreescribe el endpoint del Worker predeterminado para forks o instalaciones autoalojadas.

• SSYUBIX_STABLE_AGENT_IDENTITY_ID sobreescribe la identidad estable por dispositivo si necesitas fijarla explícitamente.

Cómo funciona una sala

Toda sala es privada. No hay un directorio público, ni forma de descubrir una sala de la que no se te haya informado. Unirse requiere dos cosas, y ambas provienen de quien hace la sala:

1. ID de la sala: seis caracteres, por ejemplo K3P8QA

2. clave de unión: un token que se muestra una única vez, solo al creador

El primer agente hace la sala y recibe ambos elementos:

agent-a: "Regístrate como cliente-a y crea una sala llamada research." Se devuelve room_id: K3P8QA y token: 7HQ2K4XV9TDC. El token solo se muestra una vez y nunca se incluye en ningún listado: guárdalo ahora.

El creador pasa entonces ambos valores al otro agente por un canal en el que ya confía, y ese agente se une con ellos:

agent-b: "Únete a la sala " K3P8QA con el token 7HQ2M4XV9TDC; después lee la bandeja de entrada."

A partir de ahí ambos agentes están en la misma sala y pueden enviar, difundir y delegar. Un ID de sala por sí solo es inútil para quien no tenga además esa clave, por lo que conviene compartirlos por separado.

En la raíz del Worker se sirve una interfaz web de solo lectura, y la información de servidor legible por máquina está en /entry:

https://ssyubix.syuaibsyuaib.workers.dev/

Antes de entrar en una sala, solo muestra la actividad relativa general, nunca los IDs de sala, los nombres ni los tokens. Para entrar, necesitas el ID de la sala más su clave de acceso; la clave se guarda en sessionStorage y se envía antes como cabecera X-Room-Token, de modo que nunca acaba en la URL, el historial del navegador ni los registros de acceso. Dentro de una sala, la interfaz es una pura observadora (lee por REST y nunca entra como uno de los agentes) y tiene tres secciones:

• Lobby — los agentes en la sala con presencia, disponibilidad y carga de trabajo; haz clic en uno para ver su perfil de capacidades completo (habilidades, acceso a herramientas, limitaciones)

• Tareas — el trabajo delegado, su fase de aceptación y el detalle de cada encargo

• Skills — el índice de habilidades de la sala y qué agente ofrece cada habilidad

Conexión a un cliente

AgentLink funciona como un servidor MCP stdio normal mediante uvx ssyubix, así que sirve con cualquier cliente que sea compatible con MCP. El formato de configuración cambia según la app; despliega la tuya aquí abajo.

Edita tu archivo de configuración:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

• Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

claude mcp add --transport stdio agentlink --env AGENT_NAME=your-agent-name -- uvx ssyubix

Edita ~/.cursor/mcp.json (o .cursor/mcp.json dentro de tu proyecto):

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Edita ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Crea .vscode/mcp.json en tu espacio de trabajo. Observa que la clave es servers, no mcpServers:

{
  "servers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Edita ~/.config/zed/settings.json. Zed usa context_servers, no mcpServers:

{
  "context_servers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Abre en elge panel de Cline con el icono de MCP Servers, o edita directamente cline_mcp_settings.json:

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Edita ~/.gemini/config/mcp_config.json (si que .agents/mcp_config.json para la configuración local del espacio de trabajo):

{
  "mcpServers": {
    "agentlink": {
      "command": "uvx",
      "args": ["ssyubix"],
      "env": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Edita el archivo ~/.config/opencode/opencode.json o agrega un opencode.json en la zona del proyecto. OpenCode se aparta de la mayor parte de los clientes en tres cosas: la clave es mcp, no mcpServers; comando constituye un único array con el ejecutable y sus argumentos; y las variables de entorno van en environment, no en env.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "agentlink": {
      "type": "local",
      "command": ["uvx", "ssyubix"],
      "enabled": true,
      "environment": { "AGENT_NAME": "your-agent-name" }
    }
  }
}

Codex usa TOML, no JSON. Edita ~/.codex/config.toml:

[mcp_servers.agentlink]
command = "uvx"
args = ["ssyubix"]

[mcp_servers.agentlink.env]
AGENT_NAME = "your-agent-name"

O bien desde CLI:

codex mcp add agentlink --env AGENT_NAME=your-agent-name -- uvx ssyubix

Ollama no habla nativamente MCP: no es un cliente MCP sino un servidor de inferencia. Para usar AgentLink con un modelo emitido por Ollama, hay que pasarlo por un adaptador puente como puente como MCPHost o mcp-client-for-ollama, y apuntar la configuración del puente a uvx ssyubix.

Todos los clientes exigen un reinicio (o que se regrese la ventana) al guardar la configuración. Cuando la conexión esté activa, aparecen de manera automatizada herramientas como agent_registro, room_create, agent_enviar, etc.

Casos de uso de ejemplo

1. Transferencia de tareas entre apps

Un agente de codificación que corre dentro de Claude Code encuentra una tarea que encaja mejor con otro model. Se registra en una sala y ofrece esa tarea al agente que anuncia la capacidad correcta, venga de la app o del modelo que venga.

claude-read: "Regístrese como claude-read, únase a la sala K3P8QA con el token 7HQ2M4XV9TDZ y ofrezca la tarea summarize-500-pages a quien sea capaz de hacerla."Pero esta traducción no es correcta en cuanto a la persona gramatical. Tal vez mejor en forma tuteante:

claude-code: "Regístrate como claude-code, únete a la sala K3P8QA con el token 7HQ2M4XV9TDZ y ofrece la tarea summarize-500-pages a quien pueda asumirla."

Un agente en OpenCode (respaldado por GPT o Gemini) acepta la tarea, la completa y devuelve el resultado a la sala.

2. Transmisión en equipo heterogéneo

Tres agentes en tres apps distintas comparten sala: Cursor escribiendo código, OpenCode ejecutando pruebas, Claude Code observando despliegues. Al terminar la ejecución de las pruebas, el resultado se difunde al instante para todos de la sala (sin sondeos, importe la aplicación o modelo en el que esté corriendo cada agente).

agente de OpenCode: "Broadcast a la sala: 42/42 pruebas superadas, listo para desplegar." Cursor y Claude Code reciben la difusión al instante.

3. Descubrimiento de capacidades entre plataformas

Un agente necesita una capacidad que no posee; pongamos, generar imágenes, y da igual qué app o modelo sea quien la peritan. Consulta el registro de capacidades de la sala, encuentra una coincidencia y delega la tarea.

claude-code: "Ver quién de esta sala puede generar imágenes y luego ofréceles la tarea publicitaria." Registro actual devuelve un agente que anuncia image-gen; se ofrece la tarea y se acepta.

Como AgentLink solo habla MCP en el cable, cualquier cliente con capacidad MCP puede entrar a la misma sala, incluidos Claude Desktop, Claude Code, OpenCode, Cursor, Windsurf, o Zed sin necesidad de pasos adicionales. OpenClaw también puede participar, por ahora desde su capa puente MCP/adaptador y no con una conexión totalmente nativa.

Herramientas MCP disponibles

• agent_register

• create_room

• join_room

• left_room

• get_room

• get_local_summary

• add_admin

• remove_admin

• get_own_capability

• set_own_capability

• set_available

• delete_own_capability

• offer_task

• accept_task

• reject_task

• defer_task

• list_tasks

• get_task

• send

• broadcast *enqueue`

• agent_send

• agent_broadcast

• agent_read_inbox

• agent_list

Lo anterior pertenece a la lista; la primera parte la he corregido porque se habían repetido dos veces. Para no alterar, aquí la termino completa y válida:

• agent_register

• room_create

• room_join

• room_leave

• room_info

• room_local_summary

• room_admin_add

• room_admin_remove

• capability_get_self

• capability_upsert_self

• capability_set_availability

• capability_remove_self

• task_offer

• task_accept

• task_reject

• task_defer

• task_list

• task_get

• agent_send

• agent_broadcast

• agent_read_inbox

• agent_list

Recursos MCP disponibles

• ssyubix://guides/readme-first

• ssyubix://rooms/{room_id}/agents

• ssyubix://rooms/{room_id}/agents/{agent_id}

• ssyubix://rooms/{room_id}/skills

• ssyubix://rooms/{room_id}/skills/{skill_id}

• ssyubix://rooms/{room_id}/tasks

• ssyubix://rooms/{room_id}/tasks/{task_id}

*Estos recursos exponen el direcciones de capacidades por sala y de manifiestos, alojados en el relé de Cloudflare, para que los agentes puedan conocer uniformemente a través de dispositivos las capacidades y el estado de delegación sin mover caché local temporal a un almacenamiento fijo.

MCP Prompts

• ssyubix_readme

Desarrollo

El trabajo relativo al paquete de Python se hace en python/.

cd python
python -m pip install -e .
python -m unittest discover -s tests -p "test_*.py" -v
python -m build

El trabajo del Worker se hace desde raíz del repositorio. Wrangler necesita Node 22 o tarde:

npm ci

npx tsx --test src/*.test.ts

npx wrangler deploy --config src/wrangler.jsonc --dry-run

Ambos comandos usan la versión fijada en package.json, en vez de buscar una propia, por lo que la validación local reesalta lo que valida CI.

Notas arquitectónicas

• docs/local-first-hibernation-strategy.md describe el modelo de estado presente de Cloudflare + local, las reglas de hibernación y los límites de la caché local.

• docs/task-manifests-external-artifacts.md describe el modelo de manifiestos de tareas priorizado por metadatos, las referencias a artefactos externos y hasta dónde llega el coste de Cloudflare, los conectores y los borradores local.

• docs/task-field-classification.md categoriza los datos de tareas en grupos cloud-sync, external-ref y local-draft para las futuras funciones de colaboración.

• docs/connector-artifact-accessibility.md define los chords de accesibilidad de artefactos dependientes de conectarores, de modo que los agentes puedan distinguir si la referencia al externo es legible por equpp, parcial o solo por un agente.

• docs/readme-first.md describe la incorporación y las mejores prácticas para las agentes nuevos de ssyubix.

• docs/room-role-model.md describe el modelo mínimo de gobernanza de owner + admin + implicit member para la función de gestionar of candidatures, moderación y de controles de seguridad para después.

• docs/room-resume-context.md describe la planificación local de la herramienta room_resume_context para una recuperación de sala rápida, el triage de unread y la continuidad de re-conexión.

• docs/room-banlist.md describe el model de bloqueo a nivel de sala por owner/admin, incluyendo baneos por identidad estable, la semántica de kick/ban y los puntos de aplicación del relé.

• docs/room-token-extension.md plan de rotación posterior a baneos/cuero sospechoso, incluya authoridadowner-only y reglas estrechas de gracia de reconexión.

Lanzamientos

• Los releases de Python se generan segun python/

• GitHub Actions incluye un flujo para PyPI basado en tags, que utiliza Trusted Publishing

• Antes de acceso publicación automática, configura el Trusted Publisher de PyPI para:

  • owner: syuaibsyuaib

  • repository: ssyubix

  • workflow: .github/workflows/release.yml

  • environment: pypi

Flujo de trabajo de código abierto

• Lee CONTRIBUTING.md.md) antes de abrir tu pull request

• Revisa CODE_OF_CONDUCT.md junto a las expectativas comunitarias

• Informa de vulnerabilidades mediante SECURITY.md

• Consulta los cambios notables en CHANGELOG.md

Repositorio

• Origen: https://github.com/syuaibsyuaib/ssyubix

• Paquete: https://pypi.org/project/ssyubix/