governance: 代码库公开方案——理论隔离、隐私安全与 Git 历史清洗

[ARCJ137442]

背景

ExoMind 代码库当前为私有仓库，需要实现公开以让社区访问。公开过程需要完成代码清理、隐私审查和标准文件补齐。

约束

1. 代码库公开（核心目标）：让所有人都能访问代码库
2. 早期草稿清理：部分早期探索性文档和实验代码属于零散的原始想法，方向已验证过于分散，不适合保留在公开仓库中。迁移到独立归档即可，无需深度清洗。
3. 隐私安全：Git 提交历史中不能包含敏感个人信息

验收标准

• AC1: 早期实验性代码和文档已迁移到独立归档仓库
• AC2: 提交历史中无敏感个人信息（PII）
• AC3: 提交历史结构尽量保留（非 squash 式丢弃）
• AC4: 公开仓库可正常编译和运行
• AC5: CI/CD 在公开仓库正常运行
• AC6: 标准开源文件补齐（CONTRIBUTING / GOVERNANCE / SECURITY / CODE_OF_CONDUCT）

当前状态（2026-03-24 审查）

已通过

• 密钥/凭据安全 — 无硬编码 secret，.env 正确 gitignored
• PII — 无真实姓名，全部使用代号
• 构建可用性 — tsc 通过，CI 正常

待处理

• 早期实验文件迁移（6 个 Rust 文件 + 若干文档，方向过于零散，迁出即可）
• agentation-mcp 的 PolyForm-Shield 许可证需审查
• 标准文件缺失（CONTRIBUTING / GOVERNANCE 在 PR docs(governance): ExoMind 集体经济与治理体系 v1 #565 中待合并）
• SECURITY.md / CODE_OF_CONDUCT.md 缺失
• 大文件清理（pencil/ 设计稿 ~15MB，app_qwen_icon.png 4.3MB）
• Dependabot 报告的 5 个安全漏洞（2 high, 3 moderate）

详细审查报告

见本 Issue 评论区的完整审查报告（2026-03-24）。

关联/依赖

• 关联：
  • docs(governance): ExoMind 集体经济与治理体系 v1 #565（PR：治理体系文件）
  • governance(v0.3): 项目治理与路线跟踪 #239（项目治理与路线跟踪）
  • feat(web-growth): 宣传官网 + 下载分发闭环 + 统计与反馈 #262（宣传官网 + 下载分发）

[ARCJ137442]

代码库公开方案——穷尽式枚举与系统性决策分析

基于 4 个并行调研 Agent 的全面扫描结果 + 系统性决策分析
分析时间：2026-03-20
dev: 3815c67

---

一、方案空间的结构化分解

任何方案都可以沿两个独立轴分解：

轴	选项
目标仓库：清洗后的代码最终存在哪里？	原仓库 / 新仓库
历史保留：提交历史保留到什么程度？	完整重写 / 部分截断 / 全部丢弃

组合后得到 6 个理论位置，其中可行的有 5 个：

                  ┌─────────────┬──────────────┐
                  │   原仓库     │   新仓库      │
  ┌───────────────┼─────────────┼──────────────┤
  │ 完整历史(重写) │  方案 A      │  方案 C       │
  ├───────────────┼─────────────┼──────────────┤
  │ 部分历史(截断) │  (不合理)*   │  方案 F       │
  ├───────────────┼─────────────┼──────────────┤
  │ 无历史        │  (不合理)*   │  方案 D       │
  └───────────────┼─────────────┼──────────────┘
                  │
                  * 在原仓库丢弃/截断历史没有意义，
                    既然要动历史不如完整重写

此外还有一个正交维度：是否需要持续同步（方案 E）。

加上用户提出的方案 B（分支替换），总共列举 6 个方案。

---

二、6 个方案的完整定义

方案 A：原地清洗（用户路线1）

当前仓库 ──[git-filter-repo]──→ 同一个仓库 ──[force push]──→ GitHub 原 URL
                                                               ↓
                                                          设为 public

操作：在当前仓库上直接执行 git-filter-repo，清除理论文件和提交消息，force push 覆盖 GitHub 上的所有分支和标签。

