cawplan-ux-tracking

CawPlan UX 跟踪

初始化

cawplan skill check

背景

Ticket 的 ux 值包括 NOT_REQUIRED、PENDING 和 READY；只有 PENDING 需要跟进 UX。

请使用 cawplan tickets search，而不是 tickets poll，因为 poll 不会返回 ux。

每个工作流都要传入 --excluded_status_categories COMPLETE,CANCELED：Ticket 关闭后，UX 仍可能处于 PENDING。请使用类别过滤器，不要使用特定产品线的状态键。

UX 查询需要完整时间范围：

--start_date 2000-01-01 --end_date <today>

仅统计数量（“按优先级/版本统计仍需要 UX 的 Ticket 数量”）：使用带有相同过滤条件的 cawplan tickets stats，并设置 --group_by priority（或 version、assignee），而不是分页后再计数。

后续查询与失败处理：请遵循 references/QUERY_RESILIENCE.md。对于“现在只看 CRITICAL+HIGH”这类后续查询，保留之前的产品/版本范围，只添加新的过滤条件。若 ID 在当前上下文中可见，请复用；否则，请根据之前的回答重新解析范围名称。绝不要丢弃范围，也绝不要将产品名称传给 --product_ids。如果命令被拒绝或某页查询失败，请报告已核实的部分结果，不要向用户展示命令或错误文本。

输入路由

输入	流程
指定产品 + 版本（“这个版本需要 UX 跟进的 ticket”）	A — 版本范围
指定产品，未指定版本，也未按优先级或团队限定	A — 版本范围，但要询问用户指的是某个特定版本，还是该产品的所有版本——“所有版本”会执行工作流 A 第 2 步，并使用 --product_ids，不传 --version_ids，不添加优先级过滤条件（这是工作流 B 的过滤条件，不能仅因省略了版本就在此处应用）
高优先级 + 未指定特定版本，或明确要求跨版本	B — 优先级范围
某个团队/产品线（“某个 team 尚未提供 UX 的清单”）	C — 团队范围
某产品 UX 成员的设计完成情况（“汇总 CawCut Cloud UX Team 本周的 UX 完成情况”）	D — 产品 UX 完成情况

工作流 A — 版本范围

1. 解析产品 + 版本（采用与 cawplan-plan-track 第 1-2 步相同的模式）：

   cawplan products list --search <product-name-word>
   cawplan versions list <product_id>
   

   将搜索文本作为一个不加引号的词传入（--search CawPlan，绝不要写成 --search "CawPlan"）：托管 Agent 会拒绝带引号的值。名称包含空格时，请搜索一个有辨识度的词，并在结果中匹配完整名称。 提供的产品必须与可访问名称完全匹配（去除首尾空格后不区分大小写）、与唯一的简称/词首匹配，或是用户明确确认的候选项。如果没有唯一匹配项，请先展示候选项并询问用户指的是哪个产品，再列出版本或查询 Ticket；绝不要使用最接近的产品名称。

2. 获取：

   cawplan tickets search --version_ids <version_id> --ux PENDING --excluded_status_categories COMPLETE,CANCELED --start_date 2000-01-01 --end_date <today> --page_size 100 --page_num 1
   

   请完整遍历所有分页（见上文“分页”）。

   对于“该产品的所有版本”（见“输入路由”），请移除 --version_ids，改用 --product_ids <product_id>——此步骤中的其他内容均保持不变，且不能仅因未指定版本就添加优先级过滤条件。

工作流 B — 优先级范围

1. 如果用户提供了产品/版本，请按工作流 A 的相同方式解析，并添加 --product_ids/--version_ids。如果用户没有提供，请询问要限定到某个产品，还是搜索其有权限访问的所有内容——不要擅自假定为“所有内容”。
2. 获取：

   cawplan tickets search --priority CRITICAL,HIGH --ux PENDING --excluded_status_categories COMPLETE,CANCELED --start_date 2000-01-01 --end_date <today> --page_size 100 --page_num 1 [--product_ids <id>] [--version_ids <id>]
   

   请完整遍历所有分页（见上文“分页”），然后按 CRITICAL → HIGH 排序。

工作流 C — 团队范围

