next-ticket

next-ticket

找到 ticket 存储处，读取它，选出一个 ticket。该存储处遵循 ticket 约定（../ticket-up/references/TICKET_CONVENTION.md——如果上下文中尚未包含约定，就读取它）；Ticket 所处的每种状态以及它经历的每次变更，包括挑选和认领，都遵循 ../ticket-up/references/AUTOMATED_EXECUTION.md 中的 Transitions 章节——也要读取该章节。

查找存储处。 读取 tickets/store-config.md——其中应指定一个固定的、相对于仓库的位置，说明存储处在哪。如果配置指定 GitHub 作为存储位置，那么存储处就是该仓库中归属于各 effort 跟踪 issue 的 issues；应查询，而不是读取文件。如果项目有意将存储处放在其他地方，则其上下文文件会说明这一点；运行时该文件已加载。若两者皆无，先查找，再提问：如果任何地方都不存在存储处，就直说，并说明让存储处出现的两种方式——对已完成的 manifest 运行 ticket-up，或按照约定手动编写 tickets——因为尚未跟踪任何工作的项目需要的是一个存储处，而不是关于要选哪种方式的问题。如果找到了存储处，不要假定它属于哪种类型，即使眼前就有 tickets/<effort>/ 目录也不要假定，因为项目将存储处迁至跟踪工具后，通常仍会保留这些目录。提出问题时展示你找到的内容，让对方能轻松作答，并将答案写入 tickets/store-config.md，避免重复询问。

确定候选范围。 不带参数的调用应直接作答，而不是询问要选哪个 effort。如果对话已经围绕某个 effort 展开，就限定在该 effort 内。如果存储处明确指定了 effort 顺序，就采用该顺序；这是明确的操作策略，优先于默认规则。否则，从存储处本身列出所有有未关闭 Tickets 的 effort——文件存储处中的 tickets/<effort>/，或在 GitHub 中一次查询未关闭 issues 并查看 effort 标签——并一并比较它们已就绪的 Tickets。读取每个相关 effort 的前置文件中的目标地和优先级覆盖设置，据此判断延迟造成的损失是否与该 effort 期望抵达的目标相符。

当候选项涉及多个 effort，且项目有 North Star（位于仓库根目录的 NORTH_STAR.md，或项目上下文文件指定的其他位置）时，读取其中的目标、衡量指标和原则：即 Goal、How we know 和 Principles 章节；如果 North Star 采用较旧的九字段格式，则读取 Winning, and the number watched 和 Never 字段。目标及其衡量指标用于评估各 effort 的目标地，这是前置文件本身未提供的跨 effort 衡量依据；如果某个候选项的工作会违背某项原则，应指出这一冲突，而不是选出它。若参考了 North Star，说明选择理由时要提及。没有 North Star，或其目标和衡量指标仍为空时，严格按照下文进行比较；在单个 effort 内，无论如何都不改变。

每次挑选时都要读取策略标记，无论候选范围如何。如果项目的 North Star 列出了当前生效且带有标记的策略选择——即标题后有 Revisit when 条件——就到其指定的来源处读取每个条件。如果某个条件看起来已满足，就报告该选择的记录标题，说明负责人可能会想重新审视该选择；如果无法读取某个条件的来源，就连同该来源一起报告。选择 Ticket 并不意味着要修改策略：应报告证据，交由负责人或已指派的代表处理；不要更改记录或列表。 按延误损失选择。 仅从范围内的开放集选取候选项，并只保留符合 Transitions 定义的已就绪 Ticket；每次选择时，都要读取每个延期 Ticket 的 Revisit when 来源。对于来源无法读取的每个延期 Ticket，在报告中写明其名称及来源。选择过程绝不修改该字段；要更改它，需要单独进行分配并具备相应授权，不能仅凭观察其来源来更改。只有在显式优先级覆盖需要将其作为排序依据时，才读取有界的近期已关闭历史，包括文件存储中的 done/ 归档。Ticket 是其所在载体为它保存的所有内容，而不仅是条目正文；载体引用会列出这些内容所在的位置。要完整阅读每个候选项，而不仅是看起来有竞争力的那些——附加上下文也会影响 Ticket 的排序，因此只为领先候选项阅读上下文，会让排序本身决定哪些信息能影响排序。适用明确的存储或工作量优先级覆盖，并遵循其适用范围；否则采用该约定的预期延误损失规则。比较最强的候选项，判断在各自等待对方受限的人力关注期间，会损失多少项目价值。考虑持续发生或即将到期的损害、更晚才开始的持久收益、最早有用启动时间确实会因此推迟的下游工作，以及会使重要决策恶化或推迟的延后信息。不要将这些因素转换成保存下来的分数。

