dsh-punky-swarm 0.3.6

package/skills/jiufeng-team/references/roles/manager.md

@@ -0,0 +1,22 @@
+# Manager — 任务池调度+派发+门禁裁决
+
+## Persona（注入用）
+任务池调度+门禁裁决；只读黑板/mailbox 建议派发，不代产 plan 产物。
+
+## 职责与产出
+- 职责：**不产出 plan 产物**（决策包/spec/task-tree/coder-tasks/tester-tasks 归 Designer）；任务池调度（空闲节点发现与建议派发）；状态迁移（member_status running→review / 恢复 idle→running）；门禁裁决（review→merged/conflict）；收发 mailbox 元数据；读批次状态（batch_status/gate_status）。
+- 产出：状态写入批次状态文件；决策记录 artifacts/<batchId>/manager-notes.md（可选）
+
+## 权限边界（注入用）
+- 可执行：治理工具（batch_*/member_*/mailbox_*/lane_*/gate_status/assign_check/asset_claim）+ read/skill
+- 禁止：写实现；产出 plan 产物（spec/四件套正文，归 Designer）；改 lane 状态（只经 member_status）
+- 约束：公共约束见 SKILL.md §worker 公共约束
+
+## 协作方式（dsh 语义）
+
+- 协作方式：公共语义单一来源见 SKILL.md；本角色差异如下
+- 派发：worker 由 Leader 经 member_status 置 running → subagent 派发（depth-1 直系，任务包含角色/目标/契约/验收）；Manager 不派发子代理，只经 mailbox 建议派发（lane+角色）
+- 指挥循环（每 turn）：batch_status 读黑板 → lane_heartbeat 心跳检查（过期检测，stalled 以事件表达，不改变成员状态） → mailbox_send inbox/broadcast 建议派发（**建议派发时从 batch_status 读取 sessionId/产物根注入任务包，禁止手写；C 类多 lane 写同一 git 仓库时先 lane_worktree_create 建独立 worktree，将返回路径注入任务包作 cwd 契约**） → mailbox_read outbox 收 worker 完成通知 → member_status running→review → member_settle 结算裁决（可用 gate_status 复核 GATE_EXIT_MISSING）；lane_worktree_merge 冲突 → 保留现场（worktree/分支/在途 merge 全保留）待裁决，conflict 语义由 Manager/Leader 裁决
+- 回执：worker 双通道——report 回报 Leader（简短完成信号）+ mailbox_send outbox 通知 Manager（详细）；Manager 不读 report（不经 Leader 转发全文）
+- 门禁（差异）：人审门禁——全额通过自动放行 / 3 次打回 → Leader
+- 交互：被 Leader send_message 事件唤醒（worker 完成信号）；不主动上报空闲（dsh 无空闲上报协议）；跨轮信息走产物+mailbox

package/skills/jiufeng-team/references/roles/reviewer.md

@@ -0,0 +1,19 @@
+# Reviewer — 对抗式审查+MUST/SHOULD/FYI
+
+## Persona（注入用）
+对抗式审查+MUST/SHOULD/FYI。只读不改码，缺陷分级报告，不修 bug。
+
+## 职责与产出
+- 职责：对抗式审查代码/产物，对照 spec 与验收标准；输出 MUST/SHOULD/FYI 分级；只读审查不改码。
+- 职责（audit lane 命名统一）：audit lane 统一命名 `audit-accept` / `audit-verify`，禁止「修复」「定论」「方案评估」等字样进入任务名（命名收敛避免放大「audit 自修」观感）。
+- 产出：artifacts/<batchId>/review-<lane>.md（报告含「待 Leader 处置的 gap 清单（不得由 audit 执行）」章节，修复须经新批次 exec 执行）+（推荐，非强制）artifacts/<batchId>/acceptance-checklist.md（对照 spec 验收标准逐项核对）；产物可含独立行 `gate: <命令>`（行首锚定，可多行顺序执行）→ merged 前置确定性执行，exit 0 通过；失败拒 merged（GATE_EXIT_*，lane 留 review）；失败且产物声明 needHuman: true → 转人工闸
+
+## 权限边界（注入用）
+- 可执行：read/glob/grep/pwsh/skill
+- 禁止：改业务源码（只读）；修 bug（缺陷走报告）
+- 约束：公共约束见 SKILL.md §worker 公共约束
+
+## 协作方式（dsh 语义）
+
+- 协作方式：公共语义单一来源见 SKILL.md；本角色差异如下
+- **不复用**：audit worker 完成一次派发即终态；追加任务（补充验证/修复后重跑）须新建 lane 重新派发，禁止 send_message 复用同一 worker

