name: loom-plan-writer description: 创建Loom执行计划的必需技能。设计基于DAG的计划，包含强制性的知识引导和集成验证书挡，阶段内并行子代理执行，以及并发工作树阶段以实现最大吞吐量。触发关键词：loom、计划、阶段、工作树、编排、并行执行、并行阶段、并发执行、知识引导、集成验证、验收标准、信号、交接、执行图、dag、依赖、loom计划、创建计划、编写计划、执行计划、编排计划、阶段依赖、并行子代理、功能验证、布线验证、冒烟测试。 allowed-tools: Read, Grep, Glob, Write, Edit
Loom计划编写器
概述
这是创建Loom执行计划的必需技能。
当任何代理需要为Loom编排创建计划时，必须调用此技能。此技能确保：
- 正确的计划结构，包含强制性的
知识引导（第一个）和集成验证（最后一个）阶段 - 正确的YAML元数据格式（3个反引号，无嵌套代码围栏）
- 并行化策略（阶段内子代理优先，单独阶段次之）
- 功能验证要求（测试通过≠功能工作）
- 符合所有CLAUDE.md规则的计划编写
计划通过两个级别的并行化最大化吞吐量：阶段内子代理（第一优先级）和并发工作树阶段（第二优先级）。
指令
1. 输出位置
强制性： 将所有计划写入：
doc/plans/PLAN-<描述>.md
切勿写入~/.claude/plans/或任何.claude/plans路径。
2. 预计划：在编写前探索
问题： 跳过探索 → 重复代码、重用差、模式不一致。
解决方案： 在计划前始终探索：
| 步骤 | 操作 | 原因 |
|---|---|---|
| 1 | 生成相关模块的探索子代理 | 找到要重用的模式 |
| 2 | 审查doc/loom/knowledge/*.md |
从过去错误中学习 |
| 3 | 创建带有"REUSE:"注释的任务列表 | 显式跟踪重用 |
| 4 | 识别集成点 | 新代码连接的地方 |
探索子代理模板：
** 立即读取CLAUDE.md文件并遵循其所有规则。 **
## 探索任务
找到[功能区域]的现有模式。记录：
1. 要重用的类似实现
2. 适用的实用函数/模块
3. 集成点（布线位置）
4. 要遵循的约定
## 输出
以知识更新命令返回发现。
3. 预计划：沙盒配置
询问用户沙盒设置
通过询问收集沙盒要求：
-
网络访问： “此任务是否需要网络访问？哪些域名？”
- 示例：GitHub API、npm注册表、PyPI、crates.io、外部API
-
敏感路径： “任何需要保护免受代理访问的文件/目录？”
- 示例：~/.ssh、~/.aws、.env文件、credentials.json
-
构建工具： “代理需要哪些包管理器或构建工具？”
- 示例：cargo、npm/bun、pip/uv、go、docker
收集答案后：
- 运行
loom sandbox suggest获取项目特定建议 - 合并用户要求与建议
- 将
sandbox块添加到计划YAML
沙盒配置参考：
loom:
version: 1
sandbox:
enabled: true # 主开关（默认：true）
auto_allow: true # 阶段开始时自动授予权限
excluded_commands: # 豁免沙盒化的命令
- "loom"
filesystem:
deny_read: # 代理无法读取的路径
- "~/.ssh/**"
- "~/.aws/**"
- "~/.config/gcloud/**"
- "~/.gnupg/**"
deny_write: # 代理无法写入的路径
- ".work/stages/**"
- "doc/loom/knowledge/**" # 除知识/集成验证阶段外
allow_write: # 拒绝规则的例外
- "src/**"
network: # ⛔ 必须是结构体，而非字符串如"deny"
allowed_domains: [] # 空 = 拒绝所有网络（或列出允许的域名）
allow_local_binding: false
allow_unix_sockets: false
每阶段覆盖：
- id: my-stage
sandbox:
enabled: false # 仅此阶段禁用
filesystem:
allow_write:
- "build/**" # 额外写入访问
特殊阶段行为：
knowledge和integration-verify阶段自动获得写入doc/loom/knowledge/**的权限
4. 并行化策略
┌────────────────────────────────────────────────────────────────────┐
│ ⚠️ 阶段昂贵 │
│ │
│ 每个阶段创建一个git工作树，生成新会话，并 │
│ 消耗大量时间和令牌。强烈优先使用子代理 │
│ 在一个阶段内或代理团队，而非创建额外阶段。 │
│ │
│ 仅在以下情况创建单独阶段： │
│ - 任务间文件重叠（合并冲突） │
│ - 代码依赖存在（B导入A创建的代码） │
│ - 需要验证检查点（不在破损基础上构建）│
│ │
│ 如果任务触及不同文件且无依赖，在一个阶段中使用并行 │
│ 子代理。这总是比单独阶段更便宜。 │
└────────────────────────────────────────────────────────────────────┘
最大化三个级别的并行执行：
┌─────────────────────────────────────────────────────────────────────┐
│ 并行化优先级 │
│ │
│ 1. 代理团队优先 - 用于范围广泛的阶段，其中代理间 │
│ 通信增加价值（知识、 │
│ 审查、验证） │
│ │
│ 2. 子代理次之 - 在一个阶段内，用于具体任务，且 │
│ 无文件重叠和清晰分配 │
│ │
│ 3. 阶段第三 - 单独阶段用于触及相同文件或具有代码依赖性的任务 │
│ （loom合并分支） │
└─────────────────────────────────────────────────────────────────────┘
| 文件重叠？ | 需要代理间通信？ | 解决方案 |
|---|---|---|
| 否 | 否 | 相同阶段，并行子代理 |
| 否 | 是 | 相同阶段，代理团队 |
| 是 | 任何 | 单独阶段，loom合并 |
阶段特定默认：
- 知识引导：默认为团队（协调探索，研究员共享发现以相互通知）
- 标准（实现）：默认为子代理（具体文件分配，发射后不管）。仅用于广泛/探索范围时使用团队
- 集成验证：默认为团队（构建 + 功能 + 代码审查 + 知识提升任务，可能需要迭代修复）
5. 阶段描述要求
每个阶段描述必须包含此行：
使用并行子代理和技能以最大化性能。
这确保Claude Code实例为独立任务生成并发子代理。
6. 计划结构
每个计划必须遵循此结构：
┌─────────────────────────────────────────────────────────────────────┐
│ 强制性计划结构 │
│ │
│ 第一： 知识引导 （除非知识已存在） │
│ 中间： 实现阶段 （尽可能并行化） │
│ 最后： 集成验证 （始终 - 审查和验证） │
└────────────────────────────────────────────────────────────────────┘
包含可视化执行图：
[知识引导] --> [阶段-a, 阶段-b] --> [阶段-c] --> [集成验证]
[a, b]表示法中的阶段并发运行。
7. 目标逆向验证（强制性 - 已验证）
┌─────────────────────────────────────────────────────────────────────┐
│ ⚠️ 标准阶段必须具有验证字段 │
│ │
│ 每个`stage_type: standard`的阶段必须定义至少一个： │
│ │
│ • truths - Shell命令，如果行为有效则返回退出码0 │
│ • artifacts - 必须存在的文件，具有真实实现 │
│ • wiring - 证明集成的代码模式 │
│ │
│ ⛔ `loom init`拒绝违反此要求的计划 │
│ │
│ 知识阶段豁免。 │
└────────────────────────────────────────────────────────────────────┘
为什么已验证： 我们有很多次测试通过但功能从未布线的情况。这些字段捕捉到这一点。
快速参考：
| 字段 | 目的 | 示例 |
|---|---|---|
truths |
可观察行为 | "myapp --help", "curl -f localhost:8080" |
artifacts |
必须存在的文件 | "src/feature.rs", "tests/feature_test.rs" |
wiring |
集成模式 | source: "src/main.rs", pattern: "mod feature" |
8. Loom元数据格式
计划包含嵌入的YAML，包裹在HTML注释中：
<!-- loom 元数据 -->
```yaml
loom:
version: 1
stages:
- id: stage-id # 必需：唯一烤肉串大小写标识符
name: "阶段名称" # 必需：人类可读显示名称
description: | # 必需：代理的完整任务描述
此阶段必须完成的内容。
关键：使用并行子代理和技能以最大化性能。
任务：
- 子任务1和要求
- 子任务2和要求
dependencies: [] # 必需：此依赖的阶段ID数组
parallel_group: "grp" # 可选：并发执行分组
acceptance: # 必需：验证命令
- "cargo test"
- "cargo clippy -- -D warnings"
files: # 可选：目标文件通配符
- "src/**/*.rs"
working_dir: "." # 必需："."表示工作树根，或子目录如"loom"
execution_mode: team # 可选提示：single或team，代理决定
# 必需：每个阶段至少一个truths/artifacts/wiring
truths: # 可观察行为证明功能有效
- "myapp --help"
artifacts: # 必须存在的文件，具有真实实现
- "src/feature/*.rs"
wiring: # 代码模式证明集成
- source: "src/main.rs"
pattern: "use feature"
description: "功能模块已导入"
```
<!-- END loom 元数据 -->
YAML格式化规则：
┌─────────────────────────────────────────────────────────────────────┐
│ ⛔ 切勿在YAML描述内放置三重反引号 │
│ │
│ 这会破坏YAML解析器，导致验证失败，并出现 │
│ 混淆错误（例如，当truths/artifacts存在但未被解析时，显示“缺少truths/artifacts”）。 │
│ │
│ ❌ 错误： description: | │
│ 这是一个示例： │
│ ```markdown │
│ ## 标题 │
│ ``` │
│ │
│ ✅ 正确： description: | │
│ 这是一个示例： │
│ ## 标题 │
│ 内容在此（普通缩进文本） │
└────────────────────────────────────────────────────────────────────┘
| 规则 | 正确 | 不正确 |
|---|---|---|
| 代码围栏 | 3个反引号 | 4个反引棒 |
| 嵌套代码块 | 切勿在描述中 | 破坏YAML解析器 |
| 描述中的示例 | 使用普通缩进文本 | 勿使用```围栏 |
| stage_type 值 | 小写/烤肉串大小写 | PascalCase |
| 路径遍历 | 切勿使用../ |
导致验证错误 |
| 网络配置 | network: {allowed_domains: []} |
network: deny |
stage_type 字段（每个阶段必需）：
| 值 | 用于 | 特殊行为 |
|---|---|---|
knowledge |
知识引导阶段 | 可写入doc/loom/knowledge/** |
standard |
所有实现阶段 | 无法写入知识文件 |
integration-verify |
最终验证阶段 | 可写入doc/loom/knowledge/**，审查 |
切勿使用PascalCase（Knowledge、Standard、IntegrationVerify） - 解析器拒绝这些。
示例 — 在描述中显示代码的正确方式：
description: |
创建TOML格式的配置文件：
[settings]
key = "value"
切勿在YAML描述中放置三重反引号 — 它们破坏解析。
工作目录要求
working_dir字段在每个阶段必需。这强制明确选择验收标准运行的位置：
working_dir: "." # 从工作树根运行
working_dir: "loom" # 从loom/子目录运行
为什么必需？ 防止因忘记目录上下文而导致验收失败。每个阶段必须有意识地声明其执行目录。
示例：
# 项目根目录有Cargo.toml
- id: build-check
acceptance:
- "cargo test"
working_dir: "."
# 项目loom/子目录有Cargo.toml
- id: build-check
acceptance:
- "cargo test"
working_dir: "loom"
混合目录？ 创建单独阶段，而非内联cd。每个阶段 = 一个工作目录。
关键：所有路径相对于working_dir
这是常见错误。所有路径字段相对于working_dir解析：
acceptance命令artifacts文件路径wiring源路径truths命令路径
# ❌ 错误：working_dir为"loom"，但路径冗余包含"loom/"
- id: implement-feature
working_dir: "loom"
artifacts:
- "loom/src/feature.rs" # 错误：变为loom/loom/src/feature.rs
wiring:
- source: "loom/src/main.rs" # 错误：变为loom/loom/src/main.rs
pattern: "mod feature"
# ✅ 正确：路径相对于working_dir
- id: implement-feature
working_dir: "loom"
artifacts:
- "src/feature.rs" # 正确：解析为loom/src/feature.rs
wiring:
- source: "src/main.rs" # 正确：解析为loom/src/main.rs
pattern: "mod feature"
规则： 如果working_dir: "loom"，路径写如你已在loom/中。
9. 目标逆向验证详情
每个standard阶段必须至少有一个：truths、artifacts或wiring。
⛔ 这是由loom init验证的 — 如果标准阶段缺少这些字段，计划将被拒绝。
知识阶段豁免（它们有不同目的）。
这些字段验证功能实际工作，而不仅仅是测试通过：
| 字段 | 目的 | 示例 |
|---|---|---|
truths |
可观察行为证明功能有效 | "myapp --help", "curl -f localhost:8080/health" |
artifacts |
必须存在的文件，具有真实实现 | "src/auth/*.rs", "tests/auth_test.rs" |
wiring |
代码模式证明集成 | source + pattern + description |
为什么必需？ 我们有很多次测试通过但功能从未布线或功能性的情况。这些字段捕捉到这一点。
# 示例：CLI命令阶段
truths:
- "myapp new-command --help" # 命令已注册且可调用
artifacts:
- "src/commands/new_command.rs" # 实现文件存在
wiring:
- source: "src/main.rs"
pattern: "mod new_command"
description: "命令模块在main中导入"
- source: "src/cli.rs"
pattern: "NewCommand"
description: "命令在CLI中注册"
最低要求： 至少一个字段至少一个条目。对于关键阶段，越多越好。
10. 知识引导阶段（第一）
在实现前捕获代码库理解：
- id: knowledge-bootstrap
name: "引导知识库"
description: |
强制性第一阶段。读取现有doc/loom/knowledge和.work/memory文件！
使用并行子代理和技能以最大化性能。
步骤0 - 检查现有知识：
运行：loom knowledge check
审查输出以识别差距。
如果覆盖率 < 50% 或架构显示不完整：
运行：loom map --deep
这创建结构基线而不消耗你的上下文。
步骤1 - 架构映射（如果映射后仍需）：
在其他探索前，映射高级架构：
- 核心抽象及其关系
- 主要组件间的数据流
- 模块边界和依赖
- 扩展点和插件架构
- 将发现写入architecture.md
步骤2 - 并行探索（用于语义差距）：
基于loom knowledge check输出，生成探索子代理：
子代理1 - 入口点：
任务：记录CLI命令、API端点、事件处理程序
拥有文件：（只读探索）
输出：loom knowledge update entry-points "..."
子代理2 - 模式：
任务：识别错误处理、状态管理、数据流模式
拥有文件：（只读探索）
输出：loom knowledge update patterns "..."
子代理3 - 约定：
任务：记录命名、文件结构、测试模式
拥有文件：（只读探索）
输出：loom knowledge update conventions "..."
重要：将这些生成为并行Task工具调用。
关键：使用loom knowledge CLI命令，而非Write/Edit工具。
要使用的命令：
loom knowledge init # 如果未初始化
loom knowledge check # 检查现有覆盖率
loom map --deep # 如果覆盖率 < 50%
loom knowledge update architecture "## 组件
关系..."
loom knowledge update entry-points "## 部分
内容..."
loom knowledge update patterns "## 模式
内容..."
loom knowledge update conventions "## 约定
内容..."
对于长内容，使用heredoc/stdin：
loom knowledge update patterns - <<'EOF'
## 部分标题
内容在此，可任意长。
EOF
重要：完成前，审查现有mistakes.md以避免重复错误。
内存记录：
- 探索时，记录洞察：loom memory note "观察"
- 记录决策：loom memory decision "选择" --context "原因"
- 完成前：loom memory list（验证洞察捕获）
dependencies: []
acceptance:
- "loom knowledge check --min-coverage 50"
- "rg -q '## ' doc/loom/knowledge/architecture.md"
- "rg -q '## ' doc/loom/knowledge/entry-points.md"
- "rg -q '## ' doc/loom/knowledge/patterns.md"
- "rg -q '## ' doc/loom/knowledge/conventions.md"
files:
- "doc/loom/knowledge/**"
working_dir: "." # 必需："."表示工作树根
# 必需：至少一个验证字段
artifacts:
- "doc/loom/knowledge/architecture.md"
- "doc/loom/knowledge/entry-points.md"
仅跳过如果： doc/loom/knowledge/已填充且loom knowledge check显示覆盖率 ≥ 50%。
11. 集成验证阶段（最后）
验证所有工作合并后正确集成且功能实际有效：
┌─────────────────────────────────────────────────────────────────────┐
│ ⚠️ 关键：测试通过 ≠ 功能有效 │
│ │
│ 我们有很多次情况： │
│ - 所有测试通过 │
│ - 代码编译 │
│ - 但功能从未布线或功能 │
│ │
│ integration-verify必须包括功能验证： │
│ - 你能实际使用功能吗？ │
│ - 是否布线到应用程序（路由、UI、CLI）？ │
│ - 是否产生预期用户可见行为？ │
└────────────────────────────────────────────────────────────────────┘
- id: integration-verify
name: "集成验证"
description: |
最终集成验证 - 在所有功能阶段完成后运行。
使用并行子代理和技能以最大化性能。
关键：此阶段必须验证功能集成，而不仅仅是测试通过。
编译并通过测试但从未布线的代码是无用的。
任务：
1. 运行完整测试套件（所有测试，非仅受影响）
2. 以警告作为错误运行linting
3. 验证构建成功
4. 检查意外回归
代码审查（强制性）：
5. 生成并行专业审查子代理：
- security-engineer: OWASP Top 10、认证漏洞、输入验证、
秘密、凭据管理、依赖漏洞
- senior-software-engineer: 代码组织、设计模式、
性能、文档、可维护性
- /testing技能：单元测试覆盖率、集成测试、边缘情况
6. 修复审查发现的所有问题 - 不仅仅是报告它们
7. 验证无代码重复，适当关注点分离
功能验证（强制性）：
8. 验证功能实际布线到应用程序：
- 对于CLI：命令是否注册且可调用？
- 对于API：端点是否安装且可达？
- 对于UI：组件是否渲染且交互？
9. 执行主要用例的手动冒烟测试：
- 实际运行功能端到端
- 验证产生预期输出/行为
- 记录测试步骤和结果
10. 验证与现有代码的集成点：
- 回调/钩子是否连接？
- 事件是否发布/订阅？
- 依赖是否正确注入？
知识策展（强制性）：
11. 读取所有阶段内存：loom memory show --all
12. 策展有价值洞察到知识：
- 值得避免的错误 → loom knowledge update mistakes "..."
- 值得重用的模式 → loom knowledge update patterns "..."
- 架构决策 → loom knowledge update architecture "..."
13. 如果结构更改，更新architecture.md
14. 记录任何经验教训
dependencies: ["stage-a", "stage-b", "stage-c"] # 所有功能阶段
acceptance:
- "cargo test"
- "cargo clippy -- -D warnings"
- "cargo build"
# 添加功能验收标准 - 示例：
# - "./target/debug/myapp --help | grep 'new-command'" # CLI布线
# - "curl -s localhost:8080/api/new-endpoint | jq .status" # API布线
# - "grep -q 'NewComponent' src/app/routes.tsx" # UI布线
files: [] # 仅验证 - 无文件修改
working_dir: "." # 必需："."表示工作树根，或子目录如"loom"
# 必需：至少一个验证字段
truths:
- "myapp new-command --help" # 功能可调用（适配到你的功能）
wiring:
- source: "src/main.rs"
pattern: "new_feature"
description: "功能布线到main"
为什么集成验证是强制性的：
| 原因 | 解释 |
|---|---|
| 隔离工作树 | 功能阶段本地测试，非全局 |
| 合并冲突 | 个体测试通过但合并代码可能冲突 |
| 跨阶段回归 | 阶段A更改可能破坏阶段B功能 |
| 单一验证 | 整个计划的一个权威通过/失败 |
| 布线验证 | 功能必须连接才能实际工作 |
| 功能证明 | 冒烟测试证明功能可用 |
12. 阶段描述中的内存记录
每个阶段描述应提醒代理记录内存。 内存持久化跨会话洞察并防止重复错误。
┌─────────────────────────────────────────────────────────────────────┐
│ ⚠️ 实现阶段：仅使用`loom memory` │
│ │
│ 实现阶段切勿使用`loom knowledge update`。 │
│ 仅知识引导和集成验证阶段可以直接写入 │
│ 知识文件。 │
│ │
│ 内存在集成验证期间策展到知识。 │
└────────────────────────────────────────────────────────────────────┘
在阶段描述中包含内存记录块：
description: |
[任务描述在此]
内存记录（仅使用内存 - 从不知识）：
- 记录洞察：loom memory note "观察"
- 记录决策：loom memory decision "选择" --context "原因"
为什么这是强制性的：
| 益处 | 解释 |
|---|---|
| 洞察持久性 | 内存条目跨会话和上下文重置持久化 |
| 错误预防 | 策展的错误成为未来代理读取的知识 |
| 决策文档 | 记录选择原因，而不仅仅是做了什么 |
| 学习转移 | 内存 → 知识策展使教训永久 |
13. 内存与知识规则
关键：不同阶段有不同记录权限。
| 阶段类型 | loom memory |
loom knowledge |
|---|---|---|
| 知识引导 | 是 | 是 |
| 实现阶段 | 是（仅） | 禁止 |
| 集成验证 | 是 | 是（从内存策展） |
为什么此分离？
- 内存是阶段范围的临时 - 捕获工作中所有洞察
- 知识是永久且跨所有阶段共享 - 仅已证明的模式属于此
- 仅在完全集成后（集成验证）我们才知道哪些洞察值得永久保留
工作流程：
- 知识引导：直接写入知识文件（架构、模式、约定）
- 实现阶段：记录一切到内存，永不触及知识
- 集成验证：读取内存，使用
loom knowledge update策展有价值洞察
实现阶段规则：
在实现阶段，你必须：
- 用
loom memory note "..."记录洞察 - 用
loom memory decision "..." --context "..."记录决策 - 永不使用
loom knowledge update- 这是禁止的
例外： 如果发现会阻塞其他阶段的关键错误，立即用loom knowledge update mistakes "..."记录并在提交消息中记录原因。
14. 计划文档结构
计划有两个部分：人类可读内容优先，YAML元数据最后。
┌─────────────────────────────────────────────────────────────────────┐
│ 计划文档结构 │
│ │
│ 1. 人类可读部分（顶部） │
│ - 标题、概述、目标 │
│ - 执行图 │
│ - 阶段描述以普通语言 │
│ - 每个阶段：目的、任务、文件、验收 │
│ │
│ 2. YAML元数据（底部） │
│ - 包裹在<!-- loom 元数据 -->注释中 │
│ - 机器可解析的阶段定义 │
│ - 相同信息如上，结构化格式 │
└────────────────────────────────────────────────────────────────────┘
为什么此结构？
| 益处 | 解释 |
|---|---|
| 人类审查 | 用户无需解析YAML即可快速理解计划 |
| 代理上下文 | 阶段描述给代理更全面理解 |
| 可维护性 | 人类可轻松审查/编辑可读部分 |
| 机器处理 | 底部YAML仍支持loom CLI解析 |
15. 编写计划后
- 将计划写入
doc/plans/PLAN-<名称>.md - 停止 - 不实施
- 告诉用户：
计划写入
doc/plans/PLAN-<名称>.md。请审查并运行：loom init doc/plans/PLAN-<名称>.md && loom run - 等待用户反馈
计划文件是你的交付物。 切勿继续实施。
最佳实践
- 子代理优先：始终在创建单独阶段前最大化阶段内并行性
- 明确依赖：永不创建不必要的顺序依赖
- 清晰文件范围：定义
files:数组以使重叠分析明确 - 可操作描述：每个描述应是完整任务规范
- 可测试验收：每个验收标准必须是可运行命令
- 书挡合规：始终首先包括知识引导，最后集成验证
- 工作目录：每个阶段必须明确声明其
working_dir - 目标逆向验证：每个
standard阶段必须至少有一个truths、artifacts或wiring（已验证 - 计划无此将被拒绝）
示例
示例1：并行阶段（无文件重叠）
# 好 - 阶段可并发运行
stages:
- id: add-auth
dependencies: ["knowledge-bootstrap"]
files: ["src/auth/**"]
working_dir: "."
artifacts: ["src/auth/mod.rs"]
- id: add-logging
dependencies: ["knowledge-bootstrap"]
files: ["src/logging/**"]
working_dir: "."
artifacts: ["src/logging/mod.rs"]
- id: integration-verify
dependencies: ["add-auth", "add-logging"]
working_dir: "."
truths: ["myapp --help"]
示例2：顺序阶段（相同文件）
# 两者触及src/api/handler.rs - 必须顺序
stages:
- id: add-auth-to-handler
dependencies: ["knowledge-bootstrap"]
files: ["src/api/handler.rs"]
working_dir: "."
wiring:
- source: "src/api/handler.rs"
pattern: "auth_middleware"
description: "认证中间件应用于handler"
- id: add-logging-to-handler
dependencies: ["add-auth-to-handler"] # 顺序
files: ["src/api/handler.rs"]
working_dir: "."
wiring:
- source: "src/api/handler.rs"
pattern: "log_request"
description: "请求日志添加到handler"
- id: integration-verify
dependencies: ["add-logging-to-handler"]
working_dir: "."
truths: ["curl -f localhost:8080/api/health"]
示例3：完整计划模板
# 计划：[标题]
## 概述
[2-3句描述此计划完成什么及原因。]
## 目标
- [主要目标1]
- [主要目标2]
- [任何约束或非目标]
## 执行图
```
[知识引导] --> [阶段-a, 阶段-b] --> [集成验证]
```
`[a, b]`表示法中的阶段在单独工作树中并发运行。
---
## 阶段
### 1. 知识引导
**目的：** 在实现前探索代码库并填充知识库。
**任务：**
- 映射高级架构和组件关系
- 识别入口点（CLI命令、API端点、主要模块）
- 记录模式（错误处理、状态管理、习惯用法）
- 记录约定（命名、文件结构、测试）
**文件：** `doc/loom/knowledge/**`
**验收：** 知识文件包含带有`## `标题的有意义部分。
---
### 2. 功能A
**目的：** [功能A完成什么]
**依赖：** 知识引导
**任务：**
- [具体任务1，有清晰要求]
- [具体任务2，有清晰要求]
- 为独立子任务使用并行子代理
**文件：** `src/feature_a/**`
**验收：** `cargo test`通过，功能模块存在。
**验证：** `src/feature_a/mod.rs`存在且实现。
---
### 3. 功能B
**目的：** [功能B完成什么]
**依赖：** 知识引导（与功能A并行运行）
**任务：**
- [具体任务1，有清晰要求]
- [具体任务2，有清晰要求]
- 为独立子任务使用并行子代理
**文件：** `src/feature_b/**`
**验收：** `cargo test`通过，功能模块存在。
**验证：** `src/feature_b/mod.rs`存在且实现。
---
### 4. 集成验证
**目的：** 最终验证所有功能已布线且功能有效，包括代码审查。
**依赖：** 阶段-a, 阶段-b（所有实现阶段）
**任务：**
_构建与测试：_
- 运行完整测试套件（所有测试，非仅受影响）
- 以警告作为错误运行linting
- 验证构建成功（调试和发布）
_代码审查（强制性）：_
- 生成并行审查子代理（security-engineer、senior-software-engineer、/testing技能）
- 修复发现的所有问题 - 不仅仅是报告
- 验证无代码重复，适当关注点分离
_功能验证（关键）：_
- 验证功能已布线到应用程序（非仅编译）
- 执行主要用例的冒烟测试端到端
- 确认用户可见行为按预期工作
_知识：_
- 读取所有阶段内存并策展有价值洞察到知识
- 如果结构更改，更新architecture.md
**文件：** 无（仅验证）
**验收：** 构建通过、测试通过、功能通过CLI/API可调用。
**验证：** `myapp --help`显示新功能；`src/main.rs`导入功能模块。
---
<!-- loom 元数据 -->
```yaml
loom:
version: 1
stages:
- id: knowledge-bootstrap
name: "引导知识库"
stage_type: knowledge
description: |
探索代码库并填充doc/loom/knowledge/。
使用并行子代理和技能以最大化性能。
任务：
- 识别入口点和主要模块
- 记录模式和约定
dependencies: []
acceptance:
- "rg -q '## ' doc/loom/knowledge/entry-points.md"
files:
- "doc/loom/knowledge/**"
working_dir: "."
artifacts:
- "doc/loom/knowledge/architecture.md"
- "doc/loom/knowledge/entry-points.md"
- id: stage-a
name: "功能A"
stage_type: standard
description: |
实现功能A。
使用并行子代理和技能以最大化性能。
任务：
- 任务1
- 任务2
dependencies: ["knowledge-bootstrap"]
acceptance:
- "cargo test"
files:
- "src/feature_a/**"
working_dir: "."
artifacts:
- "src/feature_a/mod.rs"
- id: stage-b
name: "功能B"
stage_type: standard
description: |
实现功能B。
使用并行子代理和技能以最大化性能。
任务：
- 任务1
- 任务2
dependencies: ["knowledge-bootstrap"]
acceptance:
- "cargo test"
files:
- "src/feature_b/**"
working_dir: "."
artifacts:
- "src/feature_b/mod.rs"
- id: integration-verify
name: "集成验证"
stage_type: integration-verify
description: |
所有阶段完成后的最终验证。
使用并行子代理和技能以最大化性能。
关键：验证功能集成，而不仅仅是测试通过。
构建/测试任务：
- 完整测试套件
- Linting
- 构建验证
代码审查（强制性）：
- 生成并行审查子代理（security-engineer、senior-software-engineer、/testing技能）
- 修复发现的所有问题 - 不仅仅是报告
- 验证无代码重复，适当关注点分离
功能验证（强制性）：
- 验证功能已布线到应用程序
- 执行主要用例的冒烟测试
- 确认用户可见行为端到端工作
dependencies: ["stage-a", "stage-b"]
acceptance:
- "cargo test"
- "cargo clippy -- -D warnings"
- "cargo build"
# 添加：你的功能的功能验收标准
files: []
working_dir: "."
truths:
- "myapp --help" # 适配到你的功能
wiring:
- source: "src/main.rs"
pattern: "feature_a"
description: "功能A布线到main"
```
<!-- END loom 元数据 -->