本文是 Schema-As-Code 证据链 的"可靠性"站（D 列：验证 + 工具），属于主题行②（语义域）。在前序章节中，阶段一 Guard 结构化诊断 通过 组件语义快照 与 三层判定模型 证明了漂移真实存在；阶段二 Contract 语义契约化 将设计意图写入了 YAML 契约 与 语义字典。但契约写在文件里不等于边界被守住------本文要验证的正是：当 语义域 定义了跨层禁止规则后，机器能否在编译期、Lint 期、生成期三层独立拦截非法语义绑定。
1. 问题：规则写在字典里，不等于边界被守住了
语义字典 的 cross_layer_ban 字段白纸黑字写着"status.critical 不可用于 observational 域"，边界动作诊断 也证明了域内漂移真实存在。但团队的真实反馈是："规范里写着'限流提示禁用致命红'，上线前才发现 AI 还是把它画成了红色。"规则防不住看不见规则的人，更防不住根本读不到规则的机器。
限流提示被画上致命红、同一界面点被声明两个 L1 域、L2 脱离父层单独声明------这三类越界的共同特征是：它们单看 YAML 契约 都"合法"，字段存在、绑定已注册、语法正确。只有对照 语义域 的边界规则才能判定非法。人工评审看到的是"语法没问题的契约"，机器对照规则树看到的才是"越界的引用"。
2. 为什么人工评审守不住：认知负荷与可见性盲区
人工走查的局限不是责任心问题，是信息结构问题。组件语义快照 的 6 字段记录的是界面表象，评审者看到的是 color_token: status.critical，却看不到 语义规范体系 中该令牌的 cross_layer_ban 列表；看到的是两个 L1 声明，却看不到"每个界面点必须且只能被一个 L1 覆盖"的硬性约束；看到的是 data-destructive，却看不到它缺失了父层 transactional 的声明。
AI 生成工具更是如此------它的训练语料里没有这份 语义规范，提示词里不写，它就按旧习惯继续生成。工程师被迫在每次生成任务里手工复述规范要点，重复、易漏、不可追溯。这正是 从观察到契约 的 Semantic Pipeline 要解决的问题：诊断和契约化之后，必须进入验证阶段，证明规则真的被机器守住了。
3. 设计思路：从"文档约定"到"机器规则"
跨层禁止必须从"评审纪律"升级为"机器防线"。设计思路是：
- 编码为可运算规则 ：语义字典 中的
cross_layer_ban、L1 互斥、L2 层级不再是文档里的文字，而是 契约库 中的结构化字段，可被规则树逐条核对； - 编译为可执行指令 ：编译管线 将契约翻译为 Prompt 前缀、JSON Schema、CI 规则等消费格式，让规则到达工程师手中；
- 三层独立校验：编译期（契约加载时）、Lint 期（代码提交时）、生成期（AI 输出时）------同一规则在三个时刻被三处独立校验，任一失守有下一层兜底。
4. 本文的验证口径
"守住域边界"必须翻译成可测试的命题。本文验证三类违规，对应 6 个漂移模式 中 组件语义分类与漂移模式匹配 所定义的跨域漂移：
| 测试类型 | 测试用例 | 预期结果 |
|---|---|---|
| 绑定越域使用 | observational 域的契约引用 status.critical |
编译前置校验命中 cross_layer_ban，阻断并返回字段路径 |
| L1 互斥违反 | 同一界面点同时声明 transactional + observational | 互斥校验阻断，提示"每个界面点必须且只能被一个 L1 覆盖" |
| L2 脱离父层 | 声明 data-destructive（L2）但未声明父层 transactional |
层级校验阻断，提示 L2 必须叠加于父层 |
一、验证对象：跨层禁止的三类违规
先把"守住域边界"翻译成可测试的命题。跨层禁止面临三类违规，每一类对应一条可判定的预期结果：
| 测试类型 | 测试用例 | 预期结果 |
| 绑定越域使用 | observational 域的契约引用 status.critical（如限流提示用致命红） | 编译前置校验命中 cross_layer_ban，阻断并返回字段路径 |
| L1 互斥违反 | 同一界面点同时声明 transactional + observational 两个 L1 覆盖层 | 互斥校验阻断，提示"每个界面点必须且只能被一个 L1 覆盖" |
| L2 脱离父层 | 声明 data-destructive（L2）但未声明父层 transactional | 层级校验阻断，提示 L2 必须叠加于父层而非替代 |
三类违规的共同本质：它们单看 YAML 都"合法"------字段存在、绑定已注册、语法正确------只有对照域边界规则（cross_layer_ban / L1 互斥 / L2 层级）才能判定非法。 这正是域边界必须由机器守护而非人工评审的原因：人工评审看到的是"语法没问题的契约"，机器对照规则树看到的是"越界的引用"。
二、验证设计：三层
2.1 编译期：字典规则树对账------越界引用在入库前能被拦住吗？
问题： 契约引用绑定与覆盖层时，cross_layer_ban 是否被逐条核对？
我的设计：
●规则树对账：契约加载时，将 semantic_domain 与全部引用的绑定编译为内存规则树；逐条核对每个绑定的 cross_layer_ban 列表是否包含契约声明的域，命中即阻断。
●互斥与层级校验：同一 intent_id 作用域内出现两个 L1 声明 → 阻断；L2 声明缺失父层 → 阻断。
●错误返回：统一 { code, message, location } 结构，定位到具体字段路径（如 semantic_tokens.error_severity.retryable.visual_mapping.color_token），并附带正确绑定建议（如"限流提示应使用 status.warning"）。
演示环境证明： 在演示环境中，语义分级器输入"限流提示"场景，输出 retryable 级别（status.warning：黄色时钟 + 倒计时）；手动构造引用 status.critical 的输入，被判定为越域并返回修正建议。域归属校验逻辑在单点成立。
推演条件： 接入生产环境后，由 /api/contracts/validate（POST，只校验不产出）在 CI 中自动执行；对抗用例库需覆盖全部 6 个绑定 × 各自 cross_layer_ban 列表的笛卡尔积（含边界条件），目标拦截率 ≥ 95%。
2.2 Lint 期：代码静态检查------实现层的越界能被拦住吗？
问题： 契约层合法，不等于代码层守法。前端 JSX 里硬编码一个红色，或者组件 color 与契约声明的语义级别不一致，能不能拦住？
我的设计： 编译管线产出的 ESLint 自定义规则，在提交时静态检查（CI 集成）：
| 级别 | 规则 | 内容 |
| error | severity-color-match | 组件 color 与契约声明语义级别不一致（如 retryable 级别渲染红色） |
| error | overlay-reference-only | JSX 中语义属性硬编码、未引用字典绑定（如直接写 color="#EF4444" 而非 color_token: status.warning） |
| error | no-missing-destructive-confirm | action.destructive 绑定缺二次确认交互 |
| warning | deprecated-reference | 引用 deprecated 字典条目（附迁移指引，90 天宽限期） |
演示环境证明： 当前演示环境覆盖契约加载与语义分级（见 2.1）；Lint 规则属编译管线 v1 的产出范围（对应工程里程碑 M3 / M6 的 CI 集成模板），随管线一并落地。
推演条件： 接入生产环境后，npx eslint --rulesdir ./compiled/ci-rules src/ 在 PR 流水线执行，error 级命中即阻断合入；拦截记录按模式 ID 归因入库。
2.3 生成期：四层推演引擎------AI 生成结果中的越界能被拦住吗？
问题： 编译期与 Lint 期守住的是"人写的契约与代码"，AI 生成物（组件树 / 界面描述）在生成过程中越界，能不能拦住？
我的设计： 四层推演引擎逐层校验、逐层短路，跨层禁止由其中两层承担：
| 层 | 校验内容 | 跨层禁止相关判定 |
| 语法层 | 输出结构是否合法 | ---（短路前置） |
| 语义层 | 语义令牌是否按契约表达 | 生成物引用的绑定与声明域不匹配 → 定位到具体令牌级别（如"retryable 级别不得映射 status.critical"） |
| 安全层 | 是否触碰不可变边界 | 命中 boundary_type: semantic 类红线（如"status.critical 不可用于 observational 域"）→ 按 violation_action: block 阻断 |
| 美感层 | 视觉权重与语义权重一致性 | 越界导致的权重失配输出建议（不阻断） |
配套对抗性测试：用例库中包含"诱导越界"用例------输入"生成一个醒目的限流提示"（诱导 AI 使用致命红），断言"生成结果必须命中跨层禁止拦截，输出 status.warning 映射"。契约或字典变更后全量重跑，用例即回归资产。
演示环境证明： A/B 对比已在演示环境单点验证------同一 Prompt，注入契约编译的 Prompt 前缀组（A 组）生成的限流提示为黄色时钟 + 倒计时，未注入组（B 组）出现红色误用；"约束真的改变了 AI 的行为"闭环成立。
推演条件： 接入生产环境后，对抗用例库扩展至 6 模式 × 每模式 2 用例（共 12 例）并覆盖全部 cross_layer_ban 组合；A/B 语义合规率差值纳入收益度量，按返工成本模型推演并标注推演口径。
三、它一直在工作吗：运行逻辑
●执行链路：字典 cross_layer_ban 定义（单一来源）→ 编译期规则树对账 → Lint 期静态检查 → 生成期四层推演------同一规则在三个时刻被三处独立校验，任一失守有下一层兜底。 
●版本同步闭环：字典跨层禁止规则变更（如 Major 版本调整绑定所属域）→ Git Diff 触发重编译 → 编译时对引用方输出影响面报告（哪些契约的域声明受影响）→ 下游 Lint 规则与推演断言同步更新。 
●拦截统计与归因：三个时刻的拦截次数统一按模式 ID 与绑定 ID 归因；区分"编译期拦截"（设计侧错误）与"生成期拦截"（AI 侧漂移），分别计入走查覆盖率与契约有效性指标。 
●失败判定：字典声明的 cross_layer_ban 未出现在任何一层校验规则中（规则断链）；拦截日志缺失或版本不匹配。 
回到开头那条反馈。机器防线就位后，"限流提示被画成致命红"这个踩过的坑，走向完全不同：
| 对比项 | 调整前（真实踩坑场景） | 调整后 |
| 发现时机 | 上线前走查（甚至更晚） | 编译期 / Lint 期 / 生成期即时阻断 |
| 发现方式 | 人眼抽查，漏检率高 | 三层独立校验，任一失守有下一层兜底 |
| 反馈内容 | "这个红色好像不对" | 错误码 + 字段路径 + 正确绑定建议 |
| 归因留痕 | 口头同步，无法统计 | 按模式 ID 与绑定 ID 归因，区分设计侧错误与 AI 侧漂移 |
诚实清单：
| 已完成的（设计层） | 需工程团队补齐的（执行层） |
| 三类违规的用例定义与预期结果 | /api/contracts/validate 生产部署与 CI 接入 |
| cross_layer_ban 对账与互斥/层级校验的判定逻辑 | ESLint 规则的批量生成（编译管线格式四） |
| 语义分级器的单点演示（演示环境） | 四层推演引擎工程实现（里程碑 M4） |
| A/B 对比的单点验证 | 对抗用例库 ×12 全量构建与自动重跑 |
这不是缺陷，是分工：本篇定义"守住域边界应该测什么、通过标准是什么"，工程团队负责"怎么自动化跑、怎么接入生产环境"。
