refactor(arch): 信息架构升级 — 三层四角色控制面板 + 跨平台 task 交接协议

核心变化：
- dashboard.md 替代 DASHBOARD + ROADMAP，人类+Arch AI 唯一入口
- DECISIONS.md 人类决策入口，≤3 条待决策
- .ai/tasks/ 14 个独立 task 文件（Coder 8 + Tester 6），弱模型自包含可独立执行
- 旧 today/queue 归档，每个角色启动 ≤2 个文件
- ADR-012 跨平台「高模型指挥小模型」协作架构落地
- 知识库补全：L-002~005、P-004~005、ADR-011~012
- Arch AI 上下文资源管理硬约束写入 principles.md

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

.ai/knowledge/decisions.md

@@ -112,3 +112,60 @@
   - `questions` 表 `source` 字段 = 适配器路由 key（`self_built` | `zuoyebang` | 未来扩展）
   - `external_id` 字段存储第三方题库的原始 ID，自有题库此字段为空
   - 健康检查: 每个适配器实现 `healthCheck()`，用于监控外部 API 可用性
+
+## ADR-011: 不急于引入多 Agent 编排层 —— 先精简，后分层
+
+- 日期: 2026-05-26
+- 状态: 已采纳
+- 决策: 当前阶段不引入正式的多 Agent 编排框架（MegaAgent 式 Boss-Admin-Worker 三层架构）。保留「1 人 + 3 AI」角色划分作为逻辑框架，但实际协作由 Claude Code 子 Agent 机制承载。先做 `.ai/` 配置精简（47 → ~20 文件），再评估是否需要模型分层
+- 理由:
+  - **规模不匹配**：当前是 1 人项目，不是 10 人团队。「编排层」就是人类 + Claude Code 本身，不需要额外的编排 Agent
+  - **行业共识未形成**：2025-2026 年业界分裂为两派——多 Agent 编排派（Anthropic/NUS/华为 openJiuwen）和单 Agent 上下文工程派（Cognition/Devin）。后者认为多 Agent 在编码领域是伪命题，隐性决策冲突和整合成本 > 并行收益。Anthropic 也部分承认「编码任务的可并行性远低于研究任务」
+  - **架构已是负担**：`.ai/` 47 个文件，Phase 2 代码一行没写。继续加架构层只会加重问题
+  - **子 Agent 甜蜜点已确认**：只读研究/探索是最有效的子 Agent 场景，并行编码效果不佳——这与我们当前的实际使用模式一致
+- 关键判断:
+  - **按业务上下文划分优于按角色划分**（来自 Microsoft 参考架构 + MegaAgent 实践）。如果未来引入多 Agent，应按「认证流」「错题录入流」「推荐流」划分，而非 Arch/Dev/QA
+  - **调度层必须是确定性代码**（来自 Microsoft 参考架构）。用 LLM 做任务路由是反模式，应使用脚本/CI/工作流引擎
+  - **模型分层（Opus→Sonnet→Haiku）的方向正确**，但应在 Phase 3 功能完善阶段引入，而非现在。MegaAgent 实测成本可降至全 Opus 的 ~1/10
+- 影响:
+  - `.ai/` 配置精简为近期行动项
+  - Arch AI today.md + queue.md 合并
+  - Phase 3 前重新评估 Agent 架构，届时根据团队规模和实际瓶颈决定
+
+## ADR-012: 跨平台「高模型指挥小模型」协作架构
+
+- 日期: 2026-05-26
+- 状态: 已采纳 + 已落地（2026-05-26 同日，D-001 人类确认后立即执行）
+- 决策: 确认当前实际的三平台协作架构——Claude Code + DeepSeek V4 Pro（Arch AI）、Trae CN + GLM-4.6（Coder AI）、Coze CN（Tester AI）——并以此为基准设计任务交接协议。Git 仓库是平台间唯一的通信介质
+- 理由:
+  - **ADR-011 的前提假设错误**：之前认为所有 AI 角色都在 Claude Code 内切换，因此得出了「架构太多了，先精简」的结论。但实际上三个角色运行在三个完全不同的平台/IDE 上，文档是它们之间唯一的通信协议
+  - **跨平台意味着零共享上下文**：Trae + GLM-4.6 不会知道 Claude Code 里讨论了什么。Coze 沙盒不会知道架构设计的细节。所有上下文必须通过 Git 仓库中的文件显式传递
+  - **这恰好是一个自然的「高模型指挥小模型」架构**：Arch AI（Claude + DeepSeek V4，最强推理 + 最强 Agent 框架）→ Coder AI（Trae + GLM-4.6，中配模型）→ Tester AI（Coze CN，沙盒执行）
+- 关键设计:
+
+**模型能力边界**:
+
+| 角色 | 平台+模型 | 擅长 | 不擅长 |
+|------|----------|------|--------|
+| Arch | Claude Code + DeepSeek V4 | 架构推理、方案设计、任务分解 | 大量代码输出（token 成本高） |
+| Coder | Trae + GLM-4.6 | 代码生成、文件操作 | 复杂推理、多文件协调 |
+| Tester | Coze CN | 沙盒执行、自动化验证 | 架构判断、代码修改 |
+
+**任务交接协议（Git 是唯一集成总线）**:
+```
+Arch 写 task → commit → Coder pull → 读 task → 写代码
+    → commit → Tester pull → 跑测试 → 写 report
+    → commit → Arch 读报告做决策
+```
+
+**关键约束**:
+1. 每个 task 必须自包含——不能假设 Coder AI 「知道前面的讨论」。必须包含：明确的输入文件、输出文件、约束条件、参考 ADR
+2. 任务粒度适配 GLM-4.6——单文件或强内聚的 2-3 个文件，跨模块协调由 Arch AI 在设计阶段完成
+3. 每次 commit 粒度 = 恰好一个交接单元
+4. Coze 沙盒做真正的自动化测试闭环——拉代码 → 执行 → 生成 JSON 报告 → commit 回仓库
+
+- 影响:
+  - **推翻 ADR-011 的「精简」结论**：架构文档不能砍，但需要重新定位——从「给自己看的备忘录」变成「跨平台的可靠交接协议」
+  - Task 模板需要升级：增加「输入」「输出」「约束」「参考 ADR」四个必填字段
+  - Dev AI queue.md 的每个任务 description 需要能独立阅读理解，不依赖上下文
+  - 这是对 ADR-001「1 人 + 3 AI」协作框架的实质性落地——从抽象角色到具体平台+模型绑定

