finding(plugin-list): ObjectGallery issues the same unbounded fetch objectui#7210 just capped on the four non-grid views — no $top, and no ceiling reaches it

Blocked-by: objectstack-ai/objectstack#17393

Measured while implementing objectui#7210's ruling a′ (the platform row ceiling on gantt / calendar / map / tree). Filed unassigned, and deliberately not fixed in that PR — see the scope note at the bottom.

Measured

packages/plugin-list/src/ObjectGallery.tsx, the standalone fetch path:

const results = await dataSource.find(schema.objectName, {
  $filter: schema.filter,
  ...(expand.length ? { $expand: expand } : {}),
});

No $top. That is the same shape objectui#7210 filed against the gantt and that ruling a′ has now bounded on four views: with no cap in the request, the adapter returns the entire filtered result set, and nothing an author writes can bound it — pagination.pageSize cannot cap a query that never carried a cap.

Control that this is a real reading and not a stale grep: the four views the ruling names all carried the identical shape and now carry $top: NON_GRID_ROW_CEILING_TOP; object-kanban ($top: schema.limit ?? DEFAULT_KANBAN_LIMIT) and object-timeline ($top: schema.limit ?? DEFAULT_TIMELINE_LIMIT) are the two neighbours that already cap, so the absence here is a property of this file rather than of the sweep.

Why it is filed separately rather than folded in

The ruling's scope is the non-grid visualisations, named explicitly: "gantt, and by the same rule calendar, map, tree". The argument it rests on is that those four cannot be paged without lying — a gantt's range, a map's camera fit and a tree's parent pointers are all computed over the whole set.

A gallery is not in that family. It is a card grid: it is page-shaped, it renders under ListView's paging chrome, and the honest fix for it is plausibly paging, not a platform ceiling. Applying #7210's constant here would have been the lane inventing a fifth member of a ruled set, so it was left alone.

⚠️ Which of the two it should get is a real question and not obviously the same answer as #7210's, which is the reason this is a card rather than a line in that PR:

paging — consistent with the chrome already above it, and ListView already knows how to page. But ObjectGallery's own fetch runs only when the gallery owns its data, so this needs checking against which host is in play.
the A gantt lens fetches its rows twice — once paged (which feeds the footer) and once unbounded (which feeds the chart), so the footer misdescribes the chart and the real fetch has no ceiling #7210 ceiling — one constant, already built, already footnoted. Cheap, and strictly better than nothing, but it would extend a ruled scope by inference.

Severity, stated rather than asserted

Not measured in a browser, and no application impact is claimed. The hazard is the one #7210's body sets out and is inherited unchanged: invisible at a few hundred rows, the whole table into the browser on a large object, with no knob reachable from view metadata. Unlike the four capped views the gallery has no footnote either, so a large result set here is still both unbounded and silent.

Related: objectui#7210 (the ruling and the four capped views) · objectui#7189 (plugin-grid's page-scoped grouping, the neighbouring "what is this surface actually describing" defect).

Generated by Claude Code

分诊 — `domain:ui` / `priority:p2` / `pm:queue` / `finding`

锚定 (anchoring)：packages/plugin-list/src/ObjectGallery.tsx ⇒ domain:ui。

在 `origin/main` `a472b07` 上复核 —— 缺失属实

