Foreword¶

In DSH, handling multi-session collaboration often involves manually recording “Zhang San did A, Li Si did B” in a long session and looking back to see who replied to what. This approach is prone to errors when there are many sessions and long context: mistaking others’ outputs for your own, or forgetting whether a ticket was sent out after a restart.

The dsh-supergroup introduced below is a plugin targeting this pain point. It does not change DSH’s session mechanism but adds an orchestration layer: one main session with several execution sessions, dispatching by sessionId, recovering results by rpcId, and auto-reconciling after restart. The maintainer is LXS652, categorized as Workflow, license MIT, project version 1.0.1.

What is it¶

One-sentence positioning: dsh-supergroup is a set of session orchestration plugins for DeepSeek Harness that combine a main session and several execution sessions into a “whole”. The main session handles decomposition and dispatch, execution sessions do their own thing, and results return to the main session precisely via the rpcId generated at dispatch time.

It solves specific problems:

• Dispatching is not done by title, nickname, or the currently selected session, but by a determined sessionId, avoiding the ambiguity of “who is it dispatched to”.
• Result recovery is not done by “guessing the next reply”, but anchored by the requestId (i.e., rpcId) generated at dispatch time; this ID enters the session history with the message.
• After the host restarts, the ledger is restored first, then historical reconciliation is performed for tickets “dispatched but not yet settled”. Only those proven to be completed converge; the rest are left for human judgment.
• Reconciliation only reads history and changes status; it never automatically re-sends—because external side effects may have already occurred.

Installation only requires adding an insert entry to the DSH profile, with no external dependencies.

Core Capabilities¶

The following lists the capabilities explicitly stated in the README, categorized by function.

Orchestration Model¶

Multiple “wholes” can exist simultaneously in one DSH profile. Each whole has an independent lead session, member list, and ticket ledger view. There are a maximum of 8 members; the lead cannot be a member.

Dispatch is completed via ms2_dispatch. Messages enter the member sessions, the ledger writes dispatch, and the ticket enters the delivered state. Recovery has two paths: 1. session/event fast path: following the same rpcId in user/message to turn/end; 2. Historical reconciliation: reading session history at startup, ms2_status, and /ms2 panel times, anchoring precisely by rpcId.

Restart Self-Healing¶

When the host restarts, delivered is first converted to uncertain (status of result unknown). Startup reconciliation continues checking history:

• Find turn/end and completed, settle as completed, keep reason: "restart" as evidence, mark source as history-reconcile-after-restart;
• No evidence found, keep uncertain, write reason into observeStats;
• uncertain can also be manually accept / fail by the lead session using ms2_resolve.

It is important to emphasize: the plugin never re-dispatches a ticket to “urge results”.

Sidebar Panel¶

• The left column lists sessions grouped by task type; “Collapse Batch Sessions” and “Collapse Empty Sessions” are two independent checkboxes;
• Clicking “Create a whole” enters a three-step wizard: Select lead session -> Select execution sessions (multi-select, empty sessions allowed) -> Enter whole name;
• Each whole card displays the lead session, members, ticket count, and in-progress count. Renaming, replacing members in bulk, and dissolving the whole can be done within the card;
• When there are in-progress tickets (delivered / uncertain), dissolving or removing the corresponding member will be rejected, and the specific requestId will be returned.

Permission Isolation¶

Members cannot call ms2_* coordination tools or cross-session tools; business tools work normally. Dispatch, adjudication, renaming, modifying members, and dissolving permissions are only with the whole lead.

Installation and Enablement¶

The current version has two installation paths; for new installations, Path A is preferred: directly modifying the profile’s patch file, without relying on the bundle mechanism.

Path A: Append insert entry to cordis.patch.yml¶

1. Place the plugin directory in a fixed location, confirming the entry file exists: <your workspace>/dsh-supergroup/src/plugin2.mjs.

2. Open ~/.dsh/profiles/<profile>/cordis.patch.yml, append at the end of the file:

- insert:
    - id: dsh-supergroup
      name: file:///<your workspace>/dsh-supergroup/src/plugin2.mjs
      config:
        registryFile: '<your DSH_HOME>\data\registry.json'
        groupsFile: '<your DSH_HOME>\data\groups.json'
        ledgerFile: '<your DSH_HOME>\data\tasks.jsonl'

Pay attention to three points here: name must be an absolute path in the form of file:/// and point to the entry file src/plugin2.mjs (not the directory); Windows paths should write backslashes as /; the entry must be wrapped in an insert: list, cannot use the plugin: field, and cannot write - id: dsh-supergroup naked. If there is no corresponding existing entry, it will be treated as a override, the host will only record patch: entry ... not found and silently skip.

3. Restart DSH. The “Supervisor Deployment” icon should appear in the sidebar, and ms2_status should be available.

