docs: spec审查修正——推送_前缀过滤/两提醒串行优先级/电话归泛词/模板句过墙断言/correction预算说明

Co-Authored-By: Claude Code <noreply@anthropic.com>

docs/superpowers/specs/2026-10-08-dual-contact-and-country-code-design.md

@@ -67,9 +67,25 @@
 
 ### 4.3 一次性计数（防死缠/spam，防漏洞 1/3）
 
-- raw_info 内部状态键（`_` 前缀，不进推送画像）：`_email_asked`、`_cc_asked`
+- raw_info 内部状态键：`_email_asked`、`_cc_asked`
 - 注入提醒的同时落计数；条件判断先查计数——**每个提醒每会话最多注入一次**
-- 计数由 reminder 注入路径写入（与现有 `_` 前缀内部状态管理同构）
+- ⚠️ **推送过滤（spec 审查发现的必需项）**：`lead_push_service._build_payload`
+  的 `profile_out = dict(raw_info)` 是整体拷贝且**不过滤 `_` 前缀**（渲染侧
+  两处有过滤，推送端没有）——必须同步加
+  `{k: v for k, v in raw_info.items() if not str(k).startswith("_")}` 级过滤，
+  并补推送 payload 断言，否则 `_email_asked` 等内部状态泄进生产 CRM
+- ⚠️ **计数写回的实现约束**：`_build_context_reminder` 是 staticmethod 且收到
+  的是内存副本——调用方须在流式开始前显式写回 `profile.raw_info` 并提交
+  （轮末 extractor 合并起点是 `dict(profile.raw_info or {})`，提前写入可存活）
+
+### 4.3b 提醒优先级（两提醒同轮并发时的串行规则，spec 审查补充）
+
+主场景恰恰是并发：客户常"留裸号且无邮箱"。**一次只注入一个，顺序固定**：
+
+1. **国家代码确认优先**（先把手上的号码补全闭环）
+2. 邮箱轻补仅在以下任一条件满足后才允许注入：号码已带国家代码前缀、
+   `_cc_asked` 已消耗（问过一次，无论客户是否配合）
+3. 即两个提醒由计数与优先级共同串行化——AI 任何一轮只追问一件事
 
 ### 4.4 再索要墙精确化（boundary_filter.py asks_contact）
 
@@ -77,8 +93,10 @@
   （None = 原行为全丢，兼容无参调用）
 - 渠道分辨：精确渠道词（whatsapp / e-mail / 邮箱 / 微信…）命中 → 仅当
   该渠道**已在 confirmed_channels** 才丢；不在手则放行
-- **泛渠道词（number / phone / contact / 联系方式 / 号码）保守处理**：
+- **泛渠道词（number / phone / contact / 电话 / 联系方式 / 号码）保守处理**：
   客户已有任何号码渠道在手 → 照丢（宁丢勿放，防重复索要惹恼客户）
+- **精确词与泛词同句共存**（如 "leave your number or email"）：任一命中
+  判丢即丢（保守方向）
 - 中文/英文模式同规则
 - conversation.py 调用点传入 confirmed 渠道集合（该状态已在前移区算好）
 
@@ -86,6 +104,8 @@
 
 - 邮箱后到会触发一封"更正/补充邮件"（客户经理先后收 WhatsApp 版、补邮箱版）
   —— 信息更全，属预期
+- 客户重发完整号走现有"改号覆盖"机制 → 会消耗一次 correction 邮件/推送
+  （与邮箱后到共享每会话 3 封上限，正常预算内）
 - 客户拒绝补国家代码：号码按现状照常 confirmed，线索照发（软引导不设卡）
 
 ## 5. 不动清单
@@ -106,7 +126,12 @@
    国家代码追问句；`_cc_asked` 后 → 不含
 3. **prompt 静态断言**：system.md 含 "with the country code" / 邮箱轻补模板句 /
    好差示例新增组
-4. 全量 pytest 绿（现有再索要墙断言按新语义同步更新）
+4. **新模板句过墙回归断言**（spec 审查补充）：两个新模板句（国家代码追问句、
+   邮箱轻补句）在对应渠道已确认场景下会被 asks_contact 判丢、在缺失渠道场景
+   放行——防止后续改模板措辞时无意撞墙或穿透
+5. **推送 payload 断言**：`_email_asked`/`_cc_asked` 不得出现在 _build_payload
+   产物中（`_` 前缀过滤生效）
+6. 全量 pytest 绿（现有再索要墙断言按新语义同步更新）
 5. **真实 LLM 验收**（生产冒烟后补）：①客户给裸号 `0501234567` → AI 礼貌请其
    重发完整号（仅一次）；②客户留 WhatsApp → AI 轻补邮箱一次；③只留邮箱的
    客户 → 不被纠缠要 WhatsApp（分步双要以 WhatsApp 起手，邮箱-only 客户