1. 将团队名称解析为 product_line_id — 采用 cawplan-product-report 团队工作流中的相同模式：cawplan product-lines list --page_size 100，在客户端按名称匹配。要求名称完全匹配（去除首尾空白后不区分大小写）、唯一的简称／令牌前缀匹配，或用户明确确认某个候选项。如果有多个匹配项，请用户消除歧义；如果没有唯一的名称匹配项，请列出候选项并询问用户指的是哪个团队，而不是猜测最接近的选项。
2. 获取：

   cawplan tickets search --product_line_ids <product_line_id> --ux PENDING --excluded_status_categories COMPLETE,CANCELED --start_date 2000-01-01 --end_date <today> --page_size 100 --page_num 1
   

   完整翻页（参见上文的分页说明），然后按 CRITICAL → HIGH → MEDIUM → LOW 排序。

工作流 D — 产品 UX 完成情况

此处的 UX 团队指产品已配置的 members.designers 名单，而非 CawPlan 产品线。如果未提供产品，请询问要报告哪个产品的 UX 成员。

1. 解析产品并完成工作流 A 中使用的产品访问权限检查：

   cawplan products list --search <product-name-word-or-product_id>
   

   读取匹配产品的 members.designers[] 名单，并收集其中的 user_id 值和显示名称。如果没有设计师，请说明该产品未配置 UX 名单并停止。成员资格按产品范围确定；使用此处返回的名单，而不是在整个工作区内按关键词搜索。仅当用户未提供日期范围时，才将日期范围默认设为本周。

2. 使用一次批量调用，获取名单成员在日期范围内进行的所有 UX 更改（日期范围最多为 90 天；更长的范围需拆分）：

   cawplan tickets changes --product_ids <product_id> --fields ux --actor_ids <designer_user_ids_csv> --start_date <window_start> --end_date <window_end>
   

   仅保留 new 为 READY 的事件。每个事件的 actor 是历史记录中的操作者，at 是更改时间；响应中的 tickets 映射包含输出所需的显示 ID、标题和版本。如果 Ticket 当前的 ux 为 READY、已分配给设计师，或其 UX 字段由非设计师更改，都不得计入。如果结果为 truncated，请使用 --cursor 继续，或在报告前拆分日期范围。

   备用方案（仅当 tickets changes 不可用时使用，参见 references/QUERY_RESILIENCE.md）： 使用以下命令获取候选项

   cawplan tickets search --product_ids <product_id> --ux PENDING,READY --start_date 2000-01-01 --end_date <today> --updated_start_date <window_start> --updated_end_date <today> --page_size 100 --page_num 1
   

   并完整翻页（不排除终态：Ticket 可能曾被标记为 READY，之后又关闭或移回 PENDING；updated_at 仅用于筛选候选项）。随后，对每个候选项获取 cawplan tickets history <product_id> <version_id> <ticket_id>，仅保留满足以下条件的 UPDATED 条目：changed_fields.ux 将 UX 更改为 READY（值为字符串 READY 或包含 new: READY 的对象）；created_at 在日期范围内；且 user_id 在名单中。说明使用了较慢的方案；如果未能检查所有候选项，则报告部分结果。

3. 按 Ticket 去重，仅保留日期范围内最新的 UX-Ready 事件。按该事件的操作者分组保留的 Ticket（备用方案中使用 actor.user_id / actor.display_name，或历史条目的 user_id / user_display_name）：此操作者就是产品名单中的完成 UX 工作的设计师。绝不要根据 Ticket 的报告人或普通受派人来分组、计数或推断设计师。

输出

• 每个匹配的 Ticket 占一行：显示 ID、标题、类型、优先级、产品／版本、受派人。
• 工作流 B/C：按优先级降序排序，如上所述。
• 说明搜索日期范围，并说明已排除终态类别。
• 如果没有匹配项，请明确说明；不要只返回一个没有说明的空表格。
• 如果有任何页面、批次或检查未能完成，请在表格前说明已验证和未验证的内容（参见 references/QUERY_RESILIENCE.md）。按照 references/QUERY_RESILIENCE.md §5 的规则撰写答复：不得包含 CLI 命令、内部字段名称或推理文字。
• 对于工作流 D，列出每位已配置设计师的 UX-Ready Ticket 数量及 Ticket 列表（显示 ID、标题、产品／版本、UX-Ready 时间戳）。说明用户指定的日期范围、用于获取 UX 名单的产品，以及计数基于经历史记录验证的 ux → READY 事件。

References

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