# 课题4 设计方案：智能拆解机制 + Skill 体系工程落地

**作者**: 庞统士元
**日期**: 2026-05-15
**状态**: 方案待确认
**前置**: 课题1/2/3 已结题
**调研报告**: `docs/research/v2.6-research-04-decomposition-skills.md`

---

## Part A：智能拆解机制

### 1. 设计目标

v1.0 的拆解是"关键词匹配 → 固定 DAG 模板"，问题是：
- 模板太死板（5个固定DAG），无法根据需求动态调整
- 关键词匹配粗糙，复杂需求容易匹配错模板
- 庞统拆解时靠 LLM 理解，没有结构化引导

课题4要解决：**庞统收到用户需求后，如何把它变成黑板上的任务（含依赖关系、角色分配、风险等级）。**

### 2. 和课题1/2/3的关系

课题1-3 已经定义了"任务在黑板上长什么样"（tasks 表 schema、状态机、reviews 表、Guardrail 配置）。课题4定义的是"任务怎么被创建出来"。

```
课题4（创建） → 课题2（触发执行） → 课题3（审查） → 课题1（失败处理）
```

### 3. 设计决策

#### D4-1：模板组件库替代固定 DAG

> **参考实践**：
> - **MetaGPT**：SOP 自动链 + `_watch` 声明式订阅，不是固定 DAG
> - **get-shit-done**：discuss→plan→execute→verify→ship 五阶段，但每阶段内部灵活
> - **open-multi-agent**：Goal → DAG 自动分解，按 complexity 决定粒度
> - **v1.0**：5 个固定模板（full_role_development / circular_review_test / multi_stage_review / data_acquisition / multi_edge_discussion）

**方案**：不是 5 个完整 DAG，而是**模板组件库（Phase Components）**。庞统按需组合。

```yaml
# template_components.yaml
components:
  research:
    trigger: "需要调研/分析"
    mandatory: false
    steps:
      - id: lit_search
        name: "资料调研"
        agent: zhaoyun-data
        output: "research_report.md"
      - id: analysis
        name: "分析总结"
        agent: pangtong-fujunshi
        output: "analysis.md"

  design:
    trigger: "需要架构/设计"
    mandatory: false
    steps:
      - id: arch_design
        name: "架构设计"
        agent: pangtong-fujunshi
        output: "design.md"
      - id: design_review
        name: "设计评审"
        agent: simayi-challenger
        review_type: plan_review

  coding:
    trigger: "需要编码/实现"
    mandatory: false
    steps:
      - id: implement
        name: "编码实现"
        agent: zhangfei-dev
        output: "code/"
      - id: code_review
        name: "代码评审"
        agent: simayi-challenger
        review_type: output_review

  data:
    trigger: "需要数据获取/处理"
    mandatory: false
    steps:
      - id: data_acquire
        name: "数据获取"
        agent: zhaoyun-data
        output: "data/"
      - id: data_validate
        name: "数据验证"
        agent: zhaoyun-data

  deploy:
    trigger: "需要部署"
    mandatory: false
    steps:
      - id: deploy
        name: "部署"
        agent: jiangwei-infra
        output: "deploy_log.md"
      - id: deploy_verify
        name: "部署验证"
        agent: jiangwei-infra

  risk_control:
    trigger: "涉及实盘/资金/策略"
    mandatory: true  # 触发条件满足时强制包含
    steps:
      - id: risk_check
        name: "风控检查"
        agent: guanyu-dev

  review:
    trigger: "always"
    mandatory: true  # 铁律 IR-1
    steps:
      - id: final_review
        name: "最终审查"
        agent: simayi-challenger
        review_type: final_review

  custom:
    trigger: "none"  # 不自动触发，庞统主动选择
    description: "庞统自由定义的 phase，结构与标准组件相同"
    steps: []  # 空的，庞统运行时填充
```

