[moz] docs(§17): issue_assigned steps git 操作具体化 + ToolchainApiSection Git 说明段落

§6.2 issue_assigned 编码路径 steps 改为具体 git 命令序列
  (checkout main → pull → checkout -b → commit → push)
§6.4 新增 Git 操作说明段落设计（ToolchainApiSection 通用 git 参考）
§6.1 对照表更新步数描述
设计原则：系统不做分支管理，agent 自己执行 git 操作

.gitea/workflows/ci.yml

@@ -26,6 +26,7 @@ jobs:
 
       - name: Setup Python
         run: |
+          rm -rf /tmp/ci-venv-lint
           python3 -m venv /tmp/ci-venv-lint
           /tmp/ci-venv-lint/bin/pip install --quiet --upgrade pip
           /tmp/ci-venv-lint/bin/pip install --quiet flake8
@@ -62,12 +63,30 @@ jobs:
           (echo '=== RETRY WITH VERBOSE ===' && \
            PYTHONPATH=$(pwd) /tmp/ci-venv-test/bin/pytest tests/ -m "not e2e" -x -v 2>&1 | tail -30)
 
-  # ── Job 3: CI 失败通知 ───────────────────────────────
+  # ── Job 3: Frontend Build ───────────────────────────
+  frontend:
+    runs-on: macos-arm64
+    needs: lint
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup Node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+
+      - name: Install & Build
+        run: |
+          cd src/frontend
+          npm ci || npm install
+          npm run build
+
+  # ── Job 4: CI 失败通知 ───────────────────────────────
   # 使用 needs.<job>.result 直接判断，不查询 commit status API
   # 根因：notify 自身的 pending status 会污染 commit status 查询结果（竞态条件）
   notify-on-failure:
     runs-on: macos-arm64
-    needs: [lint, test]
+    needs: [lint, test, frontend]
     if: always()
     steps:
       - name: Check results and notify
@@ -75,12 +94,13 @@ jobs:
           GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
           LINT_RESULT: ${{ needs.lint.result }}
           TEST_RESULT: ${{ needs.test.result }}
+          FRONTEND_RESULT: ${{ needs.frontend.result }}
         run: |
           echo "Lint result: $LINT_RESULT"
           echo "Test result: $TEST_RESULT"
 
           # 只有 lint 或 test 明确失败时才发通知
-          if [ "$LINT_RESULT" = "failure" ] || [ "$TEST_RESULT" = "failure" ]; then
+          if [ "$LINT_RESULT" = "failure" ] || [ "$TEST_RESULT" = "failure" ] || [ "$FRONTEND_RESULT" = "failure" ]; then
             echo "CI has failures, sending notification..."
 
             # 如果是 PR 事件，写评论通知
@@ -90,6 +110,7 @@ jobs:
               FAILED_JOBS=""
               [ "$LINT_RESULT" = "failure" ] && FAILED_JOBS="${FAILED_JOBS}lint "
               [ "$TEST_RESULT" = "failure" ] && FAILED_JOBS="${FAILED_JOBS}test "
+              [ "$FRONTEND_RESULT" = "failure" ] && FAILED_JOBS="${FAILED_JOBS}frontend "
 
               curl -sf -X POST \
                 -H "Authorization: token $GITEA_TOKEN" \

.gitea/workflows/deploy.yml

@@ -110,15 +110,7 @@ jobs:
           PR_AUTHOR=$(curl --max-time 5 -sf \
             -H "Authorization: token $GITEA_TOKEN" \
             "$API_URL/repos/$REPO/pulls?state=closed&sort=updated&order=desc&limit=10" | \
-            python3 -c "
-import json, sys
-sha = '$COMMIT_SHA'
-for pr in json.load(sys.stdin):
-    merge_sha = pr.get('merge_commit_sha', '') or ''
-    if merge_sha.startswith(sha) or sha.startswith(merge_sha):
-        print(pr['user']['login'])
-        break
-" 2>/dev/null || echo "")
+            python3 -c "import json,sys; sha='$COMMIT_SHA'; matches=[pr['user']['login'] for pr in json.load(sys.stdin) if (pr.get('merge_commit_sha','') or '').startswith(sha) or sha.startswith(pr.get('merge_commit_sha','') or '')]; print(matches[0] if matches else '')" 2>/dev/null || echo "")
 
           # 确定通知对象
           if [ -n "$PR_AUTHOR" ]; then

docs/design/14-task-type-architecture.md

@@ -1,10 +1,11 @@
 ---
 title: "TaskTypeRegistry + Handler 架构重构"
 created: 2026-06-10
-version: v3.0
+version: v3.1
 ---
 
 > 状态: ✅ 已完成（Step 1-5 全部合并，394 passed）
+> v3.1 新增 §18：Mail Handler Verify/Prompt 强化（2026-06-16，进行中）
 
 # §1 现状分析（v3.0 更新说明：§1-§13 保留原样，新增 §14-§18，更新 §3/§5/§7）
 
@@ -585,6 +586,18 @@ class PromptComposer:
 | 50-59 | 硬约束 | 安全红线、禁止行为 |
 | 60-69 | 扩展段 | 保留给未来使用 |
 
+## 共性 Section（三 handler 共享）
+
+以下三个 Section 在 `prompt_composer.py` 中统一定义，被 Task/Mail/Toolchain 三个 handler 共同注入：
+
+| Section | priority | 用途 |
+|---------|----------|------|
+| `GiteaConventionSection` | 55 | Gitea Issue/PR 标题规范、分支命名、提交格式 |
+| `DeliveryChecklistSection` | 55 | 交付前检查清单（产出格式、验证项、必读文档） |
+| `WikiGuideSection` | 60 | Wiki 知识库检索指引（检索路径、优先级、知识缺口记录） |
+
+设计意图：将跨 handler 的共性约束从各 handler 的 ConstraintsSection 中抽离，避免重复维护。
+
 ---
 
 # §13 三个 Handler 的 Section 注册
@@ -601,6 +614,9 @@ def get_sections(self) -> list[PromptSection]:
         RoleSkillSection(priority=30),         # BootstrapBuilder 段 3（Skill 全文）
         TaskApiSection(priority=40),           # API 操作指令，success_status="review"
         TaskConstraintsSection(priority=50),   # 硬约束
+        GiteaConventionSection(priority=55),   # Gitea 协作规范（共性）
+        WikiGuideSection(priority=60),         # Wiki 知识库检索指引（共性）
+        DeliveryChecklistSection(priority=55), # 交付检查清单（共性）
     ]
 ```
 
@@ -611,6 +627,9 @@ def get_sections(self) -> list[PromptSection]:
 | RoleSkillSection | BootstrapBuilder 段 3 | 个性：只有 task 读 Skill 全文 |
 | TaskApiSection | spawner `_build_api_section` | **共性基础 + 个性参数**（success_status） |
 | TaskConstraintsSection | BootstrapBuilder 段 4 | 个性：每种 task 约束不同 |
+| GiteaConventionSection | prompt_composer.py | **共性**：Gitea Issue/PR 规范 |
+| WikiGuideSection | prompt_composer.py | **共性**：Wiki 检索指引 |
+| DeliveryChecklistSection | prompt_composer.py | **共性**：交付前检查清单 |
 
 ## MailHandler sections
 
@@ -620,6 +639,9 @@ def get_sections(self) -> list[PromptSection]:
         MailContextSection(priority=10),       # from/to/title/text，区分 inform/request
         MailApiSection(priority=40),           # API 操作指令，success_status="done"
         MailConstraintsSection(priority=50),   # 硬约束（禁止状态转换命令等）
+        GiteaConventionSection(priority=55),   # Gitea 协作规范（共性）
+        WikiGuideSection(priority=60),         # Wiki 知识库检索指引（共性）
+        DeliveryChecklistSection(priority=55), # 交付检查清单（共性）
     ]
 ```
 
@@ -628,6 +650,9 @@ def get_sections(self) -> list[PromptSection]:
 | MailContextSection | MAIL_INFORM_TEMPLATE / MAIL_REQUEST_TEMPLATE | 个性：邮件格式 |
 | MailApiSection | spawner `_build_api_section` 变体 | **共性基础 + 个性参数**（success_status="done"，含 Mail API 指令） |
 | MailConstraintsSection | 模板中的 ⚠️ 约束 | 个性 |
+| GiteaConventionSection | prompt_composer.py | **共性**：Gitea Issue/PR 规范 |
+| WikiGuideSection | prompt_composer.py | **共性**：Wiki 检索指引 |
+| DeliveryChecklistSection | prompt_composer.py | **共性**：交付前检查清单 |
 
 ## ToolchainHandler sections
 
@@ -637,6 +662,9 @@ def get_sections(self) -> list[PromptSection]:
         ToolchainContextSection(priority=10),  # 事件类型 + 事件详情
         ToolchainApiSection(priority=40),      # API 操作指令，success_status="done"
         ToolchainConstraintsSection(priority=50),  # 硬约束
