Broken and conflicting automation across hooks and flows

[yinlianghui]

Automation that reads/writes nonexistent fields or never fires

• src/objects/campaign.hook.ts:73-74 counts crm_lead with filter: { campaign: id } — crm_lead has no campaign field. num_leads / num_converted_leads are always 0 (errors swallowed by onError: 'log').
• src/objects/contact.hook.ts:51,54 writes contact_email / contact_phone to crm_opportunity — neither field exists on the object; the failure is swallowed by catch {}.
• days_in_stage (opportunity.object.ts:180-184) is written by nothing; only seed data hardcodes it. opportunity-stagnation.flow.ts:41 filters days_in_stage > 14, so the flow only matches seeded demo rows.
• campaign-enrollment.flow.ts:11-31 is type: 'schedule' (cron 0 9 * * 1) but filters on input variables {campaignId} / {leadStatus} that a scheduled trigger never receives; each run resolves to empty filters.
• quote.hook.ts:98-128 inserts crm_contract with crm_contact from the quote; crm_quote.crm_contact is optional while crm_contract.crm_contact is required: true. Accepting a contact-less quote fails validation silently (async: true, onError: 'log').
• knowledge_article.hook.ts:25-27 sets input.published_at = nowIso without checking for a provided value; seeded historical dates (src/data/index.ts:1107,1128,1157) all become the boot date.
• crm_quote.owner (quote.object.ts:89-93) is the only owner field without defaultValue; demo-bootstrap.flow.ts:76-83 also skips quote/contract/campaign/forecast, so quote_expiration / contract_renewal / contract_expiration notify an empty owner.

Duplicate/conflicting automation on the same events

• Case escalation creates two follow-up tasks: case.hook.ts:112-128 (priority urgent) and case-escalation.flow.ts:54-65 (priority high).
• Contract renewal tasks are created twice and daily: contract.hook.ts:132-147 on activation, plus contract-renewal.flow.ts:61-73 every day inside the notification window with no idempotency marker.
• num_sent is written by both campaign-enrollment.flow.ts:55 and campaign.hook.ts:97; campaign-completion.flow.ts:46 triggers the latter.
• Escalation fields are written by three different places with different field subsets: case-escalation.flow.ts:50, case-sla-monitor.flow.ts:55, case.actions.ts:25-32.
• Quote totals: quote-generation.flow.ts:49-51 computes amount * (1 - discount/100); quote_line_item.hook.ts and all five seeded quotes compute subtotal − discount + tax + shipping. The flow (:63) also sets stage: 'proposal' unconditionally, which the opportunity_stage_progression state machine only allows from needs_analysis.
• Stage→probability values are hardcoded outside the map in opportunity.hook.ts:27-35: opportunity.actions.ts:44, lead-conversion.flow.ts:126; the 14-day stagnation threshold is duplicated in opportunity.view.ts:189; thresholds 100000/500000 appear in 5 places.

[yinlianghui]

🎯 剩余范围（2026-07-30 更新）：只剩 days_in_stage 一项

本 issue 正文列出的其余缺陷已由 #536 全部修复并合入 main（重复建任务、写不存在的字段、lead_auto_assign 优先级、campaign_enrollment 触发方式、各类失控触发与幂等等）。#536 用 Refs 而非 Fixes 关联，正是为了留下这一项。

唯一待办

crm_opportunity.days_in_stage 没有任何递增来源，因此 opportunity_stagnation 流程的 days_in_stage > 14 筛选在真实数据上永远不命中（只有种子数据硬编码了值）。

现状（main）：

• src/objects/opportunity.hook.ts 在阶段变化时把它重置为 0 —— 这是正确的一半；
• src/objects/opportunity.object.ts 里它是普通 Field.number({ readonly: true })，不是公式字段；
• 全仓库没有任何按日递增它的定时任务或 hook。

建议修法

加一个 stage_entry_date 日期字段（hook 在阶段变化时写入，插入时初始化），把 days_in_stage 改成基于它计算的公式字段。比每晚全表扫描的定时流程更省、也不会漏。

注意：crm_opportunity 目前没有任何可用的阶段进入时间戳（只有 close_date / created_date / approved_date），所以这个字段需要新增。改动涉及 schema，请同时更新种子数据与相关测试。

完成后

本 issue 可以关闭。