Outreach 闭环看板

v7 最硬的一条约束 · 前五轮外审全没发现

阶段 1.5 要把 94 人从 new 改成 contacted，而这 94 人100% 是 lead_source=linkedin，正好撞上 linkedin_outreach_v3 的取件条件（status=eq.contacted，真发 flag 已开）。

→ 目前靠 next_action_at / runner_node 为 NULL 挡着，那是巧合不是设计——冷发引擎发完就会同时写这两个字段。所以回填不得写它们。外审看不出这条，因为它只看文档，看不到 .env 和 launchd。

v7.1 更正 · 上面那条的复验判据本身是坏的 9/2 实查

v7 写的复验是表级的：「lead_source=linkedin ∧ status=contacted ∧ 两字段非空 的行数必须为 0」。实查动手前就已经是 61 行，不是 0。原文那个「0 人」是对 94 人回填 cohort 的口径，被复述成了表的现状。

→ 两种错法都致命：照原样验 ⇒ 回填后看到 61 行会错误归因成「我造出来的」；反过来把它「修」成 0 ⇒ 打断一条合法的在跑队列（A3 是设计内的 accept 后跟进）。
正确形式必须限定在回填 cohort 内：where id = any(:backfill_ids) and ...——缺这一行就是判据落在了被测对象之外。另立一条表级基线不变量（回填前后该数必须都等于 61）防止顺手污染。

不能用「Gemini Summary 有没有内容」做判据 会全队漏判

实读两份纪要正文，两份的 Summary 都是空的，原文一字不差：“A summary wasn't produced for this meeting because there wasn't enough conversation in a supported language.” 会是中英混说的，Gemini 直接拒绝出摘要。

→ 真正有内容的是 Transcript 时长：Competitive Technology 00:08:38、Carolina PayPoint 00:09:34。判据落在时长上，不是摘要上——否则这批中文团队的会议会被系统性判成「没开过」。

9/2 实跑：额度用不完不是问题 —— 瓶颈是合格供给，不是 credit 推翻上一版结论

结论：好线索已被捞走。同一批源页面里，公司层已被挡掉的 657 人中 42.9% 公司名含 payment/merchant；net-new 2,215 人只有 1.9%——密度差 22 倍（放宽到 pay|pos|iso 仍差 6 倍）。

建议：不要追「把 2,021 用完」。额度的正确用法是「有多少合格线索就 reveal 多少」。真问题是搜索条件为什么产出 97% 无关线索——那是供给质量问题，应从已实测的筛选条件代价表入手，而不是用同样条件补跑更多搜索。

原因：① 在这个池子上花掉 2,021 credit 比让它作废更糟——等于往外联队列灌 2,000 个非 ISO 联系人，代价是发信支出 + 域名声誉。② 上个周期也作废了约 70%（~1,759 / 2,510），当时定性同样是「主因是没用完，不是用在低质量线索上」——同一件事第二次发生。③ --review 首批 24 条 KEEP=0，判出的 GoTab / Pomodo（POS 软件，A 类）、Decorative Paint（油漆厂，D 类）就是这个池子的真实成分。
⚠️ 0/24 不能外推：--sample 取 cands[:N] 是前缀不是随机。但它与整池的关键词密度一致（前 24 条含支付关键词 0 家）。
⚠️ 这次 0/24 不是已知的两个假 0：两家独立同意分类且理由具体。对照 2026-07-26 那次假 0——20/24 名字字面写着 Merchant Services 却被判「无证据」，那是 rubric 自我否决。
⚠️ 上一版的密度差 17.7 倍 → 22 倍：旧口径拿「1,340 人中 633 家」当分母，而 counts.filtered=1,340 里只有 657 落进了 prefilter_20260902.json，另外 683 人（已 reveal／已在库／台账）根本没落盘 ⇒ 那组数复算不出来。现口径只用落盘文件里能枚举的两群，判据 --pool 每次重算。

