cawplan-my-work

CawPlan 我的工作

初始化

cawplan skill check

工作流

1. 解析你自己的 user_id——它从本地访问令牌中解码，无需网络调用：

   cawplan auth status
   

   读取输出中的 User ID: 行。如果缺失，请重新进行身份验证（运行 cawplan auth login，向用户显示打印出的 URL；用户批准后，再运行 cawplan auth login --device-auth --complete），不要改用 cawplan users query --email——那会为了解析一个 auth status 本应已提供的信息而消耗一次网络调用。

2. 获取你的待办事项：

   cawplan todos user <user_id>
   

   返回的数据包括 tickets（按 product_line → product → version 分组）、critical_issues（按 product_line → product 分组）和 summary。默认不应用状态筛选——响应包含所有分配给你的事项，而不仅是未完成事项。

3. 如果用户指定了某个项目／版本，将 tickets 缩小到对应的确切 product → version 叶节点。critical_issues 没有版本维度（仅按 product_line → product 分组），因此无法缩小到相同粒度——如果用户指定了版本，只将 critical_issues 缩小到匹配的 product，并明确说明这些严重问题适用于整个产品，尚未确认与指定版本有关。如果指定的项目／版本在 tickets 中完全没有出现，请明确说明（“你在 下没有找到工单”），而不要退而展示所有内容。

4. 如果用户只要未完成事项，需要解析响应中每个不同产品线的状态类别，并正确筛选——这是你自己的工作，实际涉及的产品线只有几条，不值得走捷径：

   cawplan product-lines statuses <product_line_id>   # once per distinct product line in the response
   

   排除状态键对应类别为 COMPLETE 或 CANCELED 的工单。只有当需要解析的产品线数量确实过多（一个人自己的工作中很少出现）时，才改为“清楚列出每项的状态，让用户自行判断”；如果这样做，请明确说明，而不要默默展示未筛选的列表，假装已经筛选过。

5. 按优先级排序的平铺列表（仅当用户要求“按优先级列出我的未完成工单”或类似的按优先级排序格式，而非按项目／版本分类时）：将所有产品线／产品／版本中的 tickets 平铺为一个列表。即使用户没有明确说明，这种表达也意味着只显示未完成事项——请执行步骤 4 的筛选。然后按 CRITICAL → HIGH → MEDIUM → LOW 排序。每一行仍须显示工单所属的产品／版本——为排序而平铺分组，不代表可以省略该上下文。

5a. 我的某一天或某个时间段内的任务完成／状态变更摘要（仅当用户要求“帮我总结今天的任务完成情况”“今天哪些任务状态变更了”或类似内容时）：这不是步骤 2 中的当前待办事项视图。默认时间范围为今天；如果用户明确指定日期／范围，则按其指定执行。

cawplan tickets search --assignees <user_id> --start_date 2000-01-01 --end_date <today> --updated_start_date <window_start> --updated_end_date <today> --page_size 100 --page_num 1

使用 total 完整翻页。updated_at 时间范围只用于筛选候选项：子工单发生变化时，父工单可能会刷新，即使父工单自身的状态并未改变。 然后批量获取候选项的状态变更，每次最多 50 个 ID：

cawplan tickets changes --unique_ids <candidate_ids_csv> --fields status --start_date <window_start> --end_date <window_end>

返回的每个事件都是时间范围内真实发生的状态变更（at、old → new、new_category）。只有至少有一个事件的工单才应保留。不要将 updated_at 用作最终依据。每个工单只报告一次，并使用其时间范围内最新的事件；未发生状态变化的父工单没有事件，应予以排除，即使其记录因子工单的状态变更而刷新。

