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

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。完整记录见本文件。
+> 记忆索引已更新。