cawplan-testcase-generate

CawPlan TestCase Generate

跟随用户主语言回复；同一段不同时输出中英文。用例内容本身跟测试点/需求 Markdown 语言走。

Bootstrap

cawplan skill check

最高优先级：源值保真

• Title / Preconditions / Step / Expected 中的具体文案、错误码、阈值、次数、长度和枚举只能来自测试点或需求 Markdown。
• 源里逐字给出则原样带入 Title / Expected，不抽象、不意译、不挂诚实尾巴；源里没有则使用方向描述或写作规范定义的固定尾巴，不编硬值。
• 详细判定和固定尾巴见 references/testcase-writing-spec.md；设计方法不得越过本规则。

按动作读取 Reference

每次请求按当前动作读取一次整份文件，不要逐 TestPoint 重读：

当前动作	读取内容
从 TestPoint 生成或重新生成 Case 集	references/test-design-methods.md + references/testcase-writing-spec.md
只展开已有 Case 的详情	references/testcase-writing-spec.md
触发框 1～框 5	完整读取 references/interaction-prompts.md，使用对应框
as_is 导出	references/csv-template-mapping.md
fill_then_export	写作规范 + CSV mapping；除非重建 Case 集，否则不重读设计方法

CSV 列布局的最终模板是 assets/testcase-template.csv。

交互框执行契约

命中框 1～框 5 时，在任何用户可见回复前完整读取 references/interaction-prompts.md，并按对应框实际调用 AskUserQuestion；不得用普通聊天中的编号选项代替弹窗。仅当当前运行环境未提供 AskUserQuestion，或工具调用明确失败时，才使用该 Reference 中对应的逐字 fallback。下文“渲染框 N”均指执行本契约。

Workflow

1. Resolve target Requirement

每次生成请求按顺序 fall through：

优先级	条件	动作
P1	显式 Requirement 链接、display_id、requirement_id 或切换目标	Cold handoff，整体 rebind
P2	热接力话术且已有有效 binding	使用当前 binding
P3	会话有 Requirement 或 TestPoint 草稿，但无有效 requirement_id	触发框 3
兜底	无链接、无有效 binding、无草稿	触发框 1

有效 binding 必须同时包含 product_id 和 requirement_id。热接力包括“马上生成测试用例”“按上面的生成用例”“接着生成/展开用例”及等价英文；没有 binding 时继续 fall through。未归档 fast-path 不受支持，不得带草稿进入 GET。

框 1 · 锁定 Requirement

无目标且无草稿时，读取交互文案 Reference 并渲染框 1；有效 P1/P2 不触发。不得增加“用上面出好的”选项。

• “已有 Requirement 链接或编号” → 等待链接或 REQ- 编号；收到后按下文解析，无法解析则复述选项或请重选。
• “没有 Requirement” → 写入 resume_intent = testcase，读取 cawplan-requirement-analyze Skill 接力。

框 3 · 需求还没保存

P3 或测试点草稿/表存在但无 requirement_id 时，读取交互文案 Reference 并渲染框 3。

• “马上保存” → 写入 resume_intent = testcase，走 cawplan-requirement-analyze 的保存/归档及原确认闸；成功后回 §2。
• “先不保存” → stop。
• Other / 自由回复 → 按说明处理或复述。

路由与解析

• 测试点大纲/覆盖面/“生成测试点” → cawplan-testpoint-generate。
• 分析需求/五字段/归档 Requirement → cawplan-requirement-analyze。
• 生成、展开或导出测试用例 → 本 Skill。
• 已有 cases[] 时再次模糊说“生成用例”，先问“重新生成”还是“在现有基础上调整/展开”，避免覆盖 SQA 编辑。

Requirement 引用按以下顺序解析：

1. 合法的 product_id + requirement_id 优先；直接使用，不调用 display-id 查询。
2. 旧 Portal URL 只解析字符串，绝不请求页面：

/product/{product_id}/qa-insights/test-suites/requirements/{requirement_id}

3. 裸 display_id 必须严格是 REQ- + 数字（^REQ-\d+$）；或使用 Browse URL：