**custom 组件接口**：与标准组件同 schema（steps 列表，每个 step 有 id/name/agent/output/review_type）。Plan Checker 对 custom 组件的验证和标准组件相同——检查覆盖性、依赖性、粒度、铁律。唯一区别是 custom 不从库中引用，而是庞统在 Step 2 中自由定义。
```

**庞统的拆解流程**：

```
Step 1：需求结构化
  - 分析用户输入，提取需求列表
  - 每个需求标注类型（数据/编码/分析/部署/风控）
  - 评估复杂度（简单/中等/复杂）
  - 隐含需求挖掘（如用户说"回测"→ 隐含需要数据获取）
  - 产出：structured_requirements → 写入黑板 decisions 表

Step 2：组件选择 + 组合
  - 根据需求类型，从组件库选择需要的 phases
  - 检查 mandatory 组件是否被遗漏
  - 组合 phases，排列依赖关系
  - AI 增强：增删调整（如"这次数据已有，跳过 data_acquire"）
  - 产出：draft_plan → 写入黑板 decisions 表

Step 3：Plan Checker 验证
  - 独立验证（不是庞统自己验证自己）
  - 检查项：
    - 覆盖性：每个需求是否被至少一个 step 覆盖
    - 依赖性：step 依赖是否合理（无环、无遗漏前置）
    - 粒度性：step 是否过大/过小
    - 铁律：IR-1（每任务至少2 Agent）是否满足
    - 风险：risk_level 是否合理，高风险任务是否有对抗审查
  - 不通过 → 回 Step 2 调整（最多 2 轮）
  - 2 轮不通过 → 庞统带着 Plan Checker issues 创建任务，标注 risk_level=high，由审查者在 plan_review 阶段进一步验证。不升级用户（庞统能处理）
  - 通过 → 进入 Step 4

Step 4：任务创建
  - 将 plan 转为黑板 tasks
  - 每个 step → 一个 task（含 truths / artifacts / constraints / risk_level / assigned_to）
  - 依赖关系 → tasks 的 depends_on 字段
  - 庞统在黑板上写 scope_declaration
  - 产出：tasks 写入黑板 → Daemon 检测 → 开始执行
```

#### D4-2：需求结构化的输出格式

庞统分析用户需求后，输出结构化需求到黑板：

```json
{
  "original_input": "实现一个双均线策略的回测",
  "requirements": [
    {
      "id": "req-001",
      "description": "获取标的分钟线数据",
      "type": "data",
      "acceptance_criteria": "数据文件存在于 NAS 指定路径",
      "complexity": "simple",
      "implicit": true
    },
    {
      "id": "req-002",
      "description": "编写双均线策略逻辑",
      "type": "coding",
      "acceptance_criteria": "策略代码通过单元测试",
      "complexity": "medium",
      "implicit": false
    },
    {
      "id": "req-003",
      "description": "回测并生成报告",
      "type": "analysis",
      "acceptance_criteria": "回测报告包含收益曲线和关键指标",
      "complexity": "medium",
      "implicit": false
    }
  ],
  "inferred_components": ["data", "coding", "analysis"],
  "risk_level": "standard",
  "estimated_tasks": 3
}
```

#### D4-3：Plan Checker 独立验证

> **参考实践**：
> - **superpowers**：plan-document-reviewer subagent 独立验证方案
> - **oh-my-claudecode Critic**：预判→验证→自审五阶段
> - **get-shit-done**：Scope Reduction Detection（完成后反向检查覆盖）

Plan Checker 是一个 Subagent（不需要 Agent 身份），Daemon spawn 后执行：

```yaml
# review_protocols/plan_check.yaml
name: plan_check
description: "验证庞统的拆解方案是否合理"

dimensions:
  - id: coverage
    description: "每个需求是否被至少一个 task 覆盖"
    weight: critical
    method: "需求 ID → task ID 映射矩阵，检查是否有遗漏"

  - id: dependency
    description: "依赖是否合理"
    weight: critical
    method: "拓扑排序检查无环，前置是否完整"

  - id: granularity
    description: "粒度是否合适"
    weight: major
    method: "检查每个 task 的 truths 是否是一个 Agent 一次 spawn 能完成的"

  - id: iron_rules
    description: "铁律是否满足"
    weight: critical
    method: "IR-1: 至少 2 Agent 参与；IR-2: 每个 task 有 truths"

  - id: risk_alignment
    description: "风险等级是否合理"
    weight: major
    method: "涉及资金/部署 → high；纯分析 → research"

