dsh-bailinghub

dsh plugin --profile web add dsh-bailinghub

BailingHub for DeepSeek Harness

0.8.0: prepare tools once and read knowledge when needed

A local Agent can retain complete tool declarations, read one tool's guidance and retrieve only relevant reference knowledge. A cooperating host can confirm named context delivery before omitting repeated preparation bodies. Pair Core 0.10.0 / SDK 0.8.0 / DSH 0.8.0; existing authorization, approval and original-operation recovery remain in force.

[Changes](docs/RELEASE_NOTES_v0.8.0.en.md) · [Upgrade](docs/UPGRADE_v0.8.0.en.md)

[简体中文](docs/README.zh-CN.md) | English

Ask your local DeepSeek Harness Agent to work with a business system connected to BailingHub:

find records, update allowed fields, and follow the system's existing approval rules.

BailingHub records which authorization was used and what each business action returned.

Version 0.5.0 lets one conversation use authorizations from different systems on the same Hub.

Authorize a shop and inventory system separately, select both for a new conversation and ask:

Check tumbler stock. If any are available, change the corresponding shop product's price to 59

and list it; otherwise leave it unlisted.

The Agent reads stock with the inventory authorization, then uses the shop authorization for the

permitted price and listing actions. Those capabilities must already exist, and the product mapping

must be confirmed. A stock read does not reserve or synchronize stock. Price changes, listing

results and approvals are tracked separately.

The 0.4.0 same-system flow remains available: select Store A and Store B to compare sales without

switching a global connection. New system descriptions explain each selected system's purpose

before tool search, and business-supplied names identify the approved organization, account or

other subject. See [what changed and how to upgrade](docs/RELEASE_NOTES_v0.5.0.md).

It also keeps the visible conversation together with links to its business actions. If uploading

that record fails, it can retry after reconnecting or restarting without repeating those actions.

This is an independent community integration, not a plugin developed, certified, endorsed, or

recommended by DeepSeek.

Install and start

You need Node.js 22.19.0+ or 24+, pnpm, and a compatible DeepSeek Harness release. Your

administrator must first connect the business system to BailingHub. The matched release set is

BailingHub Core 0.10.0 → BailingHub MCP/SDK 0.8.0 → this plugin 0.8.0.

npm install --global pnpm @deepseek-ai/dsh@0.1.1-rc.2
dsh plugin --profile web add dsh-bailinghub@0.8.0

The plugin installs its exact bailinghub-mcp-server@0.8.0 dependency automatically.

For an existing installation, read the [migration steps from 0.4.0 and earlier](docs/MIGRATION_VNEXT.md).

Follow the [getting started guide](docs/GETTING_STARTED.md) to enter your administrator's four

public connection values and authorize in the browser. Do not put a business password, Client

Token, signing secret, or model-provider key into this plugin's settings or chat.

Choose the accounts for each conversation

Authorize each account separately through its original business authorization page and verify the

approved subject. A compatible business backend supplies its display name automatically, such as

“Brand flagship store” or “Main warehouse”. A missing name is shown as “Authorization name pending

sync”; the plugin does not guess it from a local alias.

Names are for display only. Duplicate names and renames do not merge or recreate credentials,

change an original Session, or rewrite history. Keep the local connection selector and fixed key

independent from both the current business name and the system description.

In a new conversation, before the first message, run:

/bailinghub connections list
/bailinghub scope set <shop-connection-key> <inventory-connection-key>
/bailinghub scope

Replace the placeholders with the fixed keys from the list, not connection names. You can select

just one account, several accounts in one system, or several systems on the same Hub and audit

domain. Each selected target must have its own original Agent Session.

Wait for the command to confirm the selection, then send your request.

New conversations start as ordinary chat until you select their business scope. Logging in or

changing the default connection does not enable business tools. /bailinghub scope none explicitly

chooses ordinary chat. The first user message freezes the selection; start a new conversation to

change accounts or move from ordinary chat to business access.

Matching tools within one system are shared; same-named tools from different systems remain

separate. The Agent chooses the authorization for each call; it does not receive credentials. Every action still uses that account's own permissions and

approval rules. An approval-required action continues the original call after approval while that

conversation is still running.

If any selected authorization is revoked, replaced, or cannot be checked, business access pauses

for the whole conversation. The plugin never silently switches to another account. A temporary

connection failure can be retried with the same original selection after the network returns.

A confirmed revocation or identity change requires a new conversation with a valid selection.

Follow the conversation and its actions

With Core 0.8.0 and SDK 0.5.0, BailingHub can show the visible user and assistant messages, turn

boundaries, and links to the original business runs as one conversation record. Each authorization

also keeps its own business-call record; the combined reply is not copied into every account's

memory.

/bailinghub archive status
/bailinghub archive sync

archive status shows whether the visible record has uploaded. archive sync retries the saved

record without running the business actions again. This is separate from /bailinghub sync,

which retries a pending run

…(truncated)