```

feat(engine): 优化智能体循环中的助手消息处理逻辑

- 在没有工具调用时才添加助手消息到上下文
- 确保工具调用响应正确添加到消息上下文中
- 修复了消息构建的条件逻辑

fix(cron): 改进定时任务调度的时间解析功能

- 添加正则表达式导入用于时间显示解析
- 实现从显示文本中提取毫秒间隔的功能
- 增强整数转换的安全性，避免类型错误
- 优化定时任务配置的解析逻辑

feat(outlook): 增强Outlook集成的功能和稳定性

- 将默认超时时间从10秒增加到180秒
- 为状态检查函数添加可选的验证参数
- 串行执行邮件概览获取操作而非并行
- 改进连接状态验证逻辑

feat(channel): 添加设备名称作为会话标识的选项

- 为终端WebSocket适配器添加新的配置选项
- 实现基于设备名称生成会话对等ID的功能
- 记录原始对等ID和设备名称的元数据
- 支持从设备名称创建会话对等ID

feat(skills): 完善技能学习评估系统和进度跟踪

- 在应用启动时自动调度待评估的技能草稿
- 为技能评估工作创建独立的循环工厂
- 实现异步技能评估任务的取消和清理机制
- 添加技能评估进度报告和状态跟踪功能
- 扩展会话列表API以包含更多详细信息
- 防止对不存在的会话进行操作
- 优化技能草稿提交和评估的业务逻辑

perf(skills): 提升技能评估的并发性能

- 实现并行技能案例评估以提高效率
- 添加最大并行案例数的环境变量控制
- 实现实时评估进度更新和回调机制
- 优化评估过程中的资源管理和同步

refactor(services): 创建隔离的智能体循环实例

- 添加创建独立智能体循环的工厂方法
- 确保新循环继承运行时服务配置
- 支持技能评估等需要隔离环境的场景
```

docs/presentations/beaver-management-demo/beaver-management-demo.md

