seda-ticket

创建工单

将提供的工作拆解为一组已确认的工单，确保新接手的交付负责人无需重新梳理上级背景，也能理解并完成这些工单。只负责拆解、依赖关系与可启动性语义，以及终态工单处置；调用方负责分组、存储、发布、执行、评审进度，以及根据负责人结果进行协调。

将大量分析、调研和专家工作委派给子 Agent，并返回简洁的发现和证据链接，以精简主上下文。

1. 理解工作

使用已提供的上下文。如果引用的来源对工作有约束，应完整阅读。仅在现有行为、术语、约束或准确的工单边界有此需要时，检查当前项目或系统。在软件工作中，这可能包括代码库，但并非普遍前提。

不要臆造实质性要求。如果没有拆解权限，或粒度／依赖结构不明确，请求确认。调用方也可以提供已确认的拆解方案。

根据需要使用 seda-spec。拆解时保留约束性契约的身份和要求。

2. 优先采用结果完整的纵向任务

默认将每个任务设为一个范围精简、结果完整的纵向切片，并满足以下条件：

• 交付可独立验证的用户、运营者、利益相关方或系统成果；
• 只跨越实现该成果所需的功能或层；
• 内容足够自成一体，让新的交付负责人或评审者能够理解，但不规定候选项、提交、分支、PR/MR、文档、证明文件或 Agent 会话的边界；并且
• 不依赖复制的父级叙述或猜测的实现细节，也能保持有效。

不要仅按组织职能、技术层、工件类型或证明活动拆分同一成果。只有在某项可独立验证的赋能能力确实会阻塞后续工作，或完整成果切片无法保持可用或集成时，才使用非纵向任务。记录例外，以及该任务所支持的集成或验收边界。

对于无法通过纵向切片持续保持绿色状态的软件或系统级迁移、机械式重构，可以采用扩展–迁移–收缩序列：先添加兼容形式，再迁移有限范围的分组，最后在迁移集合完成后移除旧形式。这是适用于软件的特定分支，不是通用任务模式。

每个任务包含：

• 标题 — 使用当前项目或领域术语描述简短成果。
• 交付内容 — 端到端行为或结果及其价值。
• 背景 — 仅包含必要且稳定的事实、约束或来源引用。
• 验收与证明 — 可观察的完成条件（如有，则包含适用规范中的行为标识），以及在重要时需要履行的证明或证据义务，或稳定接口；执行者或证明负责人自行选择具体方式。
• 依赖项 — 必须处于 Done 状态的确切草稿编号或提供的任务标识，或填写 None。
• 外部前置条件 — 仅当指定的非任务事实、权威或资源会阻止任务开始时填写；已知时注明负责人或触发条件。
• 边界 — 仅当某项排除内容能够避免可能的错误交付时填写。
• 状态 — Open、Done 或 Cancelled。
• 最终证据 — Done 状态的验收或证明结果；Cancelled 状态的取消授权或原因。

起草时使用临时编号，并保留调用方提供的标识。除非调用方提供分组，否则返回不分组、按依赖关系排序的任务集合。不要创建虚构的父级任务，也不要自行管理持久 ID、生命周期持久化、执行或评审状态、状态变更历史、受派人、时间戳、谱系或协调工作。

任务标识在语义层面定义，而非操作层面：任务边界不代表提交、候选项、分支、PR/MR、文档、证明文件、部署单元或 Agent 会话的边界。交付调用方应根据集成、评审、回滚或恢复、所有权、发布及证据需求，独立选择操作容器。

避免猜测文件或工件路径、过长的代码片段、通用实现清单、重复的项目规则及人为设置的依赖项。必要时提供准确且稳定的引用。只有在文字无法保留已确认的决策时，才加入简短的原型衍生片段，并标明其来源。

可启动性与终态处置

工单状态刻意不作为执行进度状态机：

状态	含义	所需证据
Open	交付仍未完成	无
Done	当前负责人提供的证据证明工单已验收并完成验证	验收结果和验证结果
Cancelled	工单被有意移出必需交付范围	取消授权和原因

推导 Open 工单的可启动性：

• STARTABLE — 所有工单依赖均为 Done，且没有正在生效的外部前置条件；
• BLOCKED — 至少有一项工单依赖或具名外部前置条件尚未解决。

只有 Done 才能解决工单依赖。依赖项处于 Cancelled 状态时，需要重新规划，而不是悄然解除对其依赖的工单的阻塞。

不要添加 In Progress、In Review 或运行时 Blocked 工单状态。活动执行、验证、审查、运行时阻塞因素、候选项／结果标识以及恢复流程，均不属于工单状态，应由活动执行／审查负责人负责。调用方可根据当前负责人的准确结果，将 Open 协调为 Done | Cancelled，而无需将其他负责人的生命周期引入工单约定。

可启动前沿是当前推导为 STARTABLE 的所有 Open 工单。

3. 确认并返回

检查每张工单是否都可独立验证、依赖关系是否真实且无环、外部前置条件是否确实存在、验收是否可观测，以及所提供的完整范围／规范是否得到覆盖且不存在重叠。对于每张非垂直切分工单，验证其例外情况是否必要、可独立验证，并与具名集成／验收边界相关联。

需要确认时，展示草案并询问其粒度和依赖关系是否正确。持续迭代，直至确认。

按依赖顺序返回已确认的工单，先列出受阻的前置项，并附上可启动前沿。仅返回工单；不要持久化／发布工单、操作 Git／服务商状态、执行工单，或判断执行／审查进度。