output_schema: "schemas/plan-check-output.schema.json"
verdict_options: ["approved", "needs_revision"]
```

#### D4-4：复杂度驱动的粒度控制

> **参考实践**：
> - **open-multi-agent**：按 complexity 决定是否拆分子任务
> - **wanman**：Token 预算控制执行深度

| 复杂度 | 判断标准 | 拆解策略 | truths 定义 |
|--------|---------|---------|------------|
| **simple** | 单一文件、单一操作、< 50 行 | 1 个 task | 1-2 条 truths |
| **medium** | 多文件、有依赖、需要验证 | 1-3 个 task + 依赖 | 每个 2-3 条 truths |
| **complex** | 跨模块、多角色、需要调研 | 多 phase 组件组合 | 每个 3-5 条 truths |

**粒度自检规则**（庞统的 Skill 中定义）：
- 一个 task 的 truths > 5 条 → 拆分
- 一个 task 需要跨 3+ 角色 → 拆分
- 一个 task 预计 > 30 分钟 → 拆分

#### D4-5：用户确认点

> **参考实践**：
> - **get-shit-done**：discuss phase 是必须的用户确认步骤
> - **v2.0 PRD**：Phase 1 需求探索（苏格拉底对话）

不是每步都问用户，但在关键节点确认：

| 检查点 | 触发条件 | 用户看到什么 |
|--------|---------|------------|
| 需求确认 | Step 1 完成后 | 结构化需求列表 + 隐含需求 |
| 方案确认 | Step 2 完成后（complex 任务） | 任务列表 + 依赖关系 + 预估时间 |

simple 任务跳过方案确认，直接创建。complex 任务必须确认。

**用户干预三种模式**（来源：2026 human-in-the-loop 综述 + OpenAI Agents SDK）：

| 模式 | 机制 | 适用 |
|------|------|------|
| 审批式 | Agent 暂停等用户确认 | high 任务方案确认、部署前 |
| 通知式 | 推送消息，用户可回复可不回复 | standard 任务产出审查后 |
| 中断式 | Agent 主动问用户 | 歧义需求、争议仲裁 |

**当前落地**：通过庞统 session（webchat/Signal）。**未来**：dashboard Checkpoint 面板。

**干预点由 risk_level 动态决定**：low→无干预、standard→通知式、high→审批式、用户随时可中断。

---


## Part B：Skill 体系工程落地

### 4. 设计目标

三个课题产出了大量"Agent 需要知道怎么做"的内容（28 项 Skill TODO），需要一个系统的 Skill 体系来承载。

### 5. 核心洞察：被动触发不可靠

> **问题**：我们写了好多个 Skill，但除了用户明文指定"用 PAV""用 delegation"，几乎没见哪个 Skill 被主动触发过。
>
> **根因**：Agent 不知道自己不知道什么。OpenClaw 的 Skill 列表注入 system prompt 后，Agent 需要自己判断需要哪个——但 Agent 根本不知道"我应该先读一个 Skill 来学怎么做"。
>
> **优秀实践验证**：superpowers / GSD / open-multi-agent 没有一个是靠被动 Skill 触发的——全部是编排器构造好 prompt 直接注入。

**结论**：moziplus 的关键操作规范不走被动 Skill 发现，走引擎注入。

### 5.1 铁律定义（L0 内容）

铁律是**所有 Agent 共享的**强制规则，不可定制。角色追加的规则放在 L1（SOUL.md）。

| 编号 | 铁律 | 来源 |
|------|------|------|
| IR-1 | 每个任务至少 2 个 Agent 参与（做 + 挑战） | v1.0 PRD |
| IR-2 | 每个 task 必须有 truths（可观测行为标准） | 课题1 must_haves |
| IR-3 | 结论必须有证据（file:line 或具体引用） | oh-my-claudecode Critic |
| IR-4 | 语义含糊先确认，不擅自执行 | SOUL.md 底线 |
| IR-5 | 改代码先改文档（需求→设计→测试→部署） | v1.0 实践 |

**Token 估算**：5 条铁律，每条 ~30 token（编号+一句话），总计 ~150 token + XML 包装 ~50 token = **~200 token**。加上角色追加（L1 SOUL.md 已计入），L0 预算 ~200-300 token，远低于 ~500 上限。

### 6. 设计决策

#### D4-6：四层上下文架构

> **参考实践**：
> - **superpowers**：每个 subagent 有独立 prompt 模板（implementer-prompt.md / spec-reviewer-prompt.md），模板里写死操作步骤
> - **open-multi-agent**：`buildTaskPrompt()` 拼 task title + description + 依赖产出 + messages
> - **GSD**：每个 executor 拿到 PLAN.md + PROJECT.md + STATE.md + CONTEXT.md，按 context window 大小自适应
> - **OpenClaw**：Hook `agent_turn_prepare` 可注入 prependContext/appendContext

共同模式：**操作规范（模板）+ 项目背景（固定）+ 任务上下文（动态）**，编排器拼装，不靠 Agent 自己找。

```
┌─────────────────────────────────────────────────────────────┐
│ Layer 0: 铁律（Iron Rules）                                  │
│   机制: OpenClaw Hook agent_turn_prepare                     │
│   保证: 每轮强制注入 | Token: ~500                            │
│   内容: IR-1~IR-5（每个 Agent 可定制）                        │
├─────────────────────────────────────────────────────────────┤
│ Layer 1: 角色（Agent Identity）                               │
│   机制: SOUL.md + IDENTITY.md + AGENTS.md                    │
│   保证: 每轮强制 | Token: ~2000                               │
│   内容: 角色定义 + 行为准则 + 记忆                            │
│   变化频率: 极少（换平台不变）                                 │
├─────────────────────────────────────────────────────────────┤
│ Layer 2: 操作规范 + 任务上下文（引擎注入）                     │
│   机制: Daemon spawn 时拼装 bootstrap 消息                    │
│   保证: 每次 spawn 强制注入 | Token: ~1000-2000              │
│   三段式：                                                    │
│   ① 角色操作规范模板（executor.md / reviewer.md / planner.md）│
│      → 固定部分，写死关键操作步骤（scope/output/handoff等）   │
│      → 变化频率: 很少（moziplus 平台变了才改）                │
│   ② 项目背景（项目路径/框架/NAS/回测服务）                    │
│      → 半固定部分，按项目配置                                 │
│   ③ 任务上下文（truths/artifacts/constraints + depends_on产出）│
│      → 动态部分，每次 spawn 不同                              │
├─────────────────────────────────────────────────────────────┤
│ Layer 3: 参考信息（OpenClaw Skill 被动发现）                  │
│   机制: OpenClaw Skill 列表注入 system prompt                │
│   保证: ❌ 不保证触发（锦上添花）                              │
│   内容: 具体操作方法（回测流程/数据获取/部署步骤等）          │
│   优化: description 中加触发场景+示例对话+触发词（见D4-8）    │
└─────────────────────────────────────────────────────────────┘
```

**张飞编码时靠什么**：
- L0+L1：身份和纪律（每轮都有）
- L2 ① executor.md："读黑板→写scope→执行→写output→写Handoff"（引擎注入，不会忘）
- L2 ③ 任务上下文："这次要做什么、truths 是什么、前序产出是什么"（引擎注入）
- L3 quant-backtest Skill：具体回测代码怎么写（自己判断要不要读）

#### D4-7：L2 引擎注入的拼装原则

> **参考实践**：
> - **superpowers**：implementer/spec-reviewer/code-quality-reviewer 三个独立 prompt 模板，只包含该角色需要的信息
> - **open-multi-agent**：`buildTaskPrompt()` 只注入依赖链上的产出（default-deny），不是全量
> - **GSD**：按 context window 大小自适应（200K 只给任务级，1M 给全量）

**原则：按角色和任务阶段精确注入，不统一拼装，不多不少。**

| Agent 角色 | 注入内容 | 不注入 |
|-----------|---------|--------|
| **执行者** | executor.md + Guardrail 配置 + 任务上下文 | Review Protocol |
| **审查者** | reviewer.md + Review Protocol + required_reading | Guardrail 配置 |
| **庞统（规划）** | planner.md + template_components + Plan Checker | Review Protocol |
| **庞统（裁决）** | adjudicator.md + 正方 comment + 反方 comment | Guardrail 配置 |
| **反驳者** | rebuttal.md + 审查者 review + ACCEPT/REJECT 指令 | Review Protocol |
| **Plan Checker** | plan_checker.md + 需求列表 + 拆解方案 | 全部角色模板 |

**拼装逻辑**（Daemon 代码）：
```python
def build_bootstrap(agent_id, role, task):
    parts = []
    
    # ① 角色操作规范模板
    template = load_template(f"prompt_templates/{role}.md")
    parts.append(template)
    
    # ② 项目背景（半固定）
    parts.append(format_project_context(task))
    
    # ③ 任务上下文（动态）
    parts.append(format_task_context(task))
    
    # 按角色追加（只注入该角色需要的）
    if role == "executor":
        parts.append(format_guardrails(task.task_type))
    elif role == "reviewer":
        parts.append(format_review_protocol(task.review_type))
        parts.append(format_required_reading(task))
    elif role == "planner":
        parts.append(format_template_components())
    elif role == "rebuttal":
        parts.append(format_review_to_respond(task))
    
    return "\n\n".join(parts)