@@ -0,0 +1,435 @@
+# Beaver 管理层演示方案
+
+对象：公司管理层  
+时长：60 分钟  
+目标：让老板看懂 Beaver 是什么、现在已经能做什么、可以用在公司哪些地方，以及为什么值得继续投入。
+
+## 一句话定位
+
+Beaver 不是一个聊天机器人，而是一个企业内部 Agent 工作台：它能执行任务、使用文件和工具、保留过程证据、等待人工验收，并把成功的工作方式沉淀成可复用的企业技能。
+
+## 演示主线
+
+不要按页面逐个介绍，而是讲一个业务故事：
+
+> 假设这是公司里普通的一天：老板需要经营晨报，产品团队需要从客户反馈里判断优先级，项目团队需要提前识别风险，团队还要准备管理层汇报、沉淀可复用方法，并让周期性工作自动运行。Beaver 就是承载这些 Agent 工作的地方。
+
+## 60 分钟流程
+
+| 时间 | 环节 | 目的 |
+| --- | --- | --- |
+| 0-5 分钟 | 开场 | 定义 Beaver 是 Agent 工作系统，不是聊天产品 |
+| 5-12 分钟 | 场景 1：老板晨报 | 展示多信息源汇总和管理层摘要 |
+| 12-20 分钟 | 场景 2：客户反馈到产品决策 | 展示从杂乱反馈中提炼业务判断 |
+| 20-28 分钟 | 场景 3：项目风险与行动计划 | 展示风险识别和管理层决策支持 |
+| 28-38 分钟 | 场景 4：复杂任务与可追踪执行 | 展示聊天转任务、过程、修订和验收 |
+| 38-48 分钟 | 场景 5：企业技能复用 | 展示 Beaver 的长期复利价值 |
+| 48-55 分钟 | 场景 6：定时任务与治理 | 展示主动执行、状态、日志和控制能力 |
+| 55-60 分钟 | 收尾讨论 | 讨论 Beaver 下一步适合在哪些内部场景试点 |
+
+## 需要提前上传的文件
+
+文件目录：
+
+```text
+docs/presentations/beaver-management-demo/upload-files/
+```
+
+建议上传顺序：
+
+1. `sales-weekly.csv`
+2. `project-risks.md`
+3. `customer-feedback-q2.md`
+4. `meeting-notes.md`
+5. `project-status.md`
+6. `support-tickets.csv`
+7. `weekly-ops-metrics.csv`
+
+## 开场话术
+
+可以这样开场：
+
+> 今天不把 Beaver 当成聊天机器人演示。我们把它当成一个企业内部 Agent 工作台来看：员工可以把真实工作交给 Beaver，Beaver 可以使用文件和工具，生成可交付结果，留下执行过程，等待人来验收或要求修改。如果这个工作以后会重复，Beaver 还可以把被认可的方法沉淀成可复用技能。
+
+然后补充业务背景：
+
+- 聊天工具能回答问题，但企业工作需要可交付结果。
+- 管理层需要过程证据，而不是只有一段看起来流畅的文字。
+- 企业落地 AI 需要私有部署、边界、权限和运维控制。
+- 重复发生的工作应该沉淀成组织能力，而不是每个人反复写提示词。
+
+## 场景 1：老板晨报
+
+### 业务问题
+
+老板每天不想手动看销售表、项目记录、客户反馈和会议纪要，只想快速知道今天最重要的经营判断和需要拍板的事项。
+
+### 演示目标
+
+展示 Beaver 可以把分散的内部信息整理成管理层能直接看的经营晨报，并标注信息来源。
+
+### 使用文件
+
+- `sales-weekly.csv`
+- `project-risks.md`
+- `customer-feedback-q2.md`
+- `meeting-notes.md`
+- `weekly-ops-metrics.csv`
+
+### 提示词
+
+```text
+请基于我上传的文件，生成一份给 CEO 的今日经营晨报。
+
+要求：
+1. 用管理层语言，不要技术细节
+2. 分为：关键结论、风险预警、需要老板决策的事项、建议行动
+3. 每个关键结论都标注来自哪个文件
+4. 最后给出今天最重要的 3 件事
+5. 控制在 800 字以内
+```
+
+### 演示步骤
+
+1. 打开 Beaver 聊天工作台。
+2. 到 `Files` 页面快速展示已经上传的文件。
+3. 回到聊天页，发送提示词。
+4. 打开生成的任务或任务详情页。
+5. 展示结果、时间线，以及文件/工具相关证据。
+6. 现场要求修改：
+
+```text
+把这份晨报改成更适合 10 分钟管理层晨会使用的版本，只保留最关键的判断和行动。
+```
+
+7. 展示修订结果，并点击接受。
+
+### 讲解话术
+
+> 这里重点不是 Beaver 写了一份摘要，而是这件事已经变成了一项可追踪任务：有原始材料、有执行过程、有结果、有修订、有人工验收。这比一个普通聊天回答更接近真实工作。
+
+### 老板视角价值
+
+- 减少阅读分散信息的时间。
+- 把多个信息源整理成决策导向的简报。
+- 过程和来源可查看，方便追问和复核。
+
+### 翻车预案
+
+如果现场生成较慢，就先展示上传文件和预期输出结构，然后打开提前跑好的任务或聊天历史。
+
+## 场景 2：客户反馈到产品决策
+
+### 业务问题
+
+客户反馈通常很杂：销售记录、客服工单、访谈纪要里都有不同声音。管理层真正关心的是哪些问题影响收入、续约和试点成功，哪些可以后排。
+
+### 演示目标
+
+展示 Beaver 能从非结构化反馈中提炼主题、判断优先级，并形成产品投入建议。
+
+### 使用文件
+
+- `customer-feedback-q2.md`
+- `support-tickets.csv`
+
+### 提示词
+
+```text
+请分析这些客户反馈和支持工单，输出一份产品决策建议。
+
+要求：
+1. 聚类出 5 类主要问题
+2. 判断每类问题的业务影响
+3. 给出优先级：P0 / P1 / P2
+4. 区分“必须马上做”和“可以进入路线图”
+5. 给老板一个 90 天产品投入建议
+6. 最后列出还需要进一步验证的假设
+```
+
+### 演示步骤
+
+1. 打开 `Files`，展示 `customer-feedback-q2.md` 和 `support-tickets.csv`。
+2. 回到聊天页发起分析任务。
+3. 展示输出结构：主题聚类、优先级、业务影响、90 天建议。
+4. 要求 Beaver 改写成一页管理层备忘录：
+
+```text
+请把这个结果改成一页管理层备忘录，重点突出投入产出比和不做的风险。
+```
+
+### 讲解话术
+
+> 这个场景说明 Beaver 对管理层的价值不只是写文案，而是把大量不规整的信息转成可以讨论和决策的材料。
+
+### 老板视角价值
+
+- 更快从客户噪声里抓住信号。
+- 让产品优先级讨论更有依据。
+- 把产品投入和业务影响连接起来。
+
+### 翻车预案
+
+如果输出太长，就直接追问：
+
+```text
+请压缩成老板只需要看 5 分钟的一页摘要。
+```
+
+## 场景 3：项目风险与行动计划
+
+### 业务问题
+
+项目延期通常不是突然发生的，早期信号可能已经出现在会议纪要、状态周报、风险记录里，例如验收标准不清、依赖延期、资源不足、审批阻塞。
+
+### 演示目标
+
+展示 Beaver 可以作为 PMO 助手，提前识别项目风险，并给出管理层应该介入的事项。
+
+### 使用文件
+
+- `project-status.md`
+- `project-risks.md`
+- `meeting-notes.md`
+
+### 提示词
+
+```text
+你现在是项目管理办公室 PMO。
+请基于这些项目材料，判断哪些风险可能导致延期。
+
+输出：
+1. 风险清单
+2. 每个风险的影响、概率、责任人建议
+3. 本周必须推进的行动项
+4. 哪些事项需要管理层介入
+5. 一份可以发给项目负责人的跟进邮件
+```
+
+### 演示步骤
+
+1. 在聊天页发送 PMO 提示词。
+2. 展示 Beaver 生成的风险矩阵和行动项。
+3. 打开任务详情页，说明过程证据。
+4. 追问一个管理层问题：
+
+```text
+如果老板今天只能拍板 2 件事，应该是哪 2 件？请说明原因和不拍板的后果。
+```
+
+### 讲解话术
+
+> Beaver 适合处理这种需要判断、需要留下结果、还需要人来审核的工作。这里它把项目材料转成了风险清单、决策清单和跟进邮件。
+
+### 老板视角价值
+
+- 更早发现项目风险。
+- 明确责任人和行动项。
+- 提高向上升级问题的质量。
+
+### 翻车预案
+
+如果 Beaver 漏掉某个风险，不要回避，可以把它变成修订演示：
+
+```text
+你漏掉了“验收标准变化”这个风险，请重新评估它的影响，并更新行动计划。
+```
+
+## 场景 4：复杂任务与可追踪执行
+
+### 业务问题
+
+真实企业工作不是一个问题一个答案，而是需要拆解、分析、起草、审核和修改。
+
+### 演示目标
+
+展示 Beaver 和普通聊天工具的核心区别：复杂请求可以变成可管理的任务，而不是一次性聊天回复。
+
+### 使用文件
+
+这个场景可以复用前面文件，也可以不依赖文件。
+
+### 提示词
+
+```text
+请帮我为 Beaver 准备一份给公司老板看的项目汇报框架。
+
+目标是说明：
+1. Beaver 是什么
+2. 现在已经能做什么
+3. 可以用在哪些企业场景
+4. 为什么值得继续投入
+5. 下一阶段建议做什么
+
+请先拆解任务，再生成最终汇报大纲。少讲技术，多讲业务价值、风险控制和投入产出。
+```
+
+### 演示步骤
+
+1. 在聊天页发送提示词。
+2. 展示 Beaver 如何从对话进入任务执行。
+3. 打开任务详情页。
+4. 展示时间线、中间步骤、最终结果和验收控件。
+5. 要求修改：
+
+```text
+把这个汇报框架改得更像董事会材料：每一部分都要回答“为什么重要、现在有什么进展、下一步要什么资源”。
+```
+
+6. 展示修订后的结果，并点击接受。
+
+### 讲解话术
+
+> Beaver 的核心产品想法是让 AI 工作可检查。对管理层来说，重要的是能看到问了什么、做出了什么、怎么修改过、什么时候被人接受。
+
+### 老板视角价值
+
+- 把模糊需求转成结构化工作。
+- 支持带上下文的连续修订。
+- 让 AI 工作具备内部使用所需的可审查性。
+
+### 翻车预案
+
+如果任务模式没有明显触发，就继续在聊天里演示，然后打开 `Tasks` 页面展示历史任务记录。
+
+## 场景 5：企业技能复用
+
+### 业务问题
+
+企业里很多好方法会反复使用：周报、风险复盘、客户反馈分析、项目更新、事故总结。普通 AI 聊天每次都要重新教，经验无法自然沉淀。
+
+### 演示目标
+
+展示 Beaver 可以把成功工作保留下来，形成可复用技能，从而产生长期组织能力。
+
+### 使用文件
+
+复用前面场景的输出即可，不需要新增上传文件。
+
+### 演示步骤
+
+1. 打开 `Skills` 页面。
+2. 展示已发布技能，例如文件操作、搜索、Outlook、定时任务、终端、技能编写等。
+3. 解释技能生命周期：
+   - 已接受任务
+   - 技能候选
+   - 草稿生成
+   - 安全检查和 replay 评测
+   - 人工审核
+   - 发布
+   - 后续任务复用
+4. 如果页面展示评测覆盖率或报告，顺手点出来。
+5. 回到聊天页，发起一个类似任务：
+
+```text
+请按刚才的管理层汇报风格，再生成一版项目周报。保留同样的结构：关键结论、风险、需要老板决策的事项、下一步行动。
+```
+
+### 讲解话术
+
+> 这是 Beaver 的复利价值。第一次运行得到一个结果；一次被接受的成功工作，可以变成可复用的方法。时间久了，公司积累的是自己的 Agent 能力库，而不是每个人自己的提示词经验。
+
+### 老板视角价值
+
+- 减少重复说明。
+- 沉淀公司自己的工作方法。
+- 在广泛复用前保留审核和治理环节。
+
+### 翻车预案
+
+如果现场完整技能生成流程不够稳，不要强行演示。展示 `Skills` 页面和生命周期即可，把它作为可治理能力说明。
+
+## 场景 6：定时任务与治理
+
+### 业务问题
+
+很多管理动作应该周期性发生，而不是靠人每天想起来：日报、周报、风险检查、客户反馈汇总、项目提醒。
+
+### 演示目标
+
+展示 Beaver 可以从被动聊天变成主动运营，并且管理员可以看到状态和日志。
+
+### 使用文件
+
+- `sales-weekly.csv`
+- `project-risks.md`
+- `customer-feedback-q2.md`
+- `weekly-ops-metrics.csv`
+
+### 演示步骤
+
+1. 打开 `Cron` 页面。
+2. 新建或展示一个定时任务：
+
+```text
+每天上午 9 点生成经营晨报，汇总销售、项目风险、客户反馈和运营指标。
+```
+
+3. 展示启停、运行记录，或手动触发一次。
+4. 如果已有结果，打开 `Notifications` 展示定时运行产物。
+5. 打开 `Status` 和 `Logs`。
+6. 说明管理员可以查看 provider 配置、运行状态、连接器状态和失败记录。
+
+### 讲解话术
+
+> 这一步说明 Beaver 可以从助手变成运营系统：周期性 Agent 工作可以被配置、监控和审核。
+
+### 老板视角价值
+
+- 让重复工作主动发生。
+- 管理员能看到运行状态。
+- 有失败记录和配置入口，企业落地更可控。
+
+### 翻车预案
+
+如果现场没有可用的定时运行结果，就只演示创建配置，并说明生成结果会进入任务或通知。
+
+## 收尾话术
+
+可以这样收尾：
+
+> Beaver 当前最适合先在三类内部场景试点。第一，管理层信息汇总，比如晨报、周报和项目汇报。第二，围绕客户、产品、运营、项目的重复分析工作。第三，需要证据、审核和人工验收的 AI 任务。它的战略价值不是替代某个人，而是把 AI 从临时问答变成可控制、可复用、可治理的工作系统。
+
+## 推荐试点场景
+
+先选 2-3 个窄场景，不要一开始铺太大。
+
+| 试点工作流 | 为什么适合 Beaver | 成功信号 |
+| --- | --- | --- |
+| CEO 或部门周报 | 多文件输入，需要简洁管理层输出 | 一轮以内修订后可接受 |
+| 客户反馈分析 | 输入混乱，但输出能支持决策 | 产品负责人把结果用于优先级会议 |
+| 项目风险评审 | 需要证据和管理层行动 | 风险在升级会议前被识别 |
+| 每周支持工单总结 | 高频重复，适合技能复用 | 同一技能连续复用 3 周 |
+| 内部事故复盘 | 需要时间线、证据和后续行动 | 审核人能从 Beaver 输出理解事件经过 |
+
+## 演示前检查清单
+
+演示前：
+
+- 确认 Beaver 实例能登录。
+- 确认 provider/model 配置可用。
+- 上传 `upload-files/` 里的所有文件。
+- 提前跑一遍场景 1，并保留结果。
+- 提前跑一遍场景 4，并保留任务详情页。
+- 提前打开这些页面：Chat、Files、Tasks、Skills、Cron、Status、Logs。
+- 准备一份提示词备份，本 Markdown 可以直接作为备份。
+
+演示中：
+
+- 不要解释每一个页面。
+- 反复回到同一个主线：任务、证据、验收、复用、治理。
+- 如果现场生成慢，切到提前跑好的历史任务。
+- 如果输出不完美，就用它演示修订和人工验收。
+
+## 可放进 PPT 的一页总结
+
+```text
+Beaver = 企业 Agent 工作台
+
+1. 执行真实工作，不只是聊天
+2. 使用文件、工具、任务和连接器
+3. 保留过程证据，方便审核
+4. 通过人工验收保证可信输出
+5. 把成功工作沉淀成可复用技能
+6. 支持私有部署和运维治理
+```

