[lint/cli] validateReadonlyFlowWrites 仍未接入 os lint —— 一条 gating error 只在 validate/compile 跑

[os-zhuang]

现象

flow-update-readonly-field 是 error(gating):update_record 在 runAs != 'system' 下写一个 readonly:true 字段,引擎会静默剥掉,写永远不落地而步骤仍报 success(#2948 / #3425)。

但它只在两条命令上跑:

命令	调用点
os validate	packages/cli/src/commands/validate.ts:550
os compile	packages/cli/src/commands/compile.ts:628
os lint	无

也就是说,CI 只跑 os lint 的团队会绿灯放行一个已经确定不会生效的写。

根因

这不是遗漏,是已知且被写进代码里的。packages/lint/src/reference-integrity-suite.ts 自己点名它:

the drift this suite exists to end (validateReadonlyFlowWrites is the standing proof — wired into validate and compile, never into lint)

REFERENCE_INTEGRITY_RULES 加一条就三条命令全覆盖,但 validateReadonlyFlowWrites 按套件自己的成员判据并不属于它:套件收的是「把 metadata 里写的名字解析到 stack 声明的东西上」的规则,而 readonly 规则问的是另一个问题——「这个确实存在的字段会不会被引擎剥掉」。硬塞进去会把套件的成员判据稀释掉,而那个判据正是它存在的意义。

建议(需要先定方向,不是一行接线)

三个选项,倾向 B:

• A. 直接手工接进 lint.ts。 最小改动,但把「加规则要记住三个地方」的漂移又复制一次——正是 lint: no reference-integrity or option-key validation for app metadata #3583 §5 D5 要终结的形状。
• B. 开第二个 list,比如 FLOW_WRITE_SEMANTICS_RULES,收「字段存在,但这个写会不会真的生效」这一类:今天是 validateReadonlyFlowWrites,天然的下一个成员是将来任何 strip / 权限 / FLS 侧的写入语义检查。三条命令各调两个套件,新规则仍然只在一个地方登记。
• C. 放宽 reference-integrity 的成员判据,把套件重新定义为「所有 pure (stack) => Finding[] 的作者时规则」。最省事,但套件文档里那段「什么属于它、什么不属于」的判据就没了,以后没人能回答「这条规则该放哪」。

选 B 的话,顺带值得核对还有没有别的规则也只挂在部分命令上——os doctor 只跑 validateWidgetBindings,套件注释里也把这个不对称点名了(但那属于「doctor 是干什么的」的产品问题,不在本 issue 范围)。

版本

@objectstack/*@17.0.0-rc.0,main @ 38182ffb8。发现自 #4369 —— 新规则接进套件时对比了隔壁 readonly 规则的接线方式。

相关:#4380、#4383(同一批核查发现)