cawplan-product-report

CawPlan 製品レポート

ブートストラップ

cawplan skill check

エントリールーティング

入力	フロー
カテゴリおよび任意のキーワード（例：「VN iOS Collage bugs」）で絞り込んだ、製品全体の未対応／オープンチケット	A1 — 製品全体のラベルで絞り込んだチケット
製品の現行バージョンまたは指定バージョンのオープン／未クローズチケット	A0 — バージョンのオープンチケット
特定の製品（および任意のバージョン）	A — 製品レポート
Team／製品ライン（「Team A」など、製品名ではなく、チームまたはライン名）	B — Team レポート
製品の UX メンバーによる UX／デザインの完了状況	cawplan-ux-tracking の ワークフロー D を使用します。レポーターや担当者ではなく、製品に設定されたデザイナーが実行した ux → READY イベントをカウントします。
製品の QA メンバーによるチケットの検証／受け入れ状況	D — QA 検証アクティビティ。現在の担当者ではなく、製品に設定された QA メンバーが実行したステータス変更イベントをカウントします。
指名されたメンバー、または呼び出し元以外の人物（「Alex の…の状況は？」など）	C — メンバーレポート
製品、バージョン、Team のチケット数をステータス、担当者、優先度、ラベル、UX で集計する場合（「当前版本各状态多少条」、「每个 Assignee 多少条」など）	--product_ids または --version_ids で範囲を指定し、ディメンションごとに 1 回呼び出します。cawplan tickets stats --version_ids <version_id> --start_date 2000-01-01 --end_date <today> --group_by status（続いて --group_by assignee。単数形です）。日付範囲は必須です。references/QUERY_RESILIENCE.md §1 を参照してください。件数の集計に tickets search のページネーションを使用しないでください。
一定期間内に製品、バージョン、Team、メンバーの範囲で再オープンされたチケット（「どれが再オープンされたか」など）	references/QUERY_RESILIENCE.md（「再オープン」）に記載された定義とコマンドを使用し、--product_ids、--version_ids、--product_line_ids、またはメンバーの候補 --unique_ids で範囲を指定します。再オープンイベントをすべて報告してください（チケット、変更前 → 変更後のステータス、時刻）。ステータス名が「Reopen」のものだけに限定しないでください。

名前が製品か Team か不明な場合は、両方を検索し（products list --search、product-lines list）、どちらかが曖昧な場合、または両方に一致する場合は確認してください。ユーザーが指定した Team 名または製品名は、空白を除去したうえで、大文字と小文字を区別せず、アクセス可能なレコードと完全一致するか、一意な短縮形／トークンの接頭辞に一致する必要があります。一意に一致しない場合は、利用可能な候補または検索で返された候補を列挙し、どの Team／製品を指しているのか確認してください。似た名前の製品や Team に置き換えないでください。ユーザーが自身のタスク完了状況（「自分のタスク」）について尋ねている場合は、このスキルではなく cawplan-my-work を使用します。

チケットに関する共通ルール

分類の信頼できる情報源はラベルです

チケットがバグ、機能、または別のカテゴリのいずれに該当するかを判断する際に、従来のチケット type、--type 検索オプション、返される .type フィールドを使用しないでください。確認済みの製品で参照できるラベルから分類を判断し、--label_ids で絞り込んでください。互換性のために API レスポンスに従来のフィールドが含まれる場合がありますが、カテゴリの判定には使用しないでください。

チケットタイトルの忠実性

チケットレスポンスの description フィールドが正式なタイトルです。チケットタイトルを表示する際は、常に原文をそのまま再現してください。翻訳、要約、短縮、書き換え、句読点や空白の正規化、接頭辞の削除、括弧内のテキストの省略はしないでください。説明や要約が役立つ場合は、別のフィールドに記載してください。同じ表示タイトルを維持するために必要な Markdown のエスケープ（例：表内のパイプのエスケープ）は許可されます。

ワークフロー A0 — オープンチケットのバージョン別一覧

「VN Cloud の現在の Version の Open Tickets を確認」や「Product X 1.2.3 の未クローズチケットを一覧表示」といった依頼には、このワークフローを使用します。他のクエリを実行する前に、ワークフロー A で必須の製品アクセス確認を必ず実施してください。類似した名前、別名、以前のクエリ、または別の製品の現在のバージョンから製品を推測してはいけません。