package/skills/jiufeng-team/references/roles/supervisor.md

@@ -0,0 +1,13 @@
+# Supervisor — CBM 全量验收+gap-list 对账→门禁
+
+## Persona（注入用）
+CBM 全量验收+gap-list 对账→门禁；只读验收，输出 gap-list，不改码不改 DB。
+
+## 职责与产出
+- 职责：全量验收（对照 CBM 断言/验收标准）；audit gap-list 对账（逐项核对→未闭合项入 gap-list.json；**gap-list.json 唯一产出者 = Supervisor，audit 对账产出**）；输出验收结论供 Leader 门禁。
+- 产出：artifacts/<batchId>/acceptance-report.md + gap-list.json（唯一产出者 = Supervisor，audit 对账产出）；产物可含独立行 `needHuman: true` 声明 → merged 须带人工裁决证据 `human:<裁决人>:<时间>:<结论>`（如 human:user@2026-08-21:accept），缺则 GATE_NEEDHUMAN_PENDING 拒 merged
+
+## 权限边界（注入用）
+- 可执行：read/glob/grep/pwsh/skill
+- 禁止：改业务源码/DB（只读）
+- 约束：公共约束见 SKILL.md §worker 公共约束

package/skills/jiufeng-team/references/roles/tester.md

@@ -0,0 +1,13 @@
+# Tester — spec 驱动测试，不打回约束
+
+## Persona（注入用）
+spec 驱动测试+功能验证与全量测试；只读验证，缺陷登记不修复。
+
+## 职责与产出
+- 职责：**承担功能验证与全量测试：端到端、回归、验收执行**（Coder 最小自检剥离项全归 Tester）；按 tester-tasks/spec 补测与执行；只读验证（不改业务源码/DB）；缺陷登记不修复（打回=重新测试，不替 Coder 改码）。
+- 产出：artifacts/<batchId>/test-report.md（用例/结果/缺陷清单）+（推荐，非强制）可执行测试套件（运行产出 PASS/FAIL 证据）
+
+## 权限边界（注入用）
+- 可执行：read/glob/grep/pwsh/skill
+- 禁止：改业务源码/DB（只读验证）；修 bug
+- 约束：公共约束见 SKILL.md §worker 公共约束

package/skills/jiufeng-team/references/templates/call-chain-matrix-template.md

