[objectstack-fleet]

Requested by Steve · project thread

Fixes #25970

Clause-②: no
Metadata-protocol: none

What changes

A dataset-bound widget with compareTo now asks for a comparison only when its resolved filter carries a date condition on the compared field (on any field when compareTo.dimension is omitted). When the filter dates nothing, which is what the reader's All time on the dashboard date filter produces, the widget sends the same query a widget without compareTo sends and the tile shows its number with no comparison badge.

• ui/packages/plugin-dashboard/src/DatasetWidget.tsx: new exported filterDatesField(filter, dimension?). The widget's declared comparison becomes declaredCompareTo; the compareTo the query, the signature and the overlay read is that value only when filterDatesField holds. No window is lowered either, so runtimeFilter is untouched in that case.
• ui/packages/plugin-dashboard/SKILL.md: the "When NOT to use compareTo" line now separates a date condition that is not a closed window (still an error) from a filter that dates nothing (no comparison, no error).

Mechanism, measured

Picking All time calls onChange(undefined) (DashboardFilterBar.tsx, the ALL sentinel). buildWidgetScopedFilter skips an empty value, so DashboardRenderer merges no condition and the widget's own filter reaches DatasetWidget unchanged: the date key is ABSENT, not an open range. For the HotCRM "Selected Period" tile that means a runtime filter with no date at all, the case this PR omits the comparison for.

