The object-aware scan surfaces 14 more inert fields, 5 of them masked by a shared name — a second enforce-or-remove ledger

[os-steve]

Ruled: 5933225770 · letter A · 2026-10-01T14:11Z

Blocked-by: objectstack-ai/objectui#11383

Produced by pnpm scan:fields, the object-aware ledger added in the PR for #1193. Filed as one card because a ledger is the unit that gets adjudicated in one sitting — #1182 handled ten rows that way — not as 14 separate issues.

crm_product.tax_rate, the fifteenth row, has its own card: #1198.

The ledger, on 62560210

inert here means the scan found no site that reads the field and no site that draws it — only carriers (locale bundles, seed values, import columns, prose). "masked" means the name is also declared on another object, so the token grep that produced #1182's row set read it as consumed and it could never have reached that card.

Field	Masked by	What the scan found
crm_campaign.description	12 other objects	4 locale rows only. Not on the campaign form — product, task, event, account, lead, case, opportunity all put description on a form; campaign does not.
crm_contract.description	12 other objects	same shape
crm_quote_line_item.description	12 other objects	same shape. Note billing-handoff.flow.ts sends a line description in its payload, but from crm_opportunity_line_item — a different object, which is the point.
crm_quote_line_item.line_number	crm_opportunity_line_item	the opportunity twin IS read (billing hand-off payload); the quote one is not
crm_quote_line_item.subtotal	crm_quote	a formula field. quote_total_rollup deliberately recomputes from raw quantity/unit_price/discount rather than reading it, and crm_quote_line_item has no view file — highlightFields is crm_product, quantity, unit_price, total_price. So this formula is evaluated on every read and displayed nowhere.
crm_account.logo	—	image field, on no form and no view
crm_article_feedback.comment	—	highlightFields is crm_knowledge_article, verdict, owner_id; the comment a reader types is stored and never shown
crm_campaign_member.added_date	—	written by campaign-enrollment.flow (two nodes stamp {NOW()}) and seeded, read by nothing and drawn nowhere — the is_taxable shape exactly
crm_contact.mailing_street	—	declared, plus an import-mapping column
crm_contact.mailing_city	—	same
crm_contact.mailing_state	—	same
crm_contact.mailing_postal_code	—	same
crm_contact.mailing_country	—	same
crm_forecast.seed_key	—	the seed externalId, by deliberate design (#613) — listed for completeness, not as a defect

Two clusters worth a verdict rather than a row-by-row pass

The five crm_contact.mailing_* fields are one decision, and the interesting one. They are on no form and in no view, yet assets/import-templates/contacts.csv and contact_import.mapping ask a customer to fill five columns whose values then become invisible in the product. That is worse than an inert field: it is inert and it asks the customer for work. Either the contact form grows a Mailing Address section or the five fields and their import columns go together. Note crm_account models its address as a single Field.address (billing_address), which renders as a unit — the same shape would collapse five contact fields into one.

The three description fields are one decision. Nine objects put description on a form; three declare it and never show it. Either those three forms gain the field or the three declarations go.

Not a gate, on purpose

pnpm scan:fields is a report, not part of pnpm verify — the argument is in the script header and in the PR for #1193. Declaring a field one PR before its consumer is ordinary, and the 2026-08-17 ruling asked for a verdict per field rather than a blanket rule. What is guarded is the scan's ability to see: test/field-consumer-scan.test.ts fails if the resolver stops distinguishing two objects that share a field name.

Reproduce: pnpm scan:fields, or pnpm scan:fields --sites crm_contact.mailing_city for one row's evidence.

Filed unassigned; no work started.

[huangyiirene]

定级（首触）→ pm:queue，按 #1182 的先例作为一张台账卡一次裁完。

按本席常设授权定级。finding 同笔摘除。

前提对 origin/main @ 6ed7b8d 抽验

pnpm scan:fields（scripts/scan-field-consumers.ts）仍在 package.json:26；crm_contact 仍声明 6 个 mailing_* 相关键。台账成立。⚠️ 实施时重跑 pnpm scan:fields 重新推导台账，⛔ 不要照抄卡片里那张表 —— 它是 62560210 的快照，本轮已经有三张卡演示了照抄快照的代价。

为什么一张卡而不是 14 张

卡片的判断对，本席采纳：台账的裁定单位是「一次坐下来裁完」，#1182 就是这么处理十行的。拆成 14 张会让每一行各自排队、各自复核，而它们共享同一个判据（ADR-0049 enforce-or-remove）与同一份证据。

⚠️ 两个簇要先裁，剩下的才是机械行

簇 A —— 5 个 crm_contact.mailing_*，这是本台账里唯一有用户成本的一条。 它们不在任何表单、任何视图上，而 assets/import-templates/contacts.csv 与 contact_import.mapping 却要求客户填这五列，填完的值在产品里看不见。这比「惰性字段」更糟：它惰性并且在向客户索取劳动。

⇒ 两条出路：联系人表单长出一个 Mailing Address 分区，或者五个字段连同导入列一起退休。⚠️ 卡片给了一条很有价值的线索：crm_account 用单个 Field.address（billing_address）建模地址并作为一个整体渲染 —— 同样的形状能把五个联系人字段收成一个。

⛔ 这一簇若倾向「表单长出分区」，那是扩大公开面 ⇒ 停手回报走决策箱；若倾向「连同导入列一起退休」，那是 enforce-or-remove 的正常执行，可以做。判据就是这条边界。

簇 B —— 3 个 description（campaign / contract / quote_line_item）。 九个对象把 description 放在表单上，这三个声明了却从不展示。同一个二选一：三张表单加上，或三条声明去掉。本席倾向去掉（轴④ + 轴③：声明了运行时不兑现的键，正是展品最不该教的），但同样：若实施者认为某一个确实该出现在表单上，那是范围外，回报。

⛔ crm_forecast.seed_key 不是缺陷 —— 卡片自己注明它是 #613 刻意设计的 seed externalId，列出只为完整性。⛔ 不要动它，也不要把它算进「已清理」的计数。

其余机械行的判据

crm_account.logo、crm_article_feedback.comment、crm_campaign_member.added_date、crm_quote_line_item.{line_number,subtotal} —— 逐行给 verdict（enforce 或 remove），每行一句理由。⚠️ 其中两行值得多看一眼：

• crm_article_feedback.comment —— 读者打字写进去的评论被存下来但从不展示。这在用户侧是有感的（我写了，然后没人看得到）。
• crm_campaign_member.added_date —— 被 campaign-enrollment.flow 的两个节点 {NOW()} 写入、被种子写入，没有任何东西读它、没有任何地方画它。卡片说这是「is_taxable 的形状完全一致」，那一条是有先例的。

不做的事

⛔ 不要把 pnpm scan:fields 加进 pnpm verify。卡片的理由是对的（在 consumer 落地前一个 PR 声明字段是正常的，2026-08-17 的裁决要的是逐字段 verdict 而非一刀切规则），而真正被守住的是扫描器看得见的能力：test/field-consumer-scan.test.ts 在解析器不再区分两个同名字段的对象时会红。

姊妹卡：#1198（crm_product.tax_rate，第 15 行，已在决策箱）· #1182（十行台账的先例）。

---

Generated by Claude Code

[os-sales]

Blocked on #1543 by the repo:hotcrm PM seat — ⛔ not independently dispatchable.

This card was queued and looked free. It is not. Measured during #1198's R32 run:

test/field-consumer-scan.test.ts (#1193's guard) needs a field name declared on two objects with different verdicts. Exactly three exist on this tree: tax_rate, line_number, description. This card proposes removing crm_quote_line_item.line_number and the three inert description rows — i.e. both of the replacement fixtures that #1198's blocker would otherwise re-point to.

The arithmetic that makes this a shared blocker rather than a #1198 problem:

	inert rows removed
#1198	1	ruled
this card	14	queued
remaining if both land	0	—

⇒ the live-vs-inert pair class is extinguished, not reduced. Whichever of the two lands first has to re-point the fixture, and if that choice is made without the other card in view it gets made twice — the second time with no valid inert field left to pick.

⛔ Dispatching this card first does not route around #1198's block; it hits the identical wall from the other side. Both wait on #1543, which asks the question underneath both: is zero inert fields the intended steady state, and if so should the live-vs-inert half of the guard be re-pointed or retired?

The src/translations/** serial fence #1198 was holding is released, so this card is no longer fenced on that axis — it is blocked on the guard question alone.

---

Generated by Claude Code

[os-zhuang]

Pointer (director seat, summon #15, 2026-09-05T11:3xZ): #1543 is ruled F by the maintainer — the field-consumer scanner and its guard are retired from this repo outright (comment 5552508432 on that card). The two replacement fixtures this card would have removed (line_number, description) are no longer anyone's fixture, so this card no longer waits on a re-point. It stays pm:blocked on #1543 until the retirement PR is MERGED, then is released in the same stroke and dispatched on its own adjudication; it should not be folded with #1198 (different objects, different doc faces, one worktree each).

---

Generated by Claude Code

[os-zhuang]

Released from pm:blocked → pm:queue (director seat, summon #15, 2026-09-05T15:0xZ): #1543 is ruled F and its retirement PR #1580 is MERGED (main 021db549), so the guard this card was blocked on no longer exists and nothing here needs a replacement fixture.

Not dispatched by this seat, for two reasons, both recorded so the next dispatcher does not have to rediscover them:

1. Serial. [Decision] crm_product.tax_rate: enforcing it is measurably wrong, so the remaining option is removal — which needs a ruling #1198 is dispatched now and holds the src/translations/** fence (claim 5552518995's sibling on that card); this card edits the same four locale files (14 rows across up to 8 objects) and waits for [Decision] crm_product.tax_rate: enforcing it is measurably wrong, so the remaining option is removal — which needs a ruling #1198 to MERGE.
2. The floor. This ledger removes up to 14 published fields on apiEnabled objects. The 2026-08-17 ruling (「逐个 enforce-or-remove（推荐）」) authorised per-field adjudication for the ten rows of Decorative-field sweep: enforce-or-remove every declared field with zero business consumers #1182; the 08-25 first-touch grading on this card (5410492266) queued it and told the implementer to decide remove-vs-enforce per row. Deleting published capability is on the maintainer's floor by the dispatch rules, and [Decision] crm_product.tax_rate: enforcing it is measurably wrong, so the remaining option is removal — which needs a ruling #1198 — one field — needed its own explicit authorisation (5315744424). This seat is therefore presenting this card as a ledger decision in its next batch (clusters A crm_contact.mailing_* ×5 with their import columns, B description ×3, plus the six mechanical rows; crm_forecast.seed_key excluded as Forecast seed upserts on period_label, which is no longer a unique key #613 design), and will dispatch on the reply. ⛔ Whoever picks this card before that reply should treat "remove" as unauthorised and "enforce" (a form grows a section) as widening the public face — both stop-and-report, per the 08-25 grading's own boundary.

Re-derive the ledger at dispatch time: pnpm scan:fields is gone with #1543; the 08-25 grading's instruction to re-run it is void. The replacement is a git grep per field over src/** (views, pages, apps, flows, hooks, data, mappings) — the platform diagnostic (objectstack#15922) does not exist yet.

---

Generated by Claude Code