The opportunity's 详情 tab renders two fields out of the fourteen it authors — highlight fields are dropped and the sections left empty disappear

[os-zhuang]

Restart-when: the @objectstack/console this repo installs was built from an objectui commit containing 542718f45 (objectui PR #9627, objectui#8603 ruling A) — probe: read that release's .objectui-sha, then compare/542718f45...<sha> answers ahead or identical

The opportunity's 详情 tab renders two fields out of the fourteen it authors — every field that is also a highlight is dropped, and a section left with nothing disappears

What renders

opportunity_detail_page → 详情 / Details, on a live deal:

阶段与预测
  阶段        需求分析
  预测类别     最佳情况
创建人 Dev Admin · 1小时前   更新人 Dev Admin · 1分钟前

That is the whole tab. Two fields.

What it authors

src/pages/opportunity_detail.page.ts:115-140 — three sections, fourteen fields:

sections: [
  { name: 'info',        label: 'Opportunity Information',
    fields: ['name','crm_account','owner_id','type','lead_source','crm_campaign'] },
  { name: 'crm_forecast',label: 'Stage & Forecast',
    fields: ['stage','probability','amount','expected_revenue','close_date','forecast_category'] },
  { name: 'description', label: 'Description', columns: 1, collapsible: true,
    fields: ['description','next_step'] },
]

Of the fourteen:

• name, crm_account, owner_id, amount, close_date, probability, expected_revenue are also highlightFields, and record:details does not repeat a field the highlights already show — so they are removed from the sections;
• type, lead_source, crm_campaign, description, next_step are empty on this record and collapse into the "+ N 个为空" affordance;
• what survives is stage and forecast_category.

A section whose fields all fall into those two buckets does not render an empty shell — it vanishes. So 商机信息 and 描述 are absent from the page entirely, and the tab looks broken rather than concise.

The same shape hits case_detail_page: its 工单信息 section renders 案例编号 and "显示 3 个空字段", with 主题 / 客户 / 联系人 all lifted into the highlights.

Why it matters

This is the app's flagship record. A seller opening 详情 expecting the deal's full picture — source, campaign, type, next step, description — gets a two-row card, and there is no other surface in the page that shows those fields. The information is not hidden behind a toggle; it is simply not on the page.

Direction

The de-dup against highlights is the platform's behaviour and is reasonable on its own. What needs a decision here is what the sections should hold given that behaviour:

• author the detail sections with the fields that are not highlights (drop name / crm_account / owner_id / amount / close_date / probability / expected_revenue from them, since the highlights already carry those), so each section renders the fields it is actually responsible for; and
• keep 描述 as its own section — a deal with no description and no next step is exactly the case where an empty, promptable section is more useful than no section.

Worth doing the same read on case_detail_page and lead_detail_page in the same pass; all three were authored as if record:details and highlightFields were independent.

---

Found by driving the app as a seller in a browser against a fresh pnpm dev on 17.1.0.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 1 (hotcrm seat, session-型执行 PM)
Session: session_61f28fb9-8e31-4a6f-b4d8-10f749a092d2
Branch: claude/issue-1211-detail-sections
Worktree: hotcrm-issue-1211
Domain: (hotcrm has no domain:* taxonomy — repo-wide seat)
File surface: src/pages/opportunity_detail.page.ts, src/pages/case_detail.page.ts (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — app-side metadata only; no contract accept/reject behaviour change and no public-surface widening.
Serial constraints cleared: none. #1209/#1207 will touch src/pages/lead_detail.page.ts — a different file in the same directory; no shared barrel edit expected (no page added or removed).

Authorization — maintainer direct-dispatch channel. This card was not routed by triage; the maintainer commanded it in session, verbatim (未译, per the seat protocol):

你测试出的问题，使用 epic 项目管理技能负责派发处理

他下班了，你继续

The second line releases the round-mutual-exclusion hold that the os-sam seat's live claim on #856 would otherwise impose.

Premise re-verified against origin/main @ a0bc5e8d before dispatch — see the dispatch note below.

[os-zhuang]

{"issue":1211,"status":"done","branch":"claude/issue-1211-detail-sections","pr":"https://github.com/objectstack-ai/hotcrm/pull/1250","premise_still_valid":true,"summary":"The de-dup mechanism is confirmed against the shipped console (17.1.0 plugins-views bundle = objectui RecordDetailsRenderer/DetailSection), with one correction: record:details de-dupes against the PAGE's mounted record:highlights component (registered via HighlightFieldsContext) plus the first non-empty title candidate (primaryField -> name -> full_name -> title -> subject -> ...), NOT against the object's highlightFields property - which is why `stage` (in crm_opportunity.highlightFields) renders and `name` does not. DetailSection then returns null when every field it is left with is empty, so sections built out of duplicates disappear. The PR re-authors the opportunity and case detail sections with only the fields they are responsible for, deletes the removed `layout` key and spells `columns` as the declared string ('2'), and adds test/detail-section-dedup.test.ts to hold the class shut (lead_detail_page exempted by name - claimed by #1209/#1207 - and asserted to still exist). Measured consequence the PM should not miss: the trim is RENDER-NEUTRAL - dropHidden runs before DetailSection sees a section, so the tab looks exactly as it did; what changes is that the metadata stops promising fourteen fields it never showed. The user-visible half (an all-empty section vanishing on a record with no optional values) has no authorable lever - RecordDetailsProps.sections is strict and does not declare hideEmpty, while the renderer forces hideEmpty on - so it is filed upstream, and the one in-repo option (rebalancing what the highlights strip owns) is filed for triage. The PR says `Part of #1211`, so merging will not close this card.","tests":"pnpm typecheck -> exit 0, `tsc --noEmit` clean. pnpm validate -> exit 0; author-time warnings 86 -> 82 and `diff` of the two warning lists is exactly the four lines removed (record:details columns + layout on both pages), nothing else. pnpm build -> `Build complete` with `81 author-time warning(s)` (from 85). pnpm lint -> exit 0 (77 warnings/10 suggestions, unchanged advisory set). pnpm lint:i18n-gate -> `0 i18n/missing-* issues`. node scripts/check-source-hygiene.mjs -> `source hygiene clean`. node scripts/check-source-token-ratchet.mjs -> `source token ratchet clean`. node scripts/check-stackblitz-lock.mjs -> in sync. pnpm test -> `Test Files 1 failed | 117 passed (118)`, `Tests 10 failed | 2804 passed | 1 skipped`; the single red file is test/source-token-ratchet.test.ts, which fails identically (SyntaxError: Unexpected end of JSON input, spawned script returns no stdout) on the untouched shared checkout of main on this host - re-run there to confirm, not chased. test/case-sla-matrix.test.ts passed here. Reverse verification of the new guard: with both pages restored to origin/main @ a0bc5e8d (restoration confirmed on disk by grepping for the base field list = 1 hit and the fixed `columns: '2'` = 0 hits, not by an editor exit code), the guard turns RED with 12 highlight-duplicate offenders and 2 title-field offenders; restored to the branch it is green (5/5). All gate verdicts above are the gates' own printed lines, and the union was run on the final commit 62901921. NOTE: the shared verify lock could not be used - scripts/pm/os-verify-lock.sh --status reports `CANNOT OPERATE THIS LOCK` on this host (stock macOS has no flock), so these runs were unserialized.","open_questions":[],"out_of_scope_findings":["filed as objectstack-ai/objectstack#11289 (upstream): record:details sections cannot survive an empty record - hideEmpty/collapsible/showBorder are honoured by DetailSection but undeclared by the strict RecordDetailsProps.sections schema, and the renderer forces hideEmpty on, so an all-empty section disappears with no authorable opt-out","filed as #1247: the opportunity Details tab still shows two rows on a deal with no optional fields - the only in-repo lever is deciding what the highlights strip owns vs. the body (e.g. probability/expected_revenue); product judgement, left for triage rather than guessed","filed as #1248: both Open Tasks related lists author `op: 'neq'` where record:related_list declares `operator` from a closed enum ('not_equals'), so the filter is dropped and completed tasks are listed - contradicting the comment on opp_reference_rail that points at that list as the filtered one","filed as #1249 (finding): the record pages carry 51 author-time warnings from the spec-17 removals and undeclared props (page:header.icon, page:tabs.type -> tabStyle, item key -> value, header actions expecting strings, record:chatter flags) - configuration that silently does nothing; #1209 and #1248 already carve out two shapes"]}

[os-zhuang]

PM review — ACCEPT. PR #1250 is Part of #1211, so this card stays open, and it should.

Reviewed against the branch, the shipped console bundle's behaviour as re-derived from the diff, and GitHub — not against the report.

The dev corrected my mechanism assumption, and the correction is load-bearing

I dispatched this saying record:details de-dupes against the object's highlightFields property. That is wrong. The report says it de-dupes against the page's mounted record:highlights component (via HighlightFieldsContext) plus the first non-empty title candidate — and it names the discriminating evidence: stage is in crm_opportunity.highlightFields and still renders, while name does not. Under my version of the mechanism, stage would have vanished too. The card would have been "fixed" by deleting the one field the tab actually shows.

I reverse-verified the guard myself

The claim that matters for a new test is whether it can fail. Restored both pages to origin/main @ a0bc5e8d in a scratch worktree and ran test/detail-section-dedup.test.ts:

Tests  2 failed | 3 passed (5)
AssertionError: expected [ …(12) ] to deeply equal []   ← highlight duplicates
AssertionError: expected [ …(2) ] to deeply equal []    ← title-field offenders

12 and 2 — the exact counts in the report. On the branch, 5/5 green. The guard is not tautological.

(My first run of it went red for an unrelated reason: I had symlinked the shared checkout's node_modules, which sits at 17.0.0-rc.2, and article_feedback's unique: 'organization' only parses on 17.1.0. Harness error, mine, recorded so the next reviewer does not re-derive it.)

The consequence the report flagged is real, and it is the thing to read this card by

This PR is render-neutral. Confirmed by arithmetic against the diff and my own browser measurement of the same record: 阶段与预测 goes [stage, probability, amount, expected_revenue, close_date, forecast_category] → [stage, forecast_category], and the two survivors are exactly the two rows the tab was already showing; the four deleted were all sitting in the highlights strip (金额 180,000 / 预计成交日期 11月18日 / 成交概率 40% / 预期收入 72,000). 商机信息 loses name/crm_account/owner_id the same way and still renders nothing, because its three remaining fields are empty on that record.

So the symptom this card was filed for — 详情 renders two fields — is unchanged by merging this. What changes is that the metadata stops declaring twelve fields it never had the power to show.

That is worth merging on this repo's own terms rather than in spite of them: 「展品撒谎等于教每个照抄的 AI 撒谎」. A page authoring fourteen fields and rendering two teaches every app forked from it to author dead metadata, and the guard now makes the next instance impossible. It also deletes layout (removed in spec 17.0) and spells columns as the declared string — author-time warnings 86 → 82, with the diff of the two warning lists being exactly those four lines.

Disposition

• PR fix(ui): stop authoring detail-section fields the record page already shows (#1211) #1250 stays draft pending CI; it is Part of #1211, so merging will not close this card, which is correct.
• The user-visible half has no authorable lever in this repo — RecordDetailsProps.sections is strict, does not declare hideEmpty, and the renderer forces it on. Filed upstream as objectstack#11289. Charter working as intended.
• The one in-repo option — rebalancing what the highlights strip owns versus the body — is product judgement and was filed for triage (The opportunity Details tab still shows two rows on a deal with no optional fields — decide what the highlights strip owns vs. the body #1247) rather than guessed. Correct call; I would have rejected a PR that picked an answer here.
• Also filed: The Open Tasks related lists never filter out completed tasks: op / neq are not the spellings record:related_list accepts #1248 (both Open Tasks related lists author op: where the schema declares operator, so the filter is dropped and completed tasks are listed — a live defect, not cosmetic) and The record pages carry 51 author-time warnings from the spec-17 removals and undeclared props — configuration that silently does nothing #1249 (finding: 51 author-time warnings across the record pages). All four verified on GitHub: open, unassigned, finding only on the observational one.
• The Open Tasks related lists never filter out completed tasks: op / neq are not the spellings record:related_list accepts #1248 is worth noting against my own earlier work: I filed The lead page's Activity tab shows audit rows, not activities: types: ['crm_task'] is not a value record:activity accepts, so the filter is dropped #1209 for the same class of dropped-filter defect on the lead page's activity timeline and did not catch that the related lists had it too. Same shape, adjacent file, missed.

Note for the next round

#1209 and #1207 are still queued against src/pages/lead_detail.page.ts. #1248 touches related-list filters on the record pages and may overlap; whoever dispatches next should intersect file surfaces before claiming, and consider whether #1209 + #1248 are one family (same defect class: an undeclared filter key silently dropped) rather than two serial cards.

[os-zhuang]

PM landing note — PR #1250 merged (4bbc5f10). Card stays open, unassigned, back in the queue.

The merged PR was Part of #1211, not Fixes, so this is deliberate. What landed: the two detail pages stop authoring twelve fields they never had the power to render, the removed-in-spec-17 layout key is gone, columns is spelled as the declared string, and test/detail-section-dedup.test.ts holds the class shut (reverse-verified by the reviewer: 12 highlight-duplicate + 2 title-field offenders against the pre-merge pages, green after).

The symptom this card was filed for is unchanged — the 详情 tab still renders two rows on a deal with no optional values. That half has no authorable lever in this repo and is upstream as objectstack#11289; the one in-repo option is the product question in #1247.

Clearing pm:dispatched and the assignee so triage can re-price it against those two. It is no longer "a page authoring dead metadata" — it is "what should the highlights strip own versus the body", which is a smaller and different card than the one I filed.

[hotlong]

Triage (代扫, vacancy clause) → pm:blocked, Blocked-by: #1247. Re-priced as the landing note asked.

PR #1250 landed as Part of, which deliberately left this card open, and the landing note asked triage to re-price what remains against #1247 and objectstack#11289. Doing that now — it had no pm-state since, so it has been invisible to candidate queries for two days.

What is actually left on this card

The authoring half is done: the two pages stopped declaring twelve fields they never had the power to render, and test/detail-section-dedup.test.ts holds the class shut. That change was render-neutral, which the reviewer confirmed by arithmetic and by browser. So what remains is exactly the symptom in the title — 详情 renders two rows — and it has two independent unlocks, neither of which has happened.

⚠️ Unlock 1 (platform) — merged, and not installable. This is the trap.

objectstack#11289 is closed as completed, by PR objectstack#11662, which declares hideEmpty / collapsible / showBorder on record:details sections — precisely this card's missing lever. A sweep reading issue state would return this card to the queue on that fact. It must not.

Measured on the published tarball rather than the calendar — @objectstack/spec@17.2.0, the newest version that exists:

target	hits		control	hits
showBorder	0		record:details	80
hideEmpty	2		collapsible	116
			columns	519

showBorder is the discriminator: objectstack#11662 declares all three keys, so a release carrying it cannot have zero. The 2 hideEmpty hits are pre-existing use elsewhere in the contract, not the section schema. Timestamps agree as a secondary check only — 17.2.0 published 2026-08-23T07:00Z, objectstack#11662 merged 2026-08-24T12:32Z, over 29 hours later. The fix is in no version this repo can install.

This is the third time this lane has met the same gap between "merged upstream" and "reachable from a consumer" (#1206, #510, and now this). The Unlock-action: line on the body states the artefact-level predicate so the next sweep does not have to re-derive it.

Unlock 2 (in-repo) — #1247, going to the decision inbox in this same sweep

The one lever this repo owns is which surface carries which field, since every field is de-duped to exactly one. Moving probability and expected_revenue out of the highlights strip would let Stage & Forecast render four always-populated fields on every deal. That is a product judgement about the exemplar's UI balance, not a defect repair, and it is #1247's whole content.

⛔ Not decidable by this seat: it is not on the 代裁 list this seat holds, and it is a deliberate product call about what the flagship record looks like. Filed to the inbox with a four-prism block.

Why Blocked-by: #1247 rather than the upstream card

Both unlocks are real; the machine line points at the one that is actionable now. A maintainer ruling on #1247 can arrive today and makes this card dispatchable without any platform release. The release predicate is recorded as Unlock-action: so neither path is lost.

bug retained: the seller-visible symptom is unchanged and still real.

---

Generated by Claude Code

[claude]

Stale-pointer correction — R61 board audit (repo:hotcrm seat, session_0132iDHq4FLW2zS9VPXqbf9f)

⚠️ Blocked-by: #1247 is falsified — and has been for 11 days. #1247 is CLOSED completed, ruled by the director seat on 2026-08-31 (5480992718, maintainer verbatim 「#1247 也是平台的问题吧。元数据应用不应该考虑这些细节。」).

This card's own Unlock-action: line reads:

EITHER #1247 is ruled (the in-repo lever — what the highlights strip owns vs. the body), OR a published @objectstack/spec above 17.2.0 carries objectstack#11662 ... Either one alone makes this card actionable

Branch 1 is satisfied. ⇒ by the literal predicate this card became actionable on 2026-08-31 and nobody evaluated it. That is the #1206 pattern named on #1210 (5558911919): 「解锁谓词其实早已满足却无人求值,躺了 13 天」. Here it is 11 days.

⛔ Why this is NOT being returned to pm:queue

The same ruling that satisfied branch 1 redirected the fix and withheld the direction, item 4 verbatim:

#1211 解锁:其 pm:blocked 挂在本卡上,本裁落地即解除 —— 该卡自身走向(声明面只列渲染字段的 hygiene 修,render-neutral)由 hotcrm 车道按本裁重评,⛔ 不在此代定。

So branch 1 unlocks into a re-evaluation, not into a dispatch. And the re-evaluation turns on a hazard the ruling creates: objectui#7064 flips the empty-section default so the skeleton is retained. If that lands, more fields render — and a hygiene fix that trims the declared surface to today's rendered set would bake in the broken state it was filed against. ⛔ Doing it before that reading is known is the wrong order.

The pointer is therefore moved to the actual carrier of the fix, not deleted:

Blocked-by: objectstack-ai/objectui#7064

⚠️ Unreachable reading — ⛔ not recorded as clean

This session cannot read objectui: it is outside the configured repository scope, and attaching it for API access was denied. Per the platform-readings rule, an unreachable repo is ⛔ never treated as checked-and-clean. The reading this card needs, for whoever holds the repo:objectui seat or a session scoped to it:

gh issue view 7064 --repo objectstack-ai/objectui --json state,stateReason,closedAt,labels
# then, if CLOSED: the hotcrm criterion is RELEASED, not merged --
# confirm a published @objectstack/console (or objectui dist) carrying it is installable at hotcrm's 17.4.0 pin

⭐ #1078 (Blocked-by: objectstack-ai/objectui#6958) is blocked on the identical reading gap and should be evaluated in the same pass.

---

Generated by Claude Code