1. 次のコマンドで、依頼された製品を特定します。

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

   検索テキストは引用符で囲まず、1つのトークンとして渡します（--search CawPlan。--search "CawPlan" は不可）。ホストされたエージェントは、引用符で囲まれた値を拒否します。名前にスペースが含まれる場合は、特徴的な単語を1つ検索し、結果から完全な名前と照合します。 完全一致するアクセス可能な名前、または一意な短縮名／トークンの接頭辞に一致する場合に限り、次へ進みます。一致する候補がない場合は、「アクセス可能な製品で <input> に一致するものはありません。存在しないか、別の名前であるか、アクセス権がない可能性があります。」と報告します。バージョンやチケットを照会してはいけません。API が明示的にアクセス拒否エラーを返した場合は NO_PERMISSION と報告します。それ以外の場合、アクセス権がないと断定してはいけません。

2. バージョンを特定します。「現在の Version」の場合は、一致した製品の inprogress_version_id と inprogress_version_name を使用します。いずれかが存在しない場合は、その製品に現在進行中のバージョンがないことを報告します。名前が指定されたバージョンの場合は、cawplan versions list <product_id> を使用し、バージョン名が完全一致するものを必須とします。別の製品のバージョンを流用してはいけません。

3. total に達するまでページングし、そのバージョンのチケットをすべて取得します。

   cawplan tickets search --version_ids <version_id> --start_date 2000-01-01 --end_date <today> --page_size 100 --page_num 1
   

   チケットは、インラインの status_display.category が COMPLETE でも CANCELED でもない場合に限り、オープンとして扱います。--excluded_status_categories COMPLETE,CANCELED フィルターが指定されていても、クライアント側でこの条件による絞り込みを行ってください。サーバー側の除外だけを安全策として信頼してはいけません。

4. 特定した製品とバージョン、オープンチケットの合計数、ステータス／優先度別の内訳を報告します。各チケットについて、表示 ID、ラベル、優先度、ステータス、そして変更せずそのままの description タイトルを表示します。結果がチャットで有用に提示できる量を超える場合は、まず件数と内訳を提示し、その後、優先度／ステータスでの絞り込み、またはエクスポートを依頼します。別の製品に黙って置き換えたり、不完全な一覧を完全な一覧として報告したりしてはいけません。

ワークフロー A1 — 製品全体のラベルで絞り込んだチケット

「VN iOS の残りの Collage のバグを一覧表示して」のようなリクエストには、このワークフローを使用します。ユーザーが範囲を明示的に絞り込まない限り、アクティブなバージョンとバックログを対象にします。

1. 指定された製品を特定し、ワークフロー A の必須製品アクセスゲートを完了します。確認済みの product_id を保持し、名前の似た製品から推測しないでください。

2. その製品で参照できるラベルカタログ全体を取得します。

   cawplan labels list --product_id <product_id> --page_size 200 --page_num 1
   

   total 件までページを取得します。この製品スコープのカタログには、そのチーム／製品ラインを通じて適用されるラベルと、ワークスペース全体のラベルが含まれます。実際に返されたレコードからのみ選択してください。ラベル名や ID を捏造したり、スコープ指定のないワークスペース全体のカタログを代わりに照会したりしないでください。

3. ユーザーが指定したカテゴリを、返されたカタログと照合します。比較時には大文字と小文字、空白、ハイフン、アンダースコアを正規化しますが、返されたラベル ID と名前は正確に保持してください。

   • バグ／欠陥を意図する場合、behavior が BUGFIX の返却ラベルはすべて有力な一致候補です。
   • ラベル名または明確なトークン／フレーズとして bug、bugs、bugfix、bug fix、defect、defects、regression、regressions が含まれている場合は、有力な名前の手掛かりです。ただし、debug のような任意の部分文字列は対象外です。
   • fix、fixing、hotfix、issue、crash、incident、blocker は、文脈に応じて候補になります。返されたカタログとユーザーの表現から、それらがカテゴリを意味すると明確に判断できる場合にのみ選択してください。Fixing のようなワークフロー／状態ラベルを、バグ分類として機械的に扱わないでください。
   • Feature、Enhancement、Blocked、優先度ラベルは、バグチケットに付いている可能性があるというだけでバグを意味するものではありません。
   • バグ以外のカテゴリでは、同じ意味上の基準を適用し、ユーザーが指定したカテゴリを明確に表す返却ラベルのみを選択してください。
   • 意味上安全に一致するラベルが複数ある場合は、すべて選択してください。検索では label_ids 内で OR として扱われ、その結果と他のフィルターが AND で結合されます。
   • 安全に一致する返却ラベルがない場合は、最も近い候補を提示してユーザーに選択を求めてください。従来の type にフォールバックしないでください。

