oh-my-openagent 纯结构重构 PR 的三层验证策略以 delegate-task 常量拆分为例【免费下载链接】oh-my-openagentOmO: Drop your tokens. Ultrawork. Done.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent本文以 oh-my-openagent 仓库中一份真实的 PR 验证策略文档为主体完整还原“本地预检 → CI 门禁 → 多智能体评审 → 外部 Bot”的四步验证链路并以delegate-task/constants.ts的模块化拆分为具体案例讲解每个门禁要检查什么、失败时如何定位以及“纯重构不改变运行时行为”这一声明如何被逐项证明。背景为什么“纯重构”也需要专门的验证策略该策略文档verification-strategy.md服务于一次结构性重构将 oh-my-openagent 中 654 行、承载 4 种职责的constants.ts拆分为聚焦单一职责的小模块。其执行计划execution-plan.md给出的拆分方案是新文件职责约 LOCdefault-categories.tsDEFAULT_CATEGORIES、CATEGORY_DESCRIPTIONS~40category-prompt-appends.ts8 个*_CATEGORY_PROMPT_APPEND常量 CATEGORY_PROMPT_APPENDS记录~300提示词文本豁免 LOC 限制plan-agent-prompt.tsPlan agent 系统提示词常量 构造函数~250提示词文本豁免plan-agent-names.tsPLAN_AGENT_NAMES、isPlanAgent、PLAN_FAMILY_NAMES、isPlanFamily~30constants.ts更新从 4 个新文件 re-export保持向后兼容~5向后兼容通过两条路径保证constants.tsre-export 全部 4 个新文件的内容index.ts已有的export * from ./constants保持不变。从当前仓库源码看该策略的向后兼容思路已体现在 index.ts 中export * from ./constants而当前的 constants.ts 顶部已采用“re-export barrel”形态把BUILTIN_CATEGORY_REQUIRES_MODEL、CATEGORY_DESCRIPTIONS、CATEGORY_PROMPT_APPENDS、CATEGORY_PROMPT_APPEND_RESOLVERS、DEFAULT_CATEGORIES统一从./builtin-categories转出。从源码结构看实际落地的文件命名如builtin-categories.ts与计划稿中的 4 文件方案存在演进差异但“原路径继续可用、新增模块只负责实现”的兼容策略是一致的。纯重构的验证核心难题在于“无行为变更”是一个声明不是事实。策略文档因此把验证拆成逐层递进的门禁每层只回答一个问题编译是否通过现有消费者是否被破坏结构是否满足拆分目标外部视角有无遗漏第一层Pre-Gate 本地验证Push 之前策略要求在推送前于 worktree 内跑完与 CI 相同的关键检查外加一条专门针对 re-export 完整性的动态导出检查# In worktree bun run typecheck bun test src/tools/delegate-task/ bun run build # Verify re-exports are complete bun -e import * as c from ./src/tools/delegate-task/constants; console.log(Object.keys(c).sort().join(\n))其中bun -e一行是本次策略最有价值的细节它把“barrel 是否完整”从主观判断变成了可核对的导出清单比对。文档给出的期望导出清单为原文标注 13 total实际列出 19 个符号——这个计数偏差本身就是评审时 QA 代理应抓住的小坑ARTISTRY_CATEGORY_PROMPT_APPENDCATEGORY_DESCRIPTIONSCATEGORY_PROMPT_APPENDSDEFAULT_CATEGORIESDEEP_CATEGORY_PROMPT_APPENDPLAN_AGENT_NAMESPLAN_AGENT_SYSTEM_PREPEND_STATIC_AFTER_SKILLSPLAN_AGENT_SYSTEM_PREPEND_STATIC_BEFORE_SKILLSPLAN_FAMILY_NAMESQUICK_CATEGORY_PROMPT_APPENDULTRABRAIN_CATEGORY_PROMPT_APPENDUNSPECIFIED_HIGH_CATEGORY_PROMPT_APPENDUNSPECIFIED_LOW_CATEGORY_PROMPT_APPENDVISUAL_CATEGORY_PROMPT_APPENDWRITING_CATEGORY_PROMPT_APPENDbuildPlanAgentSkillsSectionbuildPlanAgentSystemPrependisPlanAgentisPlanFamily对照当前仓库可以验证这条检查为何必要tools.test.ts 从 barrel 一次性导入DEFAULT_CATEGORIES、CATEGORY_DESCRIPTIONS、isPlanAgent、PLAN_AGENT_NAMES、isPlanFamily、PLAN_FAMILY_NAMES等符号——任何遗漏的 re-export 都会直接让这份测试在 import 阶段失败。而buildPlanAgentSystemPrepend这类函数在当前源码中仍是 barrel 的核心成员constants.ts它把“技能注入前的静态提示词 动态生成的类别/技能表格 技能注入后的静态提示词”三段拼成 plan agent 的完整系统提示词。Gate ACI阻塞门禁CI 是唯一的硬阻塞门禁用一条命令订阅其结果gh pr checks --watch策略文档依据 ci.yml 列出预期通过的 4 个 CI 项Tests (split)mock 密集型隔离测试 批量bun testTypecheckbun run typecheck即tsc --noEmitBuildbun run buildSchema auto-commit仅在检测到 schema 变更时触发文档对失败点的预判非常明确没有预期失败点因为这是纯 re-export 重构、无运行时行为变化。同时它预先写好了两类失败模式的标准排查路径避免门禁失败后临时猜测Typecheck 报错→ 缺少 re-export 或引入 import 环。修复位置在新模块内amend 提交后重推。测试报错→ 典型根因是tools.test.ts这类“从./constants导入全部符号”的测试文件要求 re-export barrel 必须完整。这个预判与仓库现状互相印证当前 constants.ts 顶部仅 3 行 import 类型/工具函数后即进入 re-export 块没有任何指向新模块的循环引用——“无 import 环”这一 CI 风险点被结构本身消解。Gate Breview-work 五代理并行评审CI 通过后调用/review-work由 5 个并行代理从不同视角验证同一份改动。这份策略文档对每个代理的具体核查项都给出了可执行的断言而非泛泛的“检查一下代码”Oracle目标/约束视角验证“向后兼容”声明成立逐一确认 13 条外部导入路径仍能解析。执行计划中为此附了完整的外部导入映射表src/agents/atlas/prompt-section-builder.ts、src/agents/builtin-agents.ts、src/plugin/available-categories.ts、src/plugin-handlers/category-config-resolver.ts、src/shared/merge-categories.ts及其测试均从../tools/delegate-task/constants导入使核查项可以逐条打勾。Oracle代码质量视角验证每文件单一职责、LOC 上限、无 catch-all 模块违规——这正是拆分constants.ts的原始动机评审需要确认拆分结果确实满足目标。Oracle安全视角确认该重构无安全影响提示词常量与名称判断逻辑不涉及权限边界。QA实机执行视角实际运行bun test src/tools/delegate-task/并确认全绿而非仅阅读 diff。Context miner上下文视角确认没有相关未关闭的 issue/PR 与本次拆分冲突。预期结论Expected verdict为Pass纯结构重构、无行为变化五个视角均无实质风险。Gate CCubic 外部 Bot 审查第三个门禁是等待外部审查机器人cubic-dev-ai[bot]在 PR 上发布 “No issues found”。策略文档对此门禁的预期管理很务实若 Cubic 提出问题大概率是误报——典型场景是对“新增文件数量多”这一客观事实的机械告警本次拆分恰好新增 4 个文件处理方式是在 PR 评论中解释而非盲目按 Bot 意见回改代码。仓库自带的 PR 生命周期技能 work-with-pr 对 Cubic 门禁有更细的信号判别规范批准信号是最新 Cubic 评论同时含**No issues found**与置信度**5/5**唯一允许“跳过”该门禁的情形是配额耗尽Bot 发布配额/用量提示或有界等待内始终未出现新评审且必须显式记录为 SKIPPED 而非静默略过。发现问题从来不是跳过的理由。Merge 策略与一处值得注意的差异策略文档给出的收尾动作是gh pr merge --squash --delete-branch git worktree remove ../omo-wt/refactor-delegate-task-constants即 squash merge 将 2 个原子提交“提取类别默认值与提示词常量”、“提取 plan agent 提示词与名称”折叠为 dev 分支上的 1 个干净提交随后移除任务专用 worktree 并清理。需要注意一个仓库规则层面的差异oh-my-openagent 自身的 work-with-pr 技能 明确写道“This repository requires merge commits. Never use --squash or --rebase”并给出默认命令gh pr merge $PR_NUMBER --merge --auto --delete-branch自动合并门禁全绿后由 GitHub 落地。因此若在当前仓库实际执行该验证策略合并方式应服从仓库的 merge commit 规则而策略文档中“两个原子提交折叠为一个”的叙述可替换为“保留原子提交历史、以 merge commit 并入 dev”。worktree 清理、失败时保留 worktree 供人工检查等配套纪律则不受影响。小结可复用的验证策略骨架把这份文档抽象出来它对“纯结构重构类 PR”给出了一个可直接复用的四段式骨架本地预检typecheck 定向测试 build 之外加一条bun -e动态导出比对把 barrel 完整性从主观判断变成清单核对CI 门禁事先列出预期通过的 CI 项与最可能的两类失败模式让失败后的定位成本趋近于零多代理评审每个评审代理绑定一条可执行断言导入路径数、LOC 上限、实机测试命令、冲突 issue 扫描避免“看起来没问题”式的空洞评审外部 Bot预先区分真问题与误报并把“配额耗尽→SKIPPED”与“发现问题→必须修复”两种终态严格分开。这套策略的价值不在于命令本身而在于它把“验证”从 PR 合并前的被动等待变成了一组在 push 之前就已写死、可逐项核对的断言——对任何“无行为变更”声明型改动这都是比多跑一轮测试更有说服力的证明方式。【免费下载链接】oh-my-openagentOmO: Drop your tokens. Ultrawork. Done.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-openagent 纯结构重构 PR 的三层验证策略：以 delegate-task 常量拆分为例
oh-my-openagent 纯结构重构 PR 的三层验证策略以 delegate-task 常量拆分为例【免费下载链接】oh-my-openagentOmO: Drop your tokens. Ultrawork. Done.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent本文以 oh-my-openagent 仓库中一份真实的 PR 验证策略文档为主体完整还原“本地预检 → CI 门禁 → 多智能体评审 → 外部 Bot”的四步验证链路并以delegate-task/constants.ts的模块化拆分为具体案例讲解每个门禁要检查什么、失败时如何定位以及“纯重构不改变运行时行为”这一声明如何被逐项证明。背景为什么“纯重构”也需要专门的验证策略该策略文档verification-strategy.md服务于一次结构性重构将 oh-my-openagent 中 654 行、承载 4 种职责的constants.ts拆分为聚焦单一职责的小模块。其执行计划execution-plan.md给出的拆分方案是新文件职责约 LOCdefault-categories.tsDEFAULT_CATEGORIES、CATEGORY_DESCRIPTIONS~40category-prompt-appends.ts8 个*_CATEGORY_PROMPT_APPEND常量 CATEGORY_PROMPT_APPENDS记录~300提示词文本豁免 LOC 限制plan-agent-prompt.tsPlan agent 系统提示词常量 构造函数~250提示词文本豁免plan-agent-names.tsPLAN_AGENT_NAMES、isPlanAgent、PLAN_FAMILY_NAMES、isPlanFamily~30constants.ts更新从 4 个新文件 re-export保持向后兼容~5向后兼容通过两条路径保证constants.tsre-export 全部 4 个新文件的内容index.ts已有的export * from ./constants保持不变。从当前仓库源码看该策略的向后兼容思路已体现在 index.ts 中export * from ./constants而当前的 constants.ts 顶部已采用“re-export barrel”形态把BUILTIN_CATEGORY_REQUIRES_MODEL、CATEGORY_DESCRIPTIONS、CATEGORY_PROMPT_APPENDS、CATEGORY_PROMPT_APPEND_RESOLVERS、DEFAULT_CATEGORIES统一从./builtin-categories转出。从源码结构看实际落地的文件命名如builtin-categories.ts与计划稿中的 4 文件方案存在演进差异但“原路径继续可用、新增模块只负责实现”的兼容策略是一致的。纯重构的验证核心难题在于“无行为变更”是一个声明不是事实。策略文档因此把验证拆成逐层递进的门禁每层只回答一个问题编译是否通过现有消费者是否被破坏结构是否满足拆分目标外部视角有无遗漏第一层Pre-Gate 本地验证Push 之前策略要求在推送前于 worktree 内跑完与 CI 相同的关键检查外加一条专门针对 re-export 完整性的动态导出检查# In worktree bun run typecheck bun test src/tools/delegate-task/ bun run build # Verify re-exports are complete bun -e import * as c from ./src/tools/delegate-task/constants; console.log(Object.keys(c).sort().join(\n))其中bun -e一行是本次策略最有价值的细节它把“barrel 是否完整”从主观判断变成了可核对的导出清单比对。文档给出的期望导出清单为原文标注 13 total实际列出 19 个符号——这个计数偏差本身就是评审时 QA 代理应抓住的小坑ARTISTRY_CATEGORY_PROMPT_APPENDCATEGORY_DESCRIPTIONSCATEGORY_PROMPT_APPENDSDEFAULT_CATEGORIESDEEP_CATEGORY_PROMPT_APPENDPLAN_AGENT_NAMESPLAN_AGENT_SYSTEM_PREPEND_STATIC_AFTER_SKILLSPLAN_AGENT_SYSTEM_PREPEND_STATIC_BEFORE_SKILLSPLAN_FAMILY_NAMESQUICK_CATEGORY_PROMPT_APPENDULTRABRAIN_CATEGORY_PROMPT_APPENDUNSPECIFIED_HIGH_CATEGORY_PROMPT_APPENDUNSPECIFIED_LOW_CATEGORY_PROMPT_APPENDVISUAL_CATEGORY_PROMPT_APPENDWRITING_CATEGORY_PROMPT_APPENDbuildPlanAgentSkillsSectionbuildPlanAgentSystemPrependisPlanAgentisPlanFamily对照当前仓库可以验证这条检查为何必要tools.test.ts 从 barrel 一次性导入DEFAULT_CATEGORIES、CATEGORY_DESCRIPTIONS、isPlanAgent、PLAN_AGENT_NAMES、isPlanFamily、PLAN_FAMILY_NAMES等符号——任何遗漏的 re-export 都会直接让这份测试在 import 阶段失败。而buildPlanAgentSystemPrepend这类函数在当前源码中仍是 barrel 的核心成员constants.ts它把“技能注入前的静态提示词 动态生成的类别/技能表格 技能注入后的静态提示词”三段拼成 plan agent 的完整系统提示词。Gate ACI阻塞门禁CI 是唯一的硬阻塞门禁用一条命令订阅其结果gh pr checks --watch策略文档依据 ci.yml 列出预期通过的 4 个 CI 项Tests (split)mock 密集型隔离测试 批量bun testTypecheckbun run typecheck即tsc --noEmitBuildbun run buildSchema auto-commit仅在检测到 schema 变更时触发文档对失败点的预判非常明确没有预期失败点因为这是纯 re-export 重构、无运行时行为变化。同时它预先写好了两类失败模式的标准排查路径避免门禁失败后临时猜测Typecheck 报错→ 缺少 re-export 或引入 import 环。修复位置在新模块内amend 提交后重推。测试报错→ 典型根因是tools.test.ts这类“从./constants导入全部符号”的测试文件要求 re-export barrel 必须完整。这个预判与仓库现状互相印证当前 constants.ts 顶部仅 3 行 import 类型/工具函数后即进入 re-export 块没有任何指向新模块的循环引用——“无 import 环”这一 CI 风险点被结构本身消解。Gate Breview-work 五代理并行评审CI 通过后调用/review-work由 5 个并行代理从不同视角验证同一份改动。这份策略文档对每个代理的具体核查项都给出了可执行的断言而非泛泛的“检查一下代码”Oracle目标/约束视角验证“向后兼容”声明成立逐一确认 13 条外部导入路径仍能解析。执行计划中为此附了完整的外部导入映射表src/agents/atlas/prompt-section-builder.ts、src/agents/builtin-agents.ts、src/plugin/available-categories.ts、src/plugin-handlers/category-config-resolver.ts、src/shared/merge-categories.ts及其测试均从../tools/delegate-task/constants导入使核查项可以逐条打勾。Oracle代码质量视角验证每文件单一职责、LOC 上限、无 catch-all 模块违规——这正是拆分constants.ts的原始动机评审需要确认拆分结果确实满足目标。Oracle安全视角确认该重构无安全影响提示词常量与名称判断逻辑不涉及权限边界。QA实机执行视角实际运行bun test src/tools/delegate-task/并确认全绿而非仅阅读 diff。Context miner上下文视角确认没有相关未关闭的 issue/PR 与本次拆分冲突。预期结论Expected verdict为Pass纯结构重构、无行为变化五个视角均无实质风险。Gate CCubic 外部 Bot 审查第三个门禁是等待外部审查机器人cubic-dev-ai[bot]在 PR 上发布 “No issues found”。策略文档对此门禁的预期管理很务实若 Cubic 提出问题大概率是误报——典型场景是对“新增文件数量多”这一客观事实的机械告警本次拆分恰好新增 4 个文件处理方式是在 PR 评论中解释而非盲目按 Bot 意见回改代码。仓库自带的 PR 生命周期技能 work-with-pr 对 Cubic 门禁有更细的信号判别规范批准信号是最新 Cubic 评论同时含**No issues found**与置信度**5/5**唯一允许“跳过”该门禁的情形是配额耗尽Bot 发布配额/用量提示或有界等待内始终未出现新评审且必须显式记录为 SKIPPED 而非静默略过。发现问题从来不是跳过的理由。Merge 策略与一处值得注意的差异策略文档给出的收尾动作是gh pr merge --squash --delete-branch git worktree remove ../omo-wt/refactor-delegate-task-constants即 squash merge 将 2 个原子提交“提取类别默认值与提示词常量”、“提取 plan agent 提示词与名称”折叠为 dev 分支上的 1 个干净提交随后移除任务专用 worktree 并清理。需要注意一个仓库规则层面的差异oh-my-openagent 自身的 work-with-pr 技能 明确写道“This repository requires merge commits. Never use --squash or --rebase”并给出默认命令gh pr merge $PR_NUMBER --merge --auto --delete-branch自动合并门禁全绿后由 GitHub 落地。因此若在当前仓库实际执行该验证策略合并方式应服从仓库的 merge commit 规则而策略文档中“两个原子提交折叠为一个”的叙述可替换为“保留原子提交历史、以 merge commit 并入 dev”。worktree 清理、失败时保留 worktree 供人工检查等配套纪律则不受影响。小结可复用的验证策略骨架把这份文档抽象出来它对“纯结构重构类 PR”给出了一个可直接复用的四段式骨架本地预检typecheck 定向测试 build 之外加一条bun -e动态导出比对把 barrel 完整性从主观判断变成清单核对CI 门禁事先列出预期通过的 CI 项与最可能的两类失败模式让失败后的定位成本趋近于零多代理评审每个评审代理绑定一条可执行断言导入路径数、LOC 上限、实机测试命令、冲突 issue 扫描避免“看起来没问题”式的空洞评审外部 Bot预先区分真问题与误报并把“配额耗尽→SKIPPED”与“发现问题→必须修复”两种终态严格分开。这套策略的价值不在于命令本身而在于它把“验证”从 PR 合并前的被动等待变成了一组在 push 之前就已写死、可逐项核对的断言——对任何“无行为变更”声明型改动这都是比多跑一轮测试更有说服力的证明方式。【免费下载链接】oh-my-openagentOmO: Drop your tokens. Ultrawork. Done.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考