feat: 项目架构重构 - hwd32h757芯片成片测试及SDK开发

- 从errlens模板(3角色)重构为1人+Arch AI+Worker AI(2角色) - 去掉review仓库/QA AI/Dev AI分离，Worker AI统一负责开发+测试 - 新增33个功能单元目录(Test/cases/)，按P0-P6七阶段bring-up - 新增SDK驱动层骨架(Drivers/CMSIS/HAL_Driver/BSP) - Arch AI/Worker AI角色不绑定特定AI平台，任何AI可随时接手 - 5个ADR：测试驱动SDK演进、HAL/LL双层、分阶段bring-up、单仓库、角色可替换 - 参考errlens的分层信息架构：dashboard→card→task，token预算控制
2026-05-27 16:37:52 +08:00
parent 6c09a9b6d4
commit 3d43cd87d5
97 changed files with 645 additions and 4143 deletions
@@ -0,0 +1,41 @@
 # 架构决策记录 (ADR)
 ## ADR-001: 测试驱动 SDK 演进
 - 日期: 2026-05-27
 - 状态: 已采纳
 - 决策: 寄存器测试是 SDK 的第一用户，测试代码直接演进为 LL 层驱动
 - 理由: bring-up 阶段的核心产出是验证寄存器功能，测试代码天然包含了对寄存器的精确操作逻辑，提炼为 LL 层零浪费
 - 影响: Test/cases/ 的代码质量要求等同于 SDK 代码；每个功能单元的测试代码必须结构化，便于后续提炼
 ## ADR-002: HAL/LL 双层架构，参考 STM32CubeH7
 - 日期: 2026-05-27
 - 状态: 已采纳
 - 决策: 采用与 STM32CubeH7 一致的 HAL/LL 双层架构，包括句柄模式、弱回调、模块化编译
 - 理由: STM32CubeH7 是经过大规模验证的工业级 SDK 架构，HAL/LL 双层兼顾了可移植性和性能，开发者社区熟悉度高
 - 影响: 驱动代码必须遵循 HAL/LL 分层；HAL 用句柄+状态机+回调，LL 用内联函数直操寄存器；编译体积由 hal_conf.h 宏开关控制
 ## ADR-003: 33 个功能单元分 7 阶段 bring-up
 - 日期: 2026-05-27
 - 状态: 已采纳
 - 决策: 按 bring-up 逻辑将 33 个功能单元分为 P0-P6 七个阶段，P0-P1 串行，P2-P6 可按需并行
 - 理由: 芯片 bring-up 有天然依赖——必须先能跑（P0），才能有调试输出（P1），然后才能测其他外设。但模拟、定时器、存储、高速接口之间没有强依赖，可以并行
 - 影响: 任务编号用 D{阶段号}-{序号}，阶段切换需人类确认
 ## ADR-004: 1 人 + 2 AI 单仓库协作
 - 日期: 2026-05-27
 - 状态: 已采纳
 - 决策: 采用 1 人 + Arch AI + Worker AI 的协作模式，单仓库，不需要 review 仓库
 - 理由: 嵌入式项目文件数少但精度高，Arch AI 和 Worker AI 在同一仓库操作更直接。测试包含在 Worker AI 职责内，不需要独立 QA AI
 - 影响: 去掉 errlens 的 review/ 目录和 QA AI 角色；Worker AI 同时负责开发和测试
 ## ADR-005: Arch AI 角色可由任何 AI 担当
 - 日期: 2026-05-27
 - 状态: 已采纳
 - 决策: Arch AI 和 Worker AI 不是绑定到某个特定 AI 平台的角色定义，而是职责定义。任何 AI（扣子、Claude Code、DeepSeek 等）读到 card.md 即可担当
 - 理由: 实际使用中不同场景适合不同 AI——架构讨论用扣子对话，代码执行用 Claude Code 终端，快速查询用 DeepSeek CLI。强制绑定单一平台会降低效率
 - 影响: card.md 必须自包含，不假设读它的 AI 有任何前置上下文；AGENTS.md 是通用上下文锚点
@@ -0,0 +1,13 @@
 # 经验教训
 ## 目的
 记录开发过程中学到的东西。每条记录包含：
 - 上下文（我们在做什么）
 - 问题（出了什么问题/什么让我们意外）
 - 教训（学到了什么）
 - 行动（因此改变了什么）
 ---
 （暂无经验教训，项目刚启动。随着 bring-up 推进自动积累。）
@@ -0,0 +1,52 @@
 # 可复用模式
 ## 目的
 记录开发过程中发现的可持续复用的模式和做法。
 ---
 ## P-001: 测试→LL→HAL 提炼路径
 **上下文**: 每个功能单元从寄存器测试到最终 SDK 驱动的演进
 **问题**: 测试代码和 SDK 驱动如何衔接，避免重复劳动
 **方案**: 三步提炼路径：
 1. **寄存器测试代码** → 直接操作寄存器地址和位域，验证功能正确性
 2. **LL 层提炼** → 将测试中的寄存器操作封装为内联函数+宏，零开销
 3. **HAL 层封装** → 在 LL 层之上加句柄+状态机+回调，高抽象可移植
 **关键约束**: 测试代码必须结构化（用宏封装寄存器操作，不用硬编码地址），否则提炼成本极高
 **何时用**: 每个功能单元完成后
 **何时不用**: 纯软件功能（无寄存器操作）
 ---
 ## P-002: 勘误驱动规避
 **上下文**: 芯片 bring-up 中发现的硅缺陷
 **问题**: 如何让 SDK 驱动自动规避已知勘误
 **方案**:
 1. 勘误记录在 Test/errata/ 中，结构化格式（影响外设、触发条件、规避方法）
 2. LL 层代码中在受影响操作处加 workaround 注释
 3. HAL 层代码中自动执行规避逻辑（对调用方透明）
 **何时用**: 发现勘误后立即记录，LL/HAL 代码同步更新
 **何时不用**: 确认无硅缺陷的功能
 ---
 ## P-003: 跨 AI 上下文交接
 **上下文**: 不同 AI 可能在不同时间、不同平台介入同一项目
 **问题**: 如何确保任何 AI 随时能接手
 **方案**:
 1. AGENTS.md 是通用上下文锚点
 2. dashboard.md 记录当前状态，任何 AI 读到即知全貌
 3. task 文件自包含（输入/输出/约束/验收），不依赖对话历史
 4. Git commit 记录所有变更，Git 是唯一的历史来源
 **核心原则**: 对话是易失的，文件是持久的。每个判断产生后立即写入文件。
 **何时用**: 每次 AI 会话
 **何时不用**: 无（这是基础模式，始终适用）
@@ -0,0 +1,27 @@
 # 阶段索引
 | 阶段 | 名称 | 功能单元 | 状态 | 目录 |
 |------|------|---------|------|------|
 | P0 | 基础 bring-up | 电源管理/时钟/NRST复位/GPIO/JTAG_SWD | PLANNED | — |
 | P1 | 基本通信 | USART/SPI/I2C | PLANNED | — |
 | P2 | 模拟链路 | ADC/DAC/比较器/VREFBUF/温度/参考电压/Scaler启动时间 | PLANNED | — |
 | P3 | 定时器类 | Timer/HRTIM/LPTIM/看门狗 | PLANNED | — |
 | P4 | 存储搬运 | FMC/QSPI/SDMMC/DMA/DLYB | PLANNED | — |
 | P5 | 高速接口 | USB/以太网/SAI/ULPI | PLANNED | — |
 | P6 | 杂项 | 电压监控/模拟开关升压/升压器/CRC/电流特性 | PLANNED | — |
 ## 阶段执行原则
 1. **P0必须先完成** — 芯片能跑起来才能测其他
 2. **P1在P0完成后启动** — 需要调试输出和通信通道
 3. **P2-P6可按需并行** — 依赖P1但不互锁
 4. **SDK随阶段推进** — 每个阶段完成后提炼LL/HAL层
 ## 阶段切换规则
 1. 当前阶段所有功能单元测试通过（或勘误已记录）
 2. 人类签字确认
 3. Arch AI 更新本索引文件
 4. Arch AI 更新 dashboard.md（进度条 + task 状态面板 + 最近事件）
 5. Arch AI 更新 Worker card.md（当前阶段字段）
 6. 产出阶段完成总结
@@ -9,16 +9,16 @@ AI 的上下文窗口有限。每个读入上下文的字都是成本。这套
 | 层级 | 预算 | 内容 | 加载时机 |
 |------|------|------|----------|
 | 入口（dashboard/card） | < 2K | 身份+全貌+任务 | 每次会话必读 |
-| Task 文件 | < 1K | 单任务全部信息 | Coder/Tester 开工时 |
+| Task 文件 | < 1K | 单任务全部信息 | Worker 开工时 |
 | 知识沉淀 (knowledge) | < 3K | 决策/模式/教训 | 按需加载 |
 | 阶段上下文 (phase) | < 5K | 目标+范围+架构 | 按需加载 |
-## 信息分层（三层架构）
+## 信息分层
 ```
 指挥层: dashboard.md → 人类 + Arch AI 唯一入口
 决策层: DECISIONS.md → 待人类决策事项
-执行层: .ai/tasks/active/ → Coder/Tester 各自 task 文件
+执行层: .ai/tasks/active/ → Worker 各自 task 文件
 ```
 ## 维护规则
@@ -43,13 +43,12 @@ AI 的上下文窗口有限。每个读入上下文的字都是成本。这套
 4. **接近窗口上限时主动收尾**：感觉上下文开始吃力时，主动 checkpoint——已完成写入文件、commit、告知人类当前进展和下一步。**宁可多开一个会话，不要带着残缺记忆继续**
 5. **拆分到可提交粒度**：大任务拆成独立子任务。每个子任务结束后 git commit，确保即使后续会话压缩，已完成的部分不会丢失
-### 角色特定约束
+### 嵌入式项目特有约束
 | 角色 | 主要风险 | 应对策略 |
 |------|---------|---------|
-| Arch AI (Claude Code) | 长对话积累上下文，架构讨论容易收不住 | 每个 ADR 产出后立即写入 decisions.md；感知吃力时主动收尾 |
+| Arch AI | 架构讨论容易收不住，寄存器细节容易混淆 | 每个 ADR 产出后立即写入 decisions.md；寄存器定义以 SVD 为准，不靠记忆 |
-| Coder AI (Trae + GLM-4.6) | 上下文窗口更小，多文件任务容易超出 | 每个 session 只做 1 个 task 文件；不读其他 task，不读架构文档 |
+| Worker AI | 单个外设测试代码可能涉及大量寄存器位域 | 每个 session 只做 1 个 task；测试代码按功能单元独立，不跨单元引用 |
 | Tester AI (Coze CN) | 沙盒执行时间有限 | 1 个 session 只测 1 个 T01-XXX task；报告立即写回 repo |
 ### 信号识别（何时应立即执行规则 4）
@@ -57,35 +56,22 @@ AI 的上下文窗口有限。每个读入上下文的字都是成本。这套
 - 开始忘记用户几分钟前说过的话
 - 回复质量出现可感知的下降
 - 同一个问题被重复提出
- （Coder AI）需要同时修改 3 个以上文件才能完成 task
+- 需要同时修改 3 个以上文件才能完成 task
 ### 反模式
 - 「一口气做完再 commit」——做一半触发压缩，前面做的全丢
 - 「这个 task 简单，我顺便把下一个也做了」——超边界 = 超上下文
 - 「先放着，等会儿一起处理」——对话不等人，放着 = 丢了
 - 「凭记忆写寄存器地址」——嵌入式寄存器地址必须从 SVD/头文件获取，不能靠回忆
 ---
 ## 文件约定
 - 控制面板: `dashboard.md`
 - 决策入口: `DECISIONS.md`
 - 角色工作台: `.ai/roles/{role}/card.md`
 - 执行任务: `.ai/tasks/active/`
 - 阶段上下文: `.ai/phases/phase-NN-name/`
 - 知识沉淀: `.ai/knowledge/`
 - 提示词模板: `.ai/prompts/{domain}/`
 - Skill 工具: `.trae/skills/`
 - 框架边界: `SYNC.md`
 - 模板变量: `TEMPLATE.yaml`
 ## 阶段切换检查清单
 切换阶段时 Arch AI 必须：
 - [ ] 更新所有角色的 card.md（当前阶段字段）
 - [ ] 更新 dashboard.md（进度条 + task 状态面板 + 最近事件）
 - [ ] 更新 phases/INDEX.md
- [ ] 生成上一阶段的 completion.md
+- [ ] 产出上一阶段的 completion.md
 - [ ] 产出阶段复盘（docs/share/phase-NN/）
 - [ ] 审计 token 预算
@@ -0,0 +1,48 @@
 # Arch AI — 架构师
 ## 身份
 我是架构 AI。负责需求分析、架构设计、技术选型、任务拆解、质量审查。
 **平台**: 不限（扣子/Claude Code/DeepSeek，任何AI均可担当此角色）
 ## 启动流程
 1. 读本文件（card.md）→ 我是谁、权限
 2. 读 `dashboard.md` → 了解项目全貌、当前阶段、任务状态
 3. 按需深入 → `.ai/knowledge/decisions.md`（ADR）、`.ai/phases/`（阶段上下文）
 4. 拆解新任务 → 按模板写 `.ai/tasks/active/D{阶段号}-{序号}.md`
 5. Worker 完成后 → 审查代码质量、确认测试覆盖、更新 dashboard.md
 ## 当前阶段
 P0: 基础 bring-up（电源/时钟/复位/GPIO/JTAG）
 ## 核心交付物
 - 架构设计文档 (docs/)
 - 任务定义 (.ai/tasks/active/)
 - 验收标准 (task 文件内)
 - ADR (.ai/knowledge/decisions.md)
 ## 权限
 **可写**: docs/ .ai/knowledge/ .ai/tasks/ .ai/phases/ Tools/
 **只读**: Test/ Drivers/HWD32H757_HAL_Driver/ Drivers/BSP/
 **禁止**: .ai/roles/ .ai/principles.md（人类维护）
 ## 关键入口
 | 文件 | 说明 |
 |------|------|
 | `dashboard.md` | 项目全貌（每次必读） |
 | `DECISIONS.md` | 待人类决策事项 |
 | `.ai/knowledge/decisions.md` | ADR 全文 |
 | `.ai/tasks/active/` | 活跃任务列表 |
 | `.ai/tasks/templates/TASK_TEMPLATE.md` | task 格式说明 |
 ## 特别注意
 - 嵌入式项目的架构决策往往影响寄存器层——ADR 必须注明影响哪些功能单元
 - 测试→LL→HAL 的提炼路径是核心模式，拆任务时要体现这个递进关系
 - Arch AI 不是某一个人/AI，任何 AI 读到这份文档都可以担当此角色