+        GiteaConventionSection(priority=55),   # Gitea 协作规范（共性）
+        WikiGuideSection(priority=60),         # Wiki 知识库检索指引（共性）
+        DeliveryChecklistSection(priority=55), # 交付检查清单（共性）
     ]
 ```
 
@@ -645,6 +673,9 @@ def get_sections(self) -> list[PromptSection]:
 | ToolchainContextSection | toolchain_templates.py + md 文件 | 个性：事件格式 |
 | ToolchainApiSection | spawner `_build_api_section` 变体 | **共性基础 + 个性参数** |
 | ToolchainConstraintsSection | 新增 | 个性 |
+| GiteaConventionSection | prompt_composer.py | **共性**：Gitea Issue/PR 规范 |
+| WikiGuideSection | prompt_composer.py | **共性**：Wiki 检索指引 |
+| DeliveryChecklistSection | prompt_composer.py | **共性**：交付前检查清单 |
 
 ## Section 复用分析
 
@@ -655,6 +686,9 @@ def get_sections(self) -> list[PromptSection]:
 | *ConstraintsSection | ✅ | ✅ | ✅ | ❌ 约束内容不同，各自实现 |
 | PriorOutputsSection | ✅ | ❌ | ❌ | 仅 task |
 | RoleSkillSection | ✅ | ❌ | ❌ | 仅 task |
+| GiteaConventionSection | ✅ | ✅ | ✅ | **共性**：三 handler 共享，prompt_composer.py 定义 |
+| WikiGuideSection | ✅ | ✅ | ✅ | **共性**：三 handler 共享，prompt_composer.py 定义 |
+| DeliveryChecklistSection | ✅ | ✅ | ✅ | **共性**：三 handler 共享，prompt_composer.py 定义 |
 
 **结论**：ApiSection 可以抽一个 BaseApiSection（curl 模板 + success_status 参数），其余 section 各自实现。
 
@@ -667,9 +701,9 @@ src/daemon/
 ├── task_type_registry.py    # §3 + §4：Protocol + Registry
 ├── prompt_composer.py        # §12 PromptSection + PromptContext + PromptComposer
 ├── base_task_handler.py      # §16 BaseTaskHandler 基类
-├── task_handler.py           # §13 TaskHandler（继承 BaseTaskHandler）+ 5 sections
-├── mail_handler.py           # §13 MailHandler（继承 BaseTaskHandler）+ 3 sections
-├── toolchain_handler.py      # §13 ToolchainHandler（继承 BaseTaskHandler）+ 3 sections
+├── task_handler.py           # §13 TaskHandler（继承 BaseTaskHandler）+ 8 sections
+├── mail_handler.py           # §13 MailHandler（继承 BaseTaskHandler）+ 6 sections
+├── toolchain_handler.py      # §13 ToolchainHandler（继承 BaseTaskHandler）+ 6 sections
 ├── dispatcher.py             # §6 改动
 ├── spawner.py                # §6 改动
 ├── ticker.py                 # §6 改动
@@ -952,7 +986,219 @@ handler.post_complete(task_id, agent_id, outcome, db_path)
 
 ---
 
-## §14. Mail 失败通知机制
+## §18. Mail Handler Verify/Prompt 强化
+
+> 日期：2026-06-16 | 作者：庞统 | 状态：方向 1-5 全部已确认
+
+## 18.1 问题背景
+
+### 触发事件
+
+2026-06-12 daemon 重启后，_mail DB 中积压的 E2E 测试遗留邮件（5/18~6/1 创建，type=request，performative="text"）被 dispatch 给 agent。agent 正常处理并输出文本（如"已阅，无需处理"），但 `verify_completion` 判定 no_reply → 标 failed → 触发 `notify_mail_failed` → 产生 38 封 `[投递失败]` 通知邮件，每 ~2.5 分钟一轮，持续 10 轮。
+
+### 根因链
+
+```
+E2E 测试脚本 bug（type="text"）
+  → mail_routes.py 不校验 type 值，直接透传
+  → performative="text" ≠ "inform" → 走 _check_reply
+  → _check_reply 查 in_reply_to task，agent 没用 Mail API 回复
+  → verify 失败 → on_failure 标 failed
+  → notify_mail_failed 发 [投递失败] 通知
+  → 通知本身也是 task，循环触发
+```
+
+### 三种 handler verify 对比
+
+| 维度 | TaskHandler | MailHandler | ToolchainHandler |
+|------|------------|-------------|------------------|
+| verify 信号 | output / comment(≥50字) / terminal_status（三信号） | in_reply_to task（单信号） | action_report / output / comment(≥20字)（三层 fallback） |
+| inform 处理 | N/A | 直接通过（不检查执行证据） | N/A |
+| verify 失败后 | **留 working**（覆盖 post_complete） | **标 failed**（base post_complete + mail on_failure） | 标 failed（base post_complete + tc on_failure） |
+| agent 输出持久化 | 靠 agent 主动 POST output/comment | **无**（agent 输出只在内存） | 靠 agent 主动 POST action_report |
+
+**关键发现**：
+1. MailHandler 继承 BaseTaskHandler，未覆盖 `post_complete` → verify 失败时走 base 的 `on_failure` → 标 failed
+2. TaskHandler 覆盖了 `post_complete` → verify 失败时留 working，让 ticker 重试
+3. MailHandler 的 verify 只有 `in_reply_to` 一条路径，没有 fallback
+4. inform 类型直接通过（`VerifyResult(True)`），不检查任何执行证据——inform 是"无需回复"不是"无需检查"
+5. E2E 测试用 `TestClient(app)` 写生产 `_mail DB`，且测试脚本用了非标准 `type="text"`
+
+## 18.2 修复方向
+
+### 方向 1：mail verify 对齐 toolchain 模式（✅ 已确认）
+
+**问题**：mail verify 只有 in_reply_to task 一条路径。task/toolchain 都有多层 fallback（outputs / comments）。
+
+**方案**：mail 对齐 toolchain 模式——prompt 加 action report 要求，verify 优先查 action_report → fallback outputs → fallback comments。in_reply_to 回复邮件从唯一信号降为 request 类型的第 4 优先级信号。
+
+#### prompt 强化（MailApiSection）
+
+参照 ToolchainApiSection，在 mail prompt 中追加 action report 要求：
+```
+### 完成后必须提交 action report
+执行完邮件处理后，必须提交 action report：
+curl -s -X POST "http://localhost:8083/api/projects/_mail/tasks/{task_id}/comments" \
+  -H "Content-Type: application/json" \
+  -d '{"author": "{agent_id}", "comment_type": "action_report", "body": "处理结果摘要"}'
+
+⚠️ 不提交 action report 的任务会被标记为 failed。
+```
+
+#### verify 改造（MailHandler.verify_completion）
+
+```python
+def verify_completion(self, task_id, db_path) -> VerifyResult:
+    performative = self._parse_performative(task_id, db_path)
+
+    # 1. 优先检查 action_report comment（所有类型通用）
+    if self._has_action_report(task_id, db_path):
+        return VerifyResult(True, "has_action_report", "action_report found")
+
+    # 2. fallback: outputs
+    if self._has_outputs(task_id, db_path):
+        return VerifyResult(True, "has_output", f"output_count={count}")
+
+    # 3. fallback: 有实质内容的 comment（≥20字，非 system）
+    if self._has_comment(task_id, db_path):
+        return VerifyResult(True, "has_comment", f"comment_count={count}")
+
+    # 4. request 特有：检查 in_reply_to 回复邮件
+    if performative == "request":
+        if self._check_reply(task_id, db_path):
+            return VerifyResult(True, "has_reply", "in_reply_to found")
+
+    return VerifyResult(False, "no_action",
+                        "no action_report, no output, no comment, no reply")
+```
+
+注意：action_report 提交到 moziplus DB（comments 表），不是 Gitea。Gitea comment 是跨 agent 协作用的，不是 verify 检查的依据。
+
+### 方向 2：prompt 约束强化（✅ 已确认）
+
+**问题**：当前 mail prompt 只给了 curl 示例，没有硬约束要求 agent 必须输出处理结果。agent 判断"已阅"后直接跳过，不创建 in_reply_to task。
+
+**方案**：mail request/inform prompt 加 JSON 输出约束（参考 toolchain 的 Red Flags 模式）。
+
+#### MailContextSection 强化
+
+**request 类型**追加：
+```
+### 输出要求
+- 你的回复必须包含对邮件的实际处理结果
+- 如果是第一次收到：正常处理，输出处理结果
+- 如果是重复邮件（你之前处理过相同 ID 的邮件）：输出"此前已处理" + 之前的处理结果摘要
+- ⚠️ "已阅""无需处理"不是有效处理结果
+```
+
+**inform 类型**追加：
+```
+### 输出要求
+- 你的回复必须确认已处理（读取/执行/记录），不能只说"已阅"
+- 如果是重复邮件：输出"此前已处理" + 处理结果摘要
+- ⚠️ "已阅"不是有效输出
+```
+
+**MailConstraintsSection** 追加 Red Flags：
+```
+| Agent 想法 | Red Flag 驳回 |
+|------------|--------------|
+| "已阅即可" | ❌ 错！必须输出处理结果或确认执行 |
+| "重复邮件忽略" | ❌ 错！输出"此前已处理" + 结果摘要 |
+| "无需回复" | ❌ 错！request 必须回复，inform 必须确认处理 |
+```
+
+### 方向 3：inform 也要检查执行证据（✅ 已确认）
+
+**问题**：当前 inform verify 直接返回 `VerifyResult(True)`，不检查任何执行证据。inform 是"无需回复"不是"无需检查"。
+
+**方案**：inform verify 改为检查 agent 是否有实质输出（comment/output），和 request 走不同的验证路径但都需要验证。
+
+**改动文件**：`src/daemon/mail_handler.py` `verify_completion` 方法
+
+### 方向 4：verify 失败保持 working（✅ 已确认）
+
+**问题**：MailHandler 继承 BaseTaskHandler，verify 失败时走 base 的 `on_failure` → 标 failed。而 TaskHandler 覆盖了 `post_complete`，verify 失败时留 working。
+
+**原始设计意图**（§2 设计文档）："不通过 → 留 working，ticker 重查（最多 3 次，然后标 failed）"。
+
+**方案**：MailHandler 覆盖 `post_complete`，verify 失败时不标 failed，保持 working。ticker 的 `_check_timeouts` 超时兜底：
+- `check_completion` 通过（有回复）→ done
+- `check_completion` 不通过 → 超时后标 failed
+- Runaway Guard（§15 dispatch_count ≥ 10）兜底防止无限循环
+
+**改动文件**：`src/daemon/mail_handler.py`，新增 `post_complete` 覆盖
+
+### 方向 5：type 校验 + E2E 修复 + DB 清理（✅ 已确认）
+
+#### 5.1 mail_routes.py type 校验
+
+**问题**：`mail_type = body.get("type")` 直接透传，传什么存什么。`"text"` 不是标准值。
+
+**方案**：创建时校验 type 只允许 `inform` / `request`，非法值默认 `request`。
+
+```python
+mail_type = body.get("type")
+if mail_type is None:
+    mail_type = "inform" if in_reply_to else "request"
+elif mail_type not in ("inform", "request"):
+    # 非标准值，校正为默认值
+    mail_type = "inform" if in_reply_to else "request"
+```
+
+**改动文件**：`src/api/mail_routes.py`
+
+#### 5.2 _parse_performative 容错
+
+**问题**：`meta.get("performative", meta.get("type", "request"))` 当 performative="text" 时返回 "text"，不等于 "inform" → 走 _check_reply。
+
+**方案**：只认 `inform` 和 `request` 两个值，其他一律当 `request`。
+
+```python
+def _parse_performative(self, task_id, db_path) -> str:
+    raw = meta.get("performative", meta.get("type", "request"))
+    if raw == "inform":
+        return "inform"
+    return "request"  # 非标准值一律当 request
+```
+
+**改动文件**：`src/daemon/mail_handler.py` `_parse_performative` 方法
+
+#### 5.3 E2E 测试修复
+
+**问题**：`tests/e2e/test_e2e_v27.py` 用 `type="text"` 创建测试邮件，且用 `TestClient(app)` 写生产 `_mail DB`。
+
+**修复**：
+1. `type="text"` 全部改为 `type="inform"` 或 `type="request"`
+2. E2E 测试跑完后清理测试邮件（`mail_ids` 列表中记录的 task）
+
+**改动文件**：`tests/e2e/test_e2e_v27.py`
+
+#### 5.4 生产 DB 清理
+
+**问题**：生产 `_mail DB` 中残留大量 E2E 测试邮件（5/18~6/3 创建的"筛选测试""详情测试""已读测试""任务分配"等）。
+
+**方案**：手动清理这些测试残留（一次性操作，不需要代码改动）。
+
+## 18.3 影响范围
+
+| 文件 | 改动类型 | 影响面 |
+|------|---------|--------|
+| `src/daemon/mail_handler.py` | verify + post_complete + prompt section | MailHandler 核心逻辑 |
+| `src/api/mail_routes.py` | type 校验 | Mail API 创建入口 |
+| `tests/e2e/test_e2e_v27.py` | type 值修正 + 清理 | E2E 测试 |
+| 生产 `_mail DB` | 清理测试残留 | 一次性操作 |
+
+## 18.4 验证计划
+
+1. 单元测试：mail_handler verify/prompt 变更
+2. 集成测试：mail dispatch → verify → done/working 全链路
+3. 回归测试：`pytest -m "not e2e"` 全量
+4. 手工验证：创建 inform/request 邮件，确认 verify 行为正确
+
+---
+
+# §14. Mail 失败通知机制
 
 ### 20.1 背景
 

docs/design/15-runaway-guard.md

@@ -0,0 +1,61 @@
+# §15 Runaway Guard — Per-Task Dispatch 上限
+
+> 设计文档 v1.0 | 2026-06-16
+
+## 问题
+
+mail/toolchain task 走 handler auto-working（跳过 claim 阶段），不受 claim_timeout 的 3 次重试兜底保护。如果一个 auto-working task 反复 spawn 但永远到不了 done/failed，会无限循环消耗资源。
+
+### 实际案例
+
+2026-06-15 mention 重复投递事件：`spawn_full_agent` 在 `use_main_session=True` 时返回 `None`，ticker `_process_mentions` 误判为失败，每次 tick（30s）都重试。同一 mention 投递了 4 次，直到 retry_count 达到 mention_queue 的 5 次上限才停止。
+
+直接根因已由 PR #80 修复，但如果类似 bug 再次出现，当前没有任何机制阻止 task 层面的无限循环。
+
+## 设计
+
+### 机制
+
+tasks 表新增 `dispatch_count` 字段，每次 ticker 成功 dispatch 一个 task 时递增。当 `dispatch_count >= 10`（全局默认）时，自动标 failed。
+
+### 默认值选择
+
+全局默认 10 次。参考 Hermes v0.13 Best Practices §3 "Per-Task 重试上限"：
+
+- 简单任务重试 1 次
+- 复杂任务重试 3 次
+- crash recovery（3 次）+ api_retry（3 次）余量 = ~10 次
+
+### 适用范围
+
+所有 task 类型（task/mail/toolchain），所有非终态（pending/working/claimed）。
+
+### 检查时机
+
+在 `_check_timeouts` 方法开头，先于现有的 claimed/working 超时检查执行。
+
+### 与现有机制的关系
+
+| 机制 | 覆盖场景 | 触发动作 |
+|------|---------|---------|
+| claim_timeout retry_count >= 3 | 广播任务无人认领 | 升级庞统 |
+| crash_limit 3/30min | working 状态 crash | 标 failed |
+| api_retry_count | API 连续失败 | 标 failed |
+| 续杯 max_retries 3 | 续杯耗尽 | 标 failed |
+| working timeout | working 超时 | 标 failed 或 done |
+| **runaway_guard 10 次** | **任何状态的无限循环** | **标 failed** |
+
+runaway_guard 是最后一道防线，覆盖所有其他机制遗漏的循环场景。
+
+## 改动文件
+
+| 文件 | 改动 |
+|------|------|
+| `src/blackboard/db.py` | `_safe_add_column(conn, "tasks", "dispatch_count", "INTEGER DEFAULT 0")` |
+| `src/blackboard/models.py` | Task dataclass 加 `dispatch_count: int = 0` |
+| `src/daemon/ticker.py` | `_dispatch_pending` / `_dispatch_reviews` 递增 dispatch_count；`_check_timeouts` 加 runaway guard 检查 |
+
+## 参考
+
+- Hermes v0.13 Kanban Best Practices §3 "Per-Task 重试上限"
+- 实际案例：2026-06-15 mention 重复投递事件（PR #80 修复了直接根因，runaway guard 作为兜底）

docs/design/17-toolchain-handler-enforcement.md

@@ -391,7 +391,11 @@ def verify_completion(self, task_id: str, db_path: Path) -> VerifyResult:
 
 #### 完整设计
 
-三分路的详细伪代码、失败上限、决策依据见 §5.2.1~§5.2.3（on_failure 分路处理详细设计）。
+三分路的详细设计见 §6.4（基础设施 Issue 转交流程）和 toolchain_handler.py 实现（`_handle_infrastructure_failure` / `_classify_failure`）。
+
+#### 首次 steps 分支指引
+
+三分路是 verify 失败后的兜底机制。此外，ci_failure 和 deploy_failure 的首次 toolchain task steps 中**已包含分支指引**——agent 在执行过程中自行判断失败原因，如果是基础设施问题则直接创建 Issue 指派 jiangwei-infra（见 §6.4）。三分路作为第二道防线，覆盖 agent 未正确判断或未执行分支的情况。
 
 ### 5.3 action_report comment 格式
 
@@ -431,9 +435,9 @@ Agent 可能写了 action_report 但没真做。缓解机制：
 | Review 请求 → reviewer | review_request | toolchain | 4 步 | 读 diff + 审查 + 提交 Review + report |
 | Review 有新提交 → reviewer | review_updated | toolchain | 4 步 | 读 diff + 检查修改 + 提交 Review + report |
 | Review 评论 → PR 作者 | review_comment | toolchain | 3 步 | 查看评论 + 响应（修改/回复）+ report |
-| CI 失败 → PR 作者 | ci_failure | toolchain | 4 步 | 查 CI 日志 + 修测试 + push + report |
-| Issue 指派 → 开发者 | issue_assigned | toolchain | 6 步 | 创建分支 + 编码 + push + CI + PR + report |
-| 部署失败 → 运维 | deploy_failure | toolchain | 4 步 | 查日志 + 排查 + 修+重部署 + report |
+| CI 失败 → PR 作者 | ci_failure | toolchain | 3 步 | 查 CI 日志 + 分支判断（代码问题自己修 / 基础设施问题提 Issue 给姜维）+ report |
+| Issue 指派 → 开发者 | issue_assigned / infrastructure_failure | toolchain | 6 步（编码，含具体 git 命令）或 4 步（运维） | 按 label 分流：type/infrastructure → 运维排查；其他 → git checkout main/pull → 创建分支 → 编码 → push → CI → PR + report |
+| 部署失败 → 运维 | deploy_failure | toolchain | 3 步 | 查日志 + 分支判断（代码/配置问题自己修 / 基础设施问题提 Issue 给姜维）+ report |
 | @mention → 被@者 | mention | toolchain | 按 guidance | 按 mention 模板的 response_guidance + report |
 | PR 合并 → PR 作者 | review_merged | toolchain | 0 步 | 纯通知，走 _send_toolchain_task（steps 为空，verify 始终通过） |
 
@@ -502,29 +506,46 @@ event_type: ci_failure
 action_type: ci_failure
 steps:
   1. 查看完整 CI 日志（PR 页面或 Gitea Actions 页面）
-  2. 修复失败的测试
-  3. push → CI 自动重跑
-  4. 提交 action report
+  2. 根据 CI 日志判断失败原因类型：
+     a. 代码问题（lint/test 失败）→ 修复失败的测试 → push 到原分支 → CI 自动重跑
+     b. 基础设施问题（runner 环境/Python/venv/Gitea/网络故障）→ 在该仓库创建 Issue 指派 jiangwei-infra（见 §6.4），label 必须包含 type/infrastructure
+  3. 提交 action report — 报告中说明判断的原因类型和执行的操作
 context:
   pr_number, repo, branch, error_summary
 ```
 
+**分支设计说明**：原设计假设"CI 失败 = 代码问题"，steps 只有"修测试 + push"一条路径。实际运行中发现 CI 失败可能是 runner 环境故障（如 ensurepip 失败），agent 判断为基础设施问题后不知道该做什么。现在 steps 中明确两条分支，agent 自行判断后走对应路径。
+
 #### Issue 指派 → 开发者
 
 ```
-event_type: issue_assigned
-action_type: issue_assigned
-steps:
-  1. 创建分支 fix/{issue_number}-{brief}
+event_type: issue_assigned 或 infrastructure_failure
+action_type: issue_assigned 或 infrastructure_failure
+steps（按 label 分流）:
+
+  # 默认路径（编码任务）:
+  1. 在开发目录执行 git 操作：
+     a. git checkout main && git pull origin main  （确保从最新代码分叉）
+     b. git checkout -b fix/{issue_number}-{brief}  （创建功能分支）
   2. 编码 + 写 UT
-  3. push → 等 CI
-  4. CI 通过后创建 PR（Gitea API: POST /repos/{repo}/pulls）
+  3. git add -A && git commit -m "[moz] fix: {简述}" && git push origin fix/{issue_number}-{brief}
+  4. CI 通过后创建 PR（Gitea API: POST /repos/{repo}/pulls，head: fix/{issue_number}-{brief}, base: main）
   5. 等 Review
   6. 提交 action report
+
+  # type/infrastructure label 路径（运维任务）:
+  1. 根据 Issue body 中的错误来源和日志片段排查问题
+  2. 修复基础设施问题（如修复 CI runner 环境、恢复网络、重启服务等）
+  3. 修复后在 Issue 上 comment 说明修复方式和结果
+  4. 提交 action report
 context:
   issue_number, repo, issue_title, labels, issue_body, brief
 ```
 
+**label 分流说明**：issue_assigned handler 检查 label 中是否包含 `type/infrastructure`。如果是，走运维排查 steps（event_type 设为 infrastructure_failure，verify 始终 auto-pass 防递归）；否则走编码 steps。
+
+**编码路径 git 操作具体化说明**（§17 v3 补充）：原 steps 只写「创建分支」「push」等抽象指令，agent 需要自己推导具体 git 命令。现在 steps 中写清楚完整 git 操作序列（checkout main → pull → checkout -b → commit → push），降低 agent 出错概率。系统不做分支管理（不通过 Gitea API 预创建分支），分支管理完全由 agent 自己执行。ToolchainApiSection 中新增 Git 操作说明段落作为通用参考。
+
 #### 部署失败 → 运维
 
 ```
@@ -532,9 +553,10 @@ event_type: deploy_failure
 action_type: deploy_failure
 steps:
   1. 检查 deploy 日志
-  2. 排查失败原因
-  3. 修复并重新部署
-  4. 提交 action report
+  2. 根据 deploy 日志判断失败原因类型：
+     a. 代码/配置问题（rsync 路径错、依赖缺失、启动失败）→ 修复 → 重新部署
+     b. 基础设施问题（Gitea 不可用、网络不通、磁盘满、SSH 故障）→ 在该仓库创建 Issue 指派 jiangwei-infra（见 §6.4），label 必须包含 type/infrastructure
+  3. 提交 action report — 报告中说明判断的原因类型和执行的操作
 context:
   repo, commit_sha, reason
 ```
@@ -577,6 +599,89 @@ context:
 
 **spawn 说明**：review_merged 仍会触发 spawn（Agent 只需阅读通知），verify auto-pass 后标 done。未来可优化为 ticker 直接 auto-done 跳过 spawn。
 
+### 6.4 基础设施 Issue 转交流程
+
+当 ci_failure / deploy_failure 的 agent 在调查后发现失败原因是基础设施问题（非代码问题），需要创建 Gitea Issue 指派 jiangwei-infra。
+
+#### Issue 提在哪里
+
+**根据问题来源决定**——哪个仓库的 CI/部署失败了，Issue 就提到那个仓库。CI runner 是全局共享的（一个 Mac mini），但 Issue 挂在触发的仓库最自然。如果 runner 故障影响多个仓库，各仓库会各自触发 ci_failure task，姜维看到任何一个 Issue 就能定位全局问题。
+
+#### Issue 格式规范
+
+```markdown
+## 问题描述
+
+<简要描述问题现象>
+
+## 错误来源
+
+- 仓库: <repo>
+- PR/Commit: <链接>
+- CI/Deploy run: <Gitea Actions 页面链接>
+
+## 日志关键片段
+
+```
+<错误日志摘要，不需全文，但要让排查者看到关键信息>
+```
+
+## 判断依据
+
+<为什么判断为基础设施问题而非代码问题>
+```
+
+**必填字段**：问题描述、错误来源（含链接）、日志片段、判断依据。Issue body 不完整会导致姜维无法高效排查。
+
+**label 要求**：必须包含 `type/infrastructure`，用于 issue_assigned handler 分流（见下）。
+
+#### issue_assigned handler label 分流
+
+当 Gitea Issue 指派触发 webhook 时，issue_assigned handler 检查 label：
+
+| label 包含 type/infrastructure | event_type | steps |
+|---|---|---|
+| 是 | infrastructure_failure | 运维排查：根据 Issue body 排查问题 → 修复 → Issue comment 说明修复方式 → action report |
+| 否 | issue_assigned | 编码：创建分支 → 编码 → push → CI → PR → 等 Review → action report |
+
+基础设施路径的 verify 始终 auto-pass（防递归，已有逻辑覆盖）。
+
+⚠️ **label 分流当前为设计目标**，toolchain_handler.py 尚未实现 issue_assigned 的 label 检查。当前只有 `_handle_infrastructure_failure`（verify 失败时）创建 infrastructure_failure task。issue_assigned handler 的 label 分流在后续代码 PR 中实现。
+
+⚠️ **label 预创建**：使用前需确认仓库中已创建名为 `type/infrastructure` 的 label。sanguo_moziplus_v2 仓库已创建（ID=98）。其他仓库使用前需先创建。
+
+#### API 指令位置
+
+Issue 创建的 API 调用方式（curl 示例）统一在 ToolchainApiSection 中，与 action_report / comment 指引并列。steps 指令中不重复 API 调用方式，只描述"做什么"。
+
+#### Git 操作说明段落
+
+ToolchainApiSection 中新增通用 Git 操作说明段落，作为 agent 执行 git 命令的参考：
+
+```
+### Git 操作说明
+
+你的工作目录是开发目录。
+标准分支操作流程：
+  git checkout main && git pull origin main    # 从最新主干开始
+  git checkout -b fix/{branch_name}           # 创建功能分支
+  # ... 写代码 ...
+  git add -A && git commit -m 'message'        # 提交改动
+  git push origin {branch_name}               # 推送到远程
+
+⚠️ 不要在 main 分支上直接 commit。
+```
+
+**设计原则**：系统不做分支管理（不预创建分支、不做 checkout），分支管理完全由 agent 自己执行。ToolchainApiSection 提供通用 git 操作参考，steps 中写清楚具体操作序列。
+
+#### Red Flags 补充
+
+硬约束 Red Flags 表新增一条：
+
+| Agent 想法 | Red Flag 驳回 |
+|---|---|
+| "CI/部署失败不是我代码的问题，我什么也不用做" | ❌ 错！即使是基础设施问题，你也必须创建 Issue 指派 jiangwei-infra（body 含错误来源链接 + 日志 + 判断依据），并在 action report 中说明。不能只报告"不是我的问题"就完事 |
+
 ---
 
 ## §7. _send_toolchain_task 函数设计

docs/design/19-skill-lifecycle-and-experience-loop.md

