ticket-up

ticket-up

ticket-up 是创建 Ticket 的唯一入口。它负责梳理文案、应用规范、去重，并通过项目配置的渠道呈现结果。

输出前请阅读 references/TICKET_CONVENTION.md。该文档定义了每个渠道都必须遵循的单元、类型、结构、生命周期和优先级。

解析输入并确定 Ticket 单元

接受以下任意一种输入：

• 已完成的 Manifest；
• 应纳入存储的直接工作请求；
• 一个或多个需要分别管理的问题；
• 运行源 Ticket 时发现的事项，并注明该源 Ticket。

如果没有明确输入，仅当对话已表明某个近期 Manifest 是预期来源时才使用它；否则，询问用户要将什么创建为 Ticket。

一个 Ticket 代表一个可独立安排的生命周期。将共享同一结果、并会被一并分配、排定优先级和关闭的工作合并在一起。只有当分别管理所有权、优先级、阻塞关系或关闭状态确有价值时才拆分。不要把每个 Deliverable、问题或细微发现都变成 Ticket。

是否拆分是一个问题；拆分点在哪里是另一个问题。无论输入是什么，第二个问题的答案都应遵循同一原则。拆分产生的每个 Shaped Ticket 都应是一个可独立端到端验证的切片——能够在其适用场景中运行、阅读或以其他方式评判，而不只是确认它存在。沿实现层拆分 Ticket（“架构”“端点”“界面”）会导致没有任何内容可运行，因此完成定义只能退化为检查某项内容是否存在，接手者也无法判断这项工作是否有帮助。在保留范围的同时，重新划分偶然形成的实现层；仅重命名一个层不算重新划分。保留明确要求的交付边界，并确保工作可在该边界内验证，或指出真正的冲突。仅有编号列表并不能证明存在此类要求。Question Ticket 不受此限制——调查没有可运行的切片，其完成标准是记录调查答案。

Manifest 输入默认生成一个涵盖整个 Manifest 的 Shaped Ticket。 其 Deliverable 仍作为内部执行和验证结构。只有调用者明确要求委派或并行接手时，才按每个 Deliverable 拆分为一个 Ticket。现有 Deliverable 边界是允许拆分的最小边界：如果某个 Deliverable 过大，或只是实现层而非可端到端验证的内容，应修改 Manifest，而不是交付一个无法端到端评判的单元。

只有当问题需要独立生命周期时，问题输入才单独生成 Question Ticket。 当前工作能够回答的问题，或仅用于记录执行选择的问题，应保留在所属 Ticket 中。需要一并管理的相关问题应合并为一个 Question Ticket。明确要求跟踪或委派某个问题，即表明它需要独立生命周期。

后续事项输入应与源 Ticket 的义务保持区分。 当前范围内的工作应留在源 Ticket 中；阻碍其完成定义的问题应升级处理。先搜索该工作项的开放事项集；如果已有 Ticket 涵盖这项工作，就将发现并入其中；然后在创建 Ticket 前归并相关的新发现。每个新建的后续 Ticket 都应链接回其源 Ticket，并沿用相同的工作项归属，除非该发现确实属于其他工作项。

转译知识，而非机械内容

在保留有效产品意图的同时，保留任务分配和权限：谁的进展至关重要、在什么情况下、有哪些替代方案和权衡，以及观察到的内容与假设的内容分别是什么。不要把询问的答案或 Manifest 简化成任务和检查项的列表。

Ticket 是与陌生人订立的契约，而对方可能没有 manifest-dev。应将源内容改写为符合约定结构的内容，而非摘录其中片段。一个称职的陌生人仅凭这份 Ticket，能否理解工作为何存在、了解其边界、避开陷阱，并判断工作是否完成？Ticket 中出现 Manifest-dev 术语就过不了这一关。