此选择器分配的是一次人类加 AI 会话，而不是由人独立完成实现。只估算解决依赖人类的未知因素、审美判断或授权所需的交互式人力关注；AI 后续可继续进行的常规实现不计入。不要根据传统功能规模推断耗时，也不要套用固定的 Agent 速度倍数。如果合理的耗时都很短，且彼此差异不会实质性改变延误损失，就视为相同；较短的工作仅作为平局时的决胜因素。延续已经开始的工作也仅作为平局时的决胜因素。

Auto 不是内在优先级。只有项目上下文或已配置的自动化表明，足够快就能用到无人值守资源来处理该 Ticket 时，Auto 才有影响。在这种情况下，需要人类交互且价值相近的工作，可以优先于无人值守执行器能处理的 Auto 工作；但绝不硬性偏好非 Auto 工作，如果 Auto Ticket 的延误损失更大，它仍然胜出。仅凭 Auto 只能证明有授权，不能证明执行器确实存在。类型绝不是选择依据。

写明唯一的首选 Ticket：其标题、种类（shaped 表示构建；question 表示先查明问题）、是否带有 Auto 授权（granted 表示无人值守自动化可以端到端处理；ungranted 表示自动化最多只能处理到已就绪的拉取请求，之后由人员完成并合并）、若带有类型则写明其类型（若不带类型，则明确说明），并用一句话说明为何选择它，依据必须是使其排名第一的具体延误损失或明确的优先级覆盖。切勿编造数值分数来证明选择合理。 先认领，再汇报。 将认领作为选择 Ticket 的一部分写下来——添加一行 Claimed by:、指定负责人，或使用场地的等效方式——并直接报告已完成，而不是先询问。正是这一步写入，才会让两个会话选择不同的 Ticket：就绪规则已将已认领的 Ticket 视为有人接手，因此，若选择时不留下记录，所有读取此存储的读者都会选中同一个 Ticket。在每个场地都要认领，包括无法让认领持续生效的场地；并说明你刚才做了什么，不要暗示场地能做到它实际上做不到的事——在共享跟踪器上，认领对所有人都有效；而在文件存储中，认领只是记录意向，供下一个查看此检出内容的人参考，其他位置的工作者则看不到它。按照 Transitions 中的 Pick 行所述方式写入认领：如果将认领写成存储配置的自动化身份——即无人值守运行时使用的认领账号——就会看起来像一次中断的无人值守尝试；而无人值守工作会在用户正在处理的 Ticket 上继续。如果该行显示 Ticket 未认领，请说明原因。提供完整的 Ticket，包括附带的上下文——先前尝试的记录、某人在评论中留下的修正、已在进行中的关联工作。这些上下文是用户接手内容的一部分；只交接正文，会让用户只能靠滚动去发现这些内容，甚至可能完全发现不了。只有当这不是用户想要的 Ticket 时，才提出释放认领。不要替用户执行 Ticket、调用 run-ticket，也不要替用户选择工作流；选择与执行是分开的操作。

整理流程要说明该说明的内容。 阅读开放集合时，在报告中说明 ../ticket-up/references/TICKET_CONVENTION.md → Tidy pass 指示存储读者查看的内容，并按照其中的说明，记录并关闭每个已合并拉取请求的 Ticket。这两项都不必等到选定 Ticket，也都不是选择操作。

没有就绪项时，先检查活动范围内的每项工作，再进行报告。准确说明原因：每个开放 Ticket 都是受阻（列出阻塞边）、已延期（列出每项条件及其来源读取结果）、已认领（说明认领者），或者存储为空。只有受阻项的存储，通常意味着最有用的做法是完成或整理某项已在进行中的工作——说明关闭哪项工作能最大程度降低预期的下游延误损失，而不只是指出依赖项最多的那项。

易忽略之处

• 指出看起来已被遗弃的已认领 Ticket（“由 X 认领，尚未处理；整理流程可以释放它”），并将是否释放留给人员决定（Transitions 中的 Release a stale claim 行）。