判断 Poppy 草案里能力协商是否讲清，别停在概述页的能力列表。先把草案当一条协商链来读：入口在哪、谁发起谁响应、谁有权拒绝，能力声明有没有写出取值、约束和默认值，不支持与部分支持时走什么路径，扩展能力是否要显式进入协商。这些都能从公开草案文本、配置示例、日志或命令行为里核对；对不上，就不要只凭概述下结论。
读 Poppy 草案时，先判断它是否把能力协商写成可复现的流程：谁发起、谁响应、谁拒绝；能力声明是否带取值、约束和默认值；不支持与部分支持时的降级动作有没有写清；扩展能力是否必须显式进入协商。任一项缺口，通常意味着后续实现要自己补约定，不能只凭概述页认定草案已覆盖。
在 Poppy 草案里定位协商入口与角色说明
先在草案里找协商入口和角色，不要先背能力名。入口和角色通常不会集中在一处，常见描述位置可以先看这几类：
- 术语表或概述段：定义主动方与被动方怎么称呼。
- 协商流程章节：描述谁先发、谁后回、协商在哪个阶段发生。
- 消息或状态机描述：列出与协商相关的消息和阶段划分。
- 错误处理段：拒绝权常常藏在这里，而不是协商流程里。
- 配置示例或附录：展示协商开关和默认行为。
角色上至少要能回答：谁发起协商、谁响应、谁拥有拒绝权。拒绝权如果只写在错误处理段，而没写进协商流程，通常意味着草案把拒绝当异常而不是协商结果，后续实现要自己决定是否回落。检查动作：对本地保存的草案文本做关键词定位，确认每类描述都能落到具体段落。
# 对本地保存的草案纯文本做关键词定位，便于逐段落核对
grep -n -E 'capabilit|negotiat|initiator|responder|reject' poppy-draft.txt如果草案里同一个角色在不同段落称呼不一致，例如概述叫 client、流程段叫 initiator，需要先记录对应关系再读能力声明，否则会把同一角色当成两方来读。
把能力声明拆成能力名、取值、约束、默认值四栏
能力协商能不能落地，取决于声明信息够不够。读每一段能力说明时，都拆成四栏去填；填不满的那一栏就是草案缺口，不是你读得不够快。四栏模板可以直接抄去用：
能力名 | 取值 | 约束 | 默认值
--------------|-----------------|---------------------|-------------
<待填> | <待填> | <待填> | <待填>
缺失标记约定：
- 草案完全未提：写「未定义」
- 提了但表述模糊：写「表述模糊」并记下段落位置
- 只在示例或附录出现：写「仅示例，非规范」
- 需要结合实现确认：写「待实现确认」遇到缺失不要用猜的。可以先按保守策略处理：把该能力视为协商中未确认，不默认启用；等确认草案或对端实现后再补。验证方式是在自己的协商记录里检查这四栏是否都能对上，对不上的能力不要写进默认配置。
用支持、不支持、部分支持三条路径检查协商结果
协商结果不能只写「支持/不支持」两个状态。至少要按三条路径检查草案是否定义了后续动作，尤其是不支持和部分支持。
- 支持：响应方确认该能力，发起方按声明的取值和约束启用。后续动作：写入生效配置；验证方式：协商日志或配置回显里能看到该能力被接受。
- 不支持：草案要说明是明确拒绝、忽略该能力，还是直接判定协商失败。后续动作：按草案走降级、回退默认值或中止；验证方式：日志里出现对应错误或忽略记录，且没有误启用。
- 部分支持：常见于取值有子集或约束不满足。草案要说明是否允许协商收窄到交集。后续动作：按交集启用并记录被裁掉的部分；验证方式：对比双方声明，确认实际生效范围是两者交集。
如果草案只写了「支持」路径，不支持和部分支持留给实现自己发挥，那就需要在对接前补一份本地约定，否则双方对同一能力的理解会在边界取值上分叉。
对照 Poppy 草案的扩展与版本段落
扩展能力与基础能力的边界要看两处：基础声明段有没有给扩展留挂载点，扩展段落有没有说明扩展必须显式进入协商。通常扩展声明不能默认继承基础能力的可用性，对端没在协商里确认，就不应生效。
版本段落要关注协商顺序：版本协商和能力协商谁先谁后，版本变化是否改变能力集合。不要自行假设某个版本号对应某组能力，草案里没写的版本差异，一律标为待确认。检查动作：把草案中扩展小节和版本小节各读一遍，分别记录「哪些能力是基础的、哪些只能通过扩展声明、版本段是否影响协商入口」。
输出能力协商读后检查单
读完 Poppy 草案后，用下面六项复核。任何一项答不上来，通常都说明对应段落需要重读，或应在自己的笔记里标记为缺口。
- 入口：协商从哪里开始，触发条件是什么？验证：能在草案里指到具体章节和流程步骤。
- 角色：谁发起、谁响应、谁拥有拒绝权？验证：不同段落的称呼是否一致，不一致先记映射。
- 取值：每个能力的取值范围和合法组合是否写清？验证：四栏模板的取值栏是否填满。
- 默认：未协商或协商中未确认时默认是什么？验证：默认值栏有没有「未定义」或「待实现确认」。
- 拒绝：拒绝是显式结果还是异常？验证：日志或草案错误处理段能否对上。
- 降级：不支持与部分支持时的动作是否定义？验证：三条路径是否都能走通并留下可核对记录。