四个字段里三个是「无法失败的判据」 读错就等于没有闸

响应里有四个看着像配额的字段。此刻已消耗 489，但：

→ 仓里已经栽过一次：曾用 effective_num_lead_credits 的「2510 → 2510 零 delta」证明「搜索免费」。那个字段本来就不动，零 delta 不构成任何证据——结论碰巧对，证据是假绿。读错字段 = 做一个永远不会跳闸的闸。

🔴 9/2 晚实现时查出：花钱路径上是三重阻断，实时闸不是 9/16 的瓶颈 改变结论

写完「.env 的 key 是死的」之后继续追「就算换好 key，钱花得出去吗」——花不出去，而且另外两层是别人刻意设的：

→ 链条实证：_reserve_credit():327 调 guard("apollo",N) → reserve_quota 对 apollo 恒 FALSE → 抛 QuotaHalt → 一分不花。⇒ 无论实时闸开不开、.env 的 key 修不修，apollo_email_backfill 这条路都花不出去钱。

→ 只验读余额那把 key 是不够的：闸读余额用 master key，花钱却用另一把。只验读的那把，就会做出一个「余额 2,021、充足、放行」→ 然后每次 reveal 全 401 的闸——钱一分没花、额度一个没救回来，而日志看起来一切正常。已加 verify_spend_key() 在读余额之前先验花钱那把。

⇒ 给 Graham 的是两件独立的事，别混成一件 B 才是 9/16 的那件

→ A 不做也能做 B；A 做了也不能替代 B。我一开始把 A 当成了 B 的前置条件——那是错的，而且是本项目的典型错法：把一个架构目标摆在一个有硬死线的业务目标前面。

A7 是我自己的漏改 —— 而且是同一个毛病的第 15 次

我在 §3 阶段 1.5 把 LinkedIn 复验判据改成 cohort 级，§4 判据表忘了跟着改，仍写表级「必须 = 0」——而表级实际是 61 条合法的在跑队列。后果双向：误判回填失败，或为了归零把 61 条合法队列清掉。

→ 关键在于我的一致性脚本为什么没抓到：它只查过期数字，而这次漏改的是判据类型——数字一个都没错。已给检查器加第 2 类判据（表级归零断言必须带 cohort 限定），并双向验过：构造回归样本 exit=2 精确定位到行，修好的文档 exit=0。一个从没红过的检查等于没有检查。

🛑 第九轮之后停止外审循环 —— 依据不是「审够了」，是四轮数据显示它不收敛 仍不是「通过了」

→ 命中数在降（12→9→8→7），但没有趋近 0，且新缺陷的严重度没有下降。每轮修 N 条、引入约 2 条，而引入的那 2 条一直排在最严重的位置。同时三家在第八、九两轮都独立建议先做预生产演练而不是继续审文档，第九轮三家还都把「文档过大、执行路径被历史台账淹没」列成了问题——这份文档现在 1,800+ 行，相当一部分是外审台账本身。

→ 决定：不再进入第十轮文档外审，下一步是隔离库演练。一句话：文档审查已经审到了它自己会制造缺陷的区间；而演练能发现的东西，文档审不出来。

→ ⚠️ 这不是「通过了」。三家仍明确判定「不建议直接进入生产真写」，该结论保持有效。四项硬前置不变：① D7 阻塞项（查清冻结 Hermes 发送器的可执行命令）② 隔离库演练跑通「快照→分块写→复验→撤销→复验」③ ck_lead_status_source 加 'tracker' ④ 3 家 opt-out 清理 + 规则 6a 处置。恢复外审的条件是拿演练产出去审，不是拿文档。

第九轮最重的一条：我连着三轮把发送侧的问题装在账本侧 D2

§07 白纸黑字：「tracker 仍是发送决策的权威源，Supabase 是发送后的派生账本」。我却连着三轮用 status 值去解决「别再发这个人」。