.ai/knowledge/journal/2026-05-26.md

@@ -1,32 +1,55 @@
-# Arch AI · 今日任务 · 2026-05-26
+# Arch AI · 开发日志 · 2026-05-26
 
-## 已完成
+## 完成事项
 
-- [x] **[P0]** 编写 `docs/01_产品需求/PRD.md` — 错题本产品需求文档
-- [x] **[P0]** 设计 `docs/02_系统架构/` — 总体架构、技术选型、模块设计、数据模型
-- [x] **[P1]** 将 P01 项目文档从"代码检测"改写为"错题本"
-- [x] **[P1]** 更新 ROADMAP.md 任务看板（PRD 完成后分配 Dev 任务）
+### Phase 1 收尾
+- [x] 旧架构合并：30 项决策逐项确认，5 份架构文档升级至 v0.4.0
+- [x] 一鸡多吃：6 篇对外分享文章完成（项目缘起、框架设计、阶段复盘、ADR-007/009、旧架构合并）
+- [x] share-context Skill v1.0 创建
+- [x] Phase 1 → DONE 100%，Phase 2 启动
+- [x] Dev AI 工作台初始化（8 个 task）
+- [x] `shared/temp/` 旧架构参考文件删除
 
-## 交付物
+### 架构方向审视（蜂群调研）
+- [x] 调研 2025-2026 年业界多 Agent 架构实践（MegaAgent、Claude Code Agent Swarm、Devin、JiuwenSwarm 等）
+- [x] ADR-011: 不急于引入多 Agent 编排层，先精简后分层
+- [x] 澄清实际三平台配置：Arch (Claude Code + DeepSeek V4 Pro) / Coder (Trae CN + GLM-4.6) / Tester (Coze CN)
+- [x] ADR-012: 跨平台「高模型指挥小模型」协作架构（修正 ADR-011）
+- [x] L-002 ~ L-004、P-004 ~ P-005 写入 knowledge/
+- [x] share-context Skill v1.1 — 新增 Step 0「反向检查」补知识摄入端
 
-| 文件 | 状态 |
+### 信息架构升级（三层四角色控制面板）
+- [x] `dashboard.md` — 合并 DASHBOARD + ROADMAP + task 状态面板 + ADR 摘要索引
+- [x] `DECISIONS.md` — 人类决策入口
+- [x] `.ai/tasks/` — Coder 模板 + 8 个 task 文件 + Tester 模板 + 6 个 task 文件
+- [x] 三个角色 card.md 更新（新启动流程 + 新入口引用）
+- [x] AGENTS.md + roles/README.md 更新
+- [x] 8 个旧文件归档至 `.ai/archive/`
+- [x] 人类确认 D-001（选 A — 立即落地新架构）
+
+### 上下文管理规则
+- [x] `.ai/principles.md` 新增「Arch AI 上下文资源管理」硬约束
+- [x] L-005: 上下文窗口是硬约束——盲目冲刺 = 带残缺记忆做决策
+
+### 知识库变更汇总
+
+| 文件 | 新增 |
 |------|------|
