cawplan-ux-tracking

CawPlan UX Tracking

Bootstrap

cawplan skill check

Background

Tickets have ux values NOT_REQUIRED, PENDING, and READY; only PENDING needs UX follow-up.

Use cawplan tickets search, not tickets poll, because poll does not return ux.

Every workflow passes --excluded_status_categories COMPLETE,CANCELED: UX can remain PENDING after a ticket closes. Use category filters, not product-line-specific status keys.

UX queries need the full window:

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

Pagination: increment page_num while page_num * page_size < total; use total as the completion signal. In the hosted agent each page is its own tool call (no shell loops or jq) and a turn has roughly 16 calls: use --page_size 100, and if the pages do not fit, report a partial result (see references/QUERY_RESILIENCE.md).

Counts only ("how many tickets still need UX, by priority/version"): use cawplan tickets stats with the same filters and --group_by priority (or version, assignee) instead of paging and counting.

Follow-ups and failures: follow references/QUERY_RESILIENCE.md. In a follow-up such as "now only CRITICAL+HIGH", keep the earlier product/version scope and add only the new filter. Reuse the IDs when they are visible in your context; otherwise resolve the scope name from the earlier answer again. Never drop the scope, and never pass a product name as --product_ids. If a command is rejected or a page fails, report what was verified as a partial result and do not show commands or error text to the user.

Entry Routing

Input	Flow
A specific product + version ("这个版本需要UX跟进的ticket")	A — Version scope
A specific product, no version given, not framed by priority or team	A — Version scope, but ask the user whether they mean a specific version or all versions of the product — "all versions" runs Workflow A step 2 with --product_ids and no --version_ids, no priority filter added (that's Workflow B's filter, not applicable here just because the version was dropped)
High-priority + no specific version, or explicitly cross-version	B — Priority scope
A Team / product line ("某个team尚未提供UX的清单")	C — Team scope
A product's UX members' design completion ("汇总 CawCut Cloud UX Team 本周的 UX 完成情况")	D — Product UX completion

Workflow A — Version scope

1. Resolve product + version (same pattern as cawplan-plan-track steps 1-2):

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

   Pass the search text as one unquoted token (--search CawPlan, never --search "CawPlan"): the hosted agent rejects quoted values. For a name with spaces, search one distinctive word and match the full name in the results. The supplied product must be an exact accessible-name match (case-insensitive after trimming whitespace), a unique short-form/token-prefix match, or a candidate the user explicitly confirms. If no unique match exists, show the candidates and ask which product they mean before listing versions or querying tickets; never use the closest product name.

2. Fetch:

   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
   

   Page through fully (see Pagination above).

   For "all versions of this product" (per Entry Routing), drop --version_ids and use --product_ids <product_id> instead — everything else in this step is unchanged, and no priority filter is added just because there's no version.

Workflow B — Priority scope

1. If the user gave a product/version, resolve it the same way as Workflow A and add --product_ids/--version_ids. If they didn't, ask whether to scope to a product or search across everything they have access to — don't silently assume "everything."
2. Fetch:

   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>]
   

   Page through fully (see Pagination above), then sort CRITICAL → HIGH.

Workflow C — Team scope

1. Resolve the Team name to a product_line_id — same pattern as cawplan-product-report's Team workflow: cawplan product-lines list --page_size 100, match by name client-side. Require an exact name match (case-insensitive after trimming whitespace), a unique short-form/token-prefix match, or explicit user confirmation of a candidate. Ask to disambiguate on multiple matches; if no unique name match exists, list candidates and ask which Team the user means rather than guessing the closest one.
2. Fetch:

   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
   

   Page through fully (see Pagination above), then sort CRITICAL → HIGH → MEDIUM → LOW.

Workflow D — Product UX completion

UX Team here means the product's configured members.designers roster, not a CawPlan product line. If the product is omitted, ask which product's UX members should be reported.

1. Resolve the product and complete the product-access gate used by Workflow A:

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

   Read the matched product's members.designers[] roster and collect its user_id values and display names. If it has no Designers, report that the product has no configured UX roster and stop. Membership is product-scoped; use this returned roster, not a workspace-wide keyword search. Default the date window to the current week only when the user does not provide one.

2. Fetch every UX change made by the roster in the window with one bulk call (window at most 90 days; split longer ranges):

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

   Keep only events whose new is READY. Each event's actor is the history actor, its at the change time, and the response's tickets map carries the display ID, title and version for the output. Do not count a Ticket because its current ux is READY, because it is assigned to a Designer, or because a non-Designer changed its UX field. If the result is truncated, continue with --cursor or split the window before reporting.

   Fallback (only if tickets changes is unavailable, see references/QUERY_RESILIENCE.md): fetch candidates with

   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
   

   paged fully (no terminal-status exclusion: a Ticket may have been marked READY and later closed or moved back to PENDING; updated_at is only a candidate filter). Then, for every candidate, fetch cawplan tickets history <product_id> <version_id> <ticket_id> and keep only an UPDATED entry whose changed_fields.ux changes to READY (a READY string or an object with new: READY), whose created_at is in the window, and whose user_id is in the roster. Say that the slower path was used, and report a partial result if not every candidate could be checked.

3. Deduplicate by Ticket, retaining its latest in-window UX-Ready event. Group the retained Tickets by that event's actor (actor.user_id / actor.display_name, or the history entry's user_id / user_display_name on the fallback path): this actor is the product roster's Designer who completed the UX work. Never group, count, or infer the Designer from the Ticket's reporter or ordinary assignees.

Output

• One row per matching ticket: display ID, title, type, priority, product/version, assignee.
• Workflow B/C: sorted by priority descending, as above.
• State the search window and that terminal categories are excluded.
• If nothing matches, say so plainly — don't return an empty table with no comment.
• If any page, batch or check could not be completed, say what was verified and what was not before the table (see references/QUERY_RESILIENCE.md). Write the answer by the rules in references/QUERY_RESILIENCE.md §5: no CLI commands, internal field names or reasoning text.
• For Workflow D, show each configured Designer's UX-Ready ticket count and the Ticket list (display ID, title, product/version, UX-Ready timestamp). State the requested window, the product used for the UX roster, and that counts are based on history-verified ux → READY events.

References

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