Docs: record the tool-allowlist and Session-restore fixes in CHANGES
This commit is contained in:
@@ -1,7 +1,7 @@
|
|||||||
# CHANGES — 本 fork 的改动
|
# CHANGES — 本 fork 的改动
|
||||||
|
|
||||||
给接手这个 fork 的人。上游是 deepseek-ai/dsh-superagent-prototype(DeepSeek 团队的研究原型),
|
给接手这个 fork 的人。上游是 deepseek-ai/dsh-superagent-prototype(DeepSeek 团队的研究原型),
|
||||||
基线 = `6337fc8`(pristine);其上是本 fork 的 11 个提交(`4379973` → `cf40686`)。
|
基线 = `6337fc8`(pristine);其上是本 fork 的 23 个提交(`4379973` → `4d00454`,含文档与插件栈整理)。
|
||||||
|
|
||||||
## 总述
|
## 总述
|
||||||
|
|
||||||
@@ -121,13 +121,44 @@ prompt 装配读的是 Session Controller 的内存 selection。改为优先调
|
|||||||
Uncategorized,已改名);该 Gitea 版本没有 Projects API,改标签或移卡后跑外部同步脚本
|
Uncategorized,已改名);该 Gitea 版本没有 Projects API,改标签或移卡后跑外部同步脚本
|
||||||
card-sync.mjs,只碰这个看板、不直接操作数据库。
|
card-sync.mjs,只碰这个看板、不直接操作数据库。
|
||||||
|
|
||||||
|
### `4bb3cc2` + `bd5ff35` Sessions: expose plugin tools to managed Sessions
|
||||||
|
|
||||||
|
动机:插件在 profile 里装了、面板也能用,但 worker 会话看不到——`Sessions` 的
|
||||||
|
`tools.restrict({ allow })` 是硬编码白名单,未列出的工具被隐藏,看起来像"插件没生效 / 和
|
||||||
|
super-agent 自带工具互斥"。改了哪里:`src/app/sessions.ts` 增加 `CONTEXT_TOOLS`
|
||||||
|
(`compress` / `decompress` / `search_context` / `acp_status` / `acp_cache`,
|
||||||
|
billion-context 用)与 `workbuddy_web_search`,master / worker 的白名单都带上;每一项经
|
||||||
|
`agent.ctx.tools.get(name, parent)` 过滤存在性,没装该插件时静默无效果。`bd5ff35` 同时在
|
||||||
|
`execution-environment.ts` 注入 `DSH_SUPERAGENT_WEB_SEARCH` 说明,提示调研任务优先用
|
||||||
|
WorkBuddy 原生搜索(不依赖 DeepSeek key)、失败回退 `web_search`。第一版直接内联工具名导致
|
||||||
|
`restrict` 对不存在的名字抛错、runtime.spec 91 例全挂——加存在性过滤后回到基线。
|
||||||
|
|
||||||
|
### `4d00454` Sessions: restore managed Sessions resumed before the creation listener was installed
|
||||||
|
|
||||||
|
动机:真机出现「用户打断并重启会话后,worker 报 `Error: unknown tool "orchestrator_ack"`,
|
||||||
|
不能和调度器通信」。逐轮解码 `session.v4.jsonl.zstd` 取证:重启前 system=40329、含
|
||||||
|
`dsh-superagent` 策略节、orchestrator 工具 6 个;重启后 system=6647、策略节消失、
|
||||||
|
orchestrator 工具 0 个、技能目录里 `dsh-superagent-github` 也没了——会话退回 DSH 默认
|
||||||
|
preset。根因是启动时序竞态:`Runtime.initialize()` 先跑耗时的 `Setup.run()`,之后才
|
||||||
|
`Sessions.install()` 订阅 `agent/created`;Web / pocket 面板在旧进程 shutdown 到新进程订阅
|
||||||
|
之间把 worker 会话 resume 了,而上游 `announce()` 对每个 entry 只发一次 `agent/created`,
|
||||||
|
早到的那次无人接收,之后不会再补发。改了哪里:`src/app/sessions.ts` 新增幂等的
|
||||||
|
`restore()`——按 `masterId` + 全部工单的 `workerSessionId(ticket.id)` 逐个
|
||||||
|
`ctx.agents.get(id)` 找回已 live 的 Session 并重新 `decorate()`(错误隔离、warn 不拦启动);
|
||||||
|
`src/app/runtime.ts` 在 `install()` 之后、`ensure(masterId)` 之前 `await sessions.restore()`
|
||||||
|
(此时 setup 已完成,`decorate` 里读 `setup.deployment` 才安全)。`tests/runtime.spec.ts`
|
||||||
|
新增回归用例:用 `restart()` 保留同一 live agents 模拟「resume 早于订阅」,断言策略节与
|
||||||
|
`orchestrator_report` 被重新注册、Session 没有被 recreate。
|
||||||
|
|
||||||
## 测试基线
|
## 测试基线
|
||||||
|
|
||||||
上游原型在 Windows 本机跑 `pnpm test` 有约 38 个固有失败(tmux、lark-cli、POSIX shims、
|
上游原型在 Windows 本机跑 `pnpm test` 有约 38 个固有失败(tmux、lark-cli、POSIX shims、
|
||||||
deployment 相关、docs 测试的 path.sep 枚举、NTFS 语义等)。本 fork 的门禁口径 = **零回归**:
|
deployment 相关、docs 测试的 path.sep 枚举、NTFS 语义等)。本 fork 的门禁口径 = **零回归**:
|
||||||
失败集合必须始终 ⊆ 基线,即 `pnpm typecheck` 全绿且失败集合不新增条目。新增测试文件:
|
失败集合必须始终 ⊆ 基线,即 `pnpm typecheck` 全绿且失败集合不新增条目。新增测试文件:
|
||||||
`tests/gitea.spec.ts`(21 例)、`tests/role-models.spec.ts`(14 例)、
|
`tests/gitea.spec.ts`(21 例)、`tests/role-models.spec.ts`(14 例)、
|
||||||
`tests/default-model.spec.ts`(14 例)、`tests/reclaim.spec.ts`(5 例)。
|
`tests/default-model.spec.ts`(14 例)、`tests/reclaim.spec.ts`(5 例)、
|
||||||
|
`tests/runtime.spec.ts` 新增的会话恢复回归用例(1 例)。全量门禁当前为
|
||||||
|
`33 failed / 1220 passed`(8 个失败文件全为 Windows 固有基线子集)。
|
||||||
|
|
||||||
## Gitea 部署实战要点(运维备忘)
|
## Gitea 部署实战要点(运维备忘)
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user