```

#### D4-8：L3 Skill 被动触发的优化写法

> **参考实践**：
> - **superpowers code-reviewer**：description 里嵌入 `<example>` 标签，用对话示例教 Agent 触发场景
> - **wiki-query**：description 里加 Chinese/English triggers 列表
> - **gstack plan-design-review**：加 `Proactively suggest when...` 指令
> - **SkillRouter 论文**（2026）：Agent 自主搜索（agentic）比纯关键词/纯语义准确率最高

即使 L3 不保证触发，也要优化写法提高命中率。**moziplus 的 Skill 全部按以下规范写 description**：

```yaml
---
name: quant-backtest
description: >
  标准化量化回测技能。
  
  When to use: 当需要回测量化策略、验证策略历史表现、测试策略参数时。
  
  Chinese triggers: 回测、backtest、策略测试、历史表现验证、参数优化。
  English triggers: backtest, strategy test, historical performance, parameter optimization.
  
  Proactively suggest when: 用户提到策略实现完成后，主动建议运行回测验证。
  
  Example: user says "帮我测一下双均线策略" → use quant-backtest skill.
---
```

**description 四要素**：
1. **功能描述**：这个 Skill 干什么
2. **触发场景**（When to use）：什么情况下该用
3. **触发词**（Chinese/English triggers）：中英文关键词
4. **主动建议**（Proactively suggest）：Agent 看到相关场景时主动推荐

#### D4-9：Skill 诚实边界

> **参考实践**：nuwa-skill Agentic Protocol 要求每个 Skill 声明自己做不到什么

每个 Skill 必须包含 `## 诚实边界` section：