docs/presentations/beaver-management-demo/upload-files/README.md

@@ -0,0 +1,24 @@
+# Beaver 管理层演示上传文件
+
+这些文件是 Beaver 管理层演示用的样例业务输入。
+
+演示前建议全部上传到 Beaver：
+
+1. `sales-weekly.csv`
+2. `project-risks.md`
+3. `customer-feedback-q2.md`
+4. `meeting-notes.md`
+5. `project-status.md`
+6. `support-tickets.csv`
+7. `weekly-ops-metrics.csv`
+
+建议场景映射：
+
+| 场景 | 文件 |
+| --- | --- |
+| 老板晨报 | `sales-weekly.csv`, `project-risks.md`, `customer-feedback-q2.md`, `meeting-notes.md`, `weekly-ops-metrics.csv` |
+| 客户反馈分析 | `customer-feedback-q2.md`, `support-tickets.csv` |
+| 项目风险评审 | `project-status.md`, `project-risks.md`, `meeting-notes.md` |
+| 定时经营汇总 | `sales-weekly.csv`, `project-risks.md`, `customer-feedback-q2.md`, `weekly-ops-metrics.csv` |
+
+文件内容是虚构数据，但按照真实管理层演示场景设计，方便现场上传和测试。

docs/presentations/beaver-management-demo/upload-files/customer-feedback-q2.md

