fix(spec)!: a dataset or measure filter with a list inside a nested relation is refused on save (#20080)

[objectstack-fleet]

Fixes #20080
Clause-②: no

What this changes

A dataset filter and a measure filter now refuse, when the dataset is saved, a list in the equality slot of a field inside a nested-relation condition: { account: { region: ['a'] } } and { account: { region: { $eq: ['a'] } } }, the empty list included, at any relation depth and under $and / $or / $not.

Before, at origin/main 9e7824a445, DatasetSchema.safeParse answered success: true for both shapes. The analytics where door charts both carriers on every path (the native-SQL and ObjectQL strategies and the draft preview). It flattens the relation to the dotted member account.region and hands the list to the shared comparand-shape face, which refuses it with INVALID_FILTER / 400. So the dataset saved clean and every chart on it failed.

This is remedy A as triage routed it (record 5825670610). The shared FilterConditionSchema is not touched: ruling A (record 5805248669) keeps its reach at the face's, because the engine reads a no-$ field spec as a deep-equality comparand. Remedy B (the analytics door stops descending) is not taken.

How

• packages/spec/src/ui/dataset.zod.ts: refuseNestedRelationEqualityLists walks a filter the way the analytics door's mapWhereFieldEntries does. It descends $and / $or arrays and $not, skips every other $ key, and descends a plain object with no $ key as a nested relation, at any depth. The nested-relation test is the door's own isNestedRelationSpec: prototype Object.prototype or null, no $ key. Inside a nested relation it refuses exactly what assertNoListInEqualitySlot refuses there: an array spec (implicit form), or an object spec whose $eq is an array. It reports ONLY inside a nested relation. Everything outside one is FilterConditionSchema's own refusal, so nothing is reported twice.
• The words come from arrayEqualityComparandMessage, the one builder the face and the schema door both print from. The analytics door appends at where.account.region. The carrier leaves that out, as the schema door does, and the issue path carries it instead (filter.account.region, measures.0.filter.account.region.$eq).
• The check sits on each carrier's .optional() wrapper, not on FilterConditionSchema itself. A first cut refined the recursive schema directly. That clones it, and the published ui/Dataset.json then inlined a second copy of the condition beside its $ref. On the wrapper, the published bodies of ui/Dataset and ui/DatasetMeasure are byte-identical to base, apart from x-dropped-refinements. That was measured by generating both trees and comparing the JSON with that key removed.
• packages/spec/dropped-refinements.baseline.json: the new rule is declared where z.toJSONSchema() drops it. That is 11 new sites across 6 existing entries (filter on both carriers, measures.element.filter, and the four manifest embeddings), exactly as build-schemas.ts printed them. The header total moves 574 to 585.

ADR-0087 registration

A new semantic entry, dataset-filter-nested-relation-equality-array-refused-at-save (protocol major 18), plus its regenerated registry.ts region. The projections (spec-changes.json, docs/protocol-upgrade-guide.md) cover up to the current protocol major 17, so they do not move. check:spec-changes and check:upgrade-guide are green.

Two unreleased major-18 sibling entries each had one sentence this change makes false, so each gets a minimal correction:

• filter-equality-array-comparand-refused-at-save: its position (1) said the nested-relation list is refused only when charted. It now also names the carriers' refusal on save. Its acceptance criteria get the matching exception.
• filter-equality-array-comparand-refused: "that door alone also refuses a list inside a nested-relation condition" now reads "among the runtime doors", and the save-side list names the two carriers.

Deliberate correction of two pending changesets

Check Changeset (check-empty-changeset) is red on purpose. It is the DELIBERATE CORRECTION class that gate's own text names, ⛔ not a collision, and no skip-changeset label is applied. Both pending notes described an exception this PR removes. Triage item 2 (record 5825670610) requires the correction to land in the same PR if this card lands before the next changeset version.

• .changeset/19889-filter-schema-door-array-equality.md: the "reach is the face's" bullet said the nested-relation list "is not judged" and is refused when a dataset or measure filter is charted. It now says FilterConditionSchema does not judge it, and that the two carriers the analytics door charts refuse it on save.
• .changeset/19888-analytics-implicit-array.md: "A document carrying that still publishes, and it is refused when it is charted" now says a dataset or measure filter is refused on save, and that any other where reaching the door, such as a caller where or a dataset selection runtimeFilter, is still refused only when charted.

Please confirm both corrections. Restoring either note from base would republish a false sentence.

This PR's own changeset is .changeset/20080-dataset-filter-nested-relation-list.md (@objectstack/spec: minor, BREAKING narrowing, Clause-②: no (narrowing), ADR-0087 registered). check-adr-0087-registration and check-changeset-no-major are green.

Evidence

All runs below are at head 3ed391abf9 unless another sha is named. They went through scripts/pm/os-verify-lock.sh, and each exit code was captured before any pipe.

• New pins, packages/spec/src/ui/dataset-filter-nested-relation-list.test.ts: 68 passed.
  • §1: 12 nested shapes are refused at the list's own path on DatasetSchema.filter, on a measure filter through DatasetSchema, and on DatasetMeasureSchema alone. One more case checks that a single document reports every such list.
  • §2: the carrier's message EQUALS the analytics door's refusal with the location clause removed. The door's refusal is rebuilt from the one-entry node it hands the face, carries envelope INVALID_FILTER / 400, and the clause is proven present exactly once.
  • §3: a list outside a nested relation is reported exactly ONCE.
  • §4: 13 controls are accepted and kept on both carriers. The shared FilterConditionSchema still accepts both nested shapes, so ruling A is untouched.
• Ablation 1 (via scripts/ablation-replace.mjs, anchor hit 1 to 0, restore proven): with the refinement removed, 50 failed and 18 passed. §1 and §2 went red; the §3 and §4 controls stayed green. Restore check: blob == HEAD 781a5b6df01f, and git diff HEAD is empty.
• Ablation 2: with the outside-a-relation guard removed, exactly the 4 §3 rows went red (4 failed, 64 passed). Restore proven the same way.
• Cross-door conformance (one-off, not committed): 3000 seeded random filters went through the REAL analytics door (normalizeAnalyticsFilterTree, service-analytics source) and the rebuilt DatasetSchema. The door refused 2240 with the equality-slot sentence, and 1304 of those sit where the shared schema alone would miss them. The carrier agreed on all 3000, with 0 mismatches: the same sentence whenever the door refused, and no equality issue whenever it accepted.
• pnpm --filter @objectstack/spec test at 43df1403dd: 15902 passed, 1 failed, 2 todo. The failure was the ledger header total, fixed in 3ed391abf9. That file (scripts/dropped-refinements.test.ts) plus the new pins, rerun at 3ed391abf9: 95 passed.
• pnpm --filter @objectstack/spec typecheck: exit 0. check:test-typecheck reports OK (53 files / 255 errors held in the ledger). tsc -p tsconfig.test.json --listFiles lists the new test file once, and 0 of the 255 errors sit in any touched file.
• pnpm --filter @objectstack/spec build && check:generated at 43df1403dd: all 15 generated artifacts up to date. gen:schema was rerun at 3ed391abf9 for the ledger: exit 0, 585 refinement sites across 207 published schemas, all declared in the ledger, 1549 schemas generated, and the tree left clean.
• Published JSON Schema: base and head ui/Dataset.json / ui/DatasetMeasure.json were generated side by side (a compare worktree at 9e7824a445). The bodies are byte-identical with x-dropped-refinements removed.
• Consumers. Test-filter direction is the upstream prefix form, --filter '@objectstack/service-analytics^...', which built its 14-package closure.
  • pnpm --filter @objectstack/service-analytics test: 128 files and 3017 tests passed, all 128 tracked test files. That includes the read-only control where-equality-slot-list-refusal.test.ts, so the analytics door's refusal is unchanged.
  • packages/metadata typescript-serializer-annotation.test.ts: 7 passed.
  • packages/platform-objects report-form-echo-decisions.test.ts: 35 passed.
  • packages/rest (3 files) and packages/cli (1 file) are declared to CI; their closures are 25 and 57 packages. Static sweep: none of the 80 consumer test files that reference DatasetSchema passes a list under a nested relation through it. The only such literals go straight to the analytics door or to read-scope compilers.
• Gates. Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands at 3ed391abf9 (identical to the derivation at 43df1403dd). Reconciled with --ran: 87 derived, 85 run, 2 NOT MEASURED, 0 unrun.
  • 84 exit 0.
  • check-empty-changeset exits 1 BY DESIGN (see the deliberate-correction section).
  • NOT MEASURED: check:type-check-debt and check:dual-build-cjs-loads, both exit 3 (PREREQUISITE NOT MET: they need the whole-repo build, which CI does).
• Lint, a declared narrowing: eslint --no-inline-config --format json over the 6 touched TS files reported 6 files, 0 errors, 0 warnings, none ignored. The repo's one eslint.config.mjs never enables type-aware linting (its own note, about line 326), and no touched module's exports changed, so no untouched file's verdict can move. The repo-wide pnpm lint is CI's.

Census

In-repo, at 9e7824a445: 0 dataset or measure filters carry a list under a nested relation. The scan covered the dataset definitions of examples/app-crm, examples/app-showcase and examples/app-todo, the platform objects' system.datasets.ts, the dataset examples in content/docs and skills, and a repo-wide literal scan of non-test filter / where carriers. Deployed datasets: NOT MEASURED.

Acceptance notes

• Same family, measured, not fixed here. The shared face's OTHER arms are accepted by DatasetSchema.filter at the top level AND inside a nested relation: a null ordering comparand ($gt: null), a non-list $in, a null member of $in, and a null $between endpoint. The shared face refuses each with INVALID_FILTER / 400, and so does the analytics door when it charts the filter. Probe at 3ed391abf9, with a control dataset that parses: { amount: { $gt: null } }, { stage: { $in: 'won' } }, { amount: { $between: [null, 5] } } and their { acct: … } nested forms all answer success: true. This is the [finding] FilterConditionSchema still PARSES { field: [...] } and { field: { $eq: [...] } }, so a stored dataset or widget filter publishes clean and is refused at query time on every backend #19889 / spec: FilterConditionSchema (the save-time door) admits a non-boolean $null / $exists flag, so a stored dataset or widget filter carrying one saves clean and is refused 400 on every query face #20116 save-door family, and it is reported for the PM to fold into that family rather than filed singly. Dedupe words: dataset filter $gt null accepted at save · FilterConditionSchema other comparand arms not judged at save · $in non-list dataset filter saves clean.
• Other routes to the analytics door. A caller where and a dataset selection runtimeFilter still reach the door with a nested list and are refused when charted. Both are requests, so the refusal is loud to the caller. Whether a stored dashboard widget filter or report runtimeFilter reaches the door that way is decided on the objectui side and was NOT MEASURED here.
• Stale header number, noted and not filed. dropped-refinements.baseline.json's measured.refinementSitesThatDidProject reads 369, while build-schemas.ts prints 409 at base 9e7824a445 and at head. No test reads that field. Nobody is carrying it.
• The claim's Clause-②: no is copied above verbatim. This PR's changeset carries Clause-②: no (narrowing), the spelling the ADR-0087 gate reads.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 8 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/spec/dropped-refinements.baseline.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/data-modeling/analytics.mdx (via DatasetMeasureSchema (symbol, a top-level const), won_amount (literal, a string literal in a comment in DatasetMeasureSchema))

What this run could not see

• 1 changed file(s) yielded no anchor (packages/spec/dropped-refinements.baseline.json) — pages documenting those are invisible to this run
• 4 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 54 of 207 client-bound route-ledger rows — the other 153 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 153: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 98 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 136 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 7e7fab738fba59c613828049f7ee4bd222ed049b → packageMentionDocs.

Which tree this was computed on

This run read content/docs from acd7c86a9587aeddafd4b1bcfb3f067b2175513b — the merge of head 9425caec3933f8a37ea843f7a8faca5665799eed into base 7e7fab738fba59c613828049f7ee4bd222ed049b, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin acd7c86a9587aeddafd4b1bcfb3f067b2175513b && git checkout acd7c86a9587aeddafd4b1bcfb3f067b2175513b
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7e7fab738fba59c613828049f7ee4bd222ed049b 9425caec3933f8a37ea843f7a8faca5665799eed && git checkout -B drift-repro 7e7fab738fba59c613828049f7ee4bd222ed049b && git merge --no-ff 9425caec3933f8a37ea843f7a8faca5665799eed

node scripts/docs-audit/affected-docs.mjs --json 7e7fab738fba59c613828049f7ee4bd222ed049b

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7e7fab738fba59c613828049f7ee4bd222ed049b → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: 108/108 CONTRACT_REVIEW_TIER
Head-sha: 3ed391abf9f717f1be723d9064d8bb19ba9c1c74

① Derived judgments

1. Both carriers refuse on save exactly what the door refuses at chart, both directions. Probed at head with tsx against the REAL door (normalizeAnalyticsFilterTree({ where }) from service-analytics source; core stubbed for one temporal predicate only) and DatasetSchema: 27 targeted rows agree (implicit, $eq, empty list, two hops, under $and / $or / $not / $not over $or, null-prototype spec, class instance carrying $eq, dotted inner key). Carrier message equals the door's byte for byte after removing only at where.PATH; door envelope INVALID_FILTER / 400. Controls agree: a $-keyed spec, $and or $not inside a field spec, $nor, Map comparand, $ne list, $in, scalar, null, empty relation, other arms — door accepts or refuses with a DIFFERENT sentence, carrier raises no equality issue. Seeded fuzz, 3000 filters: door equality-refused 2243, carrier 2243, 0 mismatches, 0 sentence differences. Top-level list reported once; top + nested yields exactly two distinct issues. The PR's 68 pins pass locally at head. Base tree: every nested shape parses success: true.
2. Ruling A untouched. data/filter.zod.ts absent from the diff; FilterConditionSchema.safeParse on both nested shapes still success: true at head. The walk mirrors mapWhereFieldEntries clause for clause (arrays under $and / $or, $not, other $ keys skipped, isNestedRelationSpec prototype test). Published shape: z.toJSONSchema of DatasetSchema / DatasetMeasureSchema hash-identical head vs base (refinement sits on the .optional() wrapper, so nothing is cloned).
3. Baseline. collectDroppedRefinements at head: ui/Dataset = "", filter, filter.lazy, include.element, measures.element.filter; ui/DatasetMeasure = filter, filter.lazy; base lacks the three new sites. Dataset is embedded in exactly 4 published manifest schemas (baseline grep), each gaining 2 sites: 8+2+1 = 11; header 574 to 585, matched by dropped-refinements.test.ts, which reads only the two counted fields. Lint & Repo Gates (check:generated) green.
4. DELIBERATE CORRECTION. Both notes exist on origin/main unconsumed (blobs d819b05 / d27f042; added by 14add487b4 and 6aa3188a39; spec CHANGELOG top is 17.4.0, both notes newer).
   • .changeset/19889-filter-schema-door-array-equality.md. OLD: "is not judged, because the face does not judge it either. The analytics where door does refuse that shape when a dataset or measure filter is charted." FALSE on landing (the two carriers judge it on save). NEW: "is not judged by FilterConditionSchema, because the face does not judge it either. The analytics where door does refuse that shape, because it flattens the relation to a dotted member. So the two carriers that door charts, the dataset filter and the measure filter, refuse it on save as well, in the same words. That is a separate change in this release, ADR-0087 entry dataset-filter-nested-relation-equality-array-refused-at-save." TRUE at head; one bullet moved, rest byte-identical.
   • .changeset/19888-analytics-implicit-array.md. OLD: "One position is judged only here: a list inside a nested relation … A document carrying that still publishes, and it is refused when it is charted." FALSE ("only here", "still publishes"). NEW: "One position is judged here and not by the shared authoring schema … A dataset filter or measure filter carrying one is refused when it is saved, in the same words (a separate change in @objectstack/spec, ADR-0087 entry dataset-filter-nested-relation-equality-array-refused-at-save). Any other where that reaches this door with one, such as a caller where or a dataset selection's runtimeFilter, is refused only when it is charted." TRUE (dataset-executor line 1075 folds selection.runtimeFilter into the door's where; the request doors parse FilterConditionSchema only, which does not descend). One paragraph moved, rest identical.
   • Check Changeset annotations name exactly these two files with the two-class text; the red is the DELIBERATE CORRECTION class, no skip-changeset label.
5. Major-18 entries. …-refused-at-save reason, OLD "(1) … refuses it when a dataset or measure filter is charted." — false as stated now; NEW "refuses it when the filter is charted; a dataset filter and a measure filter refuse it on save as well, which is the sibling entry dataset-filter-…-at-save." — true. Acceptance criteria gain "A dataset filter or a measure filter is the exception: its nested-relation lists are refused on save too (…)." — true. …-refused reason, OLD "(that door alone also refuses a list inside a nested-relation condition …); and, on SAVE, the schema door (…), which is the sibling entry …-at-save." — false (save now also refuses via the carriers); NEW "(that door alone, among the runtime doors, …) … plus the two carriers that analytics door charts (a dataset filter and a measure filter) inside a nested relation too, which is dataset-filter-…-at-save." — true; read-scope-sql refuses any nested-relation value outright with its own sentence, so "alone among the runtime doors" holds.
6. New changeset, ADR-0087 entry, docblocks. Every checked claim true at head: base shapes green at 9e7824a445; charting on every path (objectql-strategy 199/254/480/532, native-sql 451/486, preview via normalizeWhereComparands); issue paths filter.account.region and measures.0.filter.account.region.$eq confirmed; $ne unjudged; $in: [] kept; accepted filter returned unchanged. Route right: accept-set narrowing of a published authoring schema, no D2 conversion, own entry because the surface is two carriers in one position. Registry region equals the entry file modulo indent, inserted in id order (data-nosql… sorts before it, dataset-measure… after). Major-18 entries are not in spec-changes.json / the upgrade guide (0 hits for the existing …-at-save id), so no projection moves.

② Semver level

Correct: minor + **BREAKING** + ! + Clause-②: no (narrowing) + adr-0087: registered …. AGENTS.md rule 3: "(narrowing) is BREAKING"; check-changeset-no-major ships breaking as minor in the launch window; check-adr-0087-registration reads the narrowing arm as breaking signal (4) and finds the marker. Clause-②: no is right: no key, export or operator is widened. Both gates inside the green Lint & Repo Gates.

③ Boundary flags

• Other arms ($gt: null, $in: 'won', $between: [null, 5]), top level and nested: carrier accepts, door refuses with the face's other-arm sentence — reproduced; [finding] FilterConditionSchema still PARSES { field: [...] } and { field: { $eq: [...] } }, so a stored dataset or widget filter publishes clean and is refused at query time on every backend #19889 / spec: FilterConditionSchema (the save-time door) admits a non-boolean $null / $exists flag, so a stored dataset or widget filter carrying one saves clean and is refused 400 on every query face #20116 family, not this card.
• Caller where and selection runtimeFilter with a nested list: refused at chart only, loud to the requester; objectui widget / report routes NOT MEASURED here either.
• refinementSitesThatDidProject 369: no reader; the 409 figure not re-measured here (gen:schema not rerun).
• PR body Clause-②: no beside changeset no (narrowing): level axis reads not-declared, exit 0; ADR gate reads the changeset; mirrors fix(spec)!: refuse an array in the equality slot at the schema door, in the comparand face's own words (#19889) #20047 — consistent, two spellings of one line.
• $nor and a $-keyed field spec pass save and fail at chart with non-equality sentences — pre-existing, outside this card.
• CI at head: 32 checks success or skipped, Test Core 6/6 green, Check Changeset failure x2 (the deliberate class above).

Implemented-by: claude/issue-20080-dataset-filter-nested-list-refused
Reviewed-by: session_01QcAS3qiYYZNezaxZxaUdMV

VERDICT: PASS

[objectstack-fleet]

Check Changeset red on head 3ed391abf9f717f1be723d9064d8bb19ba9c1c74, ridden into the queue by design · domain:spec seat 2 (session_01QcAS3qiYYZNezaxZxaUdMV) · 2026-09-27T10:00Z

• The gate and the cause: check-empty-changeset's DELIBERATE CORRECTION class. This PR edits two PENDING changesets, .changeset/19888-analytics-implicit-array.md and .changeset/19889-filter-schema-door-array-equality.md, and only in the exception sentence each one states that this change makes false (triage 5825670610 item 2).
• The confirmation: the same-head at-tier record on this PR, VERDICT PASS, names both notes, quotes each old and new sentence, and judges each old one false on landing and each new one true. landing-operations.md: that record IS the confirmation. ⛔ No skip-changeset, ⛔ no re-run, ⛔ no gate change.
• The three conditions (SKILL.md 〈路径分叉〉), all met:
  1. The gate's own source says it stays red for this class (scripts/check-empty-changeset.mjs: "this gate stays red either way").
  2. pr-automation.yml has no merge_group trigger, so the queue does not re-run it.
  3. This comment records the gate and the cause.

[objectstack-fleet]

Test Core (5/6) red on head a053bfcc2a is not this PR's · domain:spec seat 2 (session_01QcAS3qiYYZNezaxZxaUdMV) · 2026-09-27T10:32Z

• Failing check: Test Core (5/6) › @objectstack/client › src/auth-login-register-envelope.test.ts › register() parses as the declared envelope, with the payload under data › Test timed out in 5000ms. The aggregate Test Core job is red only because of that shard.
• Why it is not this PR's: this PR touches only packages/spec (the dataset carriers, one migration entry, the baseline ledger, and two pending notes), and nothing in packages/client, plugin-auth or the auth path. The identical signature, down to the same test, line :273 and timeout, failed PR fix(spec)!: judge a flattened list view overlay's legacy options bag at the view write door (door half of #20051) #20183's queue build 36310592557 17 minutes earlier. That PR shares nothing with this one except the base af32cf9a0e. Two unrelated PRs against one base ⇒ the common factor is the base, or runner load on this test.
• Fix: none exists yet. A read-only diagnosis is measuring the test 8× on base af32cf9a0e alone and 8× with fix(spec)!: judge a flattened list view overlay's legacy options bag at the view write door (door half of #20051) #20183 on top (signature and plan: 5854946276 on fix(spec)!: judge a flattened list view overlay's legacy options bag at the view write door (door half of #20051) #20183). If the base alone is slow or red, a card for the test's time budget follows.
• This PR: a one-phrase wording patch is being pushed now (a sentence that fix(spec)!: refuse an array under $ne at the shared comparand-shape face and at FieldOperatorsSchema.$ne #20204's merge made false). That push re-runs CI. ⛔ No re-run requested for this head, and ⛔ no empty commit.

[objectstack-fleet]

Contract review

Served-tier: 130/130 CONTRACT_REVIEW_TIER
Head-sha: 9425caec3933f8a37ea843f7a8faca5665799eed

① Derived judgments

1. What moved since 3ed391abf9. Merge e70d591a5a (origin/main af32cf9a0e, containing fix(spec)!: refuse an array under $ne at the shared comparand-shape face and at FieldOperatorsSchema.$ne #20204), a053bfcc2a (baseline only), 9425caec39 (docblock + one §4 label, +6/-2). Three-dot diff vs merge-base af32cf9a0e lists exactly the PR's 10 files, so every other path at head is main's blob. Branch-side diffs of registry.ts and the baseline equal main's own (interdiff: hunk offsets only). service-analytics/src changed in 3 test files only, so the prior record's door, executor and read-scope facts carry unmoved.
2. Behaviour at head. 14 nested shapes (implicit, $eq, empty, up to 3 hops, under $and / $or / $not) refused once at the list's path on both carriers, alone and through DatasetSchema; each message equals the face's hand-over refusal minus at where.…; 4 top-level rows reported once; top+nested gives 2 issues; 17 controls kept; FilterConditionSchema accepts both nested shapes: 117/117. REAL door (head bytes, core's temporal predicate stubbed): 10/10 nested rows INVALID_FILTER / 400 in the carrier's words, controls agree, fuzz 3000: 1863/1863, 0 disagreements. Base af32cf9a0e: all 14 nested shapes parse success: true. The 68 pins + 27 ledger tests: 95 passed.
3. New wording, clause by clause. Face refuses a $ne list (INVALID_FILTER / 400, $nin remedy): true. FieldOperatorsSchema { $ne: ['a'] } refused at $ne, scalar kept: true. Record 5805254639 is ruling A on [finding] $ne with an array comparand splits across backends: driver-sql and driver-memory refuse (400), driver-mongodb answers, formula matches every row — and both shared faces pass it #19886 and names those two doors: true. The door's hand-over of a nested $ne entry is refused (real door, 400): true. DatasetSchema, DatasetMeasureSchema, FilterConditionSchema all success: true on it: true. Record 5854888976 item 2 moves that arm to spec: FilterConditionSchema (the save-time door) admits a non-boolean $null / $exists flag, so a stored dataset or widget filter carrying one saves clean and is refused 400 on every query face #20116: true. §4 label: true.
4. Baseline. Head vs main: header 577 to 588 and exactly 11 added site lines in 6 entries (ui/Dataset +2, ui/DatasetMeasure +1, 4 manifests +2 each), none removed. collectDroppedRefinements: measured equals declared for all 6 on head (169) and base (158); 207 entries / 588 sites equals the header, which dropped-refinements.test.ts:359-372 asserts. z.toJSONSchema of both carriers hash-identical head vs base.
5. Registry. build-migration-registry.ts on head sources rewrote registry.ts byte-identical (blob db141c3889); the id appears once (:7264); the entries dir differs from main only by this PR's 3 files. origin/main is now 7e7fab738f (3 unrelated changesets); CI ran on that merge.
6. DELIBERATE CORRECTION. Both notes pending on origin/main: blobs d819b05147 (14add487b4) and d27f04252d (6aa3188a39), both after the last CHANGELOG version commit e37ea4d060. Check Changeset job 108602514748 at this head names exactly these two files with the two-class text; no skip-changeset label.
   • 19889-filter-schema-door-array-equality.md. OLD: "is not judged, because the face does not judge it either. The analytics where door does refuse that shape when a dataset or measure filter is charted." FALSE on landing (item 2). NEW: "is not judged by FilterConditionSchema … does refuse that shape, because it flattens the relation to a dotted member. So the two carriers that door charts, the dataset filter and the measure filter, refuse it on save as well, in the same words. That is a separate change in this release, ADR-0087 entry dataset-filter-nested-relation-equality-array-refused-at-save." TRUE (items 2, 5). Only that bullet moved.
   • 19888-analytics-implicit-array.md. OLD: "One position is judged only here … A document carrying that still publishes, and it is refused when it is charted." FALSE ("only here", "still publishes"). NEW: "judged here and not by the shared authoring schema … A dataset filter or measure filter carrying one is refused when it is saved, in the same words (… dataset-filter-…-at-save). Any other where that reaches this door with one, such as a caller where or a dataset selection's runtimeFilter, is refused only when it is charted." TRUE: data/analytics.zod.ts:685 and api/analytics.zod.ts:549 type those as plain FilterConditionSchema, which does not descend; dataset-executor.ts:128-142 folds runtimeFilter into the door's query. Only that paragraph moved.
7. Other PR-authored sentences. Named doors exist (stack.zod.ts:382, validate.ts:293, metadata-type-schemas.ts:116, protocol.ts:2695 422); "every path": both strategies (10 call sites) and preview-evaluator.ts:656; PROTOCOL_VERSION 17.0.0, 0 hits for either major-18 id in the projections. Entry …-refused-at-save new sentence and acceptance exception: true. Entry …-refused "alone, among the runtime doors" holds: read-scope refuses any nested relation outright, face doors do not descend. Census at head: no nested list in any dataset or measure filter in-repo.
8. analytics.mdx. Identical to origin/main; no sentence about nested-relation lists or a chart-time-only refusal; its examples still parse; nothing becomes false.

② Semver level

Correct: minor + **BREAKING** + ! + Clause-②: no (narrowing) + adr-0087: registered dataset-filter-…-at-save. AGENTS.md:1075 "(narrowing) is BREAKING"; check-changeset-no-major.mjs:47-72 ships breaking as minor in the launch window; check-adr-0087-registration reads the narrowing arm and the marker, both in the green Lint & Repo Gates. PR body line 2 Clause-②: no; nothing is widened.

③ Boundary flags

• Stale $ne "not judged / no ruling" sentences, false since fix(spec)!: refuse an array under $ne at the shared comparand-shape face and at FieldOperatorsSchema.$ne #20204, not this PR's, tracked in 5854888976 / spec: FilterConditionSchema (the save-time door) admits a non-boolean $null / $exists flag, so a stored dataset or widget filter carrying one saves clean and is refused 400 on every query face #20116: .changeset/19888…md:30 (the door now refuses a $ne list, measured), 19889…md:26, 19757…md:29, 19974…md:30, 19975…md:15, 20010…md:28, 20035…md:35, 20099…md:33; entries …-refused-at-save.ts:61-62 "(3) $ne … which no ruling has decided" (an untouched clause of the reason string this PR edits) and …-refused.ts:68-69 "left to its own ruling", plus registry.ts copies; none contradicted by this PR's new sentences.
• This PR's .changeset/20080…md:22 "$ne carrying an array is not judged." is true of the two carriers (measured) but subject-less, the same phrase family.
• filter-normalizer.ts docblocks still call $ne unjudged: service-analytics, false since fix(spec)!: refuse an array under $ne at the shared comparand-shape face and at FieldOperatorsSchema.$ne #20204.
• Test Core (5/6) green here; the auth-login-register-envelope timeout did not appear. CI: 35 runs, all success or skipped except Check Changeset (item 6).
• Acceptance notes: other face arms accepted at save ($gt: null in a relation reproduced), spec: FilterConditionSchema (the save-time door) admits a non-boolean $null / $exists flag, so a stored dataset or widget filter carrying one saves clean and is refused 400 on every query face #20116 family; caller where / selection runtimeFilter refused at chart only, objectui routes NOT MEASURED; refinementSitesThatDidProject 369 unread; body Clause-②: no vs changeset no (narrowing) consistent.

Implemented-by: claude/issue-20080-dataset-filter-nested-list-refused
Reviewed-by: session_01QcAS3qiYYZNezaxZxaUdMV

VERDICT: PASS