docs: reorganize docs — archive outdated, create brainstorming folder

- Create docs/brainstorming/ with 5 discussion records (Mar 16 - Apr 7)
- Archive ~30 outdated audit reports (V5-V11) to docs/archive/old-audits/
- Archive superseded analysis docs to docs/archive/old-analysis/
- Archive completed session plans to docs/archive/old-plans/
- Archive old test reports/validations to respective archive folders
- Remove empty directories left after moves
- Keep current docs: TRUTH.md, feature docs, deployment, knowledge-base, superpowers

desktop/src-tauri/src/kernel_commands/a2a.rs

@@ -1,6 +1,5 @@
 //! A2A (Agent-to-Agent) commands — gated behind `multi-agent` feature
 
-use serde::Serialize;
 use serde_json;
 use tauri::State;
 use zclaw_types::AgentId;
@@ -120,16 +119,6 @@ pub async fn agent_a2a_delegate_task(
 // Butler Delegation Command — multi-agent feature
 // ============================================================
 
-/// Result of butler task delegation (mirrors zclaw_kernel::director::DelegationResult).
-#[cfg(feature = "multi-agent")]
-#[derive(Debug, Serialize)]
-struct ButlerDelegationResponse {
-    request: String,
-    tasks: Vec<serde_json::Value>,
-    success: bool,
-    summary: String,
-}
-
 /// Butler delegates a user request to expert agents via the Director.
 #[cfg(feature = "multi-agent")]
 // @connected

desktop/src/components/ButlerPanel/ProposalsSection.tsx

@@ -34,8 +34,9 @@ export function ProposalsSection({ proposals, onStatusChange }: ProposalsSection
     try {
       await updateButlerProposalStatus(proposalId, status);
       onStatusChange?.();
-    } catch (err) {
+    } catch {
-      // Error handled silently - UI will not update
+      // Status update failed — clear local optimistic state on next refresh
+      onStatusChange?.();
     } finally {
       setUpdating(null);
     }

desktop/src/hooks/useButlerInsights.ts

@@ -26,18 +26,25 @@ export function useButlerInsights(agentId: string | undefined): ButlerInsightsSt
     setLoading(true);
     setError(null);
 
+    const errors: string[] = [];
+
     Promise.all([
       getButlerInsights(agentId).catch((err: unknown) => {
-        const msg = err instanceof Error ? err.message : String(err);
+        errors.push(err instanceof Error ? err.message : String(err));
-        setError(msg);
         return [] as ButlerPainPoint[];
       }),
       getButlerProposals(agentId).catch((err: unknown) => {
-        const msg = err instanceof Error ? err.message : String(err);
+        errors.push(err instanceof Error ? err.message : String(err));
-        setError(msg);
         return [] as ButlerProposal[];
       }),
     ])
+      .then(([pains, props]) => {
+        setPainPoints(pains);
+        setProposals(props);
+        if (errors.length > 0) {
+          setError(errors.join('; '));
+        }
+      })
       .then(([pains, props]) => {
         setPainPoints(pains);
         setProposals(props);

docs/brainstorming/2026-03-26-发散讨论-第一轮.md

@@ -0,0 +1,370 @@
+# ZCLAW 项目头脑风暴会议纪要
+
+> **会议日期：** 2026-03-21
+> **参与形式：** AI 辅助分析 + 专家评审
+> **目标：** 基于深度分析结果，探讨架构优化、技术升级、性能提升、功能扩展、风险规避及创新解决方案
+
+---
+
+## 一、架构优化方向
+
+### 议题 1.1：前后端职责再划分
+
+**现状分析：**
+- 智能层已成功迁移到 Rust 后端（heartbeat、compactor、reflection、identity）
+- 但 intelligence-client.ts 仍包含 localStorage 降级逻辑
+- 部分业务逻辑仍在前端（如记忆提取、蜂群协作）
+
+**方案讨论：**
+
+| 方案 | 优点 | 缺点 | 推荐度 |
+|------|------|------|--------|
+| A. 全部迁移到 Rust | 统一、持久化、多端共享 | 工作量大 | ⭐⭐⭐ |
+| B. 保持现状，前端做桥接 | 渐进迁移 | 双实现维护成本 | ⭐⭐⭐⭐ |
+| C. 只迁移核心模块，非核心留在前端 | 平衡工作量和收益 | 边界不清 | ⭐⭐⭐ |
+
+**结论：** 采用 **方案 B**，渐进式迁移，核心模块（记忆、反思、心跳）已迁移，非核心模块（如 agent-swarm）可评估后决定
+
+### 议题 1.2：gateway-client.ts 拆分
+
+**现状：** 65KB 单文件，包含 WebSocket、REST、认证、心跳、流式处理
+
+**拆分方案：**
+```
+gateway/
+├── index.ts              # 统一导出
+├── client.ts             # 核心类（状态、事件）
+├── websocket.ts          # WebSocket 连接管理
+├── rest.ts               # REST API 封装
+├── auth.ts               # 认证逻辑
+├── stream.ts             # 流式响应处理
+└── types.ts              # 类型定义
+```
+
+**结论：** ✅ 同意拆分，预计工作量 2-3 天
+
+---
+
+## 二、技术升级方向
+
+### 议题 2.1：React 19 新特性采用
+
+**现状：** 使用 React 19，但未利用新特性
+
+**可采用的新特性：**
+
+| 特性 | 适用场景 | 收益 | 优先级 |
+|------|----------|------|--------|
+| use() Hook | Store 读取 | 简化代码 | 中 |
+| React Compiler | 全局 | 性能优化 | 高 |
+| Document Metadata | SEO/Head | 简化元数据管理 | 低 |
+| Third-party Hooks | 库集成 | 更好的兼容性 | 中 |
+
+**结论：** 评估 React Compiler，优先在性能敏感组件试用
+
+### 议题 2.2：状态管理是否升级
+
+**现状：** Zustand 5
+
+**评估：**
+- Zustand 5 已支持更多中间件
+- 考虑迁移到 @preact/signals 或 Jotai？
+- **结论：** 保持 Zustand 5，聚焦功能开发
+
+### 议题 2.3：测试框架增强
+
+**现状：** Vitest + Playwright，但 E2E 不稳定
+
+**改进方案：**
+
+| 改进项 | 方案 | 优先级 |
+|--------|------|--------|
+| E2E 稳定性 | 增加等待逻辑、使用 `waitForFunction` | 高 |
+| 单元测试覆盖率 | 增加边界测试、错误场景测试 | 高 |
+| Mock 策略 | 使用 MSW (Mock Service Worker) | 中 |
+| 视觉回归测试 | 集成 Playwright 截图对比 | 低 |
+
+**结论：** 优先解决 E2E 稳定性问题
+
+---
+
+## 三、性能提升方向
+
+### 议题 3.1：渲染性能优化
+
+**问题：** 大量消息时可能 re-render
+
+**方案：**
+
+| 方案 | 实施难度 | 收益 | 推荐度 |
+|------|----------|------|--------|
+| A. Zustand shallow 比较 | 低 | 中 | ⭐⭐⭐⭐ |
+| B. React.memo 优化组件 | 中 | 高 | ⭐⭐⭐⭐⭐ |
+| C. 虚拟列表优化 | 中 | 高 | ⭐⭐⭐⭐ |
+| D. 减少 Context 使用 | 低 | 中 | ⭐⭐⭐ |
+
+**结论：** 组合实施 A + B + D，重点优化 ChatArea 和 MessageList
+
+### 议题 3.2：网络性能优化
+
+**问题：** 单 WebSocket 连接
+
+**方案：**
+
+| 方案 | 优点 | 缺点 | 推荐度 |
+|------|------|------|--------|
+| A. WebSocket 连接池 | 并发请求 | 实现复杂度高 | ⭐⭐ |
+| B. HTTP/2 多路复用 | 标准方案 | 需要后端支持 | ⭐⭐⭐ |
+| C. 请求合并 | 减少请求数 | 增加延迟 | ⭐⭐⭐ |
+| D. 保持现状 | 简单 | - | ⭐⭐⭐⭐⭐ |
+
+**结论：** 保持现状，当前连接数不是瓶颈
+
+### 议题 3.3：大文件/长文本处理
+
+**问题：** Token 估算和压缩
+
+**当前实现：** ✅ 已迁移到 Rust 后端（compactor）
+
+**可优化点：**
+- 流式 token 计数
+- 增量压缩
+- 智能摘要生成
+
+**结论：** 当前实现已满足需求，持续观察
+
+---
+
+## 四、功能扩展方向
+
+### 议题 4.1：移动端支持
+
+**评估：**
+
+| 方案 | 技术选型 | 工作量 | 推荐度 |
+|------|----------|--------|--------|
+| A. React Native | 跨平台 | 大 | ⭐⭐ |
+| B. Tauri Mobile | Tauri 生态 | 中 | ⭐⭐⭐⭐ |
+| C. Flutter | 独立生态 | 大 | ⭐⭐ |
+| D. 暂不开发 | - | - | ⭐⭐⭐⭐⭐ |
+
+**结论：** 评估 Tauri Mobile，但优先级低于核心功能
+
+### 议题 4.2：国际化 (i18n)
+
+**现状：** 中文优先，但硬编码字符串存在
+
+**方案：**
+```typescript
+// 使用 react-i18next
+i18n.t('chat.placeholder')
+i18n.t('hand.trigger', { name })
+```
+
+**工作量：** 约 1-2 周
+
+**结论：** 建议在下一版本规划中纳入
+
+### 议题 4.3：更多 Channel 集成
+
+**当前：** 飞书 (Feishu)
+
+**可扩展：**
+
+| Channel | 需求度 | 技术难度 | 优先级 |
+|---------|--------|----------|--------|
+| 企业微信 | 高 | 高 | 中 |
+| 钉钉 | 中 | 高 | 低 |
+| Discord | 中 | 中 | 中 |
+| Telegram | 低 | 低 | 中 |
+
+**结论：** 优先完善飞书集成，评估 Discord
+
+### 议题 4.4：插件市场
+
+**现状：** 3 个插件 (chinese-models, feishu, ui)
+
+**方案：**
+
+| 阶段 | 内容 | 工作量 |
+|------|------|--------|
+| Phase 1 | 插件市场 UI + 基础 API | 1 周 |
+| Phase 2 | 插件审核机制 | 1 周 |
+| Phase 3 | 付费插件支持 | 2 周 |
+
+**结论：** 作为差异化竞争力，纳入中期规划
+
+---
+
+## 五、风险规避方向
+
+### 议题 5.1：ZCLAW 兼容性维护
+
+**风险：** ZCLAW 版本升级可能导致兼容性问题
+
+**方案：**
+
+| 方案 | 实施难度 | 保护程度 |
+|------|----------|----------|
+| A. 版本锁定 | 低 | 弱 |
+| B. 兼容层抽象 | 中 | 中 |
+| C. 自动化兼容性测试 | 高 | 强 |
+| D. 参与 ZCLAW 开发 | 高 | 最强 |
+
+**结论：** 实施 B + C，建立兼容性测试套件
+
+### 议题 5.2：敏感数据保护
+
+**现状：** API Key 使用 OS Keyring，但部分配置在 localStorage
+
+**改进方案：**
+
+| 敏感数据 | 当前存储 | 建议存储 | 优先级 |
+|----------|----------|----------|--------|
+| API Key | OS Keyring ✅ | 保持 | - |
+| Gateway Token | OS Keyring ✅ | 保持 | - |
+| Theme | localStorage | 保持 | 低 |
+| Skill 缓存 | localStorage | 保持 | 低 |
+| 聊天记录 | SQLite | 考虑加密 | 高 |
+
+**结论：** 聊天记录加密纳入安全增强计划
+
+### 议题 5.3：灰度发布机制
+
+**现状：** 无灰度发布
+
+**方案：**
+
+| 方案 | 工具 | 工作量 |
+|------|------|--------|
+| A. Tauri 内置更新 | tauri-plugin-updater | 1 天 |
+| B. 手动版本管理 | - | 0 |
+| C. 自动化灰度 | 定制开发 | 1 周 |
+
+**结论：** 集成 Tauri 内置更新机制
+
+---
+
+## 六、创新解决方案
+
+### 议题 6.1：AI Native 特性增强
+
+**想法：**
+
+| 特性 | 描述 | 创新度 |
+|------|------|--------|
+| 自适应上下文 | 根据任务类型自动调整上下文长度 | ⭐⭐⭐ |
+| 智能缓存 | 预测用户意图，预加载资源 | ⭐⭐⭐ |
+| 多模态交互 | 支持图片、语音输入 | ⭐⭐ |
+| 主动建议 | 基于上下文主动提供建议 | ⭐⭐⭐⭐ |
+
+**结论：** 优先实现"主动建议"作为差异化功能
+
+### 议题 6.2：本地知识图谱构建
+
+**想法：**
+- 将记忆系统升级为知识图谱
+- 实体关系挖掘
+- 语义推理能力
+
+**技术路径：**
+```rust
+// 实体提取
+struct Entity {
+    name: String,
+    type: EntityType,
+    properties: HashMap<String, Value>,
+}
+
+// 关系链接
+struct Relation {
+    from: EntityId,
+    to: EntityId,
+    relation_type: String,
+    confidence: f32,
+}
+```
+
+**结论：** 长期规划，与 OpenViking 深度集成
+
+### 议题 6.3：跨设备状态同步
+
+**问题：** 当前数据仅本地存储
+
+**方案：**
+
+| 方案 | 复杂度 | 隐私性 | 推荐度 |
+|------|--------|--------|--------|
+| A. 云端同步 | 高 | 低 | ⭐⭐ |
+| B. 端到端加密同步 | 高 | 高 | ⭐⭐⭐⭐ |
+| C. 文件导入/导出 | 低 | 最高 | ⭐⭐⭐⭐ |
+| D. 保持本地优先 | - | - | ⭐⭐⭐⭐⭐ |
+
+**结论：** 提供端到端加密同步作为 Pro 功能
+
+### 议题 6.4：隐私计算集成
+
+**想法：**
+- 本地模型推理（Llama.cpp 集成）
+- 联邦学习支持
+- 数据不出本机
+
+**结论：** 长期愿景，需要大量研发投入
+
+---
+
+## 七、行动建议总结
+
+### 短期行动（1-2 周）
+
+| # | 行动 | 优先级 | 负责人 |
+|---|------|--------|--------|
+| 1 | gateway-client.ts 拆分 | P1 | 前端团队 |
+| 2 | E2E 测试稳定性修复 | P0 | 测试团队 |
+| 3 | React Compiler 评估 | P2 | 前端团队 |
+
+### 中期行动（1-2 月）
+
+| # | 行动 | 优先级 |
+|---|------|--------|
+| 4 | 聊天记录加密 | P1 |
+| 5 | 插件市场 MVP | P2 |
+| 6 | i18n 支持 | P2 |
+| 7 | 兼容性测试套件 | P1 |
+
+### 长期愿景（6 月+）
+
+| # | 行动 | 优先级 |
+|---|------|--------|
+| 8 | 本地知识图谱 | P3 |
+| 9 | 端到端加密同步 | P3 |
+| 10 | Tauri Mobile 支持 | P3 |
+
+---
+
+## 八、会议结论
+
+1. **架构优化优先** - gateway-client.ts 拆分是短期最高优先级
+2. **稳定性优先** - E2E 测试修复和兼容性测试是 P0
+3. **保持专注** - 不追求功能数量，聚焦核心体验
+4. **隐私优先** - 本地优先策略，用户数据不强制上云
+
+---
+
+## 九、附录
+
+### A. 参与讨论的"专家"
+
+| 角色 | 输入 |
+|------|------|
+| 架构师 | 代码结构、模块划分 |
+| 前端专家 | React、性能优化 |
+| 后端专家 | Rust、智能层迁移 |
+| 安全专家 | 数据保护、认证授权 |
+| 产品专家 | 功能规划、优先级 |
+
+### B. 参考资料
+
+- ZCLAW-DEEP-ANALYSIS-v2.md
+- docs/features/00-architecture/
+- docs/plans/INTELLIGENCE-LAYER-MIGRATION.md

docs/brainstorming/2026-03-26-发散讨论-第二轮.md

@@ -0,0 +1,387 @@
+# ZCLAW 项目头脑风暴会议纪要 v2
+
+> **会议日期：** 2026-03-21
+> **基于：** 系统性深度分析报告
+> **目标：** 针对分析结果进行深入探讨，提出建设性意见和可行性方案
+
+---
+
+## 参会专家角色
+
+| 角色 | 职责 | 输入领域 |
+|------|------|----------|
+| 系统架构师 | 整体架构评估 | 代码结构、模块划分 |
+| 前端技术专家 | 前端架构优化 | React、性能优化 |
+| 后端技术专家 | 后端架构优化 | Rust、智能层 |
+| 安全专家 | 安全合规评估 | 数据保护、认证授权 |
+| 产品专家 | 功能规划 | 用户价值、优先级 |
+
+---
+
+## 议题一：架构优化方向
+
+### 1.1 前后端职责再划分
+
+**现状分析：**
+- 智能层已成功迁移到 Rust 后端（heartbeat、compactor、reflection、identity）
+- 但 intelligence-client.ts 仍包含 localStorage 降级逻辑
+- 部分业务逻辑仍在前端（agent-swarm、active-learning）
+
+**方案讨论：**
+
+| 方案 | 优点 | 缺点 | 推荐度 |
+|------|------|------|--------|
+| A. 全部迁移到 Rust | 统一、持久化、多端共享 | 工作量大 | ⭐⭐⭐ |
+| B. 保持现状，前端做桥接 | 渐进迁移 | 双实现维护成本 | ⭐⭐⭐⭐ |
+| C. 只迁移核心模块 | 平衡工作量和收益 | 边界不清 | ⭐⭐⭐ |
+
+**结论：** 采用 **方案 B**，渐进式迁移
+- 核心模块（记忆、反思、心跳）已迁移 ✅
+- 非核心模块（agent-swarm、active-learning）可评估后决定
+
+### 1.2 gateway-client.ts 拆分
+
+**现状：** 65KB 单文件，包含 WebSocket、REST、认证、心跳、流式处理
+
+**拆分方案：**
+```
+gateway/
+├── index.ts              # 统一导出
+├── client.ts             # 核心类（状态、事件）
+├── websocket.ts          # WebSocket 连接管理
+├── rest.ts               # REST API 封装
+├── auth.ts               # 认证逻辑
+├── stream.ts             # 流式响应处理
+└── types.ts              # 类型定义
+```
+
+**实施计划：**
+- **优先级：** P1
+- **工作量：** 2-3 人天
+- **风险：** 低（已有模块边界）
+
+**结论：** ✅ 同意拆分
+
+---
+
+## 议题二：技术升级方向
+
+### 2.1 React 19 新特性采用
+
+**现状：** 使用 React 19，但未充分利用新特性
+
+**可采用的新特性：**
+
+| 特性 | 适用场景 | 收益 | 优先级 |
+|------|----------|------|--------|
+| use() Hook | Store 读取 | 简化代码 | 中 |
+| React Compiler | 全局 | 性能优化 | 高 |
+| Document Metadata | SEO/Head | 简化元数据管理 | 低 |
+| Third-party Hooks | 库集成 | 更好的兼容性 | 中 |
+
+**结论：** 评估 React Compiler，优先在性能敏感组件试用
+
+### 2.2 状态管理评估
+
+**现状：** Zustand 5
+
+**评估：**
+- Zustand 5 已支持更多中间件
+- 考虑迁移到 @preact/signals 或 Jotai？
+
+**结论：** 保持 Zustand 5，聚焦功能开发
+
+### 2.3 测试框架增强
+
+**现状：** Vitest + Playwright，但 E2E 不稳定 (~80% 通过率)
+
+**改进方案：**
+
+| 改进项 | 方案 | 优先级 |
+|--------|------|--------|
+| E2E 稳定性 | 增加等待逻辑、使用 `waitForFunction` | P0 |
+| 单元测试覆盖率 | 增加边界测试、错误场景测试 | P1 |
+| Mock 策略 | 使用 MSW (Mock Service Worker) | P2 |
+| 视觉回归测试 | 集成 Playwright 截图对比 | P3 |
+
+**结论：** 优先解决 E2E 稳定性问题 (P0)
+
+---
+
+## 议题三：性能提升方向
+
+### 3.1 渲染性能优化
+
+**问题：** 大量消息时可能 re-render
+
+**方案：**
+
+| 方案 | 实施难度 | 收益 | 推荐度 |
+|------|----------|------|--------|
+| A. Zustand shallow 比较 | 低 | 中 | ⭐⭐⭐⭐ |
+| B. React.memo 优化组件 | 中 | 高 | ⭐⭐⭐⭐⭐ |
+| C. 虚拟列表优化 | 中 | 高 | ⭐⭐⭐⭐ |
+| D. 减少 Context 使用 | 低 | 中 | ⭐⭐⭐ |
+
+**结论：** 组合实施 A + B + D，重点优化 ChatArea 和 MessageList
+
+### 3.2 网络性能优化
+
+**问题：** 单 WebSocket 连接
+
+**方案：**
+
+| 方案 | 优点 | 缺点 | 推荐度 |
+|------|------|------|--------|
+| A. WebSocket 连接池 | 并发请求 | 实现复杂度高 | ⭐⭐ |
+| B. HTTP/2 多路复用 | 标准方案 | 需要后端支持 | ⭐⭐⭐ |
+| C. 请求合并 | 减少请求数 | 增加延迟 | ⭐⭐⭐ |
+| D. 保持现状 | 简单 | - | ⭐⭐⭐⭐⭐ |
+
+**结论：** 保持现状，当前连接数不是瓶颈
+
+### 3.3 大文件/长文本处理
+
+**现状：** Token 估算和压缩已迁移到 Rust 后端
+
+**可优化点：**
+- 流式 token 计数
+- 增量压缩
+- 智能摘要生成
+
+**结论：** 当前实现已满足需求，持续观察
+
+---
+
+## 议题四：功能扩展方向
+
+### 4.1 移动端支持
+
+**评估：**
+
+| 方案 | 技术选型 | 工作量 | 推荐度 |
+|------|----------|--------|--------|
+| A. React Native | 跨平台 | 大 | ⭐⭐ |
+| B. Tauri Mobile | Tauri 生态 | 中 | ⭐⭐⭐⭐ |
+| C. Flutter | 独立生态 | 大 | ⭐⭐ |
+| D. 暂不开发 | - | - | ⭐⭐⭐⭐⭐ |
+
+**结论：** 评估 Tauri Mobile，但优先级低于核心功能
+
+### 4.2 国际化 (i18n)
+
+**现状：** 中文优先，但硬编码字符串存在
+
+**方案：**
+```typescript
+// 使用 react-i18next
+i18n.t('chat.placeholder')
+i18n.t('hand.trigger', { name })
+```
+
+**工作量：** 约 1-2 周
+
+**结论：** 建议在下一版本规划中纳入
+
+### 4.3 更多 Channel 集成
+
+**当前：** 飞书 (Feishu)
+
+**可扩展：**
+
+| Channel | 需求度 | 技术难度 | 优先级 |
+|---------|--------|----------|--------|
+| 企业微信 | 高 | 高 | 中 |
+| 钉钉 | 中 | 高 | 低 |
+| Discord | 中 | 中 | 中 |
+| Telegram | 低 | 低 | 中 |
+
+**结论：** 优先完善飞书集成，评估 Discord
+
+### 4.4 插件市场
+
+**现状：** 3 个插件 (chinese-models, feishu, ui)
+
+**方案：**
+
+| 阶段 | 内容 | 工作量 |
+|------|------|--------|
+| Phase 1 | 插件市场 UI + 基础 API | 1 周 |
+| Phase 2 | 插件审核机制 | 1 周 |
+| Phase 3 | 付费插件支持 | 2 周 |
+
+**结论：** 作为差异化竞争力，纳入中期规划
+
+---
+
+## 议题五：风险规避方向
+
+### 5.1 ZCLAW 兼容性维护
+
+**风险：** ZCLAW 版本升级可能导致兼容性问题
+
+**方案：**
+
+| 方案 | 实施难度 | 保护程度 |
+|------|----------|----------|
+| A. 版本锁定 | 低 | 弱 |
+| B. 兼容层抽象 | 中 | 中 |
+| C. 自动化兼容性测试 | 高 | 强 |
+| D. 参与 ZCLAW 开发 | 高 | 最强 |
+
+**结论：** 实施 B + C，建立兼容性测试套件
+
+### 5.2 敏感数据保护
+
+**现状：** API Key 使用 OS Keyring，但聊天记录未加密
+
+**改进方案：**
+
+| 敏感数据 | 当前存储 | 建议存储 | 优先级 |
+|----------|----------|----------|--------|
+| API Key | OS Keyring ✅ | 保持 | - |
+| Gateway Token | OS Keyring ✅ | 保持 | - |
+| 聊天记录 | SQLite | 加密存储 | P1 |
+| Theme | localStorage | 保持 | 低 |
+
+**结论：** 聊天记录加密纳入安全增强计划
+
+### 5.3 灰度发布机制
+
+**现状：** 无灰度发布
+
+**方案：**
+
+| 方案 | 工具 | 工作量 |
+|------|------|--------|
+| A. Tauri 内置更新 | tauri-plugin-updater | 1 天 |
+| B. 手动版本管理 | - | 0 |
+| C. 自动化灰度 | 定制开发 | 1 周 |
+
+**结论：** 集成 Tauri 内置更新机制
+
+---
+
+## 议题六：创新解决方案
+
+### 6.1 AI Native 特性增强
+
+**想法：**
+
+| 特性 | 描述 | 创新度 |
+|------|------|--------|
+| 自适应上下文 | 根据任务类型自动调整上下文长度 | ⭐⭐⭐ |
+| 智能缓存 | 预测用户意图，预加载资源 | ⭐⭐⭐ |
+| 多模态交互 | 支持图片、语音输入 | ⭐⭐ |
+| 主动建议 | 基于上下文主动提供建议 | ⭐⭐⭐⭐ |
+
+**结论：** 优先实现"主动建议"作为差异化功能
+
+### 6.2 本地知识图谱构建
+
+**想法：**
+- 将记忆系统升级为知识图谱
+- 实体关系挖掘
+- 语义推理能力
+
+**技术路径：**
+```rust
+// 实体提取
+struct Entity {
+    name: String,
+    type: EntityType,
+    properties: HashMap<String, Value>,
+}
+
+// 关系链接
+struct Relation {
+    from: EntityId,
+    to: EntityId,
+    relation_type: String,
+    confidence: f32,
+}
+```
+
+**结论：** 长期规划，与 OpenViking 深度集成
+
+### 6.3 跨设备状态同步
+
+**问题：** 当前数据仅本地存储
+
+**方案：**
+
+| 方案 | 复杂度 | 隐私性 | 推荐度 |
+|------|--------|--------|--------|
+| A. 云端同步 | 高 | 低 | ⭐⭐ |
+| B. 端到端加密同步 | 高 | 高 | ⭐⭐⭐⭐ |
+| C. 文件导入/导出 | 低 | 最高 | ⭐⭐⭐⭐ |
+| D. 保持本地优先 | - | - | ⭐⭐⭐⭐⭐ |
+
+**结论：** 提供端到端加密同步作为 Pro 功能
+
+### 6.4 隐私计算集成
+
+**想法：**
+- 本地模型推理（Llama.cpp 集成）
+- 联邦学习支持
+- 数据不出本机
+
+**结论：** 长期愿景，需要大量研发投入
+
+---
+
+## 行动建议总结
+
+### 短期行动（1-2 周）
+
+| # | 行动 | 优先级 | 负责人 | 工作量 |
+|---|------|--------|--------|--------|
+| 1 | E2E 测试稳定性修复 | P0 | 测试团队 | 2-3 人天 |
+| 2 | gateway-client.ts 拆分 | P1 | 前端团队 | 2-3 人天 |
+| 3 | Rust unwrap() 替换 | P1 | 后端团队 | 0.5 人天 |
+
+### 中期行动（1-2 月）
+
+| # | 行动 | 优先级 | 工作量 |
+|---|------|--------|--------|
+| 4 | 聊天记录加密 | P1 | 1 周 |
+| 5 | 插件市场 MVP | P2 | 1 周 |
+| 6 | i18n 支持 | P2 | 1-2 周 |
+| 7 | 兼容性测试套件 | P1 | 1 周 |
+| 8 | 性能优化 (re-render) | P2 | 2-3 人天 |
+
+### 长期愿景（6 月+）
+
+| # | 行动 | 优先级 |
+|---|------|--------|
+| 9 | 本地知识图谱 | P3 |
+| 10 | 端到端加密同步 | P3 |
+| 11 | Tauri Mobile 支持 | P3 |
+| 12 | 主动建议能力 | P2 |
+
+---
+
+## 会议结论
+
+1. **架构优化优先** - gateway-client.ts 拆分是短期最高优先级
+2. **稳定性优先** - E2E 测试修复和兼容性测试是 P0
+3. **保持专注** - 不追求功能数量，聚焦核心体验
+4. **隐私优先** - 本地优先策略，用户数据不强制上云
+5. **渐进改进** - 避免大规模重构，采用渐进式优化
+
+---
+
+## 关键决策记录
+
+| 决策项 | 决策结果 | 理由 |
+|--------|----------|------|
+| 前后端职责划分 | 渐进迁移 | 平衡工作量和收益 |
+| 状态管理 | 保持 Zustand 5 | 聚焦功能开发 |
+| 移动端 | 暂不开发 | 优先级低于核心功能 |
+| 国际化 | 下一版本纳入 | 1-2 周工作量 |
+| 聊天记录 | 加密存储 | 保护用户隐私 |
+| 跨设备同步 | Pro 功能 | 端到端加密 |
+
+---
+
+*会议纪要完成*

docs/brainstorming/2026-04-07-第一轮发散探讨-产品愿景.md

@@ -0,0 +1,395 @@
+# ZCLAW 发散式头脑风暴记录
+
+> 日期: 2026-04-07
+> 状态: 进行中
+> 待归档至: docs/ 或 memory 系统
+
+---
+
+## 1. 项目起源与核心哲学
+
+### 1.1 OpenClaw 的启发
+
+ZCLAW 诞生的起点是 **OpenClaw 的人格系统**。其核心吸引力在于：
+
+- AI 不只是工具，而是**伙伴** — 能一起成长
+- 能**主动检讨**并学习，从而为用户解决问题
+- 长期相处中建立信任感和默契
+
+### 1.2 能力融合路径
+
+在 OpenClaw 基础上，吸收了三个系统的特长：
+
+| 来源 | 借鉴内容 |
+|------|---------|
+| **OpenFang** | Hands 自主能力体系 + 安全性设计 |
+| **OpenMaic** | 教育类专项技能 |
+| **DeerFlow 2.0** | 架构模式（clarification、渐进式加载、sub-agent） |
+
+### 1.3 终极目标
+
+**打造一个能解决用户任何问题的管家式系统。**
+
+---
+
+## 2. 产品定位：与市场差异化
+
+### 2.1 核心差异
+
+| 维度 | 市面 Claw 系统 | ZCLAW |
+|------|---------------|-------|
+| 用户画像 | 开发者、技术爱好者 | **非编程用户、不擅长用电脑的人** |
+| 交互模型 | 选模型、配参数、写 Prompt | **只管说，我来理解和执行** |
+| AI 角色 | 工具/助手 | **伙伴 — 会成长、会反思、会主动** |
+| 能力边界 | 用户能描述清楚的范围内 | **用户说不清楚的，也要想办法解决** |
+
+### 2.2 行业模板 + 潮汕特色产业
+
+SaaS Admin 端预设了行业 Agent 模板，聚焦潮汕地区特色产业：
+
+- **玩具** — 澄海"玩具之都"，全球供应
+- **制衣** — 潮汕纺织服装集群
+- **医疗** — 汕头医疗器械产业带
+- **教育** — 潮汕教育传统
+
+**目的**：不是给用户一个空白 AI，而是给一个"已经入行多年的学徒"。
+
+---
+
+## 3. 三层知识模型
+
+```
+┌─────────────────────────────────┐
+│  Layer 3: 用户独有记忆            │  ← 对话、操作、偏好、习惯
+│  （私有、不可共享、真正的差异点）    │     主要成长来源
+├─────────────────────────────────┤
+│  Layer 2: 行业知识库              │  ← 系统持续采集丰富
+│  （共享、持续丰富、运营驱动）        │     同行业 Agent 共享
+├─────────────────────────────────┤
+│  Layer 1: 行业模板                │  ← 预装基础能力、工作流、话术
+│  （共享、相对稳定、冷启动用）        │     冷启动起点
+└─────────────────────────────────┘
+```
+
+**成长模型**：
+- 模板是起点（Layer 1）
+- 系统持续丰富行业知识库（Layer 2）
+- **主要成长来自用户自己的对话和操作积累**（Layer 3）
+- 每个用户的 Agent 最终长得不一样
+
+---
+
+## 4. "成长时刻"的定义
+
+### 4.1 核心理念
+
+> **产品的价值体现于它能为用户解决多大的问题。**
+
+"成长时刻" = **Agent 主动发现行业痛点，制定解决方案并交付**。
+
+### 4.2 四层能力模型
+
+| 层次 | 表现 | 性质 | 示例 |
+|------|------|------|------|
+| L1 回答 | "CE 认证需要哪些材料？" | 百科全书 | 被动回答 |
+| L2 提醒 | "下周五要做 CE 检测了" | 秘书 | 基于日历/规则 |
+| L3 执行 | "我帮你填好了 CE 申请表" | 助理 | 代办事务 |
+| **L4 管家** | **"分析了 3 批退货原因，核心是包装合规。拟了新规范 + 供应商方案"** | **伙伴** | **主动发现 + 方案制造** |
+
+**ZCLAW 的目标是 L4。**
+
+### 4.3 触发方式：静默分析 + 主动推送
+
+- Agent 在后台**持续分析**用户数据和行业动态
+- 发现问题后**主动推送**解决方案
+- 不等用户提问，不等用户触发
+
+### 4.4 信任建立：全开 + 透明日志
+
+- **从第一天就全部能力开启**
+- 用户可以看到 Agent 在分析什么、怎么分析的
+- 信任来源于**透明**，而非渐进式引导
+
+**关键体验**：每个主动推送的洞察，都能追溯到用户自己的某次操作或对话：
+- "这个想法来自：您 3/7 提到'这批货又迟了' + 3/15 问了广州仓库租金 + 近 3 个月物流费用明细"
+
+### 4.5 痛点识别引擎：方案 A（LLM 自分析）
+
+**选择理由**：方案 B（规则筛选）需要行业专家定义规则，无人能保证规则质量，会降低体验。
+
+**流程设计**：
+
+```
+用户对话 → 对话结束 → LLM 自分析（Haiku，低成本）
+  "刚才的对话里，用户有没有遇到反复出现的困难？"
+    ↓ 有 → 存入 PainPoint 记忆
+    ↓
+  后台定期聚合同类 PainPoint，计次
+    ↓ 累积到阈值 → Sonnet 生成方案 → 推送给用户
+```
+
+**成本控制**：
+- 痛点分析用 Haiku（便宜 3x）
+- 跨会话聚合用 Haiku
+- 只在"生成方案"时用 Sonnet
+- 整体成本与方案 B 相当，但无需人工维护规则
+
+**行业模板的角色转变**：
+- 不再是"预定义痛点规则"
+- 而是"提供行业知识背景"，让 LLM 更懂这个行业的上下文
+
+---
+
+## 5. OpenViking：被忽视的 L4 基石
+
+### 5.1 已有能力清单
+
+OpenViking 记忆系统已经具备大量 L4 管家所需的基础能力：
+
+| L4 需求 | OpenViking 模块 | 说明 |
+|---------|----------------|------|
+| 对话记忆提取 | `memory/extractor.rs` | LLM 驱动，自动从对话中提取关键信息 |
+| 语义搜索 | `viking_find` + FTS5 + TF-IDF + embedding | 混合检索，70% embedding + 30% TF-IDF |
+| 上下文分层 | `context_builder.rs` | L0 概览 / L1 摘要 / L2 全文，token 预算控制 |
+| 记忆注入 | `injector.rs` + `viking_inject_prompt` | 将相关记忆注入 system prompt |
+| 自我反思 | `intelligence/reflection.rs` | Agent 自我反思引擎 |
+| 主动心跳 | `intelligence/heartbeat.rs` | 主动心跳引擎 |
+| 上下文压缩 | `intelligence/compactor.rs` | 长对话压缩 + 记忆刷出 |
+| 对话钩子 | `intelligence_hooks.rs` | 对话前后集成钩子 |
+| UI | `VikingPanel.tsx` | 语义记忆浏览面板 |
+
+URI 命名空间：`viking://user/memories/...` + `viking://agent/{id}/memories/...`
+存储：SQLite + FTS5 + TF-IDF
+记忆类型：Preference / Knowledge / Experience / Session
+
+### 5.2 关键认知修正
+
+之前的差距分析有误。L4 不是"从零建"，而是"激活已有基础 + 补最后公里"。
+
+**真正的差距**：
+- ~~痛点识别引擎~~ → reflection + extractor 已有，缺的是"痛点聚合 + 置信度评分"层
+- ~~透明推理链~~ → viking:// URI 已有溯源能力，缺的是"面向用户的白话解释"UI
+- ~~方案生成器~~ → Pipeline DSL + 技能路由已有，缺的是"痛点 → 方案"的自动编排
+- ~~主动推送~~ → heartbeat 已有基础设施，缺的是"推送时机决策"逻辑
+
+### 5.3 反思：为什么 OpenViking 没被充分利用
+
+这个问题值得深入思考。可能的原因：
+1. 模块存在但未被端到端打通
+2. reflection/heartbeat 能力存在但使用场景不够具体
+3. 记忆提取在运行但"提炼痛点"这一步没有闭环
+
+---
+
+## 6. 核心结论：L4 路径是"激活"而非"新建"
+
+### 6.1 诊断
+
+ZCLAW 的核心问题不是"缺什么模块"，而是"已有模块到底在不在工作"。
+
+项目存在一个反复出现的模式：**代码写了、能力定义了，但"写完 → 跑通 → 用户能感知到"这条链路经常断在最后一截。**
+
+- OpenViking 有 extractor/reflection/heartbeat/compactor — 不确定实际运行状态
+- 131 个 SaaS API — 前端未全部接通
+- 177 个 Tauri 命令 — 16 个 reserved
+- 75 个 SKILL.md — 大部分未做执行验证
+
+### 6.2 优先级修正
+
+之前的差距分析 → 修正后的优先级：
+
+| 之前以为的 | 修正后 |
+|-----------|--------|
+| 新建痛点识别引擎 | **验证 reflection.rs 是否在跑** |
+| 新建透明推理链 UI | **验证 extractor 输出是否能被用户看到** |
+| 新建方案生成器 | **验证 heartbeat 是否能触发推送** |
+| 新建主动推送基础设施 | **验证现有 heartbeat → inject → prompt 链路** |
+
+**第一步：端到端跑通 OpenViking 已有能力，确认哪些是活的、哪些是壳。**
+
+### 6.3 与稳定化阶段的一脉相承
+
+这个判断与已完成的稳定化工作完全一致：
+- Sprint 1-2：P0 修复 + 断链接通
+- Batch 5：GrowthIntegration 桥接
+- V12 审计：模块化审计 + @reserved 标注
+- 死代码清理：Automation/SkillMarket 删除
+
+L4 激活是这个方向的延续 — 不是新的建设阶段，而是**对已有投资的兑现**。
+
+---
+
+## 7. 技能市场悖论 — 结论
+
+**技能完全隐式。** SkillMarket 删除是正确决定。
+
+- 75 个 SKILL.md 定位为 AI 的内部能力图，不是用户的商品目录
+- 用户只感知"我说了需求 → 管家帮我搞定了"
+- 技能选择由 AI 语义路由自动完成
+- 管家面板不展示"技能列表"，而是展示"我帮你做了什么"
+
+## 8. Multi-agent — 结论
+
+**管家调度专家模式，尽快接通。**
+
+- 主 Agent（管家）是用户唯一对话的入口
+- 管家拆解复杂任务，分派给专家 Agent 并行执行
+- 专家 Agent 可以有独立的上下文窗口，深入各自领域
+- 用户感知不到 Multi-agent 的存在，只感知到"管家帮我搞定了"
+
+已有多 agent 资产：
+- 912 行 Director 代码（feature-gated）
+- sub-agent ID 匹配（已修复）
+- 行业 Agent 模板 → 可作为专家 Agent 的基础
+- OpenViking → 每个专家可以有独立记忆上下文
+
+## 9. 桌面端 vs SaaS — 结论
+
+**后勤部模式：三层服务架构。**
+
+```
+Layer 1: 运营层 (SaaS + Admin)
+  → 运营团队使用，管理行业知识库、模板、用户账户
+Layer 2: 管家层 (桌面端 Agent)
+  → 用户的私人管家，对话交互，技能隐式路由，Multi-agent 调度
+Layer 3: 用户层 (对话界面)
+  → 零门槛，零配置，只有聊天
+```
+
+SaaS 的 131 API 不需要全部被桌面端接通。
+桌面端只需接通：获取行业知识、同步模板、上报使用数据等关键接口。
+
+## 10. 非技术用户交互 — 结论
+
+**聊天窗口 + 管家面板。**
+
+聊天窗口是用户的主世界，管家面板是透明日志的 UI 化：
+
+管家面板内容：
+- 🧠 我最近在关注（主动发现的痛点 + 推理链）
+- 💡 我提出的方案（方案追踪、采纳状态）
+- 📝 我记得关于您（用户偏好、习惯、事实）
+
+管家面板不是设置页面，是"管家的工作台公开给用户看"。
+
+---
+
+## 11. 综合产品蓝图
+
+将所有讨论串成一个完整画面：
+
+```
+用户视角（非技术用户）:
+  打开 ZCLAW → 跟管家聊天 → 管家帮我搞定一切
+  偶尔打开管家面板 → 看看管家在关注什么、记住了什么
+
+管家内部（用户看不到）:
+  接收用户消息
+    → LLM 理解意图
+    → 语义路由到 75 个技能中的合适能力
+    → 复杂任务拆解 → 调度多个专家 Agent 并行
+    → OpenViking 记忆系统持续提取、反思、聚合
+    → 发现痛点 → 生成方案 → 推送给用户
+
+运营层（运营团队）:
+  Admin 后台更新行业知识库和模板
+    → SaaS 存储 → 同步到桌面端
+    → 管家获得新知识，不中断用户使用
+```
+
+三层知识模型 + 四层能力模型 + 三层服务架构，构成 ZCLAW 的完整产品 DNA。
+
+### 补充：LLM 供给架构
+
+**桌面端用户不使用本地 LLM，而是通过 SaaS 的 Token 池获取大模型能力。**
+
+```
+用户订阅 Plan（如 coding plan）
+  → SaaS 后端分配 Token 额度 + 配置可用模型
+    → 桌面端通过 SaaS API 调用大模型
+      → 不同厂家（OpenAI/Anthropic/Doubao/...）的模型统一通过 SaaS 路由
+
+用户端：零配置，打开就能用
+运营端：通过 Admin 管理 Token 池、模型配额、定价方案
+```
+
+这意味着：
+1. 用户不需要知道"模型"是什么概念 — 管家自动选择最合适的模型
+2. SaaS 后端承担模型路由、Token 计费、配额管理的职责
+3. 桌面端的"模型配置"UI 对普通用户应该隐藏，只对高级/开发者用户可见
+4. Token 池是核心商业模式 — 用户为"管家能力"付费，不是为"模型调用量"付费
+
+---
+
+## 12. 冷启动体验 — 结论
+
+**行业剧本预设：Admin 后台配置每个行业模板的冷启动流程。**
+
+- 管家开场白（行业定制）
+- 引导问题列表（快速了解用户具体业务）
+- 行业热点话题（展示"我懂你的行业"）
+- 用户回答存入 OpenViking → 即时个性化
+- 冷启动质量可运营：运营团队持续迭代剧本
+
+## 13. 管家人格 + 反馈闭环 — 结论
+
+**可配置人格：运营定基线，用户通过自然对话塑造。**
+
+Admin 配置：tone（语气）、proactiveness（主动性）、formality（正式度）、humor（幽默度）
+用户微调：通过对话自然发生（"别叫我王总了"→ formality 自动降低）
+
+反馈闭环设计：
+
+| 用户反应 | 管家行为 | 存入 OpenViking |
+|---------|---------|----------------|
+| "你说得不对" | 承认错误 + 请用户纠正 | lessons_learned |
+| "我不是这个意思" | 重新理解 + 确认 | patterns（修正偏好） |
+| "别再提这个了" | 立即停止 | preferences（排除项） |
+| "上次那个方案很好" | 强化权重 | lessons_learned（正向） |
+
+关键：管家的学习要"说出来" — "我记下来了，以后不会搞混了"。
+强化伙伴感：用户知道管家在听、在学、在改。
+
+## 14. 数据安全 + 离线 — 结论
+
+**强化安全路线，核心能力：数据脱敏令牌化（Data Tokenization）。**
+
+### 14.1 数据脱敏
+
+在中间件链中新增 `DataMaskingMiddleware`：
+
+```
+用户消息 → 脱敏（本地） → LLM（脱敏数据） → 还原（本地） → 用户看到
+例: "A公司" → "company_00234" → LLM 处理 → "A公司"
+```
+
+- 令牌映射表存在本地 OpenViking，永远不上传
+- SaaS 和 LLM 提供商只能看到脱敏后的数据
+- 产品承诺："你的商业数据永远不会离开你的电脑"
+- **这是核心产品差异化**
+
+### 14.2 离线模式
+
+- 离线时管家不可用（不能调用 LLM）
+- 所有本地数据可查看：历史对话、管家面板、记忆、方案
+- OpenViking 本地数据加密存储
+
+### 14.3 安全架构总结
+
+| 数据类型 | 存储位置 | 安全措施 |
+|---------|---------|---------|
+| 对话内容 | SaaS 中转 | 脱敏后传输，不留存原文 |
+| OpenViking 记忆 | 本地 SQLite | 加密存储，不上传 |
+| PainPoint 洞察 | 本地 OpenViking | 最敏感，脱敏 + 加密 |
+| 令牌映射表 | 本地 OpenViking | 永远不上传 |
+| 行业知识库 | SaaS PostgreSQL | 运营数据，正常管理 |
+
+---
+
+## 15. 后续行动
+
+- [ ] 归档讨论成果至 memory 系统
+- [ ] 可能产出：OpenViking 端到端验证计划
+- [ ] 可能产出：L4 激活路线图
+- [ ] 可能产出：DataMaskingMiddleware 设计文档
+- [ ] 可能产出：冷启动剧本模板设计

docs/brainstorming/2026-04-07-第二轮发散探讨-产品策略与架构.md

@@ -0,0 +1,407 @@
+# ZCLAW 发散式探讨（第二轮）— 一件事 / 商业化 / 技术架构
+
+> 日期: 2026-04-07
+> 形式: 无主题发散式互动探讨
+> 参与者: iven + Claude
+
+---
+
+## 议题一：管家 vs 工具的边界在哪里？
+
+### 抛砖
+
+ZCLAW 定位"主动管家"，但 AI 桌面端大多退化为"高级搜索框"。什么条件下用户会真的把决策权交给 AI？
+
+### 讨论
+
+**三阶梯框架：**
+
+| 阶梯 | 行为 | 信任要求 | 例子 |
+|------|------|----------|------|
+| 响应式 | 用户问，AI 答 | 无需信任 | ChatGPT |
+| 建议式 | AI 主动发现，建议方案 | 用户觉得"有道理" | Copilot 建议 |
+| 代理式 | AI 直接做了，事后通知 | 用户觉得"比我做得好" | 自动下单 |
+
+**共识：ZCLAW 停在建议式。**
+
+关键洞察（iven）：
+- 代理式涉及钱款决策时，出了问题用户会要求系统厂家赔偿
+- 这不是技术问题，是**风险边界**
+- AI 帮用户做前期工作（调研、对比、整理）是甜区 — 降低执行成本但决策权在用户
+
+**设计含义：**
+- 管家的"主动性"体现在**发现问题和准备方案**，不是替用户做决定
+- 涉及钱、合同、对外承诺的操作，必须是"帮你准备好，你确认才执行"
+- 这个原则应该是产品级约束，写进系统 prompt
+
+---
+
+## 议题二："零门槛"是伪命题吗？
+
+### 抛砖
+
+目标用户是非编程的潮汕工厂老板。配置 API Key、选择 LLM Provider 已经是门槛。SaaS Token 池解决了技术门槛，认知门槛呢？
+
+### 讨论
+
+**三层门槛分析：**
+
+| 层级 | 问题 | 状态 |
+|------|------|------|
+| 技术门槛 | API Key、Provider 概念 | ✅ SaaS Token 池基本解决 |
+| 认知门槛 | "我能问什么？"空聊天框恐惧 | 🚧 行业剧本冷启动可缓解 |
+| 场景门槛 | "我什么时候该打开它？"习惯未建立 | ❌ 真正的杀手 |
+
+**共识：培养习惯是零门槛的核心策略。**
+
+iven 的洞察：
+- 系统成熟发布后接入 QQ/微信 — 在用户已有的沟通工具里触达
+- **每日定时推送（如早上9点）**：昨日工作总结 + 最新行业动态
+- 逻辑是先用**被动接收**培养习惯，用户发现"确实有帮助"后自然会主动使用，频次随之增长
+- 这本质上是把"场景门槛"倒过来 — 不是用户找场景，而是**场景找用户**
+
+**设计含义：**
+- 早上9点推送是一个"锚定时刻" — 让用户每天至少跟 ZCLAW 产生一次接触
+- 推送内容必须是**跟用户行业直接相关的**（不是泛新闻），才有打开的价值
+- 接入微信/QQ 是分发渠道，桌面端是深度交互场所，两者定位不同
+- 习惯养成路径：被动接收 → 觉得有用 → 主动提问 → 深度依赖
+
+---
+
+## 议题三：记忆系统是护城河还是负担？
+
+### 抛砖
+
+OpenViking 5,252 行记忆代码，记忆越积越多 — 隐私焦虑、存储膨胀、回忆噪声。如何让用户感到被记住但不感到被监视？
+
+### 讨论
+
+**记忆的双刃剑：**
+
+| 维度 | 护城河 | 负担 |
+|------|--------|------|
+| 竞争 | 用户用了三个月，AI 懂他的业务，换竞品成本极高 | — |
+| 信任 | — | 记忆越精确，用户越不安（"它怎么知道我表弟？"） |
+| 技术 | — | 存储无限增长，回忆噪声淹没信号 |
+
+**共识：沿用上次讨论的管家面板设计，不过度设计。发布后根据用户反馈迭代。**
+
+iven 的洞察：
+- 管家面板已经设计好了（VikingPanel），不需要在这个阶段加码
+- 透明度的具体形态（面板 vs 对话中自然说出 vs 其他）应该由**用户反馈**决定
+- 过早优化记忆展示 = 过度设计，跟项目"稳定化"原则一致
+
+**设计含义：**
+- 当前记忆系统（OpenViking）专注把管线接通，让记忆真正可用
+- 管家面板作为已有的透明机制，先上线最小版本
+- 隐私焦虑的解法：发布后观察用户行为，数据驱动迭代
+
+---
+
+## 综合结论
+
+三个议题串成了一条清晰的产品线：
+
+```
+建议式管家（边界）→ 每日推送培养习惯（零门槛）→ 记忆驱动个性化（护城河）
+```
+
+**核心产品原则：**
+
+1. **建议不代理** — 主动发现 + 准备方案，决策权永远在用户。涉及钱/合同/对外承诺必须用户确认
+2. **场景找用户** — 早9点推送是锚定时刻，微信/QQ是分发渠道，桌面端是深度交互场所
+3. **先跑再调** — 不过度设计，管家面板用已有设计，记忆透明度等用户反馈
+4. **反馈驱动迭代** — 所有产品决策在发布后用真实数据验证，不靠想象力
+
+**对当前开发的影响：**
+- L4 管家激活计划的方向确认正确 — 建议式、透明化、不过度设计
+- 每日推送功能是发布后的高优先级特性（需要行业信息源 + 定时调度）
+- 微信/QQ 接入是分发层规划，不影响当前桌面端架构
+
+---
+
+## 议题四：如果 ZCLAW 只做一件事，那件事是什么？
+
+### 抛砖
+
+砍掉所有 Hands、Skills、Pipeline、Multi-agent，只留一个核心功能。是什么？为什么？
+
+### 讨论
+
+**ZCLAW 的灵魂 = 成长性的问题解决者**
+
+能力三角（缺一不可）：
+
+```
+发现问题（眼睛）→ 解决问题（手）→ 越来越擅长（成长）
+```
+
+| 角色 | 系统能力 | 砍掉的后果 |
+|------|----------|-----------|
+| 发现 | 早推送、痛点聚合、行业动态 | 退化为等指令的工具 |
+| 解决 | Hands、Skills、Pipeline | 退化为高级新闻推送 |
+| 成长 | OpenViking 记忆、reflection | 每次都从零开始，无差异化 |
+
+iven 的关键纠正：
+- 砍掉 Hands/Skills/Pipeline，管家就没有处理问题的能力
+- "只做一件事"不是砍功能，而是所有功能都服务于同一个灵魂：**帮你解决行业问题，而且一次比一次好**
+- 早推送是发现，Hands/Skills/Pipeline 是解决，OpenViking 是成长 — 不是插件，是同一能力的三个面
+
+**一句话定义：帮你解决你行业里的问题，而且一次比一次做得好。**
+
+---
+
+## 议题五：商业化路径
+
+### 抛砖
+
+Token 池是核心商业模式。但 SaaS 层 93 个 API、13 个 admin 页面 — 运营成本不低。如何找到 PMF（Product-Market Fit）？
+
+### 讨论
+
+**商业定位：小而美**
+
+iven 的选择：不需要融资，养活小团队，几百个付费用户，每个高客单价，靠口碑慢慢涨。
+
+**对比分析：**
+
+| 维度 | 规模化 SaaS | 小而美（ZCLAW 选择） |
+|------|------------|---------------------|
+| 目标用户 | 尽可能多 | 潮汕制造业（玩具、制衣）、医院行政领导、教师 |
+| 定价 | 低价月费（¥29-99） | 高客单价（¥299-999/月） |
+| 获客 | 线上投放 | 地推、老乡圈、口碑 |
+| 竞争壁垒 | 功能多、价格低 | 懂行业 + 记住业务 |
+| Token 池 | 用量计费，低价走量 | 包含在客单价中，用户无感 |
+
+**商业化的核心飞轮：**
+
+```
+行业深耕 → 独家知识库（L2） → 推送/建议越精准 → 用户越依赖 → 续费率越高
+```
+
+**关键洞察：**
+- 小而美不需要 93 个 API 什么都做，需要的是**一个行业做透**
+- 获客靠人脉和口碑，不是线上流量 — 这跟潮汕商业文化天然匹配
+- 几百个深度用户的记忆积累，本身就是数据资产 — 未来可以反向强化行业知识库
+- Token 池的成本由 SaaS 层统一管控，用户不感知底层模型细节
+
+---
+
+## 议题六：技术架构演进 — 资产 vs 负担筛选
+
+### 全景数据
+
+| 维度 | 数量 |
+|------|------|
+| Rust crates | 10（+ desktop + zclaw-saas） |
+| Rust 总代码量 | ~83K 行 |
+| Tauri 命令（已注册） | 130 |
+| Tauri 命令（有前端调用） | 92 |
+| Tauri 命令（无前端调用） | 38 |
+| SaaS API 端点 | 140 |
+| 前端 Store 文件 | 19（8,349 行） |
+| Admin 页面 | 17 路由（14 组件） |
+
+### 逐项筛选清单
+
+> 标记：✅ 资产 | ⚠️ 待讨论 | ❌ 负担 | 🔒 冻结
+
+---
+
+#### A. Rust Crates（10 个）
+
+| # | Crate | 行数 | 初步判断 | 理由 |
+|---|-------|------|----------|------|
+| 1 | zclaw-types | 1,789 | ✅ 资产 | 全链路依赖 |
+| 2 | zclaw-memory | 1,427 | ✅ 资产 | 记忆基础 |
+| 3 | zclaw-growth | 4,926 | ✅ 资产 | 护城河核心 |
+| 4 | zclaw-protocols | 2,063 | ⚠️ MCP✅ / A2A🔒 | A2A 短期不用 |
+| 5 | zclaw-skills | 4,411 | ✅ 资产 | 技能系统 |
+| 6 | zclaw-runtime | 9,653 | ✅ 资产 | LLM + Agent Loop 核心 |
+| 7 | zclaw-hands | 7,548 | ✅ 资产 | 解决问题的"手" |
+| 8 | zclaw-kernel | 9,051 | ✅ 资产 | 中枢，multi-agent 部分 🔒 |
+| 9 | zclaw-pipeline | 7,522 | ⚠️ 待讨论 | 行业模板有用，但复杂度高 |
+| 10 | zclaw-saas | 17,291 | ⚠️ 待讨论 | 140 API，小而美用不了这么多 |
+
+---
+
+#### B. Tauri 无前端调用命令（38 个，按模块分组）
+
+| 模块 | 无调用数 | 初步判断 | 理由 |
+|------|---------|----------|------|
+| gateway/commands.rs | 11 | ⚠️ | Kernel 模式下是否还需要 Gateway？ |
+| viking_commands | 11 | ⚠️ | intelligence-backend 已间接调用？ |
+| memory/embedding | 2 | ⚠️ | 内部使用 |
+| llm/ 直接调用 | 3 | ⚠️ | kernel 层内部使用 |
+| pipeline_commands | 11 | ⚠️ | workflowStore 有 invoke？需确认 |
+| classroom_commands | 5 | ❌ 负担 | 教育场景，非目标 |
+| butler/pain_aggregator | 5 | ⚠️ | L4 管家即将接通 |
+| trigger/approval/mcp | 8 | ⚠️ | 核心但前端未接 |
+| skill/agent CRUD | 3 | ⚠️ | configStore 间接调用？ |
+
+---
+
+#### C. SaaS API 端点（140 个，按模块分组）
+
+| 模块 | 端点数 | 初步判断 | 小而美需要？ |
+|------|--------|----------|-------------|
+| auth | 11 | ✅ | 必须 |
+| account/device | 12 | ✅ | 必须 |
+| relay | 9 | ✅ | Token 池核心 |
+| billing | 8 | ✅ | 商业化 |
+| agent_template | 11 | ✅ | 冷启动 |
+| scheduled_tasks | 5 | ✅ | 每日推送 |
+| health | 1 | ✅ | 必须 |
+| prompts | 10 | ✅ | 管家人格 |
+| knowledge | 23 | ⚠️ 待讨论 | 有用但 23 个太多 |
+| model_config | 23 | ⚠️ 待讨论 | 小而美用不了 23 个 |
+| config_sync | 11 | ⚠️ 待讨论 | 可能过度 |
+| telemetry | 4 | ⚠️ 待讨论 | 看需求 |
+| roles/permissions | 11 | ❌ 负担 | 几百用户不需要 RBAC |
+| migration | 11 | ⚠️ 待讨论 | 配置迁移 |
+
+---
+
+#### D. 前端 Store（19 个）
+
+| Store | 行数 | 初步判断 | 理由 |
+|-------|------|----------|------|
+| connectionStore | 859 | ✅ | 连接核心 |
+| chat/streamStore | 724 | ✅ | 流式核心 |
+| saasStore | 893 | ✅ | SaaS 集成 |
+| configStore | 821 | ✅ | 配置核心 |
+| handStore | 722 | ✅ | Hands 管理 |
+| chat/conversationStore | 364 | ✅ | 会话管理 |
+| chatStore | 363 | ✅ | 聊天核心 |
+| offlineStore | 372 | ✅ | 离线支持 |
+| agentStore | 379 | ✅ | Agent 管理 |
+| browserHandStore | 519 | ✅ | 浏览器自动化 |
+| chat/messageStore | 98 | ✅ | Token 统计 |
+| chat/artifactStore | 54 | ✅ | 产物展示 |
+| index | 115 | ✅ | 协调器 |
+| workflowStore | 540 | ⚠️ | Pipeline UI |
+| workflowBuilderStore | 456 | ⚠️ | 可视化编辑器复杂度高 |
+| memoryGraphStore | 322 | ⚠️ | MVP 不需要可视化 |
+| securityStore | 286 | ⚠️ | 安全面板用户看不到 |
+| classroomStore | 234 | ❌ | 教育场景 |
+| sessionStore | 228 | ⚠️ | 与 Kernel 模式重叠 |
+
+---
+
+#### E. Admin 页面（14 组件）
+
+| 页面 | 初步判断 | 理由 |
+|------|----------|------|
+| Login | ✅ | 必须 |
+| Dashboard | ✅ | 必须 |
+| Accounts | ✅ | 必须 |
+| AgentTemplates | ✅ | 冷启动核心 |
+| Billing | ✅ | 商业化 |
+| Usage | ✅ | 用量追踪 |
+| Relay | ✅ | 中继监控 |
+| ScheduledTasks | ✅ | 每日推送 |
+| Knowledge | ✅ | 行业知识库 |
+| Prompts | ✅ | 管家人格 |
+| Providers/Models/ApiKeys | ⚠️ 4→2？ | 可能过度拆分 |
+| Roles | ❌ | RBAC 过度 |
+| Config | ⚠️ | 配置管理 |
+| ConfigSync | ⚠️ | 配置同步 |
+| Logs | ⚠️ | 操作日志 |
+
+---
+
+### 讨论决策区
+
+**关键修正（iven）：SaaS 是未来主入口，不是可瘦身的后端。**
+
+潮汕工厂老板设备优先级：**手机 >> 电脑**。最终形态是：
+```
+SaaS（中枢）→ 桌面端（深度交互）+ 微信/QQ（日常触达）
+```
+
+因此：
+- roles/permissions ✅ — 移动端多用户需要权限管理
+- config_sync ✅ — 桌面端与移动端数据同步
+- model_config ✅ — SaaS 统一管控模型供给
+- knowledge ✅ — 行业知识库是核心壁垒
+- 所有 SaaS 模块 → ✅ 资产（不瘦身，保持完整）
+
+#### 修正后的最终判断
+
+**Rust Crates：全部 ✅ 资产**
+
+| Crate | 最终判断 | 修正理由 |
+|-------|----------|----------|
+| zclaw-saas (17,291行) | ✅ 资产 | 未来主入口，140 端点面向多端 |
+| zclaw-pipeline (7,522行) | ✅ 资产 | 行业自动化模板，手机端也会触发 |
+
+**SaaS API：全部 ✅ 保留**
+
+| 模块 | 最终判断 | 修正理由 |
+|------|----------|----------|
+| roles/permissions | ✅ 保留 | 移动端多用户需要 |
+| config_sync | ✅ 保留 | 多端同步 |
+| model_config (23端点) | ✅ 保留 | SaaS 统一管控模型 |
+
+**前端 Store：classroomStore ❌ 是唯一确认的负担**
+
+| Store | 最终判断 |
+|-------|----------|
+| classroomStore | ❌ 教育场景，非目标行业 |
+
+**Admin 页面：全部 ✅ 保留**
+
+| 页面 | 最终判断 | 修正理由 |
+|------|----------|----------|
+| Roles | ✅ 保留 | 移动端用户管理需要 |
+| Providers/Models/ApiKeys | ✅ 保留 | 模型供给管理 |
+
+**核心结论：架构不是太重，是方向对了。小而美不等于功能少，等于用户少但每人用得深。**
+
+---
+
+## 第二轮综合结论
+
+### 六大共识
+
+| # | 共识 | 核心句 |
+|---|------|--------|
+| 1 | ZCLAW 灵魂 | **成长性的问题解决者** — 发现→解决→越来越擅长，三角缺一不可 |
+| 2 | 管家边界 | **建议不代理** — 主动发现+准备方案，决策权永远在用户，涉及钱/合同必须用户确认 |
+| 3 | 零门槛策略 | **场景找用户** — 早9点推送是锚定时刻，微信/QQ是分发渠道，习惯路径：被动→有用→主动→依赖 |
+| 4 | 商业定位 | **小而美** — 几百个高客单价用户，不融资，地推+口碑，一个行业做透 |
+| 5 | 记忆系统 | **沿用管家面板，不过度设计，发布后迭代** |
+| 6 | 架构判断 | **全部保留** — SaaS 是未来主入口（手机>电脑），小而美≠功能少=用户少但用得深 |
+
+### 产品方向一句话
+
+> 帮潮汕制造业老板解决行业问题，而且一次比一次做得好。
+
+### 架构最终形态
+
+```
+SaaS（中枢，140 API）→ 桌面端（深度交互）+ 微信/QQ（日常触达）
+                        ↑ 记忆/成长        ↑ 每日推送
+```
+
+### 唯一确认的负担
+
+- `classroomStore` — 教育场景，非目标行业
+
+### 待未来讨论的议题
+
+1. 冷启动前 10 个用户
+2. L2 行业知识库冷启动
+3. 管家人格方言/语气
+4. 定价模型
+5. 微信/QQ 技术选型
+6. LLM 成本控制
+7. 离线能力边界
+8. 数据飞轮闭环
+9. 竞品差异化
+10. 小团队运维极限
+
+---
+
+> 讨论归档于 2026-04-07。完整记录见本文件。
+> 记忆索引已更新。