@@ -0,0 +1,810 @@
+# §19 Skill 生命周期管理 + 经验闭环四阶段设计
+
+> 作者：庞统士元
+> 日期：2026-06-18（v2.0）
+> 状态：方案待确认
+> 前置：§14 Task 五层架构、§16 知识注入四层体系
+
+## 变更摘要（v2.0）
+
+| 变更项 | 原设计 | 新设计 | 理由 |
+|--------|--------|--------|------|
+| 蒸馏频率 | 庞统每天一次 | **双层 daily**：各 agent 03:00 自蒸馏 + 庞统 05:00 整合 | agent 是自己经验的最佳蒸馏者；庞统负责跨 agent 整合 |
+| 蒸馏者 | 庞统一人 | **双层**：L1 各 agent + L2 庞统 | 消除蒸馏者偏差；经验是 per-agent 的 |
+| .learnings/ | DISCOVER 数据源之一 | **废弃**。JSONL 是唯一数据源 | 信息冗余；agent 执行中不应分心写 .learnings/ |
+| 三重验证 | 跨任务复现 + 生成力 + 排他性 | **Recurrence-Count 机制**（融合 self-improvement skill） | ≥3 次自动触发提升，比主观判断更客观 |
+| Skill 数量 | 未明确 | **一个 skill：skill-management** + references/ 四阶段 | 减少上下文开销；DISCOVER/IMPROVE 是 cron 场景不需要独立 skill description |
+| self-improvement skill | 未提及 | **废弃**。优势融合到 DISCOVER 输出格式 | 职责重叠；统一为单一闭环 |
+| Skill 存放 | 未区分 | **per-agent 目录 + 公共目录** | agent 专属经验不污染其他 agent 上下文 |
+
+## 1. 背景
+
+moziplus v2.0 的 P4 剩余两项：
+- T7 C3：Skill 生命周期管理（draft → active → deprecated）
+- T7 C5：经验闭环 IMPROVE 阶段（DISCOVER → DISTILL → APPLY → IMPROVE 中的最后一步）
+
+### 当前实现状态
+
+| 组件 | 状态 | 问题 |
+|------|------|------|
+| `SkillRegistry`（skill_system.py） | 死代码 | 只有 register/match 方法，从未被外部调用 |
+| `SkillExecutor`（skill_system.py） | 死代码 | 从未被外部调用 |
+| `ExperienceDistiller`（experience.py） | 空转 | ticker 调用时没传 review_result 和 outputs，蒸馏函数收到 None 直接返回空 |
+| `ExperienceStore`（experience.py） | 空转 | experiences 目录全部为空 |
+| `experiences` 表（db.py） | 未使用 | 代码用 jsonl 文件不用 DB 表 |
+| Skill 生命周期 | 缺失 | 只有 enabled bool，无 draft/active/deprecated 状态流转 |
+
+**结论**：现有的 experience.py 和 skill_system.py 需要重新设计，不是修补能解决的。
+
+### 实际运行的知识体系
+
+实际的 Skill 发现和加载走的是 **openclaw 原生 skill 机制**：
+- openclaw 扫描 skills 目录 → 生成 `<available_skills>` 列表注入 system prompt
+- Agent 按 description 匹配 → `read` SKILL.md → 按内容执行
+- moziplus 的 SkillRegistry/SkillExecutor 完全不参与
+
+因此本设计**不重建 moziplus 的 skill 引擎**，而是基于 openclaw 原生机制构建。
+
+## 2. 设计目标
+
+1. 经验从「发现→蒸馏→应用→改善」形成完整闭环
+2. Skill 有明确的生命周期管理（draft → active → deprecated）
+3. 产物统一为 Skill，不再有 experiences.jsonl / .learnings/ 等中间形态散落各处
+4. 追踪 Skill 引用情况，支撑淘汰决策
+5. 充分利用 openclaw 已有的 skill_workshop 工具和 skill 加载机制
+6. **每个 agent 是自己经验的最佳蒸馏者**——经验 per-agent，精益求精
+
+## 3. 核心设计决策
+
+| # | 决策 | 理由 | 参考 |
+|---|------|------|------|
+| D1 | 统一产物：Skill-only | 不再有中间形态散落各处。Hermes 只有 Skill + Memory 两种载体，没有第三种 | Hermes skill_manage + memory_tool |
+| D2 | 生命周期通过 skill_workshop 管理 | OpenClaw 已有 pending → applied → rejected → quarantined 生命周期 | OpenClaw skill_workshop 工具 |
+| D3 | 蒸馏频率：双层 daily | L1 各 agent 每天 03:00 自蒸馏；L2 庞统每天 05:00 整合。有距离感的蒸馏优于即时记录 | self-improvement skill daily review；主公确认 |
+| D4 | 蒸馏者：双层（各 agent + 庞统） | L1 每个 agent 蒸馏自己的经验（自己最准）；L2 庞统负责跨 agent 共性识别 + draft 审查 | Hermes skill_manage：「每个将军都应建立自己的 Skill 库」 |
+| D5 | 二级蒸馏抽象为根因模式 | 不固化在特定技术细节。description 描述「问题模式」而非「技术症状」 | Superpowers writing-skills：description = when not how |
+| D6 | 废弃 .learnings/ 作为数据源 | JSONL 已包含完整信息（工具调用、推理过程、错误输出）。.learnings/ 只是重复抄写，且打断 agent 执行流 | DISCOVER 统一采集；主公确认 |
+| D7 | 只创建一个 skill：skill-management | 四阶段的详细操作放到 references/ 目录。DISCOVER/IMPROVE 是 cron 场景不需要独立 skill description 常驻上下文 | moziplus skill-engineering practices §4：组合模式 |
+
+## 4. L4 知识层：Skill Workshop
+
+在现有 L0-L3 四层知识体系上新增 L4：
+
+| 层级 | 名称 | 内容 | 加载方式 | 已有 |
+|------|------|------|---------|------|
+| L0 | 注入式上下文 | MEMORY.md / TOOLS.md | 每次 session 启动 | ✅ |
+| L1 | 确定性规则 | SOUL.md / AGENTS.md | 每次 session 启动 | ✅ |
+| L2 | 任务上下文 | BootstrapBuilder PromptSection | 按 task_type 注入 | ✅ |
+| L3 | 按需 Skill | openclaw skills | description 匹配 → agent read | ✅ |
+| **L4** | **Skill 生命周期** | **skill_workshop** | **draft → active → deprecated 管理** | **新增** |
+
+L4 不是一个 prompt 层，而是 Skill 的**管理层**——负责 Skill 的创建、验证、应用、追踪、淘汰。
+
+## 5. DISCOVER 阶段（双层）
+
+### 5.1 L1 各 agent 自蒸馏（每天 03:00）
+
+每个 agent 的 cron 扫描**自己当天**的 session JSONL，识别信号，蒸馏为 draft proposal。
+
+**数据源（1 个）**：
+
+| 数据源 | 位置 | 包含什么 |
+|--------|------|---------|
+| 自己的 Session JSONL | ~/.openclaw/agents/<agent_id>/sessions/*.jsonl | 当天完整思考过程、工具调用、错误恢复、用户对话 |
+
+**不需要**扫描黑板/Gitea/Mail 等——那是 L2 庞统的职责。L1 聚焦自己的经验。
+
+**信号识别（5 类高价值信号）**：
+
+| 信号类型 | 从哪发现 | 识别特征 |
+|---------|---------|---------|
+| 失败模式 | task failed、CI failed、review rejected | 有明确的失败原因 |
+| 重复问题 | 跨多个任务出现同类问题 | 同关键词出现 ≥2 次 |
+| 决策转折 | rebuttal comment、需求澄清、主公纠正 | 原方向被推翻或修正 |
+| 新实践 | 设计文档新增、wiki-vault 新页面 | 之前没有的知识 |
+| 知识缺口 | agent 表达不确定、查不到的东西 | 查不到/不确定的东西 |
+
+**输出**：draft skill proposal（提交到 skill_workshop，pending 状态）
+
+### 5.2 L2 庞统整合（每天 05:00）
+
+庞统的 cron 在 L1 全部完成后执行，扫描全量数据源 + 审查所有 L1 draft proposal。
+
+**数据源（全量）**：
+
+| 数据源 | 位置 | 包含什么 |
+|--------|------|---------|
+| 黑板 tasks | 各项目 blackboard.db | 任务生命周期：创建、分配、执行、完成/失败 |
+| 黑板 reviews | reviews 表 | 审查结论 + 逐步骤 verdict + suggestions |
+| 黑板 comments | comments 表 | @mention 讨论、rebuttal 推理、action_report |
+| 黑板 outputs | outputs 表 | 任务产出物内容 |
+| 黑板 events | events 表 | 状态变更、guardrail 拦截、异常检测 |
+| Gitea Issues/PRs | Gitea API | 问题报告、diff、review 评论 |
+| Gitea CI | Gitea Actions | lint/test/build 成功/失败 |
+| Mail | mail API | 跨 agent 通信、讨论推理过程 |
+| **所有 agent 的 Session JSONL** | ~/.openclaw/agents/*/sessions/ | 全团队完整思考过程 |
+| MEMORY.md | 各 agent workspace | 长期记忆、已有经验教训 |
+| knowledge-gaps.md | wiki-vault/_meta/ | 知识缺口 |
+| **L1 draft proposals** | skill_workshop pending | 各 agent 当天提交的 draft |
+
+**核心职责**：
+
+a. **跨 agent 共性模式识别**：张飞和关羽都在类似场景踩坑 → 合并为共享 Skill
+b. **审查 L1 draft proposals**：
+   - APPROVE：质量达标的个人经验 → 变 active（仅作者 agent 可见）
+   - MERGE：跨 agent 共性 → 合并为共享 Skill（所有 agent 可见）
+   - REJECT：质量不够（附原因，agent 看到反馈后改进）
+c. **全局提升**：高确定性/高频率经验 → 提升到 AGENTS.md 规则（所有 agent 强制注入）
+
+### 5.3 去重
+
+同一事件在多个数据源出现（CI 失败 → toolchain task → mail → comment 讨论），按时间窗口 + 关键词去重，保留信息量最大的那条。
+
+跨 agent 的同一模式，按 Pattern-Key 去重，合并为共享信号。
+
+### 5.4 输出格式（融合 self-improvement skill 结构化字段）
+
+每条候选信号包含：
+```
+信号类型 | 来源（task_id / PR / review / session）| 时间 | 简述（≤100 字）
+ID: SIG-YYYYMMDD-XXX
+Priority: low | medium | high | critical
+Status: pending | in_progress | resolved | promoted
+See Also: SIG-YYYYMMDD-XXX（关联信号）
+Recurrence-Count: N（同一模式出现次数）
+Pattern-Key: category.subcategory（稳定去重键，如 sync.field_mapping）
+```
+
+**字段说明**（汲取自 self-improvement skill）：
+
+| 字段 | 用途 | 借鉴来源 |
+|------|------|---------|
+| ID | 唯一标识，便于交叉引用 | self-improvement logging format |
+| Priority | 优先级排序，critical/high 优先处理 | self-improvement priority guidelines |
+| Status | 生命周期跟踪 | self-improvement status lifecycle |
+| See Also | 关联相似信号，发现共性模式 | self-improvement recurring pattern detection |
+| Recurrence-Count | 同一模式出现次数，≥3 触发自动提升 | self-improvement recurring pattern + Skill Extraction Criteria |
+| Pattern-Key | 稳定去重键，跨 agent 匹配同一模式 | self-improvement Pattern-Key |
+
+## 6. DISTILL 阶段
+
+### 6.1 核心原则：HOW not WHAT
+
+蒸馏的是「怎么做」不是「发生了什么」（nuwa-skill 实践 #5）：
+
+```
+❌ "PR #83 修复了 event_type 未知的问题"
+    → 这是 WHAT，无法复用
+
+✅ "数据消费者与数据生产者解耦时，新增字段必须同步所有生产者的提取逻辑"
+    → 这是 HOW，可复用到任何消费者/生产者场景
+```
+
+### 6.2 蒸馏产物 = Skill
+
+直接产出 SKILL.md 格式或对现有 Skill 的 patch，提交到 skill_workshop。
+
+**SKILL.md 编写规范**（参考 Superpowers writing-skills）：
+
+```yaml
+---
+name: skill-name
+description: Use when [触发条件/问题模式描述]，不描述工作流
+---
+
+# Skill 标题
+
+## 什么时候用
+（具体的触发场景，按问题模式描述，不按技术特定症状）
+
+## 怎么做
+（根因分析 + 操作步骤）
+
+## 常见错误
+（反模式：什么不该做）
+
+## 来源
+（evidence：哪些 task/PR/review 提炼了这条经验）
+```
+
+**description 关键规则**（Superpowers 的核心发现）：
+- 只描述触发条件（when to use），**绝不描述工作流**（how）
+- 以「Use when...」开头
+- 描述问题模式，不描述技术特定症状
+- 原因：测试发现 description 如果总结了工作流，agent 会按 description 执行而跳过读完整 SKILL.md
+
+### 6.3 蒸馏示例
+
+**一级蒸馏**（从具体案例提取）：
+
+```yaml
+# 案例 1：PromptContext event_type 未知
+# 案例 2：PromptContext from_agent/mail_type 缺失（PR #26 D2）
+→ 共同根因：消费者/生产者字段同步问题
+
+# 蒸馏为 Skill section（加到 trial-and-error-patterns）：
+## 消费者/生产者字段同步
+
+**什么时候用**：修改 dataclass 时，如果该 dataclass 由外部 JSON 提取填充
+
+**怎么做**：
+1. 改 dataclass 定义
+2. 检查所有从 JSON 提取字段的代码路径，同步新增提取逻辑
+3. 检查所有构造该 dataclass 的调用点，同步新增参数
+4. 跑一次构建测试验证字段不为空
+
+**常见错误**：只改 dataclass 不改提取逻辑 → 字段默认值为空 → 运行时不报错但行为异常
+```
+
+**二级蒸馏**（从多个一级经验提取通用模式）：
+
+如果「消费者/生产者字段同步」经验在 ≥2 个不同场景复现（PromptContext + 其他），验证通过后，可以提升为独立 Skill 或固化到 AGENTS.md 规则。
+
+### 6.4 验证机制（融合 self-improvement Recurrence-Count + Skill Extraction Criteria）
+
+从 draft → active 的验证标准：
+
+| 验证维度 | 标准 | 不通过的处理 |
+|---------|------|------------|
+| Recurrence-Count ≥ 2 | 同一 Pattern-Key 在 ≥2 个不同场景出现过 | 降级为 MEMORY.md 临时记录 |
+| 有生成力 | 能给出具体的操作指引 | 丢弃 |
+| 有排他性 | 不是「代码要测试」的常识 | 丢弃 |
+
+**提升触发条件**（从 draft 提升为 active Skill，融合 self-improvement Skill Extraction Criteria）：
+
+全部满足时触发提升：
+- Recurrence-Count ≥ 3（同一模式 30 天内出现 3 次以上）
+- 跨 ≥2 个不同任务验证
+
+**时间窗口**：Recurrence-Count 以 30 天为窗口，超过 30 天的记录不计入。6 个月内 3 次 vs 1 周内 3 次信号强度不同，30 天窗口确保经验仍然新鲜。
+
+**Skill Extraction 质量 Gate**（汲取自 self-improvement skill）：
+
+| 标准 | 描述 |
+|------|------|
+| Recurring | 有 See Also 链接到 2+ 个相似信号 |
+| Verified | Status 是 resolved 且有工作修复 |
+| Non-obvious | 需要实际调试才能发现（不是常识） |
+| Broadly applicable | 不是项目特定，可跨场景复用 |
+
+### 6.5 质量检查自动化
+
+参考 nuwa-skill quality_check.py，对蒸馏产出做结构化检查：
+
+| 检查项 | 标准 |
+|--------|------|
+| trigger 是否具体 | 不是「注意代码质量」这种泛泛而谈 |
+| action 是否可执行 | 不是「要小心」这种无操作指引 |
+| 是否与已有 Skill 重复 | 检查现有 skills 目录中是否已有覆盖 |
+| description 是否只含触发条件 | 不包含工作流描述 |
+
+### 6.6 矛盾处理（nuwa-skill 实践 #10）
+
+新经验与已有经验冲突时：
+- **时间性矛盾**（观点演化）→ 记录演化轨迹，以近期为主
+- **领域性矛盾**（不同场景不同规则）→ 分场景记录
+- **本质性张力**（价值观内在冲突）→ 标注为「核心张力」，两个版本都保留
+
+**矛盾是特征，不是 Bug。** 强制调和会丢失关键信号。
+
+### 6.7 蒸馏者（双层）
+
+**L1：每个 agent 自己（每天 03:00 cron，各 agent 错开 15 分钟避免资源争用：03:00, 03:15, 03:30, ...）**
+1. 扫描自己的 session JSONL
+2. 用判断力提取根因模式（不是机械提取）
+3. 按 SKILL.md 格式产出
+4. 提交到 skill_workshop（pending proposal）
+
+**L2：庞统（每天 05:00 cron）**
+1. 审查所有 agent 提交的 draft proposal（approve / merge / reject）
+2. 跨 agent 共性模式识别和合并
+3. 高频/高确定性经验提升到 AGENTS.md 规则
+
+未来考虑半自动化（LLM 辅助草案 + agent 审阅确认）。
+
+## 7. APPLY 阶段
+
+### 7.1 统一走 openclaw skill 机制
+
+**不新建 ExperienceSection 或任何 moziplus 自定义注入**。因为产物统一为 Skill，openclaw 已有的机制天然支持：
+
+1. openclaw 扫描 skills 目录 → 生成 `<available_skills>` 列表
+2. Agent 按 description 匹配 → `read` SKILL.md
+3. Agent 按内容执行
+
+### 7.2 Skill description 编写规范
+
+这是 APPLY 阶段效果好坏的关键。参考 Superpowers writing-skills 的核心发现：
+
+```yaml
+# ❌ BAD：描述了工作流，agent 会按 description 执行而跳过读 SKILL.md
+description: Use when modifying dataclass — checks all extraction points, runs tests, verifies non-null fields
+
+# ✅ GOOD：只描述触发条件
+description: Use when modifying a dataclass that is populated from JSON extraction by another module
+
+# ❌ BAD：太抽象
+description: Use for code quality
+
+# ✅ GOOD：描述问题模式
+description: Use when a field added to a dataclass appears empty or as default value at runtime
+```
+
+### 7.3 渐进式加载
+
+openclaw 已有的机制：
+- L1：`<available_skills>` 列表（~100 token/skill，只有 name + description）
+- L2：Agent `read` SKILL.md（完整内容）
+- L3：SKILL.md 内引用的 references/ 文件（按需加载）
+
+### 7.4 Skill 存放位置与可见性
+
+agent 专属经验放到 agent 自己的 workspace skills 目录，全局共享 Skill 放到公共 skills 目录。openclaw 扫描时自动合并。
+
+| Skill 位置 | 谁能看到 | 适用场景 |
+|-----------|---------|---------|
+| `~/.openclaw/workspace-zhangfei/skills/` | 只有张飞 | 编码模式、个人踩坑经验 |
+| `~/.openclaw/workspace-pangtong/skills/` | 只有庞统 | 规划经验、方向把控 |
+| `~/.openclaw/workspace-simayi/skills/` | 只有司马懿 | 审查技巧、挑战模式 |
+| `~/.sanguo_projects/sanguo_mozi/skills/` | 所有 moziplus agent | 团队共识、协作规范、通用实践 |
+
+**设计原则**：
+- 个人经验不污染其他 agent 上下文（张飞的编码坑不需要司马懿看到）
+- 共性经验自动共享（庞统 MERGE 后放到公共目录）
+- openclaw 原生机制天然支持（扫描时合并所有 skills 目录）
+
+## 8. IMPROVE 阶段
+
+### 8.1 Skill 自我修补
+
+参考 Hermes skill_manage 的设计哲学：
+
+> "If you used a skill and hit issues not covered by it, patch it immediately."
+> "Skills that aren't maintained become liabilities."
+
+Agent 使用 Skill 时发现问题（缺步骤、过时信息、命令变更）→ 立即通过 skill_workshop 提交 revise proposal（patch）。
+
+这不需要定时任务，靠 agent 的主动维护。关键是在 agent 的 prompt 中注入这条规则（SOUL.md 或 AGENTS.md）。
+
+### 8.2 引用追踪
+
+**设计原则**：不追求精确归因，做时间维度的信号采集。
+
+| 信号 | 采集方式 | 可信度 |
+|------|---------|--------|
+| Skill 最近被 read 的时间 | 扫描 session JSONL 中 `"tool":"read"` + SKILL.md 路径 | 中 |
+| Skill 在 available_skills 中被注入 | 扫描 JSONL 中 available_skills 列表 | 中（被注入但未必被用） |
+| Agent 在输出中提及了 skill name | grep skill name in assistant messages | 高（主动提到说明确实用了） |
+| Skill 文件最近修改时间 | git log / 文件 mtime | 高 |
+
+**采集频率**：每周一次 cron，扫描过去 7 天的所有 session JSONL。
+
+### 8.3 淘汰机制
+
+**决策流程**：
+
+```
+30 天无引用信号
+  → 生成淘汰候选报告（庞统审阅）
+    → 确认淘汰 → skill_workshop quarantine
+    → 保留观察 → 标注，下轮再查
+    → 更新后保留 → 修改 description / 内容，重置计时
+```
+
+**注意**：openclaw 本身的 skill（~/.openclaw/plugin-skills/ 和全局 skills）也纳入追踪范围。主公可以据此决定哪些 openclaw skill 可以禁用。
+
+### 8.4 经验提升路径
+
+同一 Skill section 被频繁引用（≥5 次）且经过多次验证 → 考虑提升：
+
+| 提升目标 | 条件 | 效果 |
+|---------|------|------|
+| 独立 Skill | 足够通用，有自己的触发条件 | 独立 SKILL.md，description 匹配 |
+| AGENTS.md 规则 | 确定性高，适用于所有 agent | L1 确定性注入，强制生效 |
+| guardrail | 安全相关，不可违反 | 强制检查 |
+
+### 8.5 反馈到 DISCOVER
+
+IMPROVE 发现的经验缺口（「这条 Skill 不适用 XXX 场景」）→ 写入 knowledge-gaps.md → 成为下一轮 DISCOVER L2 的输入。
+
+## 9. 闭环全景
+
+```
+DISCOVER L1（每天 03:00，各 agent cron）
+  数据源：自己的 session JSONL
+  信号识别：5 类高价值信号
+  输出：draft skill proposal（structured，带 ID/Priority/Pattern-Key/Recurrence-Count）
+  ↓
+DISCOVER L2（每天 05:00，庞统 cron）
+  数据源：全量 12 个数据源（含 L1 draft proposals）
+  跨 agent 共性模式识别
+  审查 draft proposals：approve / merge / reject
+  ↓
+DISTILL（L2 庞统执行）
+  原则：HOW not WHAT（根因模式，不固化技术细节）
+  验证：Recurrence-Count ≥ 2 + 生成力 + 排他性
+  提升：Recurrence-Count ≥ 3 → 独立 Skill / AGENTS.md 规则
+  质量：自动化检查 + 矛盾保留
+  产物：Skill（通过 skill_workshop 管理）
+  ↓
+APPLY（实时，openclaw skill 机制）
+  匹配：description 匹配 → agent read SKILL.md
+  执行：agent 按内容执行
+  自我修补：使用时发现问题 → 立即 revise proposal
+  per-agent 隔离：专属 Skill 在 agent workspace，共享 Skill 在公共目录
+  ↓
+IMPROVE（每周 cron，庞统执行）
+  追踪：scan JSONL 引用信号
+  淘汰：30天无引用 → 庞统审查 → quarantine
+  提升：高频引用 → 独立 Skill / AGENTS.md 规则 / guardrail
+  反馈：知识缺口 → knowledge-gaps.md → 回到 DISCOVER L2
+```
+
+## 10. 与现有实现的关系
+
+| 组件 | 处理方式 |
+|------|---------|
+| `skill_system.py`（SkillRegistry/SkillExecutor） | **标记 deprecated，后续清理。** 死代码，实际不参与 skill 发现/加载 |
+| `experience.py`（ExperienceDistiller/ExperienceStore） | **标记 deprecated，后续清理。** 空转代码，experiences 目录全空 |
+| `experiences` 表 / `experience_tags` 表（db.py） | **保留表结构但不再写入。** 未来如果需要 DB 查询可以重新启用 |
+| ticker.py:336-348 经验蒸馏逻辑 | **移除。** 不再逐任务蒸馏，改为双层 daily cron |
+| `skill_workshop` 工具 | **核心使用。** 所有 Skill 生命周期通过它管理 |
+| openclaw `<available_skills>` 机制 | **核心依赖。** APPLY 阶段完全基于此 |
+| **self-improvement skill**（`~/.openclaw/workspace/skills/self-improving-agent/`） | **废弃。** 其优势（结构化 ID/Status/Priority/See Also/Recurrence-Count）已融合到 DISCOVER 输出格式中。原 skill 文件保留但标记 deprecated |
+| **.learnings/ 目录**（各 agent workspace） | **废弃。** JSONL 是唯一数据源。目录保留但不再写入新内容（历史数据保留） |
+| **SELF_IMPROVEMENT_REMINDER.md** | **废弃。** 规则已融合到 skill-management skill 中 |
+
+## 11. 实现计划
+
+| 步骤 | 内容 | 优先级 | 工作量 |
+|------|------|--------|--------|
+| S1 | 在 SOUL.md / AGENTS.md 加入 Skill 自我修补规则 + 双层 daily 蒸馏规则 | P0 | L1（改文案） |
+| S2 | 创建 skill-management Skill（主 SKILL.md + references/ 四阶段详细操作） | P0 | L2 |
+| S3 | 创建各 agent 的 03:00 cron（自蒸馏 L1） | P1 | L1 |
+| S4 | 创建庞统的 05:00 cron（整合 + 审查 L2） | P1 | L1-L2 |
+| S5 | 实现 IMPROVE cron：JSONL 引用追踪 + 淘汰报告（每周） | P2 | L2-L3 |
+| S6 | 清理 deprecated 代码（skill_system.py / experience.py / self-improvement skill / SELF_IMPROVEMENT_REMINDER.md） | P3 | L1 |
+
+S1 和 S2 已完成（PR #85）。S3-S5 设计见下方 §11A。
+
+## 11A. Cron 配置方案（S3-S5 详细设计）
+
+### 设计决策
+
+**每个 agent 用自己的 agentId 执行 L1 cron**，不由庞统代理。
+
+理由（对照设计目标 D4）:
+- L1 核心价值是"每个 agent 是自己经验的最佳蒸馏者"——agent 扫描自己的 JSONL，用自己的判断力识别信号
+- 如果庞统代理，变成庞统替别人蒸馏，消除不了蒸馏者偏差（D4 要解决的正是这个问题）
+- openclaw cron 原生支持 `agentId` 参数 + `sessionTarget: "isolated"`，技术上无障碍
+
+### S3: L1 各 agent 自蒸馏 cron
+
+6 个 agent，各创建一个 isolated cron，错开 15 分钟（和 discover-l1.md 时间表一致）：
+
+| Agent | agentId | cron 表达式 | 时区 |
+|-------|---------|-----------|------|
+| 张飞 | zhangfei-dev | `0 3 * * *` | Asia/Shanghai |
+| 关羽 | guanyu-dev | `15 3 * * *` | Asia/Shanghai |
+| 赵云 | zhaoyun-data | `30 3 * * *` | Asia/Shanghai |
+| 司马懿 | simayi-challenger | `45 3 * * *` | Asia/Shanghai |
+| 庞统 | pangtong-fujunshi | `0 4 * * *` | Asia/Shanghai |
+| 姜维 | jiangwei-infra | `15 4 * * *` | Asia/Shanghai |
+
+**Cron 配置规范**（每个 L1 cron job）：
+
+```json
+{
+  "schedule": { "kind": "cron", "expr": "<时间>", "tz": "Asia/Shanghai" },
+  "sessionTarget": "isolated",
+  "agentId": "<agent-id>",
+  "payload": {
+    "kind": "agentTurn",
+    "message": "L1 自蒸馏 cron。请执行：\n1. read ~/.sanguo_projects/sanguo_mozi/skills/skill-management/SKILL.md\n2. read ~/.sanguo_projects/sanguo_mozi/skills/skill-management/references/discover-l1.md\n3. 按 discover-l1.md 步骤执行自蒸馏\n4. 如有信号：蒸馏为 HOW 格式，使用 skill_workshop(action=create) 提交 draft proposal\n5. 如无有价值信号：不产出，这是正常的",
+    "timeoutSeconds": 600
+  },
+  "delivery": { "mode": "announce" }
+}
+```
+
+**设计要点**:
+- `sessionTarget: "isolated"`：每次创建临时 session，不污染 main session context
+- `delivery.mode: "announce"`：执行结果投递到 Control UI，保持可见性（早期使用 `none` 导致 cron 执行后零可见性，已修正）
+- `timeoutSeconds: 600`：10 分钟足够（扫描 JSONL + 蒸馏 + 提交 proposal）
+- message 指引 read SKILL.md + discover-l1.md：agent 按 references 指南执行，不依赖 memory
+
+### S4: L2 庞统整合审查 cron
+
+庞统的 L2 cron 在所有 L1 完成后执行（最后一个 agent 04:15 开始，L2 设在 05:00）：
+
+| 角色 | agentId | cron 表达式 | 时区 |
+|------|---------|-----------|------|
+| 庞统 | pangtong-fujunshi | `0 5 * * *` | Asia/Shanghai |
+
+**Cron 配置**:
+
+```json
+{
+  "schedule": { "kind": "cron", "expr": "0 5 * * *", "tz": "Asia/Shanghai" },
+  "sessionTarget": "isolated",
+  "agentId": "pangtong-fujunshi",
+  "payload": {
+    "kind": "agentTurn",
+    "message": "L2 整合审查 cron。请执行：\n1. read ~/.sanguo_projects/sanguo_mozi/skills/skill-management/references/discover-l2.md\n2. 按 discover-l2.md 步骤执行：\n   a. skill_workshop(action=list, status=pending) 获取所有 L1 draft proposals\n   b. 全量数据源扫描，识别跨 agent 共性模式\n   c. 逐个审查 proposal：approve / merge / reject\n   d. 全局提升检查（Recurrence-Count >= 3 的经验提升为规则）\n   e. 知识缺口反馈到 knowledge-gaps.md",
+    "timeoutSeconds": 1200
+  },
+  "delivery": { "mode": "announce" }
+}
+```
+
+**设计要点**:
+- `delivery.mode: "announce"`：审查决策结果投递到 Control UI，主公可见
+- `timeoutSeconds: 1200`（20 分钟）：L2 需要扫描全量数据源 + 审查多个 proposal，时间更长
+- 庞统可以访问所有 agent 的 JSONL 和 skill_workshop proposals
+
+### S5: IMPROVE 每周引用追踪 cron
+
+庞统每周日 06:00 执行引用追踪（周日选活动量最低的时段）：
+
+| 角色 | agentId | cron 表达式 | 时区 |
+|------|---------|-----------|------|
+| 庞统 | pangtong-fujunshi | `0 6 * * 0` | Asia/Shanghai |
+
+**Cron 配置**:
+
+```json
+{
+  "schedule": { "kind": "cron", "expr": "0 6 * * 0", "tz": "Asia/Shanghai" },
+  "sessionTarget": "isolated",
+  "agentId": "pangtong-fujunshi",
+  "payload": {
+    "kind": "agentTurn",
+    "message": "IMPROVE 每周引用追踪 cron。请执行：\n1. read ~/.sanguo_projects/sanguo_mozi/skills/skill-management/references/improve.md\n2. 按 improve.md 步骤执行：\n   a. 扫描过去 7 天所有 agent 的 session JSONL，采集 Skill 引用信号\n   b. 生成淘汰候选报告（30 天无引用的 Skill）\n   c. 庞统审阅决策：quarantine / 保留观察 / 更新后保留\n   d. 经验提升检查（被频繁引用 >= 5 次的 Skill）\n   e. 反馈知识缺口到 knowledge-gaps.md",
+    "timeoutSeconds": 1800
+  },
+  "delivery": { "mode": "announce" }
+}
+```
+
+**设计要点**:
+- `delivery.mode: "announce"`：淘汰/提升报告投递到 Control UI
+- `timeoutSeconds: 1800`（30 分钟）：全量 JSONL 扫描是最重的操作
+- 每周一次频率足够——Skill 引用变化不会很快
+- 淘汰决策通过 skill_workshop quarantine 执行，提升决策通过手动编辑 AGENTS.md
+
+### Cron 创建方式
+
+使用 openclaw cron 工具创建。**不是 moziplus 管理**，而是直接在 openclaw 层面配置。
+
+创建顺序：先 S3（L1），再 S4（L2），最后 S5（IMPROVE）。
+
+创建后验证：`cron(action=list)` 确认所有 job 存在且 enabled=true。
+
+### 去重和幂等
+
+每个 cron job 的 name 包含 agent 名，避免命名冲突：
+- `l1-distill-zhangfei`
+- `l1-distill-guanyu`
+- `l1-distill-zhaoyun`
+- `l1-distill-simayi`
+- `l1-distill-pangtong`
+- `l1-distill-jiangwei`
+- `l2-review-pangtong`
+- `improve-weekly-pangtong`
+
+创建前先 `cron(action=list)` 检查同名 job 是否已存在，避免重复创建。
+
+## 11B. 一致性偏差修复清单（S6 补充）
+
+§19 设计-实现一致性检查（2026-06-18）发现以下偏差，列入 S6 一并修复：
+
+| # | 偏差 | 严重度 | 修复方式 |
+|---|------|--------|--------|
+| B4 | ticker.py:336-348 ExperienceDistiller 调用未移除 | 中 | 移除 experience_distiller 参数和调用，日志改为 debug 级空转提示 |
+| B5 | skill_system.py / experience.py 未标记 deprecated | 低 | 文件头部加 `# DEPRECATED — §19 重设计，不再参与 skill 发现/加载` 注释 |
+| B6 | SELF_IMPROVEMENT_REMINDER.md 引用残留 | 低 | AGENTS.md 中已标注废弃，但 system prompt 仍注入。从 workspace 文件列表中移除该文件 |
+
+**B4 修复细节**：
+
+ticker.py 构造函数 `__init__` 接受 `experience_distiller` 参数（默认 None），tick() 中第 336-348 行有条件调用。修复方式：
+- 保留参数（向后兼容），但条件块内加 `logger.debug("ExperienceDistiller deprecated per §19, skipping")` 后直接 return
+- 不删除代码（P3 级清理时再做物理删除）
+
+**B6 修复细节**：
+
+当前 Project Context 中注入了 `SELF_IMPROVEMENT_REMINDER.md` 的内容。该文件在 workspace-pangtong 中已不存在（被删），但 system prompt 模板仍引用它。修复方式：确认文件不存在即可——openclaw 会跳过不存在的注入文件。实际已无影响，标注为 resolved。
+
+## 12. wiki-vault / 知识库参考实践映射
+
+| 设计决策 | 参考来源 | 核心借鉴 |
+|---------|---------|---------|
+| 统一产物 Skill-only | Hermes skill_manage + memory_tool | 只有 Skill 和 Memory 两种载体 |
+| HOW not WHAT | nuwa-skill 实践 #5 | 蒸馏思维方式不是知识内容 |
+| description = when not how | Superpowers writing-skills | description 只描述触发条件 |
+| 质量检查自动化 | nuwa-skill quality_check.py | 结构化检查代替主观判断 |
+| 矛盾处理 | nuwa-skill 实践 #10 | 矛盾是特征不是 Bug |
+| Skill 自我修补 | Hermes skill_manage schema | 使用时发现问题立即 patch |
+| 闭环学习循环 | 知识管理体系实践 #1 | DISCOVER→DISTILL→APPLY→IMPROVE |
+| Experience→Skill 延迟转化 | moziplus 经验实践 #2 | 多次验证后才固化 |
+| Skill 生命周期 draft→active→deprecated | OpenClaw skill_workshop | pending→applied→rejected→quarantined |
+| 棘轮机制 | moziplus 经验实践 #2 | 经验只能改进不能退化 |
+| 优雅降级 | nuwa-skill 实践 #17 | 信息不足时不要强行蒸馏 |
+| 迭代上限 | nuwa-skill 实践 #18 | 最多 2 轮验证，不无限打磨 |
+| **双层 daily 蒸馏** | self-improvement skill daily review | 有距离感的蒸馏优于即时记录 |
+| **结构化信号格式** | self-improvement skill logging format | ID/Status/Priority/See Also/Recurrence-Count |
+| **Recurrence-Count 验证** | self-improvement skill recurring pattern detection | ≥3 次自动触发提升，比主观判断更客观 |
+| **Skill Extraction Criteria** | self-improvement skill extraction | Recurring + Verified + Non-obvious + Broadly applicable |
+| **per-agent Skill 目录** | Hermes skill_manage + self-improving-agent practice §5 | 每个 agent 建立自己的 Skill 库 |
+| **废弃 .learnings/** | DISCOVER 统一采集 | JSONL 是唯一数据源，避免信息冗余 |
+| **组合模式（主 skill + references）** | moziplus skill-engineering practices §4 | Skill 之间通过产出物松耦合传递 |
+
+## 13. 部署目录结构
+
+### 13.1 openclaw skill 加载优先级
+
+OpenClaw 按 6 级优先级扫描 skill 目录，同名 skill 高优先级覆盖低优先级：
+
+| 优先级 | 来源 | 路径 | 可见性 |
+|--------|------|------|--------|
+| 1 — 最高 | Workspace skills | `<workspace>/skills` | 只对该 agent |
+| 2 | Project agent skills | `<workspace>/.agents/skills` | 只对该 workspace 的 agent |
+| 3 | Personal agent skills | `~/.agents/skills` | 所有 agent |
+| 4 | Managed / local skills | `~/.openclaw/skills` | 所有 agent |
+| 5 | Bundled skills | 随安装包（`/opt/homebrew/.../openclaw/skills/`） | 所有 agent |
+| 6 — 最低 | Extra dirs + plugin skills | `skills.load.extraDirs` + `~/.openclaw/plugin-skills/` | 所有 agent |
+
+### 13.2 skill-management Skill 目录结构
+
+放在公共目录（`~/.sanguo_projects/sanguo_mozi/skills/`），所有 moziplus agent 可见：
+
+```
+~/.sanguo_projects/sanguo_mozi/skills/skill-management/
+├── SKILL.md                    # 主 Skill：综述 + 核心原则 + 各阶段职责摘要
+├── references/
+│   ├── discover-l1.md          # L1 各 agent 自蒸馏详细操作（03:00 cron 读这个）
+│   ├── discover-l2.md          # L2 庞统整合详细操作（05:00 cron 读这个）
+│   ├── distill.md              # DISTILL 阶段详细操作（蒸馏规范 + 验证标准）
+│   ├── apply.md                # APPLY 阶段说明（openclaw 原生机制，简短）
+│   └── improve.md              # IMPROVE 阶段详细操作（引用追踪 + 淘汰 + 提升）
+└── assets/
+    ├── templates/
+    │   ├── skill-template.md   # SKILL.md 标准模板
+    │   └── signal-format.md    # 信号输出格式模板（ID/Priority/Pattern-Key）
+    └── checklists/
+        └── quality-check.md    # 质量检查清单
+```
+
+**为什么放公共目录**：所有 agent 都需要触发这个 skill（DISCOVER L1 时各 agent 按 description 匹配 → read SKILL.md → 再按需 read references/）。DISCOVER/IMPROVE 是 cron 场景，cron payload 中直接指定 `read references/xxx.md` 按内容执行。
+
+**为什么不拆分为独立 skill**：5 个 skill = 5 条 description 常驻上下文（~500-800 token）。其中 DISCOVER 和 IMPROVE 是 cron 触发不是 agent 按描述触发，不需要常驻 description。用 references/ 按需加载更省上下文。
+
+### 13.3 Cron 产出流转路径
+
+```
+L1 产出（各 agent 03:00）
+  ↓ skill_workshop create（pending proposal）
+  ↓ 存储：skill_workshop 内部管理（~/.openclaw/workspace-<agent>/.skill-workshop/）
+  ↓
+L2 审查（庞统 05:00）
+  ↓ skill_workshop list → inspect → 决策
+  ↓
+  ├─ APPROVE（个人经验，质量达标）
+  │   → skill_workshop apply
+  │   → 写入：~/.openclaw/workspace-<agent>/skills/<skill-name>/SKILL.md
+  │   → 仅该 agent 可见（workspace skill，优先级 1）
+  │
+  ├─ MERGE（跨 agent 共性）
+  │   → 合并多个 proposal 为共享 Skill
+  │   → skill_workshop apply 到庞统 workspace，然后 cp/symlink 到公共目录
+  │   → 写入：~/.sanguo_projects/sanguo_mozi/skills/<skill-name>/SKILL.md
+  │   → 所有 agent 可见（extra dir，优先级 6）
+  │   → 清理：MERGE 后通知各 agent quarantine workspace 中的同名 draft
+  │
+  │   ⚠️ skill_workshop 只能写 workspace skills，不能写 extraDir。
+  │   MERGE 流程的实际写入方式：庞统在 workspace apply 后，
+  │   手动 cp 到公共目录（或配置 skills.load.allowSymlinkTargets 用 symlink）。
+  │
+  ├─ REJECT（质量不够）
+  │   → skill_workshop reject（附原因）
+  │   → agent 在下次 L1 蒸馏时看到反馈
+  │
+  └─ PROMOTE（高确定性，提升为确定性规则）
+      → 手动写入 AGENTS.md / SOUL.md / TOOLS.md
+      → 所有 agent 强制注入（L1 确定性规则层）
+```
+
+**关键设计**：APPROVE 写入 per-agent workspace（优先级 1，最高），MERGE 写入公共目录（优先级 6，最低）。如果同名 skill 在两边都有，workspace 版本覆盖公共版本——agent 可以有自己改进过的版本。
+
+### 13.4 Per-agent Skill 目录
+
+各 agent workspace 下的 skills 目录（目前不存在，L2 审查 APPROVE 后由 skill_workshop 自动创建）：
+
+```
+~/.openclaw/workspace-zhangfei/skills/    # 张飞的个人经验 Skill
+~/.openclaw/workspace-guanyu/skills/       # 关羽的个人经验 Skill
+~/.openclaw/workspace-zhaoyun/skills/      # 赵云的个人经验 Skill
+~/.openclaw/workspace-simayi/skills/       # 司马懿的个人经验 Skill
+~/.openclaw/workspace-pangtong/skills/     # 庞统的个人经验 Skill
+~/.openclaw/workspace-jiangwei/skills/     # 姜维的个人经验 Skill
+```
+
+**适用场景**：
+- 张飞的编码踩坑模式 → 只有张飞需要，不污染其他 agent 上下文
+- 司马懿的审查技巧 → 只有司马懿需要
+- 庞统的规划经验 → 只有庞统需要
+
+### 13.5 Proposal 中间产物存储
+
+```
+~/.openclaw/workspace-<agent>/.skill-workshop/
+├── proposals/
+│   ├── <proposal-id>/
+│   │   ├── PROPOSAL.md          # 草案内容
+│   │   ├── metadata.json        # 状态、hash、scanner state
+│   │   └── support-files/       # 附带的 references/assets
+│   └── ...
+├── applied/                      # 已 apply 的 proposal 归档
+├── rejected/                     # 已 reject 的 proposal 归档
+└── quarantined/                  # 已 quarantine 的 proposal 归档
+```
+
+**注意**：proposal 存储由 skill_workshop 内部管理，不需要手动操作。首次使用 skill_workshop 时自动创建 `.skill-workshop/` 目录。庞统 L2 cron 通过 `skill_workshop list`（查看所有 agent 的 pending proposal）+ `skill_workshop inspect`（查看具体内容）+ `skill_workshop apply/reject/quarantine`（执行决策）完成审查。
+
+### 13.6 全景目录结构
+
+```
+# ━━━━━━━ Skill 来源（按 openclaw 优先级） ━━━━━━━━
+
+# P1: Per-agent workspace skills（个人经验，L2 APPROVE 后写入）
+~/.openclaw/workspace-<agent>/skills/<skill-name>/SKILL.md
+
+# P4: Managed / local skills（保留，目前为空）
+~/.openclaw/skills/
+
+# P5: Bundled skills（openclaw 自带，不动）
+/opt/homebrew/lib/node_modules/openclaw/skills/
+
+# P6: Extra dirs + plugin skills
+~/.sanguo_projects/sanguo_mozi/skills/          # moziplus 团队共享 Skill
+├── skill-management/                           # ← §19 核心 Skill
+│   ├── SKILL.md
+│   ├── references/{discover-l1, discover-l2, distill, apply, improve}.md
+│   └── assets/{templates, checklists}/
+├── blackboard-executor/                        # 现有
+├── blackboard-reviewer/                        # 现有
+├── trial-and-error-patterns/                   # 现有（经验会追加到这里）
+└── ...（其他现有 skill）
+
+~/.openclaw/plugin-skills/                      # plugin Skill（feishu 等）
+
+# ━━━━━━━ Cron 产出流转 ━━━━━━━━
+
+# L1（03:00 各 agent）
+#   输入：~/.openclaw/agents/<agent_id>/sessions/*.jsonl
+#   产出：skill_workshop create → proposal（pending）
+#   存储：~/.openclaw/workspace-<agent>/.skill-workshop/proposals/
+
+# L2（05:00 庞统）
+#   输入：全量数据源 + 所有 pending proposals
+#   审查：skill_workshop list → inspect → apply/merge/reject
+#   产出：
+#     APPROVE → ~/.openclaw/workspace-<agent>/skills/<skill-name>/（per-agent）
+#     MERGE   → ~/.sanguo_projects/sanguo_mozi/skills/<skill-name>/（共享）
+#     REJECT  → proposal 归档到 rejected/
+#     PROMOTE → 手动写入 AGENTS.md / SOUL.md / TOOLS.md
+
+# IMPROVE（每周 庞统）
+#   输入：过去 7 天所有 agent 的 session JSONL
+#   产出：淘汰候选报告 → skill_workshop quarantine
+
+# ━━━━━━━ 废弃的目录（保留历史，不再写入） ━━━━━━━━
+
+# .learnings/ — 不再写入
+~/.openclaw/workspace-*/.learnings/
+
+# self-improvement skill — 不再激活
+~/.openclaw/workspace/skills/self-improving-agent/
+
+# SELF_IMPROVEMENT_REMINDER.md — 废弃
+# 规则已融合到 skill-management skill 中
+```

skills/skill-management/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: skill-management
+description: "Use when managing skill lifecycle through the DISCOVER-DISTILL-APPLY-IMPROVE loop, when doing daily experience distillation, or when reviewing/auditing skill proposals."
+---
+
+# Skill Management — 经验闭环 + Skill 生命周期
+
+四阶段闭环：DISCOVER → DISTILL → APPLY → IMPROVE。双层 daily 蒸馏架构。
+
+## 什么时候用
+
+- **L1 自蒸馏**（每天 03:00，各 agent）：扫描自己的 session JSONL，蒸馏自己的经验 → 提交 draft proposal
+- **L2 整合审查**（每天 05:00，庞统）：扫描全量数据源 + 审查所有 L1 draft → approve/merge/reject
+- **IMPROVE**（每周，庞统）：追踪 Skill 引用情况，淘汰 30 天无引用的 Skill
+- **自我修补**（实时，任何 agent）：使用 Skill 时发现问题 → 立即 revise proposal
+
+详细操作步骤见 references/ 目录，按当前阶段 `read` 对应文件。
+
+## 核心原则
+
+1. **统一产物 Skill-only**：产物只有 Skill（skill_workshop 管理）和 Memory（MEMORY.md），不再有 .learnings/ 等中间形态
+2. **HOW not WHAT**：蒸馏「怎么做」不是「发生了什么」。描述问题模式，不固化技术细节
+3. **description = when not how**：Skill 的 description 只描述触发条件，不描述工作流
+4. **双层蒸馏**：L1 各 agent 自己蒸馏（自己最准）；L2 庞统负责跨 agent 共性识别 + 审查
+5. **矛盾是特征不是 Bug**：保留矛盾，标注类型（时间性/领域性/本质性），不强制调和
+
+## 四阶段速查
+
+| 阶段 | 谁 | 何时 | 做什么 | 详细文档 |
+|------|---|------|--------|---------|
+| DISCOVER L1 | 每个 agent | 03:00（错开 15min） | 扫描自己 JSONL → 蒸馏 → draft proposal | `references/discover-l1.md` |
+| DISCOVER L2 | 庞统 | 05:00 | 全量扫描 + 审查 draft → approve/merge/reject | `references/discover-l2.md` |
+| DISTILL | L1 各 agent + L2 庞统 | 同 DISCOVER | 提取根因模式，按 SKILL.md 格式产出 | `references/distill.md` |
+| APPLY | openclaw 原生 | 实时 | description 匹配 → read SKILL.md → 执行 | `references/apply.md` |
+| IMPROVE | 庞统 | 每周 | JSONL 引用追踪 + 淘汰 + 提升 | `references/improve.md` |
+
+## 验证标准（Recurrence-Count 机制）
+
+从 draft → active：
+
+| 维度 | 标准 | 不通过 |
+|------|------|--------|
+| Recurrence-Count ≥ 2 | 同一 Pattern-Key 在 ≥2 个场景出现 | 降级为 MEMORY.md |
+| 有生成力 | 能给出具体操作指引 | 丢弃 |
+| 有排他性 | 不是常识 | 丢弃 |
+
+提升触发（全部满足）：30 天内 ≥3 次 + 跨 ≥2 个任务。
+
+## 自我修补规则
+
+使用 Skill 时发现缺步骤、过时信息、命令变更 → **立即** 通过 skill_workshop 提交 revise proposal。不等定时任务，不等到下次 review。
+
+## 常见错误
+
+| 错误 | 后果 | 正确做法 |
+|------|------|---------|
+| 蒸馏 WHAT 不 HOW | 经验无法复用 | 描述根因模式 |
+| description 包含工作流 | Agent 跳过读完整 SKILL.md | description 只描述触发条件 |
+| 缺少 Recurrence-Count | 偶发问题被固化 | 必须 ≥2 次才提升 |
+| 强制调和矛盾 | 丢失关键信号 | 保留矛盾，标注类型 |
+| skill_workshop 写公共目录 | 操作失败 | skill_workshop 只能写 workspace，公共目录用 cp/symlink |
+
+## 来源
+
+- 设计文档：`docs/design/19-skill-lifecycle-and-experience-loop.md` v2.0
+- 参考实践：Hermes skill_manage、nuwa-skill、Superpowers writing-skills、self-improvement skill

skills/skill-management/assets/checklists/quality-check.md

@@ -0,0 +1,36 @@
+---
+name: quality-check
+description: "Skill 蒸馏产出质量检查清单"
+---
+
+# 质量检查清单
+
+蒸馏产出提交前，逐条检查：
+
+## 结构检查
+
+- [ ] frontmatter 有 name 和 description
+- [ ] description 以「Use when...」开头
+- [ ] description 只含触发条件，不含工作流
+- [ ] 有「什么时候用」章节
+- [ ] 有「怎么做」章节
+- [ ] 有「常见错误」章节
+- [ ] 有「来源」章节
+
+## 内容检查
+
+- [ ] trigger 是否具体（不是「注意代码质量」这种泛泛而谈）
+- [ ] action 是否可执行（不是「要小心」这种无操作指引）
+- [ ] 蒸馏的是 HOW 不是 WHAT（根因模式，不是事件描述）
+- [ ] 没有项目特定的硬编码值
+
+## 验证检查
+
+- [ ] Recurrence-Count ≥ 2（同一模式在 ≥2 个场景出现）
+- [ ] 有生成力（能给出具体操作指引）
+- [ ] 有排他性（不是常识）
+
+## 重复检查
+
+- [ ] 检查现有 skills 目录中是否已有覆盖
+- [ ] 如果是对已有 Skill 的增量更新，使用 revise 而非 create

skills/skill-management/assets/templates/signal-format.md

@@ -0,0 +1,39 @@
+---
+name: signal-format
+description: "DISCOVER 阶段信号输出格式模板"
+---
+
+# 信号输出格式
+
+每条候选信号包含：
+
+```
+信号类型 | 来源（task_id / PR / review / session）| 时间 | 简述（≤100 字）
+ID: SIG-YYYYMMDD-XXX
+Priority: low | medium | high | critical
+Status: pending | in_progress | resolved | promoted
+See Also: SIG-YYYYMMDD-XXX（关联信号）
+Recurrence-Count: N（同一模式出现次数）
+Pattern-Key: category.subcategory（稳定去重键）
+```
+
+## 字段说明
+
+| 字段 | 用途 | 示例 |
+|------|------|------|
+| ID | 唯一标识，便于交叉引用 | SIG-20260618-001 |
+| Priority | 优先级排序 | critical: 阻断核心功能; high: 影响常见流程; medium: 有 workaround; low: 边缘场景 |
+| Status | 生命周期跟踪 | pending → in_progress → resolved / promoted |
+| See Also | 关联相似信号，发现共性模式 | SIG-20260617-003 |
+| Recurrence-Count | 同一模式出现次数，≥3 触发自动提升 | 2 |
+| Pattern-Key | 稳定去重键，跨 agent 匹配同一模式 | sync.field_mapping |
+
+## 信号类型（5 类）
+
+| 类型 | 识别特征 |
+|------|---------|
+| 失败模式 | 有明确的失败原因 + 排查过程 |
+| 重复问题 | 同关键词出现 ≥2 次 |
+| 决策转折 | 原方向被推翻或修正 |
+| 新实践 | 之前没有的知识 |
+| 知识缺口 | 查不到/不确定的东西 |

skills/skill-management/assets/templates/skill-template.md

@@ -0,0 +1,51 @@
+---
+name: skill-template
+description: "SKILL.md 标准模板 — 蒸馏产出时按此格式编写"
+---
+
+# Skill 标准模板
+
+```yaml
+---
+name: <skill-name>
+description: "Use when <触发条件/问题模式描述>"
+---
+
+# <Skill 标题>
+
+## 什么时候用
+<具体的触发场景，按问题模式描述，不按技术特定症状>
+
+## 怎么做
+<根因分析 + 操作步骤>
+
+1. <步骤 1>
+2. <步骤 2>
+3. <步骤 3>
+
+## 常见错误
+<反模式：什么不该做>
+
+- ❌ <错误做法> → <后果>
+- ❌ <错误做法> → <后果>
+
+## 来源
+<evidence：哪些 task/PR/review 提炼了这条经验>
+
+- task <id>: <简述>
+- PR #<num>: <简述>
+```
+
+## description 编写要点
+
+- 以「Use when...」开头
+- 只描述触发条件（when），**不描述工作流**（how）
+- 描述问题模式，不描述技术特定症状
+- 控制在 1-2 句话
+
+## 质量自检
+
+- [ ] trigger 是否具体（不是「注意代码质量」）
+- [ ] action 是否可执行（不是「要小心」）
+- [ ] 是否与已有 Skill 重复
+- [ ] description 是否只含触发条件

skills/skill-management/references/apply.md

@@ -0,0 +1,34 @@
+# APPLY — Skill 应用阶段
+
+## 机制
+
+APPLY 完全基于 openclaw 原生 skill 机制，不需要额外代码：
+
+1. openclaw 扫描 skills 目录 → 生成 `<available_skills>` 列表（只有 name + description）
+2. Agent 按 description 匹配 → `read` SKILL.md 完整内容
+3. Agent 按内容执行
+
+## 渐进式加载
+
+- L1：`<available_skills>` 列表（~100 token/skill）— 每次启动注入
+- L2：Agent `read` SKILL.md — 按需加载
+- L3：SKILL.md 内引用的 references/ 文件 — 按需加载
+
+## Skill 存放位置与可见性
+
+| 位置 | 可见性 | 优先级 |
+|------|--------|--------|
+| `~/.openclaw/workspace-<agent>/skills/` | 仅该 agent | 1（最高） |
+| `~/.sanguo_projects/sanguo_mozi/skills/` | 所有 moziplus agent | 6（最低） |
+
+workspace 版本覆盖公共版本——agent 可以有自己改进过的版本。
+
+## 自我修补
+
+使用 Skill 时发现问题（缺步骤、过时信息、命令变更）→ **立即** 通过 skill_workshop 提交 revise proposal：
+
+```python
+skill_workshop(action="revise", proposal_id="<id>", proposal_content="<修改后的内容>")
+```
+
+不等定时任务，不等到下次 review。

skills/skill-management/references/discover-l1.md

@@ -0,0 +1,84 @@
+# DISCOVER L1 — 各 agent 自蒸馏（每天 03:00）
+
+## 你是谁
+
+你是某个 agent（张飞/关羽/赵云/司马懿/庞统/姜维），在每天 03:00 被 cron 唤醒，执行自己的经验蒸馏。
+
+## cron 错开时间
+
+各 agent 错开 15 分钟避免资源争用：
+
+| Agent | 时间 |
+|-------|------|
+| zhangfei-dev | 03:00 |
+| guanyu-dev | 03:15 |
+| zhaoyun-data | 03:30 |
+| simayi-challenger | 03:45 |
+| pangtong-fujunshi | 04:00 |
+| jiangwei-infra | 04:15 |
+
+## 操作步骤
+
+### Step 1: 扫描当天 session JSONL
+
+```
+输入：~/.openclaw/agents/<your-agent-id>/sessions/*.jsonl
+时间范围：过去 24 小时（上次 L1 到现在）
+```
+
+重点扫描以下内容：
+- `"tool":"exec"` 失败的命令（exit code 非 0）
+- `"role":"user"` 消息中的纠正（「不对」「错了」「应该是」等）
+- `"role":"assistant"` 中的反复返工（同一文件改了 3 次以上）
+- task status 变更为 failed 的事件
+- review verdict 为 REQUEST_CHANGES 的记录
+
+### Step 2: 信号识别（5 类高价值信号）
+
+| 信号类型 | 识别特征 | 示例 |
+|---------|---------|------|
+| 失败模式 | 有明确的失败原因 + 排查过程 | 命令报错、CI 失败、review 驳回 |
+| 重复问题 | 同关键词在当天出现 ≥2 次 | 反复修改同一段代码、同类错误 |
+| 决策转折 | 原方向被推翻或修正 | 主公纠正、需求澄清、rebuttal |
+| 新实践 | 之前没有的知识 | 新工具用法、新架构模式 |
+| 知识缺口 | 表达不确定、查不到 | 「不确定」「没找到」「推测」 |
+
+### Step 3: 蒸馏（HOW not WHAT）
+
+对每个信号，提取根因模式，不是事件描述：
+
+```
+❌ "PR #83 修复了 event_type 未知的问题"（WHAT，无法复用）
+✅ "消费者/生产者字段同步：新增 dataclass 字段时，必须同步所有从 JSON 提取该字段的代码路径"（HOW，可复用）
+```
+
+蒸馏规范详见 `references/distill.md`。
+
+### Step 4: 产出 draft proposal
+
+对蒸馏后的经验，使用 skill_workshop 提交：
+
+```
+skill_workshop(action="create", name="<skill-name>", description="Use when <触发条件>", proposal_content="<SKILL.md 内容>")
+```
+
+输出格式（每条信号）：
+```
+信号类型 | 来源（task_id / session）| 时间 | 简述（≤100 字）
+ID: SIG-YYYYMMDD-XXX
+Priority: low | medium | high | critical
+Status: pending
+Recurrence-Count: N
+Pattern-Key: category.subcategory（如 sync.field_mapping）
+```
+
+### Step 5: 完成
+
+所有 draft proposal 提交后，L1 结束。不需要等待 L2 审查结果（庞统会在 05:00 处理）。
+
+## 注意事项
+
+- 数据源**只有**你自己的 session JSONL，不需要扫描黑板/Gitea/Mail
+- 如果当天没有有价值的信号（没踩坑、没被纠正、没新发现），不产出任何 proposal，这是正常的
+- 不要为了产出而强行蒸馏——偶发问题降级为 MEMORY.md，不提交 proposal
+- 质量优于数量：1 条高质量 proposal 比 5 条流水账有价值

skills/skill-management/references/discover-l2.md

@@ -0,0 +1,118 @@
+# DISCOVER L2 — 庞统整合审查（每天 05:00）
+
+## 你是谁
+
+你是庞统，在每天 05:00 被 cron 唤醒，执行跨 agent 整合 + draft proposal 审查。
+
+前提：所有 agent 的 L1 自蒸馏（03:00-04:15）已完成。
+
+## 操作步骤
+
+### Step 1: 获取所有 L1 draft proposals
+
+```
+skill_workshop(action="list", status="pending")
+```
+
+列出所有 pending 状态的 proposal，检查哪些是今天 L1 产出的。
+
+### Step 2: 全量数据源扫描
+
+扫描以下数据源，识别跨 agent 共性模式：
+
+| 数据源 | 位置 | 关注什么 |
+|--------|------|---------|
+| 黑板 tasks | 各项目 blackboard.db | task failed、状态异常 |
+| 黑板 reviews | reviews 表 | REQUEST_CHANGES verdict + suggestions |
+| 黑板 comments | comments 表 | rebuttal 讨论、@mention 争议 |
+| 黑板 events | events 表 | guardrail 拦截、异常检测 |
+| Gitea Issues/PRs | Gitea API | 新问题、PR review 评论 |
+| Gitea CI | Gitea Actions | lint/test/build 失败 |
+| Mail | mail API | 跨 agent 讨论、推理过程 |
+| 所有 agent JSONL | ~/.openclaw/agents/*/sessions/ | 全团队当天思考过程 |
+| MEMORY.md | 各 agent workspace | 已有经验教训 |
+| knowledge-gaps.md | wiki-vault/_meta/ | 知识缺口 |
+| L1 draft proposals | skill_workshop pending | 各 agent 当天提交 |
+
+### Step 3: 跨 agent 共性模式识别
+
+寻找同一 Pattern-Key 在多个 agent 的 JSONL/proposal 中出现的情况：
+
+```
+张飞 SIG-20260618-001: Pattern-Key: sync.field_mapping
+关羽 SIG-20260618-002: Pattern-Key: sync.field_mapping
+→ 共性信号！Recurrence-Count = 2，可合并为共享 Skill
+```
+
+### Step 4: 审查每个 draft proposal
+
+对每个 L1 draft proposal，逐条审查：
+
+```
+skill_workshop(action="inspect", proposal_id="<id>")
+```
+
+审查维度：
+
+| 维度 | 标准 | 不通过 |
+|------|------|--------|
+| Recurrence-Count ≥ 2 | 同一 Pattern-Key 在 ≥2 个场景出现 | 降级为 MEMORY.md |
+| 有生成力 | 能给出具体操作指引 | 丢弃 |
+| 有排他性 | 不是常识 | 丢弃 |
+| description 合规 | 只描述触发条件，不含工作流 | 要求 revise |
+| trigger 具体 | 不是「注意代码质量」 | 要求 revise |
+
+### Step 5: 执行决策
+
+对每个 proposal 做出决策：
+
+**APPROVE**（个人经验，质量达标）：
+```python
+skill_workshop(action="apply", proposal_id="<id>")
+# skill_workshop 自动写入 agent workspace: ~/.openclaw/workspace-<agent>/skills/<skill-name>/
+# 仅该 agent 可见
+```
+
+**MERGE**（跨 agent 共性）：
+```python
+# 1. 在庞统 workspace apply 合并后的版本
+skill_workshop(action="apply", proposal_id="<id>")
+# 2. cp 到公共目录（skill_workshop 不能写 extraDir）
+cp ~/.openclaw/workspace-pangtong/skills/<skill-name>/SKILL.md \
+   ~/.sanguo_projects/sanguo_mozi/skills/<skill-name>/SKILL.md
+# 3. 通知各 agent quarantine workspace 中的同名 draft
+# 在相关 PR/Issue 中 @agent 说明
+```
+
+**REJECT**（质量不够）：
+```python
+skill_workshop(action="reject", proposal_id="<id>", reason="<具体原因>")
+# agent 在下次 L1 时看到反馈
+```
+
+**PROMOTE**（高确定性经验，提升为规则）：
+```python
+# 手动写入 AGENTS.md / SOUL.md / TOOLS.md 对应区块
+# 这不属于 skill_workshop 管理范围
+```
+
+### Step 6: 全局提升检查
+
+检查是否有经验达到提升条件（Recurrence-Count ≥ 3 + 跨 ≥2 任务 + 30 天内）：
+
+| 提升目标 | 条件 | 效果 |
+|---------|------|------|
+| 独立 Skill | 足够通用，有自己的触发条件 | 独立 SKILL.md |
+| AGENTS.md 规则 | 确定性高，适用于所有 agent | L1 强制注入 |
+| guardrail | 安全相关，不可违反 | 强制检查 |
+
+### Step 7: 知识缺口反馈
+
+IMPROVE 发现的经验缺口或 L2 发现的新领域 → 追加到 `knowledge-gaps.md`。
+
+## 注意事项
+
+- L2 时间窗口：05:00 执行，确保 L1 全部完成（最后一个 agent 04:15 开始）
+- 全量扫描不需要逐行读 JSONL，用 grep 定位关键词再精读匹配段
+- MERGE 后必须清理各 agent workspace 的同名 draft（避免覆盖公共版本）
+- REJECT 必须附具体原因，帮 agent 改进而非打击