-| `docs/01_产品需求/PRD.md` | 草案完成，待人类审阅（第 10 节 5 个待决策事项） |
-| `docs/02_系统架构/总体架构.md` | 完成 |
-| `docs/02_系统架构/技术选型.md` | 完成 |
-| `docs/02_系统架构/模块设计.md` | 完成 |
-| `docs/02_系统架构/数据模型.md` | 完成 |
-| `projects/P01_errlens_app/docs/01_需求概要.md` | 已改写 |
-| `projects/P01_errlens_app/docs/02_架构设计.md` | 已改写 |
-| `projects/P01_errlens_app/docs/03_接口定义.md` | 已改写 |
-| `ROADMAP.md` | 已更新，RED 阻塞解除，Dev 任务已分配 |
+| decisions.md | ADR-011, ADR-012 |
+| lessons.md | L-002, L-003, L-004, L-005 |
+| patterns.md | P-004, P-005 |
 
-## 明天 (2026-05-27)
+## 关键决策
 
-1. **根据人类反馈修订 PRD**（若有修改意见）
-2. **将 Dev 任务写入 Dev AI 工作台**，指导 Dev 开始开发
-3. **补充架构决策记录 ADR-009**（错题本技术选型决策）
+- **ADR-012 生效**：三平台四角色架构，Git 是唯一集成总线，task 文件自包含
+- **信息架构从「内部备忘录」重定位为「跨平台交接协议」**
+- **取消 ADR-011 的精简计划**：文档不能砍，因为它是平台间的唯一通信协议
+- **Arch AI 上下文管理作为硬约束写入原则**
 
-## 阻塞
+## 项目状态
 
-（无 — 等待人类审阅 PRD 第 10 节）
+Phase 2 就绪。14 个 task 文件待 Coder/Tester AI 领用。无阻塞。
+
+## 明天
+
+Phase 2 编码启动。Coder AI (Trae + GLM-4.6) 从 P01-001 (DB Schema) 开始。

.ai/knowledge/lessons.md

@@ -20,6 +20,72 @@
 
 ---
 
-## L-002
+## L-002: 角色边界划分是 AI Agent 协作的反模式
 
