维护者速读
事情：17.4 把作者期规则从 42 条加到 44 条，其中一条 field-no-consumers 报出本仓 21 个字段「声明了，但这个 stack 里没有任何东西读它或显示它」。门禁全绿（是 warning 不是 error），所以不阻塞任何事 —— 但它指出的东西对一个展品来说是要紧的。
发现于 17.4 升级（#35 / PR #37），当场没有顺手改：在一个依赖升级里替 21 个字段做产品决定是夹带，不是交付。
21 个字段（每个的判定都一样：只有载体，没有消费者 —— 翻译包给了它一个标签，然后没有任何视图、页面或流程读它）：
| 对象 |
字段 |
clm_party |
legal_representative · address · contact_phone · bank_name · bank_account · risk_note · screened_at |
clm_signature |
envelope_id · signers · notes |
clm_review |
comments · internal_note |
clm_deviation |
deviation_text · justification |
clm_clause |
standard_text · fallback_text |
clm_obligation |
evidence · notes |
clm_contract_type |
description · template_placeholders |
clm_contract_version |
notes |
为什么要你拍板：这 21 个不是一类东西。clm_party.bank_account 和 contact_phone 是任何 CLM 都真的要有的合同相对方资料，缺的只是一个视图列；clm_signature.envelope_id 是电子签集成落地时才有消费者的字段（卡 12，M4）；而 clm_clause.standard_text / fallback_text 是条款库的正文，没人读它意味着条款库今天是个空壳。给消费者还是删声明，得逐组判，而判据是产品要不要这个能力。
你要做的：回一个字母定默认方向，逐字段的执行我按它派发。
选项
|
做法 |
代价 / 收益 |
| A（推荐） |
默认删声明，只保留能当场点名消费者的字段（含卡 12/13 已排期要用的，正文写明排期即算消费者） |
符合 ADR-0049 enforce-or-remove 与创业阶段不扩散；展品从此 declared = enforced。代价：删字段要连翻译包里的载体一起删，且是一次性的批量改动 |
| B |
默认给消费者 —— 逐个补进视图列、详情页分区或流程 |
展品更丰满，21 个字段都变成真能力。代价最大，且其中若干（envelope_id、screened_at）今天没有真实数据来源，补上去就是假能力，正是 AGENTS.md 的 Honest capabilities 禁止的 |
| C |
分组处理：相对方资料补消费者，签署/审查的内部字段删声明，条款正文单独判 |
最贴近事实，但它其实不是一个选项，是「A 和 B 各用在对的地方」。选它等于要我先出一张分组清单再逐组回一次 |
四棱分析
实际业务需求 — 偏 C，其次 A。这一棱要求实测「谁在写、谁在读」。今天：21 个全都没人读。但写的一侧不一样 —— clm_party 那七个是种子数据真的在写的（相对方档案），clm_signature.envelope_id 与 screened_at 是连写都没人写的纯投机面。所以「有拉动」的只有一部分，把 21 个当一类处理会同时犯两个方向的错。
项目长远合理性 — 偏 A。展品的第一职责是示范正确写法。一个被翻译包命名、被 schema 声明、然后没有任何东西渲染的字段，是在教读者「声明可以不兑现」。ADR-0049 的 enforce-or-remove 就是为这个形状写的，方向是拉回而不是补齐。
防 AI 写错 — 最偏 A，且这一棱最不平衡。展品撒谎等于教每个照抄的 AI 撒谎（本车道章程原话）。而 B 在这里特别危险：给 envelope_id 补一个详情页字段，读者会认为电子签集成已经在跑；给 screened_at 补一个列，读者会认为制裁名单筛查已经在跑。两者都没有。 补消费者去掩盖「没有生产者」，比留着不读更糟 —— 那把一个安静的空声明变成一个会骗人的界面。
创业阶段不扩散 — 明确偏 A。21 个无拉动的声明面按 implementation-first 处置；已发布零消费的能力不因沉没成本获得豁免。本仓 private: true、尚未发布，删除成本是历史最低的一刻。
结论：三棱偏 A，第一棱指出 21 个不同质。拟推荐 A 作为默认方向，并接受第一棱的修正：clm_party 那七个若你认为相对方档案是 V1 该有的，就点名保留并派一张「给它们视图列」的卡 —— 那是 A 的例外，不是 B。⛔ 我没有替你逐字段决定，那 21 个里至少三组是产品能力取舍。
影响
不阻塞。门禁全绿，pnpm validate 只是多 21 条 warning。但每一轮 validate 都会打印它们，新 warning 会很快变成没人看的 warning —— 这是本仓 AGENTS.md「a boot that logs warnings is not a passing boot」那条纪律真正的成本。
⚠️ 坦白一句：这张卡把决策箱从 8 张变成 9 张，而你刚让我清它。我没有把它自裁掉，因为「删 21 个字段还是补 21 个界面」是产品能力取舍，那是代裁的人工地板，不在任何自裁通道里。
关联
#35 / PR #37（发现处）· AGENTS.md → Honest capabilities · ADR-0049 enforce-or-remove · 卡 12（e-sign，envelope_id 的排期消费者）· 卡 13（AI skills）
维护者速读
事情：17.4 把作者期规则从 42 条加到 44 条，其中一条
field-no-consumers报出本仓 21 个字段「声明了，但这个 stack 里没有任何东西读它或显示它」。门禁全绿（是 warning 不是 error），所以不阻塞任何事 —— 但它指出的东西对一个展品来说是要紧的。发现于 17.4 升级（#35 / PR #37），当场没有顺手改：在一个依赖升级里替 21 个字段做产品决定是夹带，不是交付。
21 个字段（每个的判定都一样：只有载体，没有消费者 —— 翻译包给了它一个标签，然后没有任何视图、页面或流程读它）：
clm_partylegal_representative·address·contact_phone·bank_name·bank_account·risk_note·screened_atclm_signatureenvelope_id·signers·notesclm_reviewcomments·internal_noteclm_deviationdeviation_text·justificationclm_clausestandard_text·fallback_textclm_obligationevidence·notesclm_contract_typedescription·template_placeholdersclm_contract_versionnotes为什么要你拍板：这 21 个不是一类东西。
clm_party.bank_account和contact_phone是任何 CLM 都真的要有的合同相对方资料，缺的只是一个视图列；clm_signature.envelope_id是电子签集成落地时才有消费者的字段（卡 12，M4）；而clm_clause.standard_text/fallback_text是条款库的正文，没人读它意味着条款库今天是个空壳。给消费者还是删声明，得逐组判，而判据是产品要不要这个能力。你要做的：回一个字母定默认方向，逐字段的执行我按它派发。
选项
envelope_id、screened_at）今天没有真实数据来源，补上去就是假能力，正是 AGENTS.md 的 Honest capabilities 禁止的四棱分析
实际业务需求 — 偏 C，其次 A。这一棱要求实测「谁在写、谁在读」。今天：21 个全都没人读。但写的一侧不一样 ——
clm_party那七个是种子数据真的在写的（相对方档案），clm_signature.envelope_id与screened_at是连写都没人写的纯投机面。所以「有拉动」的只有一部分，把 21 个当一类处理会同时犯两个方向的错。项目长远合理性 — 偏 A。展品的第一职责是示范正确写法。一个被翻译包命名、被 schema 声明、然后没有任何东西渲染的字段，是在教读者「声明可以不兑现」。ADR-0049 的 enforce-or-remove 就是为这个形状写的，方向是拉回而不是补齐。
防 AI 写错 — 最偏 A，且这一棱最不平衡。展品撒谎等于教每个照抄的 AI 撒谎（本车道章程原话）。而 B 在这里特别危险：给
envelope_id补一个详情页字段，读者会认为电子签集成已经在跑；给screened_at补一个列，读者会认为制裁名单筛查已经在跑。两者都没有。 补消费者去掩盖「没有生产者」，比留着不读更糟 —— 那把一个安静的空声明变成一个会骗人的界面。创业阶段不扩散 — 明确偏 A。21 个无拉动的声明面按 implementation-first 处置；已发布零消费的能力不因沉没成本获得豁免。本仓
private: true、尚未发布，删除成本是历史最低的一刻。结论：三棱偏 A，第一棱指出 21 个不同质。拟推荐 A 作为默认方向，并接受第一棱的修正：
clm_party那七个若你认为相对方档案是 V1 该有的，就点名保留并派一张「给它们视图列」的卡 —— 那是 A 的例外，不是 B。⛔ 我没有替你逐字段决定，那 21 个里至少三组是产品能力取舍。影响
不阻塞。门禁全绿，
pnpm validate只是多 21 条 warning。但每一轮validate都会打印它们，新 warning 会很快变成没人看的 warning —— 这是本仓AGENTS.md「a boot that logs warnings is not a passing boot」那条纪律真正的成本。关联
#35 / PR #37（发现处）·
AGENTS.md→ Honest capabilities · ADR-0049 enforce-or-remove · 卡 12（e-sign，envelope_id的排期消费者）· 卡 13（AI skills）