OmX 可复现 Bug 包Reproducible Bug Package模板实战指南从 issue 到工作树的确定性治理【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex导读本文围绕 OmXOh My codeX在 docs/pipeline/templates/triage/reproducible-bug-package.md 中定义的可复现 Bug 包模板展开讲解当一份 bug 报告被确认可复现、可直接执行后如何把它固化为一个带有稳定package_id的 OMX 工作包绑定分支、创建 git worktree、启动唯一一个可变更mutating运行时会话并逐一通过 mutation gate。读完本文你将掌握从 issue 分类到ready状态落地、再到后续执行与合并决策的完整链路以及如何在公开工件中避免泄露密钥与内部拓扑。模板定位triage 决策树中的一个分支在 OmX 的公开流水线中docs/pipeline/templates/README.md 将模板分为两类triage 模板docs/pipeline/templates/triage/issue 常见处置结果的评论模板execution 模板docs/pipeline/templates/execution/package、plan、result、review、merge 五类生命周期工件。reproducible-bug-package.md属于前者它代表 triage 决策树中的一个分支当分类器判定报告为 bug 且已具备可复现证据时直接进入包创建流程。与之并列的分支还包括needs-repro-question.md报告缺少最小复现细节需向提交者索要能复现问题的最小精确命令/提示词及其输出并补充oh-my-codex版本、OS/shell、Node.js 版本等环境事实且在超时前无跟进则可能被关闭duplicate-close.md判定为重复 issue关闭并引导讨论汇聚到 canonical issuefeature-contract-proposal-gate.md功能/契约提案需维护者确认用户问题、受影响 CLI/API/docs 面、兼容性与迁移路径、验证计划等在 gate 通过前不得创建可变更 worktree。也就是说只有在复现细节齐备、被判定为真正 bug 时才应使用本文主题模板把可复现这个判定结果固化为可执行的包。模板全文与逐字段解读模板正文由两部分组成YAML 包身份块与 mutation gate 清单。package_id: issue-0000-short-slug branch: fix/issue-0000-short-slug worktree: ../oh-my-codex-worktrees/issue-0000-short-slug omx_session: issue-0000-short-slug state: ready各字段含义如下字段作用取值约定package_id包的稳定身份标识贯穿整个生命周期通常为issue-number-short-slug如issue-1234-repro-timeoutbranch该包对应的 git 分支推荐fix/issue-0000-short-slug前缀表达变更类型fix/docs/feat等worktree确定性工作树路径路径中必须包含package_id例如../oh-my-codex-worktrees/issue-0000-short-slugomx_session运行时标签标识由哪个会话负责变更实现相关但包工件必须记录哪个运行时执行了 mutationstate包状态模板中落定为ready表示包身份已存在且尚未开始变更state的取值空间在 docs/pipeline/templates/issue-package-identity.md 中有完整定义intake | needs_repro | duplicate | proposal | ready | executing | review | merge_ready | merged | closed。本模板默认把状态写到ready正是因为前面的 triage 流程已经完成了 intake、去重、复现与风险评估剩下的就是等待一个可变更运行时认领。mutation gate 是模板的第二部分也是能否真正动手改代码的准入门槛Duplicate search completed.Reproduction steps are present in the issue.Risk level recorded.Exactly one mutating runtime is assigned to the worktree.Package artifact exists or will be committed with the implementation.其中Exactly one mutating runtime恰好一个可变更运行时是 OmX 流水线最核心的安全不变量观察者与评审者可以并发读取但同一时刻只允许一个会修改状态的运行时拥有某个 worktree。这一约束在 docs/pipeline/github-pr-package-identity.md 中被明确为公共契约any state-changing action must pass an explicit gate. Only one active mutating runtime may own a worktree at a time; observers and reviewers may read concurrently.在整条流水线中的位置从 issue 到 worktree 的完整链路reproducible-bug-package.md不是孤立模板它处于 docs/pipeline/github-pr-package-identity.md 定义的六步流水线的第三步Package identity与第四步Worktree/session/branch mapping的交界处。完整链路如下IntakeGitHub/Discord接受 GitHub issue 与可选的 Discord/社区线程报告外部上下文需要时镜像到 GitHub issue用 issue-package-identity.md 记录 canonical 身份。Classify、去重、复现与风险门将报告分类为 bug、feature/contract proposal、duplicate、support question 或 invalid/spam创建包前先搜索既有 issue 与 PRbug 报告不可操作时索要最小复现在可变更运行时启动前应用风险门分支目标、受影响面、预期测试、是否涉及凭据或破坏性命令。Package identity为可操作工作创建稳定package_id通常issue-number-short-slug把包绑定到一个 repo、一个 issue、一个分支、一个 worktree、可选的线程引用。Worktree/session/branch mapping分支格式kind/issue-number-short-slugworktree 是包含package_id的确定性路径如../oh-my-codex-worktrees/package_idOMX session 是包含或关联package_id的运行时标签。Execution artifactspackage.md记录身份、范围、门与状态plan.md记录计划变更与验证execution-result.md记录变更内容与证据review.md记录评审发现与批准/拒绝merge-decision.md记录最终门结果。PR、review 与 merge gatesPR 面向约定基分支通常dev链接 issue 与包工件评审检查可追溯性、验证、风险与单 owner 的 worktree mutation只有验证证据与评审批准齐备后才允许合并。本模板正是第 2 步复现成功与第 34 步创建包、绑定工作树之间的桥梁分类器确认可复现后协调器coordinator据此创建包并给 issue 回帖回帖内容就是这个模板。源码级佐证协调器如何消费本模板在 docs/pipeline/github-pr-package-identity.md 的协调器骨架代码中可以清楚看到本模板的实际消费方式。当intakeLoop收到事件后if (classification.kind bug) { await createPackageIdempotently(issue, classification); }createPackageIdempotently先通过 issue 查重幂等然后生成branch、worktree、session先过风险门再创建 worktree 并写入package.md最后把本模板作为评论贴回 issueconst branch fix/${packageId}; const worktree ../oh-my-codex-worktrees/${packageId}; const session tmux-or-omx-${packageId}; await requireGate(risk, { issue: issue.number, packageId, risk: classification.risk, mutationOwner: session }); await run(git fetch origin dev); await run(git worktree add ${shellQuote(worktree)} -b ${shellQuote(branch)} origin/dev); await writeTemplate(${worktree}/package.md, execution/package.md, { source: github, repo: issue.repo, issue: issue.number, package_id: packageId, branch, worktree, discord_thread: n/a, state: ready, }); await commentFromTemplate(issue, triage/reproducible-bug-package.md, { packageId, branch, worktree, session });注意其中的幂等设计findPackageByIssue若发现该 issue 已存在包则直接返回避免重复创建。随后调度是显式的——协调器记录它要求运行时执行的命令并把OMX_PACKAGE_ID通过环境变量注入const command OMX_PACKAGE_ID${packageId} omx team 1:executor ${shellQuote(prompt)}; await runInWorktree(worktree, command); await recordDispatch(issue, { command, worktree, branch, packageId });这印证了模板中Exactly one mutating runtime的落地方式通过omx team 1:executor恰好派发一个执行器会话且派发命令被持久化记录可供后续审计。手工创建可复现 Bug 包的完整命令序列仓库提供的 docs/pipeline/github-pr-package-identity.md 还给出了不依赖协调器脚本、可手工执行的一组等价命令以下为适配说明需按实际环境替换占位值# 1. 拉取基分支创建确定性 worktree包身份绑定分支 git fetch origin dev git worktree add ../oh-my-codex-worktrees/issue-2087-pipeline-templates \ -b docs/issue-2087-pipeline-templates origin/dev # 2. 在 worktree 内启动恰好一个可变更运行时并记录该命令 cd ../oh-my-codex-worktrees/issue-2087-pipeline-templates OMX_PACKAGE_IDissue-2087-pipeline-templates \ omx team 1:executor Implement issue-2087; keep package artifacts current. # 3. 验证证据齐备后创建 PR gh pr create --base dev --head docs/issue-2087-pipeline-templates \ --title docs: add issue package pipeline templates \ --body-file .github/pr-body.md这套命令与模板字段一一对应git worktree add的路径对应该worktree字段-b分支对应branch字段OMX_PACKAGE_ID环境变量对应package_id与omx_session。原文档明确提示这些示例是占位符应适配环境中可用的公开 CLI 命令并把实际执行的命令记录进package.md或execution-result.md——因为聊天只是协调提示不是真相真相存在于 GitHub issue、PR 与提交到分支/附加到 issue 的包工件中。Mutation Gate 背后的运行时权威机制模板中的 mutation gate 并非空泛的清单它与 OmX Rust 运行时的权威authority语义一一对应。在 runtime-authority-backlog-replay-readiness.md 中定义了如下约束运行时最多持有一个有效的权威租约authority lease租约包含owner、lease_id、leased_until过期的租约必须先标记为 stale之后才允许授予其他 owner 权威AuthorityLease位于 crates/omx-runtime-core/src/authority.rs实现三态机acquire无租约或同 owner 续持才成功否则返回AlreadyHeldByOther、renew仅同 owner 可续租、force_release无条件清空所有租约字段derive_readiness()位于 crates/omx-runtime-core/src/engine.rs只有在租约持有且未过期、且没有待重放事件时才返回ReadinessSnapshot::ready()。这解释了为何模板要求恰好一个 mutating runtime底层运行时以租约机制强制实现同一 worktree 的单一写者。若第二个运行时尝试acquire会因为AlreadyHeldByOther而失败观察者与评审者则始终被允许并发读取。换句话说模板的勾选项是上层契约Rust 运行时的 AuthorityLease 是其机械保证。与其他模板的配合使用一个完整的可复现 Bug 包在生命周期中会依次用到多个模板本模板只是起点execution/package.md包的正式工件包含 Identity与本模板同源的 YAML、Scope问题/范围内/范围外、Gates去重、复现或提案契约、风险门、单一 mutating runtime、无密钥泄露与 Runtime ownershipmutation 会话、开始时间、释放时间四节。协调器在git worktree add后立即把package.md写入 worktree状态为readyexecution/plan.md记录计划变更与验证方式execution/execution-result.md记录实际变更与证据execution/review.md 与 execution/merge-decision.md记录评审结论与最终合并决策。整个生命周期中state依序流转ready → executing → review → merge_ready → merged/closed而issue-package-identity.md规定只有对应的 gate 或工件被记录后才允许更新state。安全与合规边界OmX 流水线对公开工件有严格的边界要求使用本模板时需注意公开作用域docs/pipeline/templates/下的模板与流水线契约可以安全地复制、评审并随仓库版本化但 webhook 监听器、Discord bot、队列 worker、凭据存储、部署目标与调度器内部均处于契约之外不得在公开文档中记录密钥、主机名、队列名、token、私有频道或运维拓扑身份块中的线程引用discord_thread可以是n/a或公开安全的引用但严禁包含私有频道 ID 或 token真相模型聊天消息只是协调提示真相以 GitHub issue、PR 与包工件为准合并前检查PR 必须链接 issue 与包工件、验证证据必须是当前的、评审决策必须被记录、合并决策必须声明该 PR 是否关闭 issue。对应到本模板的 gate 清单即Package artifact exists or will be committed with the implementation——包工件要么已存在要么随实现一同提交确保任何公开面都不会丢失可追溯性。总结reproducible-bug-package.md是一份小而关键的 triage 模板它以 YAML 身份块把可复现 bug固化为有稳定package_id的 OMX 工作包以 mutation gate 清单守住单一 mutating 运行时这一安全底线。在实际流水线中它由协调器在复现成功、风险门通过后自动回帖并触发 worktree 创建与package.md、plan.md、execution-result.md、review.md、merge-decision.md共同构成从 issue 到合并的完整可追溯链路。对于维护者掌握本模板即掌握了让一个 bug 报告变成一份可执行、可审计、可安全并行的工作包的标准化操作。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考