```markdown
## 诚实边界
- 本 Skill 不覆盖实盘交易逻辑（实盘请参考 live-trading Skill）
- 性能问题需要实际测试数据，纯代码审查无法确认
- 复杂策略可能需要拆分为多个 task
```

#### D4-10：moziplus 目录结构

```
sanguo_moziplus/
  prompt_templates/              ← L2 ① 角色操作规范（Daemon 读取拼装）
    executor.md                  ← 执行者操作步骤（读黑板→scope→执行→output→handoff）
    reviewer.md                  ← 审查者操作步骤（读Protocol→审查→写review）
    planner.md                   ← 庞统拆解步骤（需求结构化→组件选择→PlanChecker）
    adjudicator.md               ← 庞统裁决步骤（正方反方→判断→写决策）
    rebuttal.md                  ← 反驳步骤（读review→ACCEPT/REJECT/PARTIAL）
    plan_checker.md              ← Plan Checker 步骤（覆盖性→依赖→粒度→铁律）
  
  review_protocols/              ← L2 审查协议（Daemon 构造 reviewer bootstrap 时读取）
    plan_review.yaml             ← 方案审查协议
    output_review.yaml           ← 产出审查协议
    guardrail_l2.yaml            ← L2 轻量AI检查协议
    analysis_review.yaml         ← 分析审查协议
    plan_check.yaml              ← Plan Checker 协议
  
  schemas/                      ← CLI 层 Schema 校验（blackboard.py 读取）
    handoff.schema.json          ← Handoff 格式校验
    output.schema.json           ← Output 格式校验
    decide.schema.json           ← Decision 格式校验
    observe.schema.json          ← Observation 格式校验
    review-output.schema.json    ← Review 格式校验
  
  template_components.yaml      ← 模板组件库（庞统拆解时参考）
  guardrails.yaml               ← 声明式 Guardrail（Daemon 执行检查）
  project_context.yaml          ← L2 ② 项目背景（NAS路径/回测服务/框架）
```