@@ -0,0 +1,121 @@
+# 调用链矩阵模板
+
+> 本文档定义前端行为触发的完整调用链映射，作为 spec.md 的组成部分。
+> Designer 在产出四件套时，必须为每个涉及前端-后端交互的行为填充此模板。
+> **目标**：确保每个前端变更的调用链完整性，避免"修改项独立作用"和"孤儿代码"。
+
+---
+
+## 调用链总览
+
+| 调用链 ID | 触发端 | 起始事件 | 中间链路 | 终结点 | 穿透层级 | 复杂度 |
+|-----------|--------|---------|---------|--------|---------|:------:|
+| CH-01 | 前端 | PageX.submitBtn.onClick | → API /api/v1/xxx → ServiceX.method() → Repository.find() | DB table_x | 4 层 | 中 |
+| CH-02 | 前端 | PageY.searchInput.onChange | → API /api/v1/yyy → ServiceY.search() → External API /ext/zzz | 外部服务 | 4 层 | 高 |
+
+### 穿透层级说明
+
+| 层级 | 含义 | 示例 |
+|:----:|------|------|
+| 1 | 前端事件层 | 用户操作、组件生命周期、路由变更 |
+| 2 | 前端数据层 | API 调用、状态管理(Store/State)、本地缓存 |
+| 3 | 后端 API 层 | 路由、中间件、请求/响应处理 |
+| 4 | 后端服务层 | 业务逻辑、服务编排、数据组装 |
+| 5 | 数据层 | 数据库读写、外部服务调用、缓存读写 |
+
+---
+
+## 逐条调用链详述
+
+### CH-XX：{行为描述}
+
+#### 完整链路
+
+```
+前端事件层:
+  [PageX.Component.Event] → 事件 handler 执行
+     ↓
+前端数据层:
+  状态变更 (loading=true) → 构建 API 请求参数 → 发起 HTTP 请求
+     ↓ HTTP Request
+后端 API 层:
+  路由匹配 → 中间件(鉴权/参数校验) → Controller 处理
+     ↓
+后端服务层:
+  Service 方法调用 → 业务规则执行 → 数据组装
+     ↓
+数据层:
+  Repository/DAO 查询/写入 → DB / 外部服务
+     ↑
+后端服务层:
+  结果处理 → 异常转换 → 响应组装
+     ↑ HTTP Response
+前端数据层:
+  响应解析 → 状态更新 (loading=false) → 数据绑定 → UI 渲染
+```
+
+#### 关键节点
+
+| 节点 | 角色 | 预期行为 | 异常处理 |
+|------|------|---------|---------|
+| **事件触发** | 前端 | 用户操作后触发事件 handler | 防抖/节流/重复提交防护 |
+| **API 调用** | 前端 | 构建请求参数，发起 HTTP 请求 | 超时重试、网络不可达提示 |
+| **权限校验** | 后端 API | 验证用户身份和权限 | 401 跳转登录 / 403 无权限提示 |
+| **业务处理** | 后端服务 | 执行业务规则，组装结果 | 业务异常 → 结构化错误码返回 |
+| **数据访问** | 数据层 | 查询/写入数据源 | 连接超时/数据不存在 → 降级或报错 |
+| **状态更新** | 前端 | 解析响应，更新本地状态 | 响应异常 → 错误 UI 展示 |
+| **UI 渲染** | 前端 | 根据最新状态重新渲染 | 渲染异常 → fallback UI |
+
+#### 影响面分析
+
+| 影响组件 | 影响类型 | 影响描述 | 防范措施 |
+|---------|---------|---------|---------|
+| `{ComponentA}` | 直接 | 调用链变更导致其输入数据格式变化 | 同步更新组件接口适配 |
+| `{ComponentB}` | 间接 | 依赖同一 API 的不同调用链可能受影响 | 回归测试该组件的调用链 |
+| `{API Name}` | 直接 | 修改 API 响应结构可能影响其他前端页面 | 新增字段而非修改/删除已有字段 |
+
+#### 调用链验收标准
+
+```
+[CH-XX] 调用链验收标准
+- [ ] 完整调用链可通过端到端测试验证
+- [ ] 每个节点的输入/输出可独立断言
+- [ ] 任一节点异常时，调用链有明确的降级/错误处理路径
+- [ ] 影响面中的全部组件完成回归测试
+- [ ] 无孤儿代码：调用链中所有修改点都有对应的消费者
+```
+
+---
+
+## 孤儿代码防范检查
+
+### 修改项影响面声明
+
+| 修改项 | 类型 | 影响范围 | 反向依赖 | 风险等级 |
+|--------|------|---------|---------|:--------:|
+| `{文件名/组件}` | 新增/修改/删除 | {影响的调用链 ID 列表} | {依赖该修改项的其他模块} | L/M/H |
+
+### 检查规则
+
+1. **每项修改必须标注影响面**：修改什么 + 会影响到哪些调用链 + 哪些组件会受影响
+2. **每项删除必须确认反向依赖**：删除前 grep 全项目确认无其他消费者
+3. **每项 API 变更必须兼容**：新增字段/可选参数优先，禁止直接修改或删除已有字段
+4. **调用链断裂检测**：如果 A 调用链的产出是 B 调用链的输入，修改 A 时必须同步验证 B
+
+### 风险等级定义
+
+| 等级 | 含义 | 处理要求 |
+|:----:|------|---------|
+| **L** | 影响面可控，仅涉及单个组件/文件 | 常规自检即可 |
+| **M** | 影响多个组件或调用链 | 回归测试受影响范围 |
+| **H** | 影响面跨模块/跨团队，或存在断裂风险 | **回报人审，给出影响分析报告和建议方案** |
+
+---
+
+## 调用链复杂度与人审门禁
+
+| 复杂度 | 判定标准 | 处理方式 |
+|:------:|---------|---------|
+| **低** | 2-3 层，无外部依赖 | Reviewer 常规审查 |
+| **中** | 3-4 层，有外部依赖但有明确降级方案 | Reviewer 常规审查 + Supervisor gap-list 对账 |
+| **高** | ≥4 层，多个外部依赖，或存在数据一致性风险 | **Supervisor 回报人审，给出影响分析和建议方案后由用户决策** |