4. 一致するチケットをすべて照会します。手順 3 の ID を使用し、ユーザーが Collage のような別個のタイトル／テキストキーワードを指定した場合にのみ --search を追加します。

   cawplan tickets search \
     --product_ids <product_id> \
     --label_ids <comma-separated-selected-label-ids> \
     --search <optional-keyword> \
     --start_date 2000-01-01 \
     --end_date <today> \
     --excluded_status_categories COMPLETE,CANCELED \
     --page_size 100 \
     --page_num 1
   

   別個のキーワードがない場合は --search を省略します。page_num * page_size < total の間、ページを取得してください。

   --search は複数のチケットフィールドを対象とするフリーテキスト検索であり、構造化されたモジュールフィルターではありません。そのため、Photo Edit ... Collage のようなチケットは、Collage モジュールに属していなくても Collage に一致することがあります。キーワード検索の結果を、厳密なモジュール所属として説明しないでください。ユーザーがモジュールに限定した一覧を求めていて、API に専用のモジュールフィルターがない場合は、その制限を明示してください。回避策として、バグラベルとモジュールラベルを同じ --label_ids 引数に追加しないでください。label_ids 内の値は OR として扱われるため、バグ AND モジュール ではなく バグ OR モジュール が返されます。

5. 各結果を個別に判定し、インラインの status_display.category が COMPLETE でも CANCELED でもない場合に限り、オープンとして分類します。TESTING は引き続きオープンです。サーバー側の除外条件が指定されていても、このクライアント側の確認は必須です。

6. 分類を監査可能にします。結果表の前に、選択したラベルを正確に記載し（名前、ID、選択理由を含め、該当する場合は behavior=BUGFIX も記載）、続けて特定された製品、オープンの合計件数、ステータス／優先度／バージョン別の内訳を報告します。各チケットについて、表示 ID、ラベル、バージョンまたはバックログ、優先度、ステータス、変更を加えていない description のタイトルを記載してください。タイトルを書き換えたり、部分的なページを完全な一覧として提示したりしないでください。

ワークフロー A — 製品レポート

必須の製品アクセス確認

製品、バージョン、またはチケットに紐づくデータを照会する前に、要求された製品が呼び出し元の products list の応答に含まれていることを確認してください。呼び出し元が製品 ID を直接指定した場合や、ID が以前のコンテキストから保持されている場合も、この確認を適用してください。

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

完全一致または一意に特定できる短縮名の一致によって、対象となる製品を 1 つ（product_id / unique_id）特定した後にのみ処理を続行してください。ユーザーが指定した製品名に一意にアクセス可能な一致がない場合は、処理を中止して候補から対象の製品を確認するよう求めてください。製品、バージョン、アクティビティ、またはチケットの照会を実行してはいけません。NO_PERMISSION は、API がアクセス拒否を明示的に報告した場合にのみ使用してください。アクセスできない製品や特定できていない製品を、成功した空の結果として決して報告してはいけません（例：Open Tickets: 0）。

1. 製品名を product_id に解決し、必須の製品アクセス確認を完了します：

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

   製品名が完全一致または一意に特定できる短縮名で一致しない場合は、候補（名前 + product_id）を一覧表示し、どの製品を指しているのかユーザーに確認してください。推測してはいけません。このスキルの製品に紐づくすべてのワークフローで、この方法により製品を特定します。

2. ユーザーがバージョンを指定した場合は、バージョン名を version_id に解決します：

   cawplan versions list <product_id>
   

3. 製品レポートを取得します：

   cawplan product-activity get \
     --product_id <product_id> \
     --start YYYY-MM-DD \
     --end YYYY-MM-DD
   
   # Scoped to a specific version:
   cawplan product-activity get \
     --product_id <product_id> \
     --version_id <version_id> \
     --start YYYY-MM-DD \
     --end YYYY-MM-DD
   

4. 特定のバージョンについて報告する場合は、バージョンの進捗情報で補足します：

   cawplan versions get <product_id> <version_id>
   

   これにより、progress.complete_percent、risk、risk_reason、target_release が提供されます。

