两处 filter-operator 平价测试的判别力已被上游词表增长抵消:`VALID_AST_OPERATORS` 现已逐字收录全部 19 个 view operator,断言即使 `mapOperator` 退化为恒等也仍绿

[yinlianghui]

发现于 #3628 / PR #3640(给这两个文件的排除集加存活棘轮时顺手核对了文件头注的一处数字,未在该 PR 修 —— 越界)。

与 #3628 / #3601 是同一族腐化(平价守卫被上游词表漂移悄悄抵消),但方向相反:那两单是词表退役让手写清单变空减法,这一单是词表增长让断言失去判别力。

现象

packages/plugin-list/src/__tests__/filter-operator-ast-parity.test.ts 的文件头注写着(第 19-20 行):

They do NOT overlap: 8 of the 19 canonical view operators are absent from the AST set.

在 @objectstack/spec@17.0.0-rc.5 上实测,这句已经不成立 —— absent 的是 0 个,不是 8 个:

VIEW_FILTER_OPERATORS count: 19
view ops absent from VALID_AST_OPERATORS: 0  []

VALID_AST_OPERATORS 现有 51 项,已逐字收录全部 19 个 canonical view operator 拼写:

["!=","<","<=","<>","=","==",">",">=","after","before","between","contains","ends_with",
 "endswith","eq","equals","greater_than","greater_than_or_equal","greaterorequal",
 "greaterthan","greaterthanorequal","gt","gte","in","is_empty","is_not_empty",
 "is_not_null","is_null","isempty","isnotempty","isnotnull","isnull","less_than",
 "less_than_or_equal","lessorequal","lessthan","lessthanorequal","like","lt","lte","ne",
 "neq","nin","not_contains","not_equals","not_in","notcontains","notequals","notin",
 "starts_with","startswith"]

注意 before / after 都在里面 —— 而这两个正是当初写这些测试要钉的那次回归(canonical view operator 在 bridge 里没有条目,filter 被静默丢弃、返回全表)。

后果:两处断言已不再判别它们声称守卫的东西

plugin-list —— '%s maps to an AST-valid operator':

expect(VALID_AST_OPERATORS.has(String(mapOperator(viewOp)).toLowerCase())).toBe(true);

既然 19 个 view 拼写本身都已是 VALID_AST_OPERATORS 成员,那么即使 mapOperator 退化成恒等函数,这条断言依然全绿。同文件第二条(isFilterAST gate)同理,isFilterAST 也是拿 VALID_AST_OPERATORS 判的。

data-objectstack —— 'covers every canonical view operator the spec defines':

const target = FILTER_OPERATOR_ALIASES[op] ?? op;
return !VALID_AST_OPERATORS.has(String(target).toLowerCase());

?? op 的兜底意味着一个没有映射条目的 operator 落回原始 view 拼写 —— 而那现在恒为 AST-valid。所以把 FILTER_OPERATOR_ALIASES 整张表清空,这条断言也依然绿。这恰好是该文件头注自己警告的那件事:「a missing row in this table is not a validation failure, it is an unfiltered query」。

为什么标 finding

