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

[Protocol-zero-0]

背景

在 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 或强推。

当前分支判断

分支/对象	当前判断	建议
main	default branch，Git 历史主线清晰	保留为 default/history 主线
master	代码内容最新、能力最完整，但与 main 无共同祖先	作为“内容来源”保留，后续收敛后归档/删除
workspace/local-2026-05-20	是 master 的祖先，内容已被 master 覆盖	收敛完成后归档/删除
codex/paper-progress-and-preview-fixes	已通过 PR #17 合入 main	归档/删除
pr/nanobanana-motivation-overview-figures	已通过 PR #16 合入 main	归档/删除
production	旧快照，缺少大量后续架构能力	不作为生产/开发主线；建议重命名归档，如 archive/production-2026-04-30
PR #18	修复 acceptance/repro/doc/hash，mergeable 但 CLA 未通过	优先吸收其内容，或待 CLA 后合入
PR #8	visualization pipeline，open 且 not mergeable	暂缓，主线稳定后再评估

推荐主线策略

建议不要直接把 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”收敛成“可信、可复现、可继续协作的科研系统”。

[koen666]

先别管这个，main是主功能分枝，master是最新版本分支

[Protocol-zero-0]

先别管这个，main是主功能分枝，master是最新版本分支

基于目前的进展，需要进一步讨论下

背景

当前项目已经能持续产生有价值的科研过程和实验成果。随着后续需要稳定对外展示 Dashboard，并持续进行研发实验，建议
先做一个最小架构分离：

• 临时 GPU 环境负责科研计算和实验执行
• 稳定服务器负责长期资产保存和 Dashboard 展示

具体落在哪个分支、如何合并现有实现，请维护团队结合当前分支收敛工作自行判断。本 issue 只讨论运行架构和资源使用原
则。

建议原则

1. 计算资源可以是临时的

   GPU 资源适合作为弹性计算窗口：有资源时继续跑实验，没有资源时暂停产出。科研发现流程不需要依赖 GPU 24 小时在
   线。

2. 科研资产必须稳定保存

   不只最终论文，中间过程也应视为有价值资产。包括实验 spec、运行日志、代码、benchmark manifest、result packet、
   图表、paper / submission bundle、状态快照等。

3. Dashboard 不依赖 GPU 在线

   对外展示服务应读取稳定服务器上已经同步的资产。GPU 离线时，Dashboard 仍能展示已有成果，只是不继续新增产出。

4. 第一阶段保持轻量实现

   不建议一开始做复杂分布式调度。可以优先用 sidecar 同步进程、artifact export hook、定期 DB/metadata snapshot
   等低侵入方式完成资产同步。

最小目标

• 每次有价值实验或阶段性结果产生后，能同步到稳定服务器
• 稳定服务器保存历史资产，并支持后续归档
• Dashboard 基于稳定资产展示，不直接依赖临时 GPU 机器
• 每个重要 run 能追溯到对应代码版本、配置和主要产物

轻量协作建议

• 用于真实实验运行的代码，应及时 push 到 GitHub
• 重要实验应记录 branch / commit / config，便于复现和协作
• 稳定展示版本与活跃研发版本尽量分开
• 架构、部署、资源使用变化尽量通过 issue / PR 留痕

这样可以在不大改现有系统的前提下，降低临时计算资源变化带来的风险，也方便后续协作和持续维护。