→ 改 status 不会让 Hermes 少发一封信，它只是让账本看起来像挡住了。L3 的阻断已改走 tracker 抑制名单（compute_queue 真正查的三道闸之一）。paused 从此只剩两种原因，C1 为了兜住多义性而发明的 paused_reason 机制整个删掉。

→ 当一个修法需要发明新机制来兜住它自己引入的歧义时，先怀疑被修的那个设计。

→ 另一条（D3）：v8.1 说每日 guard「只是补丁」说轻了，v8.2 说第二道闸是「唯一硬闭环」说重了——两次都为了让结论干净而说过头。闸和不变量的差别不是强度，是能不能被绕过而不被发现。

🔴🔴🔴 三轮下来的信号，比任何单条意见都重要 修复动作本身是缺陷主要来源

→ 连续三轮，最严重的缺陷都来自上一轮的修复动作。§08 那张「同一个毛病第 N 次」记的是漏改；这张记的是修改本身。后者更难防：漏改可以靠脚本查，而「改 A 的时候在 B 上开了个洞」没有任何静态检查能抓到。

→ 已落成合并方案 §2b 的第三条写作规矩：每修一条外审意见，必须显式回答「这个改动新增了哪些状态 / 路径 / 语义？谁会读它们？它们怎么离开？」三条实证教训同一个根 —— 状态机既要看入边也要看出边（B1）；一个值承载多种原因，转换规则必然对其中至少一种是错的（C1）；修一个方向的偏差前先问它会不会把偏差翻到另一个方向（C5）。我在改一个点，而它是一张图上的节点。

第八轮 · 三家第三次全部不建议直接执行 8 条 ≥2 家命中 已修

→ C3 是一次裁决改判：第七轮三家方向相反（Codex「不够且没必要」/ 千问「要 38/38」/ DeepSeek「样本量不足」）构成 1:1:1 分裂，按规则没自行拍板；第八轮 Codex 改口后 ≥2 家一致，分裂消解 ⇒ 主会话拍板。理由不是「多多益善」：总体只有 38，抽样省下的 28 次核对，换来的是一个永远无法消除的推广风险，而写入不可逆。总体小到可以全查时，抽样不是节省，是自找的不确定性。

→ C4 的处置是「承认它不是防护」而不是「把它升级成防护」：防双发的硬闭环本来就在 A2 第二道闸（{status='new' 邮箱} ∩ {tracker 866} == ∅ 不满足则冷发拒绝启动）。guard 挂了、跑晚了、顺序错了都不会导致双发 —— 因为冷发根本没启动。外审问的「调度顺序怎么定」，前提就不成立。

→ 🔴 三家一致的一条流程建议已采纳为执行前置：真写前必须在隔离库完整跑一遍「快照 → 分块写 → 复验 → 撤销 → 复验」并落盘两次复验输出。这也是对「第八轮还在出 P0」最诚实的回应：文档已经审到收益递减的区间，而演练能发现的东西，文档审不出来。

🔴 第七轮：三家仍然不建议直接执行 —— 而最重的两条是我修 v7 时亲手造的 9 条 ≥2 家命中 已修

Codex「仍不建议直接执行」/ DeepSeek「仍存在会导致方案执行失效或产生新的静默风险的内部矛盾」/ 千问「不要直接进入生产真写」。3 家出票，无降级。

→ B1 的教训值得单独记：裁决①本身没错（staged 确实会被 run_promote() 放回 new），错在换一个状态值 = 换一整套下游语义，而我只审了「谁会读它」，没审「它怎么离开这个状态」。状态机既要看入边，也要看出边。staged 有出边（方向错了）；paused 一条出边都没有——我把「有一条坏出边」换成了「没有出边」，并把它当成了改进。

→ B4 是同族的另一面：把一条规则写进「状态转换矩阵」，会让人默认「有个东西会执行它」。但矩阵是被动的，它只描述「事件来了怎么办」，不产生事件。没有事件源的矩阵行 = 一条永远不执行的规则，而它在文档里长得和其它行一模一样。