核心特征：URL 不变、哈希全变、GitHub 上的旧 commit 对象变成 dangling。

---

方案 B：分支替换（用户路线2）

当前仓库
  ├── dev (现有, 含理论)
  ├── main (现有, 含理论)
  │
  ├── dev-clean (新建, 从第一个提交开始 cherry-pick/filter)
  └── main-clean (新建)
      │
      ↓ 替换
  dev-clean → dev
  main-clean → main
      ↓
  force push → GitHub

操作：在同一仓库内，创建新的干净分支，逐步将提交迁移过去（排除理论内容），然后删掉旧分支，将新分支重命名。

核心特征：概念上是"渐进式替换"，但最终效果和方案 A 完全相同。

---

方案 C：过滤克隆（推荐）

当前仓库 ──[git clone --mirror]──→ 本地副本 ──[git-filter-repo]──→ 新 GitHub 仓库
                                                                      ↓
    当前仓库改名为 exomind-legacy (保持私有)                      设为 public

操作：克隆当前仓库到本地副本，在副本上执行 git-filter-repo，推到一个全新的 GitHub 仓库。原仓库保留为私有存档。

核心特征：新 URL（但可以沿用 exomind-team/exomind 如果先改名原仓库）、哈希全变、GitHub 上零残留。

---

方案 D：全新起点（用户路线3 的极简变体）

当前代码状态 ──[手动清理理论文件]──→ git init → 1 个初始提交 → 新 GitHub 仓库

操作：在当前代码上移除所有理论文件，然后以干净的代码状态作为单一初始提交推到新仓库。

核心特征：最简单、最安全，但完全丢失历史。

---

方案 E：双仓库持续同步（用户路线3 的增强版）

私有仓库 (exomind-private)  ──[CI 自动 filter-repo]──→  公开仓库 (exomind)
        ↑ 日常开发在此                                       ↑ 外部用户看到的
        │                                                    │
        └────── 每次 push 触发同步 pipeline ─────────────────┘

操作：私有仓库作为主开发位置，CI pipeline 在每次 push 时自动执行 filter-repo，将清洗后的代码同步到公开仓库。

核心特征：持续性方案（不是一次性操作）、最大隔离度、最高维护成本。

---

方案 F：浅克隆截断

当前仓库 ──[git clone --depth=N]──→ 浅克隆 ──[清理理论文件]──→ 新 GitHub 仓库

操作：只克隆最近 N 个提交（如最近 100 个），在此基础上清理理论内容，推到新仓库。

核心特征：保留近期历史、丢弃早期历史、不需要重写（因为根本没拉取旧历史）。

[ARCJ137442]

三、方案 A 与方案 B 的等价性证明

关键论断：方案 B 是方案 A 的手动实现，二者在技术结果上完全等价。

思考链条：

前提1: 方案 B 最终要 force push 到 GitHub（替换掉旧分支）
前提2: force push 后，GitHub 上旧分支的提交变成 dangling（和方案 A 一样）
前提3: 无论用 cherry-pick 还是 filter-repo，都会生成新的提交哈希
─────────────────────────────────────
结论: 方案 A 和方案 B 对 GitHub 来说是同一个操作——
      旧的 commit 对象变成 dangling，新的 commit 对象替换上去。
      唯一区别是生成新 commit 的工具/流程不同。

方案 B 的额外劣势：

差异点	方案 A (filter-repo)	方案 B (cherry-pick)
处理 883 个提交	自动化，几分钟	手动/半自动，数小时
合并提交处理	自动保留拓扑	需要 cherry-pick -m 1，易出错
提交消息清洗	回调函数批量处理	每个提交手动编辑
空提交处理	自动 --prune-empty	手动跳过

结论：方案 B 没有任何独立于方案 A 的优势。如果选择"原仓库+完整历史"，应该直接用方案 A，不需要方案 B。

以下分析中将方案 B 合并到方案 A 讨论。

---

四、多维度对比矩阵

评估维度定义