@@ -0,0 +1,37 @@
+# Q2 Customer Feedback
+
+Source: sales calls, support notes, product interviews, and pilot discussions
+Period: 2026 Q2
+
+## Feedback Items
+
+1. "The AI answer is useful, but I do not know what source material it used."
+2. "Our compliance team needs to see a trace of tool calls and file access before approving a pilot."
+3. "The demo is strong when it turns a request into a task. Please make that the first thing users see."
+4. "We want daily and weekly reports to run automatically, not only when someone asks in chat."
+5. "The Outlook connector would be valuable if it can summarize customer emails and draft replies."
+6. "We do not want every employee pasting company data into public SaaS tools."
+7. "The Files page is useful, but users need clearer examples of what to upload."
+8. "The task detail page helps reviewers understand what happened."
+9. "The Skills concept is important. It means our team's best working methods can be reused."
+10. "Skill publishing should require human approval. We do not want low-quality automations spreading."
+11. "The interface has many pages. New users need a guided first workflow."
+12. "Management will ask how this is different from ChatGPT Team or Copilot."
+13. "The strongest value is repeatable knowledge work: weekly reports, customer feedback summaries, project risk reviews."
+14. "We need a clear admin story: status, logs, provider configuration, connector health."
+15. "Some users asked whether Beaver can run terminal commands. Security wants policy controls around that."
+16. "The first pilot should avoid too many external integrations."
+17. "We need to measure accepted tasks, revision rounds, and time saved."
+18. "The model sometimes gives too much detail. Executive summaries should be shorter."
+19. "Private deployment and per-user instance boundaries are important for enterprise buyers."
+20. "The demo should show a failed or revised answer, because review is part of real work."
+
+## Raw Themes Observed
+
+- Trust and auditability
+- Task lifecycle beyond chat
+- Reusable skills and method capture
+- Scheduled recurring work
+- Private deployment and admin control
+- Connector demand, especially email
+- Need for simpler onboarding and clearer demo story

docs/presentations/beaver-management-demo/upload-files/meeting-notes.md

@@ -0,0 +1,39 @@
+# Management Prep Meeting Notes
+
+Date: 2026-06-11
+Participants: Product, Engineering, Operations, Sales
+
+## Purpose
+
+Prepare a leadership demo that explains what Beaver is, what progress has been made, and what use cases are realistic for the company.
+
+## Discussion
+
+Product team recommended avoiding a page-by-page product tour. Leadership should see how Beaver supports real business work: summarize information, create a task, show evidence, revise output, accept result, and reuse the method.
+
+Engineering confirmed that the current system can show login, files, chat workspace, task records, task detail, skills, cron, status, and logs. The most stable story is the core loop: chat-to-task, evidence, revision, acceptance, and skill reuse explanation.
+
+Operations noted that management will care about governance. The demo should mention private deployment, instance boundaries, model provider configuration, connector configuration, status, and logs. The team should avoid overpromising fully autonomous actions.
+
+Sales said the clearest executive scenarios are:
+
+- CEO morning brief
+- Customer feedback analysis
+- Project risk review
+- Weekly support summary
+- AI task governance and evidence
+
+## Decisions
+
+1. Use a 60-minute demo format.
+2. Target company leadership, not external customers.
+3. Start with business outcomes, then show product capabilities.
+4. Use realistic but fictional sample files.
+5. Keep Outlook and external connector demo optional.
+6. Prepare backup outputs in case live model generation is slow.
+
+## Open Questions
+
+1. Which internal workflow should become the first pilot?
+2. What metric should be used to evaluate Beaver: time saved, accepted tasks, quality, or risk reduction?
+3. Should the next milestone focus on polish, connector hardening, or skill lifecycle?

docs/presentations/beaver-management-demo/upload-files/project-risks.md

@@ -0,0 +1,57 @@
+# Project Risk Notes
+
+Date: 2026-06-12
+Owner: PMO
+
+## Executive Summary
+
+The Beaver internal demo project is on track for a management review next week, but several risks require attention. The core product loop is demoable: login, files, chat-to-task, task detail, evidence, revision, acceptance, skills, cron, status, and logs. The main risks are demo stability, connector maturity, and clarity of business story.
+
+## Risks
+
+### R1: Demo scope is too broad
+
+- Impact: High
+- Probability: Medium
+- Signal: The product has many pages: chat, files, tasks, skills, marketplace, agents, MCP, cron, connectors, status, logs.
+- Concern: If the demo becomes a feature tour, leadership may not understand the main business value.
+- Suggested response: Use one storyline and only show pages that support it.
+
+### R2: Connector demo may be unstable
+
+- Impact: Medium
+- Probability: Medium
+- Signal: Outlook and external connector paths exist, but live external dependency can fail.
+- Concern: A connector failure could distract from the core Agent workspace story.
+- Suggested response: Treat connectors as optional. Demo configuration and explain target workflow if live connector is not stable.
+
+### R3: Skill learning flow may be too long for live presentation
+
+- Impact: Medium
+- Probability: High
+- Signal: Skill candidate, draft, safety, replay evaluation, review, and publish are powerful but require time.
+- Concern: Waiting for background learning may break the demo rhythm.
+- Suggested response: Show Skills page, explain lifecycle, and use pre-created examples.
+
+### R4: Leadership may ask for ROI
+
+- Impact: High
+- Probability: High
+- Signal: Management audience cares about adoption, risk, and next investment.
+- Concern: Technical progress alone will not answer "why continue?"
+- Suggested response: Position first pilots around repeated knowledge work, measurable accepted tasks, revision rounds, and time saved.
+
+### R5: Model output quality can vary
+
+- Impact: Medium
+- Probability: Medium
+- Signal: Live model generation may be verbose, miss details, or produce uneven structure.
+- Concern: Output quality variance may look like product instability.
+- Suggested response: Use revision as part of the story: Beaver supports feedback, continuation, and acceptance.
+
+## Management Decisions Needed
+
+1. Confirm the first 2-3 internal pilot workflows.
+2. Decide whether the next milestone optimizes for demo polish or pilot readiness.
+3. Pick one connector to harden first, preferably the one with the clearest business value.
+4. Define what evidence is required before a task can be considered accepted.