B2 的根因：检查器的三条互不相同的结构性缺口 全堵上 + 各钉一条回归自检

→ 中间那条与 v7 那次「grep -v '§0d' 把要修的行一起过滤掉了」是同一族：豁免规则的粒度比缺陷的粒度粗，豁免就会盖住缺陷。

→ ⚠️ 放松豁免规则之后必须回来验它仍会红，否则就是「改到绿为止」——本仓最常见的自欺形状。已对三条缺口各钉一条回归自检（喂当初真漏掉的那三行原文）+ 一条反向控制（纯历史叙述不许误报）。自检 4 条 → 9 条，全过。

本轮收益最高的一条：A9 的读方条件级审计直接推翻了 v7 的批 3 方案 差点装错

v7 让批 3 的 79 人写 staged，语义写的是「已进入外联流程、由 Hermes 负责发」。实查发现 staged 在本仓的真实语义是反的：

apollo_netnew_leadpull.py:2086 run_promote()
  取件谓词 status = eq.staged（默认不带 lead_source 过滤）
  动作     sb_patch(..., {"status": "new"})  ← staged → new

→ 那等于给正在修的「双发」装了一个单条人工命令（--promote --apply）就能复位的开关，而执行那条命令的人看不到任何提示说这 79 人是 Hermes 的。⇒ 裁决①：批 3 改写 paused——零自动写方、已在 OCCUPYING_STATUSES 内、且不宣称已触达。

本轮我自己撞到的两个坑（不是外审提的）

① 我先断言「这三列是纯数据列，没有触发器」——实查有 2 个。outreach_sequences_anchor_n1 在 email/linkedin_url/discovery_meta 上触发且会抛异常，正好挡住我原本打算在 A12 里写的 discovery_meta.backfill_provenance；touch_updated_at 每次写都刷 updated_at，直接推翻了「撤销时比对快照时刻」这个 CAS 基准——用快照时刻当基准，撤销脚本会一行都改不了却看起来很安全。

② A6 / A10 各有一半不成立。实查重复邮箱 0 组（A6 说的「一邮箱多 sequence」今天不存在，真洞是 267 行根本没有 email，其中 62 行已 staged/contacted）；297 = 571 − 274 今天仍精确成立（A10 错在它被写成裸数字、且混淆了存量与日增）。

→ 外审看不到库。不实查就照单全改，会把方案改坏在一个不存在的问题上。

⚔️ 攻击 5（最重）：「全自动」在 S4 上做不到，而且原因在仓库外 推翻标题目标

三重阻断里有两重改代码绕不过去（详见 §10）：REST search/match 被 plan-gate 回 403 API_INACCESSIBLE；reserve_quota() 对 provider='apollo' 硬 RETURN FALSE（migration 076b，刻意封的）。

→ reveal 只能走 Apollo MCP，而 MCP 要在 Claude 会话里调。目标改成「全自动除了 S4 这一个有名有姓的人工环」。这条要写在最显眼的地方——否则下一个人会花几天去「打通 S4 的自动化」，而那几天的产出必然是 0。本项目已有四次「建好了、过了外审、没接线」，这次的形状更糟：接线本身不可能成功，而失败原因在仓库外。

⚔️ 攻击 3：计划的范围和 Graham 的死线互斥 优先级排错了

死线是「任务 7 9/10 开工」+「2,021 credit 9/16 归零」。而计划内容是改数据库层闸 + 收敛 9 个入口 + 存量清理 + 回流 5,680 家——8 天落不了地，落地了也不产生一个 reveal。

→ 劈成两条互不阻塞的线：线 A（抢额度，9/16 硬死线）= 每天一次 MCP bulk_match → 落盘 → --ingest，已验证跑通、不需要任何新架构；线 B（管道收敛）无硬死线。线 A 是排期问题，不是工程问题。