范围与执行约束

2026-11-10 默认分支代码审计。以下报告含基线、证据、复现边界、价值排序和详细计划。首批事项经过独立复核后按 sub-issue 实施，其他事项保留研究计划。协作检查只覆盖已推送工作，实施前再次核对。

FastInsight 源码审计与实施建议

审计日期：2026-11-10。仓库：Q:/FullStack/fastrd/fast-insight。基线 4dd0f141d72e05e7ddc784fee9bb1cafbec2e886。独立复核见 REVIEW-fast-insight.md。

1. 结论与协作边界

推荐首批修复“验证 query 保留已有 URL + 正确解析 sender 嵌套 ID”。 前者直接防止已知论文定位线索丢失，后者是明确、低成本的输入归一化错误。取消生命周期问题成立，但跨越 capture、工作线程与发布边界，宜独立做最小设计后实施。

完整读取 PR #1 diff：仅修改 fastinsight/article.py、scripts/verify_paper.py 的 arXiv regex，以及 tests/test_article.py、新增 tests/test_arxiv_identifiers.py。本报告的首批建议限定 scripts/auto_pipeline.py、fastinsight/parse.py 和相应 query/sender 测试；不触碰 PR 的两个实现文件及两个测试文件。空 checks 不能解释为 CI 通过。PR 内容仅做范围审阅，没有检出执行其 head 测试。

2. 架构和实际阅读范围

飞书 WebSocket SDK → bot.handle_event / parse_event
→ 每 chat 的 capture（JSON 状态 + fcntl 文件锁）
→ 事件/历史轮询 claim_payload 去重 → 每项独立线程 _process
→ URL / vision / OCR → pipeline.process_paper
→ auto_pipeline.enrich_paper → verify_paper 子进程
→ LLM trend → route_paper 子进程 → _publish HTTP
→ confirmation_text → 源会话提示

capture 的 fcntl 锁保护单次文件状态操作；bot 的 _batch_lock 保护内存 stop 映射。它们未共同构成覆盖 arm、cancel 和已启动发布任务的生命周期事务。

完整阅读：fastinsight/bot.py、capture.py、parse.py、pipeline.py、scripts/auto_pipeline.py、tests/test_pipeline.py、README、requirements。定向阅读：fastinsight/feishu_api.py:1–90、tests/test_parse.py:1–100、scripts/verify_paper.py:1080–1264；另读 PR #1 全部 diff。搜索定位 query、取消、sender 和回执处理。辅助核对本地 FastResearch server/index.mjs:1530–1561 的回执生产逻辑；它不构成本次 Insight 基线的一部分，也未做跨服务联调。

3. 发现和优先级

INS-1：已有 URL 没有进入验证输入

缺陷类别是跨阶段构造输入时丢失已有确定性证据。规则是：检索优化可以增加标题/检索词，不能删除用户已提供的论文定位线索。

_verification_query 只组合 search_query/title、doi、arxiv_id，没有读取 url。真实 paper_from_url('https://arxiv.org/abs/1706.03762', 'A separate descriptive title') 保留 url，却生成 query A separate descriptive title。随后 verify_paper 1093–1101 只能从 query 提取标识、触发 direct lookup，原 URL 中的 ID 已不在输入内。

标题本身恰好是 URL 时会偶然保留，因此不能写成“所有链接输入必然丢失”。风险集中于链接伴随描述、OCR/vision 或文章抽取的结果已含 url 而没有独立 doi/arxiv_id 字段。问题不是 PR #1 的四位 ID regex。

INS-2：可抓取页面被当作相关论文身份依据

_merge_web_fallback 67 在 page_fetched=True 时允许覆盖既有 URL；73–79 无相关性门槛覆盖 title/authors/year/venue/doi/arxiv_id。page_fetched 证明读取成功，不能证明属于同一论文。

实测 existing 为 Known paper、https://doi.org/10.1000/known、doi 10.1000/known；fallback 为另一页面、match_score=0.01、page_fetched=True。结果 title、url、doi 全换成 fallback。虽然输出标记 verified_by_academic_sources=False，process_paper:293–295 仍继续 trend 与发布，没有这个标记的发布门禁。

这不只是假设性不可达输入：verify_paper 1195–1223 选择有页面的 web candidate 时没有相同相关性门槛，1247–1250 仅添加人工确认 warning。未运行真实搜索验证其发生频率；本次证明的是合并规则及候选链可达条件。后续修复应保留不确定候选，只有足够的同一身份依据才覆盖已有身份，不能把“页面读取成功”升格为相关性证明。

