oh-my-posh 代码变更工作流 Phase 5 验证指南从质量门禁到功能证明的完整实践【免费下载链接】oh-my-poshThe most customisable and low-latency cross platform/shell prompt renderer项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-posh导读本文是 oh-my-posh 仓库内嵌的 AI 代码变更工作流.agents/skills/code-changes中Phase 5 — Verify验证阶段的完整技术指南。该阶段负责在变更合并后的最终状态上运行项目的质量门禁与功能证明是防止测试通过但行为错误的最后一道防线。读完本文你将掌握 oh-my-posh 项目中验证阶段的质量门禁清单、功能证明方法、高影响结果的升级Escalate触发条件、失败分流逻辑以及保证循环收敛的重试上限机制并能直接套用go test ./...、golangci-lint run、e2e 冒烟测试等真实命令完成一次可信的验证。验证阶段在整个工作流中的定位在 code-changes 工作流说明 中从问题/PR/想法到交付代码共分六个阶段按序执行Analyzereferences/analyze.md— 根因与范围分析必须在代码中验证不能只信报告Planreferences/plan.md— 固定规格、任务拆分、并行/串行、工作区规划Delegate— 按能力为每个任务匹配执行者Supervisereferences/supervise.md— 监控、排障、批判性评审子代理产出Verify即本文主题references/verify.md— 在合并后的最终状态上运行质量门禁与功能证明Deliverreferences/deliver.md— 约定式提交与结果优先的报告。验证阶段有三个关键定位理解它们才能正确执行验证永不向下委托验证是协调者coordinator自己的本职工作默认不由更小的模型或子代理代做。这与 Delegate 阶段把实现工作派发给 implementer 形成对照——实现可以委托验证必须亲自做。验证运行在合并后的最终状态上只有当 Phase 4Supervise按merge_plan把并行分支全部合并、形成唯一的merged_diff之后验证才真正开始。每个分支各自变绿不等于门禁通过plan.md 明确要求Verify 只在合并后的状态上运行一次绝不在分支上逐次运行。验证是产出物契约的一环按 artifacts.md 的定义Phase 5 必须产出两份命名产物——失败时产出failure recordattempt_number / failure_class / destination / escalation_answer成功时产出verification evidencegates_run / functional_proof / retry_count。没有产物的验证不构成有效交接。质量门禁四项必须为零错误验证阶段的第一半是质量门禁按 verify.md 的清单执行构建、完整测试套件、格式化器、lint 全部通过且零错误。对照 Phase 2 钉定的语言/框架技能逐行复查最终 diff并运行每个技能定义的 pre-commit 门禁。Lint 覆盖不到控制流、测试结构、日志与注释约定——lint 变绿并不能证明技能被遵循。当平台相关文件发生变更时为每个目标平台交叉编译或重新 lint——本地工具链会跳过其他平台的规则语言技能会说明这些文件如何被标记。绝不为了变绿而削弱门禁不弱化 gate、不跳过 linter、不删除测试。原文以Never weaken a gate, skip a linter, or delete a test to get to green作为不可逾越的红线。在 oh-my-posh 中落实质量门禁结合仓库实际质量门禁对应如下真实命令与资源构建与单测从 src/ 模块根目录运行go test ./...针对单个段可运行go test ./segments/... -run TestFoo见 AGENTS.md 的 Key Commands。Lint运行golangci-lint run同样来自 AGENTS.md。仓库自身的 golang 技能 定义了 pre-commit 门禁的具体规则例如避免else、优先 early return、错误字符串小写开头、导出符号必须文档化等——这些正是lint 覆盖不到而必须人工复查的内容。端到端验证oh-my-posh 还提供独立的 e2e 测试套件e2e/README.md它针对 shell 集成而非 Go 内部逻辑用真实oh-my-posh二进制生成 init 脚本喂给真实 shell在伪终端中驱动交互会话。运行时在e2e/目录下执行go test -count1 ./...。该套件分三层——语法层syntax_test.go用 shell 自身解析器校验脚本、冒烟层smoke_test.go真实 pty 中启动 shell、断言提示符干净渲染、行为层features_test.go退出码传播、瞬态提示符、右提示符、FTCS 标记等场景。当变更触及 bash/zsh/fish/pwsh/nu 等五大 shell的集成逻辑时这层门禁是 Phase 5 必须包含的内容。跨平台复查oh-my-posh 是跨平台项目src/下存在大量平台特定文件如 terminal_darwin.go、terminal_windows.go、spotify_linux.go 等以及colors_*.go、constants_*.go、install_*.go系列。按文档要求这类文件变更时必须为每个目标平台做交叉编译/重新 lint因为本地工具链只会应用当前平台的构建标签规则。功能证明测试通过是必要不充分条件验证阶段的第二半是功能证明这是 verify.md 最强调的环节Tests passing is necessary, not sufficient. Run the real flow and confirm concrete outputs: render the prompt, execute the command, hit the endpoint. Record the actual values observed — the final report quotes them as evidence, not adjectives.要点拆解跑真实流程记录真实输出渲染提示符、执行命令、请求端点——把实际观察到的值写进最终报告作为证据而不是形容词应该没问题不算证据。按用户到达它的方式去走流程而不是只按测试夹具的方式验证构建产物而非 dev server、验证冷启动而非运行中的进程、验证用户实际打开的入口点。涉及 dev server 或文件监视器时先重启再判断行为——过期的 bundle 会产生自信而错误的验证。当用户声明将自行做手工验证时明确告诉他们应该检查什么、预期结果是什么。在 oh-my-posh 中落实功能证明提示符渲染oh-my-posh init shell是用户接入的入口它把 shell 特定初始化脚本写入缓存来源为 src/shell/scripts/并返回一行供 shelleval的一行式命令见 AGENTS.md 的 Shell Integration 一节。功能证明即在新 shell 会话中 eval 该初始化脚本确认提示符按 themes/ 下的主题配置真实渲染出来。CLI 命令命令树位于 src/cmdtree/命令实现位于 src/cli/root.go为入口。若变更涉及某个命令如oh-my-posh config export、oh-my-posh get shell等功能证明应在真实终端中执行该命令并记录输出。冷启动原则不要把测试进程内已加载的缓存状态当作证据以用户首次启动 shell 的方式冷启动验证这正是 e2e 冒烟层在 pty 中真实启动 shell 的原因。高影响结果升级到最强模型运行门禁与功能证明始终由协调者自己完成但当以下条件成立时需要把具体的判断问题提交给可用的最强推理模型裁决而不是自行宣布完成详见 escalate.md结果含糊不清ambiguous变更属于高爆炸半径high-blast-radius如数据库迁移、安全相关、不可逆操作。escalate.md 进一步补充了完整的触发条件清单根因无法从代码中确认、变更跨越模块边界或触碰公共 API、涉及安全/认证/加密/支付/数据迁移、操作不可逆或高爆炸半径schema 迁移、删除、force-push、生产配置、implementer 在同一任务上多次报告规格缺口或矛盾、Verify 第二次连续把同一任务退回、评审 diff 后无法确定修复正确还是仅貌似合理、用户明确要求第二意见或对抗性评审。升级的正确姿势封装具体问题而非整个任务移交回答该问题所需的钉定上下文相关代码、当前假设、为何不确定拿到答案后恢复阶段所有权。升级是有界问答调用不是阶段移交——升级层永远不会成为任务的新所有者也不决定范围。失败分流按真正坏掉的是什么选择去向验证失败时不要按默认习惯选择去向而是依据实际坏掉的东西分流见 verify.md 的 On failure 一节失败类型含义去向门禁失败构建/测试/lint或 diff 不符合规格规格是对的执行出了问题退回Phase 4由 implementer 修复功能证明与所述根因矛盾或修复完全没有改变观察到的行为规格建立在错误的诊断之上退回Phase 1重新做根因分析关键规则回到 Phase 1 会重新激活它的 stop gate重新报告修订后的分析等待用户再次go后才能重新规划——与首次进入完全相同。一次 Verify 退回不是继续无人值守实现的长期授权。回 Phase 1 的场景正是 analyze.md 中每次进入该阶段都要等待 go包括从 Verify 返回的情况这一条的实际应用。退回时按 artifacts.md 的failure record契约显式携带attempt_number本任务第几次失败验证、failure_classgate failure / spec mismatch 或 wrong-root-cause这决定了去向、destinationSupervise 或 Analyze、以及attempt_number达到 2 且已咨询 Escalation 时的escalation_answer。重试上限让循环必然收敛verify.md 的最后部分处理一个现实问题跨轮次没有内存计数必须作为文本显式携带而不是靠脑子记。每次 Verify 失败时必须在交给下一阶段的报告中显式声明本任务的尝试次数、坏掉的是什么、选择的去向。同一任务指同一个原始用户请求——Phase 1 退回后修订了诊断仍是同一任务不重置计数。重试上限规则如下同一任务第二次连续失败时无论 cycle 1 与 cycle 2 是否去往同一去向停止循环不要把任务第三次发回。将具体问题为什么修复落不了地或为什么根因总是找错升级到 Escalation 层。若升级答案之后的那个 cycle 仍然失败不要再次升级也不要第四次发回。彻底停止循环并向用户报告前两次尝试、升级的问题与答案、以及最新一次失败的证据。继续循环下去意味着该工作流在此任务上不再收敛而这个决定应当属于用户而不是又一次升级调用。这套机制与 artifacts.md 中显式重述约定同样适用于所有 more than once 触发器如 escalate.md 中 repeated spec gap的约定互为表里——所有跨轮次计数器都只以写入对话的文本形式存在。文档随行文档与代码同变更交付验证阶段还包含一项常被忽略的检查——文档变更必须与它们所描述的代码在同一变更中交付verify.md 的 Documentation 一节。对每个用户可见的行为变更逐一检查受影响功能的项目文档/网站页面oh-my-posh 的文档站为 Docusaurus位于 website/segments 文档在 website/docs/segments/当 flags、命令或默认值变更时检查 README.md 或安装/设置说明。这与 plan.md 中文档更新属于改变行为的那个任务而不是独立任务的规划原则前后呼应也与 AGENTS.md 中 segment 开发五件套源码、测试、MDX 文档、sidebars/schema 更新、gob 注册的约定一致——文档缺口会在验证阶段被显式捕获。一次完整验证的检查清单将上述规则浓缩为可执行的核对清单在合并后的最终状态上运行构建、完整测试、格式化、lint零错误go test ./...golangci-lint run涉及 shell 集成时加cd e2e go test -count1 ./...对照 Phase 2 钉定的技能如 golang逐行复查 diff运行其 pre-commit 门禁平台特定文件变更时为每个目标平台交叉编译/重新 lint如src/runtime/terminal_*.go、src/segments/spotify_*.go系列跑真实流程渲染提示符 / 执行命令 / 请求端点记录实际观察值作为证据冷启动而非复用运行中进程必要时先重启 dev server 再判断高爆炸半径或结果含糊时封装具体问题升级到最强模型得到答案后恢复所有权失败时按 failure_class 选择去向门禁失败→Phase 4根因错误→Phase 1显式携带 attempt_number / destinationPhase 1 退回须重新等待用户 go同一任务第二次连续失败即停止循环并升级升级后 cycle 再失败则停止并向用户报告用户自行做手工验证时明确告知检查内容与预期结果检查受影响的文档/网站页面与 README 是否随代码同变更交付绝不削弱门禁、跳过 linter、删除测试来换取变绿。相关资源索引验证阶段规范.agents/skills/code-changes/references/verify.md工作流总览与角色划分.agents/skills/code-changes/SKILL.md阶段间产物契约含 failure record 与 verification evidence 结构.agents/skills/code-changes/references/artifacts.md升级触发条件与操作方式.agents/skills/code-changes/references/escalate.md上游阶段分析 references/analyze.md、规划 references/plan.md、监督 references/supervise.md、交付 references/deliver.md项目级质量资源构建与 lint 命令见 AGENTS.mde2e 测试套件说明见 e2e/README.mdGo 编码门禁见 .agents/skills/golang/SKILL.md【免费下载链接】oh-my-poshThe most customisable and low-latency cross platform/shell prompt renderer项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-posh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-posh 代码变更工作流 Phase 5 验证指南：从质量门禁到功能证明的完整实践
oh-my-posh 代码变更工作流 Phase 5 验证指南从质量门禁到功能证明的完整实践【免费下载链接】oh-my-poshThe most customisable and low-latency cross platform/shell prompt renderer项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-posh导读本文是 oh-my-posh 仓库内嵌的 AI 代码变更工作流.agents/skills/code-changes中Phase 5 — Verify验证阶段的完整技术指南。该阶段负责在变更合并后的最终状态上运行项目的质量门禁与功能证明是防止测试通过但行为错误的最后一道防线。读完本文你将掌握 oh-my-posh 项目中验证阶段的质量门禁清单、功能证明方法、高影响结果的升级Escalate触发条件、失败分流逻辑以及保证循环收敛的重试上限机制并能直接套用go test ./...、golangci-lint run、e2e 冒烟测试等真实命令完成一次可信的验证。验证阶段在整个工作流中的定位在 code-changes 工作流说明 中从问题/PR/想法到交付代码共分六个阶段按序执行Analyzereferences/analyze.md— 根因与范围分析必须在代码中验证不能只信报告Planreferences/plan.md— 固定规格、任务拆分、并行/串行、工作区规划Delegate— 按能力为每个任务匹配执行者Supervisereferences/supervise.md— 监控、排障、批判性评审子代理产出Verify即本文主题references/verify.md— 在合并后的最终状态上运行质量门禁与功能证明Deliverreferences/deliver.md— 约定式提交与结果优先的报告。验证阶段有三个关键定位理解它们才能正确执行验证永不向下委托验证是协调者coordinator自己的本职工作默认不由更小的模型或子代理代做。这与 Delegate 阶段把实现工作派发给 implementer 形成对照——实现可以委托验证必须亲自做。验证运行在合并后的最终状态上只有当 Phase 4Supervise按merge_plan把并行分支全部合并、形成唯一的merged_diff之后验证才真正开始。每个分支各自变绿不等于门禁通过plan.md 明确要求Verify 只在合并后的状态上运行一次绝不在分支上逐次运行。验证是产出物契约的一环按 artifacts.md 的定义Phase 5 必须产出两份命名产物——失败时产出failure recordattempt_number / failure_class / destination / escalation_answer成功时产出verification evidencegates_run / functional_proof / retry_count。没有产物的验证不构成有效交接。质量门禁四项必须为零错误验证阶段的第一半是质量门禁按 verify.md 的清单执行构建、完整测试套件、格式化器、lint 全部通过且零错误。对照 Phase 2 钉定的语言/框架技能逐行复查最终 diff并运行每个技能定义的 pre-commit 门禁。Lint 覆盖不到控制流、测试结构、日志与注释约定——lint 变绿并不能证明技能被遵循。当平台相关文件发生变更时为每个目标平台交叉编译或重新 lint——本地工具链会跳过其他平台的规则语言技能会说明这些文件如何被标记。绝不为了变绿而削弱门禁不弱化 gate、不跳过 linter、不删除测试。原文以Never weaken a gate, skip a linter, or delete a test to get to green作为不可逾越的红线。在 oh-my-posh 中落实质量门禁结合仓库实际质量门禁对应如下真实命令与资源构建与单测从 src/ 模块根目录运行go test ./...针对单个段可运行go test ./segments/... -run TestFoo见 AGENTS.md 的 Key Commands。Lint运行golangci-lint run同样来自 AGENTS.md。仓库自身的 golang 技能 定义了 pre-commit 门禁的具体规则例如避免else、优先 early return、错误字符串小写开头、导出符号必须文档化等——这些正是lint 覆盖不到而必须人工复查的内容。端到端验证oh-my-posh 还提供独立的 e2e 测试套件e2e/README.md它针对 shell 集成而非 Go 内部逻辑用真实oh-my-posh二进制生成 init 脚本喂给真实 shell在伪终端中驱动交互会话。运行时在e2e/目录下执行go test -count1 ./...。该套件分三层——语法层syntax_test.go用 shell 自身解析器校验脚本、冒烟层smoke_test.go真实 pty 中启动 shell、断言提示符干净渲染、行为层features_test.go退出码传播、瞬态提示符、右提示符、FTCS 标记等场景。当变更触及 bash/zsh/fish/pwsh/nu 等五大 shell的集成逻辑时这层门禁是 Phase 5 必须包含的内容。跨平台复查oh-my-posh 是跨平台项目src/下存在大量平台特定文件如 terminal_darwin.go、terminal_windows.go、spotify_linux.go 等以及colors_*.go、constants_*.go、install_*.go系列。按文档要求这类文件变更时必须为每个目标平台做交叉编译/重新 lint因为本地工具链只会应用当前平台的构建标签规则。功能证明测试通过是必要不充分条件验证阶段的第二半是功能证明这是 verify.md 最强调的环节Tests passing is necessary, not sufficient. Run the real flow and confirm concrete outputs: render the prompt, execute the command, hit the endpoint. Record the actual values observed — the final report quotes them as evidence, not adjectives.要点拆解跑真实流程记录真实输出渲染提示符、执行命令、请求端点——把实际观察到的值写进最终报告作为证据而不是形容词应该没问题不算证据。按用户到达它的方式去走流程而不是只按测试夹具的方式验证构建产物而非 dev server、验证冷启动而非运行中的进程、验证用户实际打开的入口点。涉及 dev server 或文件监视器时先重启再判断行为——过期的 bundle 会产生自信而错误的验证。当用户声明将自行做手工验证时明确告诉他们应该检查什么、预期结果是什么。在 oh-my-posh 中落实功能证明提示符渲染oh-my-posh init shell是用户接入的入口它把 shell 特定初始化脚本写入缓存来源为 src/shell/scripts/并返回一行供 shelleval的一行式命令见 AGENTS.md 的 Shell Integration 一节。功能证明即在新 shell 会话中 eval 该初始化脚本确认提示符按 themes/ 下的主题配置真实渲染出来。CLI 命令命令树位于 src/cmdtree/命令实现位于 src/cli/root.go为入口。若变更涉及某个命令如oh-my-posh config export、oh-my-posh get shell等功能证明应在真实终端中执行该命令并记录输出。冷启动原则不要把测试进程内已加载的缓存状态当作证据以用户首次启动 shell 的方式冷启动验证这正是 e2e 冒烟层在 pty 中真实启动 shell 的原因。高影响结果升级到最强模型运行门禁与功能证明始终由协调者自己完成但当以下条件成立时需要把具体的判断问题提交给可用的最强推理模型裁决而不是自行宣布完成详见 escalate.md结果含糊不清ambiguous变更属于高爆炸半径high-blast-radius如数据库迁移、安全相关、不可逆操作。escalate.md 进一步补充了完整的触发条件清单根因无法从代码中确认、变更跨越模块边界或触碰公共 API、涉及安全/认证/加密/支付/数据迁移、操作不可逆或高爆炸半径schema 迁移、删除、force-push、生产配置、implementer 在同一任务上多次报告规格缺口或矛盾、Verify 第二次连续把同一任务退回、评审 diff 后无法确定修复正确还是仅貌似合理、用户明确要求第二意见或对抗性评审。升级的正确姿势封装具体问题而非整个任务移交回答该问题所需的钉定上下文相关代码、当前假设、为何不确定拿到答案后恢复阶段所有权。升级是有界问答调用不是阶段移交——升级层永远不会成为任务的新所有者也不决定范围。失败分流按真正坏掉的是什么选择去向验证失败时不要按默认习惯选择去向而是依据实际坏掉的东西分流见 verify.md 的 On failure 一节失败类型含义去向门禁失败构建/测试/lint或 diff 不符合规格规格是对的执行出了问题退回Phase 4由 implementer 修复功能证明与所述根因矛盾或修复完全没有改变观察到的行为规格建立在错误的诊断之上退回Phase 1重新做根因分析关键规则回到 Phase 1 会重新激活它的 stop gate重新报告修订后的分析等待用户再次go后才能重新规划——与首次进入完全相同。一次 Verify 退回不是继续无人值守实现的长期授权。回 Phase 1 的场景正是 analyze.md 中每次进入该阶段都要等待 go包括从 Verify 返回的情况这一条的实际应用。退回时按 artifacts.md 的failure record契约显式携带attempt_number本任务第几次失败验证、failure_classgate failure / spec mismatch 或 wrong-root-cause这决定了去向、destinationSupervise 或 Analyze、以及attempt_number达到 2 且已咨询 Escalation 时的escalation_answer。重试上限让循环必然收敛verify.md 的最后部分处理一个现实问题跨轮次没有内存计数必须作为文本显式携带而不是靠脑子记。每次 Verify 失败时必须在交给下一阶段的报告中显式声明本任务的尝试次数、坏掉的是什么、选择的去向。同一任务指同一个原始用户请求——Phase 1 退回后修订了诊断仍是同一任务不重置计数。重试上限规则如下同一任务第二次连续失败时无论 cycle 1 与 cycle 2 是否去往同一去向停止循环不要把任务第三次发回。将具体问题为什么修复落不了地或为什么根因总是找错升级到 Escalation 层。若升级答案之后的那个 cycle 仍然失败不要再次升级也不要第四次发回。彻底停止循环并向用户报告前两次尝试、升级的问题与答案、以及最新一次失败的证据。继续循环下去意味着该工作流在此任务上不再收敛而这个决定应当属于用户而不是又一次升级调用。这套机制与 artifacts.md 中显式重述约定同样适用于所有 more than once 触发器如 escalate.md 中 repeated spec gap的约定互为表里——所有跨轮次计数器都只以写入对话的文本形式存在。文档随行文档与代码同变更交付验证阶段还包含一项常被忽略的检查——文档变更必须与它们所描述的代码在同一变更中交付verify.md 的 Documentation 一节。对每个用户可见的行为变更逐一检查受影响功能的项目文档/网站页面oh-my-posh 的文档站为 Docusaurus位于 website/segments 文档在 website/docs/segments/当 flags、命令或默认值变更时检查 README.md 或安装/设置说明。这与 plan.md 中文档更新属于改变行为的那个任务而不是独立任务的规划原则前后呼应也与 AGENTS.md 中 segment 开发五件套源码、测试、MDX 文档、sidebars/schema 更新、gob 注册的约定一致——文档缺口会在验证阶段被显式捕获。一次完整验证的检查清单将上述规则浓缩为可执行的核对清单在合并后的最终状态上运行构建、完整测试、格式化、lint零错误go test ./...golangci-lint run涉及 shell 集成时加cd e2e go test -count1 ./...对照 Phase 2 钉定的技能如 golang逐行复查 diff运行其 pre-commit 门禁平台特定文件变更时为每个目标平台交叉编译/重新 lint如src/runtime/terminal_*.go、src/segments/spotify_*.go系列跑真实流程渲染提示符 / 执行命令 / 请求端点记录实际观察值作为证据冷启动而非复用运行中进程必要时先重启 dev server 再判断高爆炸半径或结果含糊时封装具体问题升级到最强模型得到答案后恢复所有权失败时按 failure_class 选择去向门禁失败→Phase 4根因错误→Phase 1显式携带 attempt_number / destinationPhase 1 退回须重新等待用户 go同一任务第二次连续失败即停止循环并升级升级后 cycle 再失败则停止并向用户报告用户自行做手工验证时明确告知检查内容与预期结果检查受影响的文档/网站页面与 README 是否随代码同变更交付绝不削弱门禁、跳过 linter、删除测试来换取变绿。相关资源索引验证阶段规范.agents/skills/code-changes/references/verify.md工作流总览与角色划分.agents/skills/code-changes/SKILL.md阶段间产物契约含 failure record 与 verification evidence 结构.agents/skills/code-changes/references/artifacts.md升级触发条件与操作方式.agents/skills/code-changes/references/escalate.md上游阶段分析 references/analyze.md、规划 references/plan.md、监督 references/supervise.md、交付 references/deliver.md项目级质量资源构建与 lint 命令见 AGENTS.mde2e 测试套件说明见 e2e/README.mdGo 编码门禁见 .agents/skills/golang/SKILL.md【免费下载链接】oh-my-poshThe most customisable and low-latency cross platform/shell prompt renderer项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-posh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考