finding(plugin-detail): #7129 retired `hideEmpty` on the premise that the spec refuses it — the pin moved to spec 17.3.0 six days later and 17.3.0 DECLARES it, with a describe() promising the behaviour this repo removed

[os-warren]

维护者速读

一句话:平台的契约今天明确告诉作者「明细区有 hideEmpty,写 false 就把空区的骨架留下」,而这个应用在那之前刚把这个行为删掉。作者照契约写,发布是绿的,界面上什么都不会变。

⭐ 新读数(本席 2026-09-15T07:47Z 复测,补的正是原卡列为「第一个要问、而且⛔ 没人量过」的那个问题):spec 加这个键不是顺手带进来的,是一次维护者裁定。spec 自己的发布说明写着(照抄):

Declare hideEmpty / collapsible / showBorder on record:details sections — the three keys objectui's renderer has honoured all along

Accept-set widening only; the renderer is unchanged (maintainer ruling 2026-08-23, direction 1).

⇒ spec 声明这个键的理由,正是「objectui 的渲染器一直在兑现它」,并且明确写了「只扩大接受集,渲染器不动」。而 2026-09-01 objectui 这边的裁定(#7129,总监批 #28,维护者「同意」)第一款写的是(照抄):「objectui 侧收敛到 spec —— 退役 @object-ui/types 的 DetailViewSection.hideEmpty 声明与 RecordDetailsRenderer 的读取;spec 照旧拒收该键」。

两条裁定方向相反,后一条的前提在上游已经不成立。⛔ 这不是说 #7129 当时判错了 —— 那时本仓的 pin 还在 17.2.0,从这个仓能看见的一切都支持那个前提。

你对本席的常设口头裁定直接压在这道题上(照抄;⛔ GitHub 上无记录,写在这里以便你确认或否认):

以 objectstack 协议为准,文档应该以实际实现为准。协议不正确的应该先修改协议

按它,这题只剩一个岔口:协议说的对不对。

两个选择:

• A —— 按协议做回来:objectui 重新实现 hideEmpty,契约说什么就有什么。代价是推翻 [Decision] hideEmpty on record:details sections: the spec REFUSES the key, @object-ui/types declares it, the zod mirror omits it, and the renderer honours it — plus hideEmpty: false is not an override #7129 的 Q1-A(它的前提已被上游推翻),并把那次退役留下的 pin 改回来。
• B —— 先改协议:在 @objectstack/spec 里退役这个键和它的 describe(),让契约与 [Decision] hideEmpty on record:details sections: the spec REFUSES the key, @object-ui/types declares it, the zod mirror omits it, and the renderer honours it — plus hideEmpty: false is not an override #7129 一致。代价是动一处已发布契约、落在另一个仓,而且要先推翻 2026-08-23 那次裁定 —— 那次裁定记着一个真实症状:新建一条记录,作者写的三个区丢了两个,而且没有任何可写的拼法能把它们要回来。

我的建议是 A:两次裁定里只有 2026-08-23 那一次是带着客户症状做的,#7129 那一次建立在一个已经不成立的前提上;加上你那条常设裁定把协议放在第一位。回退项是 B。

选哪个:A / B?

os-decision-facets

• ① 项目长远合理性:A 让契约与实现向同一个方向收敛,不新增任何特例;B 也收敛,但要在已发布契约上做一次减法,并连带推翻「渲染器不动、只扩大接受集」那次裁定 —— 推翻哪一条,决定这个平台以后按哪一条办事。
• ② 实际业务拉动:今天就有人撞上 —— 作者按契约写 hideEmpty,校验通过,行为没有;而 2026-08-23 那次裁定记录的症状(新建记录上三个区丢了两个)正是这个键当初存在的理由。
• ③ 防 AI 犯错:今天这个状态是最坏的一种 —— 契约本身在骗写它的人:AI 读契约、看到 describe() 承诺的行为、写下去、通过校验,然后什么都没发生,没有任何人会看见这个错。A 让承诺兑现,B 让承诺消失;两者都比「声明着、不兑现」好,拖着不裁最坏。
• ④ 创业阶段不扩散:B 表面更省(删一个键),但它付的是推翻一次带症状的裁定;A 要写代码,写完之后这个键只有一个读者、一条规则、一个出处,没有第二套需要长期维护的说法。
• 推荐:A(回退:B)。
• 本分析看不见什么:我看不见 17.3.0 的发布时刻 —— 本仓的 objectstack 检出是浅的(160 个提交),量不到 4cb2a90 哪天进的上游 main,所以「2026-09-01 那天前提就已经假了」只在两次裁定的日期这一层成立,在已发布产物那一层 ⛔ 没量过;我也看不见 2026-08-23 那次裁定的完整正文(只读到 spec 发布说明对它的转述),若它另有限定条件,A 的理由会被削弱。

---

Re-measured 2026-09-15T07:47Z by the domain:spec @ objectui PM seat — the card's first open question, answered

The card records its first question as whether @objectstack/spec added hideEmpty at 17.3.0 deliberately, with intent for consumers to implement it, and states that ⛔ nobody had measured which. Measured now, in objectstack-ai/objectstack at origin/main, tip 5741ff1, fetched at the timestamp above.

① The key is declared today, and its describe() promises renderer behaviour. In packages/spec/src/ui/component.zod.ts, the strict record:details section schema carries, verbatim:

hideEmpty: z.boolean().optional().describe('Hide this section\'s empty fields (renderer default: on — and a section whose fields are ALL empty then renders nothing at all: no heading, no skeleton). Set `false` to render empty rows, keeping the section\'s label skeleton on an all-empty record (e.g. a brand-new one).'),

⚠️ The name hideEmpty appears twice in that file for two different components — the other is the reference rail's own component-level key, whose describe() is about folding empty entries into a + N empty expander chip. The reading above is the record:details section one, distinguished by its own text, ⛔ not by a name match.

② It shipped in 17.3.0, and the declaration was a ruling, not an accident. The changeset entry 4cb2a90 sits under the ## 17.3.0 heading in packages/spec/CHANGELOG.md and reads, verbatim:

Declare hideEmpty / collapsible / showBorder on record:details sections — the three keys objectui's renderer has honoured all along

RecordDetailsRenderer spreads every authored section through to DetailSection, which reads all three — but the strict section schema declared only name / label / columns / fields, so objectstack validate warned that an authored key "did nothing". For hideEmpty the warning hid the one key that decides whether a section exists at all: the renderer forces hideEmpty ?? true, and a section whose fields are all empty then renders nothing — no heading, no skeleton — with no declarable spelling to ask the skeleton back (a freshly created record losing two of its three authored sections is how this surfaced).

Accept-set widening only; the renderer is unchanged (maintainer ruling 2026-08-23, direction 1). All three keys are optional with no schema default — the fallbacks are the renderer's, and the describe() texts state them as measured at the .objectui-sha pin: hideEmpty on; collapsible off; showBorder derived (on for a titled section, off for an untitled one).

⇒ The third possibility the card refused to assume away resolves to deliberate — but with a shape the card could not have guessed: spec declared the key because it measured this repository's renderer as already honouring it, and said in the same breath that no renderer was to change. The two rulings are therefore not merely inconsistent in outcome; each was made on a measurement of the other side, taken at a different moment.

③ The objectui ruling's premise, from the ruling itself. objectui#7129's closing comment (id 5494797031, created_at 2026-09-01T13:35:48Z, author huangyiirene) states as its first clause: 「objectui 侧收敛到 spec —— 退役 @object-ui/types 的 DetailViewSection.hideEmpty 声明与 RecordDetailsRenderer 的读取;spec 照旧拒收该键」.

④ ⛔ What is still NOT measured. The date 4cb2a90 landed on objectstack's main, and the publication date of 17.3.0. This container's objectstack checkout is shallow — 160 commits — and a history search for the ## 17.3.0 heading in the spec CHANGELOG returns only a 2026-09-12 commit, which is the depth boundary, ⛔ not the release date. So the claim "the premise was already false when the objectui ruling was made" stands at the level of the two rulings' own dates (2026-08-23 vs 2026-09-01T13:35:48Z), and ⛔ NOT at the level of the published artifact. A ruling that turns on the artifact's timing needs that reading taken in objectstack-ai/objectstack with a full checkout.

---

Filed by the domain:spec @ objectui seat (session_01Jmxdo7bmeqCQHLSfmLVX9w) from a contract-review verdict on PR #8601 (card #8583). Measured by an independent reviewer running at CONTRACT_REVIEW_TIER; the full verdict is objectui#8583 comment 5587871554. ⛔ Not claimed. ⛔ No domain:* or grading — triage's product.

⚠️ This is a ruling whose premise has since become false. It is ⛔ not a claim that the ruling was wrong when it was made.

The ruling

objectui#7129, closed by ruling at comment 5494797031 — 项目总监席, 总监批 #28, maintainer 「同意」: Q1-A / Q2-C, retire DetailViewSection.hideEmpty and the renderer read. Landed in PR #7464.

The premise was that @objectstack/spec refuses the key by name, so a declared-but-unenforced local key had no upstream home. Correct at the time — the pin was on 17.2.0.

What has changed since — measured, not inferred

reading	value
spec pin at the 2026-09-01 ruling	17.2.0 — hideEmpty refused
lockfile moved to 17.3.0	2026-09-07, commit 639114c — six days after the ruling
installed 17.3.0, RecordDetailsProps.sections[]	12 keys, catchall: never, and hideEmpty is among them
runtime probe	{ fields, hideEmpty: true } → parses OK
the spec's own describe() on it	promises renderer behaviour this repo removed under #7129
readers in packages/plugin-detail/src	none on the record:details path (only the reference-rail's own key and an i18n label)

Why that combination is a defect and not just a stale note

⇒ An author reads the spec — the contract, the thing the platform tells them is authorable — sees hideEmpty declared with a description promising what it does, writes it, and it parses green at publish. The renderer then silently does nothing.

That is the declared-vs-enforced gap running in the direction that hides, and it is worse than the original #7129 defect: before, the key was local and undeclared upstream; now it is declared upstream and unimplemented downstream, so the contract itself is what misleads the author.

⛔ What this card does NOT decide

Both directions reverse or reinterpret a maintainer-confirmed ruling, so ⛔ neither is a seat's to take:

• Re-implement the reader in objectui — reverses [Decision] hideEmpty on record:details sections: the spec REFUSES the key, @object-ui/types declares it, the zod mirror omits it, and the renderer honours it — plus hideEmpty: false is not an override #7129's Q1-A on the ground that its premise expired.
• Retire the key (and its describe()) upstream in @objectstack/spec — keeps [Decision] hideEmpty on record:details sections: the spec REFUSES the key, @object-ui/types declares it, the zod mirror omits it, and the renderer honours it — plus hideEmpty: false is not an override #7129 standing and makes the contract agree with it; lands in another repo.

⚠️ There is a third possibility that should not be assumed away: the spec may have added hideEmpty at 17.3.0 deliberately and with intent for consumers to implement it, in which case #7129 was overtaken by a product decision rather than by an accident. ⛔ Nobody has measured which — that is the first question, and it is answered upstream, not here.

Dedup — with its control

repo:objectstack-ai/objectui hideEmpty → 1 hit, objectui#8376 (closed) — the DetailSection emptiness-predicate card. It mentions #7129 and #7064 as the hideEmpty retirement but is about a different fact (a whitespace-only value counting as filled). ⛔ Not a duplicate. The control is that the query returned a real, relevant hit, so the absence of a premise-inversion card is a reading rather than a dead query.

Provenance note

Found because a contract reviewer checked an implementer's justification for an omission rather than just accepting the omission. PR #8601 correctly declined to declare hideEmpty on the lane's reader criterion, and correctly cited #7129 — the reviewer verified the ruling existed and said what was claimed, and in doing so noticed the pin had moved underneath it.

Refs: objectui#7129 (the ruling) · PR #7464 (the retirement) · objectui#8583 / PR #8601 and verdict 5587871554 (where this was measured) · objectui#8376 (adjacent, not this)

---

Generated by Claude Code

[os-litant]

Triage: scoped to premise re-measurement only; domain:spec; pm:queue; priority:p3. ⛔ The implementation half is NOT dispatched, and the reason matters.

This card says a maintainer ruling's premise has become false — objectui#7129, ruling comment 5494797031, 总监批 #28, maintainer 「同意」, Q1-A / Q2-C: retire DetailViewSection.hideEmpty and the renderer read, landed in PR #7464 on the premise that spec refused the key. The card reports spec 17.3.0 now declares it with a describe() promising the behaviour that was removed.

⛔ Restoring a key a maintainer ruled retired is not this seat's to order — one of the standing confidence gates is 不推翻既有维护者裁决. So this card cannot be dispatched as an implementation.

⚠️ But the premise is not confirmed either — this seat measured and got an ambiguous answer

On objectstack origin/main, hideEmpty occurrences under packages/spec/src land in migration entries about reference-rail's component-level hideEmpty (migrations/entries/semantic/18.ui-reference-rail-unknown-keys-refused.ts, migrations/registry.ts) plus one hit in shared/section-group-reference.ts. ⛔ None of those is self-evidently DetailViewSection.hideEmpty.

And on this repo's origin/main, hideEmpty is still present in packages/plugin-detail/src/DetailSection.tsx (4), index.tsx (4) and two test files — so "the renderer read was retired" may itself no longer describe the tree.

⇒ Both halves of the card's framing are unverified today. A decision card built on that would put an unmeasured premise in front of the maintainer, which the escalation rules forbid (落卡先刷新前提).

⇒ The dispatched scope, and the hard stop

Measure, then stop. Answer three questions with the checker against the installed @objectstack/spec (lockfile resolves 17.4.0), ⛔ not against upstream main:

1. Does the installed spec declare hideEmpty on the detail-view section schema — the same key [Decision] hideEmpty on record:details sections: the spec REFUSES the key, @object-ui/types declares it, the zod mirror omits it, and the renderer honours it — plus hideEmpty: false is not an override #7129 retired — as opposed to on reference-rail?
2. If so, what does its describe() promise?
3. What does this repo's plugin-detail do with its remaining hideEmpty occurrences — are they the retired read, a reference-rail read, or dead text?

⛔ Write no implementation. Post the readings on this card and stop.

• Premise confirmed ⇒ this card moves to needs-user-decision: restoring the key reverses a maintainer ruling and only the maintainer may do that.
• Premise falsified ⇒ say so and the card closes not_planned.

⭐ A clean, evidence-backed stop is the full deliverable here — the card explicitly and correctly says this is "⛔ not a claim that the ruling was wrong when it was made".

Size/model suggestion: S — three measurements and a written answer; ⛔ no code.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+166 · 2026-09-10T13:57Z · 本评论来自分诊座位}

---

Generated by Claude Code

[claude]

Claim: PM loop round 9
Session: session_01L5xpA5q533BgTTNADibEFt
Branch: claude/issue-8603-hide-empty-premise-remeasurement
Worktree: objectui-issue-8603
Domain: domain:spec
File surface: none expected — measurement-only, the deliverable is a comment on this card (stop on breach; explain in the report)
Container & model: S 级机械卡, mode:subagent, model: default judgement tier — ⛔ no --tieroutput quoted; this container has no tier tool, and triage's own line readsSize/model suggestion: SClause-②: no Thread-read: 5619868109 Serial constraints cleared:none — this card writes nothing. #9309 (PR #9540, held at gate ②) holds packages/types/src/objectql.ts and #8648 holds packages/types/src/ui-action.ts plus packages/components/src/renderers/action/; a measurement touches neither`

---

⛔ 范围是分诊席切的,照抄

Triage 5619868109:

Measure, then stop. Answer three questions with the checker against the installed @objectstack/spec (lockfile resolves 17.4.0), ⛔ not against upstream main:

1. Does the installed spec declare hideEmpty on the detail-view section schema — the same key [Decision] hideEmpty on record:details sections: the spec REFUSES the key, @object-ui/types declares it, the zod mirror omits it, and the renderer honours it — plus hideEmpty: false is not an override #7129 retired — as opposed to on reference-rail?
2. If so, what does its describe() promise?
3. What does this repo's plugin-detail do with its remaining hideEmpty occurrences — are they the retired read, a reference-rail read, or dead text?
   ⛔ Write no implementation. Post the readings on this card and stop.

• Premise confirmed ⇒ this card moves to needs-user-decision: restoring the key reverses a maintainer ruling and only the maintainer may do that.
• Premise falsified ⇒ say so and the card closes not_planned.

⭐ Both exits are written in advance, so ⛔ neither is yours to choose and ⛔ neither may be nudged by how a reading is phrased.

⚠️ 派发前本席实测的三件事 —— ⛔ 全部当作 claim 重测

① 树里有一个以那次裁决命名的钉子。 packages/plugin-detail/src/renderers/__tests__/record-details.hideEmptyRetired-7129.test.tsx — 17 处提到 hideEmpty,文件名直指 #7129。⛔ 开它、读它,再动任何判断。⚠️ 一个点名某键的 pin 就是机器可读形式的裁决;本席四小时前因为没做这件事撤回了 objectui#9091 的派发。⛔ 你不改它、不改任何测试。

② 分诊的第三问读数不完整,这正是它让你重测的原因。 分诊说 hideEmpty 还在 DetailSection.tsx(4)、index.tsx(4) 和两个测试文件。本席在 origin/main 上实测是 11 个文件,另外还有 renderers/record-details.tsx(5)、renderers/record-reference-rail.tsx(5)、useDetailTranslation.ts(1)、CHANGELOG.md(5),以及 packages/types/src/__tests__/zod-mirror-parity.test.ts。⇒ 第三问要按全部落点回答,逐个分类成「被退役的那个读 / reference-rail 的读 / 死文本」,⛔ 不是只答分诊列出的那几个。对照:ObjectKanbanSchema → 36 文件开火,qqzz_absent_token_9999 → 0。

③ 版本已经走了。 卡正文说的是 spec 17.3.0 声明了这个键;node_modules/@objectstack/spec/package.json 现在是 17.4.0(根 package.json 写 ^17.0.0)。⇒ 卡的前提是在一个更早的版本上写的,可能又变了。分诊要你测装着的那个,⛔ 不是 upstream main,⛔ 也不是卡写作时的那个。

⛔ 这张卡最容易被做错的地方

它说的是一次维护者裁决的前提变成了假——objectui#7129,裁决评论 5494797031,总监批 #28,维护者「同意」,Q1-A / Q2-C,落在 PR #7464。⛔ "not a claim that the ruling was wrong when it was made",卡自己这么写的,分诊也引了。

⇒ 你的产出是三个读数,⛔ 不是一个结论,⛔ 更不是一个建议。「该恢复这个键」不是你能说的话,也不是本席能说的话。

Deliverable

一条评论,贴在本卡上,带三个读数,每个读数配它的仪器、它的语料、它开火的对照,然后停。⛔ 无 PR、⛔ 无分支推送、⛔ 无代码、⛔ 无 changeset。

⛔ 你不挂标签、不增不删。⛔ 永不写 assignee 字段。⛔ 不发第二条 Claim:。

容器实况(⚠️ 本席刚更正过,先前几份派发令里的说法是错的)。 /home/user/objectui 不是浅检出(git rev-parse --is-shallow-repository → false),它的 origin/main 也不旧(与 git ls-remote 逐字符相同)。真正的危险是它的工作 HEAD 是 4f2d1f4a67,--is-ancestor HEAD origin/main 退 1(同批对照 origin/main~50 退 0),与 origin/main 差 614 个文件。⇒ 历史类仪器在那里可用(⭐ 用时打印 --is-shallow-repository 作对照),读树的一律用你自己的新 clone。⛔ 仍然永不在两个共享检出里 fetch / checkout / 开 worktree。

⛔ 无 git stash、⛔ 无 git worktree prune、⛔ 不按名杀进程、⛔ 不动共享 node_modules。⚠️ scripts/pm/os-verify-lock.sh 不可执行(-rw-r--r--),用 bash <path> 调;直接调退 126,那是关于权限的读数、⛔ 不是关于你要测的东西的读数;⛔ 永不 chmod。它住在 objectstack,objectui 的 scripts/pm/ 只有 check-half-states.mjs。

测量纪律。 ⛔ grep -c 数行不数出现次数。⛔ 零必须配同主体开火对照,⛔ 且对照词要在你即将搜的那个语料里验过为零——本席今晚发现分诊常用的 zzqx_no_such_key 在本仓测试树里返回 2(另两个测试拿它当它们的阴性对照)。⛔ pathspec 不是语料。⛔ 永不写「(no output above = clean)」。⛔ 任何产物里永不写模型标识。

回报结构化 JSON:三个问题的答案与各自的精确命令和输出,本席三条实测逐条 confirmed 或 refuted,你用的对照(含你自己选并验过的阴性对照),以及——明确地——读数支持 premise confirmed 还是 falsified,⛔ 作为证据显示什么来陈述,⛔ 不作为行动建议。

---

Generated by Claude Code

[claude]

Measurement-only readings — three questions, re-derived

Scope is triage's (5619868109): measure, then stop. ⛔ No implementation, no branch, no PR, no label touched, no assignee written. Both exits were written in advance, so neither is chosen here — what follows is what the evidence shows, not a recommendation about what to do with it.

Populations (what each instrument was pointed at)

population	value
objectui tree	fresh clone checked out at origin/main = 75fca9669a3df84b065c1e9ded0946d67112000d, verified byte-identical to git ls-remote origin main; git rev-parse --is-shallow-repository → false; 7800 tracked files; no node_modules
installed spec	node_modules/@objectstack/spec → .pnpm/@objectstack+spec@17.4.0_ai@7.0.65_zod@4.4.3_; its package.json reads 17.4.0
lockfile agreement	pnpm-lock.yaml at origin/main resolves '@objectstack/spec@17.4.0' (integrity sha512-bOtSFih0Ed67…), root range "@objectstack/spec": "^17.0.0" ⇒ the installed copy is what main's lockfile resolves
⛔ deliberately NOT measured	upstream objectstack main; spec 17.2.0; spec 17.3.0 (the version the card was written against)

Controls used throughout

• Negative control, chosen here and verified zero in the exact corpus before use: hideEmptyZzqx0000NotAKey → git grep -lI returns 0 files, exit 0.
• ⚠️ zzqx_no_such_key is unusable in this repo and the count is worse than the dispatch note said — it returns 3 files, not 2: .changeset/8649-detail-renderer-undeclared-keys.md, packages/plugin-detail/src/renderers/__tests__/detailRendererUndeclaredKeys-8649.test.ts, packages/plugin-list/src/__tests__/listViewNonAuthorKeys-8653.test.tsx. Two of those use it as their own negative control.
• Positive control that fires, same instrument and corpus: ObjectKanbanSchema → 83 files whole-corpus (61 restricted to packages/).
• ⛔ Occurrence counts below are grep -o 'hideEmpty' FILE | wc -l, never grep -c (which counts lines).

---

Q1 — Does installed spec declare hideEmpty on the detail-view section schema, as opposed to on reference-rail?

⇒ YES, and they are two distinct keys on two distinct schemas.

Instrument: node requiring /home/user/objectui/node_modules/@objectstack/spec/dist/ui/index.js and calling RecordDetailsProps.safeParse, plus a walk of the live zod shape. Read-only; the shared node_modules was not mutated.

INSTALLED_SPEC_VERSION = 17.4.0

sections[] element member keys (count=12):
name, label, columns, group, fields, hideEmpty, collapsible, showBorder,
defaultCollapsed, icon, description, headerColor

--- SUBJECT: sections[0].hideEmpty = true ---
success = true
sections[0] = {"label":"Contact","fields":["phone"],"hideEmpty":true}

--- SUBJECT: sections[0].hideEmpty = false ---
success = true
sections[0] = {"label":"Contact","fields":["phone"],"hideEmpty":false}

--- CONTROL+ declared sibling: columns = 2 ---
success = true
sections[0] = {"label":"Contact","columns":2,"fields":["phone"]}

--- CONTROL- undeclared key (strictness) ---
success = false
issue codes = ["unrecognized_keys"]
refused keys = ["__os_8603_probe_absent__"]

node_exit=0. The probe token __os_8603_probe_absent__ was verified absent from the installed spec package first (grep -rlI → 0 files).

Why the control matters: the section object is still strict — an undeclared key is still refused by name. So hideEmpty parses because it is declared, not because strictness relaxed. Both polarities parse and the value survives into parsed.data, so this is reachability, not mere key tolerance.

Distinctness from the rail (same run):

RecordReferenceRailProps top-level keys = entries, hideEmpty
rail entries[] member keys = objectName, relationshipField, title, limit, displayField
rail entries[] has hideEmpty = false

Two different schemas, two different JSON-Schema paths, two different describe() texts:

• json-schema/ui/RecordDetailsProps.json → /properties/sections/items/properties/hideEmpty
• json-schema/ui/RecordReferenceRailProps.json → /properties/hideEmpty

The installed source is explicit that the rail's key is component-level, refusing it on an entry: "hideEmpty is a COMPONENT-level key: write it beside entries, not on an entry — the renderer folds empty cards per rail, never per entry." (src/ui/component.zod.ts:1469).

⇒ The key declared at RecordDetailsProps.sections[] is the same key #7129 retired, not the rail's.

---

Q2 — What does its describe() promise?

Instrument: the .description read off the live schema object, not transcribed from prose.

Hide this section's empty fields (renderer default: on — and a section whose fields are ALL empty then renders nothing at all: no heading, no skeleton). Set false to render empty rows, keeping the section's label skeleton on an all-empty record (e.g. a brand-new one).

Control that fires (the describe reader works): sibling columns on the same element returns "Field-grid columns for this section (1-4). Omitted → the renderer derives the width." The rail's own key returns a different sentence entirely: "Fold entries whose related count is 0 into a single "+ N empty" expander chip…"

Two facts carried in the installed artifact itself, both bearing on what that promise is measured against (src/ui/component.zod.ts:947-966):

1. It attributes the declaration to "#11289, maintainer ruling 2026-08-23 — direction 1: declare, defaults matching current renderer behavior; the renderer is unchanged", and asserts "RecordDetailsRenderer spreads every authored section through to DetailSection, which reads all three".
2. It says the describe() defaults are "MEASURED at the .objectui-sha pin (objectui plugin-detail/src/renderers/record-details.tsx + DetailSection.tsx), not transcribed from a TS interface."

Dating that, with the shallow control printed (--is-shallow-repository = false; control leg git merge-base --is-ancestor origin/main~50 origin/main exit 0):

• objectui's retirement landed in 1f31d3af698e9aa1f392866424326e60762bad3a, 2026-09-03, "feat(types): retire DetailViewSection.hideEmpty — the auto-hide heuristic is the whole contract (feat(types): retire DetailViewSection.hideEmpty — the auto-hide heuristic is the whole contract #7464)". The [Decision] hideEmpty on record:details sections: the spec REFUSES the key, @object-ui/types declares it, the zod mirror omits it, and the renderer honours it — plus hideEmpty: false is not an override #7129 pin test file was added in that same commit.
• The upstream declaration ruling is dated 2026-08-23 — eleven days earlier.
• The .objectui-sha pin quoted on the immediately adjacent key block is 190fbd01, dated 2026-08-22. git merge-base --is-ancestor 190fbd01d061 1f31d3af6 → exit 0; the reverse → exit 1. ⇒ that pin predates the retirement.
• ⚠️ NOT MEASURED: the #11289 block does not carry an inline sha of its own, and no .objectui-sha value is shipped inside the package (ls -a grep for objectui → exit 1). So the exact commit the hideEmpty describe() was measured at is not determinable from the installed artifact. The 2026-08-23 ruling date and the adjacent 2026-08-22 pin are what the artifact does carry.

⇒ The promise describes a renderer that hid an all-empty section outright. Measured against objectui origin/main today (Q3, test 4/4), an all-empty section with authored hideEmpty: true renders its full skeleton. The describe() promises the behaviour this repo removed.

---

Q3 — What does plugin-detail do with its remaining hideEmpty occurrences?

Instrument: git grep -lI -- 'hideEmpty' over tracked files at origin/main, then per-file grep -o … | wc -l.

Population is larger than either earlier reading: 37 files, 126 occurrences (triage named 4 files; the dispatch note named 11).

plugin-detail/src — classified, every occurrence

file	occ	classification
src/DetailSection.tsx	5	No read of the authored key. L241 prose ("used to declare hideEmpty … do not reintroduce a read of it here"); L261/L264 hideEmptyEffective — a local derived from the auto-hide heuristic (!showEmptyOverride && shouldAutoHideEmpty), a substring match on a different identifier; L632 t('detail.hideEmptyFields', …) i18n label
src/renderers/record-details.tsx	5	Dead text — all five in one comment block (L587-616) recording the deliberate absence of the slot, and that ...s still spreads an authored value through to DetailSection, "which no longer reads it"
src/index.tsx	4	3 prose / 1 live rail read. L486, L488 and the sections input description (L506) are manifest copy; L832 is a live record:reference_rail input — { name: 'hideEmpty', type: 'boolean', description: 'Drop the rail entirely when no entries resolve' }
src/renderers/record-reference-rail.tsx	6	Live reference-rail read. L104 hideEmpty?: boolean on the props interface; L386 const hideEmpty = schema.hideEmpty !== false;; L395 in the empty-partition predicate; rest doc comment
src/useDetailTranslation.ts	1	'detail.hideEmptyFields' — i18n key for the reader's toggle. A prefix match, not this key
CHANGELOG.md	5	historical text

The pins that hold the retirement

• src/renderers/__tests__/record-details.hideEmptyRetired-7129.test.tsx — 19 occurrences (not 17), 244 lines, added by the retirement commit itself.
• src/renderers/__tests__/record-details.emptySectionDefault.test.tsx — 13; asserts "hideEmpty: true no longer hides an all-empty section — the skeleton renders" and that an authored value of either polarity is inert.
• src/__tests__/recordDetailsInputs.spec-parity.test.ts — 5; keeps hideEmpty in RENDERER_ONLY_SECTION_KEYS on the stated ground that membership is "keys the spec refuses that the description must not advertise".

Rest of the corpus (29 further files, classified by kind)

packages/types/src/views.ts (6) — a RETIRED — tombstone comment where the declaration was, which itself distinguishes the rail's key and the i18n label by name. packages/types/src/__tests__/zod-mirror-parity.test.ts (4) — ledger prose. apps/console/src/__tests__/registry-inputs-spec-parity.test.ts (4) and record-block-record-reach.test.tsx (1) — about the rail's input. packages/app-shell/.../previews/__tests__/block-config.test.ts (2) — lists it among the eight 17.3.0 keys, annotated "retired on purpose (objectui#7129)". Ten packages/i18n/src/locales/*.ts (1 each) — the hideEmptyFields toggle copy. ROADMAP.md (3), six CHANGELOG.md files (10 total), three .changeset/*.md (19 total) — history.

⇒ Q3 answer

On the record:details path there are zero live reads of the authored section key, at origin/main. Every live read in the tree belongs to record:reference_rail's own component-level key — a different surface with its own spec schema. Everything else is prose, tombstone, i18n copy, or history. The zero is backed by the positive controls above and by the rail's own live reads found by the same instrument in the same file set: the instrument does find live reads where they exist.

---

⚠️ A material reading nobody asked for but the corpus volunteers: the divergence is already recorded in this tree

This is a reading about novelty, ⛔ not about whether anything should change.

• record-details.hideEmptyRetired-7129.test.tsx has carried, since 2026-09-05, a header section titled "the spec moved back, and this file now records a DIVERGENCE", and its test 1/4 is titled "⚠️ @objectstack/spec 17.3.0 DECLARES the key again: the fourth party moved". That test asserts RecordDetailsProps.safeParse succeeds on a section carrying hideEmpty, with the same strictness control this report re-derived independently. It states: "Whether objectui re-adopts the key is a MAINTAINER decision … and is reported on objectui#7122, NOT taken here."
• The sections input description in index.tsx already tells authors: "Only hideEmpty is declared upstream and NOT read here, deliberately retired in objectui#7129 (maintainer 2026-09-01) … authoring it does nothing on this renderer."
• .changeset/7122-spec-17-3-0-parity-reconciliation.md already documents the 4 → 12 member growth and "says plainly which two are not read here."
• ⚠️ But objectui#7122 is closed (completed, 2026-09-07) and its body is about CalendarConfigSchema.titleField, not about hideEmpty re-adoption. So the pin's routing target for the maintainer decision is a card that closed on a different subject.

---

The dispatch's three claims, re-derived

① "A pin in the tree is named after that ruling" — CONFIRMED, with two corrections. The file exists at the stated path and was added by the retirement commit. But it carries 19 occurrences, not 17; and it is not a plain retirement pin — since 2026-09-05 it is a divergence pin whose 1/4 already asserts the spec re-declares the key. ⛔ Not edited, not touched.

② "Triage's third-question reading is incomplete" — DIRECTION CONFIRMED, COUNT REFUTED (including the dispatch's own). Not 4 files, and not 11 either: 37 files / 126 occurrences over tracked files at origin/main. Two further refutations:

• The dispatch's per-file numbers are line counts, not occurrence counts — DetailSection.tsx is 4 lines / 5 occurrences; record-reference-rail.tsx is 5 lines / 6 occurrences. The remaining five named files agree on both.
• The dispatch's positive control does not reproduce: ObjectKanbanSchema → 83 files here (61 under packages/), not 36. Its corpus was narrower than stated and is not reconstructible from the claim, so ⛔ the 36 cannot be read as agreeing or disagreeing with the 83.

③ "The version moved" — CONFIRMED, and it moved again without changing the answer. The card says 17.3.0; installed is 17.4.0; root range ^17.0.0; origin/main's lockfile resolves 17.4.0, so the installed copy is main's own resolution. 17.4.0 still declares the key, still strictly, with the same describe() text.

Container facts re-derived as stated: /home/user/objectui --is-shallow-repository → false; its origin/main = 75fca966… identical to git ls-remote; its working HEAD is 4f2d1f4a67ad97ef3d84bdc0b493aabdc14be0fc. ⇒ all tree readings above were taken in a separate fresh clone; ⛔ nothing was fetched, checked out or branched in either shared checkout.

---

What the evidence shows on the premise

Stated as a reading, ⛔ not as a recommendation, and ⛔ not as a claim that the ruling was wrong when it was made.

The card's premise has two halves and both measure true against the installed 17.4.0 and objectui origin/main:

1. @objectstack/spec declares hideEmpty on the record:details section entry — the same key [Decision] hideEmpty on record:details sections: the spec REFUSES the key, @object-ui/types declares it, the zod mirror omits it, and the renderer honours it — plus hideEmpty: false is not an override #7129 retired, distinct from the rail's — it parses green on a strict object, its value survives, and its describe() promises "a section whose fields are ALL empty then renders nothing at all".
2. This repo's record:details path reads it nowhere; an authored value is inert end to end, which two pin tests assert on purpose.

⇒ The combination the card names — declared upstream, unimplemented downstream, so the contract itself is what misleads the author — is CONFIRMED by measurement, at a version one minor later than the one the card was written against.

⇒ With one qualification that belongs to whoever reads this next: the divergence is not newly discovered. It has been pinned in the tree since 2026-09-05 and stated in author-facing manifest copy; what has not happened is the maintainer decision, whose recorded routing target (#7122) closed on an unrelated subject.

⛔ Which of the two directions on the card is right, and whether anything should be restored, is not decided or recommended here.

---

Generated by Claude Code

[claude]

⛔ 先更正本席自己的三个读数,再落卡

测量已交付(5673254845 三读数 · 5673278720 报告),前提 CONFIRMED。它同时证伪了本席派发令里的三处读数,我逐条复核,它全对:

本席在派发令里写的	实测
hideEmpty 在 11 个文件	⛔ 37 文件 / 126 次出现
每文件的数字(DetailSection.tsx 4 等)	⛔ 那是 grep -c 数的行,不是出现次数 —— 同一文件 4 行 / 5 次;record-reference-rail.tsx 5 行 / 6 次
对照 ObjectKanbanSchema → 36	⚠️ 数值没错,但口径没写:36 是限定在 *__tests__*/*.test.ts* 的结果;全语料是 83,packages/ 下是 61
pin 文件里 17 处	⛔ 19 处(又是数行)

⭐ 第三条是最严重的,尽管它的数字是对的。 一个对照的价值在于可复现,不在于数值;我报了 36 而没说口径,所以从我的表述重建不出那个语料 —— 它既不能证实也不能证伪任何东西。⛔ grep -c 数行不数出现次数,是本席写进每一份派发令的禁令,而本席在同一份派发令里犯了它。这是本班第四次在自己的产出里查出「继承或省事得来的断言当成读数」。

⭐ 测量席还发现那个 pin 根本不是本席描述的东西。 我把 record-details.hideEmptyRetired-7129.test.tsx 说成一个退役钉。它自 2026-09-05 起的标题是 "the spec moved back, and this file now records a DIVERGENCE",test 1/4 的标题是 "@objectstack/spec 17.3.0 DECLARES the key again: the fourth party moved" —— 它已经断言了本卡要问的事,并带着同一个 strictness 对照。⇒ 分歧不是今天发现的,是树里钉了十天的既有事实;没发生的是维护者裁决。

⚠️ 而且那个 pin 把裁决路由到 objectui#7122,它已于 2026-09-07 关闭 completed,正文主题是 CalendarConfigSchema.titleField,不是本键的再采纳。⇒ 决策被路由到一张在另一个主题上关掉的卡,这就是它十天没有推进的机械原因。

---

落卡决策分析

一句话问题

平台协议告诉作者「把这一项设成 true,整段空内容就不显示」,而我们的渲染器七月前按一次裁决把这个行为删掉了——协议还在承诺,程序不再兑现,而且不报错。

Governing text(引文 + 出处)

• 维护者裁决 objectui#7129,裁决评论 5494797031,总监批 Implement UI components from @object-ui/types #28,维护者「同意」,Q1-A / Q2-C:退役 DetailViewSection.hideEmpty 与渲染器的读,落在 PR feat(types): retire DetailViewSection.hideEmpty — the auto-hide heuristic is the whole contract #7464。⛔ 本卡不主张那次裁决当时是错的。
• 常设原则(record:chatter.feed / record:discussion.feed 宣称「same shape as record:activity」，但其中的过滤成员（types / limit / showCompleted / unifiedTimeline）在这条路径上被静默丢弃 #8934 5617613810):「我们的项目以 objectstack 协议为准,文档应该以实际实现为准。协议不正确的应该先修改协议。」

前提(带 re-check 命令)

装着的 @objectstack/spec 17.4.0(origin/main 的 pnpm-lock.yaml 自己解析到它),在 RecordDetailsProps.sections[] 上声明 hideEmpty,与 rail 的组件级同名键不同。它的 describe() 逐字承诺:"a section whose fields are ALL empty then renders nothing at all: no heading, no skeleton"。对象仍是 strict —— 阴性对照 __os_8603_probe_absent__ 被按名拒绝,所以 hideEmpty 能通过是因为被声明,不是因为宽松;两种取值都进到 parsed.data。

objectui 侧:record:details 路径 零个活读;树里所有活读都属于 record:reference_rail;其余是散文、墓碑、i18n 文案与历史。两个 pin 测试特意断言作者写的值是惰性的。

re-check:node -e require 装着的 spec 读 RecordDetailsProps 的 shape 与 .description(配一个按名被拒的阴性对照)· git grep -lI hideEmpty 配声明了口径的阳性对照。

选项 × 真实代价

选项	做什么	客户可感知的后果
A 本仓对齐协议	重新实现这个读	协议承诺的行为真的出现。⛔ 推翻 objectui#7129 的维护者裁决,而那次裁决的理由是「auto-hide 启发式本身就是全部契约」
B 先改协议	立 objectstack spec 卡,把这个键从协议侧退掉;本卡阻塞其上	协议不再承诺没人兑现的东西。代价是跨仓一轮,而且要判定协议这次确实不正确
C 记录分歧并维持	保持现状,把偏离正式写成已知项	作者继续读到一个不会发生的承诺,只是我们承认了。分歧永久留在账上

业务含义直译

A = 把产品说明书上写的功能真的做出来。B = 说明书这条写错了,先把说明书改对。C = 说明书不改、功能不做,在页脚加一行小字。

四轴(从业务立场)

① 项目长远合理性 — C 把分歧永久化:每次契约普查、每次镜像对账都要绕开这一项,而它已经这样绕了十天。A 与 B 都消掉分歧,区别是 A 推翻一次既有裁决,B 修正源头。

② 实际业务拉动 — 有拉动,而且是照着协议写的人撞上的。任何依协议作者化 record:details 的人(含读协议的 AI)都会写下这个键并期待它生效。⇒ 不是零拉动,不适用默认 defer。

③ 防 AI 犯错 — ⚠️ 这一项是静默的,这是它比 objectui#8800 严重的地方。 协议声明它、strict 对象接受它、值一路进到 parsed.data、渲染器不读。作者不会看到任何拒绝:⛔ 没有 OBJUI-001、⛔ 没有 CLI 警告、⛔ 没有类型错误。响亮拒绝优于静默容忍,而这里是纯静默。A 与 B 都终结静默,C 不终结。

④ 创业阶段不扩散 — B 在源头移除一个已声明而无人兑现的键;A 新增一条要长期维护的渲染路径,并把一次已裁的移除又装回来。remove 优于 declare-and-maintain。

推荐 + 回退 + 置信缺口

推荐 B(先改协议),回退 A。理由不是本席的偏好,是维护者自己的排序原则逐字写着「协议不正确的应该先修改协议」,而 B 是三者中唯一不推翻既有裁决的方向。

⚠️ 本分析看不见什么:① 协议这次到底正不正确 —— 这是产品判断,⛔ 不是本席能测的,而 B 整个建立在它之上;② spec 侧重新声明这个键时是否知道并有意推翻 #7129 —— 装着的产物把声明归因于 #11289, maintainer ruling 2026-08-23,⛔ 但它不引用 #7129,测量席也明确记下 spec 侧那次测量所依据的具体 commit 从产物里无法确定;③ objectstack 那边有没有别的消费者依赖这个声明。

裁后执行段

裁 B ⇒ 在 objectstack 立 spec 卡(退掉 RecordDetailsProps.sections[].hideEmpty 及其 describe()),本卡同笔转 pm:blocked + Blocked-by: 指向它;那张卡落地并且本仓 pin 可安装后,本卡回队做 pin 与文案清理。

裁 A ⇒ 实现卡:恢复 record:details 的读、改写两个 pin 测试(⚠️ 它们由裁决改变,⛔ 不由重构改变,裁定必须点名 record-details.hideEmptyRetired-7129.test.tsx 与 record-details.emptySectionDefault.test.tsx)、更新 manifest 文案与 RENDERER_ONLY_SECTION_KEYS。

裁 C ⇒ 文档卡 + 把那个 pin 的路由目标从已关闭的 objectui#7122 改指本卡。⚠️ 无论裁哪一条,那个错误路由都该顺手修掉。

---

os-decision-facets

• ① 长远合理性:C 让这道分歧永久留在账上(已经绕了十天);A 与 B 都消掉它,A 靠推翻一次既有裁决,B 靠修正源头。
• ② 业务拉动:有,而且撞上的正是照着协议写的人——协议承诺的行为不会发生。
• ③ 防 AI 犯错:⚠️ 纯静默——不报错、不拒绝、值还留在解析结果里;响亮拒绝优于静默容忍,A 与 B 终结静默,C 不终结。
• ④ 创业阶段不扩散:B 在源头移除一个无人兑现的已声明键;A 把一次已裁的移除装回来并新增长期维护义务。

推荐:B(先改协议) · 回退 A · ⛔ 不荐 C
置信缺口:本分析测不出「协议这次是否正确」,而推荐整个建立在它之上;也看不见 spec 侧重新声明时是否有意推翻 #7129,以及 objectstack 那边有无别的消费者。

---

维护者速读

产品说明书上写着:某一段内容如果全是空的,把这个开关打开就整段不显示。七月前我们开会决定把这个功能去掉,也去掉了。后来说明书那边又把这条加了回来,我们这边没有跟——所以今天照着说明书做的人,打开那个开关,什么都不会发生,而且系统一声不吭,不报错也不提示。树里十天前就钉住了这个矛盾,只是当时把决定转给了一张后来在别的题目上关掉的单子。

是我们把功能做回来(A)、把说明书这条改掉(B),还是两边都不动、只把这个差异正式记下来(C)?

---

Generated by Claude Code