维度	权重	定义	为什么重要
D1 安全性	⭐⭐⭐⭐⭐	理论内容是否有可能被逆向发现	核心需求——学术机密不泄露
D2 历史保留	⭐⭐⭐⭐	保留多少有价值的提交历史	明确要求"尽量保留历史"
D3 执行复杂度	⭐⭐⭐	一次性执行的难度和风险	影响出错概率
D4 维护成本	⭐⭐⭐⭐	长期运营的额外开销	"公开仓库主导"，不想双重负担
D5 社区友好度	⭐⭐⭐	外部贡献者的体验	公开的目的之一是让社区参与
D6 可逆性	⭐⭐	出错时能否回退	安全网
D7 URL/品牌	⭐⭐	是否保留 exomind-team/exomind URL	品牌连续性
D8 GitHub 生态	⭐⭐	对 Releases(30)、Tags(144)、Issues(172) 的影响	已有生态资产

评分矩阵（5分制，5=最优）

维度	A 原地清洗	C 过滤克隆	D 全新起点	E 双仓库同步	F 浅克隆截断
D1 安全性	3	5	5	5	4
D2 历史保留	5	5	1	5	3
D3 执行复杂度	3	4	5	2	4
D4 维护成本	5	5	5	1	5
D5 社区友好度	4	4	3	3	3
D6 可逆性	2	5	5	5	4
D7 URL/品牌	5	4*	4*	3	4*
D8 GitHub 生态	3	2	1	4	2

* 方案 C/D/F 可以通过先改名原仓库再用原名创建新仓库来保留 URL

[ARCJ137442]

五、评分详细依据

D1 安全性——为什么方案 A 只有 3 分？

思考链:
1. GitHub 在 force push 后，旧 commit 对象变成 dangling
2. 但 dangling 对象不会立即删除——GitHub 的 GC 时间表不公开
3. 知道旧 commit SHA 的人仍可通过 github.com/org/repo/commit/<sha> 访问
4. 虽然当前仓库是私有的（forks=0），但：
   - 有 172 个 Issue，Issue 评论中可能引用了包含理论内容的提交 SHA
   - 仓库一旦公开，所有 dangling 对象理论上可被枚举
   - 即使联系 GitHub 支持团队做 GC，也无法保证 100% 清除
5. 结论：有残留风险，安全性评 3 分

D1 安全性——为什么方案 C 是 5 分？

思考链:
1. 新仓库从零创建，GitHub 上只有过滤后的 commit 对象
2. 不存在 dangling 对象（因为从来没有推送过旧对象）
3. 旧仓库保持私有，互不关联
4. 结论：零残留风险，安全性评 5 分

D2 历史保留——方案 A 和 C 都是 5 分？

思考链:
1. 两者都使用 git-filter-repo，保留相同的历史结构
2. 唯一区别：A 在原仓库操作，C 在副本操作
3. filter-repo 的输出是确定性的——给定相同输入和规则，输出相同
4. 所以历史保留程度完全一致，都是 5 分

D4 维护成本——方案 E 只有 1 分？

思考链:
1. 需要维护 CI 同步 pipeline
2. 每次 push 触发 filter-repo（~64MB 仓库）
3. 私有仓库的新理论代码如果引用了公开代码的模块，需要处理依赖
4. 公开仓库的社区 PR 需要同步回私有仓库
5. 两个仓库的 Issue 需要交叉引用
6. 版本号和 Tag 需要双向同步
7. 长期来看，复杂度会持续累积
8. 但核心需求是"公开仓库主导"——如果主导在公开仓库，为什么还需要私有仓库？
9. 结论：与核心需求矛盾，维护成本极高

D7 URL/品牌——方案 C 为什么是 4 而不是 5？

思考链:
1. 方案 C 默认创建新仓库，URL 会变
2. 但可以通过操作保留 URL：
   a. 将 exomind-team/exomind 改名为 exomind-team/exomind-legacy
   b. 创建新仓库 exomind-team/exomind
   c. 推送过滤后的历史到新仓库
3. GitHub 会自动将旧 URL 重定向到新名字
4. 外部链接（如果有）会指向改名后的私有仓库（404）
5. 但由于仓库当前是私有的（stars=0, forks=0），外部链接不存在
6. 结论：可以保留 URL，但需要额外步骤，评 4 分

