crm_lead 有三套互不相同的字段分组（fieldGroups 10 / 详情页 5 / 表单 6），详情页的 Details 标签页够不到 notes、重复管理与沟通偏好

[yinlianghui]

Restart-when: node -p "require('@objectstack/console/package.json').version" in this repo prints a version above 17.4.0 (the first console build whose objectui pin contains objectui PR #8584, merge 81a51db)
Restart-probe: re-check by ABLATION, never by version arithmetic — rewrite lead_detail_page's record:details sections to bare { group: 'FIELDGROUP_KEY' } entries in dist/objectstack.json, boot, open a crm_lead record. Control leg: the same node mutated to the enumerated fields form must render, or the rig is broken rather than the platform.

来源：#792（PR #804）实施过程中的顺带发现。#792 让我把 leads 的「记录存储的内容」表按 fieldGroups 重写、并把「9 个区块」改成实际数量；改成 10 之前先核了一遍这句话的主语，发现它在 crm_lead 上任何数字都不成立。文档那一句已在 PR #804 里改掉（不再说「详情界面有 N 个可折叠区块」），剩下的是元数据侧的问题，故单独立单。基线 origin/main = 131daf9。

事实：三套分组

声明处	分组数	分组名
src/objects/lead.object.ts:17-28 fieldGroups	10	Identity / Company Information / Contact Information / Qualification / Assignment / Address / Additional Info / Communication Preferences / Conversion / Duplicate Management
src/pages/lead_detail.page.ts:147-178（type: 'record', object: 'crm_lead'）的 record:details	5	Lead Information / Contact / Lead Detail / Address / Description
src/views/lead.view.ts:197 起的 form.sections（均 collapsible: true）	6	Contact Information / Lead Classification / Company Information / Address / Additional Information / Privacy

crm_lead 是文档化对象里唯一自带记录页的：crm_account / crm_contact 等没有 record:details 覆盖，详情页按对象的 fieldGroups 渲染，所以「区块表 = 详情页可折叠区块」这条文档约定在别处成立、只在 leads 上断了。

影响（元数据侧，不只是文档）

lead_detail.page.ts 的 Details 标签页只列了 18 个字段中的一部分，下面这些在详情页上够不到：

• notes（Notes，richtext 工作备注）——description 有独立分区，notes 没有；
• duplicate_of_type / duplicate_of_lead / duplicate_of_contact / duplicate_status——Duplicate management: soft lead dedupe instead of the hard unique email constraint #598 的整套重复管理。疑似重复线索视图把人带到记录上之后，记录页上看不到它疑似重复了谁、也看不到重复状态，只能进编辑表单（lead.view.ts 的 DUPLICATE_LINK_FIELDS）才看得到；
• do_not_call / email_opt_out——正要打电话的人在详情页上看不到「禁止致电」；
• is_converted / converted_*——转化结果只在字段组里有，详情页没有分区承载。

next_followup_date 与 last_contacted_date 同样不在 Details 分区里，而 🔥 Hot Leads 视图正是按前者排序的。

对照 #715（crm_campaign_member 的字段组被高亮条吃掉、组在详情页永不渲染，lint field-group-shadowed 报出来的那条）：这里是相反方向的同一类问题——页面自带分区，于是对象的字段组在详情页整体失效，而 lint 目前不报。

可能的处理方向（需要决定，别直接猜）

1. 让 lead_detail.page.ts 的分区回到对象的 fieldGroups（删掉 properties.sections，让详情页按字段组渲染）——恢复全仓一致的约定，代价是失去这页手工编排的取舍。
2. 保留手工编排，但补齐缺失字段（至少重复管理 + 沟通偏好 + notes）——保留编排意图，但每加一个字段就要手工同步一次，正是本类漂移的来源。
3. 认定「详情页只放常用字段」是有意的，那就该有 lint 或测试把「哪些字段组在详情页上无处可去」暴露出来（[17.0-rc2验收] crm_campaign_member 的 "Basic Information" 字段组四字段全部被提升进详情页高亮条 —— 组在详情页永不渲染(lint field-group-shadowed) #715 的 field-group-shadowed 的镜像规则），并在文档里写明详情页是取舍过的。

三条对「AI 写的元数据要难写错」这条的取向不同：方案 1 让声明处唯一，方案 3 让偏离可被检出，方案 2 两者都不给。建议先在 1 与 3 之间定调。

⛔ 本单只记录，未改任何 src/**。文档侧的那半句已随 PR #804 修好，不必重复改。

Refs #715 #792 #598

---

Generated by Claude Code

[huangyiirene]

裁决:定性为协议问题 —— 应用侧回归 fieldGroups 简化,机制归平台统一(维护者 2026-08-31)

项目总监席 · session session_01KGtaLpkW1mycWgkbSb3H6t · hotcrm 决裁批 #16 ③

维护者原话(逐字):「#806 我认为就是协议的问题，元数据应用应该是简化的业务实现，不应该编码处理这中 lint，要处理也是平台统一处理。」

裁决内容

1. 定性:三套分组漂移是协议缺口(逃生舱整体接管 + 逐字段枚举 + 零派生 + 无互检 —— 机制实测记录见本席上一轮呈报),不是应用工艺问题;
2. ⛔ 本仓不建 lint:呈报选项 C 的「镜像 lint 守卫」半边作废 —— 应用仓不编码平台级诊断,机制归平台统一;平台半边已立 objectstack#13855(lint 镜像规则 / section 差量引用形式的形状选择,候维护者定形);
3. 应用侧走简化(⚠️ 透明记录:此半边方向由「元数据应用应该是简化的业务实现」推出 —— 即卡面方向 1;一行改裁即撤):lead_detail.page.ts 的 record:details 删除手工 properties.sections,详情页回归对象 fieldGroups 派生渲染 —— 重复管理、禁止致电、notes、转化结果等全部字段组机械可达,危害就地消解,⛔ 不逐字段手补(那是方向 2,漂移的温床,不采);
4. 范围钉死:lead.view.ts 的 form.sections(录入流编排)本裁不动 —— 编辑表单的取舍(如 Privacy 分区)是另一层关切;若维护者要一并简化,一行加令即扫。

状态转移(同笔)

needs-user-decision → pm:queue;metadata 不动。

---

Generated by Claude Code

[os-sales]

Claim: PM loop round R28
Session: session_019hUuCQStzXGMFSX4dzww5t
Branch: claude/issue-806-lead-detail-derived-sections
Worktree: hotcrm-issue-806
Domain: repo:hotcrm execution seat (single-lane repo — ⛔ no domain:*)
File surface: src/pages/lead_detail.page.ts plus whichever tests assert on that page (test/detail-section-dedup.test.ts is the known neighbour). ⛔ src/views/lead.view.ts is OUT — the ruling pins form.sections as untouched (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus (⛔ fable exhausted 2026-09-02, floor opus per the standing exemption)
Clause-②: no
Serial constraints cleared: src/pages/lead_detail.page.ts sole occupant. #1508 (src/pages/*.page.ts, undeclared section keys) and #1452 (opportunity_detail.page.ts) share the directory — #1508 is pm:queue undispatched, #1452 is pm:blocked behind this very card; ⛔ neither may be dispatched while this is in flight. #1211 (pm:blocked) reads the same renderer behaviour but has no branch.

Premise re-verified on origin/main @ d3fb7ca: properties.sections is still authored at src/pages/lead_detail.page.ts:242; the ruling's named action is still undone. Three pages carry record:details (case_detail, opportunity_detail, lead_detail) — ⚠️ the card's claim that crm_lead is the only object with its own record page is false as written, and was already flagged unverified in the 2026-08-22 grading. That does not change this card's scope, but ⛔ do not reason from it.

⚠️ This dispatch carries a live premise fork — see the dispatch order. The ruling is binding; the mechanism it names is not yet measured on the pinned version.

---

Generated by Claude Code

[os-sales]

Claim (dev seat, separate from the PM claim above)

Session: session_019hUuCQStzXGMFSX4dzww5t
Branch: claude/issue-806-lead-detail-derived-sections (pushed empty at d3fb7ca as a write-route probe before the first edit)
Worktree: hotcrm-issue-806
Assignee: ⛔ not touched — PM owns that field.

File surface (declared up front, per the serialization contract): src/pages/lead_detail.page.ts, plus whichever tests assert on that page (test/detail-section-dedup.test.ts is the known neighbour) and a .changeset/*.md. ⛔ src/views/lead.view.ts is OUT of surface — the 2026-08-31 ruling pins form.sections as untouched.

First task is NOT the edit. The ruling (2026-08-31) is binding and not re-litigated here, but the mechanism it names — "delete properties.sections ⇒ the detail page derives from the object's fieldGroups" — is not yet measured on the pinned @objectstack/* 17.2.0, and two in-repo sources disagree about it (the comment block in lead_detail.page.ts says omission falls back to highlightFields; #1452's 2026-09-03 comment reports fieldGroups derivation measured on crm_forecast). I measure that on crm_lead's own page first, with a negative control, and report the measurement either way. If it falsifies, this lands as premise_still_valid: false with no PR rather than a forced deletion.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 806,
  "status": "needs_decision",
  "branch": "claude/issue-806-lead-detail-derived-sections",
  "pr": null,
  "premise_still_valid": false,
  "summary": "The ruling's DECISION is untouched; the MECHANISM it names does not exist on the pinned @objectstack/* 17.2.0, so the ruling cannot be executed as written and I stopped instead of forcing it. Measured in a real browser on crm_lead's own page: deleting properties.sections from lead_detail.page.ts's record:details does NOT make the page derive from the object's fieldGroups, and does not fall back to highlightFields either — the Details tab renders NOTHING. Baseline 6 sections / 20 field rows / 1633 chars of page text; with sections deleted, 0 sections / 0 field rows / 1072 chars, the entire body between the tab strip and the Created-by footer gone. Executing the ruling literally would therefore make this card's own harm strictly worse (20 reachable fields to 0), which is why there is no PR. Two further premise corrections. (1) The card's duplicate-management harm is ALREADY FIXED on main: #1207 landed both the record:alert banner and a duplicates section, and run A rendered DUPLICATE STATUS / DUPLICATE OF / DUPLICATE OF LEAD live on the record page. What is still unreachable on the Details tab is 10 fields: notes, do_not_call, email_opt_out, is_converted, converted_account, converted_contact, converted_opportunity, converted_date, next_followup_date, last_contacted_date. (2) BOTH in-repo sources about the mechanism are wrong: lead_detail.page.ts lines 232-235 say omission falls back to highlightFields (it does not), and #1452's crm_forecast reading is about the SYNTHESIZED detail page, where the derivation lives in the page synthesizer, not in the record:details renderer — carrying it across to an authored page is the #1440 error the dispatch warned about. Filed the false in-code comment separately as #1521. AGENTS.md 'Scope' rule 2 is dispositive on what happens next: a platform defect means WAIT for the platform fix, do not route around it, and do not split a ruling into the half that can land now. ⛔ I did not hand-patch fields (rejected option B) and ⛔ did not write a lint (voided option C). Assignee untouched; src/views/lead.view.ts untouched; no src/** file changed — the tree is byte-identical to d3fb7ca (git diff HEAD empty, blob 12a8efa7499ee0c71d9294172b0442e45365b0e1 on both sides). GitHub sanitizer: #806's body arrived complete, no truncation; only the usual entity rewriting of quotes inside code spans.",
  "tests": "MEASUREMENT (no code changed, so no pnpm verify — nothing to verify). Apparatus: pnpm build + objectstack start on port 4021 (⛔ not 4001 — a sibling agent's worktree is live in this container), headless Chromium /opt/pw-browsers/chromium via playwright-core 1.62.1, records created through the REST data API, page text read from document.body.innerText at /_console/apps/crm_enterprise/crm_lead/record/ID. FOUR apparatus gates, each of which caught a real false reading before the result stood: (g1) mutation-on-disk — anchors counted before/after (sections:[ 1 to 0, label 'Duplicate Management' 1 to 0, label 'Lead Information' 2 to 1) plus git hash-object differing from the HEAD blob; (g2) artifact gate — dist/objectstack.json's lead_detail_page record:details propKeys ['columns','sections'] to ['columns']; (g3) SERVED-metadata gate — GET /api/v1/meta/pages read back propKeys ['columns','sections'] with 6 labels in A and ['columns'] with 0 labels in B; (g4) listener-identity gate — lsof pgid of the process holding the port must equal my own setsid group. g3 and g4 are why this reading is trustworthy: my first two mutated runs BOTH reported 'no change' and both were instrument failures — run B1 because objectstack start serves page metadata from the persisted .objectstack/data DB rather than the fresh artifact (fixed by wiping the DB per run), and run B2 because the first server's grandchild process still owned port 4001 after I killed the recorded PID, so every probe was hitting a stale baseline server (fixed by setsid + pgid teardown + the listener check). RESULTS. A3-baseline (unmutated, dist and served metadata both carry 6 sections): lead Details tab renders Lead Information / Contact / Lead Detail / Address / Duplicate Management / Description, 20 field rows, len 1633. B3-mutated (sections deleted, gates g1-g4 all green): lead Details tab renders zero sections and zero field rows, len 1072; none of the object's 10 fieldGroups labels appears (Identity, Company Information, Contact Information, Qualification, Assignment, Address, Additional Info, Communication Preferences, Conversion, Duplicate Management). NEGATIVE CONTROL, run in both A3 and B3: crm_contact has no authored record page, so the console synthesizes one — it rendered the same five fieldGroups-derived headings (Identity / Account and Role / Contact Information / Additional Info / Communication Preferences), len 915 in A3 and 915 in B3. The control did NOT go the same way as the subject: the instrument can see fieldGroups-derived sections, so B3's null is a real result, not a dead probe. MECHANISM (source read, confirming the measurement rather than substituting for it): in @objectstack/console 17.2.0 the synthesizer computes sections = authored.length ? authored : sectionsFromFieldGroups(objectSchema), while the record:details renderer does sections = Array.isArray(props.sections) ? props.sections.map(normalize) : props.sections and the detail view renders sections only when non-empty and loose fields only when non-empty — both absent renders an empty body. RESTORE LEG: trap '...' EXIT INT TERM on every mutation script, restore pinned to git checkout HEAD -- ABSOLUTE_PATH, proved by git diff HEAD empty, git status empty, and disk blob 12a8efa7499ee0c71d9294172b0442e45365b0e1 equal to HEAD:src/pages/lead_detail.page.ts. TEARDOWN: my server process group killed, port 4021 free, no process left under /home/user/hotcrm-issue-806; the sibling agent's processes were never touched (⛔ no kill by process name).",
  "mcp_calls": "7 — issue_read get #806, get_comments #806, get_comments #1452, get #1211, add_issue_comment (claim), issue_write (create #1521), add_issue_comment (this report). Issue dedup for #1521 went through the REST list endpoint (repos/OWNER/REPO/issues?state=open, 87 rows, one page) plus a local grep — ⛔ no MCP search: the REST search endpoint answers 403 in this session (sessions are bound to their configured repositories), while repo-scoped REST reads answer 200.",
  "open_questions": [
    {
      "question": "The 2026-08-31 ruling's application half names a mechanism that does not exist on the pinned 17.2.0: deleting record:details' properties.sections does not make the lead detail page derive from the object's fieldGroups — it renders an empty Details tab (measured, with a negative control). The decision is binding; the mechanism is unavailable. What replaces the named action?",
      "options": [
        "A — Execute the ruling literally now: delete properties.sections. MEASURED OUTCOME: the Details tab renders nothing at all, 20 reachable fields to 0. Every field the card wants surfaced becomes LESS reachable, including the duplicate-management block that #1207 already put there. Cost: the card's own harm, amplified, shipped.",
        "B — Hand-patch the missing 10 fields into the authored sections. Explicitly rejected by the ruling as the drift's own breeding ground, and by AGENTS.md Scope rule 2 as splitting a ruling into the half that can land now. ⛔ Not mine to choose; listed only so the fork is complete.",
        "C — WAIT, and make the dependency machine-visible: leave lead_detail.page.ts as authored, move #806 to pm:blocked with Blocked-by pointing at the platform card, and carry this measurement upstream — either onto objectstack#13855 or as its sibling, since #13855 holds the LINT-mirror half and this is a different platform fact (the authored record:details surface has no fieldGroups derivation at all). Resume the original ruling unchanged once a published @objectstack/spec above 17.2.0 carries it, re-running this same probe against the new pin before acting. Cost: the 10 fields stay unreachable on the Details tab until the platform ships; the duplicate-management and do-not-call harms are NOT part of that wait — duplicates already render, and do_not_call can be raised separately if the compliance surface cannot wait.",
        "D — Mirror fieldGroups by hand: re-author the page's sections so they reproduce the object's 10 groups one-for-one. Renders correctly today and surfaces all 10 fields, but it is option B wearing option A's clothes — a second hand-maintained copy of the grouping, which is the exact declaration-vs-render split the ruling qualified as a protocol gap."
      ],
      "recommendation": "C, and I am not close to the line. LONG-TERM SOUNDNESS (the axis that must carry at least half the weight, per the 2026-09-01 ruling): AGENTS.md's Scope chapter, distilled from the same 2026-08-31 ruling batch as this card, decides it in two sentences — rule 2, 'a platform defect means you WAIT for the platform fix … ⛔ do not route around it … ⛔ do not split a ruling into the half we can land now', and rule 1, 'a gap you find in the platform is filed as a platform card upstream — ⛔ it is never compensated for in this repo'. A and D are both in-repo compensation for a missing platform behaviour; C is the shape this repo has already been told to take, and #806 is itself the named precedent for that rule. MAKING AI-AUTHORED METADATA HARD TO GET WRONG: C is the only option that ends with one declaration site. A ends with zero rendered fields and a page whose emptiness nothing warns about — the same silent-omission class as #1211 and #715, and worse because the author sees green on objectstack validate. D re-creates the two-copies-no-comparator shape verbatim. REAL BUSINESS NEED: measured and partly already met — #1207's banner and duplicates section render live today (I saw them in run A), so the compliance-critical half of the harm is NOT waiting on this card; what waits is notes / do_not_call / email_opt_out / the conversion block / the two follow-up dates. If the maintainer judges do_not_call specifically too hot to wait, that is a one-field decision to take deliberately and separately, not a reason to adopt A or D wholesale. STARTUP SCOPE DISCIPLINE: C adds nothing to this repo — no new capability, no new gate, no new hand-maintained surface; it converts an unexecutable action into a machine-visible dependency, which is the cheapest possible carrying cost. Two things the maintainer should weigh that I could not: whether the platform work should extend objectstack#13855 or stand as a sibling card, and whether do_not_call's compliance exposure buys a deliberate one-field exception to the wait. ⚠️ Whatever is ruled here governs #970 (crm_case, the same three-way drift), #1452 (opportunity_detail.page.ts, same shape, pm:blocked behind this card) and #1508 — please rule once for the class rather than per card."
    }
  ],
  "out_of_scope_findings": [
    "filed as #1521: lead_detail.page.ts lines 232-235 and 238-241 state that omitting record:details sections falls back to highlightFields (the old auto mode) — measured on 17.2.0 it falls back to nothing; load-bearing prose that is one of the two sources which produced this card's premise fork",
    "not filed, for PM to route upstream: the platform fact itself — an AUTHORED record:details that omits sections renders an empty body, because fieldGroups derivation lives only in the console's page synthesizer and not in the record:details renderer. objectstack#13855 holds the lint-mirror half of the ruling, so this belongs either on that card or beside it; I did not file cross-repo because deduping the objectstack backlog is outside this seat and the ruling already routed the platform half there. The full measurement is in this report's tests field and on #1521."
  ]
}

---

Generated by Claude Code

[os-sales]

⛔ 裁决的动作已被实测证伪 —— 决定不动,机制不存在。回决策箱,⛔ 不静默重裁

repo:hotcrm 执行席 · session session_019hUuCQStzXGMFSX4dzww5t · R28。派发时即按第三档「带前提的裁决」写死:先验前提、假则停手报分叉。前提为假,dev 正确停手,无 PR。 完整测量见本卡上一条 os-dev 报告。

测到了什么

2026-08-31 裁决的应用侧半边命令:删 lead_detail.page.ts 的 properties.sections,详情页回归对象 fieldGroups 派生渲染。在 pin 的 @objectstack/* 17.2.0 上、用真浏览器对 crm_lead 自己的记录页实测:

运行	结果
A3 基线(未改)	6 个分区 / 20 个字段行 / 正文 1633 字符
B3(删 sections)	0 个分区 / 0 个字段行 / 1072 字符 —— 页签正文整段消失

既不派生 fieldGroups,也不回落 highlightFields,而是什么都不渲染。 ⇒ 照字面执行会把本卡自己的危害从「20 个字段可达」变成「0 个可达」。

⭐ 阴性对照没有跟着走,所以这个零是结果不是死探针:同两次运行里 crm_contact(无自建记录页 ⇒ 控制台合成)稳定渲染出 5 个 fieldGroups 派生标题,A3/B3 皆 915 字符。仪器看得见 fieldGroups 派生,只是 record:details 渲染器里没有。另有四道仪器闸,其中两道当场抓出假读数(持久化 DB 供的是旧元数据;孤儿孙进程仍占端口,探针打在旧服务器上)—— 前两次「无变化」的读数都是仪器故障,被丢弃而不是被报告。

⚠️ 本卡赖以成立的两个仓内来源都是错的

• lead_detail.page.ts:232-235:说省略 sections 回落 highlightFields —— 假。已单独立卡 lead_detail.page.ts claims that omitting record:details sections falls back to highlightFields — measured on 17.2.0 it falls back to nothing at all #1521(承重假散文)。
• opportunity_detail.page.ts hand-writes 3 record:details sections — the same shape #806 was ruled on, and no card holds it #1452 的 crm_forecast 读数:那是合成详情页,派生住在页面合成器里,record:details 渲染器里没有。把它横移到自建页正是 [audit] 逃生舱约定存量审核 — 81 处 sections：冗余 16 / 可映射 5 / 真极端 58 / 孤儿 2 #1440 犯过的错。

机制侧源码确认(佐证测量,非替代):合成器 sections = authored.length ? authored : sectionsFromFieldGroups(...);而 record:details 渲染器只 map props.sections,两者皆空即空正文。

⛔ 上游修复已合并,但未发布 —— 第二次撞上同一个陷阱

平台半边并非空白:objectstack#13855 已裁 B 并实现(PR #13897,合入 39404f3d9,2026-08-31),section 从此可 group: 'contact_info' 引用字段组、经 deriveFieldGroupLayout 派生成员 —— 正是本裁「简化的业务实现 / 单一声明处」想要的形状。

但 @objectstack/spec 最新已发布版本是 17.2.0,发布时间 2026-08-23 —— 早于该修复合并 8 天。 渲染半边 objectui#7051 亦未完成(⚠️ objectui 不在本会话仓范围,403,此项为未测量而非已确认)。

⇒ 与座位贴 §3 的 #549 同一形状:已关闭的上游卡不是可用的修复,版本算术也不是。 本车道解锁判据恒为「已发布」,⛔ 永不「已合并」。

---

四维分析

一句话问题:裁决点名的动作已不存在,用什么替代它?

选项	客户可感知的代价
A 照字面删 sections	实测:详情页正文全空,20 个可达字段归零 —— 连 #1207 已经修好的重复管理区块一起消失。⛔ 已被测量排除
B 手补缺失的 10 个字段	裁决明文否掉(漂移温床),AGENTS.md Scope 规则 2 亦禁「把裁决拆成现在能落的那一半」
C 等平台发版,届时用 group: 引用形式重写分区	10 个字段在详情页上继续不可达,直到发版;单一声明处,零抄写债
D 手工镜像 fieldGroups 十个组	今天就能渲染,但这是穿着 A 外衣的 B —— 第二份手抄分组,正是本裁定性为协议缺口的那个形状

• ① 实际业务需求:真实但已部分自愈 —— A lead flagged duplicate_status: suspected looks clean on its record page, and Convert Lead never mentions it — the duplicate converts into a second account, contact and opportunity #1207 已落地重复管理横幅与分区,实测在记录页上渲染(A3 运行亲见),所以合规最重的那半不在等待中。仍不可达的是 10 个字段:notes、do_not_call、email_opt_out、转化区块四字段、两个跟进日期。⚠️ do_not_call 是其中唯一带合规面的,是否值得单独开一个一字段例外,是维护者可以单独裁的。
• ② 项目长远合理性(权重 ≥50%,2026-09-01 裁):C 是唯一以「单一声明处」收尾的选项,而且它不是本仓发明的形状 —— 它就是 objectstack#13855 同日同批裁定的 B,平台已实现。A 收尾于「零字段 + 无人告警的空页」;D 收尾于「两份手抄无比对器」,与本裁定性为协议缺口的形状逐字相同。AGENTS.md Scope 规则 1/2(与本裁同批蒸馏)对 A 与 D 直接判负:平台缺口等平台修,⛔ 不在本仓补偿、⛔ 不拆成现在能落的一半。
• ③ 防 AI 写元数据犯错:A 最坏 —— 空页在 objectstack validate 下是绿的,作者拿到的是静默省略,与 The opportunity's 详情 tab renders two fields out of the fourteen it authors — highlight fields are dropped and the sections left empty disappear #1211 / [17.0-rc2验收] crm_campaign_member 的 "Basic Information" 字段组四字段全部被提升进详情页高亮条 —— 组在详情页永不渲染(lint field-group-shadowed) #715 同类;D 复制出第二个声明面,无机器比对。C 让成员事实只有一处。
• ④ 创业阶段不扩散需求:C 对本仓零新增(无新能力、无新门禁、无新手抄面),只是把一个不可执行的动作转成一个机器可见的等待。A/D 都是在样板工程里示范错误写法 —— 展品撒谎等于教每个照抄的 AI 撒谎。

推荐:C。 四棱同向,且长远轴独自即可定案。⛔ 但本席不代裁,理由是这不是「恢复不变量」类:裁决点名的动作与 group: 引用形式是两个不同的动作,后者恰好服务同一意图。拿后者替换前者是改裁,归维护者。

需要维护者回答的,只有一句

裁决的应用侧半边,是否改为「发版后用 group: 引用形式重写 lead_detail.page.ts 的分区」? 若是,本卡的形状自此确定,只等发布;若否,请指明替代动作。

⚠️ 附带一问(dev 提出,本席认同):本裁一旦确定,同类应一次裁完 —— #970(crm_case 同款三向漂移)、#1452(opportunity_detail.page.ts 同形,现 pm:blocked 在本卡之后)、#1508 都是同一个类。逐卡裁会裁三次。

状态转移(同笔)

pm:dispatched → needs-user-decision;assignee 清除;metadata 不动。⛔ 未回 pm:queue:回队烧掉的派发注定以 premise-false 再收场一次。

⚠️ 即便裁定为 C,本卡仍不可派发,直到装得上 —— 判据是安装面探针(装上的 @objectstack/spec 是否接受 section 的 group 键),⛔ 不是 #13897 的合并状态,⛔ 不是版本号大小。

---

Generated by Claude Code