INS-3/4：捕获状态与任务生命周期不同步

_cancel_image_batch pop stop、set、finish capture；stop 仅在轮询线程 268、297 被检查。_process 接收 batch_id，却没有读取它或检查取消状态，仍在识别后直接调用 process_paper。

受控复现：工作线程停在 _payload_to_paper 外部耗时边界；调用真实 cancel 后 capture 已非 armed、stop=True；释放识别步骤后，仍调用 process_paper 一次。探针用记录函数代替发布流程，没有真的发出 HTTP 发布；静态生产链 process_paper → run_auto_pipeline → _publish 证明其后续有发布副作用。已经提交的远端发布无法靠取消撤回；报告不声称可以撤回。

另一路交错：_start_image_batch 在 166 注册 stop 并释放内存锁，172 才 arm。此间 cancel 移除 stop，finish_batch 对尚不存在的 record 返回 finished=False（capture 301–302）；继续 arm 后 record 又为 armed。实测 armed=True、stop_registered=False、_active_image_batch 非空。事件 dispatch 此时仍可按该 batch claim 新任务。

只在 _process 开头加一次 if 不足：取消可在识别或 trend/verification 之后、真正 publish 之前到达；只把 arm 提前也可能制造对称竞态。最小方案需让单一批次身份/状态拥有生命周期，并定义取消与单个发布的线性化点。

INS-5：sender dict 的错误字符串化

_sender_id 323 先对 sender.id or sender.sender_id 调用 str，非空 dict 会产生非空字符串，324–325 提前返回，326–328 的 nested 分支对该输入永远到不了。

实际 parse_event 输入 sender_id={"open_id":"ou_example","user_id":"user_example"}，返回 "{'open_id': 'ou_example', 'user_id': 'user_example'}"，不是 ou_example。影响 bot 128 自身 ID 比较和 payload 的 sender_id；不能夸大为已经观察到重复发布，因为 125 的 sender_type == app 检查可能先挡住应用消息。现有 test_parse 输入中已有嵌套结构，却没有对应 sender_id 断言。

INS-6/7：成功结果与候选接收人混用

confirmation_text 先收集 route 所有 owners，再合并 deliveredTo。给定 owners A/B、成功仅 A、错误 B: failed，原函数输出：

⚠️ 《Example》已部分发布至 FastResearch（未分类）（@A、@B）。失败：B: failed

失败者仍出现在发布名单，容易误导操作者。修复应从确认成功结果构造成功名单，失败者留在失败段。

_publish 则把任意可解析 JSON 返回给调用者，process 无检查地 append 到 delivered。HTTP 边界返回 {"ok":false,"deliveredTo":[]}，原函数原样接受；非空 delivered 列表还会触发成功文案分支。当前本地 Research 实现 1559 正常返回 201 {ok:true,deliveredTo:[...]}，无目标用 404，因此这是客户端协议校验缺口；不能报告为“当前 Research 正常响应总是假成功”。验收应使用真实协议的本地 HTTP fixture，覆盖非对象、ok=false、空/不合法 deliveredTo。

4. 建议实施计划与验收

批次 A：严格保留已有 URL 的 query + sender 归一化

• 范围：scripts/auto_pipeline.py、fastinsight/parse.py；query 回归放既有 tests/test_pipeline.py，sender 回归放 tests/test_parse.py。PR 修复四位 arXiv 编号识别与过长数字误截断 #1 的四个文件均不动。
• query 最小修复：沿用当前输入字段，把已有非空 URL 作为原始定位线索保留到 query，再补 title/search_query 与现有显式 ID。不得重新实现 article/verifier 的 regex，不新增调用方字段，不用标题兜底覆盖 URL。检查 enrich_paper 的提前返回路径，保证 URL-only 也能到达验证。
• sender 最小修复：先按字符串 ID / 嵌套对象形态归一化，再选 open_id、user_id 等既有优先级；嵌套对象绝不能通过 str(dict) 进入身份字段。复用现有字段，不扩大为身份解析框架。
• 最小设计五问：解决输入丢证/身份形态混用的类别；调用方零负担；来源字段由系统确定；两个现有函数足够；覆盖链接和事件形态而非某篇论文/某个用户。简单追加提示词不能恢复未传给 verifier 的 URL，输出端替换身份字符串也无法修正消费者使用的 ID。
• 验收：URL+描述、URL+search_query、URL+DOI/arxiv_id、URL-only 均保留原 URL；无 URL 的原 query 优先级保持；从生产 enrich_paper 调用拦截 verifier 命令确认 --query 含原始线索。通用网页 URL 的抓取规则仍按既有 verifier 语义，不声称此次补 query 就解决 INS-2。
• sender 验收：parse_event 的嵌套 open_id/user_id、parse_feishu_message 的字符串 ID、空字段与 ID 优先级；结果不得含 dict repr。以 bot 自身 ID 比较验证该结果确实可被下游使用。

