* chore(#3618): fold fallow-runner onto the canonical binary resolver Epic #3411 Phase 2. src/fallow-runner.cts was the fourth divergent implementation of Windows binary resolution the epic enumerated — candidateNames, isExecutableFile, findInPath, findInNodeModules, 40 lines. All four are deleted; resolveFallowBinary is one seam call. Two OPT-IN options were added to resolveExecutableBinary to make the fold behavior-preserving, both defaulting off so Phase 1's callers are byte-identical: prependPaths dirs searched before env.PATH, in order, through the identical per-directory candidate logic. This expresses node_modules/.bin-first precedence without env surgery — the rejected alternative re-introduced the spread-loses-the-proxy hazard the Windows lane caught in Phase 1, at every future call site instead of once. requireExecutable POSIX-only accessSync(X_OK); a no-op on win32 where mode bits do not mean execute. Opt-in rather than default because unconditional X_OK breaks #3445's suite, which stages candidates with plain writeFileSync and never sets an exec bit — the repo bans chmod in tests — so every one would resolve to null on POSIX. Deliberate behavior change on Windows: fallow's prior candidate list ended in a BARE fallow. The seam never tries a bare name there, so an extensionless file beside fallow.cmd is no longer resolved. That is the fix, not a regression — the extensionless file is npm's POSIX sh shim, which CreateProcess cannot run (#3275). Rows 7 and 8 of the design record it. Defect found while working, fixed inline: the resolution order was documented BACKWARDS as PATH-then-.bin in structural-pre-pass.md, docs/INVENTORY.md and four INVENTORY translations. The code has always been .bin first, and .bin first is correct — a project-local tool should beat a global one. The archived changeset is left alone as a historical record. fallow-runner had no test file at all. tests/fallow-runner.test.cjs is new (F1-F15) and the seam options are pinned by S1-S12 folded into the existing dispatch suite. RED proven by execution: with both source files stashed and build:lib re-run, 7 of 27 probe cases failed. Refs #3411 * chore(#3618): backfill changeset pr number 3633 * fix(#3618): assert both platform contracts in F4 instead of a POSIX-only premise Windows CI on #3633 failed F4. The test monkeypatched accessSync to throw and asserted resolveFallowBinary returned null — but that premise, that the X_OK check is consulted at all, is POSIX-only by design. requireExecutable is a deliberate no-op on win32 because Windows mode bits do not mean execute, so the staged fixture correctly resolved there. 40-design.md's negative-space section already states this carve-out verbatim. The test contradicted the design it was written from: fixtures were made platform-adaptive in the previous commit, and this assertion was left platform-blind. F4 now asserts BOTH contracts — null on POSIX, resolves on win32 — rather than skipping either. A t.skip on one lane would have been green and would have left the win32 carve-out unpinned by fallow's own entry point. Audited every other row for the same class. F1-F3, F5, F6, F11-F15 hold on both platforms; F7-F10 and S1-S12 inject platform explicitly and are unaffected. F4 was the only row with a single-platform premise. The local probe runs on one platform and structurally cannot catch this, which is why it was green — that limitation is now stated at the top of the probe so a green probe is not mistaken for platform coverage. The win32 branch was proven by injecting platform:'win32' with accessSync throwing and asserting it still resolves. Refs #3411 --------- Co-authored-by: sim <sim@local>
GSD Core 文档
文档按四个象限组织:教程通过实践帮助你学习,操作指南解决具体任务,参考文档提供权威信息,概念说明探讨设计理念与决策。
语言版本:English · Português (pt-BR) · 日本語 · 简体中文
Tutorials
How-to guides
- 在你的运行时上安装 — 适用于全部 16 个受支持运行时的安装步骤
- 讨论一个阶段 — 在规划开始前记录实现决策
- 规划一个阶段 — 执行调研、分解工作并验证计划质量
- 执行一个阶段 — 使用全新上下文的子代理以并行波次运行计划
- 验证并交付 — 审查已完成的工作、诊断失败并创建 PR
- 自主运行阶段 — 使用自主模式进行无人值守的阶段执行
- 处理快速临时任务 — 使用
/gsd-quick和/gsd-fast处理阶段循环之外的临时工作 - 配置模型配置文件 — 在高质量、均衡和经济模型层级之间切换
- 设置跨 AI 审查 — 配置第二个 AI 对主代理生成的代码进行审查
- 使用工作流并行工作 — 使用工作流同时运行独立的工作线
- 使用工作空间隔离工作 — 使用工作空间对实验性或高风险变更进行沙箱隔离
- 调试失败的执行 — 诊断并从中断或不完整的阶段执行中恢复
- 探索与草图 — 在提交计划之前,使用
/gsd-spike和/gsd-sketch进行探索性工作 - 设计 UI 阶段 — 使用 UI 阶段循环处理前端和视觉工作
- 从追踪器 Issue 驱动 GSD — 从 GitHub、Linear 或 Jira issue 启动一个阶段
- 从 GSD 2 迁移 — 将现有的 GSD 2 项目升级到 GSD Core
- 更新 GSD — 重新运行安装程序以获取最新版本
- 恢复与故障排查 — 修复常见问题、重建上下文并卸载
Reference
- 命令 — 每个命令的标志和示例
- 配置 — 完整配置模式、模型配置文件、Git 分支策略
- CLI 工具 —
gsd-tools.cjs用于工作流和代理的编程式 API - 功能特性 — 完整功能索引
- 清单 — 已安装的技能与界面映射
- STATE.md 模式 —
.planning/STATE.md的逐字段参考 - CONTEXT.md 模式 —
.planning/phases/<N>/CONTEXT.md的逐字段参考 - PLAN.md 模式 —
.planning/phases/<N>/PLAN.md的逐字段参考 - 规划产物 — 所有
.planning/文件及其作用
Explanation
- 上下文工程 — 上下文腐化如何形成,以及 GSD Core 如何防止它
- 阶段循环 — 讨论 → 规划 → 执行 → 验证 → 交付循环的设计原理
- 多代理编排 — 子代理的生成、范围界定和协调方式
- 安全模型 — 信任边界、权限和安全自动化
- 架构 — 系统架构、代理模型和数据流
- 讨论模式 —
/gsd-discuss-phase的假设模式与访谈模式 - 上下文监控 — 上下文窗口监控钩子架构
- Issue 驱动编排 — 使用现有原语从追踪器 issue 驱动 GSD 的方案
Related
- 根目录 README — 首页、快速开始和文档概览
- 变更日志 — 发布历史