**各目录作用**：

| 目录/文件 | 谁读 | 作用 | 变化频率 |
|----------|------|------|----------|
| `prompt_templates/` | Daemon | 按 Agent 角色拼装 bootstrap 消息 | 很少变 |
| `review_protocols/` | Daemon | 构造审查者的 bootstrap 消息 | 偶尔变 |
| `schemas/` | blackboard.py CLI | 写入时校验数据格式 | 偶尔变 |
| `template_components.yaml` | 庞统（通过 L2 注入） | 拆解需求时选择组件 | 偶尔变 |
| `guardrails.yaml` | Daemon | 自动检查产出 | 偶尔变 |
| `project_context.yaml` | Daemon | 拼装项目背景信息 | 换项目时变 |

**注意**：Agent 不直接读这些文件——全部由 Daemon 读取后拼装到 bootstrap 消息中注入。

#### D4-11：L2 引擎注入示例（张飞编码场景）

Daemon spawn 张飞时拼装的完整 bootstrap 消息：

```
═══ 操作规范（executor.md 模板）═══

你是任务执行者。按以下步骤工作：

## 1. 理解任务
- 读黑板任务详情（blackboard.py read --task {task_id}）
- 理解 truths（可观测行为标准）、artifacts（必须产出）、constraints（约束）

## 2. 声明范围
- 写 scope_declaration（blackboard.py decide --task {task_id} --decider zhangfei-dev）
- 格式：{"decision": "我计划做什么", "rationale": "为什么", "artifacts": ["路径"]}

## 3. 执行工作
- 按你的专业能力完成任务
- 发现风险 → blackboard.py observe --task {task_id} --severity warning
- 需要协作 → blackboard.py comment --task {task_id} @mention

## 4. 提交产出
- blackboard.py output --task {task_id} --summary "一句话" --content-path "文件路径"

## 5. 写交接
- blackboard.py comment --task {task_id} --author zhangfei-dev \
  --handoff '{"completed":"...", "artifacts":["..."]}'

## 6. 通知引擎
- 写 inbox 文件通知 Daemon 完成

═══ 项目背景（project_context.yaml）═══

项目：sanguo_quant_live
框架：vnpy
NAS 数据：/Volumes/stock/
回测服务：http://192.168.2.154:8088
编码规范：类型注解必须、禁止 any、match 现有风格

═══ 任务上下文（黑板动态读取）═══

任务 ID: task-001
任务标题: 实现双均线策略
truths: ["策略代码通过单元测试", "回测结果包含收益曲线"]
artifacts: ["task-001/strategy.py", "task-001/backtest_report.pdf"]
constraints: ["使用 vnpy 框架", "不超过 500 行"]
risk_level: standard

═══ 前序信息（depends_on 产出）═══

[赵云 Handoff] 完成了分钟线数据下载，产出 task-000/data/
数据路径: /Volumes/stock/min_data/IF888.csv

═══ 可选参考 ═══

如果需要具体操作方法，用 read 加载：
- 编码：~/.openclaw/skills/coding-implementation/SKILL.md
- 回测：~/.openclaw/skills/quant-backtest/SKILL.md
```