回退方案（仅当 tickets changes 不可用时，参见 references/QUERY_RESILIENCE.md）： 对每个候选项，获取 cawplan tickets history <product_id> <version_id> <ticket_id>，只有当某条 UPDATED 记录包含 changed_fields.status（新状态字符串或 {old, new} 对象），且其 created_at 位于时间范围内时，才保留该工单。CREATED 不属于状态变更。 6. 我重新打开的工单（仅当用户询问重新打开的工单／工单为何被重新打开时）：没有 REOPENED 状态类别（只有 UNSTARTED／STARTED／TESTING／COMPLETE／CANCELED）——重新打开会显示为名称表明这一点的状态键，或显示为从终止类别向后转换的历史记录。扫描历史记录（要点 2）始终是事实依据；检查状态键（要点 1）只是常见情形下的快捷方式，即工单当前处于重新打开状态时使用——它不能取代扫描历史记录。

• 使用 references/QUERY_RESILIENCE.md（“Reopens”）中定义的通用规则和命令查找重新打开的工单，无论工单当前状态如何，都要检查你名下的每一张工单：使用 --unique_ids <ticket_ids_csv> 限定调用范围（每次调用最多 50 个 ID），并默认查询最近 90 天（--start_date <today-89d> --end_date <today>）——请说明这一点；只有用户询问更早的重新打开记录时，才添加更早的 90 天时间段。如果用户询问某张变更无法分类的特定工单，请在不使用这两个类别过滤条件的情况下重新运行，并按顺序查看其事件。如果无法使用 tickets changes，则回退为：对每张工单分别运行 cawplan tickets history <product_id> <version_id> <ticket_id>。
• 仅将解析每个不同产品线的状态（cawplan product-lines statuses <product_line_id>）作为辅助标记，检查重新打开转换后工单的状态是否在 display_name 中包含“reopen”——如果包含，可以在报告中将其称为“重新打开”；如果不包含（例如工单直接回到 in_progress 或 TESTING），根据历史转换，它仍属于重新打开，只需报告实际状态名称，不要假定存在专门的标签。
• 对于每次重新打开事件，如果历史记录中有时间戳和操作者，请一并报告原因：如果 API 在状态变更事件中返回了历史记录自身的评论，且该评论很可能与这次特定转换有关，请使用该评论（不要把与转换无关的通用自由文本评论说成是重新打开原因）；否则回退使用工单的 progress_comment，并明确标注为“最新进度备注，不一定是重新打开的原因”，不要把它说成是直接解释重新打开的原因。如果两者都不存在，请说明未记录原因——不要根据工单标题或描述推断原因。如果某张工单的变更查询失败，请将其列为“未检查”（这是部分结果，见 references/QUERY_RESILIENCE.md），不要说成“未发现重新打开”，也不要据此认定原因缺失。

7. 我负责的 ticket 关联的仓库 PR/commit（仅在用户询问时——“今天的 tickets 及其 PR/commit”、“整理我当天任务涉及的 tickets 和 PR/commit”）：ticket 带有一个 links[] 数组，其中可以包含 GitHub PR/commit URL（字段格式见 references/CAWPLAN_OPEN_API.md 中的“VersionTicket fields of note”）——todos/poll 不会返回此字段，只有完整的 ticket 记录才会返回，因此此步骤使用 tickets search，而不是步骤 1-6 中的 todos 调用。

   cawplan tickets search --assignees <user_id> --start_date 2000-01-01 --end_date <today> --updated_start_date <date> --updated_end_date <date> --page_size 100 --page_num 1
   

   除非用户要求其他日期/范围，否则将 <date>-<date> 默认设为今天，用于 --updated_start_date/--updated_end_date；除非结果集能证明并非如此，否则将结束日期视为包含当天全天。对于“今天的 tickets”，使用 --updated_start_date/--updated_end_date，而非 --start_date/--end_date——后者筛选的是 ticket 的创建时间（已通过 example-backend 的 DAO 确认，见 references/CAWPLAN_OPEN_API.md），因此上周创建、今天仍在处理的 ticket 会被悄然漏掉。仍必须传入 --start_date/--end_date（该端点要求提供 created_at 时间窗口或 --time_range）——将其设为最大窗口变通范围（2000-01-01 至今天），以免它本身缩小结果范围。 链接上的 platform 不是可靠的固定值——同一个手动添加的 GitHub 链接可能显示为 platform: "LINK"——因此应根据 url 本身分类：包含 /pull/ → PR，包含 /commit/ → commit，否则将其作为普通链接并报告其 title。links 数组为空的 ticket 没有仓库链接；应明确说明，而不是从报告中省略。 根据响应中的 total/page_num/page_size 字段翻页（当 page_num * page_size < total 时继续获取），而不要假定 100 条的一页就能覆盖所有结果。