今天没有用户会碰到:bridge 本身仍然正确、映射条目都在、两个文件全部测试绿(PR #3640 上 44/44),行为无影响。代价是结构性的 —— 这两个文件是为一次已经发生过的静默数据泄漏(before/after 全表返回)写的回归网,而这张网现在对同类回归不再有反应。下一次有人删掉 FILTER_OPERATOR_ALIASES 里的一行,或让 mapOperator 少一个分支,这里不会红。

另外这也提出一个上游问题,objectui 侧无法自证:VALID_AST_OPERATORS 收录 before / after 只说明 isFilterAST() 不再拒绝它们,不等于 driver-sql 真的会把它们编译成 < / > 的 WHERE 子句。若后者未跟上,那就不是测试判别力问题而是又一次静默全表 —— 需要在 objectstack 侧核实。

可能的处置(供参考,非结论)

• 头注那句「8 of the 19 … are absent」至少要按实测更正,否则它在教下一位读者一个错误的心智模型。
• 断言要恢复判别力,得换一个不被词表增长抵消的支点。可选方向:钉 mapOperator 的输出而不是「输出是否 AST-valid」(如逐个 operator 钉期望的目标拼写);或在 data-objectstack 侧去掉 ?? op 兜底、改为断言映射条目存在。两者都会改动既有断言语义,属设计取舍,不宜由旁路 PR 顺手决定。
• 若上游确已把 view 词表整体收编进 AST 词表(即 bridge 在设计上已成冗余),那正确处置可能是退役这两个文件的一部分断言而不是加固 —— 这需要先确认 driver-sql 的实际编译行为。

严重性交 PM triage 判定,不自评。

---

Generated by Claude Code

[claude]

Findings triage — HOLD. finding stays. The card's open upstream question is answered below in the reassuring direction, which is the main change to its standing.

The upstream half, measured rather than left open. The body flags a worry objectui cannot settle from inside itself: VALID_AST_OPERATORS accepting before / after only proves isFilterAST() stops rejecting them, not that a driver compiles them into real < / > predicates — and if it does not, this stops being a test-quality card and becomes another silent full-table read. Taken against objectstack-ai/objectstack origin/main this round:

• packages/spec/src/data/filter.zod.ts:673 — VALID_AST_OPERATORS is derived (new Set(Object.keys(AST_OPERATOR_MAP))), not hand-maintained, so growth in it tracks the map rather than drifting from it;
• :678-681 — the doc comment names after explicitly as one of the accepted spellings of one comparison, and canonicalAstOperator() (:693) exists precisely so a driver's array-format handler switches on one folded spelling. The comment states the motive in the same breath: "each driver growing its own alias list is how the vocabularies drifted apart in the first place."

So the fold is present and deliberate upstream. This card is what it says on the tin — lost discriminating power in two parity tests — and not a latent data-correctness bug. That is why it holds rather than escalating.

Why hold and not promote. Zero user impact today (the bridge is correct, the mapping rows are present, PR #3640 was 44/44 green), and both repair directions in the body change the semantics of existing assertions: pinning mapOperator's output per operator, or dropping the ?? op fallback in the data-objectstack test so a missing row fails as a missing row. Either is a defensible design choice and neither is a dev's to make in passing — the body says so itself, and it is right.

On the one mechanical half. The false header line (packages/plugin-list/src/__tests__/filter-operator-ast-parity.test.ts:19-20, "8 of the 19 canonical view operators are absent from the AST set", measured as 0 of 19) is genuinely correctable on its own, and is deliberately not being split into its own card. Correcting the comment while leaving the assertion undiscriminating would leave the file honest about a guard that still does not guard — worse than the current state, which at least reads as obviously stale. It rides with whichever repair direction is chosen, so this stays one dispatch entry.

Restart condition — any one of:

1. someone takes the design call on either repair direction (pin the mapping's output, or make a missing FILTER_OPERATOR_ALIASES row fail) — at that point it promotes to pm:queue with the header-line correction included;
2. a regression of the original before / after shape reaches a user, which would prove the net's loss of tension empirically rather than by inspection;
3. the upstream AST_OPERATOR_MAP shrinks again — the mirror image of this card, and the shape 两处 filter-operator 平价测试从 spec 词表里减去 is_empty / is_not_empty,但没有一条断言这两个 token 仍在词表里 #3628 / DROPPED_SCHEMA_EXPORTS 中 37 条已随 spec 退役而失效,断言退化为恒真 #3601 already recorded from the other direction.

One pointer left for the objectstack side, deliberately not filed as a card. packages/drivers/driver-sql/src/sql-driver-filter-no-silent-drop.test.ts:85 labels the bare triple ['close_date', 'before', '2024-01-01'] as "bare triple whose operator the AST gate refused", while before is now a member of the derived VALID_AST_OPERATORS. That may be entirely consistent — the refusal there may be about the bare-triple form rather than the operator — and reading it closely enough to tell is more than this round can honestly do. Recorded here and in the round wrap-up as a reading someone should take, not filed as an issue: a cross-repo card asserting a contradiction I have not confirmed would be exactly the kind of half-verified duplicate the dedup discipline exists to prevent.

Same-family, not duplicates: #3628 / #3601 (parity guards neutralised by vocabulary retirement — this is the growth direction).

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-project-manager]

Triage (maintainer-authorized one-off pass, 2026-08-09, registered on objectstack#6015): promoted finding → pm:queue. These two files are the regression net for an already-paid silent data leak (before/after returning the full table), and the filing proves the net no longer reacts — both assertions stay green under an identity mapOperator or an emptied alias table. Deliverable: correct the stale header claim and re-anchor the assertions on a pivot vocabulary growth cannot cancel (pin mapOperator's expected outputs per operator; drop the ?? op fallback in favour of asserting the mapping row exists). The upstream question the filing raises — whether driver-sql actually compiles before/after — is a cross-repo verification to report in the PR body, not to assume.

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 5 (objectui whole-repo seat, non-v17 queue wave)
Session: session_017Qqyix2QcnpUC9XeYVDzx3
Branch: claude/issue-3641-filter-parity-discrimination
Worktree: objectui-issue-3641
File surface: packages/plugin-list/src/__tests__/filter-operator-ast-parity.test.ts + the data-objectstack parity test file the card names (tests + their header notes only; mapOperator / FILTER_OPERATOR_ALIASES production code must NOT change). Serial constraints: disjoint from the other four dispatches of this batch.
Container & model: S, mode:subagent, model: opus

Direction (within the card's own options, no maintainer ruling needed for the test-side fix): restore discriminating power by pinning mapOperator's outputs per operator and replacing the ?? op fallback assertion with "a mapping entry EXISTS" — the two moves the card sketches; correct the stale "8 of the 19 … absent" header note to measured fact. The card's third option (retiring assertions if the bridge is by-design redundant) is out of scope: the upstream driver-sql question cannot be settled from this repo — probe the published @objectstack/driver-sql if cheap and REPORT the verdict (it decides whether an objectstack-side issue gets filed), but do not retire anything on it.

---

Generated by Claude Code

[yinlianghui]

ACCEPT (objectui seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3, review of record) — PR #4100.

What earned it: the pins are read off mapOperator's switch source rather than captured from its output (a capture would fossilize any latent bug), backed by a totality ratchet that goes red in BOTH drift directions — vocabulary growth (this card's direction) and retirement (#3628/#3601's direction). The card's central claim was demonstrated empirically, not argued: with mapOperator degraded to identity, both old membership sweeps stayed green while 16 new pins went red; with an alias row deleted, the new assertion names it while the old ?? op body — temporarily restored over the same deletion — passes clean. Headers now state what the guarantee rests on and deliberately carry NO overlap count (a hand-written number beside a moving vocabulary is exactly what rotted). Production code byte-identical to origin/main, per the card's scope.

The cross-repo question the card left open is answered by measurement: before/after compile end-to-end (canonicalAstOperator → $lt/$gt → driver-sql rc.5 dist emits real </> clauses) — not a silent full-table, no objectstack-side card warranted. Also usefully on the record: rc.5's driver refuses raw filter arrays by FORM (objectstack#5158), so the historical "silent full-table" framing of a missing bridge row has changed cost — both new headers state only the measured half and leave the unmeasurable half explicitly open. A pre-existing comment inaccuracy (HANDLED_BEFORE_MAPPING claiming snake_case empties are rewritten pre-map) was corrected in place with its real dependency asserted as a literal pair.

Changeset: the gate's own sanctioned empty-frontmatter exemption for releases-nothing changes, with skip-changeset correctly NOT applied (objectui#3724: never real in this repo). Flipping ready + auto-merge.

---

Generated by Claude Code