@@ -0,0 +1,60 @@
 # Worker AI — 执行者
 ## 身份
 我是执行 AI。负责代码编写、测试执行、文档生成、LL/HAL 驱动提炼。
 **平台**: 不限（Claude Code/DeepSeek/Codex CLI，任何AI均可担当此角色）
 ## 启动流程
 1. 读本文件（card.md）→ 我是谁、权限
 2. 读 `dashboard.md` → 找到自己对应的 task（状态为 `todo` 的任务）
 3. 打开对应 task 文件（如 `.ai/tasks/active/D0-001.md`）→ **这就是你的全部世界**
 4. 按 task 文件中的「输入」「输出」「约束」「验收方法」执行
 5. 完成后 → 填写 task 文件的「完成报告」→ commit（message 含 `[DONE]`）
 **不需要**读 ADR 全文、知识库、或其他 task 文件。你的 task 文件已经包含了完成任务所需的全部信息。
 ## 当前阶段
 P0: 基础 bring-up
 ## 核心交付物
 - 寄存器测试代码 (Test/cases/{unit}/)
 - LL 驱动代码 (Drivers/HWD32H757_HAL_Driver/Inc/*_ll_*.h, Src/*_ll_*.c)
 - HAL 驱动代码 (Drivers/HWD32H757_HAL_Driver/Inc/*_hal_*.h, Src/*_hal_*.c)
 - 勘误记录 (Test/errata/)
 - 工具脚本 (Tools/)
 ## 核心工作模式：测试→LL→HAL 提炼路径
 ```
 1. 寄存器测试代码 → 直接操作寄存器，验证功能正确性
 2. 测试代码提炼为 LL 层 → 内联函数+宏，零开销
 3. LL 层封装为 HAL 层 → 句柄+状态机+回调，高抽象可移植
 ```
 每次完成一个功能单元的测试后，应主动提出 LL 层提炼建议。
 ## 权限
 **可写**: Test/ Drivers/HWD32H757_HAL_Driver/ Drivers/BSP/ Drivers/CMSIS/ Tools/ Projects/
 **只读**: docs/ .ai/tasks/active/ dashboard.md DECISIONS.md
 **禁止**: .ai/ .ai/roles/ .ai/knowledge/ .ai/phases/ .ai/principles.md
 ## 关键入口
 | 文件 | 说明 |
 |------|------|
 | `dashboard.md` | 查找自己的 task |
 | `.ai/tasks/active/D{阶段号}-{序号}.md` | 你的 task 文件（开工时读这个） |
 | `.ai/tasks/templates/TASK_TEMPLATE.md` | task 格式说明 |
 ## 特别注意
 - 寄存器地址和位域定义必须从 SVD 或 CMSIS 头文件获取，不能凭记忆编写
 - 测试代码中必须包含边界条件和异常情况的测试
 - 发现勘误时必须记录到 Test/errata/，并在 LL/HAL 代码中加 workaround
 - Worker AI 不是某一个人/AI，任何 AI 读到这份文档都可以担当此角色
@@ -0,0 +1,59 @@
 # Task 模板
 > 所有 task 文件必须遵循此模板，确保自包含、零隐含上下文。
 ---
 ```markdown
 # Task {编号}: {标题}
 ## 元信息
 | 字段 | 值 |
 |------|-----|
 | 状态 | `todo` / `in_progress` / `done` / `verified` / `accepted` |
 | 优先级 | P0 / P1 / P2 |
 | 依赖 | 上游任务编号（无则写"无"） |
 | 分配给 | Worker AI |
 ## 输入
 **要读的文件**:
 - `路径` — 简要说明
 **参考的 ADR**:
 - ADR-XXX: 一句话说明关联性
 **上游依赖产出**:
 - 无 / D{X}-{YYY} 产出为 ZZZ
 ## 输出
 **要生成/修改的文件**:
 - `路径` — 简要说明
 **输出格式**: 代码/文档/配置
 ## 约束
 - 不碰: 列出禁止修改的目录
 - 技术栈: GCC ARM + CMake / Python
 - 规范: 编码规范、命名规范
 ## 验收方法
 ```bash
 # 具体命令和预期结果
 ```
 ## 完成报告
 > Worker 完成后填写。Commit message 以 `[DONE]` 结尾。
 - [ ] 输出文件已生成
 - [ ] 验收命令通过
 - [ ] Commit: `{hash}`
 - [ ] Commit message: `feat({编号}): 简短描述 [DONE]`
 - [ ] 发现的勘误: 无 / 描述
 - [ ] LL提炼建议: 无 / 描述
 ```
@@ -0,0 +1,26 @@
 # Build
 build/
 out/
 # IDE
 .vscode/
 .idea/
 *.swp
 *.swo
 # OS
 .DS_Store
 Thumbs.db
 # Python
 __pycache__/
 *.pyc
 .venv/
 # Binary
 *.o
 *.elf
 *.bin
 *.hex
 *.map
 *.lst
@@ -0,0 +1,111 @@
 # AI 角色定义与权限约定
 > **如果你是 AI，请直接跳转到你的角色入口：**
 > - Arch AI → `dashboard.md` 全文
 > - Worker AI → `.ai/roles/worker/card.md` → 对应 `.ai/tasks/active/` 任务文件
 >
 > **如果你是人类**，请看 `dashboard.md` 顶部「人类区」。
 >
 > 本文档是权限矩阵的**唯一权威参考**。角色工作台中的权限描述为摘要，如有冲突以本文档为准。
 ---
 ## 团队架构
 `1 人类 + 2 AI` 协作模式：
 - **Arch AI** — 需求分析、架构设计、技术选型、任务分解、质量审查、勘误决策
 - **Worker AI** — 代码编写、测试执行、文档生成、LL/HAL 驱动提炼
 - **人类** — 需求输入、最终决策、硬件验证、成果验收
 **核心理念**：测试驱动 SDK 演进。寄存器测试是 SDK 的第一用户，测试代码直接提炼为 LL 层驱动。
 ---
 ## 工作流
 ```
 需求分析(Arch) → 架构设计(Arch) → 任务拆解(Arch)
    → 开发实现(Worker) → 自测(Worker) → 人类硬件验证
    → 勘误记录(Worker) → LL提炼(Worker) → HAL封装(Worker)
                                       ↑
                                   Bug修复(Worker, 最多3轮)
 ```
 缺陷修复循环：最多 3 轮。第 3 轮仍有 BLOCKER → 升级给人类 + Arch AI 裁决。
 ---
 ## 角色职责
 ### Arch AI
 - 可写：架构文档、验收标准、任务定义、知识库、共享资源、开发工具、SDK 设计文档
 - 只读：测试代码、测试报告、勘误详情
 - 指导 Worker AI 工作，分配任务队列，审查产出质量
 ### Worker AI
 - 可写：业务代码、测试代码、测试报告、技术文档、开发工具、勘误记录、LL/HAL 驱动代码
 - 只读：AI 配置、任务定义（不可修改 task 内容）
 - 禁止：.ai/ 目录结构修改、dashboard.md 修改
 ### 人类
 - 全部权限，但主要行使：需求定义、架构决策、硬件验证、成果验收
 ---
 ## 目录权限矩阵
 > 图例：`-` = 禁止  `R` = 只读  `W` = 可写（含读）  `RW` = 读写
 | 目录路径 | Arch AI | Worker AI | 人类 |
 |---------|---------|-----------|------|
 | `.ai/` | `R` | `-` | `RW` |
 | `dashboard.md` | `RW` | `R` | `RW` |
 | `DECISIONS.md` | `RW` | `R` | `RW` |
 | `Drivers/CMSIS/` | `RW` | `RW` | `RW` |
 | `Drivers/HWD32H757_HAL_Driver/` | `R` | `RW` | `RW` |
 | `Drivers/BSP/` | `R` | `RW` | `RW` |
 | `Test/` | `R` | `RW` | `RW` |
 | `Test/errata/` | `RW` | `RW` | `RW` |
 | `Tools/` | `RW` | `RW` | `RW` |
 | `docs/` | `RW` | `RW` | `R` |
 | `Projects/` | `R` | `RW` | `RW` |
 优先级：`forbidden > read_only > allowed`。未出现在表中的路径默认禁止所有 AI。
 ---
 ## 命名规范
 ### 任务编号
 - 开发任务：`D{阶段号}-{序号}`，如 `D0-001`（P0阶段第1个任务）
 - 测试任务：`T{阶段号}-{序号}`，如 `T0-001`
 ### 分支命名
 ```
 feature/D0-001-short-desc
 bugfix/D0-001-short-desc
 test/T0-001-short-desc
 ```
 ### 提交信息
 ```
 feat(D0-001): 简短描述
 fix(D0-001): 简短描述
 docs(D0-001): 简短描述
 test(D0-001): 简短描述
 errata: GPIOx_BSRR 写入偶发失效 (D0-003)
 ```
 ---
 ## AI 配置文件索引
 | 文件 | 说明 |
 |------|------|
 | `.ai/principles.md` | 设计原则 + 上下文管理规则 |
 | `.ai/roles/{arch,worker}/card.md` | AI 角色身份卡 |
 | `.ai/phases/INDEX.md` | 阶段索引 + 切换规则 |
 | `.ai/knowledge/decisions.md` | 架构决策记录 (ADR) |
 | `.ai/knowledge/lessons.md` | 经验教训 |
 | `.ai/knowledge/patterns.md` | 可复用模式 |
 | `.ai/tasks/templates/` | Task 模板 |
@@ -5,11 +5,9 @@
 ---
 ---
 ## 已决策
-（暂无）
+（暂无已决策事项）
 ---
@@ -0,0 +1,48 @@
 # hwd32h757 开发环境配置
 ## 芯片信息
 | 项目 | 值 |
 |------|-----|
 | 芯片代号 | hwd32h757 |
 | 内核 | Cortex-M7 |
 | 参考架构 | STM32H7系列 |
 | SDK框架 | HAL/LL双层（参考STM32CubeH7） |
 ## 前置依赖
 | 工具 | 版本要求 | 说明 |
 |------|---------|------|
 | GCC ARM | >= 13.x | 交叉编译器 |
 | CMake | >= 3.20 | 构建系统 |
 | Python | >= 3.10 | 工具脚本（SVD解析、测试报告） |
 | OpenOCD / J-Link | — | 烧录调试 |
 | Git | >= 2.40 | 版本控制 |
 ## 开发工具
 - **IDE**: VS Code + Cortex-Debug + CMake Tools
 - **AI协作**: 1人 + Arch AI + Worker AI
 - **上下文同步**: AGENTS.md + dashboard.md（任何AI读到即可接手）
 ## 硬件环境
 - **评估板**: HWD32H757-EVAL
 - **调试器**: J-Link / ST-Link（SWD接口）
 - **串口**: USB-UART（调试输出）
 ## 快速开始
 ```bash
 # 1. 克隆项目
 git clone https://gitcode.com/tupingr/ai_soc_sw.git
 cd ai_soc_sw
 # 2. 构建
 mkdir build && cd build
 cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/arm-gcc-toolchain.cmake
 make
 # 3. 烧录
 openocd -f interface/jlink.cfg -f target/hwd32h757.cfg -c "program build/Test/cases/gpio/gpio_test.elf verify reset exit"
 ```
@@ -0,0 +1,53 @@
 # ai_soc_sw
 hwd32h757 MCU 芯片成片测试及 SDK 开发项目。
 ## 项目信息
 | 项目 | 值 |
 |------|-----|
 | 芯片代号 | hwd32h757 |
 | 内核 | Cortex-M7 |
 | 项目阶段 | Chip bring-up（回片测试） |
 | 仓库 | https://gitcode.com/tupingr/ai_soc_sw.git |
 ## 核心产出
 1. **寄存器功能测试** — 33 个功能单元的全面扫描
 2. **SDK 框架** — HAL/LL 双层驱动（参考 STM32CubeH7）
 3. **勘误记录** — 结构化硅缺陷追踪
 ## 协作模式
 1 人 + Arch AI + Worker AI，详见 [AGENTS.md](AGENTS.md)。
 ## 目录结构
 ```
 ai_soc_sw/
 ├── AGENTS.md                  # AI 角色定义与权限约定
 ├── dashboard.md               # 项目控制面板
 ├── DECISIONS.md               # 待决策事项
 ├── ENVIRONMENT.md             # 开发环境配置
 ├── .ai/                       # AI 协作核心
 │   ├── principles.md          # 设计原则
 │   ├── roles/                 # AI 角色身份卡
 │   ├── tasks/                 # 任务文件
 │   ├── phases/                # 阶段上下文
 │   └── knowledge/             # 知识沉淀（ADR/教训/模式）
 ├── Drivers/                   # SDK 驱动层
 │   ├── CMSIS/                 # ARM CMSIS + 设备文件
 │   ├── HWD32H757_HAL_Driver/ # HAL + LL 驱动
 │   └── BSP/                   # 板级支持包
 ├── Test/                      # 寄存器测试
 │   ├── framework/             # 测试框架
 │   ├── cases/                 # 33 个功能单元
 │   └── errata/                # 勘误记录
 ├── Tools/                     # 自动化工具
 ├── docs/                      # 项目文档
 └── Projects/                  # 示例工程
 ```
 ## 快速开始
 见 [ENVIRONMENT.md](ENVIRONMENT.md)。
@@ -0,0 +1,97 @@
 # hwd32h757 项目控制面板
 > 唯一真实来源。人类看顶部，Arch AI 看全文，Worker AI 看 task 文件。
 ---
 ## 人类区
 **芯片回片测试阶段** · 进度 0%
 | 阶段 | 功能单元 | 状态 | 进度 |
 |------|---------|------|------|
 | P0 | 电源管理/时钟/复位/GPIO/JTAG | 未开始 | 0% |
 | P1 | USART/SPI/I2C | 未开始 | 0% |
 | P2 | ADC/DAC/比较器/VREFBUF/温度/参考电压/Scaler | 未开始 | 0% |
 | P3 | Timer/HRTIM/LPTIM/看门狗 | 未开始 | 0% |
 | P4 | FMC/QSPI/SDMMC/DMA/DLYB | 未开始 | 0% |
 | P5 | USB/以太网/SAI/ULPI | 未开始 | 0% |
 | P6 | 电压监控/模拟开关升压/升压器/CRC/电流特性 | 未开始 | 0% |
 | SDK | CMSIS→LL→HAL→BSP→示例 | 未开始 | 0% |
 ### 需要你决策
 当前无待决策事项。
 ---
 ## Arch AI 区
 ### ADR 摘要索引
 | ADR | 一句话 | 状态 |
 |-----|--------|------|
 | 001 | 测试驱动SDK演进：寄存器测试→LL→HAL | ✅ |
 | 002 | HAL/LL双层架构，参考STM32CubeH7 | ✅ |
 | 003 | 33个功能单元分7阶段(P0-P6)bring-up | ✅ |
 ### Task 状态面板
 **当前无活跃任务。Arch AI 根据 bring-up 进度拆解任务。**
 **状态流转**: `todo → in_progress → done → verified → accepted`
 **交接信号**: Worker 完成 → commit message 包含 `[DONE]` → 人类硬件验证 → `[VERIFIED]`
 ### 依赖关系
 ```
 P0 (电源/时钟/复位/GPIO/JTAG)     ← 能跑起来的最低要求
  └→ P1 (USART/SPI/I2C)            ← 有了调试输出和基本通信
      └→ P2 (模拟链路)
      └→ P3 (定时器类)
      └→ P4 (存储和搬运)
          └→ P5 (高速接口)
 P6 (杂项) ← 可与P2-P5并行
 SDK ← P0完成后开始CMSIS，每个阶段完成后提炼LL/HAL
 ```
 ### 阻塞/风险
 | 级别 | 描述 | 影响 |
 |------|------|------|
 | — | 暂无 | — |
 ---
 ## 关键文档入口
 | 想查什么 | 路径 |
 |----------|------|
 | SDK架构参考 | `docs/sdk_design.md` |
 | 测试指南 | `docs/test_guide.md` |
 | 迁移指南 | `docs/porting_guide.md` |
 | ADR全文 | `.ai/knowledge/decisions.md` |
 | 经验教训 | `.ai/knowledge/lessons.md` |
 | 可复用模式 | `.ai/knowledge/patterns.md` |
 | 待人类决策 | `DECISIONS.md` |
 | 勘误记录 | `Test/errata/` |
 ---
 ## 角色入口
 | 角色 | 说明 | 入口 |
 |------|------|------|
 | 人类 | — | 本文件顶部「人类区」 |
 | Arch AI | 任何AI均可担当 | 本文件全文 |
 | Worker AI | 任何AI均可担当 | `.ai/roles/worker/card.md` → 对应 task 文件 |
 ---
 ## 最近事件
 | 日期 | 事件 |
 |------|------|
 | 2026-05-27 | 项目初始化，目录结构搭建 |
 *Arch AI 维护。阶段切换时更新。*
@@ -1,38 +0,0 @@
 {
  "name": "Arch AI",
  "role": "架构设计师",
  "description": "allowed_paths = 可写路径（含读）；read_only_paths = 只读路径；不在二者中的路径禁止访问。详细权限见 AGENTS.md 权限矩阵。",
  "responsibilities": [
    "需求分析和产品规划",
    "系统架构设计",
    "技术选型和评估",
    "跨模块协调和集成",
    "编写架构文档",
    "定义验收标准",
    "评估变更影响",
    "维护共享资源",
    "指导 Dev AI 和 QA AI 工作"
  ],
  "allowed_paths": [
    "docs/",
    "shared/",
    "projects/*/src/",
    "projects/*/docs/",
    "review/*/acceptance.md",
    "review/*/impact.md",
    "review/*/task.md",
    "tools/",
    "data/"
  ],
  "read_only_paths": [
    ".ai/",
    "projects/*/tests/",
    "reports/",
    "review/*/feedback/"
  ],
  "forbidden_paths": [],
  "prompt_templates": {
    "architecture": ".ai/prompts/architecture/",
    "documentation": ".ai/prompts/architecture/"
  }
 }
@@ -1,37 +0,0 @@
 {
  "name": "Dev AI",
  "role": "代码开发者",
  "description": "allowed_paths = 可写路径（含读）；read_only_paths = 只读路径；不在二者中的路径禁止访问。详细权限见 AGENTS.md 权限矩阵。",
  "responsibilities": [
    "编写业务代码",
    "生成技术文档",
    "维护项目级文档",
    "维护开发工具",
    "维护训练数据",
    "定义验收标准",
    "评估变更影响",
    "维护共享资源"
  ],
  "allowed_paths": [
    "projects/*/src/",
    "projects/*/docs/",
    "docs/",
    "tools/",
    "data/",
    "shared/",
    "review/*/acceptance.md",
    "review/*/impact.md"
  ],
  "read_only_paths": [
    "review/*/task.md",
    "review/*/feedback/"
  ],
  "forbidden_paths": [
    "projects/*/tests/",
    "reports/"
  ],
  "prompt_templates": {
    "coding": ".ai/prompts/coding/",
    "documentation": ".ai/prompts/coding/"
  }
 }