Regarding configuration, if groupsFile is omitted, it follows registryFile to groups.json in the same directory. If eventsLogFile is omitted, it falls into session-events.log in the same directory as the ledger. Optional configuration: startupReconcileAttempts (default 50, clamped 1..50), startupReconcileIntervalMs (default 200, clamped 1..200), bootstrapGroups (pre-sets wholes on first startup, array items are {name, lead, members}), startupReport (default false), selfTest (runs built-in self-check when passed an object).

Path B: Install as a bundle¶

If the profile already uses the bundle mechanism, three things must hold simultaneously, or it won’t load:

1. The profile’s package.json registers this package in dependencies, for example "dsh-supergroup": "file:<your workspace>/dsh-supergroup";
2. The same package.json’s dsh.profile.bundles array contains "dsh-supergroup";
3. Run pnpm install in the profile directory to actually put the package into node_modules.

After these three are complete, the bundle will read cordis.patch.yml inside the package. Here, name uses the package name dsh-supergroup, not the file:// path.

Troubleshooting if no reaction after install¶

1. Confirm you are editing the current profile’s cordis.patch.yml, the entry is appended at the end of the file, and is inside the insert: list.

2. Use dsh --dump-config to see the final configuration. Desktop profiles may be exclusively owned by Electron; you can copy it to check the dump:

cp -al ~/.dsh/profiles/<profile> ~/.dsh/profiles/<profile>-probe

3. Run grep dsh-supergroup to check the dump output; if patch: entry ... not found appears in stderr, it means the entry didn’t enter insert:, or the id is wrong.

4. If there is still no icon, confirm the entry file exists, name is the file:/// file URL, and DSH has been fully restarted—client bundles do not hot update.

Typical Usage¶

At the tool level, the main session completes daily orchestration via the following ms2_* tools:

A reproducible minimal workflow:

1. Execute ms2_group in the lead session to create a whole {"action":"create","name":"research","lead":"session-A","members":["session-B","session-C"]};
2. Split tasks into two tickets, dispatch them to session-B and session-C respectively using ms2_dispatch, each ticket generates a requestId;
3. Results flow back via the session/event fast path, or are settled via historical reconciliation at the next ms2_status or /ms2 panel;
4. If a ticket becomes uncertain, use ms2_resolve in the lead session to accept or fail based on evidence.

At the command level, the sidebar panel also supports the following commands. The content after the command is rawInput (excluding the /ms2 prefix):

/ms2 panel
/ms2 create {"name":"...","lead":"session-...","members":["session-..."]}
/ms2 dissolve <groupId>
/ms2 group rename {"group":"g-...","name":"..."}
/ms2 group members {"group":"g-...","members":["session-..."]}

These commands are sent to the target session by the client panel via ctx.remote.commands.execute. Only the whole lead can dissolve, rename, or modify members; member lists are full overwrites; if a removed member has delivered / uncertain tickets, the entire modification is rejected.

Applicable Scenarios and Notes¶

Suitable for: Users who need to manage multiple execution sessions within a single DSH profile, want clear attribution for dispatch, require traceable results, and care about not losing state after a restart. It delegates the three tasks of “who does it, is it done, does the ledger match after restart” to an engineered ledger and reconciliation, rather than relying on human memory.

Important boundaries, which are listed item by item in the README, are highlighted below:

• Fixed reconciliation timing: Only triggers at startup, ms2_status, and /ms2 panel. No background polling; nothing is settled unless called.
• No isolation: The plugin only does session orchestration; members share the file system, network, and cwd. No process, directory, or network isolation is provided; be aware of the visibility scope between members.
• No external effects exactly-once: The ledger guarantees ticket state recovery, but side effects executed by members before completion (sending messages, changing files, calling external APIs) cannot be rolled back by the plugin; please confirm idempotency yourself before retrying.
• Sessions must exist: Dispatch is only by sessionId and does not probe if the session is still valid. Invalid sessions will appear as “anchor point not found” during historical reconciliation.
• Main session transfer not currently supported: The lead is the session determined at the time of whole creation.

Additionally, this plugin runs with the current dsh process permissions. You should check if the source code and license (MIT) meet your environment requirements before installing. The plugin is categorized as Workflow in the SkillHub community directory. The community directory is an independent site with no official affiliation to DeepSeek.

Conclusion¶

dsh-supergroup fills this gap: the hardest part of multi-session orchestration is not “sending it out”, but “whether the books match after it’s sent out”. It uses sessionId for attribution, rpcId for recovery, and a persisted ledger plus historical reconciliation for restart self-healing. If you have already run multiple execution sessions in DSH, you can try it as a lightweight coordination skeleton.

Plugin directory page: https://www.skillhub.cn/plugins/LXS652/dsh-supergroup

Source code and documentation: https://github.com/LXS652/dsh-supergroup