---

六、决策树

                        ┌──────────────────────┐
                        │  需要保留提交历史吗？  │
                        └──────────┬───────────┘
                          ┌───────┴───────┐
                         是              否
                          │               │
                          ▼               ▼
                   ┌──────────┐    ┌────────────┐
                   │完整还是部分│    │ 方案 D      │
                   │ 保留？    │    │ 全新起点    │
                   └─────┬────┘    │ 最简单最安全 │
                    ┌────┴───┐    │ 但丢失全部   │
                   完整    部分   │ 历史          │
                    │        │    └────────────┘
                    ▼        ▼
             ┌──────────┐ ┌──────────┐
             │在原仓库还是│ │ 方案 F    │
             │新仓库？   │ │ 浅克隆截断│
             └─────┬────┘ │ 折中方案  │
               ┌───┴──┐   └──────────┘
              原仓库  新仓库
               │       │
               ▼       ▼
         ┌──────────┐ ┌──────────────┐
         │方案 A/B   │ │需要持续同步吗？│
         │原地清洗   │ └──────┬───────┘
         │=方案 B    │   ┌────┴───┐
         └──────────┘  是       否
                        │        │
                        ▼        ▼
                  ┌──────────┐ ┌──────────┐
                  │ 方案 E    │ │ 方案 C    │
                  │ 双仓库同步│ │ 过滤克隆  │
                  └──────────┘ └──────────┘

将约束代入决策树：

约束条件:
  ✓ 需要保留历史 → 排除方案 D
  ✓ 尽量保留完整历史 → 排除方案 F
  ✓ 公开仓库主导（无持续同步需求）→ 排除方案 E
  → 剩余候选: 方案 A 和 方案 C
  
最终决策点: 原仓库 vs 新仓库？
  → 这取决于对安全性的要求程度

[ARCJ137442]

七、方案 A vs 方案 C 的深层对决

决策树将选择缩窄到 A 和 C。以下是它们的逐条分析：

7.1 安全性分析

方案 A 的风险链：

force push → GitHub 上旧 commit 变成 dangling
  → dangling 对象在 GC 前可通过 SHA 访问
    → 风险1: Issue 评论中引用了旧提交 SHA
      → 仓库公开后，有人访问这些 SHA → 看到理论内容
    → 风险2: GitHub API 允许枚举 dangling objects
      → 安全研究者可能扫描公开仓库的 dangling objects
    → 风险3: 即使联系 GitHub GC，也无法保证完全清除
      → GitHub 的 CDN 缓存、搜索引擎索引等

方案 A 的风险缓解：

缓解1: 仓库当前是私有的，forks=0 → 没有 fork 中的残留
缓解2: 公开前可以联系 GitHub 做 GC → 降低风险
缓解3: 理论内容的 "机密等级" 是学术论文级别，不是军事机密
  → 即使有少量残留被发现，后果有限
缓解4: 论文发布后网络技术方面可以公开
  → 时间会逐步降低机密等级

方案 C 为什么无此风险：

新仓库 = 全新的 Git 对象数据库
  → 从未包含过理论相关的 commit 对象
    → 无 dangling、无缓存、无枚举风险
      → 安全性 = 100%

7.2 URL 保留分析

方案 A 天然保留 URL。方案 C 也可以保留——操作步骤：

1. gh repo rename exomind-team/exomind exomind-team/exomind-legacy
   → 原 URL github.com/exomind-team/exomind 自动 301 重定向到 exomind-legacy
2. 创建新仓库 exomind-team/exomind
3. 推送过滤后的历史
4. 取消重定向（GitHub 在新仓库创建后自动取消）

结果: 新仓库获得 exomind-team/exomind 的 URL
     旧仓库在 exomind-team/exomind-legacy（私有）

但有一个代价：原仓库的 172 个 Issue 和 30 个 Release 会跟着旧名走。

7.3 GitHub 生态影响