package/skills/jiufeng-team/references/templates/endpoint-behavior-template.md

@@ -0,0 +1,60 @@
+# 端点行为定义模板
+
+> 本文档定义前端端点和 API 端点的行为规范，作为 spec.md 的组成部分。
+> Designer 在产出四件套时，必须为每个受影响的端点填充此模板。
+
+---
+
+## 端点行为明细表
+
+| 端点 ID | 类型 | 路径/标识 | 方法/事件 | 触发条件 | 输入 | 输出/响应 | 错误码 | UI 影响 |
+|---------|------|-----------|----------|---------|------|----------|--------|---------|
+| EP-01 | API | `/api/v1/xxx` | POST | 用户点击提交按钮 | `{请求体结构}` | `{响应体结构}` | 400/404/500 | 提交按钮进入 loading → 成功跳转页面 / 失败显示错误提示 |
+| EP-02 | 前端事件 | `PageX.submitBtn.onClick` | 点击事件 | 表单填写完整后点击 | `{表单字段}` | 调用 API → 更新本地状态 → 路由跳转 | N/A | 按钮 disable + spinner → 页面对比更新 / Toast 提示 |
+
+### 字段说明
+
+| 字段 | 说明 |
+|------|------|
+| **端点 ID** | 全局唯一标识，格式 `EP-{序号}`，供 coder-tasks/tester-tasks 引用 |
+| **类型** | `API`（HTTP 端点）或 `前端事件`（组件事件） |
+| **路径/标识** | API 端点为 URL 路径；前端事件为 `Page.Component.Event` 格式 |
+| **方法/事件** | API 端点为 HTTP Method；前端事件为 DOM 事件类型 |
+| **触发条件** | 该端点被调用的前置条件 |
+| **输入** | API 端点为请求体 JSON Schema；前端事件为事件载荷的数据结构 |
+| **输出/响应** | API 端点为响应体 JSON Schema；前端事件为调用后的状态变更/副作用 |
+| **错误码** | API 端点的 HTTP 状态码及含义；前端事件为异常状态的处理方式 |
+| **UI 影响** | 该端点执行后前端 UI 的预期变化（加载态/成功态/错误态/跳转） |
+
+---
+
+## 端点依赖关系
+
+| 端点 ID | 依赖的端点 | 依赖类型 | 说明 |
+|---------|-----------|---------|------|
+| EP-01 | EP-02 | 先决 | EP-02 完成后 EP-01 才能获取到所需数据 |
+| EP-03 | — | 独立 | 无依赖，可独立开发和测试 |
+
+### 依赖类型
+
+| 类型 | 含义 |
+|------|------|
+| **先决** | 本端点依赖目标端点先执行完成 |
+| **数据** | 本端点依赖目标端点产生的数据 |
+| **并行** | 两个端点无依赖，可并行开发和测试 |
+| **互斥** | 两个端点不能同时触发 |
+
+---
+
+## 端点级验收标准
+
+每个端点必须满足以下验收标准：
+
+```
+[EP-XX] 验收标准
+- [ ] 输入校验：无效输入返回正确错误码/错误状态
+- [ ] 正常流程：合法输入返回预期输出/预期 UI 变更
+- [ ] 边界条件：[具体边界值] 时行为正确
+- [ ] 错误处理：超时/网络异常/服务不可用时的降级表现
+- [ ] UI 一致性：成功/失败/加载三种状态 UI 表现符合设计稿
+```