/browse/product/{product_key}/qa/requirement/{display_id}

对裸 display_id 或 Browse URL 调用（完整 URL 需加 shell 引号）：

cawplan qa-insights requirements resolve '<display_id_or_browse_url>'

• 该命令先本地校验/提取 display_id；格式错误时不请求接口。Browse URL 的 product_key（如 CP）不是 product_id，不得用它推测 UUID。
• SUCCESS：只在 meta.product_id 和 meta.requirement_id 都存在时完成 rebind，并把本次响应 data 直接记为 requirement_data。CLI 已从 API data.url 校验并解析这两个 ID；不得改用 data.redirect_url。随后进入 §2 的 display-id fast-path，不得再调用 requirements get。
• FAILURE / validation：提示 display ID 必须为 REQ- + 数字，不进入 GET。
• FAILURE / not_found：提示 Requirement 不存在，停止。其他 FAILURE 或 UNKNOWN 如实报告，不猜测 ID 或继续。
• SUCCESS 但缺少两个解析后 ID 视为返回数据异常，停止。

所有 URL 都只解析字符串，不得对 Portal/Browse 页面调用 cawplan api 或 HTTP。只有 requirement_id 时追问 product_id 或完整引用，不扫描产品。显式新目标只在完整解析成功后替换完整上下文；解析失败不清空旧 binding 或 cases[]。同时只绑定一个 Requirement。

跨 Skill 接力

• 框 1“没有 Requirement”、框 3“马上保存”和框 2“马上生成测试点”出站前写 resume_intent = testcase。
• A1/A2 完成后按该 intent 回 §2。A2 只生成并呈现测试点，不自动归档；SQA 确认归档后才继续。仅说“看着不错”未归档时，刷新后仍应再次触发框 2。
• A2 成功回执后，在有效 binding 下说“马上生成测试用例”直接走 P2 → §2，无需重贴数据。

2. 展開前に更新

今回の最新の Requirement データをサイレントに取得し、requirement_data として統一して扱います。

• 今回 requirements resolve の実行が成功した直後の場合：そのコマンドの data を直接使用します。これは requirements get が返すものと同じ Requirement 構造です。今回、requirements get を再度呼び出してはいけません。
• 有効な product_id + requirement_id、旧 Portal URL、ホットハンドオフ、または Skill をまたいだ復元の場合：次を実行します。

cawplan qa-insights requirements get <product_id> <requirement_id>

上記いずれかの方法で requirement_data を取得した後、requirement_data はメタデータ（summary、module_tree_node_id、knowledge_document、redirect_url など）としてのみ使用します。要件本文は要件 Markdown から取得する必要があり、次の手順を順番に実行します。

cawplan knowledge documents get --dataset <dataset_id> --document <document_id> --refresh --no-interactive
cawplan qa-insights testpoints list <product_id> <requirement_id>

<dataset_id> / <document_id> は、requirement_data.knowledge_document の dataset_id / id から取得します。--refresh を必ず指定してください（ローカルキャッシュは 12 時間有効で、書き込み後も無効になりません）。返された data.content が要件 Markdown です。これを requirement_md として扱い、意味に沿って読みます。見出しや章があると仮定してはいけません。要件名には summary を使用し、data.name は使用しません。knowledge_document.status をゲート判定に使用してはいけません。

• Requirement データソースが SUCCESS で、requirement_md を取得できた場合：requirement_md と、requirement_data 内の module_tree_node_id、summary、メタデータを統一して使用します。
• knowledge_document が存在しないか空の場合：統一メッセージを出力して停止します：需求文档暂未就绪。新建需求可能需要稍等片刻；历史需求若长期为空，可能未关联文档。请稍后重试。 / The requirement document isn't ready yet. A newly created requirement may need a moment; for an older requirement that stays empty, no document may be linked. Please try again later.（会話の言語に合わせてどちらかを選択）。TestPoints は取得せず、Case も生成しません。
• documents get が SUCCESS 以外の場合、またはレスポンスに data.content がない場合（code:"SUCCESS" でも data.status:"not_found" の場合を含む）：同じ統一メッセージを出力し、コマンドが返した msg を付記して停止します。古いデータは使用しません。再試行を待ちません。
• data.content が空、または空白のみの場合：「需求文档为空」 / "The requirement document is empty"（会話の言語に合わせてどちらかを選択）と報告して停止します。
• TestPoints が SUCCESS の場合：data.test_points[].sort_order に従って使用します。id → TestPointId、title → TestPointTitle、tags[] → / で連結した Tag、group → Group にマッピングします。
• 404 / not_found：事実をそのまま報告し、古い会話データは使用しません。
• FAILURE または UNKNOWN：事実をそのまま報告します。成功したと偽ったり、やみくもに再試行したり、推測したりしてはいけません。
• 要件の内容とテストポイントが明らかに一致しない場合は、展開前に簡潔な疑義を1つ出力し、黙って無視してはいけません。