资产	方案 A	方案 C
172 Issues	保留（但引用的 SHA 失效）	留在旧仓库
30 Releases	保留（但关联的 commit 失效）	留在旧仓库
144 Tags	重写后保留（新 SHA）	重写后保留
CI/CD workflows	保留	需要重新配置 Secrets
Branch protection	保留	需要重新配置

Issue/PR 可以抛弃 → 方案 C 的生态损失被约束消除。

7.4 可逆性

场景	方案 A	方案 C
过滤规则写错，遗漏了文件	需要重新从备份恢复	重新从原仓库 re-clone 重做
清洗后发现理论代码与业务代码有编译依赖	需要手动修复并再次 force push	在副本上修复后重推新仓库
公开后发现还有残留	紧急私有化 + 联系 GitHub	无此场景

方案 C 的关键优势：原仓库完好无损，可以无限次重试。

---

八、最终加权评分

权重: D1=5, D2=4, D3=3, D4=4, D5=3, D6=2, D7=2, D8=2
总权重: 25

方案 A: (3×5)+(5×4)+(3×3)+(5×4)+(4×3)+(2×2)+(5×2)+(3×2) = 15+20+9+20+12+4+10+6 = 96
方案 C: (5×5)+(5×4)+(4×3)+(5×4)+(4×3)+(5×2)+(4×2)+(2×2) = 25+20+12+20+12+10+8+4 = 111
方案 D: (5×5)+(1×4)+(5×3)+(5×4)+(3×3)+(5×2)+(4×2)+(1×2) = 25+4+15+20+9+10+8+2  = 93
方案 E: (5×5)+(5×4)+(2×3)+(1×4)+(3×3)+(5×2)+(3×2)+(4×2) = 25+20+6+4+9+10+6+8   = 88
方案 F: (4×5)+(3×4)+(4×3)+(5×4)+(3×3)+(4×2)+(4×2)+(2×2) = 20+12+12+20+9+8+8+4  = 93

排名	方案	加权总分	关键优势
🥇	C 过滤克隆	111	安全性+可逆性最优
🥈	A 原地清洗	96	URL 保留天然
🥉	D 全新起点	93	最简单
4	F 浅克隆截断	93	折中
5	E 双仓库同步	88	维护成本拖后腿

---

九、决策结论与思考链总结

决策思考链:

1. 核心需求是 "公开" → 所有方案都能满足
2. 约束 "保留历史" → 排除 D(全新起点) 和 F(浅克隆)
3. 约束 "公开仓库主导" → 排除 E(双仓库同步)
4. 剩余 A vs C → 唯一差异点是 "安全性 vs URL便利"
5. 安全性是否是决定性因素？
   → 理论是"学术机密"级别——被发现的后果是什么？
   → 如果后果是 "论文被抢先发表" → 安全性关键 → 选 C
   → 如果后果是 "只是不想公开" → 安全性次要 → A 也可以
6. 方案 C 在 URL 上的劣势可以通过 repo rename 消除
7. 方案 C 的可逆性显著优于 A（原仓库作为安全网）
8. Issue/PR 可以抛弃 → 消除了 C 的最大生态损失

最终结论: 方案 C 在当前约束组合下是帕累托最优解——
         没有任何其他方案在所有维度上都不差于 C。

可提取的决策经验

1. "在哪操作"比"用什么工具"更重要 —— filter-repo 是确定的工具选择，但在原仓库 vs 新仓库上操作才是战略分歧点
2. "可以抛弃"是强力简化器 —— 一旦接受 Issue/PR 丢失，大量方案的劣势都被消除
3. 新仓库方案有"无限重试"优势 —— 原仓库方案一旦 force push，回退成本很高
4. GitHub dangling commits 是隐性风险 —— 大多数人忽视了 force push 后旧对象仍可访问这一事实
5. 方案等价性需要证明 —— 方案 B 表面上不同于方案 A，但技术上完全等价，识别等价性避免了不必要的决策成本

[ARCJ137442]

附录 A：需要隔离的完整文件清单

A.1 纯理论文档（必须从公开仓库移除）