批次 B：身份合并和真实发布确认

• 分两项小改：先在 auto_pipeline 限定 fallback 覆盖身份所需依据；再以实际发布回执产生 delivered 与 confirmation 名单。
• 验收：低分但 fetched 页面不覆盖既有身份；具有明确同一身份依据的补全仍可进行；缺身份的发现保留不确定性。完整成功、部分成功、全部失败分别展示准确名单；异常 2xx JSON 不计入成功。确认协议后只保留一套回执规则。
• 若需要调整 verify_paper，本批必须等 PR 修复四位 arXiv 编号识别与过长数字误截断 #1 合入或与其作者协调；首批不借此修改该文件。

批次 C：取消语义与批次所有权

• 先明确取消契约：停止新增捕获，并阻止取消线性化点之后尚未提交的发布；已开始/已完成 HTTP 发布的语义须可解释。
• 方案边界：复用现有 batch_id 和 stop；用一个生命周期所有者协调注册、arm、cancel，原状态去重能力继续存在。若需传递任务上下文，只加表达“这项工作属于哪个批次”所必需的最小上下文；不引入通用作业调度/重试系统。
• 验收：cancel 发生在注册与 arm 之间、claim 后、识别中、验证/trend 中及 publish 前，各有受控交错；取消后不再 claim，不再进入未提交的 publish；旧批次不得关闭/恢复新批次；自然时间窗结束不应误取消已经合法登记的任务；已发送请求不伪称可撤销。
• 单次状态检查存在检查—副作用竞态，验收需明确 publish 的提交边界，避免只在函数入口加 guard 就宣称完成。

后续命令：Linux/WSL 下 python3 -B -m unittest discover -s tests -v，另运行隔离 HTTP fixture 和 bot 交错用例。生产飞书/Research 联调只在后续实施需要时执行。

5. 实际验证、材料与限制

材料目录 D:/Temp/opencode/fastrd-audit-20261110/：

1. python -B -X utf8 insight-probe.py：运行原 paper_from_url、query、merge、parse_event、confirmation_text、_publish；只替换 HTTP 边界，输出分别为 query 不含 URL、低分覆盖、sender dict repr、部分成功名单 A/B、坏回执被原样返回。
2. wsl -d Ubuntu -- python3 -B /mnt/d/Temp/opencode/fastrd-audit-20261110/insight-bot-probe.py：原 bot 方法与真实 CaptureStore/fcntl；SDK 不可用，导入时用 lark_oapi 和 feishu_api stand-in，实例用 __new__ 注入外部飞书替身；process_paper 仅记录调用。结果：stop=True, armed=False, process_paper_calls_after_cancel=1；arm 交错结果 armed=True, stop_registered=False, active_batch=True。
3. wsl -d Ubuntu -- python3 -B -m unittest discover -s /mnt/q/FullStack/fastrd/fast-insight/tests -t /mnt/q/FullStack/fastrd/fast-insight -v：45 tests，全部 OK；Python 3.14.4，可用 yaml。
4. Windows Python 3.13.5 首次运行 python -B -m unittest discover -s tests -v：26 项中 1 error（无 fcntl）、1 failure（子进程 GBK 无法输出 emoji）；随后改用 Linux 完整验证。不能把这两项称为已复现 Linux 产品缺陷。

没有安装或运行真实 lark-oapi 会话，没有调用真实学术搜索、LLM、飞书或 Research 发布。动态结论明确止于探针边界；取消探针证明调用继续，不是远端已写入的实测。测试全绿说明现有断言通过，不能反证本报告未覆盖场景。