display-id fast-path が省略するのは、同一リクエスト内で resolver の直後に重複して行われる GET のみです。ターンをまたぐキャッシュは作成しません。後続の新しいホットハンドオフのターン、または A2 完了後の復元では、上記の非 fast-path に従って requirements get を実行し、その後 TestPoints を更新します。

3. TestPoints がない場合は処理を停止

更新後に test_points.length === 0 の場合、Case を作成してはいけません。インタラクション文言の Reference を読み込み、枠 2 を表示します。この分岐は、未アーカイブの枠 3 と同時に適用されません。

• 「テストポイントをすぐ生成する」→ resume_intent = testcase を設定し、cawplan-testpoint-generate を読み込みます。アーカイブ成功後、§2 に戻ります。
• 「まず要件の内容を見る」→ §2 で取得済みの requirement_md を表示します（長すぎる場合は見出しごとに分けて表示）。その後、判断を待ちます。
• その他 / 自由回答 → 指示に従って処理するか、内容を言い換えて確認します。

4. cases[] を作成して展開する

cases[] は会話内の作業上の信頼できる情報源です。最初のターンではタイトルのみの Case 集を生成し、以降は SQA が指定したものだけ詳細を展開します。

Case の受け入れ不変条件

• 1 つの Case は、まとまりがあり、単独で実行可能な中核検証シナリオです。1 つの TestPoint から複数の Case を展開できます。チェックポイントが多いという理由だけで Case を分割してはいけません。1 つの Case に複数の Step/Expected を含めることができます。
• 入力、境界、異常、ロール、入口、環境、状態が、親 TestPoint のパス、境界、または期待結果に直接影響する場合は、必要な具体化として扱えます。最小限で十分なシナリオのみを残し、機械的な直積は作りません。
• 各 Case は既存の親 TestPoint に紐づける必要があり、アーカイブのメインパスでは testPointId が空であってはいけません。紐づけ先のないカバレッジ不足は疑義として記録し、A2 に戻します。cases[]、プレビュー、エクスポートには含めません。SQA が口頭で追加した Case にもこのルールを適用します。
• 分割・統合、EP、複数オブジェクト、離散値/連続値、フィールドの書き方は、執筆ガイドラインに従います。能動的なシナリオの構築は Steps に含めます。各 Step には、空でなく判定可能な Expected を必ず1つ対応させます。シグナルは UI に限定されません。

親テストポイントがない場合の疑義メッセージは、会話の言語に合わせます。

この項目に対応するテストポイントがありません。戻ってテストポイントを1つ追加し、更新してから展開してください。 この項目に対応するテストポイントがありません。戻ってテストポイントを1つ追加し、更新してから展開してください。

テストポイントごとの完了基準

同じ親 TestPoint について、以下の条件をすべて満たすまでは次へ進みません。

1. ソースで明示された値、分岐、制約、状態をすべて処理します。ソースでカバーを明示的に求められている離散値またはカテゴリは、それぞれ個別の Case にします。「それぞれ」「各」「選択したものと同じ」などの表現でまとめてはいけません。
2. 直接関係し、必要な同値クラス、境界、異常、状態遷移を、組み合わせの爆発を招かない最小限で十分なシナリオでカバーします。
3. 各候補は、単独で実行できる一貫した中核シナリオである必要があります。同じ実行で順番に確認するチェックポイントは、同じ Case 内で対応づけたままにします。
4. 同じ失敗モードの重複は執筆ガイドラインに従って統合します。親の目標範囲外の候補は疑義/A2 に移します。

