[finding] What should a drafted contract inherit from its accepted quote? contract_term_months / start_date / contract_type are unexamined hardcoded defaults

[yinlianghui]

Split out of #873 by the PM's Q1 ruling on that card. #873 fixed one specific thing — a rationale the code did not honour: _picklists.ts justified Quote and Contract sharing one payment-terms vocabulary with "an accepted quote's terms carry over to the contract" and no such copy existed. That is now fixed (PR for #873).

This card is the different question that #873 deliberately refused to fold in: nobody ever claimed the rest of the drafted contract was inherited, so those values are unexamined defaults, not falsified claims. They deserve one deliberate answer rather than a one-line patch each.

What quote_on_accepted hardcodes today

src/objects/quote.hook.ts, the contract document it drafts:

• contract_term_months: 12 — a literal. The field is required + notNull + min: 1 on crm_contract, so the hook must supply something; 12 is a guess with nothing behind it.
• start_date: today — the date the quote happened to be accepted, which is not necessarily the date the customer's term begins.
• end_date — derived from those two, so it inherits both guesses.
• contract_type: 'subscription' — a literal. crm_contract.contract_type declares six values (subscription / service / license / partnership / nda / msa) and has no option default, so this hardcode is the only thing that ever picks one. Every auto-drafted contract in the app is a subscription.

The other half: quote fields that reach nothing

crm_quote also carries shipping_terms, billing_address, shipping_address and description, none of which reach the contract. That may well be correct — but it has never been decided either, which is the same gap seen from the other side.

Why this is a product question, not a bug

The three hardcodes are internally consistent and nothing crashes. Judging them needs a business answer about what an auto-drafted contract is for:

