plugin-view `object-view`: `showRefresh` is a declared, documented, defaulted designer input that nothing reads

[os-sales]

Observation-class finding, measured while proving the reference surface empty for the handleRefresh deletion. Refs #4568. Not fixed there — that card's file surface is ObjectView.tsx + tests + a changeset, and this key lives in index.tsx and is authorable surface, so removing or wiring it is a decision rather than a mechanical cleanup.

What was measured

packages/plugin-view/src/index.tsx registers object-view with showRefresh as a designer input and a default:

81: { name: 'showRefresh', type: 'boolean', label: 'Show Refresh Button' },
94: showRefresh: true,

It is also documented as a working toggle for this component:

• content/docs/api/schema-reference.md:871 (in the object-view example) and :914 — "Toggle toolbar features."
• content/docs/plugins/plugin-view.mdx:77

But ObjectView never reads it. Repo-wide, showRefresh has zero readers inside packages/plugin-view/:

$ git grep -n "showRefresh" -- packages/plugin-view/
packages/plugin-view/src/index.tsx:81: { name: 'showRefresh', ... }
packages/plugin-view/src/index.tsx:94: showRefresh: true,

Nor is it forwarded. OBJECT_VIEW_DECLARED_FORWARDED_KEYS (ObjectView.tsx:453) is exactly four keys, and showRefresh is not among them:

export const OBJECT_VIEW_DECLARED_FORWARDED_KEYS = [
 'data',
 'filterableFields',
 'navigation',
 'searchableFields',
] as const;

So an author who writes showRefresh: false on an object-view node gets no effect — the key is accepted, documented, defaulted to true, and inert.

Where the key IS live

showRefresh is genuinely read one package over, in packages/plugin-list/src/ListView.tsx — derived from userActions.refresh at :796 and gating a real toolbar Refresh button at :3080. It is also declared in @object-ui/types (crud.ts:355, objectql.ts:1487, and both zod contracts). The key is real; its declaration on object-view is what nothing honours.

Prior art

docs/audits/2026-07-objectview-detailview-schema.md:113 already recorded this and proposed a disposition:

showRefresh | Three producers ... and a designer input at plugin-view/src/index.tsx:81; zero readers in ObjectView.tsx. | Drop the local field. The affordance is real and the spec already has it — UserActionsConfigSchema.refresh (view.zod.ts:353). If the refresh button is wanted, wire it to userActions.refresh rather than resurrecting a key nothing reads.

Note the three producers the audit names still set it (app-shell/src/views/ObjectView.tsx:2192, metadata-admin/previews/ViewPreview.tsx:136, plugin-view/src/index.tsx:94), so dropping the declaration means auditing those writes too.

Why it is worth a line

This is the "declared but not enforced" shape that makes AI-authored metadata hard to get right: the designer offers the input, the docs describe it, the default asserts a value, and the renderer ignores all three. Filing so it is not re-discovered; disposition (drop the local field vs. wire it to userActions.refresh) is a decision, not a cleanup.

---

Generated by Claude Code

[huangyiirene]

Triage (first-touch grading): finding → needs-user-decision, domain:ui, type Bug — this is an enforce-or-remove fork on published authorable surface (the designer input, a default, and two docs pages all advertise a toggle the renderer never reads), so the disposition is the maintainer's call, not a cleanup. 决策分析(中文,按四维决策框架):

一句话问题:设计器里 object-view 的「显示刷新按钮」开关是假的 —— 作者关它、文档教它、默认值写着 true,页面上什么都不变。

选项:

• A 移除假开关(按 2026-07 审计既有处置:删 plugin-view/src/index.tsx:81 声明与 :94 默认值,同步清三个生产者写入与两处文档行)。业务上 = 设计器不再骗作者;刷新按钮的真实通道(userActions.refresh,plugin-list 已实装)不受影响。代价:曾在 object-view 节点上写过 showRefresh 的存量元数据作者会看到该键从设计器消失(行为本来就没变过)。
• B 实装(让 ObjectView 真读它并渲染刷新按钮)。业务上 = 兑现声明,但同一能力从此有两扇门(showRefresh 与 userActions.refresh),后续每次改刷新行为都要改两处。
• C 保持现状。业务上 = 假开关继续骗下一个作者和下一个 AI。

<!-- os-decision-facets -->

• 项目长远合理性:A 缩小契约面、收敛到 userActions.refresh 一扇门;B 制造双门增生(机制:同能力两个作者面)。
• 实际业务拉动:刷新能力的真实需求已由 plugin-list 通道承载;object-view 声明零读者、零已知用户诉求 —— 零拉动默认 remove。
• 防 AI 犯错:假声明是 AI 写元数据犯错的温床 —— AI 看到设计器输入就会用;A 让错误无处可写,C 让错误静默无效。
• 创业阶段不扩散:B 是为零消费声明补实现,典型的需求扩散;A 是删声明,维护义务归零。
• 推荐:A(审计处置照准);回退:C(等真实需求出现再按 B 重开)。
• 本分析看不见什么:站外/存量应用元数据里是否已有人写了 showRefresh 于 object-view 节点(未扫);若维护者知道有真实客户诉求要刷新按钮,B 的业务分即反转。

回一个字母即可(A/B/C);「A,但先扫存量」也可。裁后执行:A ⇒ 入队 ui 席派发(S–M,含三生产者写入清理与文档两行);B ⇒ 入队并挂 userActions.refresh 对齐条款;C ⇒ 关 not planned 留档。

---

Generated by Claude Code

[huangyiirene]

Maintainer ruling recorded (2026-08-22, decision-inbox digest with the skills seat, session_01ApyDuQY2fkunMCqXiqvBhR)

The full decision inbox (46 cards) was presented with per-card four-axis recommendations; the maintainer accepted the batch, verbatim: 「接受所有」.

Ruled: Option A — remove the inert toggle, per the 2026-07 audit's recorded disposition. Delete the showRefresh designer input (plugin-view/src/index.tsx:81) and its default (:94), clean up the three producer writes the audit names, and remove the two docs lines advertising the toggle. The real refresh channel stays userActions.refresh (already live in plugin-list) — the affordance is not resurrected on a key nothing reads (Option B's double-door implementation and Option C's status quo are both rejected).

State: needs-user-decision removed → pm:queue (ready for dispatch).

---

Generated by Claude Code