用途：当 IFC 文件未通过 schema 校验，或 buildingSMART 校验报告出现错误时，用于定位并修复原因。覆盖校验流程第 2 阶段（Schema 合规检查）与第 3 阶段（规范性规则）。第 1 阶段 STEP 语法与编码问题另见 ifc-errors-encoding-issues。
主要能力：区分 WHERE 规则（约束单个实体实例）与全局 RULE（约束整个实例总体）；识别抽象实体实例化错误；检查属性基数、属性类型与反向基数；处理已批准的 Implementer Agreement 与尚未批准的 Informal Proposition 两类规范性 Gherkin 规则。
使用方式：先确认 schema 版本检查通过，再优先阅读 error 级发现，其次 warning；报告中未出现的检查默认已通过，不代表被跳过。修复时先处理第 2 阶段再处理第 3 阶段。WHERE 规则以 Entity.RuleName 命名，需读取规则表达式确定修复条件，例如 IfcWall 的 CorrectPredefinedType 在 PredefinedType 为 USERDEFINED 且 ObjectType 未设置时失败。全局规则如 IfcSingleProjectInstance 要求 IfcProject 数量不超过 1，需修正实例总体。抽象实体须替换为具体叶子子类型，如 IfcWall 或 IfcBuildingElementProxy。本地调试单条 Gherkin 规则可运行 python test/test_main.py alb001。
适用场景：IFC 文件校验失败排查、校验报告解读、schema 合规修复。
限制：仅覆盖第 2、3 阶段；第 1 阶段语法编码、废弃实体、断链引用等由相关技能处理。注意版本差异，IfcBuiltElement 在 IFC4.3 中非抽象，不可沿用 IFC4 的抽象规则。具体修复需依据文件实际 schema 声明，不可猜测。