文件	内容摘要
docs/plans/archive/AUTONOMOUS_LIFE_SPEC.md	自主生命体完整规格（能量模型、信号池、Actor架构）
docs/plans/2026-03-07-personal-growth-to-civilization-roadmap.md	个人→集体→文明三层递进路线图
docs/plans/product-plan.md	含认知生命理论的产品规划（五核心理念、四Agent职责）
docs/plans/2026-03-08-life-demo-energy-tick.md	能量系统+Tick调度器演示计划
docs/architecture/ARCH-signal-pool-agent-process.md	含生命判据对齐的信号池架构设计
docs/specs/.archive/SPEC-004_ENERGY_POOL.md	能量池模块规格书
docs/memory/logs.md	含论文进度、理论讨论的执行日志
docs/memory/project-overview.md	含理论定位的项目概览记忆

A.2 需要编辑脱敏的文档（保留文件，移除理论部分）

文件	需要修改的内容
CLAUDE.md	移除"项目概述"中的生命判据表、核心理念表、双层原则命名规范
docs/architecture/overview.md	移除 §1.2 生命判据(C1-C6)、§1.3 设计哲学（信号vs API、Agent vs Service 的理论论证）
docs/AI-CONTEXT.md	移除生命判据引用、"认知生命科学原型"定位
docs/product/roadmap.md	整体重写（当前全文都是理论：生命科学判据7条、能量与代谢、四Agent架构）
docs/product/PRD.md	移除四Agent系统的理论框架、L0-L5信任度阶梯
README.md	检查并移除"认知生命科学"相关引用
AGENTS.md	检查 Agent 系统说明中的理论引用

A.3 必须移除的代码文件

文件	内容	理由
crates/exomind-runtime/src/agent/life.rs	CognitiveLifeAgent 完整实现（DEFAULT_SOUL、策略选择、知识操作）	理论与代码不可分
crates/exomind-runtime/src/agent/cognition.rs	CognitionContext/CognitionEngine trait 定义	认知上下文即理论映射
crates/exomind-runtime/src/agent/llm_cognition.rs	LLM 认知引擎（策略选择算法、日记生成）	理论驱动的策略选择
crates/exomind-runtime/src/agent/heartbeat.rs	HeartbeatAgent（心跳→能量消耗→降频→dormant）	含生命阶段情感表达
crates/exomind-runtime/src/energy.rs	AgentEnergy/EnergyPool（5阶段生命周期）	能量前提论的工程映射
crates/exomind-runtime/src/routes/energy.rs	能量 HTTP API 路由	依赖 energy.rs
crates/exomind-runtime/src/tick.rs	TickManager（agent 自主心跳循环）	"过程性存在"的工程映射

A.4 需要审查的测试/UI 文件

文件	内容
tests/unit/ui/agent-hub/agent-energy-bar.issue444.test.tsx	能量条 UI 测试
tests/unit/ui/agent-hub/agents-page.energy.test.tsx	能量页面测试
Agent Hub 相关 UI 组件（能量可视化、生命周期展示）	需逐文件审查

---

附录 B：Git 提交历史关键数据

指标	数值
总提交数（所有分支）	1,564
dev 分支提交数	883
分支总数	87
Tags 数量	144
Releases 数量	30
仓库大小	64MB
创建日期	2026-02-03
Forks	0
Stars	0
可见性	private

提交者身份分布

提交者	邮箱	提交数
HailayLin	hailay@qq.com	1055 (67.4%)
ARCJ137442	ARCJ137442@github.com	236 (15.1%)
Argon@Termux	Argon@github.com	199 (12.7%)
Argon	(同上)	46
星林	hailay@qq.com	29

隐私评估：全部为化名，无真实姓名泄露。已有主动 PII 清理提交 ff5a1c6。

理论相关提交

约 15 条提交消息直接含"认知""生命""cognitive""energy"等关键词（排除 lifecycle 泛指），代表性提交：

• bed35a3: docs(architecture): v3.1 — 引入认知生命科学理论基础 + 马克思主义政治经济学视角
• ef73277: feat(agent): CognitiveLifeAgent + tick 集成
• 42f9e83: feat(life): add energy system, tick scheduler, and heartbeat agent demo
• ea9eb97: fix(ui): 认知生命体右侧面板 UI 优化

