You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
?? op 的兜底意味着一个没有映射条目的 operator 落回原始 view 拼写 —— 而那现在恒为 AST-valid。所以把 FILTER_OPERATOR_ALIASES 整张表清空,这条断言也依然绿。这恰好是该文件头注自己警告的那件事:「a missing row in this table is not a validation failure, it is an unfiltered query」。
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/objectstackorigin/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:
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;
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;
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).
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.
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.
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.
Activity
claude commentedon Aug 7, 2026
Findings triage — HOLD.
findingstays. 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_OPERATORSacceptingbefore/afteronly provesisFilterAST()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 againstobjectstack-ai/objectstackorigin/mainthis round:packages/spec/src/data/filter.zod.ts:673—VALID_AST_OPERATORSis 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 namesafterexplicitly as one of the accepted spellings of one comparison, andcanonicalAstOperator()(: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?? opfallback 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:
FILTER_OPERATOR_ALIASESrow fail) — at that point it promotes topm:queuewith the header-line correction included;before/aftershape reaches a user, which would prove the net's loss of tension empirically rather than by inspection;AST_OPERATOR_MAPshrinks 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:85labels the bare triple['close_date', 'before', '2024-01-01']as "bare triple whose operator the AST gate refused", whilebeforeis now a member of the derivedVALID_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 commentedon Aug 9, 2026
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/afterreturning the full table), and the filing proves the net no longer reacts — both assertions stay green under an identitymapOperatoror an emptied alias table. Deliverable: correct the stale header claim and re-anchor the assertions on a pivot vocabulary growth cannot cancel (pinmapOperator's expected outputs per operator; drop the?? opfallback in favour of asserting the mapping row exists). The upstream question the filing raises — whether driver-sql actually compilesbefore/after— is a cross-repo verification to report in the PR body, not to assume.Generated by Claude Code
yinlianghui commentedon Aug 10, 2026
Claim: PM loop round 5 (objectui whole-repo seat, non-v17 queue wave)
Session:
session_017Qqyix2QcnpUC9XeYVDzx3Branch:
claude/issue-3641-filter-parity-discriminationWorktree:
objectui-issue-3641File 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_ALIASESproduction code must NOT change). Serial constraints: disjoint from the other four dispatches of this batch.Container & model: S,
mode:subagent,model: opusDirection (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?? opfallback 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-sqlif 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 commentedon Aug 10, 2026
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: withmapOperatordegraded 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?? opbody — 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/aftercompile 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_MAPPINGclaiming 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-changesetcorrectly NOT applied (objectui#3724: never real in this repo). Flipping ready + auto-merge.Generated by Claude Code
test(filter-parity): pin mapOperator outputs and alias-row existence …
fix(spec-pin): pin the operator and action-key inventories to 17.1.0
Pin @objectstack/* to 17.1.0 (objectstack-ai#5529)