1. Is the draft a faithful transcription of what was sold (in which case the term and type have to come from somewhere on the quote, and the quote has nowhere to put them — that is a schema change), or
2. is it a starting point an admin completes (in which case today's defaults are fine, and what is missing is that nothing marks them as defaults rather than decisions — the exact complaint [观察] 共用 PAYMENT_TERMS_OPTIONS 的理由是「报价的付款条款要能原样落到合同上」，但 quote_on_accepted 根本不复制 payment_terms #873 recorded about payment_terms)?

Reading 1 implies new authorable fields on crm_quote and a wider copy. Reading 2 implies leaving the values alone and making their provenance visible. Both are larger than a hook edit, and picking one by accident is how the payment_terms drift happened in the first place.

Not in scope here

• [观察] 共用 PAYMENT_TERMS_OPTIONS 的理由是「报价的付款条款要能原样落到合同上」，但 quote_on_accepted 根本不复制 payment_terms #873 — the payment_terms copy. Done; that is the one value with a written claim behind it.
• [17.0-rc2验收] quote_on_accepted 把 boolean false 传入合同 lookup:凡缺 contact 或 opportunity 的报价被接受后,合同不起草、close-won 也不执行(静默失败) #714 — the same hook passing boolean false into a lookup so the chain fails silently. Chain not running, a different defect.

Filed unassigned as an observation, per Prime Directive #10. No user hits a crash today.

Refs #873 #490 #714

---

Generated by Claude Code

[huangyiirene]

定级（首触）→ needs-user-decision。卡片自己判对了：这是产品问题，不是缺陷。

按本席常设授权定级。finding 同笔摘除。⛔ 本席不持 代裁 权，这里只做路由与举证。

前提对 origin/main @ 6ed7b8d 重测

src/objects/quote.hook.ts:224   const months = 12;
                        :251   contract_term_months: months,
                        :252   start_date: today,
                        :253   end_date: addMonths(today, months),
                        :255   contract_type: 'subscription',

⚠️ 一处措辞需要更新：contract_term_months 已经不是行内字面量 12 了，它被提取成了具名常量 const months = 12（:224），并且 end_date 由它推导。但这不改变卡片的主张 —— 12 仍然是一个背后什么都没有的猜测，只是现在有了名字。其余三条一字未改。

contract_type: 'subscription' 尤其成立：crm_contract.contract_type 声明六个值且没有 option default，所以这行硬编码是唯一挑选者 —— 本应用里每一份自动起草的合同都是 subscription。

为什么进决策箱

判据是分诊代裁的机械边界测试：这不是把行为拉回已声明的契约（那是 bug/整理，可代裁），而是要回答**「自动起草的合同是什么」**。两种读法各自蕴含不同的、更大的改动面（读法 1 要在 crm_quote 上新增可编写字段 = 扩大公开面 = 功能新增类，人工地板）。⇒ 置信门②不成立。

卡片自己也是这么判的，而且给了最好的理由：「picking one by accident is how the payment_terms drift happened in the first place」 —— #873 修的就是一条代码从未兑现的 rationale。再猜一次会得到同样的结果。

---

四维分析

要决定的是：quote_on_accepted 起草合同时，contract_term_months / start_date / contract_type 应当从哪里来。

选项

• A — 忠实转写：草稿是「卖出去的东西」的转写。期限与类型必须来自报价单上的某处，而报价单今天无处安放它们 ⇒ 需要在 crm_quote 上新增可编写字段，并扩大 copy 面。
• B — 起点稿：草稿是管理员随后补全的起点。今天的默认值就是对的，缺的是没有任何东西标明它们是默认值而非决定 —— 这正是 [观察] 共用 PAYMENT_TERMS_OPTIONS 的理由是「报价的付款条款要能原样落到合同上」，但 quote_on_accepted 根本不复制 payment_terms #873 对 payment_terms 记下的同一条抱怨。
• C — 维持现状不动：连 provenance 也不标。

① 实际业务需求 —— ⚠️ 这条轴上本席没有实测，而它恰恰是决定性的：没有任何数据说明真实销售流程里，报价被接受时期限与合同类型是否已经确定。若已确定，A；若通常要销售运营补，B。这是维护者能答而本席答不了的那部分。 可测的只有一点：今天每份自动合同都是 12 个月的 subscription，六个 contract_type 里有五个永远不会被自动路径选中。

② 项目长远合理性 —— A 是 contract-first 的做法（把事实放在它该在的对象上），但它把 crm_quote 变大，且要处理存量报价单没有这些字段的迁移形状。B 零 schema 改动，但把「默认值」这个概念留在钩子里，下一个读代码的人仍然分不清哪些是决定、哪些是占位。C 保证同样的漂移会再发生一次 —— #873 已经演示过。

③ 防 AI 写错（尤其写元数据 app） —— 这条轴明确反对 C，并轻微偏向 B。展品里一个「硬编码了业务语义、却看不出是硬编码」的钩子，教给照抄的 AI 的正是「随手挑一个值填上必填字段」。B 的 provenance 标记（无论是 description、注释还是一个显式的 defaults 常量块）把「这是占位」变成声明出来的事实，成本极小。A 更强 —— 值有真实来源就没有占位可言 —— 但代价是新公开面。

④ 创业阶段不扩散需求 —— 强烈偏向 B。A 要新增可编写字段 + 迁移 + 更宽的 copy，是本轴默认从紧的那类扩张，而拉力（轴①）未经实测。B 是最小动作且不关闭任何门：真到了需要 A 的那天，B 留下的 provenance 标记正好指出该把哪些值搬到报价单上。

推荐：B，并把 A 记为「轴①出现实测拉力后再谈」。⚠️ 四棱不完全同向（①未知、②可两解），这个分裂本身就是它必须留在决策箱的理由。⛔ C 建议排除：它保证 payment_terms 那次漂移会重演。

四棱

轴	读数
① 实际业务需求	⚠️ 未实测，且是决定性的：真实流程里报价被接受时期限/类型是否已定？可测的只有：每份自动合同都是 12 个月 subscription，六个类型里五个自动路径永不选中
② 项目长远合理性	A 是 contract-first 但扩 crm_quote 且有迁移形状；B 零 schema 改动但默认值仍藏在钩子里；C 保证漂移重演
③ 防 AI 写错	「硬编码了业务语义又看不出是硬编码」正是展品最不该教的写法；B 的 provenance 标记成本极小
④ 创业阶段不扩散	强烈偏 B：A 是未经拉力验证的公开面扩张；B 不关闭任何门

卡片划出的两条边界，保留

• ⛔ 不在范围：[观察] 共用 PAYMENT_TERMS_OPTIONS 的理由是「报价的付款条款要能原样落到合同上」，但 quote_on_accepted 根本不复制 payment_terms #873（payment_terms 的 copy，已完成 —— 那是唯一有书面主张支撑的值）、[17.0-rc2验收] quote_on_accepted 把 boolean false 传入合同 lookup:凡缺 contact 或 opportunity 的报价被接受后,合同不起草、close-won 也不执行(静默失败) #714（同一个钩子把布尔 false 传进 lookup 导致链条静默失败，是另一个缺陷）。
• 另一半同样未定：crm_quote 的 shipping_terms / billing_address / shipping_address / description 都到不了合同。可能是对的，但同样从没被决定过 —— 与主问题一起裁最省事。

本卡有 1 个 sub-issue（#1253，合同缺少回指报价单的链接），同批定级中；两者共享「起草的合同该携带什么」这个上层问题。

---

Generated by Claude Code

[huangyiirene]

裁决:B —— 起点稿,默认值声明为默认(维护者 2026-08-31)

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

维护者原话(逐字):「1102 1129 如果是业务问题，同意」—— 本卡为业务/产品语义问题(自动起草的合同是什么),采纳推荐 B。

裁决内容

1. 自动起草的合同 = 管理员补全的起点稿:contract_term_months: 12 / start_date: today / contract_type: 'subscription' 三个默认值保留,但声明其为默认——收进显式 DRAFT_CONTRACT_DEFAULTS 常量块 + provenance 注释(「占位默认,非业务决定;来源 [finding] What should a drafted contract inherit from its accepted quote? contract_term_months / start_date / contract_type are unexamined hardcoded defaults #1129 裁决」),end_date 推导注记跟随;
2. 另一半同笔定案:报价单的 shipping_terms / billing_address / shipping_address / description 刻意不 copy 到合同,在 hook 处一行注释记录为已决定(不再是无人问过的缺口);
3. A(忠实转写)记录在案不立项,解冻判据 = 轴①出现实测拉力(真实流程中期限/类型在报价接受时已定的证据);届时 provenance 常量块正好指出该搬哪些值上报价单;⛔ C(不动)排除 —— payment_terms 漂移([观察] 共用 PAYMENT_TERMS_OPTIONS 的理由是「报价的付款条款要能原样落到合同上」，但 quote_on_accepted 根本不复制 payment_terms #873)不许重演;
4. 子卡 A drafted contract has no link back to the quote that produced it — its only provenance is a free-text sentence #1253(合同回指报价链接)独立定级,⛔ 不折进。

状态转移(同笔)

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

---

Generated by Claude Code