---

附录 C：git-filter-repo 工具方案（推荐工具）

对比 5 个历史重写工具后，git-filter-repo 是唯一合理选择：

工具	速度	文件移除	消息修改	合并提交	推荐度
git-filter-repo	极快	精确	callback	自动	⭐⭐⭐⭐⭐
git filter-branch	极慢	精确	msg-filter	部分	已废弃
BFG Repo-Cleaner	快	粗粒度	不支持	自动	场景适用
cherry-pick	手动	手动	手动	困难	小仓库
rebase --onto	一般	exec	exec	差	不推荐

filter-repo 关键能力：--message-callback（清洗消息）、--blob-callback（清洗文件内容）、--commit-callback（修改作者）、--invert-paths（按路径移除文件）、--prune-empty（移除空提交）。

[ARCJ137442]

迁移方案文档已创建

文件位置：docs/internal/REPO-OPEN-SOURCE-MIGRATION.md

注意：此文件位于 docs/internal/ 目录下，该目录已列入 paths-to-remove.txt，不会出现在公开仓库中。

文档结构

章节	内容
§0 决策摘要	方案选择理由与关键约束
§1 前置条件	工具安装、环境确认
§2 迁移步骤	4 个 Phase 的完整操作指南
§3 日常工作流	迁移后的开发模式
§4 风险与回退	风险矩阵 + 回退策略
§5 检查清单	逐项验收清单

4 个 Phase 概览

Phase	内容	估计时间
Phase 0: 准备	创建 3 个配置文件（路径排除、消息替换、作者映射）+ 备份	30 分钟
Phase 1: 过滤执行	mirror clone → filter-repo → 手动编辑脱敏文档 → 修复编译依赖	1 小时
Phase 2: 验证	全历史关键词搜索 + 编译验证 + 人工抽查	30 分钟
Phase 3: 发布	原仓库改名 → 新仓库创建推送 → 配置 → 公开	30 分钟
Phase 4: 理论归档	创建 exomind-theory 私有仓库 + 提取理论文件	30 分钟

配置文件预定义

文档中包含了 3 个配置文件的完整内容：

1. paths-to-remove.txt：列出所有需要从历史中彻底移除的文件路径（理论文档 + 理论代码 + 内部文档）
2. message-replacements.py：提交消息中理论术语的替换映射（13 组替换规则）
3. author-mailmap.txt：作者身份映射模板

下一步

1. 审阅迁移文档，确认过滤规则和编辑清单完整
2. 确定执行时间窗口
3. 按 Phase 0-4 顺序执行

[ARCJ137442]

补链：为配合代码库公开后的产品表面收敛，设置页 UserCard 中当前仅展示“即将推出”的“激活”按钮已单独追踪为 #621，目标是移除这一无稳定语义的占位入口。

[ARCJ137442]

决策更新：公开仓库命名为 exomind-app

变更内容

项目	原方案	更新后
公开仓库名	exomind-team/exomind（需先改名原仓库）	exomind-team/exomind-app
原仓库处理	改名为 exomind-legacy	保持不动，不改名
URL	保留原 URL	接受 URL 变化

简化效果

这一决策简化了 Phase 3：

• Phase 3.1 重命名原仓库 → 删除，不需要
• 原仓库 exomind-team/exomind 继续作为私有存档，不做任何变动
• 新公开仓库直接创建为 exomind-team/exomind-app

最终三仓库格局

exomind-team/exomind       (私有, 存档)  ← 原仓库，完好保留
exomind-team/exomind-app   (公开, 主战场) ← 过滤后的干净代码
exomind-team/exomind-theory(私有, 低频)  ← 认知生命理论代码和文档

迁移文档 docs/internal/REPO-OPEN-SOURCE-MIGRATION.md 已同步更新。

[ARCJ137442]

补链：设置页中所有指向 GitHub 仓库的入口（如“帮助中心 / 反馈建议 / 报告问题”）在公开/拆仓后也需要同步切到新的仓库路径。该问题已拆出独立 issue #627，并按阻塞关系记录为被 #613 阻塞。