package/skills/jiufeng-team/references/templates/gap-list.json

@@ -0,0 +1,33 @@
+{
+  "version": "1",
+  "round_id": "round-YYYYMMDD-NNN",
+  "generated_by": "supervisor",
+  "generated_at": "YYYY-MM-DDTHH:MM:SS+08:00",
+  "gaps": [
+    {
+      "id": "G001",
+      "type": "missing",
+      "severity": "high",
+      "source_pkg": "M-01",
+      "source_ref": "spec.md §3.1.2",
+      "description": "用户注册 API 缺少邮箱格式校验逻辑",
+      "suggested_output": "artifacts/<batchId>/code/user-module/validation/email.py",
+      "evidence": "在 artifacts/<batchId>/code/user-module/ 目录中未找到任何 validation 相关文件"
+    }
+  ],
+  "summary": {
+    "total_gaps": 1,
+    "by_type": {
+      "missing": 1,
+      "partial": 0,
+      "contradicts": 0,
+      "unrequested": 0
+    },
+    "by_severity": {
+      "critical": 0,
+      "high": 1,
+      "medium": 0,
+      "low": 0
+    }
+  }
+}

package/skills/jiufeng-team/references/templates/leader-decision-pack.md

@@ -0,0 +1,92 @@
+# Leader 决策包模板
+
+> 本文档是任务监管块（人审门禁）的输出产物模板。
+> Leader 在完成 grill 质询 + 人工介入对接细节后，按此模板产出决策包下发给 Coordinator。
+
+---
+
+## 1. 粗拆方向
+
+### 需求描述
+
+{一句话概括本轮需求的本质}
+
+### 子模块划分建议
+
+按前后端分离 + 依赖链路，建议拆分为以下子模块：
+
+| 模块 ID | 名称 | 前后端标记 | 前置依赖 | 说明 |
+|--------|------|-----------|---------|------|
+| M-01 | {名称} | BE / FE / Both | 无 / M-XX | {简要说明} |
+| M-02 | {名称} | BE / FE / Both | M-01 | {简要说明} |
+| ... | ... | ... | ... | ... |
+
+> 粗拆仅到顶层子模块级；API 粒度由 Coordinator 细拆产出 task-tree.json 后交 Designer 消费产出任务包。
+
+### 子模块间依赖关系图（可选）
+
+```
+M-01 → M-02 → M-04
+  ↘ M-03 ↗
+```
+
+---
+
+## 2. 约束清单
+
+### 技术约束
+
+| # | 约束 | 来源 |
+|---|------|------|
+| 1 | {技术栈/框架/版本要求} | {grill / 人工对接 / 顶层设计} |
+| 2 | {系统架构限制} | {来源} |
+
+### 边界约束
+
+| # | 约束 | 说明 |
+|---|------|------|
+| 1 | {在本次范围内} | {具体描述} |
+| 2 | {明确排除的范围} | {具体描述} |
+
+### 交付约束
+
+| # | 约束 | 说明 |
+|---|------|------|
+| 1 | {时间窗口} | {DDL 或周期限制} |
+| 2 | {质量红线} | {必须通过的验收条件} |
+
+### 风险备忘
+
+| # | 风险点 | 影响 | 建议处理方式 |
+|---|--------|------|-------------|
+| 1 | {grill 中暴露的不确定点} | {影响范围} | {粗拆时特别注意的事项} |
+
+---
+
+## 3. 人审验收标准（粗拆成果）
+
+粗拆成果满足以下条件时，Leader 自审后交用户人审：
+
+- [ ] 每个子模块有明确的前后端归属
+- [ ] 子模块间依赖链路清晰
+- [ ] 约束清单已逐项对照，无越界
+- [ ] 所有风险备忘已在粗拆中处理或标注
+
+---
+
+## 4. 参考材料
+
+- {grill 关键决策记录路径}
+- {需求文档路径}
+- {顶层设计文档路径（如有）}
+
+---
+
+## 5. 元信息
+
+| 字段 | 内容 |
+|------|------|
+| 决策包版本 | v{1.0} |
+| 创建时间 | {ISO 时间} |
+| 人审门禁（发起 → 通过） | {发起时间} → {通过时间} |
+| 下发对象 | Coordinator |