远端状态通过 gh pr list --state all、gh pr diff 1、gh pr view 1 --json baseRefOid,headRefOid,files,mergeable,statusCheckRollup、gh issue list --state open、git ls-remote --heads origin 核实。本阶段仅新增本地审计/复核报告，没有改源码、开 issue/branch、commit 或 PR。

独立复核

FastInsight 独立复核结论

日期：2026-11-10；基线 4dd0f141d72e05e7ddc784fee9bb1cafbec2e886。本次重新读取源码、完整查看 PR diff 并做隔离实验，属于独立证据复核；没有委派其他审阅者。主报告见 AUDIT-fast-insight.md。

1. 复核裁决

2. 首批范围裁决

推荐 URL query + sender，取消修复另批设计。

• query 负责保留既有定位证据；sender 负责输入形态归一化。改动集中于 scripts/auto_pipeline.py、fastinsight/parse.py 与 tests/test_pipeline.py、tests/test_parse.py。
• PR 修复四位 arXiv 编号识别与过长数字误截断 #1 的 article.py、verify_paper.py、test_article.py、test_arxiv_identifiers.py 不纳入首批。仅无文件重叠还不等于无语义冲突，合入后仍需跑 query/标识联合验收。
• 首批不是 INS-2 身份合并问题的完整解决方案；保留 URL 只能恢复 verifier 输入线索，不能把低相关 fallback 自动变正确。
• 本次没有改源码、创建 issue/branch；这里的“推荐”是后续实施范围，不能当作修复已经完成。

3. 取消方案的最小设计要求

缺陷类别是生命周期由内存 stop 映射和持久化 capture 状态分别拥有，且工作线程不受该生命周期约束。规则应为：每项工作都绑定一个批次身份，只有该身份允许提交时才能产生新的发布副作用。

开始实施前需明确：

1. arm/register/cancel 使用哪个单一所有者决定状态转换，旧批次不得影响新批次。
2. 自然窗口结束只停止登记，不能误取消已登记任务；显式取消的发布语义单独规定。
3. 取消与 publish 的线性化点在哪；取消返回后哪些请求可能已在途，不能承诺撤回已提交结果。
4. 复用 batch_id/stop，任何新上下文只表达必要身份/取消能力；不用新队列、任务数据库或通用恢复层替代小范围同步修复。

只在 _process 开头加 if 会遗漏识别、验证、trend 中到达的取消；把检查放到 publish 前但无协调，也仍有检查—提交间隙。验收必须安排这些交错，而不是只测取消后 status.armed=false。

4. 验证结果与可信度边界

• Windows 原测试首次运行：26 项中 1 error、1 failure，分别为缺少 fcntl 与 GBK 输出 emoji 失败。
• WSL Ubuntu Python 3.14.4：原基线 45 tests 全部 OK。这证明现有测试通过；新增复现情形不在现有断言内。
• 普通函数探针执行真实解析/merge/query/confirmation/_publish，HTTP 仅作替身，不访问远端。
• bot 探针执行真实 bot 方法及 CaptureStore/fcntl，缺少 lark-oapi 时导入 SDK/Feishu 模块由 stand-in 替换；只记录 process_paper 调用，不构成完整飞书 SDK 或真实发布验证。
• 已完整阅读 bot、capture、parse、pipeline、auto_pipeline、test_pipeline、README、requirements；定向阅读 verifier 1080–1264、feishu_api 1–90、test_parse 1–100，PR diff 全读。其他模块与 PR head 运行时行为未完整审阅。

复现脚本、命令和输出摘要存放位置见主报告第 5 节。仓库 status、工作树与暂存区 diff 最终为空。源码净行变更为 0；新增根目录两份本仓库报告。未执行真实飞书、搜索、LLM 或 FastResearch 联调。

5. 后续验收门槛

首批必须经真实 enrich_paper 调用确认 --query 保留原 URL，覆盖有/无 title、search_query、显式 ID；sender 经 parse_event/parse_feishu_message 进入下游，得到稳定字符串 ID。不得复制 verifier regex 形成另一套规则，不新增用户参数。

后续 fallback、回执、文案分别验证“候选相关性”和“确认成功名单”，成功名单只来自已校验回执。取消批次必须覆盖注册/arm、claim、识别、验证/trend、发布前的受控交错。实施前重查 PR #1 与远端分支，修复后运行 Linux 全套测试及针对生产边界的回归。