#5017 的全包 grep 顺带发现的第八处,落在第三个文件 ,不在 #5017 (validate-expressions.ts / validate-security-posture.ts)的处置范围内,按 Prime Directive #10 单独记账。
事实
packages/lint/src/validate-rule-compilability.ts:239:
// `validations` is the spec key; `validationRules` is read for the same
// …
const validations = obj . validations ?? obj . validationRules ; ObjectSchema.shape 只声明 validations,且是 strict —— 实测:
objects[].validationRules parses? false
["objects.0: Unrecognized key(s) on this object: `validationRules`. …
Did you mean `validationRules` → `validations`?"]
validateRuleCompilability 也是 input: 'parsed' 注册的规则,所以在 compile 路径上 obj.validationRules 恒为 undefined。canonical 排首位,别名 limb 不可达 —— 和 #5009 那四条、#5017 前六条完全同形。
#5017 已在另外两个文件把同族的七条收敛完毕(PR #5046 ),并落了两层结构性 meta-guard(declared-key ⊆ schema.shape + reachability)。这一条没有一并改,是因为:
它在第三个文件 ,validate-expressions / validate-security-posture 也有同形的 spec 不声明键的 ?? 别名读法(#5009 建议 3 的核对结果) #5017
fix(lint): 收敛 validate-expressions / validate-security-posture 的 spec 不声明键 ?? 别名读法 (#5017) #5046 它自己那份 meta-guard 需要单独写(该规则的 finding 形状与两者又不同)。
处置建议
照 #5046 的模式办:
收敛为 obj.validations;
补 declared-key guard(该规则从 obj / 规则对象上读的每个键 ⊆ 对应 .shape)+ reachability guard;
反向验证注意方向:canonical 排首位,所以改动前对非法拼法越权判红 ,改动后让位给 schema 的具名拒绝 —— 与 fix(lint): 删除 validateOrgAxisRedLines 里 spec 合法 stack 到不了的四条分支 (#5009) #5018
现有 fixture validate-rule-compilability.test.ts:295 用的正是 validationRules: 拼法,改动时要一并改成 canonical(否则该用例会静默失去覆盖 —— fix(lint): 收敛 validate-expressions / validate-security-posture 的 spec 不声明键 ?? 别名读法 (#5017) #5046 runtime-gate.test.ts 上正好踩到这个:别名拼法让"上下文里有坏规则"的 fixture 实际上一条 finding 都产生不了,断言 toEqual([]) 通过的原因是没有东西可减 而不是减法正确)。
理由两条轴,与 #5017 同:
参考
#5017 的全包 grep 顺带发现的第八处,落在第三个文件,不在 #5017(
validate-expressions.ts/validate-security-posture.ts)的处置范围内,按 Prime Directive #10 单独记账。事实
packages/lint/src/validate-rule-compilability.ts:239:ObjectSchema.shape只声明validations,且是 strict —— 实测:validateRuleCompilability也是input: 'parsed'注册的规则,所以在 compile 路径上obj.validationRules恒为undefined。canonical 排首位,别名 limb 不可达 —— 和 #5009 那四条、#5017 前六条完全同形。与 #5017 的关系
#5017 已在另外两个文件把同族的七条收敛完毕(PR #5046),并落了两层结构性 meta-guard(declared-key ⊆
schema.shape+ reachability)。这一条没有一并改,是因为:??别名读法(#5009 建议 3 的核对结果) #5017 的议题正文和验收条件都没有点名它;??别名读法 (#5017) #5046 的真实元数据零新红、反向验证、变异测试都是围绕那两个文件做的,顺手带上第三个规则等于把没做过同等验证的改动混进已经绿了的 PR;处置建议
照 #5046 的模式办:
obj.validations;obj/ 规则对象上读的每个键 ⊆ 对应.shape)+ reachability guard;validate-rule-compilability.test.ts:295用的正是validationRules:拼法,改动时要一并改成 canonical(否则该用例会静默失去覆盖 —— fix(lint): 收敛 validate-expressions / validate-security-posture 的 spec 不声明键??别名读法 (#5017) #5046 在runtime-gate.test.ts上正好踩到这个:别名拼法让"上下文里有坏规则"的 fixture 实际上一条 finding 都产生不了,断言toEqual([])通过的原因是没有东西可减而不是减法正确)。理由两条轴,与 #5017 同:
objects[].validationRules是真实的 authoring 面。参考
??别名读法(#5009 建议 3 的核对结果) #5017 / PR fix(lint): 收敛 validate-expressions / validate-security-posture 的 spec 不声明键??别名读法 (#5017) #5046(同族前三轮)、validate-expressions.ts 的 field-formula 校验读f.formula—— spec 声明的是expression,这段从未对任何 spec 合法 stack 跑过 #5026(同族但非??链的f.formula)、未知键静默剥离仍是全仓默认:把 #3405 的 strict 收紧从一个 schema 推广到整个可授权面(ADR-0078 完整性闸门) #4001(strict + 别名按名拒绝)