**对比审查者（司马懿）收到的 bootstrap**：

```
═══ 操作规范（reviewer.md 模板）═══

你是质量审查者。按 Review Protocol 执行审查：

## 审查步骤
1. 预判：先不读产出，预测 3-5 个最可能出问题的点
2. 验证：读实际产出（不是报告），逐条验证每个 truth
3. 多视角：从安全/新人/运维三个角度看产出
4. 缺口分析：不只看"什么有问题"，还看"什么缺失了"
5. 自审：给每个 finding 打 confidence，低 confidence 降级

## 写 Review
- blackboard.py review --task {task_id} --verdict [approved|rejected|needs_revision] ...

[... 对抗性指令 ...]

═══ Review Protocol（output_review.yaml）═══

[审查维度、方法、输出 Schema 等详细协议内容]

═══ 任务上下文 ═══
[同上]

═══ Required Reading ═══
- 执行者 scope_declaration: ...
- 产出物: task-001/strategy.py
- must_haves truths: [...]
```

---

## 7. 和现有设计的对齐检查

| 已有设计 | 课题4 补充 | 一致性 |
|---------|-----------|--------|
| §3.2 tasks 表 schema | D4-1 模板组件输出 → tasks 写入 | ✅ truths/artifacts/constraints/risk_level/depends_on 对齐 |
| §9.2 分级审查矩阵 | D4-4 复杂度→粒度控制 | ✅ risk_level 在创建时标注 |
| §4.2 Tick+Inbox | D4-1 Step 4 创建任务后 Daemon tick 检测 | ✅ 创建是事件源 |
| §9.4 Review Protocol Registry | D4-10 review_protocols/ 目录 | ✅ Daemon 构造审查者 bootstrap 时读取 |
| §9.9 Agent vs Subagent | D4-3 Plan Checker 走 Subagent | ✅ 无身份一次性检查 |
| Skill TODO 28项 | D4-10 prompt_templates/ 承载关键操作 | ✅ S-01~S-28 的关键操作写死在模板中 |

## 8. 遗留 TODO

| # | 待解决事项 | 归属 | 说明 |
|---|----------|------|------|
| ~~T4-1~~ | ~~template_components.yaml 完整定义~~ | ~~Phase 2~~ | ✅ 方案已定，开发实现 |
| ~~T4-2~~ | ~~Plan Checker 的 plan_check.yaml 实现~~ | ~~Phase 2~~ | ✅ 方案已定，开发实现 |
| ~~T4-3~~ | ~~prompt_templates/ 编写~~ | ~~Phase 1~~ | ✅ 方案已定，开发实现 |
| ~~T4-4~~ | ~~project_context.yaml 定义~~ | ~~Phase 1~~ | ✅ 方案已定，开发实现 |
| ~~T4-5~~ | ~~Daemon build_bootstrap() 拼装逻辑~~ | ~~Phase 1~~ | ✅ 方案已定，开发实现 |
| ~~T4-6~~ | ~~铁律 Hook 实现（L0）~~ | ~~Phase 1~~ | ✅ 方案已定，开发实现 |
| ~~T4-7~~ | ~~现有 Skill description 优化（加四要素）~~ | ~~Phase 2~~ | ✅ 方案已定，开发实现 |
| ~~T4-8~~ | ~~Skill 诚实边界补充~~ | ~~Phase 2~~ | ✅ 方案已定，开发实现 |
| ~~T4-9~~ | ~~Skill 测试框架~~ | ~~Phase 3~~ | ➡️ 移至工具链课题（开发工具链的一部分，不属于拆解机制） |
| ~~T4-10~~ | ~~Skill 进化/蒸馏机制~~ | ~~Phase 3~~ | ➡️ 合并进课题6（经验→Skill的进化是经验沉淀闭环，课题6已有两级蒸馏+Skill生命周期） |