5. コンテンツの状態と展開先の振り分け

状態	出力	トリガー
タイトルのみ	Group ごとに分割した4列のタイトル表	デフォルトの初回
Partial	今回指定された Case の展開ブロックのみを出力	「第 X 条を展開」など
Full	まだ展開されていない Case をすべて補完した後、現在の全 Case の展開ブロックを出力	SQA が「すべて展開」と明示的に依頼

詳細の Preconditions / Steps / Expected は、Case ごとにまとめて生成する必要があります。Partial では、SQA に代わって Case を選択しません。

大量の場合の振り分け

Partial の batchCount は今回指定された件数です。Full の batchCount は現在未展開の件数であり、プール全体の件数や展開済み件数とは関係ありません。

1. batchCount <= 10：確認せず、そのまま展開します。
2. batchCount > 10 で、リクエストに「すべて展開」より強い、振り分けを省略する明示がない場合：インタラクション文言の Reference を読み込み、枠 4 のみを表示します。先に Steps を並べてはいけません。「すべて展開」は Full を選ぶだけであり、振り分けを省略する指示にはなりません。
3. ユーザーが「どれだけ長くてもすべて出す」「確認せずすべて展開」などを明示した場合：「すべて展開」として扱い、枠 4 の表示を行いません。

枠 4 の選択肢：

選択肢	動作
すべて展開	今回のバッチを Markdown で展開し、その後 Partial/Full hint を出力
すべて Steps 付きでエクスポート	会話には展開しません。未展開の Case をサイレントに補完し、exportMode = fill_then_export を設定します。自己検証後、直接エクスポートして結果を通知し、枠 5 をスキップします
今は展開しない	停止し、より小さい範囲の指定を待ちます

枠 4 は出力方法の振り分けであり、確認のゲートではありません。「続行しますか」に変更してはいけません。

6. プレビューとレビュー

唯一のレンダリングルール

• プレビューには会話内の Markdown のみを使用し、artifact、インタラクティブコンポーネント、HTML は使用しません。
• Title／Partial／Full はすべて Group ごとに分割します。Group が 1 つだけの場合も同様です。ブロックの先頭は ### {Group} とします。タイトル表の列は「# / 用例タイトル / 優先度 / 親テストポイント」に固定し、「グループ」列を追加してはいけません。
• Partial／Full では、該当する Group の下に #### の見出し行を使用し、番号、Title、Priority、親テストポイントを保持したうえで、Preconditions / Step / Expected を列挙します。
• 「親テストポイント」列には必ず cases[].testPointTitle を使用し、testPointId、display_id、その他の ID を表示してはいけません。各 Group の先頭行には testPointTitle の全文を記載します。その行がブロックの先頭ではなく、かつ直前の行の cases[].testPointTitle と一字一句同じ場合に限り、表示上「同上」としてもかまいません。ブロックの境界で比較をリセットし、「第 N 条と同上」とすることは禁止します。
• cases[]、interim JSON、CSV には常に testPointTitle と group の全文を保持します。「同上」は Markdown 上でのみ使用します。
• SQA による変更後は、影響を受ける範囲のみを再描画します。タイトルの変更時は該当 Group のタイトル表を再描画し、ステップの変更時は該当 Case の展開ブロックのみを再描画します。既存の展開内容は cases[] に保持します。

プレビューのセルフチェック

レンダリング前に、確定的な誤りを修正してから出力します。