docs/presentations/beaver-management-demo/upload-files/project-status.md

@@ -0,0 +1,77 @@
+# Project Status: Beaver Leadership Demo
+
+Date: 2026-06-12
+Project owner: Product and Engineering
+Target review: Next week
+
+## Overall Status
+
+Status: Yellow
+
+The core Beaver demonstration is feasible, but the team needs to tighten the story and prepare backup paths. The product has enough implemented surfaces to explain the Agent workspace concept: files, chat, tasks, evidence, acceptance, skills, cron, status, and logs.
+
+## Workstreams
+
+### 1. Product Story
+
+- Status: Yellow
+- Owner: Product
+- Progress: Drafted 6 management scenarios.
+- Risk: If the story is too technical, leadership may see Beaver as another chatbot or internal tool experiment.
+- Next action: Rehearse the opening and closing talk tracks.
+
+### 2. Demo Environment
+
+- Status: Yellow
+- Owner: Engineering
+- Progress: Local instance is available. Provider configuration is being checked.
+- Risk: Live model response can be slow or verbose.
+- Next action: Run the main scenarios once and keep completed tasks available.
+
+### 3. Sample Data
+
+- Status: Green
+- Owner: Product
+- Progress: Sales, customer feedback, project risk, support, and operations files prepared.
+- Risk: Sample data must look realistic without exposing actual company data.
+- Next action: Upload all files to Beaver before the demo.
+
+### 4. Skills Story
+
+- Status: Yellow
+- Owner: Engineering
+- Progress: Skills page and lifecycle exist. Replay evaluation and review flow can be explained.
+- Risk: Full candidate-to-publish flow may take too long live.
+- Next action: Use page walkthrough and a short reuse example.
+
+### 5. Scheduled Work
+
+- Status: Yellow
+- Owner: Engineering
+- Progress: Cron page can show scheduled task configuration.
+- Risk: A live scheduled run may not complete within the meeting.
+- Next action: Use manual trigger or show configuration and run records.
+
+### 6. Governance
+
+- Status: Green
+- Owner: Operations
+- Progress: Status and logs can support the governance message.
+- Risk: Leadership may ask about security policy details that are not finalized.
+- Next action: Keep the message clear: private deployment, task evidence, human acceptance, and controlled tool rollout.
+
+## Key Risks
+
+| Risk | Impact | Probability | Owner | Mitigation |
+| --- | --- | --- | --- | --- |
+| Demo becomes feature tour | High | Medium | Product | Use one storyline and 6 scenarios |
+| Live output quality varies | Medium | Medium | Engineering | Prepare previous completed tasks |
+| Skill flow takes too long | Medium | High | Engineering | Explain lifecycle and show page state |
+| Connector dependency fails | Medium | Medium | Engineering | Keep connector optional |
+| ROI question lacks answer | High | Medium | Product | Propose 2-3 measurable internal pilots |
+
+## Management Decisions Requested
+
+1. Choose the first internal pilot workflow.
+2. Decide whether next sprint should prioritize demo polish, pilot hardening, or connector reliability.
+3. Confirm what governance controls are required before wider internal rollout.

docs/presentations/beaver-management-demo/upload-files/sales-weekly.csv

@@ -0,0 +1,9 @@
+week,region,product,new_pipeline_cny,closed_won_cny,forecast_cny,win_rate,top_account,risk_note
+2026-W23,North China,Beaver Enterprise,1280000,520000,910000,0.31,Hengyuan Manufacturing,"Procurement asks for private deployment proof before signing"
+2026-W23,East China,Beaver Enterprise,1860000,740000,1380000,0.37,Jianghai Finance,"Security review is positive but legal review is still open"
+2026-W23,South China,Beaver Team,760000,210000,430000,0.24,Nanfang Retail,"Champion changed team; sales needs executive sponsor"
+2026-W23,Overseas,Beaver Enterprise,940000,360000,690000,0.28,Atlas Components,"Customer wants Outlook connector demo before commercial discussion"
+2026-W24,North China,Beaver Enterprise,1510000,680000,1050000,0.34,Hengyuan Manufacturing,"Pilot environment requested by June 18"
+2026-W24,East China,Beaver Enterprise,2030000,810000,1520000,0.39,Jianghai Finance,"Deal depends on audit trail and task evidence explanation"
+2026-W24,South China,Beaver Team,820000,250000,500000,0.25,Nanfang Retail,"Budget owner wants clearer ROI story"
+2026-W24,Overseas,Beaver Enterprise,1010000,410000,760000,0.30,Atlas Components,"Connector reliability remains the main objection"

docs/presentations/beaver-management-demo/upload-files/support-tickets.csv

@@ -0,0 +1,11 @@
+ticket_id,date,account,segment,category,severity,summary,status
+SUP-1021,2026-05-28,Hengyuan Manufacturing,Enterprise,Deployment,P1,"Customer needs private deployment checklist for security review",Open
+SUP-1028,2026-05-30,Jianghai Finance,Enterprise,Auditability,P0,"Reviewer asks how task evidence records file usage and tool calls",Open
+SUP-1044,2026-06-02,Nanfang Retail,Team,Onboarding,P2,"New users do not know which first workflow to try",In Progress
+SUP-1051,2026-06-03,Atlas Components,Enterprise,Connector,P1,"Outlook connector setup requires clearer success and failure status",Open
+SUP-1060,2026-06-04,Hengyuan Manufacturing,Enterprise,Skills,P1,"Team wants accepted weekly report workflow to become reusable template",In Progress
+SUP-1067,2026-06-05,Jianghai Finance,Enterprise,Governance,P0,"Compliance wants human approval before publishing reusable skills",Open
+SUP-1075,2026-06-07,Nanfang Retail,Team,UX,P2,"Task output is too long for department managers",Resolved
+SUP-1082,2026-06-08,Atlas Components,Enterprise,Cron,P1,"Customer wants weekly customer email summary to run every Monday",Open
+SUP-1090,2026-06-10,Hengyuan Manufacturing,Enterprise,Model Config,P2,"Admin wants clearer provider configuration status",In Progress
+SUP-1096,2026-06-11,Jianghai Finance,Enterprise,Security,P0,"Security asks whether terminal tools can be disabled for pilot users",Open

