[dsh-superagent] Support multiple isolated instances in one profile, or a first-class multi-repo mode

[linusok-agent]

Summary

dsh-superagent-prototype currently supports exactly one SuperAgent instance per DSH profile/process. Monitoring a second repository means creating a second profile with a different port and stateDir, then re-entering every setting: GitHub account/repository, Policy, prompts, executor/prepare, and Feishu bot/chats. The existing Web GUI also cannot show the second instance in its sidebar.

I would like to request either of these, in order of preference:

1. Multiple isolated instances in one profile, with an instanceId namespace for services/routes/panels/presets/health and a separate stateDir per instance.
2. A first-class multi-repo mode for one runtime, where a Ticket carries its repository and the worker/prepare/PR binding are chosen per repository.

At minimum, a supported way to clone a profile's settings (without secrets) into a companion profile would remove most of the repeated setup.

Why this matters

A team often has several repositories but wants one operator surface: one model provider, one set of prompt conventions, one place to see queues and attention. Today each repository is a separate process, port, state database, main Session, Feishu consumer, and a full copy of settings. There is no clone/import, and the 3082 sidebar cannot expose the second instance.

This is a configuration/UX problem before it is a compute problem: the second instance is functionally identical except for a few values (repository, account, state directory, port, bot).

Current blockers (from the code)

Adding a second dsh-superagent entry to the same profile collides on:

• Runtime is Service('orchestrator') (src/app/runtime.ts) — one service per process.
• HTTP routes are fixed at /orchestrator/api (src/app/http.ts); the client fetches that fixed path (src/client/api.ts).
• The client registers fixed PANEL_ID / ENTRY = dsh-superagent, with the label Superagent (src/client/index.tsx).
• Agent presets are fixed IDs dsh-superagent-router / dsh-superagent-worker (cordis.patch.yml).
• Health entries github, feishu, history, and the effect names are global.
• stateDir is protected by a process lock; one runtime per state directory.
• The GitHub Source config has a single repository; thread keys are github:<number> without a repository component, so two repositories with the same issue/PR number collide.

A second profile avoids the conflict, but it is a separate process, port, state DB, main Session, Feishu event consumer, and a full settings copy. Re-entering the configuration is the main pain point.

Proposal

Option 1: instance namespacing

Add an instanceId (or prefix) used for:

• the orchestrator service name,
• the HTTP base path (/orchestrator/<id>/api),
• the client panel ID and sidebar label,
• the agent preset IDs,
• health entry names,
• the settings/plugin entry key.

Then allow:

- id: dsh-superagent-work
  name: dsh-superagent
  config:
    instanceId: work
    stateDir: /path/to/state-work

The sidebar could list Superagent and Superagent (work). Each instance keeps its own state DB, Sessions, Policy, and worker slots, but shares the profile's model provider and process.

Option 2: multi-repo mode

One runtime with a list of repositories. A Ticket records its repository; the Executor's prepare, DSH_SUPERAGENT_GITHUB_REPOSITORY, branch naming, commit identity, and PR binding follow the Ticket's repository. Thread keys become github:<owner>/<name>:<number>, and Policy/admission can be scoped per repository. The main Session routes by repository.

This is the better product fit for the underlying use case, but it is a larger change than instance namespacing.

Option 3: companion-profile support

If multiple processes remain the intended model:

• a supported profile clone/settings export-import that copies Sources, Policy, prompts, and executor configuration without secrets;
• a host-level sidebar entry or shortcut for companion profiles, so one Web GUI can expose Superagent and Superagent2.

Reproduction sketch

# same profile, second entry
- id: dsh-superagent-2
  name: dsh-superagent
  config:
    stateDir: /path/to/state2

The second entry cannot run as an independent instance: service registration, routes, panel IDs, agent presets, and health names conflict with the first. A second profile avoids the conflict but requires a new port/state and a full settings copy.

Environment

• DSH 0.2.1-rc.5
• dsh-superagent 0.1.0 (prototype, commit 6337fc8)
• Node 22.22, Linux