• 親テストポイント列に ID が表示されている、空欄になっている、または Group の先頭行に「同上」／「第 N 条と同上」と記載されている場合 → 該当 Case の testPointTitle 全文をそのまま使って修正します。
• steps と expected の要素数が一致しない、または空要素がある場合 → 作成規則に従って修正します。信頼できる対応付けに必要な情報がソースにない場合は、処理を停止して SQA に修正を依頼します。
• タイトルがソースの文言を一字一句保持していない、または正当な末尾表現が誤って付加されている場合 → cases[].title を確実に修正します。展開表示の Expected がソースの値を保持していない疑いがある場合は ⚠源已有文案未保留 とだけ示し、自動で上書きしません。長いソース文から当該ステップに関連する部分のみを残すことは、妥当な場合があります。
• 親テストポイントまたは要件の Markdown で、複数の個別値／カテゴリを網羅するよう明示されているにもかかわらず、「それぞれ／各／選択したものと一致」などとまとめて 1 つの Case にしている場合 → 作成規則に従って項目ごとに分割してからレンダリングします。ソースが例のみを示している場合、または項目ごとの網羅が必要か判断できない場合は、勝手に拡張しません。

それ以外のソフトヒント：「同上」の参照誤りには ⚠同上引用错误 を付けます。Step に検証を示す動詞が含まれている場合は ⚠疑似预期混入步骤 を付けます。Expected にソースの根拠がない疑いのある具体値がある場合は ⚠具体值待核 を付けます。親タイトルに複数値の可能性を示す手がかりがあるものの、必須の個別値一覧かどうか確認できない場合は、作成規則を再確認し、⚠疑似未展开取值清单 を付けてもかまいません。Config/Idea/Storyboard などのプロセス段階名を理由に誤って分割してはいけません。

セルフレビューのタイミング

タイトル表示での初回プレビュー前と、エクスポート JSON の組み立て前に、それぞれ 1 回実施します。fill_then_export の 2 回目のチェックは、静かに補完した後に実施します。Completion Criterion、ソース値の忠実性、孤立した Case がないことを確認し、分割・統合とフィールドの契約について作成規則を参照します。チェックリストを SQA に表示してはいけません。

SQA が編集した行の先頭ラベルは 【已调整】／【新增】／【存疑】 とします。削除項目はプレビュー末尾の「已移除」セクションに痕跡を残し、メモリー上では status: 'removed' とします。疑義リストは「〔対象箇所〕＋〔疑義の理由〕＋〔推奨アクション〕」の形式とし、該当がない場合は「無」と記載します。

Priority は作成規則に従って P0～P3 を設定します。

7. 確認の境界

操作	確認
タイトル表示または展開プレビュー	不要
SQA による CSV の明示的なエクスポート	ファイル書き込みの確認は不要ですが、先にボックス 5 の手順を実行します。ボックス 4 でエクスポートを選択済みの場合を除きます
削除、タイトル変更、または SQA が指定した調整	不要。メモリーを更新して部分的に再描画し、自動エクスポートはしません
Case セット全体の再生成	必要です。cases[] とすべての手動編集／削除の痕跡を消去し、GET データから再構築します

8. エクスポート

SQA が明示的にエクスポートを要求した場合、またはボックス 4 で「すべてステップ付きでエクスポート」を選択した場合に限り、CSV に書き出します。「CSV をエクスポート」と直接指示された場合は、インタラクション文言の Reference を読み込んでボックス 5 を表示します。これを省略してはいけません。

ボックス 5 の選択肢：

• 「現在のドラフトをエクスポート」 → exportMode = as_is とします。展開されていない Case は steps: []／expected: [] のまま保持し、最終的に実行可能な用例ではないことを応答で説明します。
• 「すべてステップ付きでエクスポート」 → exportMode = fill_then_export とします。作成規則に従って、展開されていないすべての Case を静かに補完し、cases[] を更新します。会話内には展開せず、エクスポート前のセルフチェックを実行します。

モードの処理後：

1. status: 'removed' を除外します。removed の行や status を snapshot に書き込んではいけません。
2. 展開済みの Step／Expected に対して、最後のフォールバックチェックを実行します。まず cases[] を修正し、信頼できる修正ができない場合に限り、エクスポートを拒否して SQA にプレビュー上での修正を依頼します。stderr をそのまま出力してはいけません。
3. references/csv-template-mapping.md を読み込み、記載されている interim JSON の契約に従って scripts/export_to_csv.js を呼び出します。CSV を手書きしたり、インラインで作成したり、エクスポート処理を一時的に書き換えたりしてはいけません。
4. スクリプトが失敗した場合は stderr を正確に報告し、上流の JSON を修正して再試行します。エクスポートしても作業状態はロックされず、何度でも実行できます。

