【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本篇技术笔记围绕 gsd-core 仓库中一份归档 changeset.changeset/archived/wise-hawks-bark.mdtype: FixedPR #582展开剖析一个在 Agent 编排系统中非常典型的缺陷spawn prompt 里要求只用 Edit 做局部修改但代理的tools:frontmatter 没有声明Edit导致运行时回退到整文件Write静默覆盖共享文件的兄弟章节。读完本文你将理解tools:frontmatter 作为可执行能力契约的地位、六个 writer 代理的修复内容、同类 bug 家族#571/#575/#581/#973的演化以及 gsd-core 在代码层Write Guard hook 与 agent 安装校验对这类事故的兜底机制。一、这次修复改了什么一张 changeset 与六个代理1.1 changeset 原文事实归档于.changeset/archived/wise-hawks-bark.md的变更记录陈述了以下事实影响对象六个 writer 代理——gsd-eval-planner、gsd-ai-researcher、gsd-domain-researcher、gsd-phase-researcher、gsd-ui-researcher、gsd-debug-session-manager。修复动作在它们的tools:frontmatter 中同时携带Edit与Write。动机这些代理的 spawn prompt 中声明了仅 Edit的写入纪律Edit-only discipline但此前 frontmatter 里没有Edit该纪律不可执行enforceable。后果没有Edit时代理回退到整文件Write会静默覆盖silently clobbered共享文件如AI-SPEC.md中其他代理已写好的兄弟章节。同源问题与 #571 属于同一 bug 类别其中gsd-doc-writer已在 #575 修复本 changeset 关联 issue #581。1.2 六个代理各自写什么从 agents/ 目录下的代理定义可以确认这六个代理都是各自阶段/流程中负责产出文档工件的 writer代理产出工件共享文件风险点gsd-domain-researcher.mdAI-SPEC.md的 Section 1bDomain Context与 ai-researcher、eval-planner 同写一个文件gsd-ai-researcher.mdAI-SPEC.md的 Section 3、4、4b同上gsd-eval-planner.mdAI-SPEC.md的 Section 5Evaluation Strategy、6Guardrails、7Production Monitoring同上gsd-phase-researcher.mdRESEARCH.md.planning/phases/XX-name/{phase_num}-RESEARCH.md与其他 research 阶段产物同处一个规划目录gsd-ui-researcher.mdUI-SPEC.md$PHASE_DIR/$PADDED_PHASE-UI-SPEC.md设计契约文档gsd-debug-session-manager.md调试会话文件.planning/debug/{slug}.md及其归档/提交会话状态与证据由多轮子代理共同追加其中AI-SPEC.md是最典型的多作者共享文件gsd-domain-researcher写 Section 1bgsd-ai-researcher写 Section 3–4bgsd-eval-planner写 Section 5–7。三者由ai-integration-phase编排器依次 spawn。任何一个代理若用整文件Write覆盖就会把前面代理写入的章节一并抹掉——这正是本次修复要消灭的静默破坏。1.3 修复后的 frontmatter 实态对照仓库现状六个代理的tools:frontmatter 均已包含Edit与Write与 compact 变体保持一致agents/gsd-eval-planner.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, AskUserQuestionagents/gsd-ai-researcher.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, WebFetch, WebSearch, mcp__context7__*, ...agents/gsd-domain-researcher.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, WebSearch, WebFetch, ...agents/gsd-phase-researcher.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, Skill, WebSearch, WebFetch, ...agents/gsd-ui-researcher.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, Skill, WebSearch, ...agents/gsd-debug-session-manager.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, Agent, AskUserQuestion各代理的 compact 变体如 agents/gsd-eval-planner.compact.md同步携带相同工具集安装时两者共同构成代理的完整定义。二、问题本质为什么没有 EditEdit-only 纪律就不可执行2.1 纪律声明在 prompt能力声明在 frontmatter以gsd-eval-planner为例其执行流里对写入方式有非常明确的纪律要求gsd-domain-researcher.md的 Write contract 写明ALWAYS use the Write tool to create files— never useBash(cat EOF)or heredoc commands同时这些代理面向共享文件AI-SPEC.md的更新动作语义上是**更新第 N 节**正确姿势应是先Read全文再用Edit精准替换目标章节而不是把整份文件重写一遍。问题在于prompt 里的指令只是建议frontmatter 里的tools:才是运行时真正授予的工具集。当代理的 spawn prompt 要求用 Edit 做局部更新但tools:里没有Edit时模型在运行时只会收到Write这一个写工具于是必然回退到整文件Write——而模型构建整文件 payload 时往往基于它对文件的部分读取尤其当文件很长、上下文预算有限时于是读了一个窗口、写回整份文件窗口之外的其他代理的章节就被静默覆盖。这就是 changeset 所描述的so the Edit-only discipline in their spawn prompts is enforceable的含义修复的本质不是改 prompt 文案而是给运行时补上执行该纪律所需的工具让纪律从文本约束变成可执行约束。2.2 共享文件的兄弟章节为何必然受害AI-SPEC.md的写作顺序在 gsd-ai-researcher.md 与 gsd-eval-planner.md 中可见domain-researcher 先写 Section 1bai-researcher 写 Section 3–4beval-planner 最后写 Section 5–7。每个代理的input都接收ai_spec_path指向同一个AI-SPEC.md。在这种多写者、单文件、分节协作的模型下任何一个代理在写入时读到的是磁盘上已含他人章节的完整文件若它用整文件Write回写payload 必须重建全文——任何遗漏都会成为兄弟章节静默丢失且这种丢失不报错、不告警编排器只检查目标节是否存在很难发现其他节被悄悄删掉。2.3 同类 bug 家族#571 → #575 → #581 → #582changeset 明确指出本修复与 #571 属同一 bug 类别gsd-doc-writer此前也因缺失Edit而回退整文件 Write于 #575 修复。本次 #582 将同样的修复推广到六个代理并关联 #581 作为跟踪。仓库中这类指令要求 Edit、能力未授予 Edit的缺陷不是孤例而是一类系统性问题——这也解释了为何 changeset 会专门标注 Same bug class as #571。更深层的历史教训记录在 hooks/gsd-write-guard.js 的头部注释中issue #973 记录了一个 planner 读取ROADMAP.md约 16 行窗口后用整文件Write覆盖了 292 行的完整文件三个里程碑的已提交历史被摧毁292 → 16 行约 94.5% 的内容坍缩。该事件直接催生了代码层的 Write Guard也印证了仅靠 prompt 指令无法阻止覆盖这一判断——#973 中代理甚至读到了 advisory 提示却将其判定为非绑定并继续执行。三、代码层的兜底gsd-write-guard.js 如何拦截灾难性 Writeprompt 修复给Edit工具降低了覆盖概率但 gsd-core 的工程哲学是由代码而非指令强制执行enforced by code rather than by instruction。为此仓库在 hooks/gsd-write-guard.js 实现了 PreToolUse 写守卫。3.1 守卫的触发条件与判定逻辑该 hook 刻意收窄触发面只拦截整文件 Write 灾难性收缩 curated.planning/工件只针对WriteEdit/MultiEdit天然不在范围内——源码注释写明 Edit/MultiEdit replace bounded spans and are out of scope by design即编辑类工具按构造就是有界的不会整文件覆盖只针对已存在的 curated 文件.planning/ROADMAP.md、.planning/STATE.md、.planning/milestones/*-ROADMAP.md以及 workstream 与 project 作用域下的对应变体CURATED_PATTERNS数组共 8 条正则见 gsd-write-guard.js阈值判定当 pending payload 行数低于磁盘文件行数的SHRINK_RATIO0.4即小于当前 40%时硬阻断exit 2, decision: block小于FLOOR_LINES40 行的 stub 文件豁免匹配前先 realpath 解析防止通过符号链接路径绕过 curated 匹配。其阻断信息会明确建议To fix: use Edit for a scoped change, or Read the full file and include every section in the Write——与本次 changeset 的修复方向完全一致能局部改就 Edit必须重写就先读全文。3.2 有界的保证与显式逃逸守卫的头部注释也诚实声明了其边界它阻止意外/单次坍缩但无法防御蓄意绕过a determined agent。为此提供了两条显式逃生通道环境变量GSD_ALLOW_PLANNING_SHRINK1供人类交互式运行一次性哨兵文件.planning/.gsd-allow-shrink供工作流步骤使用——哨兵 15 分钟 TTL、绑定唯一目标文件路径、命中即消费避免成为长期解锁。这两条通道都写进了阻断信息与被守卫的绑定测试中属于有文档的、路径绑定、单次、可审计的机制。3.3 对本 bug 类的防护意义不难看出Write Guard 与 #582 的修复形成双层防线工具层本次 changeset给六个 writer 代理授予Edit让局部更新共享文件成为运行时可能且自然的动作Hook 层#973 后建立即使某个代理仍因故发起整文件 Write只要目标是 curated 规划工件且坍缩超阈值就会被硬阻断。对于AI-SPEC.md这类非.planning/路径的共享文件Write Guard 不直接覆盖其 curated 匹配是封闭集合因此工具层修复对AI-SPEC.md的保护更为关键——这正是本次 changeset 的价值所在。四、tools: frontmatter 是权威契约安装与校验的源码佐证tools:frontmatter 不只是给模型看的提示它在 gsd-core 中是被程序读取的结构化契约。相关证据集中在 src/agent-install-check.ctsextractToolsValue来自 src/codex-agent-toml.cts由 install 发射器与校验器共享从 agent 文件解析tools:值支持行内与 YAML 块列表两种形态deriveCodexSandboxMode(agentName, toolsRaw)根据tools:契约推导 Codex 代理应处的沙箱模式——即 tools 声明直接决定运行时权限边界checkAgentsInstalled/checkCodexModelPosture/checkCodexSandboxPosture三兄弟构成安装态校验前者检查六个乃至更多agent 文件是否齐全后两者逐文件比对.toml中的sandbox_mode/model与契约推导值是否漂移。这意味着frontmatter 中缺Edit不只是能力少一个的问题而是整个工具契约与实际运行时行为的一致性被破坏。本次修复后Edit与Write并存于六个代理的契约中deriveCodexSandboxMode推导出的沙箱权限也随之与 prompt 中的写入纪律对齐。五、写给 agent 作者的实践清单从 #571/#575/#581/#582/#973 这一系列事故中可以提炼出对任何多代理multi-agent编排系统的可复用检查项纪律与能力对齐spawn prompt 中出现的每一个工具名尤其是写类工具Edit/Write都必须在tools:frontmatter 中有对应声明仅 Edit类纪律若没有Edit等于无效约束。共享文件只许局部写凡多代理共写的工件如AI-SPEC.md、RESEARCH.md、UI-SPEC.md写入动作应默认为Read全文 Edit替换目标节整文件Write仅在新建文件或明确的重写场景使用。拒绝 heredoc 创建文件各代理定义统一要求ALWAYS use the Write tool禁止Bash(cat EOF)——避免绕过工具契约与守卫。检查 compact 与完整变体同步本次六个代理的.md与.compact.md变体必须同步携带相同工具集否则安装后行为不一致。验证安装态通过gsd-tools validate agents一类校验实现见 src/agent-install-check.cts确认tools:契约、文件齐全度与沙箱模式三者一致。依赖代码级兜底而非仅文案如 #973 所示代理可能读到 advisory 但判定非绑定对高价值 curated 工件ROADMAP/STATE/milestone务必有 Write Guard 这类硬阻断机制。六、结语wise-hawks-bark这张归档 changeset 篇幅虽短却浓缩了 gsd-core 对 Agent 工具契约的一次系统性修正把Edit-only 纪律从 prompt 文本变成可执行能力。它的意义不止于修复六个代理更在于确立了一条工程原则——在多代理协同写共享文件的场景中写入能力tools:必须与写入纪律prompt严格对齐并在代码层保留对整文件覆盖的最终防线。这条原则连同 Write Guard 的实现hooks/gsd-write-guard.js与安装校验src/agent-install-check.cts共同构成了当前仓库中可查看、可验证的完整防御体系。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐GSD Core 如何锁定 Codex 技能物化契约修复 $gsd-* 入口静默丢失的回归测试实战GSD Core 如何锁定 Codex 技能物化契约修复 $gsd 入口静默丢失的回归测试实战 本篇技术指南以 GSD Core 的 changeset tigsd-core 多 Agent 并行写共享文件的竞态修复AI-SPEC.md 的 last-writer-wins 问题、Edit-only 纪律与回归保障gsd core 多 Agent 并行写共享文件的竞态修复AI SPEC.md 的 last writer wins 问题、Edit only 纪律与回归保障gsd-core UI 设计契约门禁修复 ui-safety-gate 在已安装项目中静默失效的 RUNTIME_DIR 解析机制gsd core UI 设计契约门禁修复 ui safety gate 在已安装项目中静默失效的 RUNTIME_DIR 解析机制 本文以归档 changes上一篇Windows-10-Toast-Notifications 项目常见问题解决方案下一篇GetQzonehistory 获取 QQ 空间历史说说卡在扫码登录zbar 缺失故障复现与 3 条修复路线创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gsd-core 修复 writer 代理缺失 Edit 工具：用 tools: frontmatter 契约阻止共享文件被静默整文件覆盖
【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本篇技术笔记围绕 gsd-core 仓库中一份归档 changeset.changeset/archived/wise-hawks-bark.mdtype: FixedPR #582展开剖析一个在 Agent 编排系统中非常典型的缺陷spawn prompt 里要求只用 Edit 做局部修改但代理的tools:frontmatter 没有声明Edit导致运行时回退到整文件Write静默覆盖共享文件的兄弟章节。读完本文你将理解tools:frontmatter 作为可执行能力契约的地位、六个 writer 代理的修复内容、同类 bug 家族#571/#575/#581/#973的演化以及 gsd-core 在代码层Write Guard hook 与 agent 安装校验对这类事故的兜底机制。一、这次修复改了什么一张 changeset 与六个代理1.1 changeset 原文事实归档于.changeset/archived/wise-hawks-bark.md的变更记录陈述了以下事实影响对象六个 writer 代理——gsd-eval-planner、gsd-ai-researcher、gsd-domain-researcher、gsd-phase-researcher、gsd-ui-researcher、gsd-debug-session-manager。修复动作在它们的tools:frontmatter 中同时携带Edit与Write。动机这些代理的 spawn prompt 中声明了仅 Edit的写入纪律Edit-only discipline但此前 frontmatter 里没有Edit该纪律不可执行enforceable。后果没有Edit时代理回退到整文件Write会静默覆盖silently clobbered共享文件如AI-SPEC.md中其他代理已写好的兄弟章节。同源问题与 #571 属于同一 bug 类别其中gsd-doc-writer已在 #575 修复本 changeset 关联 issue #581。1.2 六个代理各自写什么从 agents/ 目录下的代理定义可以确认这六个代理都是各自阶段/流程中负责产出文档工件的 writer代理产出工件共享文件风险点gsd-domain-researcher.mdAI-SPEC.md的 Section 1bDomain Context与 ai-researcher、eval-planner 同写一个文件gsd-ai-researcher.mdAI-SPEC.md的 Section 3、4、4b同上gsd-eval-planner.mdAI-SPEC.md的 Section 5Evaluation Strategy、6Guardrails、7Production Monitoring同上gsd-phase-researcher.mdRESEARCH.md.planning/phases/XX-name/{phase_num}-RESEARCH.md与其他 research 阶段产物同处一个规划目录gsd-ui-researcher.mdUI-SPEC.md$PHASE_DIR/$PADDED_PHASE-UI-SPEC.md设计契约文档gsd-debug-session-manager.md调试会话文件.planning/debug/{slug}.md及其归档/提交会话状态与证据由多轮子代理共同追加其中AI-SPEC.md是最典型的多作者共享文件gsd-domain-researcher写 Section 1bgsd-ai-researcher写 Section 3–4bgsd-eval-planner写 Section 5–7。三者由ai-integration-phase编排器依次 spawn。任何一个代理若用整文件Write覆盖就会把前面代理写入的章节一并抹掉——这正是本次修复要消灭的静默破坏。1.3 修复后的 frontmatter 实态对照仓库现状六个代理的tools:frontmatter 均已包含Edit与Write与 compact 变体保持一致agents/gsd-eval-planner.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, AskUserQuestionagents/gsd-ai-researcher.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, WebFetch, WebSearch, mcp__context7__*, ...agents/gsd-domain-researcher.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, WebSearch, WebFetch, ...agents/gsd-phase-researcher.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, Skill, WebSearch, WebFetch, ...agents/gsd-ui-researcher.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, Skill, WebSearch, ...agents/gsd-debug-session-manager.md第 4 行tools: Read, Write, Edit, Bash, Grep, Glob, Agent, AskUserQuestion各代理的 compact 变体如 agents/gsd-eval-planner.compact.md同步携带相同工具集安装时两者共同构成代理的完整定义。二、问题本质为什么没有 EditEdit-only 纪律就不可执行2.1 纪律声明在 prompt能力声明在 frontmatter以gsd-eval-planner为例其执行流里对写入方式有非常明确的纪律要求gsd-domain-researcher.md的 Write contract 写明ALWAYS use the Write tool to create files— never useBash(cat EOF)or heredoc commands同时这些代理面向共享文件AI-SPEC.md的更新动作语义上是**更新第 N 节**正确姿势应是先Read全文再用Edit精准替换目标章节而不是把整份文件重写一遍。问题在于prompt 里的指令只是建议frontmatter 里的tools:才是运行时真正授予的工具集。当代理的 spawn prompt 要求用 Edit 做局部更新但tools:里没有Edit时模型在运行时只会收到Write这一个写工具于是必然回退到整文件Write——而模型构建整文件 payload 时往往基于它对文件的部分读取尤其当文件很长、上下文预算有限时于是读了一个窗口、写回整份文件窗口之外的其他代理的章节就被静默覆盖。这就是 changeset 所描述的so the Edit-only discipline in their spawn prompts is enforceable的含义修复的本质不是改 prompt 文案而是给运行时补上执行该纪律所需的工具让纪律从文本约束变成可执行约束。2.2 共享文件的兄弟章节为何必然受害AI-SPEC.md的写作顺序在 gsd-ai-researcher.md 与 gsd-eval-planner.md 中可见domain-researcher 先写 Section 1bai-researcher 写 Section 3–4beval-planner 最后写 Section 5–7。每个代理的input都接收ai_spec_path指向同一个AI-SPEC.md。在这种多写者、单文件、分节协作的模型下任何一个代理在写入时读到的是磁盘上已含他人章节的完整文件若它用整文件Write回写payload 必须重建全文——任何遗漏都会成为兄弟章节静默丢失且这种丢失不报错、不告警编排器只检查目标节是否存在很难发现其他节被悄悄删掉。2.3 同类 bug 家族#571 → #575 → #581 → #582changeset 明确指出本修复与 #571 属同一 bug 类别gsd-doc-writer此前也因缺失Edit而回退整文件 Write于 #575 修复。本次 #582 将同样的修复推广到六个代理并关联 #581 作为跟踪。仓库中这类指令要求 Edit、能力未授予 Edit的缺陷不是孤例而是一类系统性问题——这也解释了为何 changeset 会专门标注 Same bug class as #571。更深层的历史教训记录在 hooks/gsd-write-guard.js 的头部注释中issue #973 记录了一个 planner 读取ROADMAP.md约 16 行窗口后用整文件Write覆盖了 292 行的完整文件三个里程碑的已提交历史被摧毁292 → 16 行约 94.5% 的内容坍缩。该事件直接催生了代码层的 Write Guard也印证了仅靠 prompt 指令无法阻止覆盖这一判断——#973 中代理甚至读到了 advisory 提示却将其判定为非绑定并继续执行。三、代码层的兜底gsd-write-guard.js 如何拦截灾难性 Writeprompt 修复给Edit工具降低了覆盖概率但 gsd-core 的工程哲学是由代码而非指令强制执行enforced by code rather than by instruction。为此仓库在 hooks/gsd-write-guard.js 实现了 PreToolUse 写守卫。3.1 守卫的触发条件与判定逻辑该 hook 刻意收窄触发面只拦截整文件 Write 灾难性收缩 curated.planning/工件只针对WriteEdit/MultiEdit天然不在范围内——源码注释写明 Edit/MultiEdit replace bounded spans and are out of scope by design即编辑类工具按构造就是有界的不会整文件覆盖只针对已存在的 curated 文件.planning/ROADMAP.md、.planning/STATE.md、.planning/milestones/*-ROADMAP.md以及 workstream 与 project 作用域下的对应变体CURATED_PATTERNS数组共 8 条正则见 gsd-write-guard.js阈值判定当 pending payload 行数低于磁盘文件行数的SHRINK_RATIO0.4即小于当前 40%时硬阻断exit 2, decision: block小于FLOOR_LINES40 行的 stub 文件豁免匹配前先 realpath 解析防止通过符号链接路径绕过 curated 匹配。其阻断信息会明确建议To fix: use Edit for a scoped change, or Read the full file and include every section in the Write——与本次 changeset 的修复方向完全一致能局部改就 Edit必须重写就先读全文。3.2 有界的保证与显式逃逸守卫的头部注释也诚实声明了其边界它阻止意外/单次坍缩但无法防御蓄意绕过a determined agent。为此提供了两条显式逃生通道环境变量GSD_ALLOW_PLANNING_SHRINK1供人类交互式运行一次性哨兵文件.planning/.gsd-allow-shrink供工作流步骤使用——哨兵 15 分钟 TTL、绑定唯一目标文件路径、命中即消费避免成为长期解锁。这两条通道都写进了阻断信息与被守卫的绑定测试中属于有文档的、路径绑定、单次、可审计的机制。3.3 对本 bug 类的防护意义不难看出Write Guard 与 #582 的修复形成双层防线工具层本次 changeset给六个 writer 代理授予Edit让局部更新共享文件成为运行时可能且自然的动作Hook 层#973 后建立即使某个代理仍因故发起整文件 Write只要目标是 curated 规划工件且坍缩超阈值就会被硬阻断。对于AI-SPEC.md这类非.planning/路径的共享文件Write Guard 不直接覆盖其 curated 匹配是封闭集合因此工具层修复对AI-SPEC.md的保护更为关键——这正是本次 changeset 的价值所在。四、tools: frontmatter 是权威契约安装与校验的源码佐证tools:frontmatter 不只是给模型看的提示它在 gsd-core 中是被程序读取的结构化契约。相关证据集中在 src/agent-install-check.ctsextractToolsValue来自 src/codex-agent-toml.cts由 install 发射器与校验器共享从 agent 文件解析tools:值支持行内与 YAML 块列表两种形态deriveCodexSandboxMode(agentName, toolsRaw)根据tools:契约推导 Codex 代理应处的沙箱模式——即 tools 声明直接决定运行时权限边界checkAgentsInstalled/checkCodexModelPosture/checkCodexSandboxPosture三兄弟构成安装态校验前者检查六个乃至更多agent 文件是否齐全后两者逐文件比对.toml中的sandbox_mode/model与契约推导值是否漂移。这意味着frontmatter 中缺Edit不只是能力少一个的问题而是整个工具契约与实际运行时行为的一致性被破坏。本次修复后Edit与Write并存于六个代理的契约中deriveCodexSandboxMode推导出的沙箱权限也随之与 prompt 中的写入纪律对齐。五、写给 agent 作者的实践清单从 #571/#575/#581/#582/#973 这一系列事故中可以提炼出对任何多代理multi-agent编排系统的可复用检查项纪律与能力对齐spawn prompt 中出现的每一个工具名尤其是写类工具Edit/Write都必须在tools:frontmatter 中有对应声明仅 Edit类纪律若没有Edit等于无效约束。共享文件只许局部写凡多代理共写的工件如AI-SPEC.md、RESEARCH.md、UI-SPEC.md写入动作应默认为Read全文 Edit替换目标节整文件Write仅在新建文件或明确的重写场景使用。拒绝 heredoc 创建文件各代理定义统一要求ALWAYS use the Write tool禁止Bash(cat EOF)——避免绕过工具契约与守卫。检查 compact 与完整变体同步本次六个代理的.md与.compact.md变体必须同步携带相同工具集否则安装后行为不一致。验证安装态通过gsd-tools validate agents一类校验实现见 src/agent-install-check.cts确认tools:契约、文件齐全度与沙箱模式三者一致。依赖代码级兜底而非仅文案如 #973 所示代理可能读到 advisory 但判定非绑定对高价值 curated 工件ROADMAP/STATE/milestone务必有 Write Guard 这类硬阻断机制。六、结语wise-hawks-bark这张归档 changeset 篇幅虽短却浓缩了 gsd-core 对 Agent 工具契约的一次系统性修正把Edit-only 纪律从 prompt 文本变成可执行能力。它的意义不止于修复六个代理更在于确立了一条工程原则——在多代理协同写共享文件的场景中写入能力tools:必须与写入纪律prompt严格对齐并在代码层保留对整文件覆盖的最终防线。这条原则连同 Write Guard 的实现hooks/gsd-write-guard.js与安装校验src/agent-install-check.cts共同构成了当前仓库中可查看、可验证的完整防御体系。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐GSD Core 如何锁定 Codex 技能物化契约修复 $gsd-* 入口静默丢失的回归测试实战GSD Core 如何锁定 Codex 技能物化契约修复 $gsd 入口静默丢失的回归测试实战 本篇技术指南以 GSD Core 的 changeset tigsd-core 多 Agent 并行写共享文件的竞态修复AI-SPEC.md 的 last-writer-wins 问题、Edit-only 纪律与回归保障gsd core 多 Agent 并行写共享文件的竞态修复AI SPEC.md 的 last writer wins 问题、Edit only 纪律与回归保障gsd-core UI 设计契约门禁修复 ui-safety-gate 在已安装项目中静默失效的 RUNTIME_DIR 解析机制gsd core UI 设计契约门禁修复 ui safety gate 在已安装项目中静默失效的 RUNTIME_DIR 解析机制 本文以归档 changes上一篇Windows-10-Toast-Notifications 项目常见问题解决方案下一篇GetQzonehistory 获取 QQ 空间历史说说卡在扫码登录zbar 缺失故障复现与 3 条修复路线创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考