总体判断：值得跑 v0，且白名单 A 恰好打在我们当前最大的证据缺口上——但 packet 字段太薄，按现稿交付，"人工节省率"这个核心指标大概率不及格。 下面按面板设计侧具名回答（可直接贴进 COMMENTS.md），最后给否决项结论。

一、为什么方向是对的

1. 白名单 A 与现有缺口精确对齐。 信用窗现在是整个框架里观测最弱的一轴：HY OAS 面上读数链路已断两周（两周规则触发中，需替代源）；观察序列第 2 层（外部融资个案：IREN 项目债 9% vs IG 6% 的 ~300bp 分层、Sharon 首笔项目债定价）全靠逐案手工抓；time-to-takeout、support intensity 两个领先量都依赖"发行/担保/waiver 类原件在窗内被捞齐"。这类事件恰是事件驱动、非日历件、常只有公司稿或贷款公告没有结构化 feed 的残差——正好是 cron 抓不到、Bot 有存在理由的那一类。
2. "不给 STATE"的记忆防火墙设计正确。 与我们的纪律同构：记忆数字视为过期、隐藏正样本（Lambda 类）不进任务书才能测真发现率。这一条不要松动。
3. 六态 + 3 检索路径止损 + 同源转述不扩散，等价于我们的反查重/反 shuffle 规则，认可。
4. 价值函数定在"释放裁决带宽"而非新闻覆盖率——与"稀缺的是裁决带宽"一致，判断层（黄灯、方向票、绊线）不给 Clerk 碰，边界画对了。

二、对 §8 面板设计五问的回答

Q1 白名单 A 够不够： 核心够，补三类、防一类噪声。

• 补：①评级展望/CreditWatch/负面观察（不只 rating action——观察名单变动往往领先行动一个窗口）；②租赁/售后回租/残值担保（RVG）/take-or-pay 类 filed instrument（8-K exhibit、贷款公告附件）——这是 D/E 层与风险留存阶梯的直接证据物，且我们刚有过"按 exhibit 标题归层未读内文"的教训，Clerk 把原件 PDF 取回存档，正是防这类错误的物理前提；③私募信贷/定期贷条款披露（Blue Owl/PIMCO/Mackenzie 类,常只有公司稿无评级稿）。
• 防噪声：匿名信源的"据悉在谈融资"一律 NOT_IN_WHITELIST——传闻不是原件，进来只灌水。

Q2 最小字段：现稿缺得多，这是最大的单点问题。 只有 URL+日期+六态，判断层仍要重开每个网页做口径分类，人工节省率归零。packet 每条必须带：

• issuer / instrument_type（项目债 vs 可转债 vs 股权 vs 定期贷 vs 担保——Sharon 与 IREN 利差禁直比，没有这个字段 packet 不可用）
• amount + 币种、tenor/maturity、pricing（coupon/spread，披露了就抄，没披露写 undisclosed）
• secured/guarantee/backstop 的原文引句（verbatim，不做 A–E 归层——归层是判断层的活，Clerk 只交原话+原件）
• doc_type（8-K/prospectus/评级报告/贷款公告）
• 已有的 event_time / disclosure_time / first_seen 保留——四同门规则（同时点、同口径）在判断层执行时全靠这三个时间戳。

Q3 "缺"的基线，可执行定义： 缺 = 窗内符合白名单 A 事件类型、且不在上一期周报 cited_urls[] 中的官方事件。基线取上一期周报引用集，不取面板 last_seen——序列数据的 last_seen 是 cron 的账，Clerk 碰它只会和结构化序列打架。这也意味着周报侧吐 cited_urls[] 不是"以后 CLAIM_AUDIT 才要"，而是 v1 的 gap scan 基线依赖，现在就该加字段，成本极低。

Q4 primary 硬性要求范围： 发行条款、评级行动、waiver/covenant、担保/RVG/租赁 instrument 四类必须落 primary（IR/SEC/评级机构/贷款公告）。Reuters/韩媒/TrendForce News 类转述永远只是线索和 secondary_coverage 字段，转述不因多家复述而升级（我们有现成案例：TrendForce News 转引 Green Economy 的 Hynix 无 price cap 条款，永远 T2）。找不到 primary 就 SOURCE_NOT_FOUND，这条现稿已写对。

Q5 采样密度： 日历件明确声明"本岗不扫"——合约价、capex 指引、CSP guidance 全是日历件+已有 cron/财报回代流程。信用格 v0 就是与周报并行的周频 + 人工事件触发，不建每日班表；发现率没被数据证明前，密度升级就是原则 5 说的"没有数据证明前不扩"。

三、超出问卷的四条意见

1. 答案钥匙要赛前封存。 隐藏正样本（Lambda 类）应在跑之前写进一份 Clerk 不可见的 sealed 文件，事后对答案——否则"发现率"是事后追认，等于 in-sample 打分。这是条件①"样本内阈值必须标注"教训在流程上的投影。
2. DROP 清单点名到序列。 用户已确认结构化数据在走本地 cron，那就把 §4 的 C 项从"主题级"细到"序列级"：TrendForce 价格、韩海关 1–20 窗、TWSE、BOK、FRED 系列（含修复后的 HY OAS）明确 DROP。HY OAS 断链本身不是 Clerk 的活——那是 API 替代源的工程问题，符合 §7 自己的规则（RSS/API 能稳定抓的不升级到 Bot），别让试岗顺手接了这个锅、污染验收。
3. 三个 support 字段冗余。 support 六态、officially_supported、official_source_present 语义重叠，六态里 SUPPORTED 本应蕴含官方原件在手。建议收敛为六态 + official_source_present 两个字段并定义优先级，否则第一次试岗就会出现三字段互相矛盾的条目，浪费异常队列。
4. COMMENTS.md 追加写有覆盖风险。 我们本周刚两次实证"同文件并行 edit 互相覆盖"。两位 agent + 人共写一个追加文件,建议改为 comments/<agent>.md 各写各的,或规定串行。

四、共同否决项：不否决，但预登记停机条件

RSS+关键词是否已够？8/29 的两类实错（窗内官方融资未引原件、窗外旧文回炉）说明残差真实存在，v0 值得跑一次。但把 kill criteria 现在写死：首跑发现率 = 0 且人工节省 ≈ 0，则判"RSS 足够"，不迭代 prompt 超过一轮、不上 Routine——否则这个实习生会变成第二套监测,违背它自己的原则 1。