9. 表示

初回表示時のサイレント処理

Requirement の解析・読み込みから、TestPoints の更新を経て、タイトル一覧を初めて表示するまで、内部処理や ID を出力しません。ただし、product_id がない場合、404／読み込み失敗、ボックス 1／2／3 での強制停止、要件の内容に不一致の疑いがある場合は除きます。

タイトルの初回表示に正常に進んだ場合、最初に表示する文言は次のいずれかを一字一句そのまま使用します。{N} は TestPoint の数です。Requirement の表示タイトルを挿入してはいけません。

已读取需求与 {N} 条测试点,先按测试点列出用例标题(未展开步骤): 要件と {N} 件のテストポイントを読み込みました。まず、テストポイントごとに用例タイトルを一覧表示します（ステップは未展開）：

対応する Markdown プレビュー、状態ヒント 1 つ、疑義リストを出力します。すべての Case を自発的に展開してはいけません。Full を表示するかどうかは、§5「大量データの振り分け」の結果のみで判断します。

Hints（会話の言語に応じていずれかを使用）：

• Title：要改就直接说(改标题、增删);想看某条用例步骤说「展开第 X 条」;要导出就说「导出 CSV」。 / 変更したい場合は、そのままお伝えください（タイトルの編集、追加／削除）。ステップを見るには「第 X 条を展開」、エクスポートするには「CSV をエクスポート」とお伝えください。
• Partial：这 N 条的步骤已展开。想看别的就说「展开第 X 条」或「全部展开」;要导出就说「导出 CSV」(未展开条目只有标题,属于草稿)。 / これら N 件のステップを展開しました。他の項目を見るには「第 X 条を展開」または「すべて展開」とお伝えください。エクスポートするには「CSV をエクスポート」とお伝えください（未展開の項目はタイトルのみで、ドラフトのままです）。
• Full：全部 N 条已展开完毕。要导出就说「导出 CSV」。 / N 件すべてを展開しました。エクスポートするには「CSV をエクスポート」とお伝えください。

エクスポート後は簡潔な応答と疑義リストのみを出力し、Case 本文は出力しません。

• 状態：已导出:<路径>。 / エクスポートしました：<パス>。
• Refs：CSV 已含 Refs 列;导入 TestRail 时映射到 References 后,可用 testrail-link 回链用例。 / CSV には Refs 列が含まれています。TestRail へのインポート時に References にマッピングすると、testrail-link を使用して用例にリンクできます。
• fill_then_export の場合は追記：已把未展开用例补齐步骤后导出(对话未铺开)。 / 未展開の用例にステップを補完してからエクスポートしました（この会話内では展開していません）。
• as_is で未展開の項目が残っている場合は追記：这是当前草稿;未展开条目只有标题,不作为最终可执行用例。 / これは現在のドラフトです。未展開の項目はタイトルのみで、最終的な実行可能用例ではありません。

SQA に対して、製品の表現として「スクリプト」を使用してはいけません。CSV はエクスポート時点の snapshot であり、Markdown は会話内の作業状態です。

Session state

• Binding：product_id、requirement_id、requirement_md（本次读取）与 requirement_data 中的 module_tree_node_id、summary、GET 得到的 TestPoints。
• Draft：内存 cases[]。Partial 回合只渲染本次点名行，可附“已展开: #1,#3”；之前展开内容继续保留。
• 无磁盘状态：不建 .memory 或跨会话缓存；interim JSON 只在导出瞬间存在于 /tmp/，随后删除。
• v1 不支持离线 CSV 编辑回传，无 is_edited；A3 不 POST/PATCH CawPlan。

References

• references/test-design-methods.md — 从父 TestPoint 发现必要候选场景
• references/testcase-writing-spec.md — 字段、拆合、优先级和校准例
• references/interaction-prompts.md — 框 1～框 5 完整双语文案与 fallback
• references/csv-template-mapping.md — interim JSON、13 列、脚本调用与导出格式