-*（待项目推进中记录）*
+**日期**: 2026-05-26
+**上下文**: Phase 1 收尾后，重新审视「1 人 + 3 AI」的 Arch/Dev/QA 角色划分架构。调研了 2025-2026 年业界最新实践（MegaAgent、Claude Code Agent Swarm、Devin、JiuwenSwarm、Microsoft 多 Agent 参考架构等）
+**问题**:
+- 按角色边界（Arch/Dev/QA）划分 Agent 导致协调成本急剧上升，Token 消耗是单体的 3-10 倍
+- Arch AI 承担了过多职责：架构设计 + 任务分配 + 文档维护 + 看板更新，成为单点瓶颈
+- `.ai/` 目录膨胀到 47 个文件，但 Phase 2 代码一行还没写——架构本身成了负担
+- Anthropic 和 Cognition（Devin）都承认：并行 Agent 在编码领域的实际收益有限，隐性决策冲突和整合成本往往超过并行收益
+**教训**:
+1. **按业务上下文划分，而非按角色划分**。正确的做法是「用户认证流 Agent」拥有路由+数据库+前端组件，「错题录入流 Agent」拥有拍照+图像处理+入库——每个 Agent 拥有完成任务所需的全部上下文
+2. **架构规模应与项目阶段匹配**。Phase 1 只有需求+设计，不需要 47 个配置文件。应该在需要时渐进式添加，而非提前搭建「完整」架构
+3. **调度层应该是确定性代码，而非 LLM**。用 LLM 做任务路由和状态更新是反模式——不稳定、成本高。这些应该用脚本/CI/工作流引擎实现
+4. **子 Agent 的甜蜜点是只读研究，而非并行编码**。隔离上下文中做信息收集然后压缩回传——这是验证最有效的模式
+5. **「高模型指挥小模型」的方向是对的，但规模要匹配**。1 人项目的「编排层」就是人类+Claude Code 本身，不需要额外的编排 Agent
+**行动**:
+- 启动 `.ai/` 配置精简审计，目标砍到 20 个文件以内
+- Arch AI 的 today.md 和 queue.md 合并，消除重复
+- Phase 3 前评估是否引入正式模型分层（Opus 做判断 → Sonnet/Haiku 做执行）
+- 当前阶段保留角色划分但降低形式化程度，实际工作由 Claude Code 子 Agent 机制承载
+
+---
+
+## L-003: 知识库「生产者」流程缺失
+
+**日期**: 2026-05-26
+**上下文**: 一次关于 Agent 架构的深度讨论产生了有价值的洞察（L-002 + ADR-011 + P-004），但发现把这些洞察写入知识库的动作没有 formalized 流程
+**问题**: `share-context` Skill 覆盖了知识库的「消费者」侧（.ai/knowledge/ → docs/share/），但「生产者」侧（开发讨论 → .ai/knowledge/）是断的。有价值的想法和教训可能因为没人记得写而丢失
+**教训**: 一条完整的信息流水线需要两端都 formalized：摄入端（什么时候写、写到哪里、怎么写）和输出端（什么时候翻译、翻译成什么）。目前只有输出端
+**行动**:
+- 更新 `share-context` Skill，增加「反向检查」步骤：每次执行时先检查是否有未入库的讨论/想法
+- 建立触发条件：当讨论产生「可复用的判断」「反直觉的发现」「被验证的错误方向」时，主动记录
+
+---
+
+## L-005: Arch AI 上下文窗口是硬约束——盲目冲刺 = 带残缺记忆做决策
+
+**日期**: 2026-05-26
+**上下文**: 持续数小时的高强度架构讨论（ADR-011、ADR-012、信息架构升级），Arch AI 的上下文窗口承载了全部对话历史
+**问题**: 复杂任务容易让人想「一口气做完」，但 Arch AI 的上下文窗口有限。做一半触发自动压缩 → 前面的讨论、决策细节、已排除的选项全部丢失 → 后续判断基于不完整记忆 → 决策质量崩盘
+**教训**:
+1. **上下文不是无限的**。每次对话都是消耗品，越长的讨论越容易触发压缩
+2. **决策即记录**。每个判断产生后立即写入 knowledge/，不留在对话里。对话是易失的，文件是持久的
+3. **主动 checkpoint 优于被动压缩**。感觉吃力时主动收尾（commit + push），开新会话继续——带着干净记忆比带着残缺记忆强
+4. **拆分到可提交粒度**。大任务拆成独立子任务，每个子任务结束后 commit。即使后续会话压缩，已完成的部分已经落地
+**行动**:
+- 写入 `.ai/principles.md` 作为 Arch AI 硬约束
+- 任务前评估上下文余量
+- 接近窗口上限时执行主动收尾协议：已完成 → commit → 告知人类进展 → 建议开新会话
+
+---
+
+## L-004: 跨平台 AI 协作下，文档是唯一的通信协议
+
+**日期**: 2026-05-26
+**上下文**: 澄清了实际的三平台配置——Arch AI (Claude Code + DeepSeek V4 Pro)、Coder AI (Trae CN + GLM-4.6)、Tester AI (Coze CN)。之前的设计假设所有角色在同一个 AI 平台内切换，这一假设被推翻
+**问题**:
+- 之前的架构分析得出了「精简文档」的结论（ADR-011），但这个结论基于错误的前提——以为所有 AI 共享同一个上下文空间
+- 实际场景中，三个平台的 AI 之间**零共享上下文**。Trae + GLM-4.6 不会知道 Claude Code 里讨论了什么，Coze 沙盒不会知道架构设计的动机
+- 如果把文档精简了，Coder AI 拿到的 task 就会缺失关键上下文，GLM-4.6 又没有能力自行推断
+**教训**:
+1. **架构结论绑定于部署拓扑**。同一个设计，在「单平台多角色切换」和「跨平台多 Agent 协作」下是完全不同的东西。先搞清楚运行环境，再做架构决策
+2. **跨平台协作中，Git 仓库不是存储，是通信介质**。每个 commit 是一次消息传递，每个文件是一份消息体。消息必须自包含，接收方不能依赖「上次聊过」
+3. **任务交接密度必须适配接收方模型能力**。GLM-4.6 不是 Claude——不能给一个需要跨 5 个文件推理的任务。每个 task 应该是单文件或强内聚的 2-3 个文件
+4. **低能力模型不是劣势，是约束**。只能处理小范围任务 → 强迫架构设计更清晰 → 反而减少 bug。这就是「限制产生创造力」
+**行动**:
+- 修正 ADR-011 的结论：不做精简，改为「重定位」——架构文档从内部备忘录升级为跨平台交接协议（ADR-012）
+- Task 模板增加四个必填字段：输入、输出、约束、参考 ADR
+- Dev queue.md 的每个任务需独立可读，不依赖前后文

