GSD for Qoder — EoS Registry entry

[cainiao1992]

GSD for Qoder — EoS Registry entry

Repository: https://github.com/cainiao1992/gsd-qoder
Latest release: https://github.com/cainiao1992/gsd-qoder/releases/latest
License: Apache-2.0

gsd-qoder embeds GSD in Qoder — Alibaba's AI coding product family, spanning Qoder CLI and Qoder Desktop. It is a third-party Embeddable Orchestration System: it depends on @opengsd/gsd-core, runs the ADR-1239 host-integration handshake against the installed SDK, and projects GSD's source agents, skills, and hook scripts into the Qoder config directory.

Why it exists

Qoder was originally proposed as an in-repo GSD runtime (issue #860, PR #2005). After seventeen review rounds the maintainer redirected it to the EoS path: Qoder is a third-party host, and since 1.7.0 the ADR-1239 Host-Integration Interface exists precisely so a third-party host integration can be first-class without living inside gsd-core. See the direction comment: #2005 (comment).

What it does

• gsd-qoder install — projects GSD agents into ~/.qoder/agents/, skills into ~/.qoder/skills/, hook scripts into ~/.qoder/hooks/, merges GSD's lifecycle hooks into settings.json (preserving the user's existing keys), and records an install manifest.
• gsd-qoder uninstall — removes exactly what the manifest recorded.
• gsd-qoder descriptor — prints the EoS descriptor (the nine negotiated axes) as JSON; this is the source of the registry entry.
• gsd-qoder doctor — verifies gsd-core is present, checks the negotiated protocol/profile, and flags missing or stale projected files.

Edition handling: ~/.qoder (International) and ~/.qoder-cn (Qoder China / Lingma) are the same product with different config directories. Install prompts interactively; --root or QODER_CONFIG_DIR skips the prompt. gsd-qoder install --plugin alternatively packages GSD as a Qoder Plugin and installs it through qodercli plugins install.

Declared axes — every value sourced, never inferred

Axis	Value	Source
embeddingMode	declarative	https://docs.qoder.com/en/cli/skills
commandSurface	slash-file	https://docs.qoder.com/en/cli/command
dispatch	named + nested + background, full subagent toolkit, isolation none	https://docs.qoder.com/en/cli/subagent
modelMode	passive	https://docs.qoder.com/en/cli/sdk/references
hookBus	host	https://docs.qoder.com/en/cli/hooks
stateIO	filesystem	https://docs.qoder.com/en/cli/quick-start
transport	mcp	https://docs.qoder.com/en/cli/mcp-servers
runtime	node	https://www.npmjs.com/package/@qoder-ai/qodercli
effortSurface	argv	https://docs.qoder.com/en/cli/model

Profile: declarative-cli. Protocol version: 1.

Known limitation, stated rather than papered over

dispatch.isolation is none — not because Qoder lacks a worktree primitive. Qoder's CLI docs document isolation: worktree as a frontmatter-declared, per-agent-definition property, while GSD's two isolation negotiation models (harness-worktree, orchestrator-worktree) both assume a per-dispatch injection point that Qoder's Agent tool and SDK schema do not expose. Activating it needs a third path: the converter injecting isolation: worktree into the executor agent's frontmatter at install time. Until that lands, none fails closed to sequential execution rather than running unisolated in parallel.

Feedback, experience reports, and questions welcome below.