docs/presentations/beaver-management-demo/upload-files/weekly-ops-metrics.csv

@@ -0,0 +1,11 @@
+metric,current_week,previous_week,target,status,note
+accepted_tasks,42,31,40,Green,"Accepted task count exceeded weekly target"
+average_revision_rounds,1.4,1.8,1.5,Green,"Output quality improved after prompt and skill updates"
+tasks_with_evidence_percent,88,82,90,Yellow,"Close to target; some simple chat tasks lack useful evidence"
+skill_reuse_count,11,6,10,Green,"Weekly report and risk review skills reused by pilot users"
+failed_tool_runs,7,9,3,Red,"Most failures came from connector timeout and missing credentials"
+scheduled_runs_completed,18,12,20,Yellow,"Cron usage is growing but several jobs are still manual"
+new_skill_candidates,5,3,4,Green,"Accepted work is generating reusable workflow candidates"
+open_p0_support_items,3,2,0,Red,"Auditability and security control questions need management attention"
+active_pilot_users,16,12,20,Yellow,"Usage increased but onboarding still depends on guided examples"
+average_task_completion_minutes,7.8,9.6,8.0,Green,"Median task completion time is improving"

docs/presentations/beaver-project/style.css

@@ -1,4 +1,4 @@
-/* Beaver Skill Replay Eval deck, based on html-ppt tech-sharing template. */
+/* Beaver Project deck, based on html-ppt tech-sharing template. */
 .replay-root {
   background: #08111d;
 }

docs/product-discovery/beaver/README.md

@@ -23,7 +23,7 @@ Beaver is an enterprise Agent sandbox and execution platform. It combines privat
 - [Backend README](../../../app-instance/backend/README.md)
 - [Recent Backend Features](../../../projcet_review/backend_recent_completed_features.md)
 - [UI/UX Page Docs](../../ui-ux/README.md)
-- [Customer Presentation](../../presentations/skill-replay-eval/index.html)
+- [Customer Presentation](../../presentations/beaver-project/index.html)
 
 ## Related Feature Discovery
 

docs/product-discovery/skill-replay-eval/README.md

@@ -10,4 +10,4 @@ Related source material:
 
 - [Skill Replay Eval Design](../../superpowers/specs/2026-06-08-skill-replay-eval-design.md)
 - [Skill Replay Eval Implementation Plan](../../superpowers/plans/2026-06-08-skill-replay-eval.md)
-- [Beaver customer presentation](../../presentations/skill-replay-eval/index.html)
+- [Beaver customer presentation](../../presentations/beaver-project/index.html)

docs/product-discovery/skill-replay-eval/product-discovery-report.md

@@ -12,7 +12,7 @@ Source context:
 - Feature design: `docs/superpowers/specs/2026-06-08-skill-replay-eval-design.md`
 - Delivery plan: `docs/superpowers/plans/2026-06-08-skill-replay-eval.md`
 - Current implementation signals: `beaver/skills/learning/{case_selection,preservation,replay,surrogate,eval}.py`, Skills page replay report UI, publish gate checks
-- Customer positioning: `docs/presentations/skill-replay-eval/index.html`
+- Customer positioning: `docs/presentations/beaver-project/index.html`
 
 ## Executive Summary
 

docs/superpowers/specs/2026-06-15-plugin-skill-mirroring-design.md