8. Ticket 已关联 PR/commit，但状态尚未更新（仅在用户询问时——“哪些 ticket 已经有 PR/commit 但状态还没更新”）：复用步骤 7 的获取机制和分页规则，并添加 --status_categories UNSTARTED,STARTED。范围：如果用户指定了产品/版本，则使用 --product_ids/--version_ids，而不是 --assignees；如果用户明确说“我”/“自己的”，则使用 --assignees <user_id>。如果两者都未指定，默认查询你自己的 tickets（--assignees <user_id>），并说明这一点。使用 --start_date 2000-01-01 --end_date <today>，因为过期的 tickets 可能不是最近创建的。

   • 当某个 ticket 的任意 links 中有 url 包含 /pull/ 或 /commit/ 时，即视为“有 PR/commit”——两者都算，因为未合并为 commit 引用的开放 PR，也和单独的 commit 链接一样，能表明代码工作正在进行。
   • 对每个符合条件的 ticket，报告找到的 PR/commit 链接（并标明各自是 PR 还是 commit，分类方式同步骤 7）及其当前状态，以便用户判断该 ticket 是否确实需要更新状态。

输出

• 按产品线 → 产品 → 版本分组，与 API 自身的分组方式一致；不要将其重新扁平化为一个不加区分的列表，除非已执行步骤 5，此时应改为呈现按优先级排序的单一列表（每行仍显示产品/版本）。
• 对于每个工单：显示 ID、类型、优先级、状态和单行标题。
• 严重问题：单独设立章节，按产品线 → 产品分组，并显示严重程度/状态。
• 如果响应中包含 summary，且步骤 3 未缩小范围，则将其置于开头 — summary 描述的是未经缩小范围的完整响应，因此将其与缩小范围后的列表一同展示会造成内容矛盾。缩小范围后，应改为说明该范围内的数量（例如：“UniFi Access 4.1.10 有 1 个工单、1 个产品级严重问题”）。
• 如果步骤 3 缩小了范围，应在列出结果前说明缩小后的范围。
• 如果确实没有分配给你的内容，请直接说明，而不是返回没有任何说明的空章节。
• 如果任何查询、分页或批次未能完成，请在列表前说明已核实和未核实的内容（references/QUERY_RESILIENCE.md）。按照 references/QUERY_RESILIENCE.md §5 的规则撰写答案：不要包含 CLI 命令、内部字段名或推理文本。
• 如果已执行步骤 6：每个重新打开的工单列一项（显示 ID、标题、重新打开时间、重新打开者（如已知）、原因或“未记录”）。如果没有你的工单被重新打开，请明确说明，而不是显示空列表。
• 如果已执行步骤 7：对获取时间范围内的每个工单列一项，并列出其 PR/提交/其他链接（或“没有代码仓库链接”）；日期字段的假设只需说明一次，无需逐个工单说明。
• 如果已执行步骤 8：每个符合条件的工单列一项 — 显示 ID、标题、当前状态，以及触发标记的 PR/提交链接。如果没有符合条件的工单，请明确说明。
• 如果已执行步骤 5a：仅列出经历史记录核实的状态变更，并显示 ID、标题、可用时的旧状态 → 新状态、变更时间戳，以及新状态是否为终结状态。说明未发生变化的父工单会被有意排除。

参考资料

• references/CAWPLAN_OPEN_API.md
• references/QUERY_RESILIENCE.md