The ruling this PR implements (the seat's delegated call)

• An author-declared one-bound window ($gte only, e.g. a YTD tile) stays an error. The executor and the spec define compareTo only on a two-bound window, so the widget still sends compareTo, and the executor's refusal names the fix. HotCRM's YTD / QTD / 12M tiles written as one bound keep erroring until they are written as a closed pair.
• Two dated fields with no compareTo.dimension stay the executor's ambiguity error.
• The omission applies only when the filter carries no date condition on the compared field at all. "A date condition" is any ISO-date operand under the field, at any depth and in any position ($or / $not included), deliberately wider than the windows extractDateWindows lowers. A custom range with only a start date picked in the filter bar ({ $gte }) therefore also keeps erroring.

Tests

At head b256ae44:

• ui/packages/plugin-dashboard whole package, vitest run --maxWorkers=2 packages/plugin-dashboard/ under the verify lock: Test Files 188 passed (188), Tests 1842 passed, 6 skipped.
• New in DatasetWidget.compareTo.test.tsx: filterDatesField unit cases, and four widget cases against a source that answers the way the executor does: no filter, a non-date filter, a named dimension left undated (all three send no compareTo and render the number with no badge), and a one-bound $gte window (still sends compareTo and shows the refusal).
• New DashboardRenderer.compareToAllTime-25970.test.tsx drives the real Radix select: under the default this_quarter range the tile compares, then after picking All time the last selection is exactly the no-comparison query, the number shows, and no badge appears. A YTD tile ($gte only, opted out of the dashboard filter) keeps the refusal.
• Four existing fixtures declared compareTo with no dated filter and had the mock answer a __compare column the real executor would have refused (DatasetWidget.test.tsx forwarding case, colorVariant, comboPresentation, dimensionlessMeasures-11261). Each now states a closed window. The objectui#7495 control (bar vs pie with no window) now uses a one-bound filter so its refusal still has something to refuse.
• pnpm --filter @object-ui/plugin-dashboard type-check: exit 0; tsc -p tsconfig.test.json --listFiles includes both changed compareTo test files.
• Ablation, once: the omission condition replaced with the bare declared value through scripts/ablation-replace.mjs (anchor x1 to x0, marker x0 to x1, restored blob equal to HEAD). The three omission cases and the All-time dashboard case went red (4 failed, 36 passed); the one-bound and YTD cases stayed green, as they pin unchanged behaviour.

Gates

node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack at b256ae44: 46 derived commands, each run, every one exit 0. --ran with exit codes: "46 derived famil(ies) accounted for — 46 run, 0 NOT-MEASURED (a DERIVED zero)". node scripts/check-sdui-manifest.mjs is among them after the re-record; node scripts/check-changeset-fixed.mjs (roster under .changeset) also exit 0. Type-check lanes, Test Core and the wide-population families are CI's.

Acceptance notes

• A widget whose author wrote compareTo with no date anywhere and no dashboard date filter bound to it now shows no comparison silently, where it used to show the refusal. At runtime that case cannot be told apart from the reader's All time, and the ruling puts the reader's case first. Catching it would belong at authoring time (a lint on compareTo over a widget that no date filter can reach); not filed here.
• The dataset-bound path of ObjectChart (ui/packages/plugin-charts) does not forward compareTo to queryDataset at all, so it never hit this refusal. Observation only.

---

Generated by Claude Code

[objectstack-fleet]

席位核对

ACCEPT · domain:ui seat 2 · session_01SMps7wq7rBTk53e8KTSEup · 2026-10-26T09:34Z · head b256ae44

1. 形态: draft → main; the first content line is Fixes #25970, which is correct because the whole card lands. The body has no other closing keyword (objectui#7495 is mentioned without a verb). Assignee is os-steve. Clause-②: no and Metadata-protocol: none lead their lines in both the PR body and the changeset.
2. 前提实测: the seat read DatasetWidget.tsx at this head. runtimeFilter is produced by resolveFilterPlaceholders (~L839) before filterDatesField runs, so a {current_year_start} one-bound window reaches the gate as an ISO date. It still sends compareTo and keeps the refusal, which matches the seat's ruling in claim 6411700534. filterDatesField walks $-operators at any depth and matches only ISO_DATE_RE operands under the compared field (or any field when there is no dimension). Only the no-date case drops compareTo, and the window lowering is skipped with it.
3. 门禁 check-runs: none at this head yet, since the PR was opened at 09:31Z. Landing waits on the head-pinned Lint & Repo Gates and TypeScript Type Check success plus all checks green. The dev's local union (46 derived families exit 0, plugin-dashboard 188/188 files) proves only the local subset.
4. 接受的偏差: four existing fixtures outside the claimed test file were changed (DatasetWidget.test, colorVariant, comboPresentation, dimensionlessMeasures-11261), plus the spec: register the three AI_* quota codes in the error-code ledger (ruled Option A on the cloud#1168 vocabulary fork) #7495 control. Each one pinned compareTo over an undated filter that the real executor refuses, so each must flip with this behaviour. All are in the same package and the same gate family, and the PR body names each one. The SKILL.md edit is the line the claim allowed.
5. 范围外去向: two observations stay unfiled. The first is an authoring-time lint for compareTo that no date filter can reach. The second is that ObjectChart's dataset path never forwards compareTo. Neither one is a defect that this PR touches or makes false.
6. 落地条款: no governed path, +313/−18, scripts/sdui-manifest.record.json re-recorded, root .changeset/ patch for @object-ui/plugin-dashboard. Once the checks are green at this head, the seat lands via relay pr_ready + automerge_enable.

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 40337868008 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

分类：failure —— 按下面的日志分诊。

失败的 job（日志抽取，best effort）：

• Test UI (14/16) — 失败步骤: Run the ui tests (shard 14/16)

  × after a successful save: the shell leaves at once 1064ms
  FAIL   @object-ui/console  src/pages/settings/__tests__/SettingsView.shellLeave-13231.test.tsx > CONTROLS: the page registers only while it holds edits (objectui#13231) > after a successful save: the 
    ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️ 断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• src/pages/settings/__tests__/SettingsView.shellLeave-13231.test.tsx — 24h 内已弹出 2 个互相独立的 PR（fix(plugin-dashboard): a compareTo KPI tile shows its number when the reader picks All time #26027、chore(ui-tooling): drop the page-key read census its card closed as not planned (slice 3 of #25920) #26057）。汇总 issue：Queue-flake anchor: src/pages/settings/__tests__/SettingsView.shellLeave-13231.test.tsx #26096（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 31 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)