两条,都是判据的问题 —— 一条是生成物没被当成使用者会先 include 的东西,一条是断言
「每一条」时那张清单没人守着。

一、生成的 SPIR-V 头必须能被单独 include

沙箱里一个把生成头放在第一行的程序:

tri_vert.h:3:7: error: 'uint32_t' does not name a type

glslc 那条路早就是自包含的 —— 它发的是初始化列表,规则本来就要在外面写声明,顺手写了
#pragma once 与 #include <cstdint>。glslang 那条路发的是完整的 C 声明,于是规则
什么都不写,而那个文件点名 uint32_t 却什么都不 include。

两个编译器产出「等价的头」正是这条规则可以在它们之间选择的前提,而「等价」必须包括
这一条。此前每个能用的消费者都在它前面放了一个 Vulkan 头,所以一个不完整的头读起来一直
像是好的 —— 直到有人第一个 include 它。

改成两条路同一个形状:编译器写 <base>.inc,规则写 <base>.h。

判据是 tests/spirv-consumer/src/main.cpp:生成的头是第一个 include,<cstdint>
不再放在它前面 —— 放在前面就是替这个头满足了编译器,而那正好盖住要测的性质。实测:把
#include <cstdint> 从生成器里拿掉,这条当场变红。

⚠️ 无感升级实测过:在 0.2.5 的产物目录上不清理直接切到这一版,<base>.h 被规则
写的包装取代、<base>.inc 新增,构建与运行都正常。

二、给「每条规则都为本宿主编译过」补它自己的分母

那个夹具断言的是「每一条规则都编译过」,而「每一条」是它自己 carry 的一张清单 ——
于是给这个包加第七个成员时,一条名字说它已经被覆盖的步骤会继续绿。

构建之前先把那张清单与包自己的 [features] 比一次,两者必须相等。实测两条腿:相等时
通过;从夹具里删掉 rules-hip 当场变红。

不在这一版里的

xim:shaderc 在 macOS 与 Windows 上仍是精确版本而不是下界。改回 >=2026.3 要等
带 cmd 转义修复的引擎发布 —— 那条修复已经合入 mcpp main(2026.9.7.1,未发布)。