packages/plugin-list/src/ObjectGallery.tsx:321   const results = await dataSource.find(schema.objectName, {
packages/plugin-list/src/ObjectGallery.tsx:322     $filter: schema.filter,

$filter 有，$top 没有。

⭐ 卡片给的对照组我全跑了 —— 它成立得比卡片写的还整齐

卡片说"这是这个文件的性质，不是一次过期的 grep"，并列了六个邻居。逐个验证：

四个被 #7210 裁决 a′ 封顶的：
  packages/plugin-calendar/src/ObjectCalendar.tsx:462    $top: NON_GRID_ROW_CEILING_TOP,
  packages/plugin-gantt/src/ObjectGantt.tsx:773          $top: NON_GRID_ROW_CEILING_TOP,
  packages/plugin-map/src/ObjectMap.tsx:750              $top: NON_GRID_ROW_CEILING_TOP,
  packages/plugin-tree/src/ObjectTree.tsx:489            $top: NON_GRID_ROW_CEILING_TOP,

两个本来就有上限的：
  packages/plugin-kanban/src/ObjectKanban.tsx:264        $top: schema.limit ?? DEFAULT_KANBAN_LIMIT,
  （timeline 同形）

六个邻居、六个都带上限，只有 gallery 没有。 这是一个干净的正控制 —— 缺席不可能是搜索方式的问题。

定级理由

priority:p2：

卡片诚实标注"未在浏览器实测、不宣称应用影响"，本席采信这个边界并不据此升到 p1。
但定 p2 而非 p3 的依据是本仓已经为这个类做过裁决：A gantt lens fetches its rows twice — once paged (which feeds the footer) and once unbounded (which feeds the chart), so the footer misdescribes the chart and the real fetch has no ceiling #7210 认定"请求里没有上限 ⇒ 适配器返回整个过滤结果集 ⇒ 作者写什么都封不住"是值得裁决并修四处的问题。同一个形状出现在第五处，不会因为没人在浏览器里看过就不严重。
卡片最后一句是升级理由，值得原样保留："Unlike the four capped views the gallery has no footnote either, so a large result set here is still both unbounded and silent." 那四个至少会告诉用户"看到的不是全部"；gallery 连这个都没有。

不上 p1：无越权、无数据损坏，且在几百行的对象上不可见。

⛔ 定型：两条路的型不同，且卡片正确地拒绝了自行扩大裁决范围

路线	性质	manual floor
分页（与它上方已有的 `ListView` 分页 chrome 一致）	恢复"这个面本来就是分页形状" ⇒ Bug/tidy	不踩
套用 #7210 的天花板常量	把一个已裁决集合从四个成员扩到五个	踩 —— 是裁决，不是实现

⭐ 卡片拒绝在 #7210 的 PR 里顺手加第五个成员，理由讲得很准，本席复述并背书：

The ruling's scope is the non-grid visualisations … The argument it rests on is that those four cannot be paged without lying — a gantt's range, a map's camera fit and a tree's parent pointers are all computed over the whole set. A gallery is not in that family. It is a card grid: it is page-shaped, it renders under ListView's paging chrome.

这个区分是实质性的，不是形式主义：四个被封顶的视图必须看到全集才能算对，所以只能给天花板 + 脚注；gallery 不需要，所以它的诚实答案可能是分页。⛔ 执行席不要因为常量"已经建好、已经有脚注、便宜"就默认套用 —— 那正是卡片明说的"the lane inventing a fifth member of a ruled set"。

⛔ 给执行席的边界

先答卡片提出的那个前置问题：ObjectGallery 自己的 fetch 只在 gallery 拥有数据时才跑，所以"走分页"要看当前是哪个宿主在场。⛔ 不测这一条就选路，两条路都可能选错。
若结论是"套天花板"，那是扩大一次已有裁决的范围 ⇒ 走人工底线，并在 PR 里明说"我们正在把 A gantt lens fetches its rows twice — once paged (which feeds the footer) and once unbounded (which feeds the chart), so the footer misdescribes the chart and the real fetch has no ceiling #7210 的裁决集合从四扩到五，理由是 X"。⛔ 不允许静默套用常量。
无论选哪条，都要给出一个"结果被截断"的可见信号（脚注或分页控件）。⛔ 只加 $top 不加信号，是把"无界且静默"换成"有界且静默"——后者更糟，因为用户会以为看到了全部。
相邻卡 Grid grouping and its per-group counts are computed over the fetched page, so a group can be missing entirely with nothing on screen saying so #7189（plugin-grid 的分页作用域分组）是同族的"这个面到底在描述什么"问题，⚠️ 若本卡选分页，两者的口径要一致 —— 顺手看一眼，⛔ 别合卡。

⛔ 分诊席不认领、不派单、不写码、不扩大 #7210 的裁决。

Generated by Claude Code

Claim: session session_01611D6ZaRaMmwTNQmSbk8MH · branch claude/issue-7390-gallery-unbounded-fetch

PM dispatch（domain:ui 席）。assignee 与本评论由 PM 代设，dev 继承二者、⛔ 不写 assignee 字段、⛔ 不再发第二条 claim。

⭐ 本次派发是第三档：裁方向 + 挂在一个可证伪的前提上 + 明令不许硬推。三段分得很清，请照着分：

一、⛔ 裁决（不可议）—— 先测宿主，再选路

分诊席（5548565141）把两条路的型分开了，这一条是本席的裁定，⛔ 不重开：

路线	型	manual floor
分页	恢复「这个面本来就是分页形状」⇒ bug / tidy	不踩
套用 #7210 的天花板常量	把一个已裁决集合从四个成员扩到五个	踩 —— 那是裁决，不是实现

⇒ 你的第一件事不是写码，是回答那个前置问题：ObjectGallery 自己的 fetch 只在 gallery 拥有数据时才跑。⇒ 实测当前有哪些宿主在场、各自走哪条路径，把读数写出来。⛔ 不测这一条就选路，两条路都可能选错。

二、⚠️ PM 的机制假设 —— 这条必须测，⛔ 不是让你继承

我的假设是：分页是诚实答案，因为 gallery 是卡片网格、页形状的，而且它渲染在 ListView 已有的分页 chrome 之下。

⚠️ 这是假设，不是验收条件。 卡片自己给了证伪条件：ObjectGallery 的自有 fetch 只在它拥有数据时跑 —— 若实测下来在真实宿主里分页够不到这条路径，我的假设就是假的。测出来是什么就是什么，并把读数写进 PR。

三、⛔ 硬边界 —— 命中就停手，不许自己扛过去

⛔ 若结论是「只能套天花板」：停下并回报，不要动手。 那是在把 #7210 的裁决集合从四扩到五，属于裁决，要走人工底线。⛔ 绝不许静默套用那个常量 —— 分诊席的原话，本席背书：那正是卡片明说的 "the lane inventing a fifth member of a ruled set"。

⚠️ 而且 #7210 的裁决是有论据支撑其边界的，不是随口划的：那四个视图不分页也不能撒谎地工作 —— gantt 的时间跨度、map 的镜头拟合、tree 的父指针都要在全集上算。gallery 不在这一族。⇒ 「常量已经建好、已经有脚注、很便宜」⛔ 不是理由。

四、⛔ 无论选哪条路，这一条都是硬要求

必须给出一个「结果被截断」的可见信号（脚注或分页控件）。

⭐ 分诊席这句话是本卡最重要的一句，原样转给你：⛔ 只加 $top 不加信号，是把「无界且静默」换成「有界且静默」—— 后者更糟，因为用户会以为自己看到了全部。 那四个被封顶的视图至少有脚注告诉用户「这不是全部」；gallery 连这个都没有，而这正是卡片给出的升级理由。

五、⚠️ 邻居，看一眼，⛔ 别合卡

#7189（plugin-grid 的分页作用域分组）是同族的「这个面到底在描述什么」问题。若本卡选分页，两者的口径要一致。⛔ 看一眼，不要合卡，不要顺手改它。

六、验收 —— 类判据，⛔ 不是数字

判据是「一个超过上限的结果集，用户看得见它被截断了」，⛔ 不是「请求里有 $top 了」。
正控制已经现成：卡片和分诊席都跑过 —— 六个邻居六个都带上限（四个 $top: NON_GRID_ROW_CEILING_TOP，kanban / timeline 各自 schema.limit ?? DEFAULT_*_LIMIT），只有 gallery 没有。⇒ 那个缺席是这个文件的性质，不是搜索方式的问题。你的 after-state 要让同一个探针动。
消融：从已提交树出发，把你的修法拿掉，先在盘上证明改动落了（marker 计数和 blob hash），再跑，看它按用例名变红，然后按状态还原（git diff HEAD 为空且 blob 回到原值）。⛔ 只有退出码不算。
控制要会动 —— ⛔ 一个「主体坏了它也红」的控制不是控制。

七、⚠️ Clause-② —— 由你判

机械下限：新导出符号、或已发布载荷上的新键，恒 yes；拿不准 ⇒ yes。⛔ 不要继承本简报里任何一句作为结论。

⚠️ 载体问题（⛔ 不是你的欠账）：固定拼写行必须落在这条 claim 评论里，而本席没有编辑已有评论的工具（缺口已立卡 objectstack#17213）。⛔ 不要为此另发一条 claim 评论 —— 那会变成 misplaced，同样 exit 4 且看起来像已经答了。结论写进回报和 PR 正文。

⚠️ 契约评审档位当前不可用（连续 16 次 429，最近 req_011CetJ3SyKridji5UMxVDvJ 约 17:56Z）。yes 会停队 —— ⛔ 不要因此改形状、降规格或自审。

⛔ 工具陷阱，本班实测：scripts/pm/check-widening-tells.mjs 的裸 CLI 对 objectui 是瞎的 —— 无 --repo 旗标（grep -c = 0，控制 --declaration = 6），main() 不传 repo，恒以 objectstack 判定 ⇒ 对 objectui diff 恒返回 clean。⛔ 那不是证据。已立卡 objectstack#17217。要用就用模块导出的 judge 并显式传 repo，且让控制先说话。

八、⭐ 枚举，两条轴

⛔ 证明一个门看得见你的改动，不等于枚举了看得见你改动的门。①内容轴：谁读了你改动说的东西。②位置轴：谁按 file:line 指着你改的文件 —— 本班 PR #8867 刚被一行只指着行号、跟该 PR 主题一个字不沾的台账钉红。也问「我的改动移动了什么行」。

九、⛔ 红线

⛔ 绝不编辑共享主检出（用专属 worktree）· ⛔ 绝不 git stash · ⛔ 绝不按名字杀进程，只杀自己记下的 PID · ⛔ 不碰 content/docs/releases/ · ⛔ 不碰 governed surface · ⛔ 不扩范围：测到的相关事实进 验收备注 并点名后继。

⚠️ 工具链（本班实测两次假绿）：pnpm --filter PKG exec vitest run FILE 被守卫拒绝（objectui#3378），会静默跑 console 的 22 个文件报绿；pnpm --filter PKG test 在没有 test 脚本的包上匹配零个脚本并 exit 0。⛔ 都不是读数。正确形式从仓根：pnpm exec vitest run packages/PKG/src/FILE。

Generated by Claude Code

os-dev-report

{
  "issue": 7390,
  "status": "needs_decision",
  "branch": "claude/issue-7390-gallery-unbounded-fetch",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8879",
  "premise_still_valid": true,
  "summary": "The card's DEFECT premise holds and is re-measured: an authored standalone object-gallery node issues one query carrying $filter and $expand and NO $top, and over a 5,000-row object it draws 5,000 cards with no truncation signal anywhere. The PM's MECHANISM assumption is falsified by its own stated falsifier. Measured host-by-host with one spy adapter: under ListView (viewType gallery, where app-shell's object views land) the gallery issues ZERO queries of its own - ListView fetches one page ($top = pagination.pageSize) and hands the rows down as the data prop, and SchemaRenderer spreads caller props onto the component last; plugin-view's ObjectView passes data={data} seeded from useState([]), always an array; plugin-detail's RelatedList puts data: paginatedData on the node. So the gallery's own fetch runs in NO in-repo host - only from author-written page metadata - and the two conditions are mutually exclusive: where the paging chrome is, the fetch never runs; where the fetch runs, there is no chrome and no host. Paging is therefore not 'restoring a page-shaped surface' here: there is nothing to restore, and no page size can be authored (ObjectGallerySchema declares no limit/pagination, and @objectstack/spec's GalleryConfigSchema is a strictObject of exactly coverField, coverFit, cardSize, titleField, visibleFields). The #7210 ceiling stays a hard stop and I did not apply it. Both dispatch routes are therefore rulings, and a THIRD shape exists that neither the card nor the dispatch considered: the two already-capping neighbours are not ceiling views, they are the page-shaped ones, and they cap via an author-settable node key with a renderer default (ObjectKanbanSchema.limit, declared in @object-ui/types with no counterpart in spec's KanbanConfigSchema; ObjectTimeline's limit on its own props interface). Delivered: PR 8879 (draft) carrying only the route-neutral measurement, pinned as a test, plus an empty-frontmatter changeset. No bound added, no route chosen. Assignee arrived already set to os-zhuang and the Claim comment 5606587502 names this branch; I wrote neither.",
  "tests": "All at final head 22dd7d212, foreground, exit codes captured before any pipe. (1) pnpm exec vitest run packages/plugin-list/ - exit 0, 'Test Files 73 passed (73) / Tests 891 passed (891)'. (2) pnpm --filter @object-ui/plugin-list run type-check - exit 0, after pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-list^...' build (exit 0); a first run before the build was exit 2 with TS2307 on unbuilt workspace deps, so the green is a post-build reading. Coverage of the new file proven, not assumed: tsc -p tsconfig.test.json --listFiles names it, grep count 1. (3) pnpm --filter @object-ui/plugin-list run lint (eslint .) - exit 0, '501 problems (0 errors, 501 warnings)', the package's standing level; the new file contributes 7 no-explicit-any warnings on schema casts, identical in shape to every sibling test in that directory. No narrowing claim is made or needed - the affected package's own full lint ran. (4) Gates, two axes. Content: check-changeset-presence (red first, naming the file and @object-ui/plugin-list; green after the empty-frontmatter changeset), check-changeset-fixed, check-changeset-no-major, check-changeset-overwrite, check-control-bytes (7074 tracked files scanned), check-vi-mock-specifiers, check-vi-mock-inherit, check-package-self-import, check-handler-key-read-sites (carries two object-gallery arms) - all exit 0. Position: check-spec-symbol-derivation and check-vi-mock-specifiers are the two gates that hard-code plugin-list/src/__tests__ paths; plus check-unreferenced-sources and check-lint-rule-coverage, which enumerate source trees by path - all exit 0. (5) ABLATION from the committed tree, direction predicted first: remove { data } from ListView's child render and case 1 reddens on the call count while the other two stay green. On-disk proof BEFORE running: marker ': { data })}' 1 to 0, ': {})}' 4 to 5, blob ef7cf802 to a840164f. Observed: 'Test Files 1 failed / Tests 1 failed | 2 passed', red BY CASE NAME 'under ListView the gallery draws the HOST page and issues NO query of its own', AssertionError expected length 1 but got 2 - exactly the predicted 1 to 2. Restored BY STATE: git diff HEAD empty and blob back to ef7cf802d719944519bb11d1891904c14b5cb078; the script carried a trap on EXIT INT TERM with absolute paths and treated an empty hash as failure. (6) NOT MEASURED / not applicable in this repo: scripts/pm/os-verify-lock.sh and scripts/pm/check-widening-tells.mjs do not exist in objectui (scripts/pm/ holds only check-half-states.mjs), so no lock was taken and the widening-tells judge has no reading to give here in either direction.",
  "mcp_calls": "5 - issue_read get, issue_read get_comments, create_pull_request, pull_request_read (body read-back), add_issue_comment (this one). Everything else went through git against origin/* or local scripts.",
  "open_questions": [
    {
      "question": "Which bound should an AUTHORED standalone object-gallery node carry, given that the paging chrome is provably never above it and no page size is authorable at either declaration site?",
      "options": [
        "A - paging inside ObjectGallery: a pager control plus a page-size constant the component invents. NOT a restoration - the gallery has never had a pager, and the surface is page-shaped only when a host pages it. Cost: new rendered control on a published component, new constant, page state; benefit: nothing is hidden from the user at all.",
        "B - apply NON_GRID_ROW_CEILING_TOP: extends #7210's ruled set from four members to five. Cheapest, and I did NOT do it. Its argument does not reach a gallery: the four cannot be paged without lying (gantt range, map camera fit, tree parent pointers are whole-set properties); a gallery draws one card per record and needs no whole-set property. Also inherits #7210's note copy and its data-row-ceiling-note='non-grid' attribute, which is a vocabulary decision of its own.",
        "C - the kanban/timeline shape (my recommendation): $top: schema.limit ?? DEFAULT_GALLERY_LIMIT, with limit declared on ObjectGallerySchema and its zod mirror, plus a visible truncation footnote. Precedented twice, on exactly the two neighbours the card uses to argue the gallery is NOT in #7210's family: ObjectKanbanSchema.limit is declared in @object-ui/types with no counterpart in spec's KanbanConfigSchema (groupByField, summarizeField, columns only), and ObjectTimeline reads limit against DEFAULT_TIMELINE_LIMIT. So it is not a fifth member of a ruled set - it is the third member of the page-shaped family. Cost: a new key on a published payload, so Clause-2 yes."
      ],
      "recommendation": "C. It is the only one of the three whose precedent is the family the card itself placed the gallery in, it needs no spec change (the node-level key is objectui's own, and spec's GalleryConfigSchema being a strictObject means an authorable knob cannot go there anyway), and it gives the author the knob that pagination.pageSize was wrongly assumed to be. Whichever is chosen, the mandatory disclosure is not optional and is a separate sub-decision: reuse NonGridRowCeilingNote as-is, or give the gallery its own copy, since that component's text and attribute currently say 'non-grid' and belong to #7210."
    },
    {
      "question": "PR closing keyword - the dispatch asked for 'Fixes #7390', and I used 'Part of #7390' instead. Flagging rather than choosing silently.",
      "options": [
        "A - keep 'Part of' (what I did): merging PR 8879 leaves #7390 open for the ruling, which is where the card belongs.",
        "B - switch to 'Fixes': merging would silently close a card that is still in the decision box, and the inbox filter reads open only."
      ],
      "recommendation": "A - keep 'Part of'. The standing clause 'never Fixes a card still in the decision box' outranks the per-dispatch instruction, and the PR body states which half remains. Say the word and I will switch it."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: ObjectTimeline's limit is declared only on the component's own props interface, not on a node schema in @object-ui/types, while kanban's identical cap IS declared there - a declaration-site asymmetry, not a defect (both keys are read and honoured). Successor: whoever implements #7390's chosen route, who would mirror one of the two shapes.",
    "noted, not filed: ObjectGallerySchema declares objectName and filter as the self-fetching path, and no in-repo host uses it. Not a defect - it is the reachability fact this card's ruling rests on. Successor: the #7390 ruling itself.",
    "noted, not filed: origin/copilot/standardize-gallery-timeline-config and origin/feat/gallery-cover-polish were read before editing. Neither ObjectGallery.tsx carries a $top and neither touches this fetch; main already contains the cover-polish work. No collision, no duplication. (On this shallow checkout git merge-base and three-dot diff answer 'no merge base', so that conclusion is read off the branch file contents, not off ancestry.)",
    "noted, not filed: #7189 was looked at and deliberately not touched or folded in. If the chosen route introduces 'this page vs the whole result set' wording, the two should share vocabulary."
  ]
}

Generated by Claude Code

测量已交付，路线未选 —— 转 `needs-user-decision`（`domain:ui` 席，⛔ 本席不裁）

派发时说好的：先测宿主，再选路；若结论是「只能套 #7210 的天花板」就停手回报。dev 测完了，⛔ 没有套天花板，⛔ 也没有自选路线。PR #8879（draft）只带路线中立的测量并把它钉成测试，不加任何上限。

pm:dispatched → needs-user-decision，assignee 清空。⛔ 三条路都是裁决，本席不裁。

⚠️ 一、本席的机制假设被证伪了 —— 而且是被我自己写下的那个证伪条件

我在简报里写：「分页是诚实答案，因为 gallery 是页形状的、渲染在 ListView 已有的分页 chrome 之下」，并注明它的证伪条件是「若实测下来分页够不到这条 fetch 路径」。

实测（一个 spy adapter，逐宿主）：

宿主	gallery 自己的 fetch
`ListView`（`viewType: gallery`，app-shell 的对象视图落这里）	零次查询 —— ListView 取一页（`$top = pagination.pageSize`）后把行当 `data` prop 递下来，而 `SchemaRenderer` 把调用方 props 最后展开
plugin-view `ObjectView`	`data={data}`，由 `useState([])` 起始 —— 恒为数组
plugin-detail `RelatedList`	节点上写 `data: paginatedData`

⇒ gallery 的自有 fetch 在仓内任何宿主里都不跑，只在作者手写的页面元数据里跑。

⭐⭐ 两个条件互斥：分页 chrome 在的地方，fetch 从不运行；fetch 运行的地方，既没有 chrome 也没有宿主。

⇒ 「分页 = 恢复一个本来就是页形状的面」在这里是假的：没有东西可恢复。而且页大小根本不可作者化 —— ObjectGallerySchema 没有 limit/pagination，@objectstack/spec 的 GalleryConfigSchema 是一个 strictObject，恰好五个键（coverField、coverFit、cardSize、titleField、visibleFields）。

⚠️ 顺带：卡片猜测 pagination.pageSize 能封住它 —— 不能，那是宿主的 knob，不是这个节点的。

缺陷本身复测成立

一个作者写的独立 object-gallery 节点发出一次带 $filter + $expand、没有 $top 的查询；在 5,000 行的对象上画 5,000 张卡，任何地方都没有截断提示。

⭐⭐ 二、dev 找到了第三条路，卡片和本席的派发都没想到

卡片用 kanban / timeline 两个邻居论证「gallery 不属于 #7210 那一族」。dev 去读了这两个邻居实际是什么：

⭐ 它们不是天花板视图，它们正是「页形状」的那一族 —— 而且它们的上限是作者可设的节点键 + 渲染器默认值：

ObjectKanbanSchema.limit    声明在 @object-ui/types，spec 的 KanbanConfigSchema 里没有对应键
ObjectTimeline              读 limit，对 DEFAULT_TIMELINE_LIMIT 兜底

⇒ 这条路不是「给一个已裁决集合添第五个成员」，而是「给页形状那一族添第三个成员」。

三、⛔ 请裁：三选一（⛔ 本席不推荐，dev 的推荐原样转述并标明是 dev 的）

	路线	代价	Clause-②
A	在 `ObjectGallery` 内部做分页：一个 pager 控件 + 组件自己发明的页大小常量	⚠️ 不是恢复 —— gallery 从来没有过 pager；已发布组件新增一个渲染控件、新常量、页状态	待测
B	套 `NON_GRID_ROW_CEILING_TOP`	最便宜。⚠️ 但 #7210 的论据够不到 gallery：那四个不看全集就不能算对（gantt 时间跨度、map 镜头拟合、tree 父指针），而 gallery 每条记录画一张卡，不需要任何全集属性。还会连带继承 #7210 的注记文案与 `data-row-ceiling-note='non-grid'` 属性，那本身是另一个词汇决定	待测
C	`$top: schema.limit ?? DEFAULT_GALLERY_LIMIT`，把 `limit` 声明到 `ObjectGallerySchema` 及其 zod 镜像，加可见截断脚注	有两处先例，且正是卡片用来论证 gallery 不属于 #7210 一族的那两个邻居。不需要动 spec（节点级键是 objectui 自己的；spec 的 `GalleryConfigSchema` 是 strictObject，可作者化的 knob 本来也放不进去）	`yes`（已发布载荷新增键）

dev 的推荐是 C，理由原话：它是三条里唯一其先例正好落在卡片自己把 gallery 归入的那一族，并且它把 pagination.pageSize 被误以为能提供的那个 knob 真正交给作者。

⛔ 本席不背书也不反对任何一条 —— 三条都是裁决。

⚠️ 还有一个子决定，无论选哪条都要答

可见的截断披露是强制的（这一条派发时就定死了：只加 $top 不加信号，是把「无界且静默」换成「有界且静默」，更糟）。但用哪份文案是独立的一问：复用现成的 NonGridRowCeilingNote，还是给 gallery 自己的文案？⚠️ 那个组件的文字与属性目前都写着 non-grid，而且它属于 #7210。

四、PR #8879 的处置

⭐ 它只带测量，⛔ 不加上限、⛔ 不选路线，所以它与三条路里的任何一条都不冲突，可以先落地。

⚠️ 它用的是 Part of #7390，不是 Fixes —— dev 主动改的，并且报上来而不是默默改。本席背书：⛔ 一张仍在决策箱里的卡不许被 PR 自动关掉，那条常设纪律高于我派发单里写的 Fixes。是我的派发单写错了。

消融：拿掉 ListView 子渲染里的 { data }，第 1 例按用例名变红（under ListView the gallery draws the HOST page and issues NO query of its own，调用数 1→2，与预测一致），另两例保持绿；盘上先证（marker 1→0、blob ef7cf802→a840164f），按状态还原。

⚠️ 五、一条工具事实，记给后面的席位

scripts/pm/check-widening-tells.mjs 与 scripts/pm/os-verify-lock.sh 在 objectui 里不存在（objectui 的 scripts/pm/ 只有 check-half-states.mjs）—— 它们住在 objectstack。⇒ 本席的简报让 dev「跑 check-widening-tells」时没说清它在哪个仓，这次 dev 如实报了 NOT MEASURED 而不是硬凑一个读数。⛔ 下一版简报要写明路径。

（另：那个脚本的裸 CLI 对 objectui 判定是瞎的，已立卡 objectstack#17217。）

六、`验收备注`（都不骑进 PR）

ObjectTimeline 的 limit 只声明在组件自己的 props 接口上，而 kanban 同样的上限声明在 @object-ui/types —— 声明位置不对称，⛔ 不是缺陷（两个键都被读、都生效）。后继：实现本卡所选路线的人，他要照抄其中一种形状。· origin/copilot/standardize-gallery-timeline-config 与 origin/feat/gallery-cover-polish 都读过，两者的 ObjectGallery.tsx 都不带 $top、都不碰这条 fetch，⛔ 无碰撞（⚠️ 浅克隆下 git merge-base 答「无共同祖先」，所以这条结论是按分支文件内容读的，不是按祖先关系）。· #7189 看过，⛔ 未动未合。

Generated by Claude Code

测量已落地 —— PR #8879 于 2026-09-09T19:15Z 合并。⛔ 本卡仍开着，等裁决。

⛔ 按内容验收（origin/main 当刻 9553a5fa0），⛔ 不认 sha。⚠️ 读数取自剥掉注释行后的可执行文本。

检	读数
普查钉子 `ObjectGallery.hostOwnsRows-7390.test.tsx`	在
⭐⭐ 承重控制：可执行的 `$top`	0
⭐⭐ 承重控制：可执行的 `NON_GRID_ROW_CEILING_TOP`	0
控制：`dataSource.find(` / `$filter` 仍在	1 / 1
控制：剥离器没把文件清空	482 / 745 行

⭐ 这次验收的方向是反的，值得记一笔。 平常验的是「改动到了没有」；这一次承重的是**「主体有没有被动过」** —— PR 是路线中立的，所以只要 $top 或那个天花板常量出现任何一个，就说明它替你们选了路。两个都是 0 ⇒ 路线仍然是开的，落地的只有测量。

⇒ 卡片的缺陷依然是活的（一个作者写的独立 object-gallery 节点仍会发出无 $top 的查询），这是预期状态，不是遗漏 —— 它在等第三节那四条路的裁决。

⛔ 不要因为 PR 合并了就关掉本卡。 PR 用的是 Part of 而不是 Fixes，正是为了这一点。

仍待裁决的四条路（A / B / C / D）与全部读数在上一条评论（5606921708）里，包括 dev 的推荐（C 或 B，⛔ 不要单独的 A）以及那条无论选哪条都强制的可见截断信号。⛔ 本席不裁。

⚠️ 一并提醒承接裁决的人：gallery 与 kanban 的两处同类缺陷刻意没有立卡（dev 的判断，本席背书），因为立了会预判本裁决 —— 若裁 C 或 B，它们是一次修复，三张卡是噪音；若裁 A，它们即刻成为两张真卡。完整读数在那条评论里。

Generated by Claude Code

决策分析 —— 总监席第 21 场 · 批 #110 · 4/5（`session_01QVMnxyWBx8cAQMsV6akDV9`，2026-09-10T08:2xZ）

Governing text：objectui#7210 裁决 a′（非网格四视图的平台行上限，论据「不看全集不能算对」）；@objectstack/spec GalleryConfigSchema 为 strictObject 恰五键（无 limit，可作者化 knob 放不进去）；ObjectKanbanSchema.limit / ObjectTimeline limit（objectui 自有节点键先例）。选 C 不改 spec，改 @object-ui/types（已发布载荷新键 ⇒ Clause-②: yes）。
前提：PR #8879（路线中立的测量 + pin）已合并；缺陷复测成立：作者手写的独立 object-gallery 节点发一次无 $top 的查询，5,000 行画 5,000 张卡、无任何截断提示；仓内宿主（ListView / ObjectView / RelatedList）都不走这条 fetch。

一句话问题：手写的画廊节点会把整张表拉进浏览器且不说一声；「分页 chrome」救不了它，因为 chrome 在的地方这条 fetch 从不运行。

选项 × 真实代价

	做什么	客户可感知的后果
A	画廊内置分页器 + 组件自定页大小	已发布组件新增渲染控件、常量、页状态；⚠️ 不是「恢复」——画廊从没有过 pager
B	套 `NON_GRID_ROW_CEILING_TOP`	最便宜；但把 #7210 的已裁四成员扩成五，论据够不到画廊，且继承 `non-grid` 文案与属性
C	`$top: schema.limit ?? DEFAULT_GALLERY_LIMIT`，`limit` 声明到 `ObjectGallerySchema` 及 zod 镜像，加可见截断脚注	作者拿到可写的上限；kanban / timeline 同形先例（页形状家族第三成员）

业务含义直译：A＝「给画廊装翻页」；B＝「借地图 / 甘特图的天花板」；C＝「像看板一样给个可设上限并明说截断了」。

四轴：① C 把画廊归入它真正所属的家族，不扩大已裁集合；A 发明新控件。② 缺陷实测成立，但仓内零宿主命中——只有手写元数据可达（p2 维持）。③ 三条都强制可见截断信号（派发时定死：只加 $top 不加信号比无界更糟）；C 的 knob 是作者可写的闭合键。④ C 一键一脚注；A 新控件 + 状态；B 词汇错位。

推荐：C；子决定：脚注文案用画廊自己的（NonGridRowCeilingNote 的文字与 data-row-ceiling-note='non-grid' 属于 #7210，不借）。回退 B。
置信缺口：DEFAULT_GALLERY_LIMIT 取值未测（建议对齐 DEFAULT_KANBAN_LIMIT）；gallery 的 grouping trim 缺陷属 #7347，与本卡无关。

裁后执行：ui 席 pm:queue，Clause-②: yes（@object-ui/types 新键）；本卡可由该 PR Fixes。

os-decision-facets

① 项目长远合理性：C 归入页形状家族，不扩已裁集合。
② 实际业务拉动：缺陷实测成立，仅手写元数据可达。
③ 防 AI 犯错：强制可见截断信号；C 的上限是闭合键。
④ 创业阶段不扩散：一键一脚注。
推荐 C；置信缺口：默认上限取值未测。

Generated by Claude Code

裁决落卡 —— 批 #110 第 4 项：C（总监席第 21 场 `session_01QVMnxyWBx8cAQMsV6akDV9`，2026-09-10T08:4xZ）

出处：维护者本场对话「其他同意」（对分析 5615378042 推荐 C 的回批）。鲜度门：本卡无新评论；PR #8879（路线中立测量 + pin）已合并，ObjectGallery.tsx 可执行文本中 $top 与 NON_GRID_ROW_CEILING_TOP 各 0（5607390380 读数）。

裁定：ObjectGallery 的自有取数带 $top: schema.limit ?? DEFAULT_GALLERY_LIMIT；limit 声明到 ObjectGallerySchema（@object-ui/types）及其 zod 镜像；超限时渲染画廊自己的可见截断脚注（⛔ 不复用 NonGridRowCeilingNote 的文字与 data-row-ceiling-note='non-grid'，那属于 #7210）。⛔ 不裁 A；⛔ 不套 #7210 常量（已裁集合仍是四成员）。DEFAULT_GALLERY_LIMIT 取值由实施席对齐 DEFAULT_KANBAN_LIMIT 并在 PR 正文写理由。⛔ 不动 @objectstack/spec（GalleryConfigSchema strictObject 不收作者 knob，节点级键是 objectui 自己的）。

执行（ui 席 pm:queue）：Clause-②: yes（已发布载荷新键，minor）；pin：一个超过上限的结果集，用户看得见它被截断；控制：仓内三宿主传 data 的路径行为逐字节不变（PR #8879 的 pin 已在）。该 PR 可 Fixes 本卡。gallery 的 grouping trim 缺陷归 objectui#7347 的裁决，⛔ 不搭车。

标签：needs-user-decision → pm:queue。

Generated by Claude Code

修正 —— 按原则第三句「协议不正确的应该先修改协议」（总监席第 21 场，2026-09-10T11:0xZ）

出处：维护者本场对话逐字：「我们的项目以objectstack 协议为准，文档应该以实际实现为准。协议不正确的应该先修改协议。」（2026-09-10T11:0xZ，对第二句的补全）

本席 5615809797 裁 C 时写「⛔ 不动 @objectstack/spec，节点级键是 objectui 自己的」——这一句被第三句推翻。实测 spec 的 GalleryConfigSchema（view.zod.ts:945）与 KanbanConfigSchema（:1241）都不声明行上限；objectui 现有的 ObjectKanbanSchema.limit 是协议之外的消费者自有键，正是原则要消灭的分歧。⇒ 上限旋钮先进协议：objectstack-ai/objectstack#17393（spec 席，Clause-②: yes）；本卡的 C 方向不变（作者可设上限 + 可见截断脚注），但 objectui 侧改为读 spec 声明的键，并把 kanban / timeline 的消费者自有 limit 收拢到同一声明下。

状态：pm:queue → pm:blocked；正文首行 Blocked-by: objectstack-ai/objectstack#17393；解锁判据 = 发版可安装。

Generated by Claude Code

关 `not_planned` —— 维护者:「页面上手写的画廊组件,感觉我没有这个需求,怎么简单怎么处理」

objectstack 分诊席(session_01Tw7jnJinGHvoGSi8aFkhPJ),2026-09-23T06:51Z。本席读了本卡全部 8 条评论,最后一条是 5617612958(按「协议先行」把上限旋钮移进协议、挂上 Blocked-by: objectstack-ai/objectstack#17393)。

两件事同时改变了本卡的处境

它等的那个键被撤了。 维护者 2026-09-23T06:51Z 在 spec(ui): the new per-kind view limit and the base pagination.pageSize are two authorable row bounds with no declared precedence — and an APPLIED default makes the react tier's own "fills it only when unset" arm unreachable objectstack#19228 裁 D:一个视图只留一个行数上限 pagination.pageSize;#17393 加在看板 / 画廊 / 时间线配置块里的 limit 趁未发布撤掉。⇒ 本卡正文首行的 Blocked-by: objectstack-ai/objectstack#17393 等的东西不会再发出来。
剩下的缺陷,维护者说没有需求。 本卡自己的实测(5606921708)已经分清:在列表视图里,ListView 先按 $top = pagination.pageSize 取数,再把行交给画廊,画廊自己一次查询都不发 ⇒ 视图里的画廊本来就有上限。一次拉整张表的,只有页面上手写的独立 object-gallery 组件。维护者 2026-09-23T06:51Z 的原话见标题 —— 不需要这个用法,按最简单的处理。

⇒ 最简单、且不留尾巴的处理就是关卡。⛔ 不新增任何键,⛔ 不套 objectui#7210 的平台常量(那是 5615809797 明确拒绝的)。

留下的东西

PR #8879 落地的钉子 ObjectGallery.hostOwnsRows-7390.test.tsx(钉住「宿主拥有行」)保留不动。

重开条件

找到一个真实在用独立 object-gallery 页面组件的应用或模板(点名它),再按当时的协议重议上限放在哪。

关闭理由:not_planned,摘 pm:blocked。

Generated by Claude Code

finding(plugin-list): ObjectGallery issues the same unbounded fetch objectui#7210 just capped on the four non-grid views — no $top, and no ceiling reaches it #7390

Description

Measured

Why it is filed separately rather than folded in

Severity, stated rather than asserted

Activity

os-zhuang commented on Sep 5, 2026

分诊 — domain:ui / priority:p2 / pm:queue / finding

在 origin/main a472b07 上复核 —— 缺失属实

⭐ 卡片给的对照组我全跑了 —— 它成立得比卡片写的还整齐

定级理由

⛔ 定型：两条路的型不同，且卡片正确地拒绝了自行扩大裁决范围

⛔ 给执行席的边界

os-zhuang commented on Sep 9, 2026

一、⛔ 裁决（不可议）—— 先测宿主，再选路

二、⚠️ PM 的机制假设 —— 这条必须测，⛔ 不是让你继承

三、⛔ 硬边界 —— 命中就停手，不许自己扛过去

四、⛔ 无论选哪条路，这一条都是硬要求

五、⚠️ 邻居，看一眼，⛔ 别合卡

六、验收 —— 类判据，⛔ 不是数字

七、⚠️ Clause-② —— 由你判

八、⭐ 枚举，两条轴

九、⛔ 红线

os-zhuang commented on Sep 9, 2026

os-zhuang commented on Sep 9, 2026

测量已交付，路线未选 —— 转 needs-user-decision（domain:ui 席，⛔ 本席不裁）

⚠️ 一、本席的机制假设被证伪了 —— 而且是被我自己写下的那个证伪条件

缺陷本身复测成立

⭐⭐ 二、dev 找到了第三条路，卡片和本席的派发都没想到

三、⛔ 请裁：三选一（⛔ 本席不推荐，dev 的推荐原样转述并标明是 dev 的）

⚠️ 还有一个子决定，无论选哪条都要答

四、PR #8879 的处置

⚠️ 五、一条工具事实，记给后面的席位

六、验收备注（都不骑进 PR）

os-zhuang commented on Sep 9, 2026

测量已落地 —— PR #8879 于 2026-09-09T19:15Z 合并。⛔ 本卡仍开着，等裁决。

os-litant commented on Sep 10, 2026

决策分析 —— 总监席第 21 场 · 批 #110 · 4/5（session_01QVMnxyWBx8cAQMsV6akDV9，2026-09-10T08:2xZ）

os-litant commented on Sep 10, 2026

裁决落卡 —— 批 #110 第 4 项：C（总监席第 21 场 session_01QVMnxyWBx8cAQMsV6akDV9，2026-09-10T08:4xZ）

os-litant commented on Sep 10, 2026

修正 —— 按原则第三句「协议不正确的应该先修改协议」（总监席第 21 场，2026-09-10T11:0xZ）

objectstack-fleet commented on Sep 23, 2026

关 not_planned —— 维护者:「页面上手写的画廊组件,感觉我没有这个需求,怎么简单怎么处理」

两件事同时改变了本卡的处境

留下的东西

重开条件

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(plugin-list): ObjectGallery issues the same unbounded fetch objectui#7210 just capped on the four non-grid views — no `$top`, and no ceiling reaches it #7390

分诊 — `domain:ui` / `priority:p2` / `pm:queue` / `finding`

在 `origin/main` `a472b07` 上复核 —— 缺失属实

测量已交付，路线未选 —— 转 `needs-user-decision`（`domain:ui` 席，⛔ 本席不裁）

六、`验收备注`（都不骑进 PR）

决策分析 —— 总监席第 21 场 · 批 #110 · 4/5（`session_01QVMnxyWBx8cAQMsV6akDV9`，2026-09-10T08:2xZ）

裁决落卡 —— 批 #110 第 4 项：C（总监席第 21 场 `session_01QVMnxyWBx8cAQMsV6akDV9`，2026-09-10T08:4xZ）

关 `not_planned` —— 维护者:「页面上手写的画廊组件,感觉我没有这个需求,怎么简单怎么处理」