package/skills/jiufeng-team/references/templates/plan-template.md

@@ -0,0 +1,61 @@
+# Plan: [Module Name]
+
+**参照 spec**：spec.md §[章节号]
+
+**外部输入**：
+- Tech Stack & Version: [由外部预置，Designer 不自主决定]
+- 开发方案大方向: [由 Leader/Coordinator 预先提供]
+
+---
+
+## Data Model
+
+### 核心实体
+
+| 实体 | 说明 | 关键字段 | 关联实体 |
+|------|------|---------|---------|
+| [Entity] | [描述] | [字段列表] | [关联] |
+
+### 数据流概要
+
+```
+[描述数据在核心实体间的流转路径]
+```
+
+---
+
+## Constraints
+
+### 性能约束
+
+| 指标 | 目标 | 测量方式 |
+|------|------|---------|
+| P95 延迟 | < [N]ms | [工具/方式] |
+| 吞吐量 | [N] req/s | [工具/方式] |
+
+### 安全约束
+
+- [ ] OWASP Top 10 合规
+- [ ] 敏感数据加密（传输 TLS + 存储加密）
+- [ ] 认证/授权机制（参考 constitution.md Security Baselines）
+- [ ] 输入校验与防注入
+
+### 合规约束
+
+- [ ] 数据本地化要求（参考 constitution.md Compliance Constraints）
+- [ ] 其他法规要求
+
+---
+
+## Performance Goals
+
+| 目标 | 当前基线 | 目标值 | 验收方式 |
+|------|---------|--------|---------|
+| [目标] | [基线] | [目标值] | [验收方式] |
+
+---
+
+## 参照文档
+
+- spec.md §[章节] — 功能需求与 API 设计
+- constitution.md §[章节] — 治理约束

package/skills/jiufeng-team/references/templates/success-pattern-seeds.md

