Flude 团队复盘了多仓库架构的实践代价。项目从第一分钟起就选择拆分成独立仓库，Pipeline、engine、design-docs、user-docs 几乎同时创建，.gitmodules 出现在父仓库的首次提交里。为了代码整洁、CI 隔离、独立历史和权限分离，系统从第一天就建立在 Git Submodules 之上。
第一个代价是状态同步的隐蔽机制。在 engine/ 里改代码，需要两次 push：先在子模块目录 push，再回到 Pipeline 根目录提交指向新 commit 的 gitlink 并 push。第一次 push 极易被遗忘——本地 commit 真实存在，构建通过、测试全绿，直到 CI 全新 checkout 时才暴露：git submodule update --init 报错 fatal: remote error: upload-pack: not our ref。曾有三个子模块同时踩坑，原因一致：本地提交从未离开开发者的笔记本。第四个托管站点的子模块 ude_promotion 落后上游太多，普通 push 无法修复，必须先做交互式 rebase。
第二个代价来自 CI。engine 既是独立仓库、有自己的构建流程，又是 Pipeline 里的子模块、要在父项目上下文中测试，两种身份必然冲突。先是 test_integration_scripts.py 依赖只存在于父仓库的 verify_pages/check_links 模块，独立 checkout 时文件不在磁盘上，只能在 ci.yml 里加一行 pytest --ignore 临时忽略。随后用 Path(file).resolve().parents[2] 找父级产物的测试开始失败：嵌套运行时正好升到父仓库根目录，独立构建时却跳出仓库根、进入 CI runner 的系统文件系统，直接抛 AssertionError。
点状修补失效后，团队引入通用约定：测试在上升层级检查系统标记目录（.workspace_config）是否存在。存在说明处于嵌套上下文，测试照常运行；不存在则用 pytest.mark.skipif 安静跳过，不再报红。
结论是多仓库架构不会在第一天白送松耦合，它要求无懈可击的 push 同步纪律，并迫使代码同时适配多种执行上下文。