ワークフロー B — チームレポート

チームに紐づくアクティビティエンドポイントはありません。product-activity get が受け取るのは単一の --product_id のみです。そのため、チーム内のすべての製品におけるチケットの変更からレポートを作成してください。

1. チーム名を product_line_id に解決します。product-lines list には名前によるフィルターがないため、ページを順に取得し、クライアント側で名前を照合してください：

   cawplan product-lines list --page_size 100
   

   名前が一致しない場合は、正しい名前を尋ねてください。一致する名前が複数ある場合は、候補（名前 + product_line_id、および応答に含まれるその他の識別情報）を一覧表示し、どれを選ぶかユーザーに確認してください。推測してはいけません。

2. チーム全体のチケット変更を取得します — これはレポートの元になるチケット変更データです：

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

   • レポート期間には --start_date/--end_date ではなく、--updated_start_date/--updated_end_date を使用してください — 後者は最終変更時刻ではなくチケットの 作成 時刻で絞り込むため（references/CAWPLAN_OPEN_API.md を参照）、それだけでは以前に作成され、期間内に実際に完了または進捗したチケットを見逃し、「何が変わったか」を知らないうちに過少報告してしまいます。--start_date/--end_date も指定する必要があります（エンドポイントでは created_at の期間または --time_range が必須です）。そのため、最大範囲（2000-01-01 から今日まで。cawplan-ux-tracking と同じ回避策）に設定し、それ自体で結果を絞り込まないようにします。実際の絞り込みには --updated_start_date/--updated_end_date を使用します。
   • --updated_end_date にはレポート期間の終了日ではなく、（実際の）「今日」を指定してください — updated_at は完了時だけでなく、あらゆるフィールドの変更時に更新されます。そのため、期間内に完了したチケットに期間後の無関係な編集（バージョン移行、優先度の引き上げ、コメント）があった場合、--updated_end_date を期間の終了日に設定すると updated_at がその日付を過ぎ、気付かないうちに除外されます（references/CAWPLAN_OPEN_API.md の updated_at は「完了時刻」ではないという注記を参照）。終了日を今日まで広げることで、これは最終結果ではなく候補の集合になります — 以下のステップ 2a で、現在完了またはキャンセル済みのチケットについて、実際の完了時刻を使って対象を絞り込みます。[window_start, today] 内に作成されたチケットも引き続き取得できます（updated_at は created_at と同じ値で始まるため）。そのため、これは従来の created_at のみの動作を厳密に包含します。
   • 「直近 N 日間」の依頼では、--updated_start_date（今日から N 日前）をクライアント側で計算してください — time_range が適用されるのは created_at の組み合わせのみで、updated_at の組み合わせには適用されません。
   • レスポンスは CommonPageResp（data、page_num、page_size、total）です — cawplan-my-work/cawplan-ux-tracking が同じ形式で使用しているルールと同様に、page_num * page_size < total の間はページを取得してください。ページがたまたま満杯だった場合でも、先に total を確認せずに取得を止めないでください。 2a. レポート期間内の実際のステータス変更に候補を絞り込みます — updated_at は広範な候補フィルターにすぎません。編集があるたびに更新されるため、サブチケットの変更後に親チケットが 再計算された場合も更新されます。チケットのステータスが変わった証拠として使うことはできません。
   • チーム全体の実際のステータス変更を、1 回の一括呼び出しで取得します（期間は最大 90 日間。これより長い場合は分割します）：

     cawplan tickets changes --product_line_ids <product_line_id> --fields status --start_date <window_start> --end_date <window_end>
     

     返されるイベントはすべて期間内のステータス変更であり、at、old → new、new_category が含まれます。イベントが 1 件以上あるチケットのみを残します。updated_at が期間内であることだけを理由にチケットを残してはいけません。完了として扱うかどうかは、DONE をハードコードするのではなく、イベントの new_category（COMPLETE / CANCELED）で分類します。件数の集計のみの場合は、--group_by new_category（または ticket）を指定するとサーバー側で集計されます。
   • 概要では各チケットを 1 回だけ数え、期間内の最新イベントを表示用の根拠として保持します。ステータスが変わっていない親チケットにはイベントがなく、サブチケットの変更によって親チケットの updated_at が更新されていても除外されます。レスポンスの tickets マップには、出力用の表示 ID、タイトル、優先度、ラベル、バージョンが含まれます。
   • 結果が truncated の場合は、報告前に --cursor を使って続きを取得するか、期間を分割します。
   • フォールバック（tickets changes が利用できない場合のみ。references/QUERY_RESILIENCE.md を参照）：手順 2 のすべての候補について cawplan tickets history <product_id> <version_id> <ticket_id> を呼び出し、created_at が [window_start, window_end] 内にある UPDATED エントリの changed_fields.status（新しいステータスキー文字列、または old と new を含むオブジェクト）がある場合に限り、チケットを残します。CREATED をステータス変更として扱ってはいけません。プロダクトラインのステータス定義を解決し、新しいステータスをカテゴリで分類します。低速な方法を使用したことを明記し、すべての候補を確認できなかった場合は、結果が一部のみであることを報告します。