@@ -0,0 +1,126 @@
+# 成功模式种子
+
+> 本文档预置蟛蜞模式首轮复盘可复用的成功模式。
+> Doc-Manager 在首轮复盘时可参考这些种子进行模式提取，
+> 也可逐条通过 dsh-mneme 落库作为初始知识库。
+> 格式：每条种子包含归属阶段 + 描述 + 复用建议 + dsh-mneme 等价写法，与复盘 Output Schema 对齐。
+
+---
+
+## 粗拆阶段
+
+### SP-01：前后端分离 + 依赖链路粗拆
+
+- **描述**：按前后端分离（BE/FE/Both）标注每子模块，再按依赖链路排序（无依赖的优先）。避免出现跨前后端的混合子模块。
+- **复用建议**：所有粗拆场景通用。如遇不可分离的跨端功能，标注为 Both 并在细拆时再分离。
+- **dsh-mneme 语义**：`memory_save(type='history', title='SP-01 前后端分离+依赖链路粗拆', importance=3)`（成功模式）
+
+### SP-02：约束清单逐项对照
+
+- **描述**：粗拆后逐项对照 Leader 约束清单的 4 类约束（技术/边界/交付/风险），确保粗拆不越界、不遗漏。
+- **复用建议**：每次粗拆必做约束对账，发现冲突立即上报 Leader。
+- **dsh-mneme 语义**：`memory_save(type='history', title='SP-02 约束清单逐项对照', importance=3)`（成功模式）
+
+---
+
+## 设计排期阶段
+
+### SP-03：单子模块逐个迭代
+
+- **描述**：每子模块独立过设计排期 → 细拆 → 执行 → 验收 → 复盘 全链路，不并行处理多个子模块的设计。
+- **复用建议**：除非子模块间完全无依赖关系（极少情况），否则坚持单子模块串行迭代。
+- **dsh-mneme 语义**：`memory_save(type='history', title='SP-03 单子模块逐个迭代', importance=3)`（成功模式）
+
+---
+
+## 细拆排期阶段
+
+### SP-04：API 粒度细拆
+
+- **描述**：Coordinator 先按 spec.md 中的 API 定义将 Coder 任务细拆到单个 API 级别（一个 API = 一个子任务，产出 task-tree.json），Designer 再消费 task-tree 产出任务包（四件套），Leader 复核后派发。
+- **复用建议**：API 级细拆让 Coder 和 Tester 的任务边界清晰，避免"一个任务做太多事"。
+- **dsh-mneme 语义**：`memory_save(type='history', title='SP-04 API 粒度细拆', importance=3)`（成功模式）
+
+---
+
+## 编码阶段
+
+### SP-05：Coder 自检后交付 + 测试两段式
+
+- **描述**：Coder 完成代码后先做最小自检（语法检查/lint/编译/已改文件单测冒烟），确认无基本问题后再交付；测试套件准备与 code 同 wave 并行（只依赖 plan 产物），执行段在 code 完成自检后立即触发，不等 Coder 通知。
+- **复用建议**：减少 Tester 因编译错误或基本语法问题被动打回的次数；两段式让测试准备与编码并行、执行紧贴自检完成，缩短串行等待。
+- **dsh-mneme 语义**：`memory_save(type='history', title='SP-05 Coder 自检后交付+测试两段式', importance=3)`（成功模式）
+
+---
+
+## 测试阶段
+
+### SP-06：Spec 驱动测试（非 Manager 驱动）
+
+- **描述**：Tester 收到任务后自主读取 spec.md 的 Acceptance Criteria 构建测试集，不等待 Manager 逐条下达。
+- **复用建议**：减少 Manager 的沟通开销，Tester 的测试更全面（spec 覆盖度更高）。
+- **dsh-mneme 语义**：`memory_save(type='history', title='SP-06 Spec 驱动测试', importance=4)`（成功模式）
+
+### SP-07：每次打回记录失败模式
+
+- **描述**：Tester/Reviewer 每次打回时，在打回裁定中附带失败模式标签（如"需求偏差/spec 不清晰/实现遗漏/测试不足"）。
+- **复用建议**：为 Doc-Manager 复盘积累结构化失败数据，便于根因分析。
+- **dsh-mneme 语义**：`memory_save(type='history', title='SP-07 每次打回记录失败模式', importance=4)`（成功模式）
+
+---
+
+## 审查阶段
+
+### SP-08：打回时附带 MUST-FIX 清单
+
+- **描述**：Reviewer 打回 REWORK 时，必须输出结构化 MUST-FIX 清单（条目编号、预期行为、严重级别），不输出模糊描述。
+- **复用建议**：减少 Coder 理解打回意图的认知开销，提高返工效率。
+- **dsh-mneme 语义**：`memory_save(type='history', title='SP-08 打回时附带 MUST-FIX 清单', importance=3)`（成功模式）
+
+---
+
+## 复盘阶段
+
+### SP-09：复盘必读 6 类产出物
+
+- **描述**：Doc-Manager 复盘时逐个读取 Leader 决策包、Designer 四件套、Coder 代码、Tester 报告、Reviewer 裁定、Supervisor 验收报告——缺一不可。
+- **复用建议**：缺失任何一类产出物，复盘结论的完整性就有缺口。
+- **dsh-mneme 语义**：`memory_save(type='history', title='SP-09 复盘必读 6 类产出物', importance=4)`（成功模式）
+
+### SP-10：成功/失败模式结构化入库
+
+- **描述**：每轮复盘提取的模式必须分类写入 dsh-mneme：成功模式 `memory_save(type='history', ...)`、失败模式 `memory_save(type='decision', ...)`，且每条标注归属阶段。
+- **复用建议**：结构化入库确保后续 Doc-Manager/Coordinator 能按阶段与类型检索复用。
+- **dsh-mneme 语义**：成功模式 `memory_save(type='history', title='SP-10 成功/失败模式结构化入库', importance=4)`；失败模式 `memory_save(type='decision', title='SP-10 失败模式入库', importance=4)`
+
+---
+
+## 入库脚本（可选）
+
+如果希望将以上种子批量写入 dsh-mneme，可用以下 memory_save 命令逐个写入（成功模式 `type='history'`，失败模式 `type='decision'`，importance 3~4）：
+
+```python
+# 示例：批量写入种子（dsh-mneme）
+# memory_save(type='history', title='SP-01 前后端分离+依赖链路粗拆',
+#             content='按前后端分离（BE/FE/Both）标注子模块，再按依赖链路排序。', importance=3)
+# memory_save(type='history', title='SP-02 约束清单逐项对照',
+#             content='粗拆后逐项对照 Leader 约束清单 4 类约束，确保不越界、不遗漏。', importance=3)
+# memory_save(type='history', title='SP-03 单子模块逐个迭代',
+#             content='每子模块独立过设计排期→细拆→执行→验收→复盘全链路，不并行处理多个子模块设计。', importance=3)
+# memory_save(type='history', title='SP-04 API 粒度细拆',
+#             content='Coordinator 先按 spec.md API 定义将 Coder 任务细拆到单个 API 级别（task-tree.json），Designer 再消费产出任务包。', importance=3)
+# memory_save(type='history', title='SP-05 Coder 自检后交付+测试两段式',
+#             content='Coder 最小自检通过后交付；测试套件准备与 code 同 wave 并行，执行段在自检完成后立即触发。', importance=3)
+# memory_save(type='history', title='SP-06 Spec 驱动测试',
+#             content='Tester 自主读取 spec.md Acceptance Criteria 构建测试集，不等待 Manager 逐条下达。', importance=4)
+# memory_save(type='history', title='SP-07 每次打回记录失败模式',
+#             content='打回时附带失败模式标签，为 Doc-Manager 复盘积累结构化失败数据。', importance=4)
+# memory_save(type='history', title='SP-08 打回时附带 MUST-FIX 清单',
+#             content='Reviewer 打回 REWORK 时输出结构化 MUST-FIX 清单（编号/预期行为/严重级别）。', importance=3)
+# memory_save(type='history', title='SP-09 复盘必读 6 类产出物',
+#             content='复盘逐个读取 Leader 决策包/Designer 四件套/Coder 代码/Tester 报告/Reviewer 裁定/Supervisor 验收报告。', importance=4)
+# memory_save(type='history', title='SP-10 成功/失败模式结构化入库',
+#             content='每轮复盘提取的模式按成功/失败分类写入 dsh-mneme，并标注归属阶段。', importance=4)
+```
+
+首轮运行时，建议至少写入 SP-01、SP-04、SP-06、SP-09、SP-10 作为最小种子集。