OmX 议题超时关闭机制:基于 timeout-close 模板的可执行证据门槛与重新打开准则

发布时间:2026/9/10 21:43:57
OmX 议题超时关闭机制:基于 timeout-close 模板的可执行证据门槛与重新打开准则 OmX 议题超时关闭机制基于 timeout-close 模板的可执行证据门槛与重新打开准则【免费下载链接】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本指南围绕 timeout-close.md 这一 triage 关闭模板系统讲解 OmXoh-my-codex在 GitHub issue 分诊流程中如何以超时窗口 可执行证据作为关闭与重新打开的准入门槛。读完本文你将掌握needs-repro标签的完整生命周期、超时关闭评论的标准写法以及判定聊天上下文不足以重新打开的证据清单并能结合 github-pr-package-identity.md 落地到自己的项目流水线中。模板原文与使用场景timeout-close.md是 docs/pipeline/templates/triage/ 目录下五个 triage 结果模板之一全文如下Closing because the requested reproduction details were not provided within the timeout window.If you can still reproduce this, please open a new issue or ask to reopen with:the exact command or prompt,environment details,expected vs actual behavior,redacted logs/screenshots.Chat context alone is not enough to reopen; the GitHub issue must contain the actionable evidence.这段模板承担三个明确职能宣告关闭原因明确指出关闭是因为请求的复现细节未在超时窗口内提供而不是因为问题不存在或不受欢迎给出重新打开路径说明提交者仍可开新 issue 或请求 reopen但必须携带四类可执行证据确立证据门槛聊天上下文chat context单独不足以重新打开GitHub issue 本身必须包含可操作证据。该模板只用于曾被打上needs-repro标签、但超时后仍无有效复现信息的 issue其前置步骤由 needs-repro-question.md 触发二者构成一条完整的索要复现 → 等待 → 关闭链路。前置步骤needs-repro 提问模板在超时关闭之前分诊方应先在 issue 上留下 needs-repro-question.mdThanks for the report. I need one focused reproduction detail before this can become an executable package:What is the smallest exact command or prompt that reproduces the problem, and what output do you get?Please include only the environment facts needed to run that command (oh-my-codexversion, OS/shell, Node.js version) and redact secrets from logs. We will keep this labeledneeds-reprountil the issue can be reproduced or narrowed to a specific contract. If there is no follow-up after the timeout window, maintainers may close it as not actionable.该模板与timeout-close.md的对应关系一目了然维度needs-repro-question.md提问阶段timeout-close.md关闭阶段触发状态报告缺少最小复现细节超时窗口内未收到复现细节要求的证据最小复现命令/提示词 输出exact command/prompt、environment、expected vs actual、redacted logs/screenshots安全约束只提供运行所需环境事实日志脱敏证据必须可操作actionable状态落点打上needs-repro标签以 not actionable 关闭两个模板共同体现一个设计原则最小复现命令 脱敏日志是 issue 从报告升级为可执行软件包executable package的前提。needs-repro 模板中before this can become an executable package一句直接指向 github-pr-package-identity.md 中的流水线定位只有能复现的 issue 才会被包装成package_id进入 worktree 执行。状态机视角needs_repro → closed在 github-pr-package-identity.md 推荐的状态机中与超时关闭相关的状态为intake收到报告尚未创建软件包needs_repro疑似 bug 的报告需要确切的复现细节对应 issue-package-identity.md 中state字段的可选值之一closed无进一步工作计划。超时关闭正是needs_repro通向closed的一种合法转移另一种则是复现成功 → 创建软件包 →ready。与之并列的分诊出口还包括duplicate-close.md重复 issue重定向到规范 issue确保 package identity、branch、worktree、PR、review 历史汇聚在一处reproducible-bug-package.md复现成功进入 package/worktree/OMX session并附带五项 mutation gate 检查feature-contract-proposal-gate.md功能/契约提案等待维护者确认契约后再动工。从源码结构看timeout-close.md属于不进入 mutation 路径的兜底出口它关闭的是证据缺失的 issue而非经过风险门禁的工作包。流水线中的协调器骨架也印证了这一点——分诊循环intake loop只在needsRepro时调用 needs-repro 模板并打标签随后等待上报者补充信息if (classification.needsRepro) { await commentFromTemplate(issue, triage/needs-repro-question.md, classification); await label(issue, [needs-repro]); continue; }超时后没有任何commentFromTemplate之外的状态变更操作——关闭动作由维护者按模板手动完成不自动创建 worktree也不绑定任何 mutation runtime这符合 github-pr-package-identity.md 中任何改变状态的动作都必须经过显式门禁的变更安全mutation safety原则。重新打开的四类证据清单模板明确要求 reopen 时提供以下四类证据缺一不可exact command or prompt——精确到能逐字执行的最小命令或提示词。这是复现的最核心输入呼应 needs-repro 模板中smallest exact command or prompt that reproduces the problemenvironment details——仅限运行该命令所需的环境事实参照 needs-repro 模板的示例oh-my-codex版本、OS/shell、Node.js 版本。模板在提问阶段就要求include only the environment facts needed因此关闭阶段的环境信息要求同样克制避免泄露敏感拓扑expected vs actual behavior——期望行为与实际行为的对照。这与流水线的验证文化一致plan.md记录计划变更与验证方式execution-result.md记录改了什么 证据issue 层面的复现同样要求预期 vs 实际的可判定差异redacted logs/screenshots——脱敏后的日志或截图。脱敏redact贯穿整个流水线协调器骨架与安全清单均要求public artifacts 中不得出现 secret、credential、private URL、queue name 或 host-specific topology。为什么 chat context 不足为凭模板最后一句Chat context alone is not enough to reopen并非随意设定而是流水线truth model的必然推论。 github-pr-package-identity.md 明确写道Truth model:chat messages are coordination hints, not truth. The truth lives in GitHub issues, pull requests, and package artifacts committed to branches or attached to issues/PRs.聊天消息只是协调提示不是事实来源事实存于 GitHub issue、PR 和提交到分支或挂载于 issue/PR 的软件包工件中。因此若复现证据只存在于聊天记录如 Discord 线程而未落到 GitHub issue就无法成为后续维护者可审计、可追溯的证据自然不足以 reopen。模板要求the GitHub issue must contain the actionable evidence正是把 truth model 落到了分诊动作上。在流水线中的完整应用timeout-close.md不是孤立文本它是 docs/pipeline/templates/README.md 所定义的GitHub / PR / package identity 流水线中公开可复制的一部分模板与工作流契约可以安全地复制、评审并纳入仓库版本管理外部编排胶水webhook 监听器、bot、队列 worker、凭据存储等不在此契约范围内所有公开模板都应避免写入密钥与内部编排细节——聊天可以汇总状态但 GitHub issues、PRs 与软件包工件才是 source of truth。在 issue-package-identity.md 的身份块中state字段的可选值包括needs_repro、closed等配合规范写法source: github # github | discord | other repo: Yeachan-Heo/oh-my-codex issue: 0000 package_id: issue-0000-short-slug branch: kind/issue-0000-short-slug worktree: ../oh-my-codex-worktrees/issue-0000-short-slug discord_thread: n/a state: intake # intake | needs_repro | duplicate | proposal | ready | executing | review | merge_ready | merged | closed当一个 issue 被以timeout-close关闭时其状态应为closed若日后携可执行证据 reopen 并经复现成功再按 reproducible-bug-package.md 的 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.这五个勾选项进一步说明了为什么聊天上下文不被接受reopen 后要立即满足复现步骤在 issue 中这一硬性条件而聊天记录无法承担该条件。维护者实操建议将本模板落地到自己项目的分诊流程时建议保持如下纪律先问后关任何timeout-close之前必须已有 needs-repro-question.md 的提问记录并确认超时窗口已过保留可追溯性关闭评论沿用模板原文明确超时 证据缺失双重原因避免被误解为对问题真实性的否定统一 reopen 口径reopen 请求一律按四类证据清单核验缺失任何一类即维持关闭状态与状态机对齐在 issue/package 工件中同步更新state字段遵循只在对应门禁或工件被记录后才更新状态的约定公开模板不泄密模板与评论内容只承载公开安全信息私密编排细节一律留在外部胶水层。小结timeout-close.md虽短却是 OmX 议题流水线证据纪律的收口动作它以超时窗口划定等待边界以四类可执行证据定义重新打开门槛以chat context 不足为凭呼应流水线的 truth model。将它与其上游 needs-repro-question.md、状态机定义 github-pr-package-identity.md 以及身份模板 issue-package-identity.md 配合使用即可在任意仓库复制一套可复现才可执行、无证据即关闭的分诊闭环。【免费下载链接】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),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询