@@ -0,0 +1,409 @@
+# Beaver Plugin Skill Mirroring Design
+
+## Decision
+
+Beaver V1 plugins are declarative skill bundles. Enabling a plugin mirrors each declared
+`SKILL.md` and its supporting files into `SkillSpecStore`. From that point onward, the
+mirrored skill is a normal Beaver skill:
+
+- it has the same resolver priority as any workspace-managed skill;
+- runtime activation, receipts, performance scoring, replay evaluation, review, publish,
+  rollback, and disable all use the existing skill lifecycle;
+- self-learning only writes Beaver-managed versions and never edits the plugin package;
+- plugin origin remains metadata, not a separate runtime class.
+
+An arbitrary in-process Python entrypoint, hooks, providers, and custom runtime code are
+out of scope for this plan. Tool-providing plugins should continue to use MCP until a
+separate executable-plugin security design is approved.
+
+## Why The Proposed Flow Is Correct
+
+The proposed "mirror, learn on the mirror, merge on plugin update, then evaluate" flow is
+correct with one important refinement: plugin upgrades must be treated as a three-way
+merge, not a two-document rewrite.
+
+The three inputs are:
+
+1. `B`, the last accepted upstream plugin snapshot;
+2. `L`, the current Beaver-published skill, including local self-learning;
+3. `U`, the newly discovered upstream plugin snapshot.
+
+This distinction prevents a plugin update from silently deleting local learning and
+prevents local learning from silently discarding new upstream safety or workflow changes.
+
+## Package Contract
+
+Each plugin directory contains `beaver.plugin.json`:
+
+```json
+{
+  "schema_version": 1,
+  "id": "baoyu-comic",
+  "name": "Baoyu Comic",
+  "version": "1.2.0",
+  "skills": [
+    {
+      "name": "baoyu-comic",
+      "path": "skills/baoyu-comic"
+    }
+  ]
+}
+```
+
+Rules:
+
+- `id` and skill names use lowercase letters, digits, `_`, and `-`.
+- Skill paths are relative to the plugin root and cannot escape it.
+- Every skill directory must contain `SKILL.md`.
+- Symlinks are rejected while mirroring.
+- Two enabled plugins cannot own the same Beaver skill name.
+- A plugin cannot overwrite an existing non-plugin workspace skill.
+- Discovery does not enable a plugin. Enablement is an explicit admin action.
+
+## Storage Model
+
+Plugin packages remain outside the managed skill version tree:
+
+```text
+workspace/
+  plugins/
+    baoyu-comic/
+      beaver.plugin.json
+      skills/baoyu-comic/SKILL.md
+  .beaver/
+    plugins/state.json
+  skills/
+    baoyu-comic/
+      skill.json
+      current.json
+      upstreams/
+        baoyu-comic/
+          <tree-hash>/
+            upstream.json
+            SKILL.md
+            assets/...
+      versions/
+        v0001/
+          version.json
+          SKILL.md
+          assets/...
+```
+
+`upstreams/` stores immutable raw plugin snapshots. `versions/` stores runtime-visible
+Beaver versions. A merged Beaver version may differ from its upstream snapshot.
+
+Every upstream snapshot has two hashes:
+
+- `skill_content_hash`: canonical hash of normalized `SKILL.md`; used by the LLM merge and
+  skill-content preservation checks.
+- `skill_tree_hash`: hash of every regular file in the skill tree, including normalized
+  relative path, byte length, bytes, and executable-bit metadata. Symlinks are rejected.
+  This is the supply-chain identity used for update detection and state.
+
+The tree hash includes `SKILL.md`, templates, assets, examples, and scripts. Full Unix
+mode bits are not hashed because umask and extraction tools can change them; only whether
+any executable bit is set is normalized into the hash. Beaver metadata files such as
+`version.json` and `upstream.json` are excluded.
+
+Every Beaver `SkillVersion` also stores a backward-compatible `tree_hash`. New versions
+compute it from the complete promoted version directory. Older versions without the field
+derive it on read, so `L.tree` is available for upgrade classification.
+
+Plugin state records:
+
+```json
+{
+  "plugins": {
+    "baoyu-comic": {
+      "enabled": true,
+      "installed_version": "1.2.0",
+      "manifest_path": "plugins/baoyu-comic/beaver.plugin.json",
+      "updates_paused": false,
+      "skills": {
+        "baoyu-comic": {
+          "accepted_upstream_tree_hash": "sha256...",
+          "observed_upstream_tree_hash": "sha256...",
+          "accepted_beaver_version": "v0003",
+          "current_beaver_version": "v0003",
+          "pending_candidate_id": null,
+          "status": "synced"
+        }
+      }
+    }
+  }
+}
+```
+
+Skill versions and drafts also carry plugin provenance. State is operational metadata;
+version provenance is the durable audit record.
+
+## Initial Enable Flow
+
+When an admin enables a valid plugin:
+
+1. Discover and validate the manifest.
+2. Copy each declared skill into an immutable upstream snapshot.
+3. Reject ownership/name conflicts before changing any skill.
+4. Run the existing deterministic skill safety checker against an in-memory initial-mirror
+   draft and reject failed or critical results.
+5. Publish an exact Beaver mirror as the next skill version.
+6. Copy supporting files into that version.
+7. Mark the skill `source_kind="plugin"` and active.
+8. Record plugin ID, plugin version, source path, upstream hash, and mirror mode in
+   `SkillVersion.provenance`.
+9. Update plugin state only after all declared skills succeed.
+
+Initial enable is an explicit trust action, so it does not require LLM synthesis. Manifest
+validation, path validation, and the existing static skill safety checks still apply.
+
+All files are first written below a transaction staging directory on the same filesystem.
+Only after manifest validation, tree hashing, conflict checks, and safety checks pass are
+immutable upstream/version directories promoted with `os.replace()`. `current.json`,
+`skill.json`, and indexes are atomically replaced under the workspace write lock; plugin
+state is written last. A failed transaction may leave an unreferenced immutable directory,
+which cleanup can remove, but it cannot make a partial version runtime-visible.
+
+For a new skill, the complete staged skill directory is promoted once. For an existing
+skill, immutable directories and metadata are promoted first and `current.json` is
+replaced last as the runtime visibility switch. This provides per-skill atomic visibility;
+the workspace lock serializes writers across a multi-skill plugin operation.
+
+## Runtime Priority
+
+Mirrored plugin skills are loaded exclusively from `SkillSpecStore`. They are not supplied
+through `SkillsLoader.extra_dirs`.
+
+This makes priority deterministic:
+
+1. active published workspace versions, including plugin-origin versions;
+2. builtin skills.
+
+`source_kind="plugin"` is displayed for provenance but does not lower selection priority
+or exclude the skill from self-learning.
+
+## Upgrade Classification
+
+For each linked skill, compare upstream tree hashes:
+
+| Condition | Action |
+| --- | --- |
+| `U.tree == B.tree` | No upstream change; no action. |
+| `L.tree == U.tree` | Acknowledge the new upstream snapshot; no draft needed. |
+| `L.tree == B.tree` and `U.tree != B.tree` | Create a deterministic `fast_forward` plugin update draft containing `U`. |
+| `L.tree != B.tree` and `U.tree != B.tree` | Create a `three_way` plugin update candidate using `B`, `L`, and `U`. |
+
+Even the `fast_forward` case goes through safety, replay evaluation, review, and publish.
+It skips LLM merge synthesis because there is no local divergence.
+
+Candidate IDs are deterministic:
+
+```text
+plugin-update:<plugin-id>:<skill-name>:<new-upstream-hash-prefix>
+```
+
+This makes boot-time sync idempotent.
+
+Supporting files use a deterministic path-level three-way merge:
+
+- local unchanged from `B`: take `U`;
+- upstream unchanged from `B`: keep `L`;
+- both sides equal: keep either;
+- a file added on only one side: keep it;
+- divergent edits, delete-versus-edit, or different additions at the same path: record an
+  unresolved file conflict and block publication.
+
+The LLM merges only `SKILL.md`. It does not attempt to merge arbitrary or binary
+supporting files.
+
+## Learning Integration
+
+Add candidate kind `plugin_skill_update`. Its evidence contains only references:
+
+```json
+{
+  "plugin_id": "baoyu-comic",
+  "plugin_version": "1.2.0",
+  "skill_name": "baoyu-comic",
+  "merge_mode": "three_way",
+  "base_upstream_tree_hash": "old-hash",
+  "new_upstream_tree_hash": "new-hash",
+  "local_version": "v0003"
+}
+```
+
+The learning service resolves the actual snapshots from `SkillSpecStore`; raw skill
+content is not duplicated into `learning-candidates.jsonl`.
+
+For `three_way`, the synthesizer receives:
+
+- old upstream `B`;
+- current local skill `L`;
+- new upstream `U`;
+- relevant historical run evidence for `L`, when available.
+
+The synthesizer must return the merged skill plus explicit merge decisions:
+
+```json
+{
+  "frontmatter": {},
+  "content": "...",
+  "change_reason": "...",
+  "preserved_local_sections": [],
+  "adopted_upstream_sections": [],
+  "resolved_conflicts": [],
+  "dropped_sections": []
+}
+```
+
+The generated draft uses `proposal_kind="plugin_skill_update"` and carries the complete
+plugin merge provenance.
+
+## Evaluation And Publish Gates
+
+The existing flow remains authoritative:
+
+```text
+candidate
+  -> draft
+  -> static safety
+  -> replay eval
+  -> review
+  -> publish
+  -> rollback if needed
+```
+
+Replay eval compares:
+
+- baseline arm: current local version `L`;
+- candidate arm: merged draft `M`.
+
+The preservation report is extended for plugin updates:
+
+- local preservation: important instructions from `L` are not silently removed;
+- upstream adoption: new important instructions from `U` are represented;
+- safety/tool preservation: Safety and Required Tools changes require explicit handling;
+- unresolved conflicts cause evaluation failure.
+
+Publishing is blocked when:
+
+- static safety fails;
+- replay evaluation regresses;
+- confidence is low under the existing gate;
+- local or upstream preservation fails;
+- merge decisions contain unresolved `SKILL.md` conflicts;
+- the supporting-file merge plan contains unresolved path/content conflicts.
+
+On publish, the pipeline notifies `PluginManager`, which advances
+`accepted_upstream_tree_hash`, clears the pending candidate, and records the new Beaver
+version.
+
+Observer delivery is not the source of truth. At the start of every sync, reconciliation
+inspects the current published version provenance. If it contains a valid, newer
+`plugin_skill_update` result and its upstream snapshot exists, plugin state is repaired:
+
+- advance `accepted_upstream_tree_hash`;
+- advance `accepted_beaver_version`;
+- clear the matching pending candidate;
+- set status to `synced`.
+
+Reconciliation never moves `accepted_beaver_version` backwards after a runtime rollback.
+An observer failure is audited but does not make an already-successful publish request
+fail, which avoids client retries creating misleading duplicate operations.
+
+## Concurrent And Failure Behavior
+
+- All plugin sync, skill version allocation/publication, plugin state mutation, and
+  learning-candidate mutation share a reentrant cross-process workspace write lock at
+  `.beaver/locks/plugin-skill-write.lock`.
+- The lock uses the repository's existing `fcntl`/`msvcrt` pattern plus an in-process
+  reentrant guard. Nested store calls reuse the held lock instead of deadlocking.
+- Candidate existence checks and JSONL writes happen inside the lock.
+- Version-number allocation and version promotion happen inside the lock.
+- Explicit enable/sync waits for the lock with a bounded timeout and returns a busy error
+  on timeout.
+- Engine boot never calls an LLM. Its auto-sync uses a non-blocking lock attempt; when the
+  lock is busy, boot proceeds with the current published skills and reports sync deferred.
+- Repeated and concurrent boot/sync is idempotent across processes, not only within one
+  Python object.
+- If another active draft targets the same skill, the plugin update remains pending and
+  is not synthesized until the skill is free.
+- If a newer plugin version appears while an older update is pending, the old candidate is
+  marked superseded and a new candidate is created against the last accepted upstream.
+- Rejecting a draft preserves the plugin package, upstream snapshots, current skill, and
+  candidate audit history. Regeneration remains possible.
+- Partial multi-skill plugin enable never promotes metadata/current pointers until every
+  staged skill passes validation.
+- Plugin files are never modified by learning or publication.
+
+## Pause, Disable, Missing, And Adopt
+
+- Pausing updates suspends discovery-to-candidate sync while linked skills remain active.
+- Resuming updates reconciles state and performs sync.
+- Disabling a plugin is an explicit destructive runtime action: it pauses updates and
+  disables linked skills, but never deletes versions or upstream snapshots. The API
+  requires an explicit `disable_linked_skills=true` confirmation.
+- Re-enabling restores linked skills and performs sync.
+- A missing plugin package is a supply-chain status only. It marks the plugin `missing`,
+  suspends sync/update, and leaves the current Beaver skills active.
+- An explicit `adopt` action detaches a skill from its plugin, changes
+  `source_kind` to `managed`, keeps the current version active, and prevents future plugin
+  updates from targeting it.
+
+## Management API And UI
+
+Backend endpoints:
+
+```text
+GET  /api/plugins
+POST /api/plugins/sync
+POST /api/plugins/{plugin_id}/enable
+POST /api/plugins/{plugin_id}/pause
+POST /api/plugins/{plugin_id}/resume
+POST /api/plugins/{plugin_id}/disable
+POST /api/plugins/{plugin_id}/skills/{skill_name}/adopt
+```
+
+API payloads never expose absolute server paths. Workspace manifests use workspace-relative
+paths. External manifests use a redacted display path such as
+`<external>/baoyu-comic/beaver.plugin.json`.
+
+The existing Skills page gains a Plugins tab showing:
+
+- discovered/enabled/missing/error state;
+- installed and discovered plugin versions;
+- declared skills and their current Beaver versions;
+- sync state and pending learning candidate;
+- enable, pause, resume, disable, sync, and adopt actions.
+
+Plugin-origin skills continue to appear in the normal Published, Candidates, and Drafts
+tabs with provenance and merge-mode labels.
+
+## Non-Goals
+
+- Importing arbitrary plugin Python modules into the Beaver process.
+- Plugin-defined hooks, providers, channels, or frontend bundles.
+- Automatic downloading from a plugin marketplace.
+- Automatically publishing plugin upgrades without review.
+- Editing or rebasing plugin source files in place.
+
+## Acceptance Criteria
+
+1. Enabling a plugin mirrors all declared skills and supporting files into managed
+   versions.
+2. Mirrored skills have the same resolver priority and learning eligibility as ordinary
+   workspace skills.
+3. Self-learning never modifies the plugin package.
+4. Plugin updates create idempotent `plugin_skill_update` candidates.
+5. Local divergence triggers a three-way merge; no divergence triggers a deterministic
+   fast-forward draft.
+6. Every plugin update passes the existing safety, replay, review, and publish gates.
+7. Publishing advances plugin state and preserves complete provenance.
+8. Pause, disable, missing package, rejection, restart, and newer-update races do not lose
+   the current skill or its learned versions; missing packages leave current skills active.
+9. Existing non-plugin skills and legacy candidate payloads remain backward compatible.
+10. Supporting-file-only updates change the upstream tree hash and create an update
+    candidate.
+11. Concurrent boot, sync, and enable operations do not allocate duplicate versions or
+    append duplicate candidates.
+12. Sync reconciliation repairs plugin state after a published version succeeds but its
+    observer/state update fails.