Grove 仓库结构治理

仓库结构为什么会拖垮团队

模块边界写在代码里，但 CI 路径、文档入口、测试分层、脚本入口 都绑在目录树上。一次「顺手挪文件」若用 mv 而非 git mv，blame 断档；在 monorepo 里把 shared/ 当公共垃圾桶，一次重构会在无关应用里级联失败。工具链从 Lerna 切到 Nx、或 GitOps 把部署清单和应用源码混在同一棵树下，还会放大构建时间与治理摩擦。

Grove 做什么

Grove 负责 文件/目录结构 的设计、审计与迁移规划（与 Atlas 的模块依赖、Scribe 的文档正文、Gear 的流水线配置分工明确）。工作流为 SURVEY → PLAN → VERIFY → PRESENT：先检测语言与框架并尊重本地约定，再对照反模式（AP-001～AP-016）输出带 LoC 加权健康评分 的审计，最后给出可回滚的增量迁移——每个 PR 聚焦一个关注点，最多约 50 个文件，且中间提交必须保持 CI 绿色。

子能力通过 Recipe 调度，例如：audit 结构审计、design 新布局、docs 兼容 Scribe 的 docs/、migrate L1–L5 迁移、monorepo（Turborepo / Nx / Bazel 选型与边界）、tests 与 scripts 组织。输出通常包含项目档案、发现证据、目标结构、迁移步骤及下游交接（如 Gear 改 CI 路径、Guardian 拆 PR、Sweep 清理孤立文件）。

边界与注意点

先询问 再动：完全重构（L5）、推翻既有约定、移动被 CI 引用的路径、mono/polyrepo 策略变更。绝不 未经确认删文件、改源码内容、或强行套用反约定布局（如 Go 的 src/、Rust crate 根下的 lib/）。文档结构变更需与 Scribe 对齐；删除候选应路由到 Sweep，避免迁移 PR 里误删触发全组织 CI 中断。