@@ -1,33 +0,0 @@
 {
  "name": "QA AI",
  "role": "测试工程师",
  "description": "allowed_paths = 可写路径（含读）；read_only_paths = 只读路径；不在二者中的路径禁止访问。详细权限见 AGENTS.md 权限矩阵。",
  "responsibilities": [
    "编写测试用例",
    "执行测试",
    "生成测试报告",
    "提供反馈"
  ],
  "allowed_paths": [
    "projects/*/tests/",
    "reports/",
    "review/*/acceptance.md",
    "review/*/feedback/"
  ],
  "read_only_paths": [
    "projects/*/src/",
    "projects/*/docs/",
    "docs/",
    "data/",
    "shared/",
    "review/*/task.md"
  ],
  "forbidden_paths": [
    ".ai/",
    "tools/",
    "review/*/impact.md"
  ],
  "prompt_templates": {
    "testing": ".ai/prompts/testing/"
  }
 }
@@ -1,48 +0,0 @@
 {
  "workflow": "human-ai-collaboration",
  "roles": ["human", "arch-ai", "dev-ai", "qa-ai"],
  "stages": [
    {
      "name": "需求分析",
      "actor": "arch-ai",
      "output": ["docs/01_产品需求/PRD.md", "review/{task_id}/task.md"]
    },
    {
      "name": "架构设计",
      "actor": "arch-ai",
      "input": ["docs/01_产品需求/PRD.md", "review/{task_id}/task.md"],
      "output": ["docs/02_系统架构/", "review/{task_id}/impact.md", "review/{task_id}/acceptance.md"]
    },
    {
      "name": "开发实现",
      "actor": "dev-ai",
      "input": ["review/{task_id}/task.md", "review/{task_id}/acceptance.md"],
      "output": ["projects/*/src/", "projects/*/docs/"]
    },
    {
      "name": "测试验证",
      "actor": "qa-ai",
      "input": ["review/{task_id}/task.md", "review/{task_id}/acceptance.md"],
      "output": ["projects/*/tests/", "reports/test-results/", "review/{task_id}/feedback/round{round}.md"]
    },
    {
      "name": "验收确认",
      "actor": "human",
      "input": ["review/{task_id}/feedback/", "reports/test-results/"]
    }
  ],
  "retry": {
    "max_rounds": 3,
    "loop": ["测试验证", "开发实现"],
    "escalation": {
      "trigger": "第 3 轮测试仍有 BLOCKER 或 HIGH 级别 Bug",
      "action": "暂停任务流转，等待人类负责人裁决"
    },
    "skip_acceptance_on_retry": true
  },
  "ci_triggers": {
    "on_push_to_main": ["run-tests", "generate-reports"],
    "on_pr_open": ["run-tests", "code-review"],
    "on_task_update": ["notify-qa-ai"]
  }
 }
@@ -1,111 +0,0 @@
 # 经验教训
 ## 目的
 记录开发过程中学到的东西。每条记录包含：
 - 上下文（我们在做什么）
 - 问题（出了什么问题/什么让我们意外）
 - 教训（学到了什么）
 - 行动（因此改变了什么）
 ---
 ## L-001: 单体 AGENTS.md 浪费 AI 上下文
 **日期**: 2026-05-25
 **上下文**: 项目启动阶段，每次 AI 会话都需要读 AGENTS.md 来了解角色和权限
 **问题**: AGENTS.md 239 行，约 80% 内容与当前 AI 角色无关。AI 有效上下文被大量无关信息占据
 **教训**: 为人类设计的文档结构不适用于 AI 的信息获取模式。AI 需要"最少必要信息"，而不是"全局完整视图"
 **行动**: 重构为分层信息架构：角色工作台 → 阶段上下文 → 知识沉淀。AI 只需读 2 个小文件即可开工
 ---
 ## 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-006: 当 AI 是执行者时，Skill 优于 Shell 脚本
 **日期**: 2026-05-26
 **上下文**: ADR-008 的「双分支 + sync-template.sh」模板同步方案，在新架构升级后 ai_project 分支严重过时。用户要求把脱敏模板价值提取到 main，放弃独立分支
 **问题**:
 - `sync-template.sh` 硬编码了旧架构的文件列表（DASHBOARD.md / ROADMAP.md / today.md / queue.md），框架一升级脚本就过时
 - 维护一个独立 Git 分支的成本 > 收益：需要手动切换分支、跑脚本、处理冲突
 - Shell 脚本的设计假设是「人类或 CI 执行」，但实际场景是 AI 执行。AI 不需要可执行脚本——AI 需要清晰的规格
 **教训**:
 1. **「用什么执行」决定「用什么描述」**。人/CI 执行 → 写脚本。AI 执行 → 写 Skill（语义描述 + 约束 + 边界定义）。Skill 描述「方法」，不会因文件路径变化而过时
 2. **边界定义文件是长期资产，执行脚本是短期负债**。SYNC.md 定义了什么属于框架、什么属于项目——这个定义独立于任何执行方式。脚本绑定了执行方式，框架一变就废
 3. **让 Git 做版本管理，让 Skill 做逻辑执行**。不需要为「脱敏」这个逻辑维护一个独立分支，Skill 从当前 main 实时执行脱敏，永远不过时
 4. **3 文件 > 4 文件 + 1 分支**。新方案：SYNC.md + TEMPLATE.yaml + Skill。旧方案：SYNC.md + TEMPLATE.yaml + sync-template.sh + init.sh + ai_project 分支
 **行动**:
 - ADR-008 标记废弃，新增 ADR-013
 - 废弃 sync-template.sh、init.sh、ai_project 分支
 - 保留并更新 SYNC.md（框架/项目边界），新增 TEMPLATE.yaml（变量定义），新增 project-init Skill
 ---
 ## 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 的每个任务需独立可读，不依赖前后文
