版本与治理
当独立实现者能判断下个月是否仍可互操作时，协议才开始有用。这需要的不只是一个版本字符串，而是兼容规则、弃用窗口、证据链，以及不会静默改变含义的流程。
协议版本
当前协议是 pling.surface/0.1，实现 describe 与 invoke。0.1 表明这是早期、刻意收窄的契约，不承诺未来实验方法已经存在。
若旧客户端能安全忽略增量变化，次版本可以保留：新增可选字段、新能力、只提供信息的返回字段。破坏性变化需要新修订：必填输入、包络形状、方法语义、错误含义或安全规则。客户端绝不能把未知失败解释为成功。
治理要决定什么
- 谁可以提出协议变更；
- 接受前需要什么证据；
- 安全与隐私评审如何记录；
- 如何至少跨两个实现测试修订；
- 弃用日期与迁移路径如何公开；
- 能力何时从“已实现”变成“稳定”；
- 争议与兼容例外如何处理。
项目仍在建立这套流程。已有规范草案、参考代码、聚焦测试与基准证据，但还没有经过认证的多厂商生态。文档应直接说明这一点。
能力 id 的版本
改变能力含义就是破坏性变更，即使传输仍然合法。如果“审批”开始使用不同限额或作用于不同对象，应使用新 id 或带版本的应用命名空间。外部 Agent 可能依赖旧 id，须在声明的迁移窗口内继续工作。
不要机械地给一切加版本。说明里的错字不是新能力。要判断消费者是否看到契约变化：输入、风险、审批、结果或目标语义。
治理产物
可信发布包含：
- 协议文本与 schema；
- 带兼容性分类的变更记录；
- 一致性用例与观察结果；
- 安全说明与已知限制；
- 面向客户端与宿主的迁移指南；
- 明确 owner 与评审记录。
对年轻项目，最小而诚实的治理是公开 RFC issue、安全敏感变更由两名独立评审者审核、兼容标签和测试产物。没有决定要做之前不要先造委员会；也不要闭门设计一次就称为标准。
与许可证、标准组织的关系
代码使用 Apache-2.0。协议文本计划使用 CC-BY-4.0，参考实现与一致性测试使用 Apache-2.0。许可证允许使用文本或代码，不认证实现，也不授予项目商标使用权。任何认证项目都需要公开标准与商标政策。
项目应先在真实采用中站住，再进入正式标准化。两个真实客户端、可复现基准与公开失败记录的协议，比没有实现者的 logo 更有分量。