方案设计（req-design）

方案讨论最容易散在群聊和会议里。我们要求结论回到需求文档，形成一条能被后来人读懂的决策记录。

1. 输入

• 需求文档（lark-cli docs +fetch --as user --doc <URL>），重点读背景、预期效果、待确认问题。
• 相关代码或系统现状：从真实仓库和文档里读，不凭印象。

待确认问题里还有影响方案的项，先回去问提出人，不进入设计。

2. 至少两个选项

每个选项一段：做法、改动范围、成本、主要风险、放弃它的理由。「什么都不改，只改文档/流程」也算一个选项，值得写。

3. 决策记录

决定：选项 B
原因：...
放弃了：选项 A，因为 ...
谁定的、何时：...
假设（被推翻时要重新评审）：...

4. 波及面

列出这次改动可能波及、但不在 diff 里的地方：调用方、配置、数据迁移、对外接口、文档、其他团队。每条写「怎么确认没坏」（一个测试、一条命令、一个负责人确认）。

5. 验收检查点

把 intake 的预期效果拆成实施过程中的检查点，每个检查点有可执行的检查方式：

检查点	何时	怎么查	通过标准
方案评审通过	开发前	文档评审记录	负责人确认
关键路径测试	合入前	<测试命令>	全绿，且新测试在旧代码上失败
灰度指标	上线后 1 天	埋点看板	不劣于基线

6. 写回文档并推进节点

写进「5. 方案设计」「6. 验收检查点」（用 +fetch --detail with-ids 拿 block_id，再 +update --command block_insert_after 或 block_replace）。

方案评审在 Meegle 上若是一个节点，评审结论按 meegle skill 的 sop-transition-node.md 写：

meegle workflow get-node --project-key <PK> --work-item-id <ID> --node-id-list '["<评审节点 key>"]' --format json
meegle workflow update-node --project-key <PK> --work-item-id <ID> --node-id <评审节点 key> \
  --fields '[{"field_key":"node_finished_opinion","field_value":"<评审意见>"}]'

节点流转（workflow transition --action confirm）由节点负责人确认后再执行。

输出

文档里的选项、决策记录、波及面、检查点四节齐全；给提出人一段摘要和仍未决的问题。

用到的命令

先确认身份和空间（每个会话一次）：

meegle project search --project-key "<空间名或 key>" --format json
meegle workitem meta-types --project-key <PK> --format json
lark-cli docs +fetch --as user --doc <需求文档 URL> --scope outline

字段 key、状态 key、transition_id 一律现查，不要凭记忆填，见 templates/meegle-field-mapping.md。