对于 Manifest 输入，将完整连贯的 Outcome 转译为一份 Ticket。Outcome 和 Problem 归入 Why；Appetite 和 Out of bounds 归入 Scope。将具有实际来源的硬性义务纳入必须遵守的 Rules。唯一例外是 Manifest 的上限不变量，无论是否拆分，都是每份 Manifest 都包含的 Global Invariant，用于将变更限制在该 Manifest 授权的范围内。绝不要将其作为规则输出，因为 Ticket 的 Scope 已涵盖其内容。将有效的验收主张和证据方法纳入 Definition of done，并保留其可根据证据调整的权限，同时维持要求的结果和硬性要求。保留明确要求的证明、审核政策和持续有效的验收要求；仅在评估者指示属于附带机械内容时才省略。Risks 和 assumptions 归入 Watch out for；Initial Approach 仍是可选建议。每项 Deliverable 和 gate 都应贡献其实质内容，不包含 gate 类型或代码。保留获准的发现处置权限，以及继续工作所需且有依据的决策；无论是转译还是整体批准，都不会让工作中的选择变成硬性要求。

在明确的拆分模式下，对每项 Deliverable 采用相同的转译方式，并将所有适用的 Global Invariant 连同其来源权限纳入每份 Ticket。若某项 Deliverable 是一个层，而非可端到端执行的内容，则应按照上述切分规则，先修改 Manifest。

自动授权

在授予或拒绝 Auto，或记录授权决定之前，请阅读 references/AUTOMATED_EXECUTION.md → The automation identity 和 Transitions：其中说明了谁的 授权有效，以及谁可以授予授权。

采用约定中的 Auto 标准：完成此任务所需的每项决策都已确定或已委派，并且授权者选择信任无人值守的执行。即使方向和实现决策均已委派，只要验收权仍由人工保留，Auto 就不能开启。

哪些人可以授予授权，见 references/AUTOMATED_EXECUTION.md → Transitions，Grant 行。个人可以通过编写 Ticket，或明确审核并授权该 Ticket 的 Auto 来授予授权；orchestrate --autonomous 会为 Agent 编写的 Ticket 调用此技能——无论是其编写的债务 Ticket，还是某次运行编写的后续 Ticket——并且仅在满足上述标准时授予授权。按工作平台呈现的方式，将授权者与授权一并记录，以便个人能够区分 orchestrate 授予的授权与自己授予的授权，并撤销该授权。

后续工作只有在该行所述条件下才能获得 Auto。Shaped 永远不意味着 Auto。

类型、依赖项与延期

如果某个 Ticket 符合存储词汇表中的类型，则为其指定一种类型；否则不指定类型。在单 Ticket Manifest 模式下，按完整工作的主要性质指定类型。在明确拆分模式下，分别为每个 Deliverable 指定类型。类型绝不授予执行权限。

只有当一个 Ticket 的结果是完成或判断另一个 Ticket 所必需的，才填写 Depends on:。优先顺序不等于依赖关系。仅仅相关的后续工作应链接到其来源，但不应以其为阻塞项；只有存在结构性需求时才添加依赖边。

如果工作需要等待某件事在现实中成立，而不是等待另一个 Ticket 关闭——例如某个数值越过界限、某个版本发布或某个日期到来——请按约定写入 Revisit when 行：注明条件以及根据场所映射读取条件的位置。指定拾取者可以读取的来源，例如仪表板、文件、发布页面或日期；如果拾取者无法读取该条件，Ticket 就会在每次拾取时都出现在负责人面前。延期绝不能写成 Depends on: 条目，优先顺序也绝不是延期。

选择并呈现场所

阅读 references/STORE_CONFIG.md 并确定场所，沿用已有选择。然后阅读其场所参考文档，并按照该映射呈现 Tickets。配置本身不会创建工作；本次调用的编写任务决定了范围。

报告

用简短表格列出编写的内容：ID、标题、类型、类别、Auto 及其授予方、依赖项、任何 Revisit when 条件，以及每个 Ticket 的落点。在 Manifest 模式下，说明采用的是默认的连贯单元还是明确的 Deliverable 拆分。在后续工作模式下，包含来源链接，并说明哪些发现被归为一组或去重。

注意事项

• 门槛可能会指定陌生人无法使用的评估机制。将其实际含义改写为可观察的完成描述。
• 一系列小问题并不自动构成一组 Question Tickets。首先进行生命周期测试。