Repository navigation
plugin-sharing isMatchAllCriteria 把 {$or:[]} 标成 match-all —— #5322 后它语义上是 match-none;拒收方向不变,措辞/归类过时 #5388
Description
Activity
发现分诊轮:持有。零行为影响的措辞/归类归位(拒收方向不变、用户撞不到),重启条件:#5330 族或下次有人动
plugin-sharing该文件时顺路处理。本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
发现分诊轮:持有(维持 08-05 判级)+ 补域
domain:identity(前一轮由本座位判级时漏打域标签,本轮补齐)。- 域锚定:落点
packages/plugins/plugin-sharing的isMatchAllCriteria与sharing-rule.test.ts:628的 pin —— SKILL 域表里plugin-sharing属domain:identity。⛔ 不按「filter / match-all」词汇猜成 engine-core:这是编写期闸门的措辞归类,不是求值器语义。 - 为什么还留着(理由未变):零行为影响 —— 拒收方向不变、且拒收方向是 under-share(安全侧),用户今天撞不到。要改的只是把
{$or: []}从 "match-all" 类移到独立的 "match-none / 无意义规则" 拒收类(或只改函数名/注释与 pin 措辞)。 - 重启条件(维持):publish/lint 面对字面量空组合子响亮拒收 —— #5322 拍板单位元后的可选编写期信号(PD #12 形状) #5330 家族落地时,或下一个动
plugin-sharing该文件的人顺路处理。⚠️ 现状核对:publish/lint 面对字面量空组合子响亮拒收 —— #5322 拍板单位元后的可选编写期信号(PD #12 形状) #5330 仍pm:blocked(等 specflow-multi-write-unfiltered不判空组合子:filter: { $and: [] }+multi: true是整表删除,却零告警 —— 身份归约在 producer 侧有三份,lint 侧不该再抄第四份 #5659),故重启条件尚未满足,本轮不晋级。 - 查重:空组合子在同仓有两个对立答案:五个后端归约成布尔单位元,service-analytics 的两个编译器 fail-closed 抛错 —— #5239 的一致性表四条因此进不了表 #5322 / publish/lint 面对字面量空组合子响亮拒收 —— #5322 拍板单位元后的可选编写期信号(PD #12 形状) #5330 /
POST /data/sharing/rules绕过SharingRuleSchema:criteria缺失或拼错静默变成"共享该对象全部记录",与 ADR-0049 "never seeded as a permissive match-all" 直接冲突 #3896 / SqlDriver.applyFilterCondition 丢弃编译成空的 $and/$or 子过滤器，而不是套用布尔单位元 —— 与同仓 matchesFilterCondition / driver-memory 相反 #5134 已在正文互链,三仓无独立重复单。
本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
- 域锚定:落点
Findings triage — verdict: HOLD stands (keeps
finding,domain:identity). One premise from the previous pass has gone stale and is corrected here.⚠️ Correction: the blocker cited last round is goneThe 2026-08-06 hold recorded:
#5330 is no longer blocked. It currently carries
pm:queue+domain:devxwith nopm:blockedlabel and no assignee — i.e. it is a dispatchable devx-lane candidate as of now. Restart condition ① ("when the #5330 family lands") is therefore no longer gated on an upstream; it is gated only on that queued issue being picked up and merged.Why that changes the reading but not the verdict
Not promoted, for a reason worth stating precisely so the next round does not re-litigate it: #5330 and this issue do not share a file. #5330's landing site is
packages/lint(build-time rejection of literal empty combinators) ⇒domain:devx; this issue's ispackages/plugins/plugin-sharing'sisMatchAllCriteriaplus the pin atsharing-rule.test.ts:628⇒domain:identity. So the relationship is conceptual, not a same-file ride-along — landing #5330 does not mechanically fix the wording here, and this issue cannot be folded into that dispatch.The substance is unchanged and still zero-behaviour: the gate rejects
{$or: []}and{$and: []}together under a "match-all" label, and post-#5322 the former is semantically match-none (OR identity ⇒ FALSE ⇒ zero rows). Rejection direction is unaffected, and it errs under-share — the safe side. Users cannot reach this today. What is owed is reclassification: move{$or: []}out of the "match-all" bucket into a distinct "match-none / meaningless rule" rejection, or just fix the function name, comment, and pin wording.Restart conditions (updated to reflect the above):
- publish/lint 面对字面量空组合子响亮拒收 —— #5322 拍板单位元后的可选编写期信号(PD #12 形状) #5330 merges ⇒ re-grade immediately — with the empty-combinator vocabulary freshly settled in
packages/lint, the identity-side wording fix becomes a small, well-specified follow-up with a named landing site, i.e. promotable topm:queue; - anyone touches
plugin-sharing'sisMatchAllCriteriaorsharing-rule.test.ts:628for another reason ⇒ handle in passing, as originally recorded.
Dedup: #5322 / #5330 / #3896 / #5134 are cross-linked in the body; three-repo scan finds no separate entry point for this wording fix.
本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
- publish/lint 面对字面量空组合子响亮拒收 —— #5322 拍板单位元后的可选编写期信号(PD #12 形状) #5330 merges ⇒ re-grade immediately — with the empty-combinator vocabulary freshly settled in
Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): closing, not planned. The body's own analysis: rejection direction stays correct and safe either way; what remains is a cosmetic reclassification of
{$or:[]}from "match-all" to "match-none" wording. Rides any future touch of that gate; not worth a card. Veto window applies.
Generated by Claude Code
观察类记录(#5322 收官时全仓扫同类 pin 发现,非缺陷修复对象;按 PD #10 立单不排队)。
packages/plugins/plugin-sharing的isMatchAllCriteria(#3896 / ADR-0049 编写期闸门)把{ $or: [] }与{ $and: [] }一并标为 "match-all" 拒收。#5322 拍板(2026-08-04)后,{ $or: [] }的运行期语义是 FALSE / 零行(OR 单位元)—— 恰恰是 match-none,不是 match-all;{ $and: [] }才是 TRUE / match-all。sharing-rule.test.ts:628的 pin 把两者钉在同一个 "should be match-all" 断言里。为什么不是缺陷、方向也不用改:该闸门是 defineRule 编写期拒收(#5330 家族,拍板明确允许的方向),拒收一条永远共享零记录的规则与拒收 match-all 规则同样安全(under-share 方向),用户今天撞不到错误行为。#3896 当年的理由(「这些形状到引擎会变成无约束 filter」)对
{ $or: [] }一格在 #5134/#5243/#5322 后已过时 —— 引擎现在会正确给零行。若将来有人整理:把
{ $or: [] }从 "match-all" 类移到独立的 "match-none / 无意义规则" 拒收类(或只改函数名/注释与 pin 的措辞),行为不变,措辞归位。与 #5330(publish/lint 面对字面量空组合子的编写期拒收)同向,可顺路处理。关联:#5322、#5330、#3896、#5134。
Generated by Claude Code