diff --git a/变更.md b/变更.md
index df91aff..8076a06 100644
--- a/变更.md
+++ b/变更.md
@@ -1,7 +1,7 @@
 # CHANGES — 本 fork 的改动
 
 给接手这个 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，改标签或移卡后跑外部同步脚本
 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、
 deployment 相关、docs 测试的 path.sep 枚举、NTFS 语义等）。本 fork 的门禁口径 = **零回归**：
 失败集合必须始终 ⊆ 基线，即 `pnpm typecheck` 全绿且失败集合不新增条目。新增测试文件：
 `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 部署实战要点（运维备忘）