背景
先说，DeepGraph 整体设计—— 闭环 discovery、SQL signal_harvester 零成本跑信号、meta_learner 从历史自我调整、venue routing 这套都很扎实，而且 evidence_gate、claim_grounding、result_interpreter、require_submission_ready() 这些 grounding / gate 模块该有的都有。框架是有潜力的。
读了代码、也看了几篇产出之后，有一个观察想和你们商量。
观察
这些门目前像是 "建好了但没真正实质闭环" —— 产出里偶尔出现合成数字、未解析引用（? / Table ??）、自相矛盾的正文，而这些本应被 require_submission_ready() 拦住（README 里写的是 "synthetic data never reaches a manuscript bundle"）。
下面三条是我的建议（供讨论，不是结论），每条把收益和代价都列出来，方便你们权衡。
建议 1 ｜ 选题层加"可验证性准入"
观察: paper_idea_agent / idea_route 目前似乎不区分"结果能否机器判定"。
提议: 是否可以考虑 —— 每个 idea 必须自带一个可执行 verifier（solver / exact-match / 可复算 ground-truth），evidence_gate 在立项处直接拒掉没有 verifier 的题？
- 收益: 从源头消灭幻觉结果。生成层有了硬锚就编不动；每篇产出自带可复现验证，系统可信度上一个台阶，reviewer 和用户的信任才建立得起来。
- 代价: 选题空间收窄，一部分宏大但暂时无法验证的方向得先放。
- 权衡: 短期少做题，长期每篇都立得住。这条最深，也最需要你们自己拍板，所以放第一个一起讨论。
建议 2 ｜ 结果强绑定稿件，写作层从"作者"变"播报员"
观察: real_experiment_runner / result_interpreter 都在，但稿件里出现过账本里不存在的数字（例如标题数字全文找不到、abstract 与表格对不上）。
提议: manuscript_generation 是否只允许引用 run artifact 的字段、任何数字都可回溯账本，并让 result_interpreter 的 verdict（refuted / supported）强制约束 abstract / conclusion 的措辞？
- 收益: 数字永远自洽可回溯，"标题数字全文找不到"这类硬伤彻底消失；稿件可信度 = 实验可信度，没有写作层的额外失真；出问题也好定位。
- 代价:
manuscript_generation 要从"写数"重构成"取数"，前期有中等改动量。
- 权衡: 一次性改造，换长期免去无穷的事后核对。
建议 3 ｜ 把 require_submission_ready() 变成真 block，补四个确定性检查
最便宜、当周可上，建议先做。
观察: format_linter 具名检查偏排版（字体、间距、引用密度），没覆盖真正出事的点。
提议: 加四个硬检查，任一命中即 fail、禁止出稿：
| # |
检查 |
命中条件 |
| a |
未解析引用 |
正文 / 参考出现 ?、Table ??、Figure ?? 等未渲染占位 |
| b |
生图脚手架泄漏 |
caption 含生图指令原文（如 Create a … figure、No in-image title） |
| c |
跨 run 身份串台 |
正文出现非本题的方法名 / 概念（与锁定 topic 不符） |
| d |
模板 boilerplate 重复 |
同一句出现 ≥ 3 次 |
- 收益: 最便宜，当周可上；自动拦住绝大多数"一眼假"产出；
require_submission_ready() 名副其实；CI 自动化，不靠人工 review。
- 代价: 几乎没有，纯确定性检查，误杀率极低。
- 权衡: 近乎全是收益 —— 所以哪怕 1、2 还要讨论，这条可以先合。
建议落地顺序
3 先做（减少明确的浪费）→ 2 → 1（根治）。
当然你们更懂自己的 codebase，顺序和取舍你们定。
Checklist
背景
先说，DeepGraph 整体设计—— 闭环 discovery、SQL
signal_harvester零成本跑信号、meta_learner从历史自我调整、venue routing 这套都很扎实，而且evidence_gate、claim_grounding、result_interpreter、require_submission_ready()这些 grounding / gate 模块该有的都有。框架是有潜力的。读了代码、也看了几篇产出之后，有一个观察想和你们商量。
观察
这些门目前像是 "建好了但没真正实质闭环" —— 产出里偶尔出现合成数字、未解析引用（
?/Table ??）、自相矛盾的正文，而这些本应被require_submission_ready()拦住（README 里写的是 "synthetic data never reaches a manuscript bundle"）。下面三条是我的建议（供讨论，不是结论），每条把收益和代价都列出来，方便你们权衡。
建议 1 ｜ 选题层加"可验证性准入"
观察:
paper_idea_agent/idea_route目前似乎不区分"结果能否机器判定"。提议: 是否可以考虑 —— 每个 idea 必须自带一个可执行 verifier（solver / exact-match / 可复算 ground-truth），
evidence_gate在立项处直接拒掉没有 verifier 的题？建议 2 ｜ 结果强绑定稿件，写作层从"作者"变"播报员"
观察:
real_experiment_runner/result_interpreter都在，但稿件里出现过账本里不存在的数字（例如标题数字全文找不到、abstract 与表格对不上）。提议:
manuscript_generation是否只允许引用 run artifact 的字段、任何数字都可回溯账本，并让result_interpreter的 verdict（refuted / supported）强制约束 abstract / conclusion 的措辞？manuscript_generation要从"写数"重构成"取数"，前期有中等改动量。建议 3 ｜ 把
require_submission_ready()变成真 block，补四个确定性检查观察:
format_linter具名检查偏排版（字体、间距、引用密度），没覆盖真正出事的点。提议: 加四个硬检查，任一命中即
fail、禁止出稿：?、Table ??、Figure ??等未渲染占位Create a … figure、No in-image title）require_submission_ready()名副其实；CI 自动化，不靠人工 review。建议落地顺序
3 先做（减少明确的浪费）→ 2 → 1（根治）。
当然你们更懂自己的 codebase，顺序和取舍你们定。
Checklist
manuscript_generation重构边界require_submission_ready()行为：检测到合成 / 未解析 / 串台内容时硬 fail，而非告警