dsh-bailinghub 0.3.0 → 0.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +80 -1
- package/PRIVACY.md +140 -7
- package/README.md +139 -198
- package/SECURITY.md +128 -3
- package/docs/AGENT_CLIENT_CONTRACT.md +433 -23
- package/docs/COMPATIBILITY.md +96 -4
- package/docs/CROSS_SYSTEM_CONVERSATIONS.md +136 -0
- package/docs/GETTING_STARTED.md +120 -60
- package/docs/GETTING_STARTED.zh-CN.md +101 -51
- package/docs/MIGRATION_VNEXT.md +142 -17
- package/docs/PROJECT_BOUNDARIES.md +6 -2
- package/docs/README.zh-CN.md +104 -173
- package/docs/RELEASE_NOTES_v0.5.0.md +79 -0
- package/lib/authorizations.js +76 -0
- package/lib/conversation-archive-store.js +265 -0
- package/lib/conversation-outbox.js +236 -0
- package/lib/index.js +3 -0
- package/lib/runtime.js +830 -49
- package/lib/session-scope-store.js +265 -0
- package/lib/session-scope.js +393 -0
- package/lib/subject-display.js +39 -0
- package/lib/system-info.js +76 -0
- package/lib/transport.js +26 -1
- package/package.json +4 -2
|
@@ -1,83 +1,133 @@
|
|
|
1
|
-
#
|
|
1
|
+
# 开始使用 0.5.0
|
|
2
2
|
|
|
3
|
-
这份指南面向业务系统已经接入 BailingHub
|
|
4
|
-
|
|
3
|
+
这份指南面向业务系统已经接入 BailingHub 的用户。管理员需要先准备 Core 0.7.0、公开的 Client
|
|
4
|
+
App ID、workspace 和浏览器业务授权入口。多系统时,每个目标分别授权,且属于同一中枢、同一
|
|
5
|
+
审计域;已有能力无需重新声明,但每项动作必须已由相应业务系统开放。
|
|
5
6
|
|
|
6
|
-
##
|
|
7
|
+
## 第一步:安装与配置
|
|
7
8
|
|
|
8
|
-
|
|
9
|
+
使用 Node.js `22.19.0+` 或 `24+`,并安装兼容的 DSH:
|
|
9
10
|
|
|
10
|
-
```
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
Workspace
|
|
14
|
-
Connection Name
|
|
11
|
+
```bash
|
|
12
|
+
npm install --global pnpm @deepseek-ai/dsh@0.1.1-rc.2
|
|
13
|
+
dsh plugin --profile web add dsh-bailinghub@0.5.0
|
|
15
14
|
```
|
|
16
15
|
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
发给你。
|
|
20
|
-
|
|
21
|
-
## 第一步:安装插件
|
|
22
|
-
|
|
23
|
-
把精确公开版本安装到 DSH Web Profile:
|
|
16
|
+
插件会自动安装 SDK 0.5.0。通过插件设置填写四项公开信息,或使用对应环境变量。下面都是
|
|
17
|
+
占位值,需要替换成管理员提供的中枢地址、Client App ID 和 workspace:
|
|
24
18
|
|
|
25
19
|
```bash
|
|
26
|
-
|
|
20
|
+
export BAILINGHUB_HUB_URL='https://hub.example.com'
|
|
21
|
+
export BAILINGHUB_CLIENT_APP_ID='example-agent-client'
|
|
22
|
+
export BAILINGHUB_WORKSPACE='order_assistant'
|
|
23
|
+
export BAILINGHUB_CONNECTION_NAME='A 店'
|
|
24
|
+
dsh --profile web --dump-config
|
|
25
|
+
dsh web
|
|
27
26
|
```
|
|
28
27
|
|
|
29
|
-
|
|
28
|
+
`Connection Name` 是你设置的本机名称。这四项都不是凭据;不要把业务密码、Client Token、签名
|
|
29
|
+
密钥、模型 Key、业务 API 地址或授权页面地址写入插件设置或聊天消息。
|
|
30
30
|
|
|
31
|
-
##
|
|
31
|
+
## 第二步:分别授权账号
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
在 DSH 中为第一家店执行:
|
|
34
34
|
|
|
35
|
-
```
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
export BAILINGHUB_CONNECTION_NAME='default'
|
|
35
|
+
```text
|
|
36
|
+
/bailinghub login
|
|
37
|
+
/bailinghub doctor
|
|
38
|
+
/bailinghub status
|
|
40
39
|
```
|
|
41
40
|
|
|
42
|
-
|
|
43
|
-
|
|
41
|
+
浏览器会打开原业务授权页面。在那里登录、切换账号,并按业务系统要求选择门店或租户;同意前
|
|
42
|
+
核对实际业务身份。可信身份由业务授权页面决定,本机名称 `A 店` 不证明身份。配套后端可自动
|
|
43
|
+
提供授权主体名称,它与固定连接键、系统用途说明独立;缺名会明确提示。同名或改名不重建授权,
|
|
44
|
+
也不更改原会话记录。
|
|
45
|
+
|
|
46
|
+
如需使用**同一系统、同一 workspace** 的 B 店,用同样的三项公开信息创建清晰命名的新连接,
|
|
47
|
+
再分别授权:
|
|
48
|
+
|
|
49
|
+
```text
|
|
50
|
+
/bailinghub connections add "B 店" https://hub.example.com example-agent-client order_assistant
|
|
51
|
+
/bailinghub login
|
|
52
|
+
/bailinghub connections list
|
|
53
|
+
```
|
|
44
54
|
|
|
45
|
-
|
|
55
|
+
请在业务页确认选中了 B 店。如果实际再次同意的是同一可信身份,SDK 会替换它的旧连接和 Session,
|
|
56
|
+
不会凭名称造出第二个身份。从已有名称授权另一身份时,原连接保留,新身份会获得可用别名。
|
|
57
|
+
`default-2` 之类的名称不能证明是哪家店,使用前应核对对应关系。若登录提示需要清理,新连接
|
|
58
|
+
已经授权成功;请检查并删除提示的旧条目,不要重复授权。
|
|
46
59
|
|
|
47
|
-
|
|
60
|
+
要接入**另一个系统**,使用管理员提供的该系统 Client App 与 workspace,并在同一中枢上
|
|
61
|
+
独立授权。例如库存目标可以使用以下占位配置:
|
|
48
62
|
|
|
49
63
|
```text
|
|
64
|
+
/bailinghub connections add "库存系统" https://hub.example.com inventory-client inventory_assistant
|
|
50
65
|
/bailinghub login
|
|
51
|
-
/bailinghub
|
|
52
|
-
|
|
66
|
+
/bailinghub connections list
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
这些配置不能从产品名称推测。每个选中目标都需要独立原 Agent Session;同系统流程中已有的
|
|
70
|
+
B 店连接可以继续保留。
|
|
71
|
+
|
|
72
|
+
## 第三步:选择本次会话的业务范围
|
|
73
|
+
|
|
74
|
+
**新建会话,在发送任何消息前**执行:
|
|
75
|
+
|
|
76
|
+
```text
|
|
77
|
+
/bailinghub connections list
|
|
78
|
+
/bailinghub scope set <商城连接键> <库存连接键>
|
|
79
|
+
/bailinghub scope
|
|
53
80
|
```
|
|
54
81
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
系统自己的登录流程,不会把业务密码或业务地址交给插件。
|
|
82
|
+
从列表复制固定连接键替换占位符,不能直接填写名称。可以选单份授权、同系统多份授权,或
|
|
83
|
+
同一中枢、同一审计域的多个系统。等设置成功回显后再发请求。相应能力已开放、商品关系已确认时:
|
|
58
84
|
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
85
|
+
```text
|
|
86
|
+
先查保温杯库存。有货就把商城对应商品的售价改为 59 元并上架;没货就先不要上架。
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
系统说明可在首次查工具前解释“线上售卖”和“库存管理”的区别。“尚未加载”表示还没查询工具,
|
|
90
|
+
不是没有能力。查库存不等于锁库存或自动同步;改价、上架及审批要分别核对结果。
|
|
91
|
+
|
|
92
|
+
原同系统流程仍可选择 A 店和 B 店,在报表能力可用时对比营业情况。没有实际调用的系统不能
|
|
93
|
+
被标为已执行。
|
|
65
94
|
|
|
66
|
-
|
|
95
|
+
智能体自行选择每次调用使用哪份选中授权;实际数据和操作范围仍由业务权限决定。先验证一次
|
|
96
|
+
查询,再在开发空间尝试一次可回滚且允许的修改。需要审批的操作继续沿用原规则。
|
|
67
97
|
|
|
68
|
-
|
|
98
|
+
未选择范围,或执行 `/bailinghub scope none` 时,只进行普通聊天,不启动 BailingHub 业务执行。
|
|
99
|
+
第一条消息会固定这个选择。之后要增减账号,或从普通聊天开启业务访问,需要新建会话;切换
|
|
100
|
+
连接管理的默认连接不会改变会话范围。
|
|
101
|
+
|
|
102
|
+
## 第四步:核对业务结果与沟通过程
|
|
103
|
+
|
|
104
|
+
在业务后台核对最终结果,在 BailingHub 查看原调用轨迹。配合 Core 0.7.0,还能把可见用户消息、
|
|
105
|
+
助手回复、轮次与相关执行记录放在同一份沟通记录里查看。多授权的各份执行记录仍分别保留自身
|
|
106
|
+
调用摘要。
|
|
69
107
|
|
|
70
108
|
```text
|
|
71
|
-
|
|
109
|
+
/bailinghub archive status
|
|
110
|
+
/bailinghub archive sync
|
|
72
111
|
```
|
|
73
112
|
|
|
74
|
-
|
|
75
|
-
|
|
113
|
+
第一条查看上传状态,第二条补传已保存记录,不会重做业务操作。`synced` 表示已保存事件获中枢
|
|
114
|
+
确认,不代表业务成功;`pending` 表示尚未传完;`blocked` 表示原授权当前无法允许上传;
|
|
115
|
+
`unsupported` 表示 SDK 或中枢不支持归档。`storage_error`、`recovery_gap` 表示采集本身可能
|
|
116
|
+
不完整;宿主没有历史可供核对时,覆盖度为未验证。
|
|
117
|
+
|
|
118
|
+
## 第五步:断网或重开后继续
|
|
119
|
+
|
|
120
|
+
重开已保存的业务会话时,核验全部原授权后才恢复原账号范围。若离线重开,联网后可以在同一
|
|
121
|
+
会话执行 `/bailinghub archive sync` 或 `/bailinghub scope` 再试一次。临时网络不确定可以恢复;
|
|
122
|
+
已撤销、被替换的授权,损坏的范围快照或存储冲突仍会阻断整组,不会自动换账号。
|
|
76
123
|
|
|
77
|
-
|
|
124
|
+
恢复范围与补传记录,**不等于恢复进程重启前未完成的业务调用或审批**。未开始的保存草稿需要
|
|
125
|
+
重新选择;旧版已开始但没有有效范围快照的会话只能保留为历史,请另开新会话。
|
|
126
|
+
`/bailinghub sync` 只用于当前仍运行会话的待同步执行结尾记录。
|
|
78
127
|
|
|
79
|
-
|
|
80
|
-
|
|
128
|
+
所选账号的上下文会共用本地模型会话;本机私有归档含明文任务正文,直到手动清理才删除。它不
|
|
129
|
+
采集隐藏思考、附件或全部历史。启用前请看[隐私说明](../PRIVACY.md);数据需要隔离的账号应分开
|
|
130
|
+
会话,不要在可见消息里粘贴秘密。
|
|
81
131
|
|
|
82
|
-
|
|
83
|
-
|
|
132
|
+
初始化失败时,可向 [GitHub Issues](https://github.com/bailinghub/bailinghub-dsh-plugin/issues)
|
|
133
|
+
提供版本、操作系统、失败命令和脱敏错误,不附带凭据、私有地址、授权码、个人信息或生产载荷。
|
package/docs/MIGRATION_VNEXT.md
CHANGED
|
@@ -1,7 +1,130 @@
|
|
|
1
|
-
#
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
1
|
+
# Migrate to 0.5.0
|
|
2
|
+
|
|
3
|
+
## From 0.4.0: add systems without replacing existing authorizations
|
|
4
|
+
|
|
5
|
+
Version 0.5.0 extends one-system multi-account conversations to different business systems on one
|
|
6
|
+
Hub and audit domain. It adds system descriptions before capability search and optional business
|
|
7
|
+
subject names. The four public plugin fields, existing host scope/archive APIs, permissions and
|
|
8
|
+
business approval rules remain in place.
|
|
9
|
+
|
|
10
|
+
1. Have the administrator back up and upgrade to Core 0.7.0. Apply only outstanding migrations in
|
|
11
|
+
order; upgrading from 0.6.1 includes 058/059. The plugin installer does not migrate the Hub.
|
|
12
|
+
2. Finish active business work and retry known pending completions with `/bailinghub sync`.
|
|
13
|
+
Retain the original DSH home, SDK credentials, real Session events, scope files and archive outbox.
|
|
14
|
+
3. Install and restart DSH:
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
dsh plugin --profile web add dsh-bailinghub@0.5.0
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
The package installs exact SDK 0.5.0. Do not manually mix in an older SDK or a local file dependency.
|
|
21
|
+
4. Check `/bailinghub doctor` and `/bailinghub connections list`. Valid existing authorizations
|
|
22
|
+
continue working; no new login is needed just for a version change or a display rename.
|
|
23
|
+
5. Add and authorize only the extra systems needed for the new task. In a new conversation, select
|
|
24
|
+
their fixed connection keys and wait for `/bailinghub scope` to confirm before sending a message.
|
|
25
|
+
6. Test an inventory read and a low-risk shop action with confirmed product mappings. Check each
|
|
26
|
+
target, separate result/approval, and original run link. Then check `/bailinghub archive status`.
|
|
27
|
+
|
|
28
|
+
Existing started v1 conversations keep their exact original scope and archive identity. The upgrade
|
|
29
|
+
never expands them to every account or converts them to a cross-system selection. A saved unstarted
|
|
30
|
+
draft requires confirmation; a started conversation whose scope cannot be restored stays blocked.
|
|
31
|
+
The same-runtime offline recovery rules continue to use the complete original group.
|
|
32
|
+
|
|
33
|
+
Custom hosts keep `setSessionScope`, `getSessionScope`, `restoreSessionScope`,
|
|
34
|
+
`getSessionArchiveStatus` and `syncSessionArchive`. Custom stores must preserve complete scope/outbox
|
|
35
|
+
v2 records, original bindings, events, acknowledgement positions and CAS revisions. Hosts may show
|
|
36
|
+
current `subjectDisplay` fields and omit a manual display-name input, but keep internal connection
|
|
37
|
+
selectors/keys separate; do not rebuild authorization or archive state to update a name. Missing
|
|
38
|
+
names stay explicit. Administrator-maintained system descriptions are separate from subject names
|
|
39
|
+
and do not grant tools or permissions.
|
|
40
|
+
|
|
41
|
+
### 0.4 用户升级摘要
|
|
42
|
+
|
|
43
|
+
管理员先备份并升级 Core 0.7.0,按顺序仅执行未完成迁移(从 0.6.1 升级包括 058/059)。用户先
|
|
44
|
+
结束当前业务任务,用 `/bailinghub sync` 重试待同步结尾,安装 `dsh-bailinghub@0.5.0` 并重启。
|
|
45
|
+
插件自动安装 SDK 0.5.0。保留原凭据、真实 Session 事件及范围/待传文件;有效授权不因升级或改名重建。
|
|
46
|
+
|
|
47
|
+
已有同系统会话范围保持不变。要把商城与库存一起使用,分别授权,另开会话,在首消息前选中固定
|
|
48
|
+
连接键并等确认。先验证库存查询与一个低风险商城动作,核对各自结果、原审批和执行关联。
|
|
49
|
+
自定义宿主保留原五个接口;自定义存储需完整保存 v2 的原绑定、事件、确认进度与修订号。名称
|
|
50
|
+
只用于展示,不能替代连接键、身份或系统说明。详情见[本次更新](RELEASE_NOTES_v0.5.0.md#简体中文)。
|
|
51
|
+
|
|
52
|
+
### Downgrading from 0.5 to 0.4
|
|
53
|
+
|
|
54
|
+
Finish active work and synchronize pending completions and archives first. Keep the original profile
|
|
55
|
+
and v2 files as recovery material. Version 0.4.0 does not understand cross-system v2 scope/outbox or
|
|
56
|
+
provide this release's system/subject metadata. Do not reinterpret v2 as v1, delete it, or reconstruct
|
|
57
|
+
it from the current registry. Use a separate profile with new same-system conversations if reverting.
|
|
58
|
+
An application downgrade does not undo an accepted business action or remove its Hub audit. Core
|
|
59
|
+
database rollback follows Core's own migration guide; never drop new columns as a plugin rollback.
|
|
60
|
+
|
|
61
|
+
## Historical 0.3.0 → 0.4.0 behavior
|
|
62
|
+
|
|
63
|
+
The section below documents the scope change introduced in 0.4.0. When upgrading directly to 0.5.0,
|
|
64
|
+
follow the current install/Core versions above and also preserve these explicit-scope requirements.
|
|
65
|
+
|
|
66
|
+
### From 0.3.0: choose the conversation scope explicitly
|
|
67
|
+
|
|
68
|
+
Version 0.4.0 keeps the four public configuration fields and existing SDK-owned authorizations.
|
|
69
|
+
It changes how a conversation gets business access: logging in or selecting a default no longer
|
|
70
|
+
automatically enables it. A new conversation is ordinary chat until you select its scope.
|
|
71
|
+
|
|
72
|
+
1. Ask the administrator to upgrade the Hub to Core 0.6.1. The plugin installs exact SDK 0.4.0.
|
|
73
|
+
2. Before restarting, finish active business work and retry known pending run completions with
|
|
74
|
+
`/bailinghub sync`. Do not assume a process restart resumes an invocation or approval.
|
|
75
|
+
3. Upgrade the plugin and restart DSH:
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
dsh plugin --profile web add dsh-bailinghub@0.4.0
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
4. Run `/bailinghub doctor` and `/bailinghub connections list`. Existing valid authorizations can
|
|
82
|
+
be selected; you do not need to authorize them again merely because the plugin was upgraded.
|
|
83
|
+
5. Start a new conversation. Before its first message, run
|
|
84
|
+
`/bailinghub scope set <connection-key> [<another-connection-key> ...]`, using fixed keys from
|
|
85
|
+
the list, then `/bailinghub scope`. Wait for successful confirmation. Select only this task's
|
|
86
|
+
accounts; several accounts must share one Hub/Client App/workspace.
|
|
87
|
+
6. Try a read, then a reversible permitted update. Check the actual result and original business
|
|
88
|
+
calls in BailingHub. Use `/bailinghub archive status` to inspect the separate visible record.
|
|
89
|
+
|
|
90
|
+
Keep old started conversations as history: if they have no valid locked scope snapshot, they
|
|
91
|
+
cannot automatically adopt today's selected connection. A stored draft that never started needs
|
|
92
|
+
explicit selection again. Existing 0.4 saved business conversations can reopen with their original
|
|
93
|
+
scope after every member is revalidated. An offline reopen can retry in the same conversation
|
|
94
|
+
with `/bailinghub scope` or `/bailinghub archive sync` once connectivity returns.
|
|
95
|
+
|
|
96
|
+
The new archive uploads visible user/assistant text, turn boundaries, and original run links for
|
|
97
|
+
the full frozen member set. Local pending events survive restart and upload without replaying
|
|
98
|
+
business work. It does not backfill all pre-upgrade history or restore unfinished invocations.
|
|
99
|
+
A detectable gap stays `recovery_gap`; missing host history is unverified. Review [Privacy](../PRIVACY.md):
|
|
100
|
+
the local outbox retains plaintext visible text, including acknowledged events, until removed by
|
|
101
|
+
the host/operator. There is no automatic retention cleanup.
|
|
102
|
+
|
|
103
|
+
### 0.3 用户升级摘要
|
|
104
|
+
|
|
105
|
+
先由管理员升级 Core 0.6.1;结束当前业务任务并用 `/bailinghub sync` 收口待同步结尾记录,再安装
|
|
106
|
+
`dsh-bailinghub@0.4.0` 并重启 DSH。已有有效授权可继续使用,不必仅因插件升级重新授权。
|
|
107
|
+
执行 `/bailinghub connections list` 后,**新建会话,在首条消息前**用
|
|
108
|
+
`/bailinghub scope set <连接键> [<另一连接键> ...]` 选择账号,并等待 `/bailinghub scope`
|
|
109
|
+
确认。未选范围就只是普通聊天;旧版已开始会话没有范围快照时不能直接恢复业务访问。
|
|
110
|
+
|
|
111
|
+
上传状态用 `/bailinghub archive status` 查看,联网后用 `/bailinghub archive sync` 补传。
|
|
112
|
+
这会恢复原范围并上传已保存文本,不会恢复重启前的业务调用或待审批操作,也不代表全部旧历史已
|
|
113
|
+
归档。更多步骤见[中文上手指南](GETTING_STARTED.zh-CN.md)与[隐私说明](../PRIVACY.md)。
|
|
114
|
+
|
|
115
|
+
## Downgrading from 0.4 to 0.3
|
|
116
|
+
|
|
117
|
+
Finish current business work and synchronize pending completions and archives before an explicit
|
|
118
|
+
downgrade. Keep the old profile and its scope/outbox files intact. Version 0.3.0 does not provide
|
|
119
|
+
0.4's explicit scope gate, multi-authorization conversation, or archive retries; its new conversations
|
|
120
|
+
use its selected default connection. Use a separate profile and new conversation if reverting.
|
|
121
|
+
Do not delete credential or archive files as a downgrade shortcut. A downgrade does not cancel an
|
|
122
|
+
accepted business action or delete its Hub audit.
|
|
123
|
+
|
|
124
|
+
## Legacy 0.1.x to the native Agent Client
|
|
125
|
+
|
|
126
|
+
There is no automatic credential, configuration, tool, or orchestration migration from the legacy
|
|
127
|
+
static MCP path. The following boundary remains separate from the 0.3 to 0.4 upgrade above.
|
|
5
128
|
|
|
6
129
|
## What remains unchanged
|
|
7
130
|
|
|
@@ -47,9 +170,9 @@ switch account, and select a tenant.
|
|
|
47
170
|
|
|
48
171
|
## Safe evaluation before migration
|
|
49
172
|
|
|
50
|
-
Do not replace a working production profile merely to evaluate 0.
|
|
51
|
-
another isolated Web profile and verify that the CLI really honors that location.
|
|
52
|
-
`0.3.0` creates a separate credential for each name registered through
|
|
173
|
+
Do not replace a working production profile merely to evaluate 0.5.0. Use a separate DSH home or
|
|
174
|
+
another isolated Web profile and verify that the CLI really honors that location. The named
|
|
175
|
+
connection lifecycle introduced in `0.3.0` creates a separate credential for each name registered through
|
|
53
176
|
`connections add` while authorization is pending. After authorization, the SDK replaces an older
|
|
54
177
|
same-binding connection when its trusted `on_behalf_of` is the same; different trusted identities
|
|
55
178
|
remain independent. A different identity returned from a same-alias login keeps the original
|
|
@@ -57,30 +180,31 @@ alias and Session and receives a non-conflicting alias that becomes current. Use
|
|
|
57
180
|
SDK installed by the DSH package when evaluating that behavior.
|
|
58
181
|
|
|
59
182
|
1. Keep the existing `0.1.1` profile and its legacy environment unchanged.
|
|
60
|
-
2. Install the exact released 0.
|
|
183
|
+
2. Install the exact released 0.5.0 package into an isolated profile.
|
|
61
184
|
3. Configure only the four public native fields using neutral values for dry composition.
|
|
62
185
|
4. Run `/bailinghub login` and approve a dedicated non-production client app/workspace whose
|
|
63
186
|
credential can be revoked without affecting a maintainer's existing profile.
|
|
64
|
-
5. Verify status
|
|
65
|
-
trajectory.
|
|
187
|
+
5. Verify status and workspace discovery. In a new conversation explicitly select its scope, then
|
|
188
|
+
verify one read, one permitted mutation, approval/resume, and the Hub trajectory.
|
|
66
189
|
6. Separately re-run the `0.1.1` submit and same-job follow-up against the newly released Core.
|
|
67
190
|
|
|
68
191
|
Passing the native path does not prove legacy compatibility, and passing the legacy path does not
|
|
69
192
|
prove the native Agent Client.
|
|
70
193
|
|
|
71
|
-
## Moving a profile to 0.
|
|
194
|
+
## Moving a legacy 0.1 profile to 0.5
|
|
72
195
|
|
|
73
196
|
Only after the isolated acceptance passes:
|
|
74
197
|
|
|
75
198
|
1. Record the exact old plugin, DSH, MCP, and Core versions without copying credentials into the
|
|
76
199
|
migration record.
|
|
77
200
|
2. Finish or cancel outstanding legacy jobs. A wait timeout is not a terminal failure.
|
|
78
|
-
3. Install the exact accepted 0.
|
|
201
|
+
3. Install the exact accepted 0.5.0 plugin version. Do not use an unpinned dist-tag.
|
|
79
202
|
4. Replace the legacy plugin configuration with the four native fields. Remove the old Client
|
|
80
203
|
Token from that process environment after confirming no remaining 0.1 integration uses it.
|
|
81
204
|
5. Start DSH, run `/bailinghub login`, use the business page to log in or switch account and select
|
|
82
205
|
a tenant if required, then authorize the intended workspace.
|
|
83
|
-
6. Run `/bailinghub status`, open a new conversation,
|
|
206
|
+
6. Run `/bailinghub status`, open a new conversation, explicitly select its scope before the first
|
|
207
|
+
message, and repeat the accepted read/mutation checks.
|
|
84
208
|
7. Confirm BailingHub receives visible conversation and invocation audit without hidden reasoning.
|
|
85
209
|
|
|
86
210
|
The developer or deployer supplies the Hub URL, public client app id, and initial workspace/route.
|
|
@@ -111,7 +235,7 @@ reuse, move, or republish an npm version or Git tag as a rollback mechanism.
|
|
|
111
235
|
|
|
112
236
|
## Release gates
|
|
113
237
|
|
|
114
|
-
Before
|
|
238
|
+
Before a public 0.5 release:
|
|
115
239
|
|
|
116
240
|
1. The matching BailingHub Core Agent Auth/Agent API contracts are released.
|
|
117
241
|
2. The exact `bailinghub-mcp-server/sdk` version is publicly installable and has passed DTO,
|
|
@@ -119,10 +243,11 @@ Before any public 0.3 release:
|
|
|
119
243
|
3. Installing only `dsh-bailinghub` into a clean DSH `0.1.1-rc.2` profile installs and resolves that
|
|
120
244
|
exact SDK dependency automatically.
|
|
121
245
|
4. Browser login, session isolation, dynamic tool replacement, approval recovery, visible
|
|
122
|
-
completion, same-identity replacement, different-identity isolation,
|
|
123
|
-
from the packaged artifact.
|
|
246
|
+
completion, same-identity replacement, different-identity isolation, explicit one/many-account
|
|
247
|
+
scope, visible archive, offline reopen/retry, and Hub trajectory pass from the packaged artifact.
|
|
248
|
+
Revocation must block the complete original selection, and archive retries must not replay business work.
|
|
124
249
|
5. Public `0.1.1` still works against the new Core through the unchanged Client API.
|
|
125
250
|
6. The maintainer explicitly selects the public version and migration story.
|
|
126
251
|
|
|
127
|
-
Do not tag or publish a future
|
|
252
|
+
Do not tag or publish a future version until all gates pass, and do not describe release
|
|
128
253
|
validation as public adoption.
|
|
@@ -23,8 +23,12 @@ community integration, not an official DeepSeek plugin or partnership.
|
|
|
23
23
|
|
|
24
24
|
## Public native line (0.2.0 onward)
|
|
25
25
|
|
|
26
|
-
Version 0.2.0 introduced this dependency path
|
|
27
|
-
|
|
26
|
+
Version 0.2.0 introduced this dependency path; 0.3.0 added the named connection lifecycle.
|
|
27
|
+
Version 0.4.0 added explicit same-system conversation scope and visible conversation archiving.
|
|
28
|
+
Version 0.5.0 extends selection across systems on one Hub and audit domain, and adds controlled
|
|
29
|
+
system descriptions and business subject display names. These names do not establish identity or
|
|
30
|
+
product mappings, and cross-system selection does not provide durable task orchestration or rollback.
|
|
31
|
+
All remain separate from the public static MCP path:
|
|
28
32
|
|
|
29
33
|
```text
|
|
30
34
|
DeepSeek Harness local Agent
|