用途：管理冷邮件发送域名群的每周卫生循环，决定域名保留、取消、提升或购买，解决“为已烧毁域名继续付费”和“预热储备闲置导致发送量不足”两类问题。默认只读，plan 步骤不写入任何内容；只有人工明确同意后运行 apply 步骤才会更改标签、活动或服务商订阅。
主要能力：按域名（非单个收件箱）判定四种状态——Warmup（新开通、预热不足14天）、Insurance（已预热健康闲置的储备池）、Active（正在活动发送）、Cancel（已判死，停止发送并取消订阅）。提供样本量下限（回复率需200封、退信率需50封、退信分类需30条、域名年龄需30天、投放测试需100-300个发件人），并按决策阶梯 G0-G5 逐域判定，输出 plan.csv、actions.csv 和摘要。还包含容量与购买计划（每收件箱30/天，域名容量按实际收件箱数相乘）、订阅成本核算、快照与回滚、取消规则和失败模式。
使用方式：运行 npx tsx scripts/plan-lifecycle.ts --goal=2000 --out=./lifecycle-$(date +%F) 拉取数据；机构账户可省略 --goal 只取判定。人工审批后运行 npx tsx scripts/apply-lifecycle.ts --actions=./lifecycle-$(date +%F)/actions.csv --apply，不加 --apply 为干跑。应用前需用 --snapshot 快照。
适用场景：每周五例行清理、判断该取消哪些收件箱、发送量低于目标、收件箱账单过高、在可投递性审计给出 SENDER_BURNED 结论后采取行动。
限制：不负责诊断域名为何变差、修复 DNS、处理急性事故或预热设置与签名。30天以下域名绝不取消；样本不足时结论为“未知”；不得按模式批量取消，须用明确枚举的域名 ID；不得盲目重试服务商取消；取消按整个域名进行，不可拆分。预热关闭的收件箱视为 HELD，不计入容量。大账户（5k+ 收件箱）首次拉取可能需20-40分钟，脚本按页检查点续跑。具体价格、平台支持等以实际资料为准，部分细节暂未提供。