[Maintenance] 分支主线收敛与归档建议：以 main 为历史主线、吸收 master 内容 #22

背景

在 2026-05-26 对当前 GitHub 远端分支、PR、issue 和代码结构做了一轮实际检查后，发现 DeepGraph 当前存在一个需要维护者判断的分支治理问题：

• main 是 default branch，包含 PR feat(#9): agenda-driven autonomous research loop #10/Integrate motivation and overview figure generation #16/Codex/paper progress and preview fixes #17 等已合入工作。
• master 是当前代码内容最完整、最新的分支，包含 2026-05-20 的实验执行/async forge 能力，以及 2026-05-25 的 manuscript hardening、quality gates、page budget、compile repair、publication tables 等。
• 但 main 与 master 没有共同 merge-base，说明 master 很可能不是从当前 main 正常分出来的 Git 历史，而更像某个时间点手动复制/重建代码树后推送的分支。
• production 名称容易误导，但从代码结构看更像 2026-04-30 的旧快照，缺少后来进入 main/master 的 agenda loop、evidence gate、venue routing、format linter、tests 等能力。

本 issue 仅提出建议，请主维护者判断；不建议在未经确认前直接删除、改 default branch 或强推。

当前分支判断

推荐主线策略

建议不要直接把 master 设为 default，也不要直接用 master 覆盖 main。

推荐路线：

main                         当前 default，保留
  \
   stabilize/mainline-from-master   新建收敛分支
      ├─ 吸收 PR #18 的复现/acceptance 修复
      ├─ 吸收 master 中实验执行与 manuscript hardening 内容
      ├─ 修复 issue #21 的 submission hard gate
      └─ 验证通过后 merge 回 main

master                       暂作内容来源，收敛完成后 archive/delete
workspace/local-2026-05-20   archive/delete
production                   rename/archive
PR #8                        wait

为什么建议这样做

1. 保留 Git 历史清晰度

main 是 default branch，已有 PR 合并历史。即使 master 内容更完整，也不建议把无共同祖先的分支直接变成主线，否则后续 blame、PR diff、review 都会变得混乱。

2. 保留最新工程能力

master 的代码内容明显比 main 新，尤其是：

• async experiment forge / runner
• compute routing / experiment watchdog
• manuscript compile repair
• manuscript page budget
• publication tables
• submission enrichment/style/visual audit
• stronger require_submission_ready() 相关 gate

这些内容不应丢弃。

3. 避免 production 名称误导

production 当前更像旧快照，不适合作为后续开发或部署事实来源。建议改名归档，避免新贡献者误基于它继续开发。

4. 先解决可信度，再扩功能

结合 #21，当前最应该优先做的是 submission integrity / hard gate，而不是继续合 UI、tunnel、visualization、新 venue、新 agent 等功能增量。

建议的近期 P0 工作

P0a: 分支收敛

• 从 main 新建 stabilize/mainline-from-master
• 以 master 为内容来源，按模块分组吸收代码，而不是直接强推覆盖
• 明确保留/归档/删除分支列表
• 合并后保持 main 为 default branch

P0b: 吸收 PR #18 的复现修复

• scripts/demo_agenda_loop.py
• scripts/verify_acceptance.sh
• deterministic / structural acceptance hash
• 修正 stale acceptance artifacts 与文档路径

P0c: 对齐 issue #21 的最小高价值目标

优先实现 #21 的建议 3：让 require_submission_ready() 成为真正 hard block，并补四类确定性检查：

• 未解析引用：?、Table ??、Figure ?? 等
• 生图脚手架泄漏：caption 中出现 Create a ... figure、No in-image title 等
• 跨 run 身份串台：稿件出现非本 run/topic/method 的概念或方法名
• 模板 boilerplate 重复：同一句出现 3 次及以上

这些检查最适合做成可对外展示的 demo：坏稿件被明确 blocked，修复后通过，并且 CI 可复现。

暂缓事项

建议在分支收敛和 #21 hard gate 完成前暂缓：

• [Enhancement] 前端 UI 视觉优化：整体样式与知识图谱展示美化 #19 Dashboard UI 美化
• [Enhancement] 内网穿透：让 DeepGraph Web 服务可被外网访问 #20 外网穿透/前后端暴露方案，尤其是未完成鉴权前
• PR Add SciForge visualization pipeline #8 visualization pipeline
• 新 venue、新 agent、新 benchmark 扩展

期望维护者判断

请维护者决定：

• 是否认可 main 作为历史主线、master 作为内容来源的收敛策略
• 是否新建 stabilize/mainline-from-master 承接后续工作
• 是否将 workspace/local-2026-05-20、codex/paper-progress-and-preview-fixes、pr/nanobanana-motivation-overview-figures 归档/删除
• 是否将 production 重命名归档，避免被误认为当前生产主线
• 是否优先处理 下一个改进方向的建议：严格产出完整性 —— 可验证性准入 + 结果绑定 + 提交硬校验 #21 的 submission hard gate，再恢复新功能开发

建议结论

短期不建议继续扩功能。建议先做：

1. 分支收敛；
2. 复现路径修复；
3. 下一个改进方向的建议：严格产出完整性 —— 可验证性准入 + 结果绑定 + 提交硬校验 #21 submission hard gate；
4. clean checkout acceptance 一键验证。

这样 DeepGraph 才能从“功能很多的 demo pipeline”收敛成“可信、可复现、可继续协作的科研系统”。