skills/skill-management/references/distill.md

@@ -0,0 +1,137 @@
+# DISTILL — 蒸馏规范
+
+## 核心原则：HOW not WHAT
+
+蒸馏的是「怎么做」不是「发生了什么」：
+
+```
+❌ "PR #83 修复了 event_type 未知的问题"
+    → 这是 WHAT，无法复用
+
+✅ "消费者/生产者字段同步：新增 dataclass 字段时，必须同步所有从 JSON 提取该字段的代码路径"
+    → 这是 HOW，可复用到任何消费者/生产者场景
+```
+
+## SKILL.md 编写规范
+
+```yaml
+---
+name: skill-name
+description: Use when [触发条件/问题模式描述]，不描述工作流
+---
+
+# Skill 标题
+
+## 什么时候用
+（具体的触发场景，按问题模式描述，不按技术特定症状）
+
+## 怎么做
+（根因分析 + 操作步骤）
+
+## 常见错误
+（反模式：什么不该做）
+
+## 来源
+（evidence：哪些 task/PR/review 提炼了这条经验）
+```
+
+## description 关键规则
+
+- 只描述触发条件（when to use），**绝不描述工作流**（how）
+- 以「Use when...」开头
+- 描述问题模式，不描述技术特定症状
+- 原因：测试发现 description 如果总结了工作流，agent 会按 description 执行而跳过读完整 SKILL.md
+
+### 示例
+
+```yaml
+# ❌ BAD：描述了工作流
+description: Use when modifying dataclass — checks all extraction points, runs tests
+
+# ✅ GOOD：只描述触发条件
+description: Use when modifying a dataclass that is populated from JSON extraction by another module
+
+# ❌ BAD：太抽象
+description: Use for code quality
+
+# ✅ GOOD：描述问题模式
+description: Use when a field added to a dataclass appears empty or as default value at runtime
+```
+
+## 蒸馏示例
+
+**一级蒸馏**（从具体案例提取）：
+
+```yaml
+# 案例 1：PromptContext event_type 未知
+# 案例 2：PromptContext from_agent/mail_type 缺失（PR #26 D2）
+→ 共同根因：消费者/生产者字段同步问题
+
+## 消费者/生产者字段同步
+
+**什么时候用**：修改 dataclass 时，如果该 dataclass 由外部 JSON 提取填充
+
+**怎么做**：
+1. 改 dataclass 定义
+2. 检查所有从 JSON 提取字段的代码路径，同步新增提取逻辑
+3. 检查所有构造该 dataclass 的调用点，同步新增参数
+4. 跑一次构建测试验证字段不为空
+
+**常见错误**：只改 dataclass 不改提取逻辑 → 字段默认值为空 → 运行时不报错但行为异常
+```
+
+**二级蒸馏**（从多个一级经验提取通用模式）：
+
+如果经验在 ≥2 个不同场景复现，验证通过后，可以提升为独立 Skill 或固化到 AGENTS.md 规则。
+
+## 验证标准
+
+从 draft → active：
+
+| 维度 | 标准 | 不通过 |
+|------|------|--------|
+| Recurrence-Count ≥ 2 | 同一 Pattern-Key 在 ≥2 个场景出现 | 降级为 MEMORY.md |
+| 有生成力 | 能给出具体操作指引 | 丢弃 |
+| 有排他性 | 不是常识 | 丢弃 |
+
+提升触发（全部满足）：30 天内 ≥3 次 + 跨 ≥2 个任务。
+
+## Skill Extraction 质量 Gate
+
+| 标准 | 描述 |
+|------|------|
+| Recurring | 有 See Also 链接到 2+ 个相似信号 |
+| Verified | Status 是 resolved 且有工作修复 |
+| Non-obvious | 需要实际调试才能发现 |
+| Broadly applicable | 不是项目特定，可跨场景复用 |
+
+## 质量检查
+
+| 检查项 | 标准 |
+|--------|------|
+| trigger 是否具体 | 不是「注意代码质量」 |
+| action 是否可执行 | 不是「要小心」 |
+| 是否与已有 Skill 重复 | 检查现有 skills 目录 |
+| description 是否只含触发条件 | 不包含工作流描述 |
+
+## 矛盾处理
+
+新经验与已有经验冲突时：
+- **时间性矛盾**（观点演化）→ 记录演化轨迹，以近期为主
+- **领域性矛盾**（不同场景不同规则）→ 分场景记录
+- **本质性张力**（价值观内在冲突）→ 标注为「核心张力」，两个版本都保留
+
+**矛盾是特征，不是 Bug。** 强制调和会丢失关键信号。
+
+## 信号输出格式
+
+每条信号包含：
+```
+信号类型 | 来源 | 时间 | 简述（≤100 字）
+ID: SIG-YYYYMMDD-XXX
+Priority: low | medium | high | critical
+Status: pending | in_progress | resolved | promoted
+See Also: SIG-YYYYMMDD-XXX
+Recurrence-Count: N
+Pattern-Key: category.subcategory
+```

