diff --git a/docs/comparison/qwen-code-improvement-report-p1-command-namespace.md b/docs/comparison/qwen-code-improvement-report-p1-command-namespace.md
new file mode 100644
index 00000000..d7cfaf54
--- /dev/null
+++ b/docs/comparison/qwen-code-improvement-report-p1-command-namespace.md
@@ -0,0 +1,107 @@
+# Qwen Code 改进建议 — P1 命令命名空间治理
+
+> 命令系统改进项：当 built-in commands、文件命令、extension commands、MCP prompt commands 同时存在时，除了“能加载”，还需要解决命名冲突、来源隔离、前缀策略与治理边界。
+>
+> 返回 [改进建议总览](./qwen-code-improvement-report.md)
+
+---
+
+<a id="item-1"></a>
+
+### 1. Slash Command Namespace Governance / 命令命名空间治理（P1）
+
+**思路**：Qwen Code 的 slash command 系统已经进入“平台化”阶段，而不再只是几十个内置命令。当前至少有四类来源会往命令空间里注入名字：
+
+1. built-in commands
+2. user / project 文件命令
+3. extension commands
+4. MCP prompt commands
+
+当来源越来越多时，真正的挑战不再是“怎么加载命令”，而是：
+
+- 谁可以占用顶级命令名？
+- 重名时谁覆盖谁？
+- extension 是否必须带命名空间前缀？
+- MCP prompt 暴露成 slash command 时，是否应默认隔离到 server namespace？
+- 用户如何知道某个命令来自 built-in、extension 还是 MCP？
+- 团队/企业如何禁用某些来源或保留关键命令名？
+
+Claude Code 在这方面采取的是更保守的合并策略：命令合并时倾向于保持稳定、可预测的名字集合；插件命令则走独立管理路径。Qwen Code 当前虽然有基础冲突处理，但规则仍偏“实现导向”，还没有发展成完整的 namespace governance。
+
+**Claude Code 源码索引**：
+
+| 文件 | 关键函数/常量 |
+|------|-------------|
+| `hooks/useMergedCommands.ts` | `uniqBy([...initialCommands, ...mcpCommands], 'name')`，保持命令名唯一 |
+| `services/plugins/pluginCliCommands.ts` | 插件命令走独立 CLI 管理入口（install/uninstall/enable/disable/update） |
+| `commands.ts` | 命令总表与内置命令体系 |
+
+**Qwen Code 现状**：`packages/cli/src/services/CommandService.ts` 会并行加载所有 loader 返回的命令，然后统一放入一个 `Map<string, SlashCommand>`。当前冲突规则是：
+
+- 如果是 extension command 且名字冲突，则自动改名为 `extensionName.commandName`，必要时再追加数字后缀；
+- 非 extension commands（built-in / user / project / MCP prompt）则按 loader 顺序“后者覆盖前者”；
+- `packages/cli/src/services/McpPromptLoader.ts` 会把 MCP prompt 直接暴露为 slash command 名，不默认带 server namespace。
+
+这套策略“能工作”，但存在几个隐患：
+
+1. **顶级命令名竞争**：MCP prompt 与 user/project 命令都可能占用短名字；
+2. **来源不透明**：用户看到 `/deploy`，并不知道它来自 project file command、某个 MCP server prompt，还是 extension；
+3. **覆盖策略不够显式**：非 extension 冲突靠 loader 顺序决定，行为可预测但不够易理解；
+4. **治理能力不足**：缺少 reserved names、per-source enable/disable、source visibility 等平台机制。
+
+**Qwen Code 修改方向**：
+1. 为 slash command 引入显式 `source namespace` 概念，例如：
+   - built-in: `/model`
+   - extension: `/ext.foo.bar`
+   - MCP prompt: `/mcp.github.review`
+   - file command: `/local.deploy`
+2. 对用户常用命令保留短别名，但短别名应由治理层决定，而不是“谁最后加载谁赢”；
+3. 在补全列表与帮助界面中显示命令来源（built-in / extension / MCP / local）；
+4. 增加 reserved name 策略，防止扩展或 MCP prompt 抢占关键命令；
+5. 增加 per-source enable/disable 配置，方便团队/企业限制命令暴露面；
+6. 对 MCP prompt 默认使用 `serverName.promptName` 命名，避免直接污染顶级命令空间。
+
+**实现成本评估**：
+- 涉及文件：~4 个
+- 新增代码：~220 行
+- 开发周期：~3 天（1 人）
+- 难点：兼容现有短命令习惯，避免破坏已有用户工作流
+
+**改进前后对比**：
+- **改进前**：所有来源往同一个命令表注册——extension 有改名兜底，但 user/project/MCP prompt 之间仍可能靠加载顺序决定覆盖关系
+- **改进后**：每类命令先进入各自 namespace，再由治理层决定哪些短别名暴露到顶级空间——冲突规则清晰、来源可见、企业可控
+
+**意义**：命令系统一旦可扩展，就必须治理命名空间。
+**缺失后果**：命令来源越多，顶级命令空间越混乱——冲突、覆盖、误调用会越来越频繁。
+**改进收益**：命令来源透明 + 冲突策略清晰 + 保留字治理，让 slash command 系统从“加载器集合”升级为“可管理的平台能力”。
+
+---
+
+## 为什么这不是现有 slash command / MCP 文档的重复
+
+- 现有 slash command 对比更多回答“有哪些命令”；
+- MCP 集成对比更多回答“能否接入 MCP”；
+- 本文讨论的是：**当命令来源变多后，命令名如何治理、如何隔离、如何防冲突**。
+
+也就是说，它关注的是 **命令平台治理**，不是命令功能列表。
+
+---
+
+## 可分阶段演进路径
+
+| 阶段 | 能力 | 说明 |
+|------|------|------|
+| Stage 1 | source 可视化 | 补全列表/帮助页展示命令来源 |
+| Stage 2 | MCP / extension 默认命名空间 | 避免顶级命令空间污染 |
+| Stage 3 | reserved names + alias policy | 保留关键短命令，统一别名分配 |
+| Stage 4 | team policy | 团队/企业按来源禁用命令或限定前缀 |
+
+这样 Qwen Code 的命令系统才能在继续开放扩展的同时保持可预测性。
+
+---
+
+## 相关文章
+
+- [内置命令总览](./slash-commands-deep-dive.md)
+- [MCP 集成深度对比](./mcp-integration-deep-dive.md)
+- [Qwen Code 改进建议总览](./qwen-code-improvement-report.md)
diff --git a/docs/comparison/qwen-code-improvement-report-p1-hooks-runtime.md b/docs/comparison/qwen-code-improvement-report-p1-hooks-runtime.md
new file mode 100644
index 00000000..9817c7c8
--- /dev/null
+++ b/docs/comparison/qwen-code-improvement-report-p1-hooks-runtime.md
@@ -0,0 +1,78 @@
+# Qwen Code 改进建议 — P1 Hook Runtime 扩展
+
+> Hook 运行时改进项：从 shell command-only 扩展到多后端执行模型，支持 Prompt Hook、异步 Hook 编排与更强的语义策略能力。
+>
+> 返回 [改进建议总览](./qwen-code-improvement-report.md)
+
+---
+
+<a id="item-1"></a>
+
+### 1. Prompt Hooks / LLM 语义 Hook（P1）
+
+**思路**：当前 Qwen Code 的 Hook 已有较完整的事件总线（`PreToolUse`、`PostToolUse`、`Notification`、`SessionStart` 等），但执行器本质上仍只有 `type: "command"`——所有 Hook 都必须落到 shell 命令。这样虽然足够通用，却不适合“语义判断”类场景：例如“这次 `git push` 是否违反团队发布策略？”、“本次工具调用是否与当前任务目标冲突？”、“这段用户输入是否包含敏感数据，应该先二次确认？”。
+
+Claude Code 在 shell / HTTP 之外，还支持 **Prompt Hook**：把 Hook prompt 连同当前上下文交给一个小模型执行，要求模型返回严格 JSON（`{ok:true}` 或 `{ok:false, reason:"..."}`）。这使 Hook 从“脚本式规则”扩展为“语义策略判断器”。适合 shell/regex 难以表达的治理场景。
+
+**Claude Code 源码索引**：
+
+| 文件 | 关键函数/常量 |
+|------|-------------|
+| `utils/hooks/execPromptHook.ts` | `execPromptHook()`，调用小模型执行 Hook prompt，强制 `json_schema` 输出 |
+| `types/hooks.ts` | Hook 类型体系、sync/async JSON 响应协议、Prompt/Callback Hook 类型定义 |
+| `utils/hooks/AsyncHookRegistry.ts` | 异步 Hook 注册、进度轮询、stdout JSON 响应解析 |
+
+**Qwen Code 现状**：Hook 类型仍是单一 `command`。`packages/core/src/hooks/types.ts` 中 `HookType` 仅有 `Command`，`HookConfig = CommandHookConfig`；`packages/core/src/hooks/hookRunner.ts` 也只实现 `executeCommandHook()`。这意味着即使事件体系很丰富，运行时仍局限于 shell 脚本 + stdin/stdout JSON。
+
+**Qwen Code 修改方向**：
+1. `packages/core/src/hooks/types.ts` 扩展 `HookType`：在 `command` 之外新增 `prompt`（后续也可继续扩展 `http`、`callback`）；
+2. 新建 `packages/core/src/hooks/execPromptHook.ts`：复用现有模型调用栈，采用小模型执行 Hook prompt；
+3. 要求 Prompt Hook 输出严格 JSON Schema，避免自由文本导致的不确定性；
+4. 在 `hookRunner.ts` 增加分发逻辑：`type === 'prompt'` 时走 LLM Hook 分支；
+5. 在 `hooksCommand.ts` / Hook UI 中展示 Hook 类型、模型、超时与阻断原因。
+
+**实现成本评估**：
+- 涉及文件：~5 个
+- 新增代码：~250 行
+- 开发周期：~3 天（1 人）
+- 难点：Hook prompt 的安全边界与超时控制
+
+**改进前后对比**：
+- **改进前**：Hook 只能执行 shell 命令——复杂语义检查需要开发者自己写脚本、调用外部模型、再拼 JSON 返回
+- **改进后**：`type: "prompt"` 直接把语义判断下沉到 Hook Runtime——可用小模型做轻量审批、策略校验、提示增强
+
+**意义**：很多治理策略本质是语义问题，而不是字符串匹配问题。
+**缺失后果**：复杂 Hook 只能壳套壳——shell 调脚本，脚本再调模型，配置脆弱且调试困难。
+**改进收益**：Prompt Hook 让 Hook 成为一等语义策略层——更适合审批、安全、规范、上下文增强。
+
+---
+
+## 为什么这不是现有“HTTP Hooks / Conditional Hooks”的重复
+
+- **Conditional Hooks** 解决的是“哪些 Hook 应该触发”；
+- **HTTP Hooks** 解决的是“Hook 是否可以直接请求远程服务”；
+- **Prompt Hooks / Hook Runtime 扩展** 解决的是“Hook Runtime 本身是否支持多执行后端，尤其是 LLM 语义执行”。
+
+三者分别对应 **触发条件**、**传输通道**、**执行模型**，不是同一个层次的问题。
+
+---
+
+## 进一步演进方向
+
+如果后续继续向 Claude Code 靠拢，Qwen Code 的 Hook Runtime 可以按下面路径递进演化：
+
+| 阶段 | 能力 | 说明 |
+|------|------|------|
+| Stage 1 | `command` + `prompt` | 本地脚本与 LLM 语义判断双后端 |
+| Stage 2 | 统一 async registry | 所有 Hook 类型共享异步调度、超时、进度与结果回传 |
+| Stage 3 | typed hook backends | `http` / `callback` / `remote-policy` 等可插拔执行器 |
+| Stage 4 | explainability | 展示“哪个 Hook 阻断了继续执行、原因是什么、来自哪层策略” |
+
+这样 Hook 系统才能从“事件很多的 shell 执行器”升级为“可扩展的策略运行时”。
+
+---
+
+## 相关文章
+
+- [Hook/插件扩展深度对比](./hook-plugin-extension-deep-dive.md)
+- [Qwen Code 改进建议总览](./qwen-code-improvement-report.md)
diff --git a/docs/comparison/qwen-code-improvement-report-p1-permission-explainability.md b/docs/comparison/qwen-code-improvement-report-p1-permission-explainability.md
new file mode 100644
index 00000000..8f0288c3
--- /dev/null
+++ b/docs/comparison/qwen-code-improvement-report-p1-permission-explainability.md
@@ -0,0 +1,94 @@
+# Qwen Code 改进建议 — P1 权限决策可解释性
+
+> 权限系统改进项：不仅要“做出 allow / ask / deny 决策”，还要向用户解释“为什么会这样判定、命中了哪条规则、下一步如何调整”。
+>
+> 返回 [改进建议总览](./qwen-code-improvement-report.md)
+
+---
+
+<a id="item-1"></a>
+
+### 1. Permission Decision Trace / 权限决策解释链（P1）
+
+**思路**：Qwen Code 这两版在权限引擎层面其实已经不弱：支持 `allow / ask / deny` 三类规则、session/persistent 两级规则、shell compound command 拆分、shell virtual operations 推导（把 `cat` / `curl` / redirect 等映射为 `read_file` / `web_fetch` / `write_file`），还会用 AST 判断 shell 命令是否只读。这意味着它已经能“算出一个合理决策”。
+
+问题在于，**用户几乎看不到这条决策链**。
+
+当一个工具调用被拒绝或要求确认时，用户真正想知道的是：
+
+- 是哪一条规则命中了？
+- 是 shell 规则命中，还是 virtual file/web 规则命中？
+- 是 `deny` 规则覆盖了 `allow`，还是没有任何规则命中而回退到默认模式？
+- 如果我想放行，应该改 `/permissions` 里的哪条规则？
+- 如果是 Hook 导致 ask/block，具体是哪一个 Hook？
+
+Claude Code 在这方面明显更成熟：不仅有权限判定，还有一整套 **decision reason → UI explanation → debug info** 链路。它把“结果”与“原因”一起展示，让权限系统从黑盒变成可调试、可学习的交互系统。
+
+**Claude Code 源码索引**：
+
+| 文件 | 关键函数/常量 |
+|------|-------------|
+| `components/permissions/PermissionDecisionDebugInfo.tsx` | 展示 decision reason、rule/hook/mode/classifier/sandboxOverride/workingDir 等来源 |
+| `components/permissions/PermissionRuleExplanation.tsx` | 把 `decisionReason` 转成用户可读解释，并给出 `/permissions` / `/hooks` 调整提示 |
+| `components/permissions/PermissionExplanation.tsx` | 懒加载权限解释，展示 risk level / explanation / reasoning |
+| `hooks/toolPermission/PermissionContext.ts` | 权限上下文状态 |
+| `hooks/toolPermission/permissionLogging.ts` | 权限日志记录 |
+| `tools/BashTool/commandSemantics.ts` | shell 语义分类辅助解释 |
+
+**Qwen Code 现状**：权限判定逻辑很强，但可解释性弱。`packages/core/src/permissions/permission-manager.ts` 负责规则优先级计算（`deny > ask > allow > default`），还会结合 `extractShellOperations()` 做 shell virtual operation 判定；但返回结果主要是最终 decision，没有面向 UI 的“命中链路对象”。`packages/cli/src/ui/components/PermissionsDialog.tsx` 更像规则管理器：列出 allow/ask/deny 规则、支持搜索/增删，却不展示“某次具体决策为何发生”。用户能改规则，却不容易理解当前规则系统到底是怎么工作的。
+
+**Qwen Code 修改方向**：
+1. 在 `permission-manager.ts` 中新增 explain 模式：除了最终 decision，还返回 `decisionTrace`，至少包括：
+   - 命中的规则（类型、来源、原始 rule 文本）
+   - 是否发生 deny/ask 覆盖
+   - 是否来自 shell virtual operations
+   - 是否走了默认回退
+2. 在 shell 场景下，把 `extractShellOperations()` 的推导结果挂入 trace，让用户知道“`cat foo` 为何等价于 `read_file(foo)`”；
+3. 在工具确认 UI 中增加“Why?”/“Explain”视图，展示命中链和建议操作；
+4. 在 `/permissions` 界面中增加“最近一次命中示例”或 dry-run tester，方便用户调试规则；
+5. 后续可与 Hook Runtime 联动：若是 Hook 导致 ask/block，也统一走同一套 decision trace UI。
+
+**实现成本评估**：
+- 涉及文件：~5 个
+- 新增代码：~250 行
+- 开发周期：~3 天（1 人）
+- 难点：在不破坏现有权限 API 的前提下为 UI 暴露结构化 trace
+
+**改进前后对比**：
+- **改进前**：用户只看到“被拒绝 / 需要确认”——但不知道是哪条规则、哪个层级、哪种语义命中导致的
+- **改进后**：用户可看到完整 decision trace——例如“命中 project deny 规则 `WriteFile(/secrets/**)`，同时 shell 语义推导出 `echo > secrets.txt` 属于写文件操作，因此最终为 deny”
+
+**意义**：权限系统越强，越需要 explainability。否则规则一多，用户只能靠试错。
+**缺失后果**：权限引擎是黑盒——用户难以调试规则，常见结果是要么过度放权，要么频繁误拦截。
+**改进收益**：decision trace 让权限系统可学习、可调试、可审计——特别适合复杂 shell、团队策略和企业治理场景。
+
+---
+
+## 为什么这不是现有“Denial Tracking / 权限对话框文件预览”的重复
+
+- **Denial Tracking** 解决的是“连续拒绝后如何自动回退模式”；
+- **权限对话框文件预览** 解决的是“审批时展示将要修改的文件内容”；
+- **Permission Decision Trace** 解决的是“这次 allow / ask / deny 到底是怎么推导出来的”。
+
+三者分别是 **回退策略**、**审批信息展示**、**决策可解释性**，层次不同。
+
+---
+
+## 可分阶段落地的演进路径
+
+| 阶段 | 能力 | 说明 |
+|------|------|------|
+| Stage 1 | 基础 decision trace | 命中 rule、source、default fallback、virtual ops |
+| Stage 2 | 确认 UI explain 面板 | 在工具确认框中展示“为什么 ask/deny” |
+| Stage 3 | `/permissions test` dry-run | 给一条工具调用/命令，输出命中链与最终结果 |
+| Stage 4 | 审计与导出 | 记录最近 N 次权限判定链，便于排障与企业审计 |
+
+这样 Qwen Code 的权限系统才能从“规则引擎”进一步升级为“可调试的权限平台”。
+
+---
+
+## 相关文章
+
+- [Hook Runtime 扩展](./qwen-code-improvement-report-p1-hooks-runtime.md)
+- [Hook/插件扩展深度对比](./hook-plugin-extension-deep-dive.md)
+- [Qwen Code 改进建议总览](./qwen-code-improvement-report.md)
diff --git a/docs/comparison/qwen-code-improvement-report-p1-resume-discovery.md b/docs/comparison/qwen-code-improvement-report-p1-resume-discovery.md
new file mode 100644
index 00000000..449f8c7b
--- /dev/null
+++ b/docs/comparison/qwen-code-improvement-report-p1-resume-discovery.md
@@ -0,0 +1,102 @@
+# Qwen Code 改进建议 — P1 会话恢复发现与导航
+
+> 会话恢复改进项：不仅要“能 resume”，还要在多目录、多 worktree、长历史会话中更容易找到并恢复正确的 session。
+>
+> 返回 [改进建议总览](./qwen-code-improvement-report.md)
+
+---
+
+<a id="item-1"></a>
+
+### 1. Worktree-aware Resume + Agentic Session Search（P1）
+
+**思路**：现有“会话恢复”讨论通常聚焦在崩溃后如何继续执行、如何重建 transcript、如何恢复上下文状态。但从日常使用体验看，用户在 `/resume` 前真正遇到的第一个问题往往不是“能不能恢复”，而是：
+
+- 我到底该恢复哪一个 session？
+- 这个 session 是不是在另一个 worktree 里启动的？
+- 如果它来自同一仓库的另一个 worktree，能不能直接恢复？
+- 如果它来自完全不同的目录，能不能给我正确的恢复命令？
+- 当我只记得“之前聊过某个 bug / 某个 API 设计”，能不能靠语义而不是时间顺序把它找出来？
+
+Claude Code 在这一层明显更完整：它不仅有 resume 命令，还实现了 **跨项目 / worktree 感知的恢复导航**，以及 **基于 session 元数据与 transcript 的 agentic semantic search**。这使 `/resume` 从“打开一个历史列表”变成“帮用户重新回到正确工作上下文”的恢复工作流。
+
+**Claude Code 源码索引**：
+
+| 文件 | 关键函数/常量 |
+|------|-------------|
+| `utils/crossProjectResume.ts` | `checkCrossProjectResume()`：区分同目录、同 repo worktree、不同项目三类恢复场景 |
+| `utils/agenticSessionSearch.ts` | `agenticSessionSearch()`：综合 title/tag/branch/summary/transcript 做语义检索 |
+| `commands/resume/resume.tsx` | `/resume` 交互入口 |
+
+从 `crossProjectResume.ts` 可以直接看到 Claude Code 会区分三种结果：
+- `isCrossProject: false`：当前目录直接恢复；
+- `isSameRepoWorktree: true`：同一仓库 worktree，可直接恢复；
+- 不同项目：生成 `cd <projectPath> && claude --resume <sessionId>` 的正确命令。
+
+而 `agenticSessionSearch.ts` 则不是简单的字符串过滤：它会综合 `title`、`tag`、`branch`、`summary`、`first message`、`transcript` 等字段，优先用字面命中做预筛，再把候选交给小模型做更宽松的语义召回与排序。
+
+**Qwen Code 现状**：Qwen Code 已有基础 session 恢复能力，但更偏“列表式浏览”。
+
+- `packages/cli/src/ui/commands/resumeCommand.ts`：`/resume` 只是打开 dialog；
+- `packages/cli/src/ui/components/SessionPicker.tsx`：主要展示 `prompt + 相对时间 + messageCount + gitBranch`，支持上下移动与按 branch 过滤；
+- `packages/core/src/services/sessionService.ts`：支持分页列出本项目会话、按 mtime 排序、加载完整会话数据；
+- 但当前没有看到：
+  - 跨目录 / worktree 恢复导航；
+  - 不同项目时生成正确恢复命令；
+  - 基于 transcript 的语义搜索；
+  - “我只记得聊过什么，不记得时间和标题”这种使用场景下的高召回检索。
+
+换句话说，Qwen Code 现在更像“session list picker”，而不是“resume discovery system”。
+
+**Qwen Code 修改方向**：
+1. 在 session metadata 中显式保留项目路径 / worktree 信息；
+2. `/resume` 入口增加 cross-project/worktree 判断：
+   - 当前目录：直接恢复；
+   - 同 repo worktree：直接恢复或提示 worktree 路径；
+   - 不同项目：给出可复制的 `cd ... && qwen --resume ...` 命令；
+3. 在 `SessionPicker` 上层增加搜索模式，不只按时间排序和 branch 过滤；
+4. 引入 agentic session search：在 title/branch/summary 命中的基础上，再把 transcript 摘要交给小模型做相关性排序；
+5. 将“恢复导航”与“崩溃恢复”分层：前者解决“找得到正确 session”，后者解决“恢复后能否无缝续跑”。
+
+**实现成本评估**：
+- 涉及文件：~6 个
+- 新增代码：~320 行
+- 开发周期：~4 天（1 人）
+- 难点：session 元数据扩展与语义搜索结果排序
+
+**改进前后对比**：
+- **改进前**：`/resume` 主要是按时间顺序列历史会话——跨目录场景需要用户自己判断，想找老会话主要靠滚动和记忆
+- **改进后**：`/resume auth bug` 可直接按语义找回相关 session；若 session 属于同仓库其他 worktree，则直接提示正确恢复路径；若来自不同项目，则生成可执行恢复命令
+
+**意义**：长周期、多分支、多 worktree 工作流下，找对 session 和恢复 session 同样重要。
+**缺失后果**：历史会话越多，`/resume` 越像时间排序日志——用户知道“以前聊过”，却很难高效回到那次上下文。
+**改进收益**：恢复导航 worktree-aware + 语义搜索，让 session 从“日志文件”升级成“可检索、可回到的工作资产”。
+
+---
+
+## 为什么这不是现有“会话崩溃恢复”条目的重复
+
+- **会话崩溃恢复与中断检测** 关注的是：session 异常中断后如何重建状态并继续执行；
+- **Worktree-aware Resume + Agentic Search** 关注的是：用户如何在大量历史 session 中找到正确会话，并在跨目录 / worktree 场景下恢复到正确位置。
+
+前者是 **恢复执行引擎**，后者是 **恢复发现与导航层**，问题层次不同。
+
+---
+
+## 可分阶段演进路径
+
+| 阶段 | 能力 | 说明 |
+|------|------|------|
+| Stage 1 | 路径感知 resume | 区分当前目录 / 同 repo worktree / 不同项目 |
+| Stage 2 | resume command suggestion | 对跨项目 session 自动生成恢复命令 |
+| Stage 3 | metadata search | title/branch/summary 搜索 |
+| Stage 4 | agentic transcript search | transcript 摘要 + 小模型语义召回 |
+
+这样 Qwen Code 的 session 恢复才能从“按时间翻列表”升级为“按上下文找回工作”。
+
+---
+
+## 相关文章
+
+- [Git 工作流与会话管理](./git-workflow-session-deep-dive.md)
+- [Qwen Code 改进建议总览](./qwen-code-improvement-report.md)
diff --git a/docs/comparison/qwen-code-improvement-report.md b/docs/comparison/qwen-code-improvement-report.md
index 8a02f542..cfddc7bb 100644
--- a/docs/comparison/qwen-code-improvement-report.md
+++ b/docs/comparison/qwen-code-improvement-report.md
@@ -53,6 +53,10 @@
 | **P1** | GitHub Actions CI — 自动 PR 审查/issue 分类 action [↓](./qwen-code-improvement-report-p0-p1-platform.md#item-1) | 缺失 | 中 | — |
 | **P1** | GitHub Code Review — 多 Agent自动 PR review + inline 评论 [↓](./qwen-code-improvement-report-p0-p1-platform.md#item-2) | 缺失 | 大 | — |
 | **P1** | HTTP Hooks — Hook 可 POST JSON 到 URL 并接收响应（不仅 shell 命令）[↓](./qwen-code-improvement-report-p0-p1-platform.md#item-3) | 仅 shell 命令 | 小 | — |
+| **P1** | Prompt Hooks / LLM 语义 Hook — Hook 直接调用小模型做结构化策略判断（不仅 shell/HTTP）[↓](./qwen-code-improvement-report-p1-hooks-runtime.md#item-1) | 仅 command hook | 中 | — |
+| **P1** | Permission Decision Trace — 展示命中规则、shell 语义推导与默认回退原因 [↓](./qwen-code-improvement-report-p1-permission-explainability.md#item-1) | 仅最终 decision | 中 | — |
+| **P1** | Slash Command Namespace Governance — 内置/扩展/MCP/file commands 的命名空间、保留字与冲突治理 [↓](./qwen-code-improvement-report-p1-command-namespace.md#item-1) | 基础冲突处理 | 中 | — |
+| **P1** | Worktree-aware Resume + Agentic Session Search — 跨目录/worktree 恢复导航与会话语义搜索 [↓](./qwen-code-improvement-report-p1-resume-discovery.md#item-1) | 列表式 resume | 中 | — |
 | **P1** | Ghost Text 输入补全 — 输入时显示命令/路径建议灰字，Tab 接受 [↓](./qwen-code-improvement-report-p0-p1-platform.md#item-10) | 缺失 | 中 | — |
 | **P1** | Structured Output — `--json-schema` 强制 JSON Schema 验证输出 [↓](./qwen-code-improvement-report-p0-p1-platform.md#item-4) | 缺失 | 小 | — |
 | **P1** | Agent SDK 增强 — Python SDK + 流式回调 + 工具审批回调（Qwen 仅 TS SDK）[↓](./qwen-code-improvement-report-p0-p1-platform.md#item-5) | 仅 TypeScript SDK | 中 | — |
@@ -229,6 +233,10 @@
 |------|------|:----:|
 | [P0/P1 核心能力](./qwen-code-improvement-report-p0-p1-core.md) | 上下文压缩、Subagent、Speculation、记忆系统、工具并行、启动优化等 | 13 |
 | [P0/P1 平台集成](./qwen-code-improvement-report-p0-p1-platform.md) | GitHub Actions CI、Code Review、SDK、Remote Control Bridge、GitLab 等 | 10 |
+| [P1 Hook Runtime 扩展](./qwen-code-improvement-report-p1-hooks-runtime.md) | Prompt Hook、LLM 语义策略、Hook Runtime 多后端扩展 | 1 |
+| [P1 权限决策可解释性](./qwen-code-improvement-report-p1-permission-explainability.md) | Permission Decision Trace、规则命中解释、shell 语义决策链 | 1 |
+| [P1 命令命名空间治理](./qwen-code-improvement-report-p1-command-namespace.md) | Slash Command Namespace、冲突处理、来源可视化与保留字治理 | 1 |
+| [P1 会话恢复发现与导航](./qwen-code-improvement-report-p1-resume-discovery.md) | Worktree-aware Resume、跨目录恢复导航、会话语义搜索 | 1 |
 | [P0/P1 引擎优化](./qwen-code-improvement-report-p0-p1-engine.md) | 流式执行、缓存、Token 管理、崩溃恢复、Agent 编排、上下文管理、安全等 | 24 |
 | [P2 核心功能与企业特性](./qwen-code-improvement-report-p2-core.md) | 中等优先级（Shell 安全、MDM 企业策略、Token 计数、Computer Use 等） | 24 |
 | [P2 工具与命令扩展](./qwen-code-improvement-report-p2-tools.md) | 中等优先级（MCP 动态插槽、Ripgrep 回退、Notebook Edit、LSP 等） | 29 |
@@ -258,6 +266,10 @@
 | 文件索引 | FileIndex（fzf 风格） | 依赖 rg/glob | 中等差距 | — |
 | Commit Attribution | Co-Authored-By 追踪 | 无 | 缺失 | — |
 | 会话分支 | /branch 对话分叉 | 无 | 缺失 | — |
+| Hook Runtime | Prompt Hook + async hook registry + 多后端执行模型 | command-only hook | 中等差距 | — |
+| 权限决策可解释性 | decision reason + rule/hook/mode/shell 语义解释链 | 仅最终 decision | 中等差距 | — |
+| 命令命名空间治理 | built-in/extension/MCP/file command 的 namespace 与保留字策略 | 基础冲突处理 | 中等差距 | — |
+| 会话恢复发现与导航 | worktree-aware resume + session 语义搜索 | 列表式 resume | 中等差距 | — |
 | Output Styles | Learning / Explanatory 模式 | 无 | 缺失 | — |
 | Fast Mode | 速度/成本分级推理 | 无 | 缺失 | — |
 | 并发 Session | 多终端 PID 追踪 + 后台脱附 | 无 | 缺失 | — |