.ai/knowledge/patterns.md

@@ -48,6 +48,93 @@
 
 ---
 
+## P-004: 编排器-执行者模式 (Orchestrator-Worker)
+
+**上下文**: AI Agent 协作中，不同任务需要不同能力的模型。高能力模型（Opus）做规划和判断，低成本模型（Sonnet/Haiku）做执行
+**来源**: MegaAgent (NUS)、Claude Code Agent Swarm (Anthropic)、JiuwenSwarm (华为 openJiuwen)、Microsoft 多 Agent 参考架构
+**方案**:
+
+```
+决策层 (Opus)    → 意图理解、方案设计、最终验收  (~10% Token, 最贵)
+调度层 (代码)    → 任务路由、负载均衡、重试熔断  (确定性代码, 不用 LLM!)
+执行层 (Haiku)   → 专注单一原子任务              (~60% Token, 最便宜)
+```
+
+**核心原则**:
+1. 按业务上下文划分 Agent（「认证流 Agent」），而非按角色（「数据库 Agent」）
+2. 调度层是确定性代码——用 LLM 做调度是反模式
+3. 子 Agent 的甜蜜点是只读研究/探索，并行编码效果不佳
+4. 写范围严格分离——并发写任务之间不能有重叠的文件所有权
+5. Agent 粒度围绕内聚能力组织——不要为「调用一个 API」建 Agent
+
+**何时用**:
+- 团队规模 ≥ 3 个 AI Agent 并行工作
+- 任务可清晰分解为独立子任务，且协调成本 < 并行收益
+- 有明确的模型成本优化需求
+
+**何时不用**:
+- 1 人项目——编排层就是人类 + Claude Code 本身
+- 编码任务的并行化——行业共识是效果不佳
+- 简单 bug 修复——分解成本 > 直接修复成本
+
+**本项目实例** (ErrLens):
+
+```
+Arch AI:  Claude Code + DeepSeek V4 Pro  → 架构推理、方案设计、任务分解
+Coder AI: Trae CN + GLM-4.6              → 代码生成、文件操作（单文件粒度）
+Tester AI: Coze CN                        → 沙盒执行、自动化测试报告
+
+通信介质: Git 仓库（唯一集成总线）
+交接粒度: 单次 commit = 一个交接单元
+```
+
+**关键适配**:
+- Coder AI 用的是 GLM-4.6，不能假设它有跨文件推理能力 → task 分解到单文件粒度
+- 跨模块协调在 Arch AI 设计阶段完成，不在 Coder AI 执行阶段
+- Tester AI 的 Coze 沙盒做真正的自动化闭环——不只是跑测试，是拉代码 → 执行 → 生成报告 → commit
+
+---
+
+## P-005: 跨平台任务交接协议 (Cross-Platform Task Handoff)
+
+**上下文**: 多个 AI Agent 运行在不同平台/IDE 上，零共享上下文，Git 是唯一通信介质
+**问题**: 如何让 Trae + GLM-4.6 拿到 task 后能直接开工，不需要追问「这个是什么意思」
+**方案**: 每个 task 必须自包含，包含四个必填字段：
+
+```markdown
+## Task: {编号} {标题}
+
+### 输入
+- 读哪些文件（完整路径）
+- 参考哪些 ADR（ADR-XXX）
+- 依赖哪些上游任务（P01-XXX，已完成/产出是 X）
+
+### 输出
+- 生成/修改哪些文件（完整路径）
+- 输出格式（代码/文档/配置）
+- 验收方式（跑什么命令看什么结果）
+
+### 约束
+- 不碰哪些目录
+- 用什么库/版本
+- 遵循什么规范（code-style.md / doc-template.md）
+
+### 参考
+- ADR-XXX: 一句话说明关联性
+- 相关文件: 一行说明
+```
+
+**核心原则**:
+1. **零隐含上下文**：接收方不能依赖「上次聊过」，所有信息必须显式写在 task 里
+2. **适配接收方能力**：给 GLM-4.6 的任务粒度 = 单文件；给 Claude 的任务可以跨 3-5 个文件
+3. **Git commit 即消息**：每次 commit 是发送一次消息，接收方 pull 即收到
+4. **任务与代码分离**：task 定义在 `.ai/roles/{role}/queue.md`，代码在 `projects/`，通过 Git 同步
+
+**何时用**: 跨平台/跨模型协作
+**何时不用**: 同一平台内的角色切换（直接对话即可）
+
+---
+
 ## 反模式（避免）
 
 - 在多个文件中重复同一状态信息 → 只在 ROADMAP.md 记录