skills/skill-management/references/improve.md

@@ -0,0 +1,70 @@
+# IMPROVE — 引用追踪 + 淘汰 + 提升（每周 cron）
+
+## 你是谁
+
+你是庞统，每周执行一次 IMPROVE cron，扫描过去 7 天的所有 session JSONL。
+
+## 操作步骤
+
+### Step 1: 引用追踪
+
+扫描过去 7 天所有 agent 的 session JSONL，采集 Skill 引用信号：
+
+| 信号 | 采集方式 | 可信度 |
+|------|---------|--------|
+| Skill 被 read 的时间 | grep `"tool":"read"` + SKILL.md 路径 | 中 |
+| Skill 在 available_skills 中被注入 | grep available_skills 列表 | 中（注入但未必用） |
+| Agent 输出中提及 skill name | grep skill name in assistant messages | 高 |
+| Skill 文件最近修改时间 | git log / 文件 mtime | 高 |
+
+### Step 2: 生成淘汰候选报告
+
+对每个 Skill 检查最近 30 天的引用信号：
+
+```
+30 天无引用信号
+  → 加入淘汰候选列表
+```
+
+输出淘汰候选报告：
+```
+| Skill 名称 | 最后引用时间 | 存放位置 | 建议 |
+|-----------|------------|---------|------|
+| xxx | 2026-05-15 | 公共目录 | 建议淘汰 |
+| yyy | 从未被引用 | 张飞 workspace | 建议淘汰 |
+```
+
+### Step 3: 庞统审阅决策
+
+逐条审阅淘汰候选：
+
+- **确认淘汰** → `skill_workshop(action="quarantine", proposal_id="<id>")`
+- **保留观察** → 标注，下轮再查
+- **更新后保留** → 修改 description / 内容，重置计时
+
+**注意**：openclaw 本身的 skill（~/.openclaw/plugin-skills/ 和全局 skills）也纳入追踪。报告给主公决定是否禁用。
+
+### Step 4: 经验提升检查
+
+检查是否有 Skill 达到提升条件（被频繁引用 ≥5 次 + 多次验证）：
+
+| 提升目标 | 条件 | 效果 |
+|---------|------|------|
+| 独立 Skill | 足够通用，有自己的触发条件 | 独立 SKILL.md |
+| AGENTS.md 规则 | 确定性高，适用于所有 agent | L1 强制注入 |
+| guardrail | 安全相关，不可违反 | 强制检查 |
+
+### Step 5: 反馈到 DISCOVER
+
+IMPROVE 发现的经验缺口写入 knowledge-gaps.md：
+```
+- [日期] IMPROVE 发现「<skill-name> 不适用 <场景>」→ 待 DISCOVER 处理
+```
+
+成为下一轮 DISCOVER L2 的输入。
+
+## 注意事项
+
+- 不追求精确归因，做时间维度的信号采集
+- 淘汰决策由庞统判断，不自动执行
+- 提升到 AGENTS.md 的规则需要主公确认（影响所有 agent 的确定性注入）

