用途
pre-launch-data-check 回答一个问题：这份最终文件今天能否直接进入发送器，而不损害域名、品牌或测试结果。它运行在最终文件上，即瀑布式补全（waterfall-enrichment）和个性化流程（personalization-pipeline）之后、上传之前。更早的关卡判断企业是否匹配（prospect-scoring）以及邮箱能否发送（deliverability-audit），而这一关只看即将被发送的行：一份匹配名单里若有损坏的 {{first_line}}、第 212 行出现现有客户、以及 30% 的 catch-all 地址，仍会烧掉整个活动。
该检查应每轮运行，而不是每个客户只跑一次。每个新批次都有自己的重复项、过期信号和空字段。
主要能力（七个层面）
- 来源：检查文件内重复、与 CRM／进行中活动／客户／退订名单的重叠、单一公司联系人数量。命中任何抑制名单即 STOP；存在重复或单一公司超过 3 个联系人则 FIX。
- 验证：检查每个地址的验证状态、格式错误、角色邮箱、免费邮箱、邮箱域名与企业域名是否一致。完全没有验证列或存在无效／格式错误地址即 STOP；存在风险地址、catch-all 超过批次 25%、角色邮箱则 FIX。
- 完整性：检查序列使用的每个变量是否都在、已填写、已渲染（不含 {{…}}、N/A、null、[NAME]）。变量列缺失或任一行空／未渲染即 STOP。
- 路由：检查每行是否有分级／队列（来自 prospect-scoring 的 A/B/D），若按发件人拆分则检查发件人。缺分级或发件人的行需 FIX。
- 卫生：检查名字大小写、公司名中的法律后缀、空白职位。如 JOHN、maria、Stripe Inc. 这类会被读者在第一行看到的问题需 FIX。
- 信号：检查信号时效是否超过新鲜度窗口、信号是否缺少来源链接。超过窗口（默认 60 天）或无证明链接需 FIX。
- 激活：检查移除问题行后的可发送行数与数量门槛的关系，以及按当前产能可发送多少天。可发送行数低于门槛（事件信号假设 300 条，数据点假设 500 条）需 FIX。
无效地址和命中抑制名单被定为 STOP 而非 FIX：前者会导致域名退信，后者会给正在与你沟通或付费的人发冷邮件，两者代价都超过延迟一天。
使用方式
需要准备：最终 CSV（包含序列使用的每一列）、各抑制名单 CSV（CRM 中已在对话中的人、进行中活动的联系人、现有客户（域名即可）、退订和勿联系名单）、序列使用的变量列表（first_name、company、first_line 等），可选邮箱数量和每个邮箱每日新联系人上限。缺少抑制名单时检查仍会运行，但会将抑制检查报告为 NOT CHECKED；应明确说明这一点。
运行命令：
python3 scripts/check_list.py final.csv \
--suppress crm_export.csv active_campaigns.csv clients.csv optouts.csv \
--vars first_name,company,first_line \
--mailboxes 6 --daily-cap 30 \
--out rows_to_fix.csv
列会自动识别（email、first_name、company、domain、title、linkedin_url、email_status、tier、signal_date、signal_source），其他列可用 --col email="Work Email" 映射。只含 domain 列的抑制文件会抑制整个公司（客户、勿联系账户）。可按客户调整参数：--max-signal-age、--catch-all-max、--max-per-company、--min-volume。退出码 0 = GO，1 = GO WITH FIXES，2 = STOP，可嵌入流水线。--out 只写出有问题的行并带 problems 列，交给负责修正的人。若名单只存在于发送工具中，应先导出 CSV；不要用样本运行检查，问题往往在尾部。
适用场景
适用于外呼邮件活动在上传发送器前的最后一道数据质量把关，适合需要按来源、验证、完整性、路由、卫生、信号和激活多个层面系统筛查批量名单的团队。
限制
该检查不判断企业是否匹配——一行干净但公司不对仍是错的，这属于 prospect-scoring 和 signal-outbound 的 90% 抽查。它不验证地址，只读取验证器写入的状态；没有状态时会阻止并退回 waterfall-enrichment。它不测试邮箱，那是 deliverability-audit 的职责，两者都通过后才能首次发送。