@@ -1,142 +0,0 @@
 # 可复用模式
 ## 目的
 记录开发过程中发现的可持续复用的模式和做法。
 同样的模式出现 3 次以上时，应当记录在这里。
 ---
 ## P-001: AI 任务交接 (review/active/)
 **上下文**: AI 角色之间需要传递工作成果
 **问题**: 如何结构化任务交接，让任何 AI 都能接手
 **方案**: 标准化 `review/active/{任务ID}/` 结构：
 - `task.md` — 任务描述（Arch AI 定义）
 - `acceptance.md` — 验收标准（Arch AI + Dev AI + QA AI 共同维护）
 - `impact.md` — 变更影响范围（Arch AI + Dev AI 评估）
 - `feedback/` — 反馈记录（QA AI 提交）
 **何时用**: 每个跨 AI 角色的任务
 **何时不用**: 单角色任务（如纯文档更新、配置修改）
 ---
 ## P-002: 角色工作台 (daily task board)
 **上下文**: AI 每次会话需要快速进入工作状态
 **问题**: 从头探索项目结构浪费时间
 **方案**: `.ai/roles/{role}/today.md` 每日任务清单，AI 只需读 2 个文件（card + today）
 **何时用**: 每次 AI 会话
 **维护者**: Arch AI 负责分配，各 AI 自己更新完成状态
 ---
 ---
 ## P-003: 模板同步 (framework sync)
 **上下文**: 项目框架层（AGENTS/权限/提示词/工作流）的变化需要传播到通用模板分支
 **问题**: 手动同步耗时且容易遗漏，AI 重做去敏化消耗 ~100K tokens
 **方案**:
 - 双分支：`main`（具体项目）+ `ai_project`（通用模板）
 - `SYNC.md` 明确定义框架层/项目层文件边界
 - `sync-template.sh` 自动 checkout 框架文件 + 重新应用 {{变量}}
 - 框架层 ~15 个文件自动同步，project 层永久隔离
 **何时用**: main 分支框架有变化时
 **维护者**: Arch AI 触发，脚本执行
 ---
 ## 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 修复——分解成本 > 直接修复成本
 **本项目实例** (SoC_SW):
 ```
 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 记录
 - 决策讨论散落在任务 feedback 中 → 提炼到 knowledge/decisions.md
 - 大段文档内联而非链接 → 用链接 + 一句话摘要
@@ -1,17 +0,0 @@
 # 阶段索引
 | 阶段 | 名称 | 状态 | 目录 |
 |------|------|------|------|
 | 1 | 基础搭建 | DONE | `phase-01-foundation/` |
 | 2 | MVP | ACTIVE | `phase-02-mvp/` |
 | 3 | 功能完善 | PLANNED | `phase-03-features/` |
 | 4 | 打磨发布 | PLANNED | `phase-04-polish/` |
 ## 阶段切换规则
 1. 当前阶段 completion.md 全部打勾
 2. 人类签字确认
 3. Arch AI 更新本索引文件
 4. Arch AI 更新所有角色 card.md（当前阶段字段）
 5. Arch AI 更新 dashboard.md（进度条 + task 状态面板 + 最近事件）
 6. 产出阶段复盘（docs/share/phase-NN/）
@@ -1,6 +0,0 @@
 # 架构提示词模板
 | 文件 | 用途 |
 |------|------|
 | `architecture-design.md` | 系统架构设计模板 |
 | `technical-evaluation.md` | 技术选型评估模板 |
@@ -1,44 +0,0 @@
 # 系统架构设计模板
 ## 输入
 - 产品需求文档 (PRD)
 - 技术约束（已有技术栈、团队能力）
 - 非功能性需求（性能、安全、可扩展性）
 ## 输出结构
 ### 1. 架构概述
 - 一句话描述架构核心思路
 - 系统边界和范围
 ### 2. 架构图（文字描述 + ASCII）
 - 模块划分和职责
 - 模块间通信方式
 - 数据流向
 ### 3. 技术选型
 - 每个模块的技术栈及理由
 - 对比方案及淘汰原因
 - 风险点和缓解措施
 ### 4. 接口设计
 - 模块间接口定义
 - API 契约（请求/响应格式）
 - 数据模型概要
 ### 5. 非功能性设计
 - 性能目标及实现策略
 - 安全设计（认证、授权、数据保护）
 - 可扩展性考虑
 ### 6. 部署架构
 - 运行环境
 - 服务拓扑
 - CI/CD 流程
 ## 注意事项
 - 架构文档面向 Arch AI 和 Dev AI，不要写人类才需要的背景介绍
 - 决策必须写理由，方便后续 AI 理解为什么这样设计
 - 每个模块标注影响范围（HIGH/MEDIUM/LOW），供 QA AI 确定回归测试范围
@@ -1,41 +0,0 @@
 # 技术选型评估模板
 ## 输入
 - 需要解决的技术问题
 - 约束条件（预算、时间、团队、已有技术栈）
 ## 输出结构
 ### 1. 需求描述
 - 要解决什么问题
 - 关键约束是什么
 ### 2. 候选方案（2-4 个）
 每个方案描述：
 - 方案名称和简介
 - 优势（3-5 条）
 - 劣势（3-5 条）
 - 与本项目技术栈的兼容度
 ### 3. 评估维度
 | 维度 | 权重 | 方案A | 方案B | 方案C |
 |------|------|-------|-------|-------|
 | 性能 | 30% | — | — | — |
 | 生态成熟度 | 25% | — | — | — |
 | 学习曲线 | 20% | — | — | — |
 | 社区活跃度 | 15% | — | — | — |
 | 团队熟悉度 | 10% | — | — | — |
 | **加权总分** | 100% | — | — | — |
 ### 4. 推荐方案
 - 推荐哪个、为什么
 - 主要风险
 - 如果失败，备选方案是什么
 ## 注意事项
 - 评估维度可调整，但必须说明理由
 - 不追求"最优"，追求"最适合当前阶段"
@@ -1,6 +0,0 @@
 # Dev AI 提示词库
 | 文件 | 说明 |
 |------|------|
 | [code-style.md](code-style.md) | 代码风格、命名规范、目录组织 |
 | [doc-template.md](doc-template.md) | impact.md / acceptance.md 等文档模板 |
@@ -1,105 +0,0 @@
 # Dev AI 代码风格规范
 ## 适用技术栈
 | 层 | 技术 | 语言 |
 |-----|------|------|
 | 前端 | Taro 4 + React 18 | TypeScript 5.x |
 | 样式 | Tailwind CSS 4 | — |
 | 后端 | NestJS 10 | TypeScript 5.x |
 | 训练 | PyTorch 2.0 | Python 3.10+ |
 ---
 ## 1. 文件命名
 | 类型 | 规则 | 示例 |
 |------|------|------|
 | 页面组件 | kebab-case | `error-detail.tsx` |
 | UI 组件 | kebab-case | `button.tsx` |
 | 工具函数 | kebab-case | `format-date.ts` |
 | 类型定义 | kebab-case | `error-entry.d.ts` |
 | NestJS 模块 | kebab-case | `auth.module.ts` |
 | Python 模块 | snake_case | `data_loader.py` |
 ## 2. 目录组织（前端）
 ```
 src/
 ├── pages/{page-name}/     # 页面 —— 一个目录一个页面
 │   ├── index.tsx
 │   ├── index.config.ts
 │   └── index.css
 ├── components/            # 通用组件
 │   └── {component-name}/
 │       └── index.tsx
 ├── lib/                   # 工具函数、hooks
 ├── types/                 # 全局类型声明
 ├── server/                # NestJS 后端
 └── config/                # Taro 构建配置
 ```
 ## 3. 目录组织（NestJS 后端）
 ```
 src/server/src/
 ├── modules/{name}/        # 一个模块一个目录
 │   ├── {name}.module.ts
 │   ├── {name}.controller.ts
 │   ├── {name}.service.ts
 │   ├── dto/
 │   └── entities/
 ├── common/                # 共享：拦截器、守卫、管道
 └── main.ts
 ```
 ## 4. 命名风格
 **TypeScript：**
 - 组件：PascalCase —— `ErrorCard`
 - 函数/变量：camelCase —— `getUserProfile`
 - 常量：UPPER_SNAKE —— `MAX_PAGE_SIZE`
 - 接口/类型：PascalCase —— `ErrorEntry`
 **Python：**
 - 类：PascalCase —— `DataLoader`
 - 函数/变量：snake_case —— `load_dataset`
 - 常量：UPPER_SNAKE —— `BATCH_SIZE`
 ## 5. 导入顺序（TypeScript）
 ```
 1. 第三方库
 2. Taro 相关
 3. 项目内部（@/ 别名）
 4. 相对路径
 5. 样式文件
 ```
 示例：
 ```typescript
 import { useState } from 'react';
 import Taro from '@tarojs/taro';
 import { Button } from '@/components/ui/button';
 import { formatDate } from './lib/date';
 import './index.css';
 ```
 ## 6. 组件规范
 - 优先使用函数组件，不用 class 组件
 - 一个文件只有一个 export default 组件
 - 组件 props 必须声明类型接口
 - 跨端兼容：避免使用 `document`、`window`（用 Taro API 代替）
 ## 7. API 调用规范
 - 前端统一使用 `@/network.ts` 中的 `Network.request`，不要直接调用 `Taro.request`
 - 后端Controller 只做参数校验和路由，业务逻辑放在 Service
 - API 响应统一使用 Envelope 格式 `{ code, msg, data }`
 ## 8. 不能做的事
 - 不要在 `src/` 下写测试文件（测试在 `tests/`）
 - 不要引入未经 package.json 声明的依赖
 - 不要在组件中硬编码后端地址（用 `PROJECT_DOMAIN` 全局变量）
@@ -1,76 +0,0 @@
 # Dev AI 文档模板
 下面三个模板用于 Dev AI 在 `review/{task_id}/` 下产出标准化文件。
 ---
 ## A. impact.md 模板（变更影响范围）
 ```markdown
 # {TASK_ID} - 变更影响范围
 ## 修改的文件
 | 文件路径 | 修改类型 | 影响等级 |
 |---------|---------|---------|
 | projects/P01_soc_sw_app/src/server/src/modules/auth/auth.service.ts | 新增 | HIGH |
 | projects/P01_soc_sw_app/src/server/src/modules/auth/dto/login.dto.ts | 新增 | MEDIUM |
 > 影响等级：HIGH=核心逻辑变更 | MEDIUM=新增文件 | LOW=注释/格式
 ## 影响的功能模块
 - [x] 用户认证模块
 - [ ] 芯片验证模块（无影响）
 ## 需要回归测试的场景
 - 场景1: 用户登录成功流程
 - 场景2: 密码错误返回 401
 - 场景3: Token 过期后刷新
 ## 环境依赖变更
 - 新增依赖: bcrypt, @nestjs/jwt
 - 数据库迁移: 新增 users 表
 ```
 **要点：**
 - `修改的文件` 必须使用从仓库根目录开始的完整路径
 - 影响等级要实事求是，不要全写 HIGH
 - `需要回归测试的场景` 要写**用户视角**的场景，不是代码内部细节
 ---
 ## B. acceptance.md 模板（验收标准）
 ```markdown
 # {TASK_ID} - 验收标准
 ## 功能验收
 - [ ] 用户可以注册新账户（邮箱+密码）
 - [ ] 密码强度不足时提示明确错误信息
 - [ ] 登录成功返回有效 JWT Token
 ## 非功能验收
 - [ ] API 响应时间 < 200ms
 - [ ] 密码使用 bcrypt 加密存储
 - [ ] JWT Token 有效期 24 小时
 ## 测试覆盖要求
 - 单元测试覆盖率: >= 80%
 - 集成测试覆盖率: >= 60%
 - E2E 测试场景: >= 3 个
 ## 验收通过条件
 - 所有功能点验证通过
 - 测试覆盖率达标
 - 无重大安全漏洞
 ```
 **要点：**
 - 功能验收用「用户可以…」句式，让 QA AI 和人类都能看懂
 - 每个功能点对应 task.md 里的一项交付物
 - 非功能验收写具体的可测量指标，不要写「性能好」「代码整洁」
 ---
 ## C. 没有 task.md 模板
 task.md 由人类负责人创建，Dev AI 只读不写。Dev AI 如需补充技术细节，写在 impact.md 的「技术备注」段落中，不要直接修改 task.md。
@@ -1,5 +0,0 @@
 # QA AI 提示词库
 | 文件 | 说明 |
 |------|------|
 | [bug-report.md](bug-report.md) | 测试反馈 / Bug 报告模板与格式规范 |
@@ -1,67 +0,0 @@
 # QA AI Bug 报告模板
 以下模板用于 QA AI 在 `review/{task_id}/feedback/round{round}.md` 中提交测试反馈。
 ---
 ## 模板
 ```markdown
 # {TASK_ID} - 第 {N} 轮测试反馈
 ## 基本信息
 - 测试时间: YYYY-MM-DD
 - 测试项目: P01_soc_sw_app / P02_soc_sw_training / P03_soc_sw_web
 - 测试环境: Node 20.x / Python 3.10
 ## 测试结果概览
 | 指标 | 数值 |
 |------|------|
 | 测试用例总数 | N |
 | 通过 | N |
 | 失败 | N |
 | 跳过 | N |
 | 代码覆盖率 | XX% |
 ## 失败用例清单
 ### Bug #1: {简短标题}
 - **严重程度**: BLOCKER / HIGH / MEDIUM / LOW
 - **涉及文件**: `projects/...`（完整路径）
 - **测试场景**: 用户登录时输入正确密码
 - **预期结果**: 返回 200 和 JWT Token
 - **实际结果**: 返回 500 Internal Server Error
 - **复现步骤**:
  1. POST /api/auth/login
  2. body: {"email": "test@example.com", "password": "correct"}
 - **建议修复**: 检查 auth.service.ts 第 42 行的异常处理
 ### Bug #2: ...
 （同上格式）
 ## 改进建议（非 Bug）
 - 建议 1: 登录接口缺少限流保护
 - 建议 2: 密码重置的邮件模板可以更友好
 ## 下一步
 - [ ] Dev AI 修复上述 Bug 后，QA AI 进行第 {N+1} 轮测试
 - [ ] 如第 3 轮仍未通过，升级给人类负责人裁决
 ```
 ---
 ## 严重程度定义
 | 级别 | 含义 | 举例 |
 |------|------|------|
 | BLOCKER | 核心功能不可用，无法继续测试 | 登录接口直接崩溃、数据库连不上 |
 | HIGH | 功能逻辑错误，用户无法正常使用 | 登录成功但不返回 Token |
 | MEDIUM | 功能可用但与预期有偏差 | 返回的日期格式不对、错误码不对 |
 | LOW | 不影响功能的瑕疵 | 提示文案不友好、缺少空值校验 |
 ## 规则
 1. **每轮反馈用新文件**：`round1.md` → `round2.md` → `round3.md`
 2. **最多 3 轮**：第 3 轮仍有 BLOCKER/HIGH Bug → 在报告中标注「建议人类负责人介入」
 3. **涉及文件必须用完整路径**：从仓库根目录开始，方便 Dev AI 定位
 4. **改进建议不要超过 3 条**：聚焦最重要的
@@ -1,57 +0,0 @@
 # AI 角色工作台
 ## 三层架构
 ```
 控制面板 (dashboard.md)     → 人类 + Arch AI 共享入口，项目唯一真实来源
    ↓ Arch AI 拆解任务
 执行层  (.ai/tasks/active/)  → Coder/Tester 各自独立 task 文件，自包含
 ```
 ## 四个角色入口
 | 角色 | 平台+模型 | 入口 | 读几个文件 |
 |------|----------|------|-----------|
 | 人类 | — | [dashboard.md](../../dashboard.md) 顶部「人类区」 | 1 |
 | Arch AI | Claude Code + DeepSeek V4 Pro | [dashboard.md](../../dashboard.md) 全文 | 1 |
 | Coder AI | Trae CN + GLM-4.6 | [card.md](dev/card.md) → 对应 task 文件 | 2 |
 | Tester AI | Coze CN | [card.md](qa/card.md) → 对应 task 文件 | 2 |
 ## 使用方式
 **Arch AI**:
 ```
 1. 读 dashboard.md → 了解全貌 + ADR 摘要 + task 状态
 2. 需要细节 → 按链接按需加载
 3. 人类决策 → 读 DECISIONS.md
 4. 拆分新任务 → 按模板写 .ai/tasks/active/P01-XXX.md
 5. 完成后 → 更新 dashboard.md task 状态
 ```
 **Coder AI (Trae + GLM-4.6)**:
 ```
 1. 读 card.md → 身份+权限
 2. 读对应 task 文件 → 输入/输出/约束/验收方法
 3. 写代码
 4. 自验 → 填写完成报告 → commit [READY_FOR_TEST]
 ```
 **Tester AI (Coze)**:
 ```
 1. git pull + 读 card.md
 2. git log --grep="READY_FOR_TEST" → 找待测 task
 3. 读对应 Tester task 文件 → 测试内容/执行方式/报告格式
 4. 拉代码 → 沙盒执行 → 生成 JSON 报告
 5. commit 报告
 ```
 ## 关键原则
 1. **每个角色只有一个入口文件** — 不拼图，不切换
 2. **Worker AI 不需要知道项目全貌** — task 文件就是它的全部世界
 3. **Git 是唯一的集成总线** — 跨平台交接通过 commit message 信号
 4. **弱模型适配强约束** — 给 GLM-4.6 的任务 = 单文件粒度，零隐含上下文
 ## 归档
 旧的 DASHBOARD.md / ROADMAP.md / roles/*/today.md / roles/*/queue.md → `.ai/archive/`
@@ -1,43 +0,0 @@
 # Arch AI — 架构师
 ## 身份
 我是架构 AI。负责需求分析、架构设计、技术选型、任务分解。
 **平台**: Claude Code + DeepSeek V4 Pro（最强推理 + Agent 框架）
 ## 启动流程
 1. 读 `dashboard.md` 全文（< 2K tokens）→ 项目全貌 + ADR 索引 + task 状态面板
 2. 需要细节 → 按 dashboard 中的链接按需加载
 3. 人类决策 → 读 `DECISIONS.md`
 4. 完成任务 → 更新 dashboard.md + 对应 ADR/knowledge 文件
 ## 当前阶段
 Phase 1: 基础搭建 — `dashboard.md`
 ## 核心交付物
 - 产品需求 + 系统架构设计
 - 技术选型 + 架构决策 (ADR)
 - 任务分解 → `.ai/tasks/active/P01-XXX.md`
 - 跨模块协调（Coder ↔ Tester 交接协议）
 - 人类决策梳理 → `DECISIONS.md`
 ## 关键入口
 | 文件 | 说明 |
 |------|------|
 | `dashboard.md` | 唯一控制面板（替代旧 DASHBOARD.md / ROADMAP.md） |
 | `DECISIONS.md` | 待人类决策事项 |
 | `.ai/knowledge/decisions.md` | ADR 全文 |
 | `.ai/knowledge/lessons.md` | 经验教训 |
 | `.ai/knowledge/patterns.md` | 可复用模式 |
 | `.ai/tasks/active/` | 所有活跃 task 文件 |
 ## 权限
 **可写**: docs/ shared/ projects/*/src/ projects/*/docs/ .ai/tasks/ .ai/knowledge/ dashboard.md DECISIONS.md
 **只读**: projects/*/tests/ reports/
 **禁止**: 无
@@ -1,40 +0,0 @@
 # Dev AI — 开发者
 ## 身份
 我是开发 AI。负责编写业务代码、技术文档、Bug 修复。
 **平台**: Trae CN + GLM-4.6（代码生成 + 文件操作，单文件粒度）
 ## 启动流程
 1. 读本文件（card.md）→ 我是谁、权限、当前阶段
 2. 读 dashboard.md → 找到自己对应的 task（状态为 `todo` 的 Coder 任务）
 3. 打开对应 task 文件（如 `.ai/tasks/active/P01-001.md`）→ **这就是你的全部世界**
 4. 按 task 文件中的「输入」「输出」「约束」「验收方法」执行
 5. 完成后 → 填写 task 文件的「完成报告」→ commit（message 含 `[READY_FOR_TEST]`）
 **不需要**读 ADR 全文、知识库、或其他 task 文件。你的 task 文件已经包含了完成任务所需的全部信息。
 ## 当前阶段
 Phase 1: 基础搭建
 ## 核心交付物
 - 业务代码实现 (projects/*/src/)
 - 项目文档 (projects/*/docs/)
 ## 关键入口
 | 文件 | 说明 |
 |------|------|
 | `dashboard.md` | 查找自己的 task |
 | `.ai/tasks/active/P01-XXX.md` | 你的 task 文件（开工时读这个） |
 | `.ai/tasks/templates/TASK_TEMPLATE_CODER.md` | task 格式说明 |
 ## 权限
 **可写**: projects/*/src/ projects/*/docs/ docs/ tools/ data/ shared/
 **只读**: review/*/task.md review/*/feedback/ .ai/tasks/active/
 **禁止**: projects/*/tests/ reports/
@@ -1,42 +0,0 @@
 # QA AI — 测试者
 ## 身份
 我是测试 AI。负责在 Coze 沙盒中拉取代码、执行测试、生成报告。
 **平台**: Coze CN（沙盒执行 + 自动化测试）
 ## 启动流程
 1. 读本文件（card.md）→ 我是谁、权限
 2. `git pull` → 拉取最新代码
 3. `git log --oneline --grep="READY_FOR_TEST"` → 查找待测试的 task
 4. 打开对应 Tester task 文件（如 `.ai/tasks/active/T01-XXX.md`）→ **这就是你的全部世界**
 5. 按 task 文件中的「测试目标」「测试内容」「执行方式」执行
 6. 生成测试报告 → `reports/{编号}-{日期}.json`
 7. 填写 task 文件的「完成报告」→ commit
 **关键**: 你不需要知道项目全貌、不需要读架构文档、不需要读 ADR。你的 task 文件 + 被测代码 = 你需要的一切。
 ## 当前阶段
 Phase 1: 基础搭建
 ## 核心交付物
 - 测试报告 (reports/)
 - Bug 反馈（在测试报告中标注 FAIL 项）
 ## 关键入口
 | 文件 | 说明 |
 |------|------|
 | `dashboard.md` | 查找自己的 task |
 | `.ai/tasks/active/T01-XXX.md` | 你的 task 文件（开工时读这个） |
 | `.ai/tasks/templates/TASK_TEMPLATE_TESTER.md` | task 格式说明 |
 ## 权限
 **可写**: projects/*/tests/ reports/
 **只读**: projects/*/src/ projects/*/docs/ docs/ data/ shared/ .ai/tasks/active/
 **禁止**: .ai/ tools/
@@ -1,47 +0,0 @@
 # Task {编号}: {标题}
 ## 元信息
 | 字段 | 值 |
 |------|-----|
 | 状态 | `todo` → `in_progress` → `done` → `tested` → `accepted` |
 | 优先级 | P0 / P1 / P2 |
 | 依赖 | {上游 task 编号，无则写「无」} |
 | 分配给 | Coder AI (Trae CN + GLM-4.6) |
 ## 输入
 **要读的文件**:
 - `{完整路径}` — {一句话说明}
 **参考的 ADR**:
 - ADR-XXX: {一句话说明关联}
 **上游依赖产出**:
 - {上游 task 编号}: {产出是什么}
 ## 输出
 **要生成/修改的文件**:
 - `{完整路径}` — {说明}
 - `{完整路径}` — {说明}
 **验收方法**:
 ```bash
 {具体命令或步骤，Coder 可以自己跑来验证}
 ```
 ## 约束
 - 不碰: `{目录路径}`
 - 技术栈: {库/版本}
 - 遵循: `{规范文件}`
 ## 完成报告
 > Coder 完成后填写。Commit message 以 `[READY_FOR_TEST]` 结尾。
 - [ ] 输出文件已生成
 - [ ] 验收命令通过
 - [ ] Commit: `{hash}`
 - [ ] Commit message: `feat({编号}): {描述} [READY_FOR_TEST]`
@@ -1,75 +0,0 @@
 # Task {编号}: {标题}
 ## 元信息
 | 字段 | 值 |
 |------|-----|
 | 状态 | `todo` → `in_progress` → `done` → `accepted` |
 | 优先级 | P0 / P1 / P2 |
 | 对应 Coder task | {P01-XXX} |
 | 分配给 | Tester AI (Coze CN) |
 ## 测试目标
 {一句话 —— 验证什么功能/模块}
 ## 被测对象
 **Coder 产出的 commit**:
 - 从 git log 查找 commit message 包含 `[READY_FOR_TEST]` 且 task 编号为 `{编号}` 的最新 commit
 - 或直接读 `.ai/roles/dev/card.md` 里指定的代码目录
 **Coder task 文件**:
 - [P01-XXX]({路径}) — 理解该 task 的输入/输出/约束
 ## 测试内容
 **关键路径**:
 - [ ] {关键路径 1}
 - [ ] {关键路径 2}
 - [ ] {边界条件}
 **不应发生的**:
 - [ ] {错误情况 1}
 ## 执行方式
 ```
 1. git pull → 拉取最新代码
 2. 在 Coze 沙盒中执行测试
 3. 生成测试报告
 ```
 ## 报告格式
 输出 `reports/{编号}-{日期}.json`:
 ```json
 {
  "task": "{编号}",
  "date": "{YYYY-MM-DD}",
  "summary": {
    "total": {N},
    "passed": {N},
    "failed": {N}
  },
  "results": [
    {
      "case": "{用例名}",
      "status": "pass|fail",
      "details": "{失败时的详细信息}"
    }
  ],
  "conclusion": "PASS|FAIL|RETRY"
 }
 ```
 ## 完成报告
 > Tester 完成后填写。
 - [ ] 测试已执行
 - [ ] 报告已生成 → `reports/{编号}-{日期}.json`
 - [ ] Commit: `{hash}`
 - [ ] Commit message: `test({编号}): {结论}`
 - [ ] 结论: PASS / FAIL / RETRY
@@ -1,253 +0,0 @@
 ---
 name: "add-subproject"
 description: "Adds a new subproject to the existing '1 Human + 2 AI' collaboration framework. Invoke when you need to add a new subproject like web admin, data entry program, etc."
 ---
 # 添加子项目 Skill
 ## 功能
 在现有的"1人+2AI"协作框架中动态添加新的子项目，自动创建：
 - 项目目录结构（src/、tests/、docs/）
 - 环境配置文件（ENVIRONMENT.md）
 - README.md 占位文件
 - 示例任务目录（含 task.md、acceptance.md、impact.md、feedback/）
 ## 使用方法
 ### 参数说明
 | 参数 | 类型 | 必填 | 说明 |
 |------|------|------|------|
 | project_name | string | 是 | 子项目名称，如 "web_admin"、"data_entry" |
 | project_number | string | 否 | 项目编号，如 "P03"，默认自动生成 |
 ### 调用方式
 ```bash
 # 方式1：仅提供项目名称（自动分配编号）
 # skill 会自动检测现有项目编号，分配下一个编号
 add-subproject --project_name="web_admin"
 # 方式2：指定项目编号
 add-subproject --project_name="web_admin" --project_number="P03"
 ```
 ## 创建的内容
 ### 目录结构
 ```
 projects/
 └── P03_web_admin/              # 新项目目录
    ├── src/                    # Dev AI 工作区
    │   ├── server/             # NestJS 后端（如需要）
    │   ├── config/             # 构建配置
    │   ├── types/              # 全局类型
    │   └── README.md
    ├── tests/                  # QA AI 工作区
    │   └── README.md
    ├── docs/                   # 项目文档
    │   ├── 01_需求概要.md
    │   ├── 02_架构设计.md
    │   └── 03_接口定义.md
    └── ENVIRONMENT.md          # 环境配置
 ```
 ### 任务目录
 ```
 review/
 └── active/
    └── P03-001/                # 新项目的第一个任务
        ├── task.md             # 任务描述（人类创建，AI 只读）
        ├── acceptance.md       # 验收标准
        ├── impact.md           # 变更影响范围
        └── feedback/           # 测试反馈
            └── round1.md
 ```
 ## 执行命令
 ```bash
 # 获取下一个项目编号（PowerShell 兼容版本）
 get_next_project_number() {
  # 兼容 Linux/macOS
  if command -v ls >/dev/null 2>&1; then
    ls -la projects/ | grep -E '^P[0-9]+_' | sort | tail -1 | sed 's/P\([0-9]*\)_.*$/\1/'
  # 兼容 Windows PowerShell
  elif command -v powershell >/dev/null 2>&1; then
    powershell -Command "(Get-ChildItem projects -Directory | Where-Object { $_.Name -match '^P\d+_' } | Sort-Object Name | Select-Object -Last 1).Name -replace 'P(\d+)_.*', '$1'"
  else
    echo "0"
  fi
 }
 # 创建项目目录
 PROJECT_NAME="web_admin"
 NEXT_NUM=$(get_next_project_number)
 PROJECT_NUM="P$(printf '%02d' $((NEXT_NUM + 1)))"
 PROJECT_DIR="projects/${PROJECT_NUM}_${PROJECT_NAME}"
 mkdir -p "${PROJECT_DIR}"/{src/{server,config,types},tests,docs}
 # 创建 ENVIRONMENT.md
 cat > "${PROJECT_DIR}/ENVIRONMENT.md" << EOF
 # ${PROJECT_NUM}_${PROJECT_NAME} - 环境准备
 ## 依赖
 - Node.js >= 20.x
 - pnpm >= 9.0.0
 ## 安装
 pnpm install
 ## 运行
 pnpm dev
 EOF
 # 创建文档
 cat > "${PROJECT_DIR}/docs/01_需求概要.md" << EOF
 # ${PROJECT_NUM}_${PROJECT_NAME} - 需求概要
 ## 项目概述
 ## 功能需求
 ## 非功能需求
 EOF
 cat > "${PROJECT_DIR}/docs/02_架构设计.md" << EOF
 # ${PROJECT_NUM}_${PROJECT_NAME} - 架构设计
 ## 技术选型
 ## 架构图
 ## 模块划分
 EOF
 cat > "${PROJECT_DIR}/docs/03_接口定义.md" << EOF
 # ${PROJECT_NUM}_${PROJECT_NAME} - 接口定义
 ## API 列表
 ## 数据结构
 EOF
 # 创建 README.md
 echo "# ${PROJECT_NAME} - src" > "${PROJECT_DIR}/src/README.md"
 echo "# ${PROJECT_NAME} - tests" > "${PROJECT_DIR}/tests/README.md"
 # 创建示例任务
 mkdir -p "review/active/${PROJECT_NUM}-001/feedback"
 cat > "review/active/${PROJECT_NUM}-001/task.md" << EOF
 # ${PROJECT_NUM}-001 - 项目初始化
 ## 任务信息
 - 任务编号：${PROJECT_NUM}-001
 - 项目：${PROJECT_NUM}_${PROJECT_NAME}
 - 创建时间：$(date +%Y-%m-%d)
 - 状态：TODO
 ## 任务描述
 完成 ${PROJECT_NAME} 项目的初始化工作。
 ## 交付物
 - 项目目录结构
 - 基础配置文件
 - README 文档
 EOF
 cat > "review/active/${PROJECT_NUM}-001/acceptance.md" << EOF
 # ${PROJECT_NUM}-001 - 验收标准
 ## 功能验收
 - [ ] 项目目录结构完整
 - [ ] ENVIRONMENT.md 已创建
 - [ ] 文档目录已初始化
 ## 测试覆盖要求
 - 无需测试（初始化任务）
 EOF
 cat > "review/active/${PROJECT_NUM}-001/impact.md" << EOF
 # ${PROJECT_NUM}-001 - 变更影响范围
 ## 修改的文件
 | 文件路径 | 修改类型 | 影响等级 |
 |---------|---------|---------|
 | ${PROJECT_DIR}/ | 新增 | LOW |
 ## 影响的功能模块
 - [x] 项目初始化
 ## 需要回归测试的场景
 - 无（新项目）
 ## 环境依赖变更
 - 无
 EOF
 cat > "review/active/${PROJECT_NUM}-001/feedback/round1.md" << EOF
 # ${PROJECT_NUM}-001 - 第一轮测试反馈
 ## 基本信息
 - 测试时间: $(date +%Y-%m-%d)
 - 测试项目: ${PROJECT_NUM}_${PROJECT_NAME}
 - 测试环境: 待配置
 ## 测试结果概览
 | 指标 | 数值 |
 |------|------|
 | 测试用例总数 | 0 |
 | 通过 | 0 |
 | 失败 | 0 |
 | 跳过 | 0 |
 | 代码覆盖率 | 0% |
 ## 反馈
 待 Dev AI 完成开发后执行测试
 EOF
 # 更新 README.md（如果存在）
 if [ -f README.md ]; then
  echo "- [${PROJECT_NUM}_${PROJECT_NAME}](${PROJECT_DIR})" >> README.md
 fi
 echo "✅ 子项目 ${PROJECT_NUM}_${PROJECT_NAME} 创建成功！"
 echo "📖 请阅读 AGENTS.md 了解协作规则"
 echo "🚀 在 review/active/${PROJECT_NUM}-001/ 下查看示例任务结构"
 ```
 ## 使用场景
 **何时调用此 skill：**
 - ✅ 添加新的 Web 管理程序
 - ✅ 添加数据录入程序
 - ✅ 添加任何新的子项目模块
 - ✅ 扩展现有项目架构
 **不适用场景：**
 - ❌ 项目尚未初始化（需先调用 ai-collab-setup）
 - ❌ 修改现有项目结构
 ## 后续步骤
 skill 执行后：
 1. 检查 `projects/${PROJECT_NUM}_${PROJECT_NAME}/` 目录结构
 2. 阅读 `review/active/${PROJECT_NUM}-001/task.md` 示例任务
 3. 根据实际需求修改 `task.md` 为真实任务
 4. Dev AI 开始开发
 ---
 **Version**: 2.0  
 **Created**: 2026-05-22  
 **Updated**: 2026-05-23  
 **Based On**: SoC_SW AI Programming Project  
 **Changes from v1**: 
 - 目录结构新增 src/server/、src/config/、src/types/ 子目录
 - 示例任务增加完整的 feedback/round1.md 格式（含基本信息表格）
 - impact.md 增加「影响的功能模块」和「环境依赖变更」段落
 - 脚本兼容 Windows PowerShell 和 Linux/macOS
 - ENVIRONMENT.md 默认使用 pnpm 包管理器
@@ -1,173 +0,0 @@
 ---
 name: "git"
 description: "Wraps common git operations as parameterized actions. Invoke when user wants to commit, push, pull, branch, or check git status."
 ---
 # Git Skill
 ## 功能
 将常用 git 操作封装为参数化动作，避免频繁手动提交，统一管理版本控制。
 ## 触发条件
 - 用户要求提交代码
 - 用户要求查看状态/日志/差异
 - 用户要求创建/切换分支
 - 用户要求拉取/推送代码
 - 用户要求回退/重置
 ## 参数说明
 | 参数 | 说明 | 示例 |
 |------|------|------|
 | `action` | 操作类型 | status, add, commit, push, pull, branch, log, diff, stash, reset |
 | `message` | 提交信息（commit 时必填） | "feat(P01-001): 实现用户登录" |
 | `branch` | 分支名（branch/push/pull 时使用） | feature/P01-001-login |
 | `files` | 指定文件（add 时使用，默认全部） | ["src/login.ts", "tests/login.test.ts"] |
 | `force` | 强制操作（push/reset 时使用） | true/false |
 | `count` | 日志条数（log 时使用） | 10 |
 ## 操作类型
 ### 1. status - 查看状态
 ```bash
 git status
 git status -s  # 简洁模式
 ```
 **输出**：显示已修改、已暂存、未跟踪的文件
 ### 2. add - 添加文件
 ```bash
 git add -A              # 添加所有变更
 git add <files>         # 添加指定文件
 git add -p              # 交互式选择（逐块确认）
 ```
 ### 3. commit - 提交
 **提交信息格式**（必须遵循 AGENTS.md 命名规范）：
 ```
 <type>(<scope>): <subject>
 <body>
 <footer>
 ```
 | type | 说明 |
 |------|------|
 | feat | 新功能 |
 | fix | Bug 修复 |
 | docs | 文档更新 |
 | style | 代码格式（不影响功能） |
 | refactor | 重构 |
 | test | 测试相关 |
 | chore | 构建/工具链 |
 **示例**：
 ```
 feat(P01-001): 实现用户登录功能
 - 添加登录页面组件
 - 实现微信授权登录
 - 添加登录状态管理
 Closes #123
 ```
 ### 4. push - 推送
 ```bash
 git push                          # 推送到当前分支
 git push origin <branch>          # 推送到指定分支
 git push -u origin <branch>       # 首次推送并设置上游
 git push --force                  # 强制推送（谨慎使用）
 ```
 ### 5. pull - 拉取
 ```bash
 git pull                          # 拉取并合并
 git pull --rebase                 # 拉取并变基
 ```
 ### 6. branch - 分支管理
 ```bash
 git branch                        # 查看本地分支
 git branch -a                     # 查看所有分支
 git branch <name>                 # 创建分支
 git checkout <name>               # 切换分支
 git checkout -b <name>            # 创建并切换
 git branch -d <name>              # 删除分支
 ```
 ### 7. log - 查看日志
 ```bash
 git log --oneline -<count>        # 简洁日志
 git log --graph --oneline         # 图形化
 git log --since="2026-05-20"      # 按日期过滤
 ```
 ### 8. diff - 查看差异
 ```bash
 git diff                          # 未暂存变更
 git diff --cached                 # 已暂存变更
 git diff HEAD                     # 所有变更
 git diff <file>                   # 指定文件
 ```
 ### 9. stash - 暂存
 ```bash
 git stash                         # 暂存当前变更
 git stash list                    # 查看暂存列表
 git stash pop                     # 恢复最新暂存
 git stash apply <stash@{n}>       # 应用指定暂存
 ```
 ### 10. reset - 重置
 ```bash
 git reset --soft HEAD~1           # 撤销提交，保留变更
 git reset --mixed HEAD~1          # 撤销提交，变更回暂存区
 git reset --hard HEAD~1           # 撤销提交，丢弃变更（危险）
 ```
 ## 执行流程
 ### 提交流程（commit + push）
 1. `git status` - 查看当前状态
 2. `git add -A` 或 `git add <files>` - 添加文件
 3. `git diff --cached` - 确认变更内容
 4. `git commit -m "<message>"` - 提交
 5. `git push` - 推送（如用户要求）
 ### 分支创建流程
 1. `git branch` - 查看当前分支
 2. `git checkout -b <branch>` - 创建并切换
 3. 提示用户后续提交将在此分支进行
 ## 注意事项
 1. **提交频率**：不要每改一个文件就提交，按功能/任务粒度提交
 2. **提交信息**：必须遵循 AGENTS.md 命名规范，包含项目编号和任务编号
 3. **推送前确认**：推送前必须让用户确认，除非明确要求
 4. **强制推送**：必须明确警告用户，确认后才能执行
 5. **冲突处理**：遇到合并冲突时，先展示冲突文件，让用户决定如何处理
 6. **文档同步**：代码提交后，提醒用户使用 `update-docs` Skill 同步文档
 ---
 **Version**: 1.0  
 **Created**: 2026-05-23  
 **Based On**: SoC_SW AI Programming Project  
 **Purpose**: 统一管理 git 操作，避免频繁提交，确保提交信息规范
@@ -1,107 +0,0 @@
 ---
 name: "project-init"
 description: "框架脱敏/初始化：将当前项目框架层导出为通用模板，或从模板初始化新项目。用户说「导出框架」「初始化新项目」「套这个框架开新项目」时调用。"
 ---
 # 项目框架脱敏与初始化
 ## 功能
 将当前项目的「框架层」（AI 协作体系）与「项目层」（SoC_SW 具体内容）分离。框架层可导出为通用模板，用于初始化任意新项目。
 **核心逻辑**：框架是骨架（角色、权限、工作流、Skill），项目是肉（PRD、架构、代码、ADR）。同一套骨架可以长出不同的肉。
 ## 触发条件
 - 用户说「导出框架」「脱敏」「生成模板」
 - 用户说「初始化新项目」「套这个框架开新项目」「用这个骨架开个 IC 验证项目」
 - 当前项目框架层有重大更新后，用户想刷新模板
 ## 两个模式
 ### Export（脱敏导出）
 将当前项目框架层文件复制 → 把 SoC_SW 具体值替换为 `{{变量}}` → 输出干净的模板目录。
 ### Init（初始化新项目）
 读取模板 → 把 `{{变量}}` 替换为用户提供的新项目值 → 输出可开工的新项目目录。
 ## 变量定义
 见 `TEMPLATE.yaml`。核心变量：
 | 变量 | 当前值（SoC_SW） | 说明 |
 |------|-------------------|------|
 | `{{PROJECT_NAME}}` | SoC_SW | 项目名 |
 | `{{PROJECT_CONCEPT}}` | SoC回片软件验证测试AI辅助自动化数字化改造实行落地运行 | 核心概念 |
 | `{{PROJECT_DESCRIPTION}}` | AI辅助的SoC回片软件验证测试自动化数字化平台 | 一句话描述 |
 | `{{P01_NAME}}` | P01_soc_sw_app | 主应用目录名 |
 | `{{DATABASE_URL}}` | postgresql://.../soc_sw | 数据库连接 |
 ## 框架层 vs 项目层
 见 `SYNC.md`。核心区分：
 **框架层（导出/同步）**：
 - `AGENTS.md` — AI 角色+权限
 - `dashboard.md` — 控制面板结构
 - `DECISIONS.md` — 决策入口
 - `.ai/principles.md` — 设计原则
 - `.ai/config/` — AI 配置
 - `.ai/prompts/` — 提示词模板
 - `.ai/roles/*/card.md` — 角色身份卡
 - `.ai/phases/INDEX.md` — 阶段索引
 - `.ai/knowledge/patterns.md` — 可复用模式
 - `.ai/knowledge/lessons.md` — 框架级教训
 - `.ai/tasks/templates/` — Task 模板
 - `.trae/skills/` — 全部 Skill
 - `docs/使用手册.md` — 使用说明
 - `ENVIRONMENT.md` — 环境结构
 - `TEMPLATE.yaml` — 变量定义
 - `SYNC.md` — 边界定义
 **项目层（不导出，新项目自己写）**：
 - `.ai/tasks/active/` — 具体 task
 - `.ai/phases/phase-*/goal.md, scope.md, architecture.md, decisions.md, completion.md`
 - `.ai/knowledge/decisions.md` — 项目 ADR
 - `.ai/knowledge/journal/` — 开发日志
 - `docs/01_*/ ~ docs/06_*/` — PRD、架构设计等
 - `docs/share/` — 对外分享
 - `projects/` — 代码
 - `reports/` — 测试报告
 ## 执行步骤
 ### Export 模式
 1. 读 `SYNC.md` 确认框架层文件清单
 2. 读 `TEMPLATE.yaml` 获取变量清单和当前值
 3. 对每个框架层文件：
   - 复制内容
   - 将当前值（如 `SoC_SW`）替换为 `{{PROJECT_NAME}}`
   - 将 `soc_sw` 替换为 `{{PROJECT_NAME_LOWER}}`
   - 依此类推，覆盖 TEMPLATE.yaml 中所有变量
 4. 输出到指定目录（默认 `../project-template/`）
 ### Init 模式
 1. 询问用户：项目名、核心概念、一句话描述
 2. 读 `TEMPLATE.yaml`，生成新值（如 `PROJECT_NAME: "ICValidator"`）
 3. 复制框架层文件到新项目目录
 4. 将所有 `{{变量}}` 替换为新值
 5. 创建项目层空目录结构（.ai/tasks/active/, .ai/phases/, docs/01_产品需求/ 等）
 6. 告知用户：新项目就绪，Arch AI 可以开始写 PRD
 ## 注意事项
 1. **框架层不包含具体业务的 ADR**。ADR-009（人机协同）是 SoC_SW 特有的，不导出。ADR-007（分层架构）是框架级的，可导出
 2. **Skill 本身属于框架层**，会被导出。新项目自带全套 Skill
 3. **TEMPLATE.yaml 导出后变量值变为 `{{}}` 占位符**，等待 init 时填入新值
 4. **脱敏检查**：export 后应人工抽查，确保没有 SoC_SW 特有信息泄露到模板
 ---
 **Version**: 1.0
 **Created**: 2026-05-26
 **Based On**: ADR-008（模板同步机制），废弃 ai_project 分支方案，改为 Skill 按需执行
@@ -1,195 +0,0 @@
 ---
 name: "resume-context"
 description: "Loads project context and syncs conversation history. Invoke when user switches computers, starts a new session, or says '接着干 开发'、'接着干 测试'、'接着干 架构'."
 ---
 # 接着干 - 上下文同步 Skill
 ## 功能
 当用户更换电脑、开启新会话、或说"接着干"时，自动读取项目上下文文档，恢复之前的开发状态和讨论背景，并根据用户指定的角色设定 AI 权限。
 ## 触发条件
 用户必须使用以下格式之一：
 | 触发词 | 角色 | 权限 |
 |--------|------|------|
 | `接着干 开发` | Dev AI | 按宪法约束（coder.json） |
 | `接着干 测试` | QA AI | 按宪法约束（tester.json） |
 | `接着干 架构` | 人类负责人 | 最高权限，不受宪法约束 |
 **别名**：`继续 开发/测试/架构`、`resume dev/test/arch`
 ## 执行步骤
 ### 1. 识别角色
 根据用户输入的后缀词判断角色：
 ```
 开发/dev/coder → Dev AI
 测试/test/qa   → QA AI
 架构/arch      → Arch AI（架构设计师）
 ```
 ### 2. 读取项目上下文
 按以下顺序读取核心文档：
 ```
 1. docs/PROJECT_CONTEXT.md          # 项目整体上下文
 2. docs/DECISIONS.md                # 关键决策记录
 3. docs/06_开发日志/                # 最新开发日志（按日期倒序）
 4. AGENTS.md                        # AI 角色和权限约定
 ```
 ### 3. 加载角色配置
 根据识别的角色，读取对应的配置文件：
 **Arch AI**：
 ```
 .ai/config/architect.json
 ```
 - 读取 `allowed_paths`、`read_only_paths`、`forbidden_paths`
 - 读取 `responsibilities`
 - 读取 `prompt_templates`
 - **拥有最高 AI 权限**，可以进行架构设计和跨模块修改
 **Dev AI**：
 ```
 .ai/config/coder.json
 ```
 - 读取 `allowed_paths`、`read_only_paths`、`forbidden_paths`
 - 读取 `responsibilities`
 - 读取 `prompt_templates`
 **QA AI**：
 ```
 .ai/config/tester.json
 ```
 - 读取 `allowed_paths`、`read_only_paths`、`forbidden_paths`
 - 读取 `responsibilities`
 - 读取 `prompt_templates`
 ### 4. 读取最新开发日志
 ```powershell
 # 获取最新的开发日志文件
 Get-ChildItem "docs/06_开发日志/" -Filter "*.md" | Sort-Object Name -Descending | Select-Object -First 3
 ```
 读取最近 3 篇日志，了解最近的讨论内容。
 ### 5. 同步状态
 向用户报告当前状态和角色：
 ```markdown
 ## 上下文同步完成
 ### 当前角色
 - **角色**: [Dev AI / QA AI / 人类负责人]
 - **权限**: [按宪法约束 / 最高权限]
 - **可写路径**: [列出 allowed_paths]
 - **只读路径**: [列出 read_only_paths]
 ### 项目状态
 - **当前阶段**: [从 PROJECT_CONTEXT.md 读取]
 - **最新任务**: [从 review/active/ 读取最新任务]
 - **最近工作**: [从最新开发日志读取]
 ### 待办事项
 - [从 PROJECT_CONTEXT.md 和开发日志中提取]
 ### 可以继续的工作
 - [列出可以继续开发的任务]
 ```
 ### 6. 确认用户意图
 询问用户：
 - 继续上次未完成的工作？
 - 开始新的任务？
 - 查看项目状态？
 ## 文档格式要求
 ### PROJECT_CONTEXT.md
 ```markdown
 # 项目上下文
 ## 项目愿景
 [一句话描述项目目标]
 ## 当前阶段
 [当前处于哪个阶段，已完成什么]
 ## 技术栈
 [主要技术选型]
 ## 团队架构
 [1 人 + 2AI 协作模式]
 ## 关键决策
 [列出重要决策和原因]
 ## 待解决问题
 [列出悬而未决的问题]
 ## 下一步计划
 [接下来的工作重点]
 ```
 ### 开发日志格式
 ```markdown
 # YYYY-MM-DD_主题
 ## 讨论内容
 [主要讨论了什么]
 ## 关键决策
 [做出了什么决定]
 ## 完成的工作
 [做了什么改动]
 ## 待办事项
 [接下来要做什么]
 ```
 ## 使用场景
 **何时调用此 skill：**
 - ✅ 更换电脑后开始工作
 - ✅ 开启新会话，需要恢复上下文
 - ✅ 长时间未开发，需要回忆项目状态
 - ✅ 用户说"接着干 开发/测试/架构"
 **不适用场景：**
 - ❌ 首次启动项目（应使用 ai-collab-setup）
 - ❌ 只需要查看代码（直接搜索即可）
 ## 注意事项
 1. **角色必须明确**：用户必须指定"开发"、"测试"或"架构"，否则询问用户
 2. **架构模式**：架构模式对应 Arch AI，拥有最高 AI 权限，可以进行架构设计和跨模块修改
 3. **不要修改文档**：此 skill 只读取上下文，不修改任何文件（除非用户明确要求）
 4. **关注最新内容**：优先读取最新的开发日志
 5. **识别阻塞点**：注意 PROJECT_CONTEXT.md 中的"待解决问题"
 6. **权限意识**：开发/测试/架构模式下严格遵循 AGENTS.md 中的权限约定
 ---
 **Version**: 3.0  
 **Created**: 2026-05-23  
 **Updated**: 2026-05-23  
 **Based On**: SoC_SW AI Programming Project  
 **Purpose**: 解决用户多电脑切换时的上下文同步问题，明确 AI 角色和权限  
 **Changes from v2.0**: 
 - 架构模式从"人类负责人"改为"Arch AI（架构设计师）"
 - 新增 .ai/config/architect.json 配置读取
 - 支持"1 人+3AI"协作模式
@@ -1,136 +0,0 @@
 ---
 name: "share-context"
 description: "一鸡多吃：将内部开发文档（ADR、阶段复盘、开发日志）翻译为对外分享文章。阶段收尾时或用户说「一鸡多吃」「同步分享」「发布分享」时调用。"
 ---
 # 一鸡多吃 — 内部文档转对外分享 Skill
 ## 功能
 将开发过程中积累的内部文档（架构决策、阶段完成记录、踩坑经验）翻译为对外可发布的分享文章，写入 `docs/share/` 目录。
 **核心逻辑**：同一份工作，两种产出。内部文档（给 AI 看）→ 去敏 + 加故事 + 加思考过程 → 对外文章（给人看）。
 ## 触发条件
 - 用户说「一鸡多吃」「同步分享」「发布分享」「更新分享」
 - 阶段收尾时（Phase completion）
 - 有新的 ADR 或重要决策产生后
 ## 执行步骤
 ### 0. 反向检查：知识库是否遗漏了有价值的洞察
 **在扫描对外分享内容之前**，先检查是否有最近的开发讨论/决策/想法尚未写入知识库：
 | 检查项 | 判断标准 | 写入目标 |
 |--------|---------|---------|
 | 近期是否有重要的架构讨论 | 讨论产生了「可复用的判断」或「方向性决策」 | `.ai/knowledge/decisions.md`（新 ADR） |
 | 近期是否有反直觉的发现或错误 | 讨论产生了「原来以为…但其实…」的洞察 | `.ai/knowledge/lessons.md`（新 L-XXX） |
 | 近期是否发现了可复用的模式 | 同样的做法出现了 2 次以上 | `.ai/knowledge/patterns.md`（新 P-XXX） |
 **触发词**：当讨论中出现以下信号时，应主动提议记录：
 - 「这个很有价值」「值得记下来」「下次遇到可以…」
 - 「原来是这样」「之前没想到」「反直觉的是…」
 - 领域术语的定义或边界划分（如「蜂群模式」「编排器-执行者」）
 如果发现遗漏，**先补知识库，再执行后续步骤**。知识库是分享的源头——源头空了，一鸡多吃也无米下锅。
 ### 1. 扫描内部文档，识别可分享内容
 按以下来源对比 `docs/share/` 已有内容，找出新增/变化：
 | 内部来源 | 对应对外产出 | 判断标准 |
 |---------|-------------|---------|
 | `.ai/knowledge/decisions.md` 中的新 ADR | `phase-XX/决策故事_ADR-XXX.md` | 有新 ADR 且无对应故事文件 |
 | `.ai/phases/phase-XX-*/completion.md` | `phase-XX/阶段复盘_XXX.md` | 阶段已完成且复盘文件为空/待写 |
 | `.ai/knowledge/lessons.md` | 踩坑记录（融入复盘或独立） | 有新的经验教训记录 |
 | `.ai/knowledge/journal/` | 开发周记 | 有新的日志文件 |
 ### 2. 确定本次要写的文章
 列出待写文章清单，向用户确认优先级和范围。
 ### 3. 逐篇撰写
 每篇文章遵循以下原则：
 **内容要求**：
 - 不只说「做了什么」，重点说「为什么这么选」
 - 有具体的决策场景（当时遇到了什么问题）
 - 有可复用的方法论（下次遇到类似情况怎么做）
 - 有真实的踩坑和教训（不粉饰）
 - 一句话总结（可引用/可传播）
 **安全要求**：
 - ❌ 不暴露 API 密钥、服务器地址、数据库连接串
 - ❌ 不暴露真实用户名、手机号、微信号
 - ❌ 不暴露未公开的第三方合作信息
 - ✅ 技术方案可以详细写
 - ✅ 决策过程可以完整写
 - ✅ 思考逻辑可以展开写
 **写作风格**：
 - 第一人称（「我」），人类视角
 - 像讲故事，不像写文档
 - 目标读者是「对 AI 编程感兴趣的人」，不是机器
 - 每篇 800-1500 字，独立可读
 ### 4. 更新分享目录
 更新 `docs/share/README.md` 中的文章列表和状态。
 ### 5. 告知用户
 ```markdown
 ## 一鸡多吃完成
 ### 新增文章
 | 文件 | 内容 |
 |------|------|
 | [文章名](路径) | 一句话描述 |
 ### 更新文章
 | 文件 | 变更 |
 |------|------|
 | [文章名](路径) | 更新内容简述 |
 ### 分享目录
 → `docs/share/README.md`
 ```
 ## 文件结构
 ```
 docs/share/
 ├── README.md                          # 分享目录索引
 ├── 00_项目缘起.md                      # 项目背景（一次性写完，后续微调）
 ├── 01_框架设计思路.md                  # 核心理念（一次性写完，后续微调）
 ├── phase-01/                          # Phase 1 分享内容
 │   ├── 阶段复盘_基础搭建.md             # 阶段复盘
 │   ├── 决策故事_ADR-007.md             # 信息架构决策
 │   ├── 决策故事_ADR-009.md             # 人机协同决策
 │   └── 决策故事_旧架构合并.md           # 旧架构合并决策
 ├── phase-02/                          # Phase 2 分享内容（待产生）
 │   └── ...
 └── templates/                         # 写作模板
    ├── 阶段复盘模板.md
    └── 决策故事模板.md
 ```
 ## 注意事项
 1. **先入库，后分享**：Step 0 必须在 Step 1 之前执行。知识库是米缸，分享是做饭——米缸空了做不出饭
 2. **不是做完再写**：开发过程中自动积累，阶段结束时批量产出
 3. **同一份工作，两种语言**：内部文档是「给 AI 看的结构化数据」，对外文章是「给人看的故事」
 4. **保持真诚**：有成功写成功，有失败写失败。读者能看出哪些是 PR 稿
 5. **去敏但不去肉**：去掉敏感信息，但保留具体细节。一个没有细节的故事没有价值
 6. **链接内部来源**：每篇文章底部可附「内部参考：ADR-XXX」但不暴露内部文件路径
 ---
 **Version**: 1.1  
 **Updated**: 2026-05-26 — 新增 Step 0「反向检查」，补上知识库摄入端  
 **Created**: 2026-05-26  
 **Based On**: SoC_SW 开发实践 — Phase 1 收尾时的「一鸡多吃」流程  
 **Purpose**: 将内部开发文档自动转化为对外分享内容，实现「开发即内容」的闭环  
@@ -1,143 +0,0 @@
 ---
 name: "switch-model"
 description: "Checks project context when switching AI models. Invoke when user says '切换模型 架构/开发/测试' or 'switch-model arch/dev/qa'."
 ---
 # 切换模型 Skill
 ## 功能
 当用户更换大模型（Claude/TRAE/扣子/元宝等）时，快速加载项目上下文，确保新模型理解当前状态并遵循规则。
 ## 触发条件
 **必须指定角色**：
 - `切换模型 架构` / `switch-model arch` → Arch AI
 - `切换模型 开发` / `switch-model dev` → Dev AI
 - `切换模型 测试` / `switch-model qa` → QA AI
 **不指定角色时**：询问用户，不执行全面检查。
 ## 执行步骤
 ### 1. 识别角色
 | 触发词 | 角色 | 配置文件 |
 |--------|------|---------|
 | 架构/arch | Arch AI | .ai/config/architect.json |
 | 开发/dev/coder | Dev AI | .ai/config/coder.json |
 | 测试/test/qa | QA AI | .ai/config/tester.json |
 ### 2. 安全检查（git 状态优先）
 **必须先检查 git 仓库状态，确保在安全的环境下加载上下文**：
 ```bash
 git status              # 工作区状态（干净/有变更/有冲突）
 git log --oneline -3    # 最近 3 次提交（了解最近做了什么）
 git branch              # 当前分支（确认是否在正确分支）
 ```
 **异常处理**：
 | 状态 | 处理方式 |
 |------|---------|
 | 工作区有未提交变更 | 提醒用户先提交或暂存，避免上下文不一致 |
 | 有合并冲突 | 立即告知用户需要解决冲突 |
 | 分支不对 | 提醒用户切换到正确分支 |
 | 远程有更新未拉取 | 提醒用户先 pull |
 ### 3. 加载基础上下文（所有角色通用）
 ```
 1. AGENTS.md                        # 团队架构和权限矩阵
 2. .ai/config/workflow.json         # 工作流配置
 3. docs/PROJECT_CONTEXT.md          # 项目整体状态
 ```
 ### 4. 按角色加载专属上下文
 #### Arch AI（架构AI）
 ```
 4. .ai/config/architect.json        # 角色权限
 5. docs/02_系统架构/                # 架构文档
 6. review/active/*/task.md          # 活跃任务
 7. .trae/skills/                    # 可用 Skill 列表
 8. ENVIRONMENT.md                  # 环境配置
 ```
 #### Dev AI（编码AI）
 ```
 4. .ai/config/coder.json            # 角色权限
 5. review/active/*/task.md          # 活跃任务
 6. review/active/*/feedback/        # 待修 Bug
 7. .trae/skills/                    # 可用 Skill 列表
 8. ENVIRONMENT.md                  # 环境配置
 ```
 #### QA AI（测试AI）
 ```
 4. .ai/config/tester.json           # 角色权限
 5. review/active/*/acceptance.md    # 验收标准
 6. reports/test-results/            # 最近测试报告
 7. .trae/skills/                    # 可用 Skill 列表
 8. ENVIRONMENT.md                  # 环境配置
 ```
 ### 5. 输出简洁检查报告
 ```markdown
 # 模型切换检查报告
 ## 角色确认
 - 当前角色: [角色名]
 - 权限: [可写路径] | 只读: [只读路径] | 禁止: [禁止路径]
 ## 项目状态
 - 当前阶段: [工作流阶段]
 - 活跃任务: [任务编号和名称]
 - 工作区: [干净/有变更]
 ## 最近提交 (3 条)
 - [commit 1]
 - [commit 2]
 - [commit 3]
 ## 待办事项
 - [ ] [待办 1]
 - [ ] [待办 2]
 ## 阻塞点
 - [无 / 具体问题]
 ✅ 已就绪，等待指令
 ```
 ### 6. 等待用户指令
 报告输出后，等待用户进一步指令。用户可以说：
 - `展开 [某项]` → 深入查看细节
 - `开始工作` → 进入角色模式
 - `切换角色` → 重新执行本 Skill
 ## 注意事项
 1. **必须指定角色**：不指定时询问用户，不盲目全面检查
 2. **简洁优先**：报告控制在 1 屏内，用户需要细节时可展开
 3. **权限意识**：加载配置后立即确认权限边界
 4. **不修改文件**：此 Skill 只读取上下文，不修改任何文件
 5. **Skill 列表**：确保新模型知道有哪些 Skill 可用
 ---
 **Version**: 1.1  
 **Created**: 2026-05-23  
 **Updated**: 2026-05-23  
 **Based On**: SoC_SW AI Programming Project  
 **Purpose**: 确保大模型切换时快速同步上下文，按角色差异化加载  
 **Changes from v1.0**: 
 - 新增安全检查步骤，git 状态优先于上下文加载
 - 增加异常处理（未提交变更/合并冲突/分支错误/远程更新）
@@ -1,95 +0,0 @@
 ---
 name: "update-constitution"
 description: "Updates AI constitution files (AGENTS.md, config files, permission matrix). Invoke when AI roles, permissions, or workflow rules change."
 ---
 # 更新宪法 Skill
 ## 功能
 当 AI 角色、权限、工作流规则发生变更时，自动更新所有相关的宪法文件，确保一致性。
 ## 触发条件
 - AI 角色增加/删除/修改
 - 权限矩阵变更（allowed_paths、read_only_paths、forbidden_paths）
 - 工作流阶段变更
 - 沟通规范变更
 - 命名规范变更
 ## 执行步骤
 ### 1. 识别变更类型
 | 变更类型 | 影响文件 |
 |---------|---------|
 | 新增 AI 角色 | AGENTS.md、.ai/config/<role>.json、workflow.json、权限矩阵 |
 | 权限变更 | AGENTS.md 权限矩阵、.ai/config/*.json |
 | 工作流变更 | AGENTS.md 工作流程图、workflow.json |
 | 沟通规范变更 | AGENTS.md 沟通规范章节 |
 | 命名规范变更 | AGENTS.md 命名规范章节 |
 ### 2. 更新宪法文件
 按以下顺序更新：
 #### 2.1 AGENTS.md
 - [ ] 更新团队架构图
 - [ ] 更新角色职责（新增/修改/删除）
 - [ ] 更新目录权限矩阵
 - [ ] 更新工作流程图（如适用）
 - [ ] 更新详细流程说明（如适用）
 - [ ] 更新 AI 配置文件说明表
 #### 2.2 .ai/config/*.json
 - [ ] 新增/更新对应角色的 JSON 配置文件
 - [ ] 确保 allowed_paths、read_only_paths、forbidden_paths 与权限矩阵一致
 - [ ] 确保 responsibilities 与角色职责一致
 - [ ] 确保 prompt_templates 指向正确的提示词目录
 #### 2.3 .ai/config/workflow.json
 - [ ] 更新 roles 数组
 - [ ] 更新 stages 数组（新增/修改/删除阶段）
 - [ ] 确保 actor 字段与角色 ID 一致
 ### 3. 更新 Skill 文件
 - [ ] .trae/skills/ai-collab-setup/SKILL.md - 目录结构、权限矩阵、角色描述、配置文件示例
 - [ ] .trae/skills/resume-context/SKILL.md - 角色识别逻辑、配置文件读取
 ### 4. 验证一致性
 - [ ] AGENTS.md 权限矩阵 与 .ai/config/*.json 路径配置一致
 - [ ] AGENTS.md 角色职责 与 .ai/config/*.json responsibilities 一致
 - [ ] AGENTS.md 工作流程图 与 workflow.json stages 一致
 - [ ] 所有 JSON 文件语法正确（使用 python -m json.tool 验证）
 ### 5. 提交 Git
 ```bash
 git add -A
 git commit -m "feat(constitution): 更新宪法 - [简要描述变更内容]
 - AGENTS.md: [具体变更]
 - .ai/config/*.json: [具体变更]
 - workflow.json: [具体变更]
 - ai-collab-setup/SKILL.md: [具体变更]"
 git push
 ```
 ## 注意事项
 1. **权限矩阵是核心**：所有路径变更必须先更新权限矩阵，再同步到 JSON 配置
 2. **JSON 语法验证**：每次修改后必须验证 JSON 语法
 3. **Skill 文件同步**：宪法变更后必须同步更新 ai-collab-setup 和 resume-context Skill
 4. **版本号**：重大变更需升级 Skill 版本号
 ---
 **Version**: 1.0  
 **Created**: 2026-05-23  
 **Based On**: SoC_SW AI Programming Project  
 **Purpose**: 确保宪法变更时所有相关文件同步更新，避免遗漏
@@ -1,103 +0,0 @@
 ---
 name: "update-docs"
 description: "Updates project documentation (README.md, changelog, PROJECT_CONTEXT.md, etc.). Invoke after any code/structure change to keep docs in sync."
 ---
 # 更新文档 Skill
 ## 功能
 在任何代码、结构、配置变更后，自动更新所有相关的项目文档，确保文档与实际状态一致。
 ## 触发条件
 - 目录结构变更（新增/删除/重命名目录）
 - 角色/权限变更（宪法更新后）
 - 工作流变更
 - Skill 文件变更
 - 任何可能影响文档的变更
 ## 执行步骤
 ### 1. 识别变更影响范围
 | 变更类型 | 需更新的文档 |
 |---------|-------------|
 | 目录结构变更 | README.md 目录树、PROJECT_CONTEXT.md 结构图 |
 | 角色/权限变更 | README.md 团队角色表、PROJECT_CONTEXT.md |
 | 工作流变更 | README.md 工作流程、PROJECT_CONTEXT.md |
 | Skill 文件变更 | README.md（如提及 Skill） |
 | 任何提交 | 变更日志 |
 ### 2. 更新文档
 按以下顺序更新：
 #### 2.1 README.md
 - [ ] 更新项目描述（如适用）
 - [ ] 更新目录结构树
 - [ ] 更新团队角色表
 - [ ] 更新工作流程说明
 - [ ] 更新任务状态流转（如适用）
 #### 2.2 docs/PROJECT_CONTEXT.md
 - [ ] 更新当前阶段
 - [ ] 更新项目结构图
 - [ ] 更新关键决策（如适用）
 - [ ] 更新待解决问题（如适用）
 - [ ] 更新下一步计划
 #### 2.3 docs/05_变更日志/YYYY-MM-DD.md
 - [ ] 创建今日日志文件（如不存在）
 - [ ] 添加本次提交记录
 - [ ] 包含 commit hash、简要描述、具体变更
 #### 2.4 docs/DECISIONS.md（如适用）
 - [ ] 新增架构决策记录（ADR）
 - [ ] 格式：背景、决策、原因、后果
 #### 2.5 docs/06_开发日志/YYYY-MM-DD_主题.md（如适用）
 - [ ] 记录讨论内容
 - [ ] 记录关键决策
 - [ ] 记录完成的工作
 - [ ] 记录待办事项
 ### 3. 验证一致性
 - [ ] README.md 目录树 与实际目录结构一致
 - [ ] README.md 团队角色表 与 AGENTS.md 一致
 - [ ] README.md 工作流程 与 workflow.json 一致
 - [ ] PROJECT_CONTEXT.md 结构图 与实际一致
 - [ ] 变更日志包含所有今日提交
 ### 4. 提交 Git
 ```bash
 git add -A
 git commit -m "docs(readme): 同步文档 - [简要描述]
 - README.md: [具体变更]
 - PROJECT_CONTEXT.md: [具体变更]
 - docs/05_变更日志/YYYY-MM-DD.md: [具体变更]"
 git push
 ```
 ## 注意事项
 1. **变更日志是必须的**：每次提交都必须更新变更日志，不能忘
 2. **README.md 是门面**：项目的第一印象，必须保持最新
 3. **PROJECT_CONTEXT.md 是上下文**：换电脑后 AI 读取的核心文档
 4. **不要过度更新**：只更新受影响的文档，不要全量重写
 5. **保持简洁**：文档更新提交信息要简洁明了
 ---
 **Version**: 1.0  
 **Created**: 2026-05-23  
 **Based On**: SoC_SW AI Programming Project  
 **Purpose**: 确保文档与代码/结构同步更新，避免"繁文缛节"被遗忘
@@ -1,119 +0,0 @@
 # AI 角色定义与权限约定
 > **如果你是 AI，请直接跳转到你的角色入口：**
 > - Arch AI → `dashboard.md` 全文
 > - Dev AI → `.ai/roles/dev/card.md` → 对应 `.ai/tasks/active/P01-XXX.md`
 > - QA AI → `.ai/roles/qa/card.md` → 对应 `.ai/tasks/active/T01-XXX.md`
 >
 > **如果你是**人类，请看 `dashboard.md` 顶部「人类区」。
 >
 > 本文档是权限矩阵的**唯一权威参考**。角色工作台中的权限描述为摘要，如有冲突以本文档为准。
 >
 > **架构说明**: 旧入口（DASHBOARD.md / ROADMAP.md / roles/*/today.md / roles/*/queue.md）已归档至 `.ai/archive/`。详见 ADR-012。
 ---
 ## 团队架构
 `1 人类 + 3 AI` 协作模式：
 - **Arch AI** — 需求分析、架构设计、技术选型、跨模块协调
 - **Dev AI** — 代码编写、文档生成、Bug 修复
 - **QA AI** — 测试设计、测试执行、质量反馈
 - **人类** — 需求输入、最终决策、成果验收
 ---
 ## 工作流（简化版）
 ```
 需求分析(Arch) → 架构设计(Arch) → 开发实现(Dev) → 测试验证(QA) → 人类验收
                                        ↑              │
                                        └── Bug修复 ──┘  (最多3轮)
 ```
 缺陷修复循环：最多 3 轮。第 3 轮仍有 BLOCKER/HIGH → 升级给人类裁决。
 详细工作流配置：`.ai/config/workflow.json`
 ---
 ## 角色职责
 ### Arch AI
 - 可写：需求分析、架构设计、技术选型、跨模块协调、架构文档、验收标准、影响评估、共享资源、开发工具、训练数据、业务代码
 - 只读：AI 配置、测试代码、测试报告、测试反馈
 - 指导 Dev AI 和 QA AI 工作，分配任务队列
 ### Dev AI
 - 可写：业务代码、技术文档、项目级文档、开发工具、训练数据、共享资源、验收标准、影响评估
 - 只读：任务描述、测试反馈
 - 禁止：测试代码、测试报告
 ### QA AI
 - 可写：测试用例、测试报告、验收标准补充、测试反馈
 - 只读：业务代码、技术文档、项目级文档、训练数据、共享资源、任务描述
 - 禁止：AI 配置、开发工具、影响评估
 ---
 ## 目录权限矩阵
 > 图例：`-` = 禁止 &nbsp;&nbsp; `R` = 只读 &nbsp;&nbsp; `W` = 可写（含读） &nbsp;&nbsp; `RW` = 读写
 | 目录路径 | Arch AI | Dev AI | QA AI | 人类 |
 |---------|---------|--------|-------|------|
 | `.ai/` | `R` | `-` | `-` | `RW` |
 | `docs/` | `RW` | `RW` | `R` | `RW` |
 | `tools/` | `RW` | `RW` | `-` | `RW` |
 | `data/` | `RW` | `RW` | `R` | `RW` |
 | `shared/` | `RW` | `RW` | `R` | `RW` |
 | `projects/*/src/` | `RW` | `RW` | `R` | `RW` |
 | `projects/*/tests/` | `R` | `-` | `RW` | `RW` |
 | `projects/*/docs/` | `RW` | `RW` | `R` | `RW` |
 | `review/*/task.md` | `RW` | `R` | `R` | `RW` |
 | `review/*/acceptance.md` | `RW` | `RW` | `RW` | `RW` |
 | `review/*/impact.md` | `RW` | `RW` | `-` | `RW` |
 | `review/*/feedback/` | `R` | `R` | `RW` | `RW` |
 | `reports/` | `R` | `-` | `RW` | `RW` |
 | `.github/` | `-` | `-` | `-` | `RW` |
 优先级：`forbidden > read_only > allowed`。未出现在表中的路径默认禁止所有 AI。
 ---
 ## 命名规范
 ### 任务编号
 `P{项目编号}-{任务序号}`，如 `P01-001`
 ### 分支命名
 ```
 feature/P01-001-short-desc    # 功能开发
 bugfix/P01-001-short-desc     # Bug修复
 test/P01-001-short-desc       # 测试用例
 ```
 ### 提交信息
 ```
 feat(P01-001): 简短描述
 fix(P01-001): 简短描述
 docs(P01-001): 简短描述
 test(P01-001): 简短描述
 ```
 ---
 ## AI 配置文件索引
 | 文件 | 说明 |
 |------|------|
 | `.ai/config/architect.json` | Arch AI 配置（权限、职责） |
 | `.ai/config/coder.json` | Dev AI 配置（权限、职责） |
 | `.ai/config/tester.json` | QA AI 配置（权限、职责） |
 | `.ai/config/workflow.json` | 工作流配置（阶段、触发器） |
 | `.ai/prompts/architecture/` | 架构设计提示词模板 |
 | `.ai/prompts/coding/` | 编码提示词模板 |
 | `.ai/prompts/testing/` | 测试提示词模板 |
 | `.ai/roles/` | AI 角色工作台（日常入口） |
 | `.ai/phases/` | 阶段上下文 |
 | `.ai/knowledge/` | 知识沉淀 |
@@ -1,73 +0,0 @@
 # SoC_SW 开发环境配置
 ## 前置依赖
 | 工具 | 版本要求 | 说明 |
 |------|---------|------|
 | Node.js | >= 20.x | JavaScript 运行时 |
 | pnpm | >= 9.0.0 | 包管理器 |
 | Python | >= 3.10 | 脚本/数据处理 |
 | Git | >= 2.40 | 版本控制 |
 ## 快速开始
 ```bash
 # 1. 克隆项目
 git clone <repository-url>
 cd soc_sw
 # 2. 安装前端依赖
 pnpm install
 # 3. 恢复上下文（换电脑后）
 # 在 Claude Code 中使用 resume-context Skill
 # 4. 启动开发服务器（根据子项目）
 cd projects/P01_soc_sw_app
 pnpm dev
 ```
 ## 子项目环境
 ### P01_soc_sw_app（主应用）
 ```bash
 cd projects/P01_soc_sw_app
 pnpm install
 pnpm dev
 ```
 ### P02_soc_sw_training（数据处理）
 ```bash
 cd projects/P02_soc_sw_training
 python -m venv venv
 source venv/bin/activate
 pip install -r requirements.txt
 ```
 ### P03_soc_sw_web（Web 管理后台）
 ```bash
 cd projects/P03_soc_sw_web
 pnpm install
 pnpm dev
 ```
 ## 开发工具
 - **AI 协作**: 1 人 + 3 AI（Arch AI + Coder AI + Tester AI）
 - **上下文同步**: 使用 `resume-context` Skill
 ## 跨平台开发
 本项目支持在 Windows、macOS、Linux 上开发。换电脑时：
 1. `git pull` 拉取最新代码
 2. 使用 `resume-context` Skill 恢复上下文
 3. 继续开发
 ## 环境变量
 各子项目的环境变量文件：
 - `projects/P01_soc_sw_app/.env`
 - `projects/P03_soc_sw_web/.env`
 参考各子项目的 `ENVIRONMENT.md` 获取详细配置。
@@ -1,82 +0,0 @@
 # 模板同步边界定义
 > 定义哪些文件属于"框架层"（跨项目复用），哪些属于"项目层"（项目特有）。
 > 框架层导出/初始化通过 `project-init` Skill 按需执行（ADR-013）。
 ---
 ## 规则
 ```
 框架层 = 可以复用的结构和逻辑（导出）
 项目层 = 某个具体项目的内容和数据（不导出）
 ```
 ---
 ## 文件分类
 ### 框架层（导出）
 | 文件/目录 | 说明 |
 |-----------|------|
 | `AGENTS.md` | AI 角色定义 + 权限矩阵 + 工作流 + 命名规范 |
 | `dashboard.md` | 控制面板结构（人类+Arch AI 入口） |
 | `DECISIONS.md` | 决策入口结构 |
 | `.ai/principles.md` | 架构设计原则 + 上下文管理硬约束 |
 | `.ai/config/*.json` | AI 配置（权限路径、职责定义、工作流） |
 | `.ai/prompts/` | 提示词模板（架构、编码、测试） |
 | `.ai/roles/README.md` | 角色工作台说明 |
 | `.ai/roles/{arch,dev,qa}/card.md` | 角色身份卡（身份、权限、启动流程） |
 | `.ai/phases/INDEX.md` | 阶段索引 + 切换规则 |
 | `.ai/knowledge/patterns.md` | 可复用模式 |
 | `.ai/knowledge/lessons.md` | 框架级经验教训 |
 | `.ai/tasks/templates/` | Task 模板（Coder + Tester） |
 | `.trae/skills/` | Skill 定义 |
 | `docs/使用手册.md` | 使用手册（框架层） |
 | `ENVIRONMENT.md` | 开发环境结构（框架层） |
 | `TEMPLATE.yaml` | 模板变量配置 |
 | `SYNC.md` | 本文档 |
 ### 项目层（不导出）
 | 文件/目录 | 说明 |
 |-----------|------|
 | `.ai/tasks/active/` | 活跃 task 文件（项目特定） |
 | `.ai/tasks/completed/` | 已完成 task（项目特定） |
 | `.ai/phases/phase-*/goal.md` | 阶段目标（项目特定） |
 | `.ai/phases/phase-*/scope.md` | 阶段范围（项目特定） |
 | `.ai/phases/phase-*/architecture.md` | 架构快照（项目特定） |
 | `.ai/phases/phase-*/decisions.md` | 阶段决策（项目特定） |
 | `.ai/phases/phase-*/completion.md` | 完成状态（项目特定） |
 | `.ai/knowledge/decisions.md` | ADR 全文（项目特定） |
 | `.ai/knowledge/journal/` | 每日日志（项目特定） |
 | `.ai/archive/` | 归档文件 |
 | `docs/01_*/ ~ docs/06_*/` | 项目文档（PRD、架构、数据模型等） |
 | `docs/share/` | 对外分享内容 |
 | `projects/` | 项目代码 |
 | `reports/` | 测试报告 |
 ---
 ## 使用方式
 通过 `project-init` Skill 执行，而非脚本。
 **Export（导出框架）**:
 ```
 在 Claude Code 中说「导出框架」→ Skill 读取 SYNC.md + TEMPLATE.yaml → 复制框架层文件 → 替换项目值为 {{变量}} → 输出到 ../project-template/
 ```
 **Init（初始化新项目）**:
 ```
 在 Claude Code 中说「套这个框架开新项目」→ Skill 询问新项目信息 → 替换 {{变量}} 为新值 → 创建新项目目录
 ```
 Skill 位置: `.trae/skills/project-init/SKILL.md`
 ## 原则
 1. **Skill 优于脚本** — AI 是执行者时，语义描述优于硬编码文件列表（ADR-013）
 2. **项目层隔离** — 任务、日志、代码、决策不受影响
 3. **边界定义是长期资产** — SYNC.md 定义「什么属于框架」，独立于执行方式
@@ -1,37 +0,0 @@
 # ============================================================
 # 项目模板变量定义
 # 用于 project-init Skill 的 export/init 双向替换
 # ============================================================
 # --- 项目身份 ---
 PROJECT_NAME: "SoC_SW"
 PROJECT_NAME_LOWER: "soc_sw"
 PROJECT_CONCEPT: "SoC回片软件验证测试AI辅助自动化数字化改造实行落地运行"
 PROJECT_DESCRIPTION: "AI辅助的SoC回片软件验证测试自动化数字化平台"
 # --- 子项目 P01（主应用）---
 P01_NAME: "P01_soc_sw_app"
 P01_DESC: "SoC_SW 主应用"
 P01_FRONTEND: "Taro 4 + React 18 + TypeScript"
 P01_BACKEND: "NestJS 10 + TypeScript"
 # --- 子项目 P02（训练/AI）---
 P02_NAME: "P02_soc_sw_training"
 P02_DESC: "SoC_SW AI 训练模块"
 # --- 子项目 P03（管理后台）---
 P03_NAME: "P03_soc_sw_web"
 P03_DESC: "SoC_SW Web 管理后台"
 # --- 阶段定义 ---
 PHASE1_NAME: "基础搭建"
 PHASE1_GOAL: "搭建项目骨架：协作框架、脚手架、权限体系"
 PHASE2_NAME: "MVP"
 PHASE2_GOAL: "实现SoC回片软件验证测试AI辅助自动化数字化改造实行落地运行核心功能"
 PHASE3_NAME: "功能完善"
 PHASE3_GOAL: "功能迭代、多端适配、性能优化"
 PHASE4_NAME: "打磨发布"
 PHASE4_GOAL: "质量提升、安全审计、文档完善"
 # --- 数据库 ---
 DATABASE_URL: "postgresql://user:password@localhost:5432/soc_sw"
@@ -1,102 +0,0 @@
 # SoC_SW 项目控制面板
 > 唯一真实来源。人类看顶部，Arch AI 看全文，Worker AI 看 task 文件。
 ---
 ## 人类区
 **Phase 1/4 — 基础搭建** · 进度 0%
 | 阶段 | 状态 | 进度 |
 |------|------|------|
 | 1. 基础搭建 | ← 当前 | 0% |
 | 2. MVP | 未开始 | 0% |
 | 3. 功能完善 | 未开始 | 0% |
 | 4. 打磨发布 | 未开始 | 0% |
 ### 需要你决策
 当前无待决策事项。
 ### 上次决策追踪
 （暂无）
 ---
 ## Arch AI 区
 ### ADR 摘要索引
 | ADR | 一句话 | 状态 |
 |-----|--------|------|
 | 001 | 「1 人 + 3 AI」三角协作框架 | ✅ |
 | 002 | 四级权限体系（-/R/W/RW） | ✅ |
 | 003 | 根级 docs/ 目录 | ✅ |
 | 004 | 独立 tools/ + data/ 目录 | ✅ |
 | 005 | 测试→修复 3 轮升级机制 | ✅ |
 | 006 | resume-context 多机同步 | ✅ |
 | 007 | 分层信息架构 + Token 预算 | ✅ |
 | 012 | 跨平台「高模型指挥小模型」协作架构 | ✅ 当前基准 |
 | 013 | Skill 替代脚本 — 框架脱敏/初始化的正确方式 | ✅ |
 ### Task 状态面板
 **Coder 任务 (Trae + GLM-4.6)**：
 | Task | 描述 | 优先 | 状态 | 依赖 | 分配给 |
 |------|------|------|------|------|--------|
 | — | 暂无 | — | — | — | — |
 **Tester 任务 (Coze CN)**：
 | Task | 描述 | 优先 | 状态 | 对应 Coder task |
 |------|------|------|------|-----------------|
 | — | 暂无 | — | — | — |
 **状态流转**: `todo → in_progress → done → tested → accepted`  
 **交接信号**: Coder 完成 → commit message 包含 `[READY_FOR_TEST]` → Tester 自动发现
 ### 依赖关系
 （暂无任务）
 ### 阻塞/风险
 （暂无）
 ---
 ## 关键文档入口
 | 想查什么 | 路径 |
 |----------|------|
 | 产品需求 | [docs/01_产品需求/PRD.md](docs/01_产品需求/PRD.md) |
 | 系统架构 | [docs/02_系统架构/](docs/02_系统架构/) |
 | ADR 全文 | [.ai/knowledge/decisions.md](.ai/knowledge/decisions.md) |
 | 经验教训 | [.ai/knowledge/lessons.md](.ai/knowledge/lessons.md) |
 | 可复用模式 | [.ai/knowledge/patterns.md](.ai/knowledge/patterns.md) |
 | 分享文章 | [docs/share/](docs/share/) |
 | 待人类决策 | [DECISIONS.md](DECISIONS.md) |
 ---
 ## 角色入口
 | 角色 | 平台+模型 | 入口 |
 |------|----------|------|
 | 人类 | — | 本文件顶部「人类区」 |
 | Arch AI | Claude Code + DeepSeek V4 Pro | 本文件全文 |
 | Coder AI | Trae CN + GLM-4.6 | [.ai/roles/dev/card.md](.ai/roles/dev/card.md) → 对应 task 文件 |
 | Tester AI | Coze CN | [.ai/roles/qa/card.md](.ai/roles/qa/card.md) → 对应 task 文件 |
 ---
 ## 最近事件
 | 日期 | 事件 |
 |------|------|
 | 2026-05-26 | 项目初始化：从 ErrLens 框架导出，SoC_SW 项目创建 |
 *Arch AI 维护。阶段切换时更新。不随每日任务变化。*
@@ -1,236 +0,0 @@
 # SoC_SW 使用手册
 > 适用对象：人类负责人、Arch AI、Coder AI、Tester AI
 ---
 ## 目录
 - [人类篇：我怎么管项目](#人类篇我怎么管项目)
 - [AI 篇：我怎么干活](#ai-篇我怎么干活)
  - [Arch AI](#arch-ai-架构师)
  - [Coder AI](#coder-ai-开发者)
  - [Tester AI](#tester-ai-测试者)
 - [场景篇](#场景篇)
  - [日常推进](#场景一日常推进)
  - [换电脑/换模型](#场景二换电脑换模型)
  - [阶段切换](#场景三阶段切换)
  - [Bug 修复循环](#场景四bug-修复循环)
 - [速查表](#速查表)
 ---
 ## 人类篇：我怎么管项目
 ### 第一次进来
 ```
 1. 打开 dashboard.md（30 秒读完）
   → 了解：现在在哪个阶段、进度如何、有什么阻塞
 2. 打开 DECISIONS.md
   → 看：有没有需要你拍板的事
 3. 打开 docs/使用手册.md（就是本文档）
   → 了解：怎么跟 AI 协作
 ```
 ### 日常工作
 | 你想干嘛 | 去哪个文件 | 干什么 |
 |----------|-----------|--------|
 | 看看进度 | `dashboard.md` | 一眼看到阶段和阻塞 |
 | 看任务状态 | `dashboard.md` → Task 面板 | Coder/Tester 各自进度 |
 | 需要决策 | `DECISIONS.md` | 待决策项 |
 | 看测试结果 | `reports/` | Tester AI 生成的报告 |
 | 看为什么这样设计 | `.ai/knowledge/decisions.md` | 架构决策记录 |
 ### 你不需要懂的东西
 - `projects/*/src/` — 代码，交给 Coder AI
 - `projects/*/tests/` — 测试代码，交给 Tester AI
 - `.ai/config/` — AI 配置文件，Arch AI 维护
 ---
 ## AI 篇：我怎么干活
 ### 核心原则
 ```
 每个角色只读 1-2 个文件即可开工：
  Arch AI:    dashboard.md 全文（1 个文件）
  Coder AI:   card.md → task 文件（2 个文件）
  Tester AI:  card.md → task 文件（2 个文件）
 不要从头遍历项目。用链接按需加载。
 ```
 ---
 ### Arch AI（架构师）
 #### 进来第一件事
 ```
 读 dashboard.md 全文 → 项目全貌 + ADR 索引 + task 状态面板
 ```
 #### 日常工作
 | 做什么 | 怎么做 | 产出 |
 |--------|--------|------|
 | 写 PRD | 读背景 → 写 `docs/01_产品需求/PRD.md` | PRD.md |
 | 设计架构 | 用 `.ai/prompts/architecture/architecture-design.md` | `docs/02_系统架构/` |
 | 分配任务 | 按模板写 `.ai/tasks/active/P01-XXX.md`，更新 dashboard.md | task 文件 |
 | 记录决策 | 在 `.ai/knowledge/decisions.md` 新增 ADR | ADR |
 | 人类决策入口 | 写入 `DECISIONS.md` | 待决策项 |
 #### 完成工作后
 ```
 1. 更新 dashboard.md（task 状态 + 最近事件）
 2. 写 .ai/knowledge/journal/{日期}.md（简要记录）
 ```
 #### 阶段切换（重要）
 ```
 1. 检查 completion.md 全部打勾
 2. 更新所有 .ai/roles/*/card.md 的当前阶段
 3. 更新 .ai/phases/INDEX.md
 4. 更新 dashboard.md（进度条 + task 状态面板 + 最近事件）
 5. 产出阶段复盘 → docs/share/phase-NN/
 6. 通知人类签字
 ```
 ---
 ### Coder AI（开发者）
 #### 进来第一件事
 ```
 读 .ai/roles/dev/card.md   → 身份、权限、当前阶段
 读 dashboard.md            → 找到自己的 task（状态为 todo）
 读 .ai/tasks/active/P01-XXX.md → 这就是你的全部世界
 ```
 #### 核心规则
 **不需要**读 ADR 全文、知识库、或其他 task 文件。你的 task 文件已经包含了完成任务所需的全部信息（输入/输出/约束/验收方法）。
 #### 完成代码后
 ```
 1. 填写 task 文件的「完成报告」
 2. commit（message 含 [READY_FOR_TEST]）
 ```
 ---
 ### Tester AI（测试者）
 #### 进来第一件事
 ```
 读 .ai/roles/qa/card.md    → 身份、权限
 git pull                   → 拉取最新代码
 git log --grep="READY_FOR_TEST" → 查找待测试的 task
 读 .ai/tasks/active/T01-XXX.md  → 这就是你的全部世界
 ```
 #### 核心规则
 你不需要知道项目全貌、不需要读架构文档、不需要读 ADR。你的 task 文件 + 被测代码 = 你需要的一切。
 #### 完成后
 ```
 1. 生成测试报告 → reports/{编号}-{日期}.json
 2. 填写 task 文件的「完成报告」
 3. commit
 ```
 ---
 ## 场景篇
 ### 场景一：日常推进
 **人类**：
 1. 打开 `dashboard.md` 看一眼
 2. 打开 `DECISIONS.md` 看有没有待决策
 **Coder AI**：读 card.md → task 文件 → 写代码 → commit [READY_FOR_TEST]
 **Tester AI**：git pull → git log --grep → task 文件 → 测试 → commit
 ### 场景二：换电脑/换模型
 **换电脑**：用 `resume-context` Skill → 自动加载上下文
 **换模型**：用 `switch-model` Skill → 指定角色 → 自动加载角色工作台
 **手动恢复**：
 ```
 1. 读 dashboard.md → 知道现在在哪
 2. 读 .ai/roles/{你的角色}/card.md → 知道你是谁
 ```
 ### 场景三：阶段切换
 ```
 Phase N 完成 → Phase N+1 启动：
 1. Arch AI 检查 completion.md 全部打勾
 2. Arch AI 写阶段复盘到 docs/share/phase-NN/
 3. 人类签字确认
 4. Arch AI 更新：
   ├── dashboard.md（进度条 + task 面板 + 事件）
   ├── .ai/phases/INDEX.md（状态改为 DONE/ACTIVE）
   └── .ai/roles/*/card.md（当前阶段字段）
 5. 新阶段启动
 ```
 ### 场景四：Bug 修复循环
 ```
 Coder AI 提交代码 [READY_FOR_TEST]
  → Tester AI 测试
    → 有 Bug?
      ├── 是 → 测试报告标注 FAIL
      │        → Arch AI 写入 task 的约束/补充说明
      │          → Coder AI 修复 → 重新 [READY_FOR_TEST]
      │            → Tester AI 复查
      │              ├── 仍 FAIL (第3轮) → 升级人类
      │              └── PASS → DONE
      └── 否 → PASS → DONE
 ```
 ---
 ## 速查表
 ### 我想知道...
 | 问题 | 答案在哪 |
 |------|----------|
 | 项目总进度 | `dashboard.md` |
 | 有什么待决策 | `DECISIONS.md` |
 | 这个任务怎么做 | `.ai/tasks/active/{编号}.md` |
 | 这个设计为什么这样 | `.ai/knowledge/decisions.md` |
 | AI 有什么权限 | `AGENTS.md`（权威）或 `.ai/roles/{role}/card.md` |
 | 代码怎么写才规范 | `.ai/prompts/coding/code-style.md` |
 | 测试怎么报告 Bug | `.ai/prompts/testing/bug-report.md` |
 | 现在是什么阶段 | `dashboard.md` |
 | 踩过什么坑 | `.ai/knowledge/lessons.md` |
 | 可复用的模式 | `.ai/knowledge/patterns.md` |
 | 今天做了什么 | `.ai/knowledge/journal/{日期}.md` |
 | 怎么装开发环境 | `ENVIRONMENT.md` |
 | 新加入一个 AI 怎么上手 | 读本手册 + 读对应角色的 card.md |
 ---
 ## 维护者
 Arch AI。本文档随架构演变同步更新。