企业官网建设流程全解析

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 关闭模板，系统讲解 OmX（oh-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.

这段模板承担三个明确职能：

1. 宣告关闭原因：明确指出关闭是因为"请求的复现细节未在超时窗口内提供"，而不是因为问题不存在或不受欢迎；
2. 给出重新打开路径：说明提交者仍可开新 issue 或请求 reopen，但必须携带四类可执行证据；
3. 确立证据门槛：聊天上下文（chat context）单独不足以重新打开，GitHub issue 本身必须包含可操作证据。

该模板只用于"曾被打上needs-repro标签、但超时后仍无有效复现信息"的 issue，其前置步骤由 needs-repro-question.md 触发，二者构成一条完整的"索要复现 → 等待 → 关闭"链路。

前置步骤：needs-repro 提问模板

在超时关闭之前，分诊方应先在 issue 上留下 needs-repro-question.md：

Thanks 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的对应关系一目了然：

两个模板共同体现一个设计原则："最小复现命令 + 脱敏日志"是 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 时提供以下四类证据，缺一不可：

1. exact command or prompt——精确到能逐字执行的最小命令或提示词。这是复现的最核心输入，呼应 needs-repro 模板中"smallest exact command or prompt that reproduces the problem"；
2. environment details——仅限运行该命令所需的环境事实，参照 needs-repro 模板的示例：oh-my-codex版本、OS/shell、Node.js 版本。模板在提问阶段就要求"include only the environment facts needed"，因此关闭阶段的环境信息要求同样克制，避免泄露敏感拓扑；
3. expected vs actual behavior——期望行为与实际行为的对照。这与流水线的验证文化一致：plan.md记录计划变更与验证方式，execution-result.md记录"改了什么 + 证据"，issue 层面的复现同样要求"预期 vs 实际"的可判定差异；
4. 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 中"这一硬性条件，而聊天记录无法承担该条件。

维护者实操建议

将本模板落地到自己项目的分诊流程时，建议保持如下纪律：

1. 先问后关：任何timeout-close之前，必须已有 needs-repro-question.md 的提问记录，并确认超时窗口已过；
2. 保留可追溯性：关闭评论沿用模板原文，明确"超时 + 证据缺失"双重原因，避免被误解为对问题真实性的否定；
3. 统一 reopen 口径：reopen 请求一律按四类证据清单核验，缺失任何一类即维持关闭状态；
4. 与状态机对齐：在 issue/package 工件中同步更新state字段，遵循"只在对应门禁或工件被记录后才更新状态"的约定；
5. 公开模板不泄密：模板与评论内容只承载公开安全信息，私密编排细节一律留在外部胶水层。

小结

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