src/api/toolchain_routes.py

@@ -778,9 +778,8 @@ def _send_deploy_failure_task(repo: str, pr_number: int, pr_title: str, reason:
             action_type="deploy_failure",
             steps=[
                 "检查 deploy 日志",
-                "排查失败原因",
-                "修复并重新部署",
-                "提交 action report（POST http://localhost:8083/api/projects/_toolchain/tasks/<task_id>/comments，comment_type=action_report）",
+                "根据 deploy 日志判断失败原因类型：\n  a. 代码/配置问题（rsync 路径错、依赖缺失、启动失败）→ 修复 → 重新部署\n  b. 基础设施问题（Gitea 不可用、网络不通、磁盘满、SSH 故障）→ 在该仓库创建 Issue 指派 jiangwei-infra（见下方「需要创建 Issue 时」），label 必须包含 type/infrastructure",
+                "提交 action report（POST http://localhost:8083/api/projects/_toolchain/tasks/<task_id>/comments，comment_type=action_report）— 报告中说明判断的原因类型和执行的操作",
             ],
             context_data={
                 "repo": repo,
@@ -997,30 +996,58 @@ async def _handle_issues(payload: Dict[str, Any]) -> None:
             "brief": brief,
         })
 
-        title = f"Issue 指派: {issue_title} ({repo}#{issue_number})"
-        _send_toolchain_task(
-            to_agent=assignee,
-            title=title,
-            description=text,
-            event_type="issue_assigned",
-            action_type="issue_assigned",
-            steps=[
-                f"创建分支 fix/{issue_number}-{brief}",
-                "编码 + 写 UT",
-                "push → 等 CI",
-                f"CI 通过后创建 PR（Gitea API: POST /repos/{repo}/pulls）",
-                "等 Review",
+        # 检查是否是基础设施 Issue（按 label 分流）
+        is_infrastructure = any("infrastructure" in lbl.lower() for lbl in labels_list)
+
+        if is_infrastructure:
+            infra_steps = [
+                "根据 Issue body 中的错误来源和日志片段排查问题",
+                "修复基础设施问题（如修复 CI runner 环境、恢复网络、重启服务等）",
+                "修复后在 Issue 上 comment 说明修复方式和结果",
                 "提交 action report（POST http://localhost:8083/api/projects/_toolchain/tasks/<task_id>/comments，comment_type=action_report）",
-            ],
-            context_data={
-                "issue_number": issue_number,
-                "repo": repo,
-                "issue_title": issue_title,
-                "labels": labels,
-                "issue_body": issue_body or "(无描述)",
-                "brief": brief,
-            },
-        )
+            ]
+            title = f"基础设施 Issue: {issue_title} ({repo}#{issue_number})"
+            _send_toolchain_task(
+                to_agent=assignee,
+                title=title,
+                description=text,
+                event_type="infrastructure_failure",
+                action_type="infrastructure_failure",
+                steps=infra_steps,
+                context_data={
+                    "issue_number": issue_number,
+                    "repo": repo,
+                    "issue_title": issue_title,
+                    "labels": labels,
+                    "issue_body": issue_body or "(无描述)",
+                    "brief": brief,
+                },
+            )
+        else:
+            title = f"Issue 指派: {issue_title} ({repo}#{issue_number})"
+            _send_toolchain_task(
+                to_agent=assignee,
+                title=title,
+                description=text,
+                event_type="issue_assigned",
+                action_type="issue_assigned",
+                steps=[
+                    f"创建分支 fix/{issue_number}-{brief}",
+                    "编码 + 写 UT",
+                    "push → 等 CI",
+                    f"CI 通过后创建 PR（Gitea API: POST /repos/{repo}/pulls）",
+                    "等 Review",
+                    "提交 action report（POST http://localhost:8083/api/projects/_toolchain/tasks/<task_id>/comments，comment_type=action_report）",
+                ],
+                context_data={
+                    "issue_number": issue_number,
+                    "repo": repo,
+                    "issue_title": issue_title,
+                    "labels": labels,
+                    "issue_body": issue_body or "(无描述)",
+                    "brief": brief,
+                },
+            )
 
     elif action == "opened":
         if "部署失败" in issue_title:
