把语法写成可核对的行为契约

一段语法说明需要让读者判断“怎样写合法”和“写下后会发生什么”。将已知规则逐项表达，未定项按影响标注；不为了表格完整发明语言能力。

契约字段

维度	作者要回答的问题	写在何处
位置	声明、表达式还是函数体片段？	形式之前
形式	哪些部分必选、可选或可重复？	签名或语法结构
名称	依赖哪些声明，在哪里查找？	前提或引用小节
输入	参数的意义、数量、类型及适用范围？	参数说明
结果	成功值、类型、结构或可见 UI 效果？	结果小节
依赖与效果	哪些值需先得到，是否有业务修改？	行为说明
阶段	哪些问题可由 Preflight 判断，哪些属于 inflight？	相关约束旁
边界	缺失、失败、未就绪或非法结构会怎样？	约束与失败
状态	已确定、收录提案还是未定义？	章节入口及关键局部

对于 use，不适合虚构“返回值”，应说明依赖来源与引用效果。对于 UI 参数，说明子节点和排列；没有规定布局单位就不能补像素默认值。字段适配对象，不能机械填表。

“必须”表示文档确实规定的必要条件；“可以”表示允许的用法；“建议”表示作者偏好；“例如”只给出一个实例。“默认”必须有明确依据。

区分结构层和语义层。EBNF 能表达某个参数存在，不自动说明它的含义、范围和权限。同样，文字声称允许多个声明时，产生式也应允许；两者冲突时不能只改示例使检查通过。

对尚未定义的范围，不写“任意”“始终”“自动”“所有”这类全称断言。例如，简单 workspace handle 样例不证明全部 handle 只能包含小写字母；namespace 层级不自动决定视图成员范围。

参数数量不符等可静态判断的问题，可依现有提案说明为 Preflight 诊断。调用执行中的数据缺失属于 inflight 情况。错误文本、错误码和捕获语法未确定时，只说明可观察问题和已有规则，不虚构诊断输出。

“第二次调用需要第一次的结果”表达数据依赖；“所有参数严格从左到右执行”是额外的求值顺序规则。前者不能推出后者。普通调用也不能推出自动重试、缓存一致性或无副作用。

优先选用已经写明的形式。若目标就是介绍读取提案，则给出提案状态、成员假设和成功路径；把未知的失败处理写成自然语言边界。不得为了演示成功路径而暗示失败时会得到零值。

如果关键声明根本不存在，不能把完整源码标成可运行。可以提供明确的局部片段或概念用法，并列出缺少的语言决定。

从每条文字规则找到支持它的形式或例子；再从例子中的每个名称、调用和关键效果回到规则或明确假设。

例如 use atelier:shop.pricing 支持“完整 key”这一形式，但不证明所有成员自动进入作用域。跨 namespace 调用例子还需说明目标可见、无名称冲突的局部条件。

核对详情记录在TPL-05 变更工作单即可，不必把作者的所有分析附在读者正文中。