【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载导读Phase Dependency Analysis是 GSD CoreGit. Ship. Donev1.32 引入的一项规划期功能由/gsd-manager --analyze-deps命令触发。它会在执行/gsd-manager之前对.planning/ROADMAP.md中的各阶段Phase进行依赖关系分析——检测阶段之间的文件重叠、语义依赖API/Schema 的生产者与消费者和数据流依赖输出生产者与读取者并为 ROADMAP.md 中缺失的Depends on字段给出建议。读完本文你将掌握该功能的完整执行流程、三类依赖检测的判断规则、ROADMAP.md 的写入规范以及依赖信息在 GSD Core 执行编排wave 分组、halt 传播、quick-batch中的底层消费方式。一、功能定位为什么要在执行前先做依赖分析GSD Core 的/gsd-manager是一个单终端命令中心用于在同一个终端里管理一个里程碑内的多个阶段显示所有阶段的仪表盘、推荐下一步动作并支持一个阶段在后台讨论/规划/执行的同时并行推进其他阶段见 commands/gsd/manager.md 的objective块。这种并行执行模型带来一个经典问题如果两个阶段会修改同一批文件或者一个阶段消费另一个阶段才产出 API/Schema/数据并行执行就会产生合并冲突或运行时失败。Phase Dependency Analysis正是为此而生——它的官方定位是Detect phase dependencies and suggestDepends onentries for ROADMAP.md before running/gsd-manager.即在/gsd-manager真正调度阶段之前先把阶段间的依赖关系显式化写进 ROADMAP.md 的Depends on字段从而让执行编排先跑依赖提供方、后跑依赖消费方从源头规避并行冲突。从仓库结构看本功能是分析建议analyze-dependencies workflow与消费执行plan 的depends_on编排两段式设计前者是规划期的人工/LLM 辅助分析后者是执行期的确定性依赖图计算见 src/plan-dependency-graph.cts。本文后续章节会分别展开。二、命令入口与调用链2.1 命令形态/gsd-manager --analyze-deps--analyze-deps是/gsd-manager的可选参数argument-hint: [--analyze-deps]不带任何额外参数值。它不要求用户先进入 manager 仪表盘而是作为 manager 的前置分析模式存在分析完成后会引导用户运行/gsd-manager按正确的顺序执行阶段。2.2 底层调用链命令的调度逻辑定义在两个文件中内容一致命令文件 commands/gsd/manager.md 的process块If --analyze-deps is in the arguments block: Read and execute ~/.claude/gsd-core/workflows/analyze-dependencies.md end-to-end.技能文件 skills/gsd-manager/SKILL.md 的process块同样的规则。也就是说--analyze-deps触发后manager 会端到端执行gsd-core/workflows/analyze-dependencies.md 这个工作流而不是进入常规的 dashboard 刷新循环。分析流程结束后才按需进入/gsd-manager的常规执行。2.3 前置条件执行分析前需要满足项目已初始化必须存在.planning/ROADMAP.md。工作流第一步明确规定若该文件不存在则报错No ROADMAP.md found — run/gsd:new-projectfirst.处于一个有效的里程碑中与/gsd-manager的前置条件一致需要 ROADMAP.md 与 STATE.md。三、需求契约REQ-DEP 系列本功能在 docs/FEATURES.md 的 Feature 77 条目中定义了四条硬性需求是任何实现都必须满足的验收契约编号需求内容对应工作流步骤REQ-DEP-01系统必须检测阶段之间的文件重叠第 3 步 File Overlap DetectionREQ-DEP-02系统必须检测语义依赖API/Schema 的生产者与消费者第 3 步 Semantic Dependency DetectionREQ-DEP-03系统必须检测数据流依赖输出生产者与读取者第 3 步 Data Flow DetectionREQ-DEP-04系统必须在用户确认后才写入依赖建议第 6 步 Confirm and Apply产物Produces依赖建议表Dependency suggestion table可选地更新 ROADMAP.md 的Depends on字段。值得注意的是 REQ-DEP-04 的用户确认约束分析引擎永远不直接改 ROADMAP.md而是先展示建议表再通过yes / no / edit三态确认后才落盘——这一点与 GSD Core 一贯的AI 建议、人工确认哲学一致。四、完整执行流程六个步骤完整流程定义在 gsd-core/workflows/analyze-dependencies.md 的process块中共六个步骤。步骤 1加载 ROADMAP.md读取.planning/ROADMAP.md提取所有阶段并为每个阶段捕获阶段编号与名称Phase number and name范围/目标描述Scope/Goal descriptionFiles或files_modified字段中列出的文件若存在现有的Depends on字段值从 ROADMAP.md 模板gsd-core/templates/roadmap.md可以看到每个阶段的### Phase Details区块结构### Phase 1: [Name] **Goal**: [What this phase delivers] **Depends on**: Nothing (first phase) **Requirements**: [REQ-01, REQ-02, REQ-03] **Success Criteria** (what must be TRUE): 1. [Observable behavior from user perspective] **Plans**: [Number of plans]其中**Depends on**:就是本功能要建议/更新的字段。模板中首个阶段标注Nothing (first phase)后续阶段按链式依赖标注Phase 2 → Phase 1Phase 3 → Phase 2……。步骤 2推断可能修改的文件对于没有显式files_modified字段的阶段工作流要求依据范围/目标描述推断其可能修改的文件并使用以下启发式规则阶段类型推断的文件域数据库/Schema 阶段迁移文件、Schema 定义、模型文件API/后端阶段路由文件、控制器文件、服务文件、处理器文件前端/UI 阶段组件文件、页面文件、样式文件认证阶段中间件文件、认证路由文件、会话/令牌文件配置/基础设施阶段配置文件、环境文件、CI/CD 文件测试阶段测试文件、spec 文件、fixture 文件共享工具阶段lib/utils 文件、共享类型定义推断完成后按文件域database、API、frontend、auth、config、shared对阶段分组。这一分组是下一步文件重叠检测的基础。步骤 3检测依赖关系对每一对阶段 (A, B) 检查三类依赖信号1文件重叠检测File Overlap Detection如果阶段 A 和 B 都会修改同一文件域或同一批具体文件那么其中一个必须先于另一个执行。提供基础foundation的阶段先跑。2语义依赖检测Semantic Dependency Detection阅读每个阶段的 scope/goal匹配以下模式阶段 B 提到消费、使用或调用阶段 A 创建/实现的内容阶段 B 引用了阶段 A 构建的 API、schema、model、endpoint 或 interface阶段 B 表述为 after X is complete、once X is built、using the X from Phase N阶段 B 扩展或修改阶段 A 建立的代码3数据流检测Data Flow Detection阶段 A 创建数据结构/Schema/类型 → 阶段 B 消费或转换它们阶段 A 填充/迁移数据库 → 阶段 B 从该数据库读取阶段 A 暴露 API 契约 → 阶段 B 为该契约实现客户端三类信号对应 REQ-DEP-01/02/03共同构成为什么这两个阶段有依赖的理由该理由会写入建议表的reason字段。步骤 4构建依赖建议表输出如下格式的依赖建议表Phase Dependency Analysis Phase N: name Scope: brief scope Likely touches: inferred file domains Suggested dependencies: → Depends on: Phase M — reason: overlap/semantic/data-flow explanation Current Depends on: existing value or (none)对于未检测到依赖的阶段对必须显式声明No dependency detected between Phase X and Phase Y.——这一明确的无依赖结论同样重要它让用户知道该阶段可以安全并行。步骤 5汇总建议变更展示一个合并后的 ROADMAP.mdDepends on变更 diffSuggested ROADMAP.md updates: Phase 3: add Depends on: 1, 2 (file overlap: database schema) Phase 5: add Depends on: 3 (semantic: uses auth API from Phase 3) Phase 4: no change needed (independent scope)这个汇总视图让用户一眼看清全部待改项再决定是否应用。步骤 6确认并应用用户三态决策向用户提问Apply theseDepends onsuggestions to ROADMAP.md? (yes / no / edit)三种回答的处理方式对应 REQ-DEP-04回答行为yes将所有建议的Depends on条目写入 ROADMAP.md且每处写入都要确认no仅以文本形式打印建议用户手动更新edit逐条展示建议每条用 yes/no/skip 单独决策写入 ROADMAP.md 时必须遵守三条纪律定位阶段条目添加或更新Depends on:字段保留该阶段的其他所有内容不变不得重排阶段顺序应用完成后提示ROADMAP.md updated. Run/gsd:managerto execute phases in the correct order.五、依赖信息的下游消费从Depends on到执行编排分析功能写入 ROADMAP.md 的Depends on只是第一步。GSD Core 在执行期还有一套确定性的依赖图消费机制二者配合才能实现按依赖顺序执行。5.1 PLAN 级别的depends_on前端字段规划阶段/gsd-plan-phase生成的*-PLAN.md文件在 YAML frontmatter 中携带调度元数据其中就包括wave、depends_on和files_modified。从仓库的规范解析器 src/plan-document.cts编译产物为gsd-core/bin/lib/plan-document.cjs可以看出cmdPhasePlanIndex依赖parsePlanDocument解析这些字段用于执行期的波次分组。5.2 依赖 DAG 上的 halt 传播源码级佐证src/plan-document.cts 的同名模块 src/plan-dependency-graph.cts编译产物gsd-core/bin/lib/plan-dependency-graph.cjs是代码库中计划依赖图的唯一拓扑排序 halt 传播引擎对应内部 issue #2830。其头部注释揭示了设计动机代码库中原本存在两个独立的哪些计划未完成读取器phase.cts的 wave 分组cmdPhasePlanIndex和phase-locator.cts的阶段定位原语searchPhaseInDir被约 50 个符号、五个命令路由器消费在 #2830 之前只有前者解析depends_on且仅用于拓扑波次分配从不把一个halted设计性停止计划对依赖者的阻塞传播下去该模块将拓扑排序Kahn 算法单次遍历与 halt 传播统一收敛到一处两个读取器从此不可能再对哪个计划被阻塞产生分歧。该模块导出的关键函数包括computeHaltPropagation(nodes, precomputedOrder?)—— 在依赖 DAG 上计算 halt 传播返回{ order, visited, blockedBy }。blockedBy记录被哪些 halted 计划含传递依赖阻塞菱形依赖去重、传递依赖到任意深度isHaltedStatus/isSummaryFileHalted—— 判定 SUMMARY frontmatterstatus: halted设计性停止仍写完成记录isBlockedStatus/isSummaryFileBlocked—— 判定status: blocked失败记录不计入完成这是 #3345 引入的与 halted 互补的语义。这组源码揭示了依赖分析的闭环价值规划期把依赖写进depends_on/Depends on执行期才能据此做拓扑排序、wave 分组和 halt/block 传播——没有前者后者无从谈起。5.3 执行期的 wave 分组/gsd-execute-phase的 wave 执行模型见 docs/FEATURES.md Feature 5无依赖的计划 → Wave 1并行依赖 Wave 1 的计划 → Wave 2并行等待 Wave 1依此类推直到全部完成同一 wave 内的文件冲突强制改为串行执行这正是Depends on信息在快速执行路径上的消费形态。依赖分析越准确wave 分组越合理并行收益越大。5.4 quick-batch 的强制依赖声明在/gsd-quick-batch批量快速任务中依赖信息被提升为强制约束调度器要求每个条目必须携带depends_on/files_modifiedfrontmatter见 docs/FEATURES.md Feature 4015 的 REQ-QB-06并在每层规划后根据声明的依赖/文件重算执行波次REQ-QB-07。这说明依赖声明在整个 GSD 编排体系中是统一的调度输入。六、契约保障测试如何守护--analyze-deps行为该功能的命令契约由测试锁定。在 tests/skill-frontmatter-contract.test.cjs 中测试断言manager.md的 frontmatterargument-hint包含--analyze-deps测试断言manager.md正文引用了analyze-dependencies.md即--analyze-deps的 dispatch 存在同时记录了analyze-dependencies工作流被吸收进 manager.md 的 --analyze-deps这一演进对应 issue #3131。也就是说/gsd-manager --analyze-deps一定存在、且一定派发到分析工作流不是文档口头承诺而是被持续运行的契约测试守护的既定行为。另外阶段依赖分析依赖的 ROADMAP.md 结构Depends on字段也由 gsd-core/templates/roadmap.md 模板固化/gsd-new-project生成项目时即按此结构产出确保分析工作流总能找到可解析的字段。七、使用建议与适用前提在里程碑规划完成后、开始并行执行前运行/gsd-manager --analyze-deps的典型时机是 ROADMAP.md 已生成、但尚未大规模调度阶段之时。为每个阶段写好 Goal/Scope 描述分析质量高度依赖阶段描述——语义依赖与数据流检测都是基于 scope/goal 文本的模式匹配描述越具体推断越准确。能显式声明files_modified就显式声明这可以跳过推断环节让文件重叠检测直接基于事实而非启发式。善用edit模式逐条确认对于跨阶段共享文件较多、依赖关系复杂的项目逐条决策比全量接受yes更稳妥也比纯文本输出no更高效。依赖分析不等于强制串行检测不到的依赖会显式声明无依赖这些阶段可以放心并行——分析的目的是把必须串行的部分精确地找出来而不是把所有阶段都串起来。适用前提本功能需要 GSD Core 已安装且项目已完成初始化存在.planning/ROADMAP.md。命令经由/gsd-manager技能入口触发分析工作流在 gsd-core/workflows/analyze-dependencies.md命令契约在 commands/gsd/manager.md均可在当前仓库中直接查阅。参考功能说明docs/features/phase-dependency-analysis.mdFeature 77v1.32工作流实现gsd-core/workflows/analyze-dependencies.md命令入口commands/gsd/manager.md、skills/gsd-manager/SKILL.mdROADMAP 模板gsd-core/templates/roadmap.md依赖图引擎src/plan-dependency-graph.cts计划解析src/plan-document.cts契约测试tests/skill-frontmatter-contract.test.cjs特性索引docs/FEATURES.md赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐Kubernetes 命名推荐工作流从社区提案到 ADR 落地的完整实践指南Kubernetes 命名推荐工作流从社区提案到 ADR 落地的完整实践指南 导读 本文系统讲解 Kubernetes 社区中语言/术语推荐Naming RGSD Core 阶段学习萃取指南用 /gsd-extract-learnings 将完成阶段沉淀为 Decisions、Lessons、Patterns 与 SurprisesGSD Core 阶段学习萃取指南用 /gsd extract learnings 将完成阶段沉淀为 Decisions、Lessons、Patterns 与gsd-core Roadmapper 完全指南从需求到可执行阶段路线的 GSD 路线图构建方法gsd core Roadmapper 完全指南从需求到可执行阶段路线的 GSD 路线图构建方法 导读 gsd roadmapper 是 gsd core 中上一篇C开发者必备screen_capture_lite实战示例轻松实现屏幕录制下一篇tinker-manager API接口文档开发者必备参考手册创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考