3. 任意：チームを構成するプロダクトを解決します（依頼された場合に限り、プロダクト別の内訳を作成します）。

   cawplan products list --product_line_id <product_line_id>
   

ワークフロー D — QA 検証アクティビティ

「CawCut Cloud の QA Team の今週の Ticket 検収状況をまとめて」や 「この製品の QA チケット検証状況をまとめて」のような依頼には、このワークフローを使用します。ここでいう QA Team は、製品で設定されている members.qas のメンバー一覧を指し、CawPlan の製品ラインではありません。製品が指定されていない場合は、どの製品の QA メンバーについて報告すればよいか確認します。このワークフローでは QA アクティビティ、つまり依頼された期間中に QA メンバーが実際に行った Ticket のステータス遷移を測定します。現在の担当者、報告者、または Ticket の現在のステータスを、QA 作業の代用指標としては使用しません。

1. 製品を特定し、ワークフロー A で必須となる製品アクセスの確認を完了します。

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

   該当製品の members.qas[] メンバー一覧を読み取り、user_id の値と表示名を収集します。QA メンバーがいない場合は、製品に設定済みの QA メンバー一覧がないことを報告して終了します。メンバーシップは製品単位です。ワークスペース全体を対象にしたキーワード検索ではなく、この製品について返されたメンバー一覧を使用します。期間が指定されていない場合は今週を既定とし、使用した開始日と終了日を含む期間を明記します。

2. ウィンドウ内に QA メンバーが行ったすべてのステータス変更を、1 回の一括呼び出しで取得します（ウィンドウは最大 90 日間とし、それより長い期間は分割します）。

   cawplan tickets changes --product_ids <product_id> --fields status --actor_ids <qa_user_ids_csv> --start_date <window_start> --end_date <window_end>
   

   返された各イベントは、ウィンドウ内にメンバー一覧のメンバーが実行したステータス変更です。CREATED、TRANSFERRED、任意の updated_at、QA 以外のアクターが行ったステータス変更、または現在 QA に割り当てられているというだけの Ticket はカウントしません。QA メンバーごとの件数は、--group_by actor,new_status_category を指定するとサーバー側で集計されます。結果が truncated の場合は、--cursor を使って続きのデータを取得するか、ウィンドウを分割します。

3. フォールバック（tickets changes が利用できない場合のみ。references/QUERY_RESILIENCE.md を参照）： ページネーションも含め、ワークフロー B の手順 2 とまったく同じ方法で候補の完全なセットを作成します。

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

   （updated_at は、履歴が関連する可能性のある Ticket を特定するためだけに使用します。終了日は実際の今日の日付のままにします。）候補ごとに cawplan tickets history <product_id> <version_id> <ticket_id> を呼び出し、changed_fields.status が存在する（通常は {old, new}。古い形式の文字列は新しいステータスとして許容）、created_at が [window_start, window_end] の範囲内にある、かつ user_id が members.qas のメンバー一覧に含まれるすべての UPDATED エントリーを保持します。時間のかかる方法を使用したことを明記し、すべての候補を確認できなかった場合は部分的な結果であることを報告します。

4. 保持した各履歴エントリーを 1 件の QA アクティビティとして扱います。Ticket ごとに重複排除してはいけません。Ticket が 1 週間の間に QA Testing、Done、Reopen、Close と遷移することは十分あり得ます。ステータス遷移はそれぞれ、検証に役立つ証跡です。アクティビティはイベントの actor（またはフォールバックの場合は履歴エントリーの user_id / user_display_name）、つまり変更を実行した QA メンバーに帰属させます。その人物を Ticket の報告者や担当者から推測してはいけません。アクターがなく、製品の QA メンバー一覧と照合できないエントリーは除外します。除外理由の説明に関連する場合に限り、そのエントリーを未割り当て／統合イベントとして別途示します。