The prototype repository has issues disabled, so I am posting this in the parent project's Ideas category. If there is a better tracker for dsh-superagent feedback, please point me there.

---

中文摘要： 当前一个 DSH profile 只能跑一个 SuperAgent。第二个仓库要新建 profile、端口、stateDir，并把 GitHub、Policy、Prompts、Executor、Feishu 全部重配一遍；现有 3082 的左侧也看不到第二个实例。希望支持同 profile 多实例（用 instanceId 做服务/路由/面板/preset/health 命名空间），或一个运行时多仓库；至少提供配置克隆/导入，减少重复初始化。

[n-pll]

Independent confirmation from a second deployment, plus one gap this post does not cover.

Setup. dsh-superagent 0.1.0 (6337fc8), DSH 0.2.2-rc.1, Linux. Only the Feishu Source is enabled (one chat); the GitHub Source is off. executor.directory and executor.prepare both pin one project: prepare is git -C <clone> worktree add -b agent/$DSH_SUPERAGENT_NAME <root>/... master. Requests arrive as chat messages and every Ticket lands in that one project's worktrees. So the pain is not only "re-enter settings for a second profile"; it is that one runtime knows exactly one project, and a request that belongs elsewhere cannot be placed.

The gap: with a non-GitHub Source the worker is never told which project it is in. SourceRegistry.environments() (src/sources/registry.ts:85-89) only emits variables for enabled Sources, so with the GitHub Source off, DSH_SUPERAGENT_GITHUB_REPOSITORY is not injected at all; the Executor's own variables are only DSH_SUPERAGENT_DIR/NAME/TICKET/BLOCKED_COMMANDS (src/app/execution-environment.ts:10-15). Project identity therefore lives only in the prepare string and in the directory path (src/executor/dsh.ts:110 derives the Ticket directory from the single execution root). No field of a Ticket carries the project, so "which project should this request go to?" has no answer today: it is not a missing heuristic, the data path does not exist.

Minimal incremental ask (a subset of Option 2, no instance namespacing needed):

1. Move prepare and directory from the global executor block (src/policy.ts:91-97) into per-Source configuration, so each Source describes where its Tickets check out.
2. Record the originating Source id, and the repository when the Source knows one, on the Ticket; expose both to the worker as e.g. DSH_SUPERAGENT_SOURCE / DSH_SUPERAGENT_REPOSITORY for every Source kind, not just GitHub.
3. Let the prepare command and the worker instructions read those values, so one plugin instance can serve several projects when the Source (bot, chat, or repository) determines the project.

This keeps one process, one panel, one settings page and one queue; Option 1 remains the better answer for genuinely independent deployments, and the two compose.

Direction question. If (1)-(3) is acceptable as the first step, we would rather send a patch than another proposal: we can prototype it in a fork and open a PR on dsh-superagent-prototype so you can decide with the diff in hand. If you would split it differently (for example per-repository Policy first), naming the first one you would take is enough for us to align.

中文摘要：我们在"只开 Feishu 来源、关掉 GitHub 来源"的部署里复现了同一个限制，并补一个原文没覆盖的点：SourceRegistry.environments() 只为已启用的 Source 输出变量，所以 GitHub 来源一关，worker 连 DSH_SUPERAGENT_GITHUB_REPOSITORY 都拿不到；Executor 自身变量只有 DIR/NAME/TICKET/BLOCKED_COMMANDS，项目身份只存在于 prepare 命令与目录路径里，Ticket 上没有任何可携带、可打印、可路由的项目字段——因此"这个需求该去哪个项目"不是启发式缺失，而是数据通路不存在。建议的最小增量方案（属于 Option 2 的子集，不需要实例命名空间）：①prepare/directory 从全局 executor 配置下沉到 Source；②Ticket 记录来源 Source id（以及来源已知时的仓库），并对所有来源类型暴露 DSH_SUPERAGENT_SOURCE / DSH_SUPERAGENT_REPOSITORY；③prepare 与 worker 指令可读取这些值，从而一个实例服务多个项目。若方向可接受，我们愿意直接在 fork 里做出来提 PR，让你看着 diff 决定。