@@ -1043,9 +1070,8 @@ async def _handle_issues(payload: Dict[str, Any]) -> None:
                     action_type="deploy_failure",
                     steps=[
                         "检查 deploy 日志",
-                        "排查失败原因",
-                        "修复并重新部署",
-                        "提交 action report（POST http://localhost:8083/api/projects/_toolchain/tasks/<task_id>/comments，comment_type=action_report）",
+                        "根据 deploy 日志判断失败原因类型：\n  a. 代码/配置问题（rsync 路径错、依赖缺失、启动失败）→ 修复 → 重新部署\n  b. 基础设施问题（Gitea 不可用、网络不通、磁盘满、SSH 故障）→ 在该仓库创建 Issue 指派 jiangwei-infra（见下方「需要创建 Issue 时」），label 必须包含 type/infrastructure",
+                        "提交 action report（POST http://localhost:8083/api/projects/_toolchain/tasks/<task_id>/comments，comment_type=action_report）— 报告中说明判断的原因类型和执行的操作",
                     ],
                     context_data={
                         "repo": repo,
@@ -1126,9 +1152,8 @@ async def _handle_issue_comment(payload: Dict[str, Any]) -> None:
             action_type="ci_failure",
             steps=[
                 "查看完整 CI 日志（PR 页面或 Gitea Actions 页面）",
-                "修复失败的测试",
-                "push → CI 自动重跑",
-                "提交 action report（POST http://localhost:8083/api/projects/_toolchain/tasks/<task_id>/comments，comment_type=action_report）",
+                "根据 CI 日志判断失败原因类型：\n  a. 代码问题（lint/test 失败）→ 修复失败的测试 → push 到原分支 → CI 自动重跑\n  b. 基础设施问题（runner 环境/Python/venv/Gitea/网络故障）→ 在该仓库创建 Issue 指派 jiangwei-infra（见下方「需要创建 Issue 时」），label 必须包含 type/infrastructure",
+                "提交 action report（POST http://localhost:8083/api/projects/_toolchain/tasks/<task_id>/comments，comment_type=action_report）— 报告中说明判断的原因类型和执行的操作",
             ],
             context_data={
                 "pr_number": issue_number,

src/blackboard/db.py

@@ -117,6 +117,7 @@ def _migrate_v28(conn: sqlite3.Connection) -> None:
 
     _safe_add_column(conn, "tasks", "round_count", "INTEGER DEFAULT 0")
     _safe_add_column(conn, "tasks", "resumed_from", "TEXT")
+    _safe_add_column(conn, "tasks", "dispatch_count", "INTEGER DEFAULT 0")
 
     # 3. checkpoints 表（M3）
     conn.execute("""CREATE TABLE IF NOT EXISTS checkpoints (

src/blackboard/models.py

@@ -41,6 +41,8 @@ class Task:
     resumed_from: Optional[str] = None       # 暂停前状态，恢复时回到原状态
     # v2.9 四相循环
     round_count: int = 0                     # 庞统 review 轮次计数
+    # §15 Runaway Guard
+    dispatch_count: int = 0                  # 被 ticker dispatch 的总次数
     # v2.8 归档
     archived: bool = False
     archived_at: Optional[str] = None

src/blackboard/operations.py

@@ -208,7 +208,7 @@ class Blackboard:
                 params.append(parent_task)
             if conditions:
                 query += " WHERE " + " AND ".join(conditions)
-            query += " ORDER BY priority ASC, created_at ASC"
+            query += " ORDER BY priority ASC, created_at DESC"
             rows = conn.execute(query, params).fetchall()
             return [Task.from_row(r) for r in rows]
         finally:

src/daemon/experience.py

@@ -1,3 +1,5 @@
+# DEPRECATED per §19 重设计 — 经验蒸馏改为双层 daily cron（L1 各 agent + L2 庞统）
+# 保留代码供参考，后续 P3 清理时物理删除
 """Experience Distillation — 经验蒸馏
 
 从已完成的任务产出中提取经验：

src/daemon/mail_handler.py

@@ -9,7 +9,7 @@ import logging
 from pathlib import Path
 
 from src.daemon.base_task_handler import BaseTaskHandler, VerifyResult
-from src.daemon.prompt_composer import PromptComposer, PromptContext, GiteaConventionSection, WikiGuideSection
+from src.daemon.prompt_composer import PromptComposer, PromptContext, GiteaConventionSection, WikiGuideSection, DeliveryChecklistSection
 from src.blackboard.db import get_connection
 
 logger = logging.getLogger("moziplus-v2.handler.mail")
@@ -36,7 +36,7 @@ class MailHandler(BaseTaskHandler):
         return composer.compose(context)
 
     def get_sections(self) -> list:
-        return [MailContextSection(), MailApiSection(), MailConstraintsSection(), GiteaConventionSection(), WikiGuideSection()]
+        return [MailContextSection(), MailApiSection(), MailConstraintsSection(), GiteaConventionSection(), WikiGuideSection(), DeliveryChecklistSection()]
 
     def verify_completion(self, task_id: str, db_path: Path) -> VerifyResult:
         """Mail 完成验证：区分 inform/request。

src/daemon/prompt_composer.py

@@ -174,3 +174,27 @@ class WikiGuideSection:
 
     def should_include(self, context: "PromptContext") -> bool:
         return True
+
+
+# ---------------------------------------------------------------------------
+# DeliveryChecklistSection — 交付检查清单
+# ---------------------------------------------------------------------------
+class DeliveryChecklistSection:
+    """交付检查清单 — 提醒 Agent 完成前同步关联成果物。"""
+
+    name: str = "delivery_checklist"
+    priority: int = 55  # CONSTRAINTS(50) 和 EXTENSION(60) 之间
+
+    CHECKLIST_TEXT = (
+        "## 交付检查\n"
+        "完成代码改动前确认：\n"
+        "- 改了实现 → docs/design/ 对应设计文档是否需要更新\n"
+        "- 改了实现 → tests/ 是否有对应测试脚本需要更新\n"
+        "- 所有成果物变更通过 PR 流程：PR review 把关设计合理性，CI 把关代码质量，CD 把关部署正确性\n"
+    )
+
+    def render(self, context: "PromptContext") -> str:
+        return self.CHECKLIST_TEXT
+
+    def should_include(self, context: "PromptContext") -> bool:
+        return True

src/daemon/skill_system.py

@@ -1,3 +1,6 @@
+# DEPRECATED per §19 重设计 — 不再参与 skill 发现/加载
+# 实际 skill 发现走 openclaw 原生 <available_skills> 机制
+# 保留代码供参考，后续 P3 清理时物理删除
 """Skill System — 技能注册、加载、匹配、执行
 
 三层自由度：

src/daemon/spawner.py

@@ -288,6 +288,8 @@ class AgentSpawner:
             mail_type = ""
             action_type = ""
             action_steps = []
+            event_type = ""
+            event_data = {}
             try:
                 meta = json.loads(must_haves) if must_haves else {}
                 from_agent = meta.get("from", "")
@@ -295,6 +297,8 @@ class AgentSpawner:
                 # toolchain 字段提取
                 action_type = meta.get("action_type", "")
                 action_steps = meta.get("steps", [])
+                event_type = meta.get("event_type", "")
+                event_data = meta.get("context", {})
             except Exception:
                 pass
             ctx = PromptContext(
@@ -304,6 +308,7 @@ class AgentSpawner:
                 spawn_type=spawn_type,
                 from_agent=from_agent, mail_type=mail_type,
                 action_type=action_type, action_steps=action_steps,
+                event_type=event_type, event_data=event_data,
             )
             return handler.build_prompt(ctx)
 
@@ -625,19 +630,24 @@ curl -X POST http://{self.api_host}:{self.api_port}/api/projects/{project_id}/ta
                 stdout=asyncio.subprocess.PIPE,
                 stderr=asyncio.subprocess.PIPE,
             )
-            self._register_session(session_id, agent_id, task_id, proc.pid,
+            # use_main_session=True 时 session_id 为 None,但 _register_session 和
+            # _monitor_process 需要一个非 None 的 key;同时 ticker 等调用方用
+            # `result is not None` 判断 spawn 是否成功,返回 None 会被误判为失败。
+            # 统一用 "main" 作为占位标识。
+            effective_sid = session_id or "main"
+            self._register_session(effective_sid, agent_id, task_id, proc.pid,
                                    broadcast_task_ids=broadcast_task_ids)
             logger.info("Spawned agent %s (session=%s, pid=%d)",
-                        agent_id, session_id, proc.pid)
+                        agent_id, effective_sid, proc.pid)
 
             # Schedule monitor(传 wrapped_on_complete)
             asyncio.create_task(
-                self._monitor_process(session_id, proc, agent_id, task_id,
+                self._monitor_process(effective_sid, proc, agent_id, task_id,
                                       on_complete=_wrapped_on_complete,
                                       db_path=task_db_path or self.db_path)
             )
 
-            return session_id
+            return effective_sid
 
         except Exception as e:
             # spawn 失败也要 release counter
@@ -1251,7 +1261,7 @@ curl -X POST http://{api_host}:{api_port}/api/projects/{project_id}/tasks/{task_
             conn = get_connection(db_path)
             try:
                 row = conn.execute(
-                    "SELECT id, title, status FROM tasks WHERE id=?", (
+                    "SELECT id, title, status, must_haves FROM tasks WHERE id=?", (
                         task_id,)
                 ).fetchone()
                 if not row:
@@ -1949,6 +1959,19 @@ curl -X POST http://{api_host}:{api_port}/api/projects/{project_id}/tasks/{task_
                 try:
                     from src.daemon.mail_notify import _is_mail_project, notify_mail_failed
                     if _is_mail_project(db_path):
+                        # 防御性检查：如果 task 已经 done，不触发失败通知（竞态保护）
+                        # 场景：spawner 标 failed 和 handler 标 done 同时发生
+                        try:
+                            conn2 = get_connection(db_path)
+                            current_status = conn2.execute(
+                                "SELECT status FROM tasks WHERE id=?", (task_id,)
+                            ).fetchone()
+                            conn2.close()
+                            if current_status and current_status["status"] == "done":
+                                logger.info("Task %s already done, skipping mail failure notification", task_id)
+                                return
+                        except Exception:
+                            pass
                         # Mail 失败：通知发件人，不 @pangtong
                         notify_mail_failed(db_path, task_id, reason, detail)
                     else:

src/daemon/task_handler.py

@@ -10,7 +10,7 @@ from pathlib import Path
 from typing import Dict, Optional
 
 from src.daemon.base_task_handler import BaseTaskHandler, VerifyResult
-from src.daemon.prompt_composer import PromptComposer, PromptContext, GiteaConventionSection, WikiGuideSection
+from src.daemon.prompt_composer import PromptComposer, PromptContext, GiteaConventionSection, WikiGuideSection, DeliveryChecklistSection
 from src.blackboard.db import get_connection
 
 logger = logging.getLogger("moziplus-v2.handler")
@@ -315,6 +315,7 @@ class TaskHandler(BaseTaskHandler):
             TaskConstraintsSection(),
             GiteaConventionSection(),
             WikiGuideSection(),
+            DeliveryChecklistSection(),
         ]
 
     def build_prompt(self, context: PromptContext) -> str:

src/daemon/ticker.py

@@ -332,25 +332,10 @@ class Ticker:
             except Exception as e:
                 logger.warning("HealthChecker error for %s: %s", project_id, e)
 
-        # 9. 经验蒸馏（完成的 task 自动触发）
+        # 9. 经验蒸馏 — DEPRECATED per §19, 双层 daily cron 替代
+        # 保留参数向后兼容，不再执行逐任务蒸馏
         if self.experience_distiller:
-            try:
-                conn2 = get_connection(db_path)
-                try:
-                    done_tasks = conn2.execute(
-                        "SELECT id FROM tasks WHERE status='done' AND updated_at > datetime('now', '-60 seconds')"
-                    ).fetchall()
-                finally:
-                    conn2.close()
-                for row in done_tasks:
-                    t = Blackboard(db_path).get_task(row[0])
-                    if t:
-                        self.experience_distiller.distill_from_task(
-                            task_id=t.id, task_title=t.title, task_type=t.task_type
-                        )
-            except Exception as e:
-                logger.warning(
-                    "ExperienceDistiller error for %s: %s", project_id, e)
+            logger.debug("ExperienceDistiller deprecated per §19, skipping (use L1/L2 daily cron)")
 
         # 10. 扫描后状态
         result["summary_after"] = queries.task_summary()
@@ -1084,6 +1069,19 @@ Parent Task ID: {parent_task.id}
             broadcast_ids = await self._broadcast_claim(broadcast_tasks, db_path, project_id)
             dispatched.extend(broadcast_ids)
 
+        # §15 Runaway Guard: 统一递增 dispatch_count
+        if dispatched:
+            conn = get_connection(db_path)
+            try:
+                for tid in dispatched:
+                    conn.execute(
+                        "UPDATE tasks SET dispatch_count = COALESCE(dispatch_count, 0) + 1 WHERE id=?",
+                        (tid,),
+                    )
+                conn.commit()
+            finally:
+                conn.close()
+
         return dispatched
 
     async def _broadcast_claim(self, tasks: list, db_path: Path,
@@ -1376,6 +1374,19 @@ Parent Task ID: {parent_task.id}
             except Exception:
                 logger.exception("Review dispatch failed for %s", task.id)
 
+        # §15 Runaway Guard: 统一递增 dispatch_count (review)
+        if dispatched:
+            conn = get_connection(db_path)
+            try:
+                for tid in dispatched:
+                    conn.execute(
+                        "UPDATE tasks SET dispatch_count = COALESCE(dispatch_count, 0) + 1 WHERE id=?",
+                        (tid,),
+                    )
+                conn.commit()
+            finally:
+                conn.close()
+
         return dispatched
 
     # ------------------------------------------------------------------
@@ -1388,6 +1399,31 @@ Parent Task ID: {parent_task.id}
         reclaimed: List[str] = []
         now = datetime.utcnow()  # UTC，与 SQLite datetime('now') 一致
 
+        # §15 Runaway Guard: per-task dispatch_count 上限检查
+        # 覆盖所有状态，防止无限循环 dispatch
+        MAX_DISPATCH_COUNT = 10
+        for status_to_check in ("pending", "working", "claimed"):
+            tasks_to_check = queries.tasks_by_status(status_to_check)
+            for task in tasks_to_check:
+                dispatch_count = getattr(task, 'dispatch_count', 0) or 0
+                if dispatch_count >= MAX_DISPATCH_COUNT:
+                    conn = get_connection(db_path)
+                    try:
+                        ok = self._transition_status(
+                            conn, task.id, "failed",
+                            agent="daemon",
+                            detail={"reason": "runaway_guard",
+                                    "dispatch_count": dispatch_count,
+                                    "message": f"dispatch {dispatch_count} 次仍未完成，自动标 failed"},
+                        )
+                        if ok:
+                            reclaimed.append(task.id)
+                            logger.error(
+                                "Task %s: runaway guard triggered (dispatch_count=%d, status=%s), marking failed",
+                                task.id, dispatch_count, status_to_check)
+                    finally:
+                        conn.close()
+
         # claimed 超时 → 重置为 pending（如果 retry_count >= 3 则升级庞统）
         claimed = queries.tasks_by_status("claimed")
         for task in claimed:

src/daemon/toolchain_handler.py

@@ -13,7 +13,7 @@ from pathlib import Path
 from typing import Dict, List
 
 from src.daemon.base_task_handler import BaseTaskHandler, VerifyResult
-from src.daemon.prompt_composer import PromptComposer, PromptContext, GiteaConventionSection, WikiGuideSection
+from src.daemon.prompt_composer import PromptComposer, PromptContext, GiteaConventionSection, WikiGuideSection, DeliveryChecklistSection
 from src.daemon.toolchain_templates import render_template, _TEMPLATE_MAP
 from src.blackboard.db import get_connection
 
@@ -51,17 +51,41 @@ class ToolchainContextSection:
     name: str = "toolchain_context"
     priority: int = 10
 
+    EVENT_LABELS_ZH: Dict[str, str] = {
+        "review_request": "Review 请求",
+        "review_result": "Review 结果",
+        "review_merged": "PR 合并",
+        "review_comment": "Review 评论",
+        "review_updated": "Review 更新",
+        "ci_failure": "CI 失败",
+        "deploy_failure": "部署失败",
+        "issue_assigned": "Issue 指派",
+        "mention": "@提及",
+    }
+
     def render(self, context: PromptContext) -> str:
         event_type = context.event_type
         event_data: Dict = context.event_data or {}
 
+        # 事件类型中文标签
+        event_label = self.EVENT_LABELS_ZH.get(event_type, event_type or '未知')
+
+        # from / to 信息
+        to_agent = context.agent_id or ''
+        from_agent = 'system'
+
         # Part 1: 事件信息(现有模板引擎)
         if event_type in _TEMPLATE_MAP:
             variables = {k: str(v) for k, v in event_data.items()}
             event_text = render_template(event_type, variables)
+            # 补充事件类型中文标签 + from/to
+            header = f"- **事件类型**: {event_label}\n- **来源**: {from_agent}\n- **指派**: {to_agent}\n"
+            event_text = header + "\n" + event_text
         else:
             lines = ["## 工具链事件", ""]
-            lines.append(f"- **事件类型**: {event_type or '未知'}")
+            lines.append(f"- **事件类型**: {event_label}")
+            lines.append(f"- **来源**: {from_agent}")
+            lines.append(f"- **指派**: {to_agent}")
             if event_data:
                 lines.append("- **事件详情**:")
                 for key, value in event_data.items():
@@ -142,6 +166,19 @@ class ToolchainApiSection:
             "",
             "⚠️ 不要使用 Mail API(飞鸽传书)。所有协作通过 Gitea 留痕。",
             "",
+            "### 需要创建 Issue 时",
+            "",
+            "如果步骤中要求创建 Issue 指派他人（如 jiangwei-infra）：",
+            "```bash",
+            f'curl -s -X POST "{_GITEA_BASE}/repos/{{repo}}/issues" \\',
+            '  -H "Authorization: token <your-token>" \\',
+            '  -H "Content-Type: application/json" \\',
+            '  -d \'{"title": "[moz] infra: 简述问题", "body": "## 问题描述\\n\\n<简要描述问题现象>\\n\\n## 错误来源\\n\\n- 仓库: <repo>\\n- PR/Commit: <链接>\\n- CI/Deploy run: <Gitea Actions 页面链接>\\n\\n## 日志关键片段\\n\\n```<错误日志摘要>```\\n\\n## 判断依据\\n\\n<为什么判断为基础设施问题>", "assignees": ["jiangwei-infra"], "labels": [<label_id>]}\'',
+            "```",
+            "",
+            "⚠️ Issue body 必须包含错误来源链接（PR/Commit + CI run），让排查者能直接看到全貌。",
+            "⚠️ label 数字 ID 先 GET /repos/{repo}/labels 查询 type/infrastructure 对应的 ID。",
+            "",
         ]
         return "\n".join(lines)
 
@@ -194,6 +231,7 @@ class ToolchainConstraintsSection:
             '| “我已经知道了” | ❌ 知道不等于执行。执行步骤 + 提交 action report 才算完成 |',
             '| “步骤太多了，选几个做就行” | ❌ 错！必须逐条执行，不可跳过 |',
             '| “这个步骤不适用于当前情况” | ❌ 如果确实不适用，在 action report 中说明原因，但其他步骤必须执行 |',
+            '| “CI/部署失败不是我代码的问题，我什么也不用做” | ❌ 错！即使是基础设施问题，你也必须创建 Issue 指派 jiangwei-infra（body 含错误来源链接 + 日志 + 判断依据），并在 action report 中说明。不能只报告“不是我的问题”就完事 |',
             "",
         ]
         return "\n".join(lines)
@@ -228,6 +266,7 @@ class ToolchainHandler(BaseTaskHandler):
             ToolchainConstraintsSection(),
             GiteaConventionSection(),
             WikiGuideSection(),
+            DeliveryChecklistSection(),
         ]
 
     def build_prompt(self, context: PromptContext) -> str:

src/frontend/src/App.tsx

@@ -17,7 +17,6 @@ import CourtCeremony from './components/CourtCeremony';
 import CourtDiscussion from './components/CourtDiscussion';
 import UsagePanel from './components/UsagePanel';
 import SettingsPanel from './components/SettingsPanel';
-import ToolchainPanel from './components/ToolchainPanel';
 import GlobalSearch from './components/GlobalSearch';
 import NotificationCenter from './components/NotificationCenter';
 
@@ -101,7 +100,6 @@ export default function App() {
     usage: <UsagePanel />,
     morning: <MorningPanel />,
     settings: <SettingsPanel />,
-    toolchain: <ToolchainPanel />,
   };
 
   return (

src/frontend/src/components/SettingsPanel.tsx

@@ -5,6 +5,7 @@
 
 import { useState, useCallback } from 'react';
 import { api, AgentsStatusData } from '../api';
+import ToolchainPanel from './ToolchainPanel';
 
 interface ServiceCheckResult {
   name: string;
@@ -15,7 +16,7 @@ interface ServiceCheckResult {
 }
 
 export default function SettingsPanel() {
-  const [tab, setTab] = useState<'connections' | 'security' | 'version' | 'logs'>('connections');
+  const [tab, setTab] = useState<'connections' | 'security' | 'version' | 'logs' | 'toolchain'>('connections');
 
   // 接线状态巡检
   const [checking, setChecking] = useState(false);
@@ -95,6 +96,7 @@ export default function SettingsPanel() {
           { key: 'security' as const, label: '🛡️ 安全防务' },
           { key: 'version' as const, label: '📦 版本更新' },
           { key: 'logs' as const, label: '📋 城防日志' },
+          { key: 'toolchain' as const, label: '⛓️ 工具链' },
         ].map((t) => (
           <button key={t.key} className={`btn ${tab === t.key ? 'btn-primary' : ''}`} onClick={() => setTab(t.key)}>
             {t.label}
@@ -288,6 +290,9 @@ export default function SettingsPanel() {
           </div>
         </div>
       )}
+
+      {/* ========== 工具链 ========== */}
+      {tab === 'toolchain' && <ToolchainPanel />}
     </div>
   );
 }

src/frontend/src/components/ToolchainPanel.tsx

@@ -4,6 +4,28 @@
  */
 import { useEffect, useState } from 'react';
 
+const AGENT_NAMES: Record<string, string> = {
+  'pangtong-fujunshi': '庞统',
+  'simayi-challenger': '司马懿',
+  'zhangfei-dev': '张飞',
+  'guanyu-dev': '关羽',
+  'zhaoyun-data': '赵云',
+  'jiangwei-infra': '姜维',
+  'system': '系统',
+};
+
+const EVENT_LABELS: Record<string, string> = {
+  'review_request': 'Review 请求',
+  'review_result': 'Review 结果',
+  'review_merged': 'PR 合并',
+  'review_comment': 'Review 评论',
+  'review_updated': 'Review 更新',
+  'ci_failure': 'CI 失败',
+  'deploy_failure': '部署失败',
+  'issue_assigned': 'Issue 指派',
+  'mention': '@提及',
+};
+
 const STATUS_COLORS: Record<string, string> = {
   pending: '#f59e0b22', claimed: '#6a9eff22', working: '#6a9eff22',
   review: '#818cf822', done: '#2ecc8a22', failed: '#ef444422',
@@ -36,6 +58,7 @@ export default function ToolchainPanel() {
   const [detail, setDetail] = useState<any>(null);
   const [searchQuery, setSearchQuery] = useState('');
   const [loading, setLoading] = useState(false);
+  const [filterMode, setFilterMode] = useState<'all' | 'pending'>('all');
 
   const loadTasks = async (q?: string) => {
     setLoading(true);
@@ -52,6 +75,10 @@ export default function ToolchainPanel() {
     setLoading(false);
   };
 
+  const displayed = filterMode === 'pending'
+    ? tasks.filter(t => !['done', 'failed', 'cancelled'].includes(t.status))
+    : tasks;
+
   useEffect(() => { loadTasks(); }, []);
 
   // 搜索防抖 300ms
@@ -120,7 +147,19 @@ export default function ToolchainPanel() {
             padding: '3px 8px', borderRadius: 4, fontSize: 10,
             border: '1px solid #2a3550', background: '#161b2e', color: '#8899aa', cursor: 'pointer',
           }}>🔄</button>
-          <span style={{ fontSize: 10, color: 'var(--muted)' }}>{tasks.length} 条</span>
+          <button onClick={() => setFilterMode('all')} style={{
+            padding: '3px 8px', borderRadius: 4, fontSize: 10,
+            border: `1px solid ${filterMode === 'all' ? 'var(--acc)' : '#2a3550'}`,
+            background: filterMode === 'all' ? 'var(--acc)22' : '#161b2e',
+            color: filterMode === 'all' ? 'var(--acc)' : '#8899aa', cursor: 'pointer',
+          }}>全部</button>
+          <button onClick={() => setFilterMode('pending')} style={{
+            padding: '3px 8px', borderRadius: 4, fontSize: 10,
+            border: `1px solid ${filterMode === 'pending' ? 'var(--acc)' : '#2a3550'}`,
+            background: filterMode === 'pending' ? 'var(--acc)22' : '#161b2e',
+            color: filterMode === 'pending' ? 'var(--acc)' : '#8899aa', cursor: 'pointer',
+          }}>未处理</button>
+          <span style={{ fontSize: 10, color: 'var(--muted)' }}>{filterMode === 'pending' ? displayed.length : tasks.length} 条</span>
         </div>
 
         {/* 事件列表 */}
@@ -130,7 +169,7 @@ export default function ToolchainPanel() {
               {loading ? '加载中...' : '暂无工具链事件'}
             </div>
           )}
-          {tasks.map((t: any) => (
+          {displayed.map((t: any) => (
             <div key={t.id} onClick={() => setSelectedId(t.id)} style={{
               padding: '10px 14px', borderBottom: '1px solid var(--line)',
               cursor: 'pointer', transition: 'background .15s',
@@ -151,6 +190,9 @@ export default function ToolchainPanel() {
                 fontSize: 12, fontWeight: 500, color: '#dde4f8',
                 overflow: 'hidden', textOverflow: 'ellipsis', whiteSpace: 'nowrap',
               }}>{t.title}</div>
+              <div style={{ fontSize: 10, color: 'var(--muted)', marginTop: 2 }}>
+                {AGENT_NAMES['system'] || '系统'} → {AGENT_NAMES[t.assignee] || t.assignee || '?'}
+              </div>
             </div>
           ))}
         </div>
@@ -174,6 +216,9 @@ export default function ToolchainPanel() {
                 <span style={{ fontSize: 10, color: 'var(--muted)' }}>{detail.id}</span>
               </div>
               <div style={{ fontSize: 18, fontWeight: 700, lineHeight: 1.3 }}>{detail.title}</div>
+              <div style={{ fontSize: 11, color: 'var(--muted)', marginTop: 4 }}>
+                {AGENT_NAMES['system'] || '系统'} → {AGENT_NAMES[detail.assignee] || detail.assignee || '?'}
+              </div>
               <div style={{ fontSize: 12, color: 'var(--muted)', marginTop: 6 }}>
                 {fmtTime(detail.created_at)}
               </div>

src/frontend/src/store.ts

@@ -120,7 +120,7 @@ export function isArchived(t: Task): boolean {
 export type TabKey =
   | 'tasks' | 'court' | 'monitor' | 'agents'
   | 'models' | 'skills' | 'sessions' | 'archives' | 'templates'
-  | 'usage' | 'settings' | 'officials' | 'morning' | 'mail' | 'toolchain';
+  | 'usage' | 'settings' | 'officials' | 'morning' | 'mail';
 
 export const TAB_DEFS: { key: TabKey; label: string; icon: string }[] = [
   { key: 'tasks',     label: '任务看板', icon: '📜' },
@@ -135,7 +135,6 @@ export const TAB_DEFS: { key: TabKey; label: string; icon: string }[] = [
   { key: 'archives',  label: '奏折阁',   icon: '📜' },
   { key: 'morning',   label: '早朝简报', icon: '🌅' },
   { key: 'templates', label: '任务模板', icon: '📋' },
-  { key: 'toolchain', label: '工具链',   icon: '⛓️' },
   { key: 'settings',  label: '系统设置', icon: '⚙️' },
 ];
 

tests/integration/test_ticker_integration.py

@@ -543,3 +543,94 @@ class TestCheckTimeoutsUnified:
         reclaimed = ticker._check_timeouts(db_path)
 
         assert "t-review-dead" not in reclaimed
+
+
+# ---------------------------------------------------------------------------
+# E13: §15 Runaway Guard — per-task dispatch_count 上限
+# ---------------------------------------------------------------------------
+
+class TestRunawayGuard:
+    """E13: dispatch_count >= 10 → 自动标 failed（覆盖所有非终态）"""
+
+    @pytest.fixture
+    def guard_project(self, tmp_path):
+        """创建项目 + 任务"""
+        data_root = tmp_path / "projects"
+        registry = ProjectRegistry(data_root)
+        registry.create_project("guard-proj", "Guard Test", agents=["agent-a"])
+        db_path = data_root / "guard-proj" / "blackboard.db"
+        bb = Blackboard(db_path)
+        return registry, db_path, bb
+
+    def test_runaway_guard_triggers_working(self, guard_project):
+        """E13.1: working 状态 dispatch_count >= 10 → 标 failed"""
+        registry, db_path, bb = guard_project
+
+        bb.create_task(Task(
+            id="t-runaway", title="Runaway Task", status="working",
+            assigned_by="daemon", current_agent="agent-a",
+        ))
+
+        conn = bb._conn()
+        try:
+            conn.execute(
+                "UPDATE tasks SET dispatch_count = 10 WHERE id = ?", ("t-runaway",))
+            conn.commit()
+        finally:
+            conn.close()
+
+        ticker = Ticker(registry, tick_interval=30)
+        reclaimed = ticker._check_timeouts(db_path)
+
+        assert "t-runaway" in reclaimed
+        task = Queries(db_path).task_by_id("t-runaway")
+        assert task.status == "failed"
+
+    def test_runaway_guard_triggers_pending(self, guard_project):
+        """E13.2: pending 状态 dispatch_count >= 10 → 标 failed"""
+        registry, db_path, bb = guard_project
+
+        bb.create_task(Task(
+            id="t-pending-runaway", title="Pending Runaway", status="pending",
+            assigned_by="daemon",
+        ))
+
+        conn = bb._conn()
+        try:
+            conn.execute(
+                "UPDATE tasks SET dispatch_count = 10 WHERE id = ?",
+                ("t-pending-runaway",))
+            conn.commit()
+        finally:
+            conn.close()
+
+        ticker = Ticker(registry, tick_interval=30)
+        reclaimed = ticker._check_timeouts(db_path)
+
+        assert "t-pending-runaway" in reclaimed
+        task = Queries(db_path).task_by_id("t-pending-runaway")
+        assert task.status == "failed"
+
+    def test_runaway_guard_not_triggered(self, guard_project):
+        """E13.3: dispatch_count < 10 → 正常流程不受影响"""
+        registry, db_path, bb = guard_project
+
+        bb.create_task(Task(
+            id="t-normal", title="Normal Task", status="working",
+            assigned_by="daemon", current_agent="agent-a",
+        ))
+
+        conn = bb._conn()
+        try:
+            conn.execute(
+                "UPDATE tasks SET dispatch_count = 5 WHERE id = ?", ("t-normal",))
+            conn.commit()
+        finally:
+            conn.close()
+
+        ticker = Ticker(registry, tick_interval=30)
+        reclaimed = ticker._check_timeouts(db_path)
+
+        assert "t-normal" not in reclaimed
+        task = Queries(db_path).task_by_id("t-normal")
+        assert task.status == "working"

tests/unit/test_toolchain_handler_v2.py

@@ -523,3 +523,73 @@ class TestFullPromptBuild:
         # Must have constraints with Red Flags
         assert "Red Flags" in prompt
         assert "强制要求" in prompt
+
+
+# ---------------------------------------------------------------------------
+# §17 v2: CI/deploy failure branching + issue label routing + Issue API guidance
+# ---------------------------------------------------------------------------
+
+class TestCiFailureBranching:
+    """ci_failure steps should include a/b branching guidance."""
+
+    def test_ci_failure_steps_contain_branching(self):
+        source_file = PROJECT_ROOT / "src" / "api" / "toolchain_routes.py"
+        source = source_file.read_text()
+        assert '基础设施问题' in source
+        assert 'type/infrastructure' in source
+        assert 'jiangwei-infra' in source
+
+
+class TestDeployFailureBranching:
+    """deploy_failure steps should include a/b branching guidance."""
+
+    def test_deploy_failure_steps_contain_branching(self):
+        source_file = PROJECT_ROOT / "src" / "api" / "toolchain_routes.py"
+        source = source_file.read_text()
+        count = source.count('基础设施问题（Gitea 不可用')
+        assert count >= 2, f'Expected >=2 deploy_failure branching, found {count}'
+
+
+class TestIssueAssignedLabelRouting:
+    """issue_assigned handler should route by type/infrastructure label."""
+
+    def test_label_check_in_source(self):
+        source_file = PROJECT_ROOT / "src" / "api" / "toolchain_routes.py"
+        source = source_file.read_text()
+        assert 'is_infrastructure' in source
+        assert 'infrastructure_failure' in source
+        assert '基础设施 Issue' in source
+
+    def test_normal_issue_keeps_coding_steps(self):
+        source_file = PROJECT_ROOT / "src" / "api" / "toolchain_routes.py"
+        source = source_file.read_text()
+        assert '创建分支 fix/' in source
+        assert 'issue_assigned' in source
+
+
+class TestToolchainApiIssueGuidance:
+    """ToolchainApiSection should include Issue creation guidance."""
+
+    def test_has_issue_creation_section(self):
+        source_file = PROJECT_ROOT / "src" / "daemon" / "toolchain_handler.py"
+        source = source_file.read_text()
+        assert "需要创建 Issue 时" in source
+        assert "/issues" in source
+        assert "jiangwei-infra" in source
+        assert "type/infrastructure" in source
+
+    def test_issue_body_template_mentions_required_fields(self):
+        source_file = PROJECT_ROOT / "src" / "daemon" / "toolchain_handler.py"
+        source = source_file.read_text()
+        assert "错误来源" in source
+        assert "判断依据" in source
+
+
+class TestRedFlagsInfrastructure:
+    """Red Flags should include the 'not my code' entry."""
+
+    def test_has_infrastructure_red_flag(self):
+        source_file = PROJECT_ROOT / "src" / "daemon" / "toolchain_handler.py"
+        source = source_file.read_text()
+        assert "不是我代码的问题" in source
+        assert "基础设施问题" in source