5. カテゴリー別に内訳を示す場合は、各イベントの new_category を使用します。フォールバックの場合に限り、製品ラインのステータス定義を解決します。実際の遷移（old → new）と、新しいステータスのカテゴリーがある場合はそれも表示します。DONE、REOPEN、CLOSE、QA Testing をハードコードしてはいけません。カスタムのステータスキーやカテゴリーも有効な QA アクティビティです。

ワークフロー C — メンバー別レポート

ワークフロー B と同じチケット変更の手順ですが、製品ライン全体ではなく、1 人に絞って実行します。

1. メンバーを user_id に解決します：

   cawplan users query --email <email>       # if the user gave an email
   cawplan users query --keyword <name-word>    # if the user gave a name
   

   キーワード検索で複数の人が見つかった場合は、氏名とメールアドレスを一覧表示し、どの人かを確認してください。推測してはいけません。

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
   

   ユーザーが製品／バージョンも指定している場合は、--product_ids <id> ／ --version_ids <id> を追加します（ワークフロー A の手順 1 と同じ方法で解決します）。ワークフロー B の手順 2 と同じく、--updated_start_date／--updated_end_date を --start_date／--end_date より優先するルール、終了日を広げるルール、日付の計算ルール、ページネーションのルールを適用します。このメンバーにかなり前から割り当てられていたものの、期間内に完了したチケットを、期間内に 作成 されていないという理由だけで見落としてはいけません。

3. ワークフロー B の手順 2a と同様に、候補 50 件ごとに 1 回の一括呼び出しでステータス変更を検証します。updated_at が「完了日時」ではないという問題は、1 人のメンバーのチケットにも同様に当てはまります：

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

   候補ごとに tickets history を呼び出してはいけません。tickets changes 自体が失敗した場合に限り、ワークフロー B の手順 2a にあるフォールバックとして使用します（references/QUERY_RESILIENCE.md）。

出力

検索、ページ、バッチ、または期間のいずれかを完了できなかった場合は、レポートの前に、何を検証できたか、何を検証できなかったかを記載します（references/QUERY_RESILIENCE.md）。references/QUERY_RESILIENCE.md §5 の規則に従って回答を作成してください。CLI コマンド、内部フィールド名、推論内容は記載しないでください。

ワークフロー A：

• 概要：期間内に何が変更され、何が完了したか。
• 進捗：チケット完了率、ステータス別の内訳。
• リスク：現在のリスクレベルとその理由（LOW ／ MEDIUM ／ HIGH）。
• 優先度に基づく推奨事項：リリース前に対処すべき事項。
• 今後の予定：リリース目標日と残っている未完了項目。

ワークフロー B：

• 概要：期間内にチーム全体で何が変更されたか（リスク評価ではなく件数。このワークフローには versions track のようなリスクフィールドはありません。作り出さないでください）。
• 完了状況：期間内にステータス変更が履歴で検証されたチケットについて、ステータス別の件数、返されたラベル、優先度。終端ステータスの件数はイベントの新しいステータスのカテゴリに基づき、updated_at の生値や現在のステータスだけに基づいてはいけません。分類に旧式の type を使用しないでください。
• 注目すべき項目：期間内に実際にステータスが変更された CRITICAL ／ HIGH 優先度のチケットに加え、検証済みのステータス変更イベントによって終端カテゴリに移行したチケット。
• 製品別の内訳：手順 3 が実行され、ユーザーが希望した場合に限ります。

ワークフロー C： ワークフロー B と同じ構成（概要 + 完了状況 + 注目すべき項目）で、1 人のメンバーのチケットに絞ります。製品別の内訳セクションは設けません。

ワークフロー D：

• QA 活動の概要：期間内のステータス変更イベントの合計数と、該当するチケットの数。
• QA メンバー別：製品に設定された members.qas のメンバー一覧と一致する、履歴イベントの実行者ごとの活動件数とチケット数。グループ化のフィールドに現在の担当者や報告者を使用してはいけません。
• 検証済みの遷移：old → new ステータス別の件数とチケットの根拠（解決済みの場合は新しいステータスのカテゴリも含む）。QA Testing、Done、Reopen、Close、および API から返されたカスタムステータスを含みます。

参考資料

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