uipath-maestro-case

UiPath Case Management 作成アシスタント

sdd.md から UiPath Case Management の定義を作成します。テナントのリソースを tasks/registry-resolved.json に解決してから、uip maestro case sdd convert で caseplan.case を出力し、ドキュメントから判断できない部分を、該当するプラグインごとの JSON レシピを使用して補完します。SDD が計画そのものです。中間の計画ファイルはなく、変換された caseplan.case も計画ファイルではありません。これは、計画を言い換えたものではなく、そこから生成される成果物です。

作成時の不変条件： 変更を伴う uip maestro case コマンド（cases|stages|tasks|*-conditions ... add|update|remove。tasks add-connector を含む）は使用せず、--help で調べることも禁止です。CLI は、スキャフォールディング、メタデータの読み取り、検証／デバッグ、ランタイム操作、ソリューションの同期／アップロードにのみ使用してください。正確な構文が必要な場合に限り、case-commands.md を参照してください。CLI を利用できることや、最終的な validate が必要であることは、このルールの例外にはなりません。

sdd.md が存在しない場合、ケースの設計は uipath-planner だけが担当し、この会話内で Case Design Lane を実行します。このスキルが独自に設計することはありません。このレーンでは、妥当な前提に基づく設計、Listen → Sketch → 設計時の完全なテナントリソース解決、必須の他の経路の検討、意思決定を先に示す8セクションの Case Review を実施します。Build への回答が同意となり、テンプレートに準拠した sdd.md を作成した後、このスキルが直ちに

uip solution init、Phase 1、

および後続のフェーズを続行します。同じ引き継ぎは、sdd.draft.md の最終化にも適用されます。既存の sdd.md を上書きしてはいけません。

対象範囲： sdd.md からの新規構築と、既存の caseplan.case に対する対象を絞った編集です。references/brownfield.md を参照してください。Studio Web のケースでは、公開によってサーバー上の変更が上書きされないよう、まず uip solution download または solution projects resync で現在のサーバー状態を取得してください。

このスキルを使用する場合

以下の場合に使用します。

• sdd.md から Case Management プロジェクトを構築する。
• SDD がない状態でケースを作成する。この会話内で設計を uipath-planner に引き継ぐ。
• SDD から実装タスクを生成する。
• 対象を絞った指示に基づき、既存の caseplan.case を編集する。ステージ／タスクの変更、条件、トリガーなどが該当します。
• ケース JSON スキーマ、ノード、遷移、タスク、ルール、SLA、またはランタイムのケースインスタンスに関する質問に答える。

.xaml → uipath-rpa、.flow → uipath-maestro-flow、またはケースの文脈外にある単独のエージェント／API／プロセスには使用しないでください。

重要なルール

1. 設計の引き継ぎと SDD の優先性。 sdd.md が存在しない場合は、リファレンスを読んだりテナントコマンドを実行したりする前に、この会話内で直ちに uipath-planner の Case Design Lane を呼び出してください。この場で独自にヒアリングしたり、設計用サブエージェントを作成したり、汎用の Build Plan 承認を求めたり、設計のみを行ったりしてはいけません。このレーンで行う単一の Case Review には、必ず次のセクションを含めます：Case Snapshot；Primary Journey；Other Paths Considered；SLA and Escalations；Rules and Outcomes；Resources and Integrations with design-time resolutions；Decisions I Made；Review Flags。すべてのステージ／タスク、種類、有効化／グループ化、必須ステータス、ルーティング／結果、SLA のコンテキストを明記します。sdd.md には、完全なデータコントラクト、変数、タスクの入力／出力を別途記載します。Build の選択肢にはルール12を反映し、Build への回答だけを同意として扱います。修正時には、変更された Review セクションのみを再表示します。承認前に、すべての selected-tasks-completed セレクターが同じステージ内のアドホックでない兄弟タスクを参照できる必要があります。このレーンは早い段階で sdd.md を作成し、その後このスキルが

uip solution init <SolutionName> と Phase 1

を実行します。 明示的に求められない限り、追加のプロンプトを使わずに進めます。設計のみのリクエストでは、ルール 3 の設計のみの例外に従い、sdd.md の作成後に停止します。sdd.draft.md を確定する場合は、対象のベース名を sdd.md としてレーンのファストパスを使用します。sdd.md を上書きしてはいけません。 2. セッションをまたいでも、設計後の入力は SDD のみです。 ユーザーが提供した、または以前に作成された sdd.md を信頼し、検証、情報の補完、暗黙の推測は行いません。設計承認と同じ会話内では、フェーズ中に再読み込みするのではなく、sdd.md を作成したインメモリモデルを使用します。ただし、ルール 8 のフェーズ 2 およびフェーズ 3 の開始時チェックポイントでは、コンテキストが圧縮されている可能性があるため、必ず再読み込みします。ビルドフェーズで曖昧さがある場合は AskUserQuestion を使用します。作成時に監視していなかった SDD を読む前に、受領確認として先頭 40 行を Read します。`` マーカーと、値が passed の Template validation ヘッダーの両方が存在する必要があります。それ以外の場合は、プランナーのテンプレート準拠チェックリストに戻ります。 3. フェーズ 1 のレジストリゲート。

uip login status --output json を実行し、その後 uip maestro case registry pull を、キャッシュの確認、引き継ぎ、解決、Phase 1 の書き込みより前に実行します。ユーザーが Rule 18 の検索結果なしのゲートで Force pull and re-resolve を選択した場合、または sdd resolve が古いキャッシュを報告した場合（以下を参照）を除き、1 セッションにつき 1 回まで実行します。このセッションでプランナーレーンが実行され、プルが成功し、SDD に書き込んだ場合は、キャッシュを再利用します。レーンのコンテキスト内で得られた解決結果を使い、検証のみの計画を行います。結果をそのまま tasks/registry-resolved.json に保存し、キャッシュのエントリをスポットチェックして、ゲートの決定を実行し、古いエントリや欠落エントリのみ再解決します。それ以外の場合は、フルゲートを実行します。ログインまたはプルに失敗した場合、Phase 1 を停止します。この高速パス以外では、uip maestro case sdd resolve "<SDD_PATH>" --out tasks/registry-resolved.json --output json で解決します。このコマンドは、タスクの種類ごとのインデックスを選択し、完全一致検索とフォルダーによる絞り込みを実行して、すべてのタスクについて Rule 10 の台帳を 1 回の呼び出しで書き込みます。Data.Warnings が古いキャッシュを報告した場合（Data.Scope.cache.stale: true）、確認を求めずに uip maestro case registry pull --force --output json を 1 回実行し、その後 sdd resolve を再実行します。 通常のプルでは、24 時間以内のキャッシュが再利用されるため、更新するのは --force だけです。この警告は、通常なら --force の実行時に求められる確認の代わりとなる、古さの証拠です。強制プル後も古い状態のままであれば、その旨を報告して続行します。その台帳を手作業で作成してはいけません。解決処理は 1 秒もかからずに書き込めますが、手作業では実測で約 50 秒かかり、同じ実行で後から紐付けられたリソースにも selected: null が記録されていました。残っている作業は Data.Unresolved[] だけであり、手作業で行うのもその作業だけです。absent エントリでは、Rule 18 のゲートに進む前に、registry-discovery.md の型横断フォールバックとソリューション内の兄弟項目チェックを実行します。ambiguous エントリ、つまり SDD のフォルダーで絞り込めなかった完全一致が複数ある場合は、いずれかを選んで決着させてはいけません。absent と同様に Rule 18 のゲートに進み、回答がなければ <UNRESOLVED> のままにしてプレースホルダーにします。これらの手動検索では、uip maestro case registry search "<Name>" --type <type> --output json と ~/.uip/case-resources/<type>-index.json は同じレコードを返しますが、形式は異なります。インデックスファイルは camelCase のオブジェクト（entityKey、folders）を含むフラットなリストです。registry search は各ヒットを Data.Resources[] = {ResourceType, Resource: {…}} としてラップし、キーには PascalCase（EntityKey、Folders）を使用します。CLI が sdd resolve を不明なコマンドとして報告した場合（ErrorCode: "invalid_argument"、終了コード 3）、registry-discovery.md に従ってすべてのタスクを手動で解決し、その旨を 1 行で伝えます。プルが成功するまでは、キャッシュファイルの欠落は更新前提条件の不成立であり、検索結果が 0 件であることを意味しません。成功した後に限り、完全一致の検索結果が空の場合やインデックスがない場合を、検索結果なしの処理に進めます。SDD を信頼してください。プルで更新されるのは検出情報のみです。プランナーレーンは設計時の解決を担当します。テナントに紐付く作業が最初に現れた時点でログインとプルを遅延開始し、1 回の Case Review ゲートで ID を解決して、SDD のセルと解決台帳を記録します。そこでスキーマの検出は行いません。 設計のみの例外： sdd.md または sdd.draft.md で明示的に停止し、caseplan.case、ソリューション、ビルドを作成しない場合は、テナントレジストリ、接続、スキーマ、ユーザー検出のコマンドを実行しないでください。意図された名前を維持し、ID は <UNRESOLVED> のままにして、後続の連携作業は返信で報告してください。代替の計画ファイルには記載しないでください。この例外は、ユーザーがリソース／ID の解決、レジストリの更新、古い監査結果の置き換え、tasks/registry-resolved.json、または tasks/recipients-resolved.json を要求した場合には適用されません。その場合は通常のゲートを実行し、ID を解決し、台帳を書き込み、Phase 2 の前で停止してください。 4. 作成前に変換してください。 Phase 2 の冒頭で、Rule 3 のレジストリゲートの後、uip maestro case sdd convert "<SDD_PATH>" --resolved tasks/registry-resolved.json --out "<SolutionName>/<ProjectName>/<PLAN_FILE>" --output json を実行して計画を出力してください。ここで <PLAN_FILE> は case init がシードした計画ファイルです（Rule 14：caseplan.case、または .case という名前が使われる前の CLI では caseplan.json）。計画ファイルは 2 階層下に置きます。Rule 24 で作成するプロジェクトディレクトリ内です。ソリューションルートにも sdd.md の隣にも置かないでください。浅い階層に書き込むと、すべての評価ツール、validate、bindings sync、solution pack が参照する場所に何も置かれないか、caseplan.case が 2 つできてビルドが曖昧になります。caseplan.case の大半は SDD で決まります。要素ごとに再導出するより、一度変換するほうが適切です。パーサーがすでに出力する内容を手作業で作成するのは、コストの高い方法であり、ドキュメントとの乖離も起こりやすくなります。その Data.Unresolved[] は作業リストです。resource-binding は Phase 1 のバインディングで解決し、output-type は uip maestro case splice --described（Step 9.8）で解決し、connector-context は Check 12 で解決します。これは最低限のリストであり、上限ではありません。変換時にスキップされたと認識された項目だけが記載され、誤って出力された項目は記載されません。記載されない既知の不足点として、すべての jsonSchema 変数は body: null の状態で出力されます。SDD の行をもとに、global-vars/impl-json.md § jsonSchema type に従って body と _jsonSchema を補完してください。Data.Unresolved[] は残作業の完全なリストです。 出力された計画を一度読み、そこにある項目を解決して、そこで停止してください。変換で出力済みの内容を再導出、再検証したり、参照を読み直したりしないでください。変換後の計画に含まれている構造は確定済みです。再検討すると、変換で節約できた作業量全体よりもコストがかかります。要素を作成する前に変換してください。 Rule 24 に従って、まずプロジェクトのスキャフォールドを作成してください。case init は空でないディレクトリを拒否するため、先に変換すると project.uiproj がなく、マニフェストも登録されていないプロジェクトになります。その後すぐに変換を実行してください。先にステージ、タスク、条件、変数を手作業で作成してから変換するのは避けてください。上流では検出されない、必須のタスクエントリルールの確認も含む完全な手順については、references/phased-execution.md を参照してください。

バージョンガード。 CLI が sdd または convert を不明なコマンドとして報告した場合（ErrorCode: "invalid_argument"、終了コード 3）、Phase 2 を手作業で作成し、その旨を 1 行で伝えてから続行してください。このメッセージなしの終了コード 3 は実際の失敗であり、フォールバックではありません。CLI をインストール、再インストール、または変更してはいけません。

5. 解析済みの読み取りには --output json が必要です。

6. 作成する内容にはプラグインのリファレンスを使用し、convert が出力した内容には使用しないでください。 計画時には、該当する planning.md を cat してください。実行時には、そのプラグインの形状を手作業で作成または修正する前に、プラグインの impl-json.md を cat してください。対象となる形状は、Data.Unresolved[] が名前を挙げるもの（ルール 4）、ステップ 12 が報告するもの、およびプラグインの sdd convert がカバーしないものです。変換済みの計画に含まれている形状については、impl-json.md を読む必要はありません。convert が出力しており、ルール 4 で確定するため、そのレシピを開いてファイル全体を読み込んでも何も変わらず、全ファイルの読み取りコストがかかります。何を開く場合でも、ルール 25 に従って必要なセクションを読み、JSON の形状を推測してはいけません。

7. ビルドは SDD に対して損失があってはなりません。 中間計画ファイルを作成してはいけません。計画は sdd.md であり、それを言い換えると内容にずれが生じます。caseplan.case には、SDD の各ステージ、タスク、トリガー、条件、SLA ルール、変数、引数ごとに 1 つの要素を含め、明示的なデフォルトも含めてください。その大半は sdd convert が出力し（ルール 4）、残りは後から補います。このルールが定めるのは完成した成果物に含まれる内容であり、各要素を手作業で書くことではありません。有効な明示的ルール／セレクターはすべてそのまま保持し、無効な selected-tasks-completed セレクターは却下して修正してください。ステージまたはタスクの **Description:** 行は、その要素の description に一字一句そのままコピーしてください。ブロックに **Description:** がない場合に限り、**Design Rationale:** を使用してください。それ以外の理由付け、SLA の理由付け、条件のルーティング／有効化に関する理由付けは build-issues.md に記載してください。また、要素に description スロットがない場合も、**Description:** は build-issues.md に記載します。すべての Inputs 行、バインディングモード、値を保持してください。JSON オブジェクトリテラルはそのまま保持してください。input.value にはネイティブオブジェクト、または JSON エンコードされた文字列を使用します。SDD に明示されている場合に限り、=js:／=jsonString: を追加してください。Outputs は plugins/variables/io-binding/planning.md に従って射影し、演算子とオペランドを保持してください。SDD の出力行には -> または = が必要です。スキーマから検出された、演算子のない出力は、作成対象となる SDD の行ではありません。同じ名前の -> 行を単純化してはいけません。greeting -> greeting は、スキーマから検出された演算子のない greeting とは異なります。— のプレースホルダーはオペランドではありません。認識できない行や曖昧な行については AskUserQuestion を使用し、黙って省略してはいけません。グリーンフィールドビルドは最初から再生成し、ブラウンフィールド編集では ID を保持してください。各タスクノードには、SDD の Entry Condition テーブルと Activation Mode から導出した独自の entryConditions を含めてください。似たタスクのグループに一度だけ書くのではなく、タスクごとに記述してください。validate が出すのは Task has no entry rules という警告だけですが、これが抜けていると case debug がいつまでも停止したままになります。references/implementation.md を参照してください。

   完了条件は常に --strict --sdd です。デフォルトプロファイルの Valid ではありません。 Step 12 で uip maestro case validate <caseplan.case> --strict --sdd sdd.md を実行し、ビルド完了を報告する前に、すべての STRICT_SDD_* の検出結果と、sdd convert の Data.Unresolved[] エントリーをすべて解消してください。通常の validate は、ステージ、タスク、条件、SLA ルール、出力タイプが欠けているプランでも Valid を返します。その Valid をビルド結果として報告してはいけません。

8. ビルドゲート。 Phase 1 は自動的に Phase 2 へ進みます。解決後に停止するのは、依頼に設計のみ、Phase 1 のみ、先にレビュー、またはビルドしないことが明示されている場合だけです。Phase 2 と Phase 3 の開始時に sdd.md と tasks/registry-resolved.json を読み直してください。コンテキストが圧縮されている可能性があります。

9. 未解決のリソース。 ID を捏造してはいけません。tasks/registry-resolved.json では <UNRESOLVED: ...> を維持してください。プレースホルダータスクには type、displayName、構造フィールド、および data: {} が必要です。条件では引き続きその TaskId を参照します。プレースホルダーのイベントトリガーは、レンダリングフィールドと、sdd convert が出力する serviceType、entryPointId、および objectName のコンテキストエントリー（SDD Source）のみを含む data.inputs を維持してください。entry-points.json のエントリーを追加し、トリガーエッジは作成しないでください。references/placeholder-tasks.md および impl-json.md § Placeholder fallback を参照してください。

10. 解決監査。 tasks/registry-resolved.json には、タスクごとに、stage、task、taskType、cacheFile、searchQuery、matches、selected、rationale という正確なキーを持つオブジェクトを1つずつ格納し、解決済みの I/O／レビューのメタデータも含めます。uip maestro case sdd resolve --out がこれを書き込みます（Rule 3）。これらのエントリーを保持する resolved 配列と、unresolved、scope を含むオブジェクトです。この形を維持してください。再度ラップしたり、さらに深くネストしたり、手作業でフラット化したりしてはいけません。 コンシューマーはエントリーを検索しますが、その検索には深さの上限があります。台帳を見つけられない場合、台帳が存在しない場合と区別できず、正当なプレースホルダーが警告ではなく検証エラーになります。解決処理では、各リソースを {name, identifierField, identifier, folder} として正規化して記録します。タスクの識別情報はこれらのフィールドから読み取り、キャッシュオブジェクトをそこへ再コピーしてはいけません。台帳のその他の内容は、該当するエントリーに Edit で追加します。具体的には、gateDecision、以下の識別スロットマーカー、wiringNotes、および resolve がカバーしないトリガーとコネクターに紐づく条件の各エントリーです。同一セッションのプランナー台帳は、受け取った形のまま（Rule 3）保存します。コンシューマーはどちらの形も読み取ります。gateDecision を追加するのは、ユーザーが設計時のリソースゲートに回答した場合だけです。デフォルトの保留には含めません。matches は更新済みキャッシュにある完全一致名の集合です。selected は一致した候補、または実際に検索して候補がなかった場合の null です。真の不一致、つまり resolve が unresolved[] に列挙したエントリー、または手動検索で空だったエントリーには、Rule 9 が要求する <UNRESOLVED: <reason>> テキストを保持する、そのタスクタイプに応じた識別スロットも必ず含めてください。非コネクタータスクでは taskTypeId、コネクタータスクとトリガーでは typeId / connectionId です。resolve がテナントリソースを使用しないため selected: null として記録する wait-for-timer エントリーは不一致ではなく、マーカーも不要です。コネクターエントリーは resolve ではなくコネクターパイプライン（connector-integration.md）で解決するため、その結果に従ってマーカーを設定します。コネクターに対する resolve の selected: null は、resolve が検索しなかったことだけを意味します。selected: null だけでは不一致を記録したことになりません。Phase 2 がスキーマを取得する代わりにプレースホルダーを出力するかどうかを判断する際に読むのはマーカーです。同一セッションのプランナー台帳はそのまま保存し、Rule 3 に従って検証／拡張します。解決台帳と registry-resolved.json は機械処理専用です。Case Review を含め、ユーザーに提示してはいけません。

11. タスク間参照。 "Stage Name"."Task Name".output_name と、plugins/variables/io-binding/impl-json.md に記載された共通の出力参照 ID アルゴリズムを使用してください。参照元の出力の .id を使用します。.id のないカスタム = 出力に限り、検証済みのルートコンパニオンの .id を使用してください。再割り当てされた出力の .var は使用しないでください。コネクタータスクの名前は uip maestro case spec で、非コネクタータスクの名前は uip maestro case tasks describe で確認します。大きな =js: 式では vars.$xref('Stage','Task','output') を使用し、これは Step 11.5 で解決されます。references/bindings-and-expressions.md を参照してください。

12. ビルドレビューの希望。 ジャーニー開始時に一度だけ確認します。設計引き継ぎでは、これを Case Review のビルドオプション（Build it — straight through または Build it — pause at the build preview）に含めます。提供された SDD ではロードマップの後に一度だけ確認します。非対話型の実行、および希望が記録されていない再開実行では、straight-through をデフォルトにします。Phase 2 から Phase 3 への移行時に validate --skeleton-v2 を試し、応答で v2 が不明または未対応と明示された場合に限り、旧形式の --skeleton へ一度だけフォールバックします。通常は invalid_argument／終了コード 3 です。終了コード 3 だけでは不十分です。実際の v2 エラーは報告してください。検証結果の指摘は、この助言的なゲートを停止させません。straight-through の場合、確認を求めず続行します。pause-at-preview の場合は references/phased-execution.md に従います。AskUserQuestion で Publish for review / Skip publish and continue / Abort を提示します。公開する場合は、リソースを更新し、必須のフィルターを指定してアップロードし、フォローアップの前に DesignerUrl を表示してから、Continue to implementation / Abort を尋ねます。Phase 4 の再試行上限、Phase 5、Phase 6、Phase 7、および Phase 6 の修正後の再公開では、常にハードストップを維持します。

13. Orchestrator の自動デバッグや公開は禁止です。 uip maestro case debug は実際のメール、メッセージ、API 呼び出しを実行します。Phase 7（case pack → solution pack → solution publish）はテナントに公開します。それぞれについて、個別に AskUserQuestion で同意を得る必要があります。

14. アーティファクトの I/O。 プランファイルは caseplan.case です。 作成するプランの名前は caseplan.case とし、エントリーポイントでは caseplan.case.bpmn を指定し、パッケージ記述子では両方のファイルを指定してください。プロジェクトにすでに別の Studio Web 名のプランがある場合、たとえば caseplan.json、case.stage.json、default.stage.json、または以前の case init が用意したファイルがある場合は、そのファイルをプランとして使用します。そこに書き込み、検証してください。CLI と Studio Web は存在する最新の名前のみを読み取り、case pack は別のプランのサイドカーを指定するエントリーポイントを拒否するため、隣に2つ目のプランファイルを作成してはいけません。case init が使用できず、T01 の直接 JSON スキャフォールドでプロジェクトを作成する場合（Rule 24）、その CLI は .case に対応していないため、プラン名を caseplan.json にします。このスキル内の caseplan.case はすべて、そのファイルを指します。caseplan.case、sdd.md、sdd.draft.md、tasks/registry-resolved.json、tasks/trigger-spec-cache.json、tasks/spec-cache.<elementId>.json、id-map.json、entry-points.json、build-issues.md には、ハーネスのファイルツールのみを使用してください（例外の bindings_v2.json は uip maestro case bindings sync が生成します。手作業で書き込んではいけません。caseplan.case にも、認められた生成方法が1つあります。Phase 2 の最初に uip maestro case sdd convert --out が sdd.md から初期プランを出力します。それ以降の編集はすべて、他のファイルと同様に Write／Edit で行います。tasks/registry-resolved.json にも同様の方法があります。Phase 1 で uip maestro case sdd resolve --out が書き込み（Rule 3）、その後の追加はすべて Edit で行います。tasks/spec-cache.<elementId>.json は3つ目の例外です。数十 KB に及ぶ応答を手作業でコピーするとサブツリーが気づかれないまま欠落するため、uip maestro case spec --output json の出力をこのファイルへリダイレクトしてください。このリダイレクトは一度限りの書き込みであり、このルールで許可されている唯一のものです。その後、このファイルを編集したり、対象となる他のアーティファクトへリダイレクトしたりしてはいけません。各イベントトリガーでは、T 番号のキーを tasks/trigger-spec-cache.json に Write／Edit でマージします）。変更には Write／Edit（または apply_patch）のみを使用してください。禁止されるのは書き込みの手段だけです。 これらのファイルをスクリプトで変更してはいけません。sed -i、perl -pi、awk、jq、Python、Node による書き換え、シェルリダイレクト、tee、cp、mv、install、rsync、または /tmp 以下を含む、エージェント作成のあらゆる種類のスクリプトを使用してはいけません。読み取りに制限はありません。 対象アーティファクトおよび ~/.uip/case-resources/ では、cat、sed -n、head、rg、jq による射影、python3 -c による読み取りをすべて使用できます。このルールが禁止するのは、アーティファクトのスクリプトによる作成または編集であり、スクリプトによる確認ではありません。caseplan の検証には uip maestro case validate --strict --sdd を使用します（Rule 7）。caseplan.case が約 30KB を超える場合は、全体を読み込むのではなく、case-editing-operations.md に記載されたプレビュー／詳細の読み取り手順に従ってください。Bash は、読み取り専用の調査、ファイルシステムにアクセスしない UUID v4 の生成、CLI メタデータ、validate、format、bindings sync、splice、sdd parse、sdd resolve、sdd convert、debug、ソリューションのスキャフォールド／アップロードに使用できます。プレフィックス付き ID はインラインで選択します。caseplan.case は整形済みの形式で書き込み、書き込むたびに uip maestro case format "<caseplan.case path>" --output json を実行してください。これは唯一認められた再整形方法です。圧縮されたプランには Edit／apply_patch を適用できません。このルールに違反したことが確認された perl -pi／sed -i の事例はすべて、圧縮ファイルから始まっていました。format の正確な出力と冪等性については、case-commands.md § uip maestro case format を参照してください。

15. 実行可能なリソースとサイドカー。 Phase 4 の前に、公開、debug、リソース更新をスキップする場合でも、Step 12 の Checks 7、9、11、12 を実行してください。selected が null ではないリソースをプレースホルダーにしてはいけません。完全なルートバインディングとともに data.name と data.folderPath を保持し、uip maestro case bindings sync でサイドカーを再生成してください。また、resourceKey はコピーしたテナント ID／UUID ではなく、独自のデフォルト値と整合させてください。チェックごとの対象範囲と修正方法は、implementation.md § Step 12 を参照してください。すべてのコネクターコンテキストの connection エントリーは、宣言済みの Connection ルートバインディングを参照する必要があります。コネクタータスクでは uip maestro case splice がこれを設定します。このコマンドは、保存済みの仕様に基づき、=bindings.<id> の参照と両方のルートバインディングを一度の呼び出しで書き込みます。イベントトリガーノードとコネクターに紐づくルールでは、仕様の =bindings.<id> 参照、ConnectionId、FolderKey のルートバインディングを同じ編集で設定します。接続 ID が folderKey に入っている場合、またはコネクターの bindings[] に Connection バインディングがない場合、そのリソースは決して解決されません。完了条件は Rule 7 のとおり --strict --sdd です。各フェーズでどのプロファイルを実行するか、連結実行を禁止するルール、CLI 1.202 のバージョンガードについては、case-commands.md § uip maestro case validate を参照してください。不整合を修正して再確認し、残っている場合は Phase 4 に進まないでください。resources refresh の前には毎回 Check 7 を繰り返してください。**プランがコネクター接続をバインドする場合は、アップロードや debug の直前だけでなく、必ず uip solution resources refresh を実行してください。**また、アップロードまたは debug のたびに再実行してください。このコマンドが resources/*/connection/*.json を生成するため、実行しないと、検証に合格するプランでも接続できないソリューションがパッケージ化されます（bindings-v2-sync.md）。アップロードフラグと DesignerUrl の報告については、phased-execution.md § Phase 5 を参照してください。

16. 引き継ぎの契約。 uipath-planner の Case Design Lane はサブエージェントとしてではなく、この会話内で呼び出してください。設計、解決、レビュー、SDD の作成はそれが担当し、このスキルはソリューションの初期化から再開します。ユーザー向けの表現では、引き継ぎに触れず、1つの連続したフローとして説明してください。利用できない場合は、その旨を一行で伝え、sdd.md または承認済みの設計の貼り付けを依頼して停止します。製品をまたぐ計画は、プランナーへのプレーンテキストの提案として扱います。確認されていない SDD の読み取りを行う前に、Rule 2 の受領確認のスポットチェックを適用してください。

17. タスクタイプは限定されています。 caseplan.case のタスク type は、必ず次のいずれかと完全一致させてください。process、agent、rpa、action、api-workflow、function、business-rule、case-management、execute-connector-activity、flow-process、http-request、document-extraction、wait-for-connector、external-agent、external-workflow、wait-for-timer。プラグインのフォルダー名や CLI 名、wait-for-event、その他の独自値を使用してはいけません。未対応のタイプは引き続き未対応です。references/case-schema.md と Plugin Index を参照してください。

18. 検索結果が空の場合のゲート。 同一セッションの台帳にユーザーの gateDecision がある場合は、再確認せずその指示を実行してください。resolve-at-build → プレースホルダー、create-during-build → その場で作成、pick:<name> → そのリソースをバインドします。決定がない場合は、デフォルトの保留であり同意ではありません。ゲートを一通り実行してください。一致候補が0件の場合は、(name,type) ごとにまとめて1回の AskUserQuestion を行い、次を提示してください。Force pull and re-resolve、Use placeholders for all、および作成可能なリソースがあり registry --local に対応している場合のみ Create missing resources inline。同じ名前の完全一致候補が複数あり、SDD でフォルダーが絞り込まれていない場合は、順番で選んではいけません。キャッシュのリソースはテナントへの登録順に並んでいるため、先頭の候補は最初にデプロイされたものです。別チームのフィクスチャやデバッグ用コピーであることもよくあります。同じバッチで、どの候補が対象かを尋ねてください。候補ごとにフォルダー名を示す選択肢を1つずつ用意し、Use a placeholder も提示します。回答がない場合や非対話型の場合は、<UNRESOLVED> のままにします。作成するのは選択された agent、api-workflow、business-rule リソースのみです。uipath-agents、uipath-api-workflow、uipath-rules を呼び出してください。SDD の内容から作成を推測してはいけません。その他の空のタイプではプレースホルダーのみを使用します。I/O が同じ選択済みリソースは、1回のビルドで共有できます。I/O が異なる場合は後で分割し、名前はアンカーに保持します。SDD の更新には許可が必要です。registry-discovery.md § 1c、Create-on-Missing、および § MUST Confirm を参照してください。

19. レイアウト。 トップレベルの layout: {} のみを出力してください。ノードの position、style、measured、width、height、zIndex、またはエッジの data.waypoints を出力してはいけません。位置を計算しないでください。

20. グローバル出力 ID。 Phase 3 終了時に Step 12 の Check 8 を一度実行してください。これは必須です。合格するまで Phase 4 に進まず、CLI validate で代用してはいけません。

21. エッジを作成しないでください。 schema.edges は [] のままにしてください。TriggerEdge／Edge オブジェクトを作成してはいけません。ステージ間のフローは条件で表し、最初のステージでは case-entered を使用します。読み取り専用のエッジ形式については、case-schema.md Appendix に記載されています。

22. グローバルイベントと SLA 応答。 グローバル外部イベントは、中断型のセカンダリステージの wait-for-connector エントリーとして一度だけモデル化してください。SLA 応答は、notify-only、start-task、enter-stage、exit-stage、exit-case から明示的に選択します。start-task 応答はステージのエントリーではなく、後続タスク自体の sla-status-change エントリーに設定します。中断型かどうかは、実行中の作業が停止、一時停止、または別経路へ転送されるかによって決まります。並行監視では Interrupting: No を使用し、セカンダリのままにします。sla-status-change では slaId を指定し、リスク対応の場合のみ escalationId を追加します。応答が指定されていない場合、リスク状態と違反はいずれも通知とします。プライマリステージ間でルールを複製しないでください。references/sla-response-shapes.md と SLA Response Map を参照してください。

23. 正式な引数の ID。 variables.inputs[].id と variables.outputs[].id は、v と8文字を組み合わせた合成 ID とし、name／var と異なるものにしてください。コンパニオン名をコピーしてはいけません。Phase 3 終了時に Step 12 の Check 10 を一度実行し、不適合があれば非対話型で ID を再生成してください。CLI validate では確認されません。global-vars/impl-json.md § Formal-arg slot ID format を参照してください。

24. uip solution init でスキャフォールドを作成し、ソリューションディレクトリ内から uip maestro case init を実行します。 まず cd <SolutionDir> を実行してください。uip solution init の後に && でつないでも条件を満たせず、プロジェクトがソリューションの外に作成され、ソリューションがもう一つ自動的にスキャフォールドされます。Data.SolutionRegistration.Status が Registered または AlreadyRegistered であることを確認してください。case init を利用できない場合に限り、implementation.md § Step 6 の T01 ダイレクト JSON スキャフォールドを使用してください。case-commands.md § case init を参照してください。

25. 変更を加える前に、その変更で使う記述を読みます。 参照資料の形状、手順、制約、検証ルールを使う最初の Write/Edit の前に、それらを定めているセクション全体を読んでください。見出し（参照資料の見出し、または用語の検索）から該当箇所を見つけ、同じレベルの次の見出しまで読みます。ファイル全体を読む必要はなく、ファイルの `` が表示される必要もありません。例外 — ブラウンフィールドのレシピ： edit-recipes-guide.md のレシピで対象となる編集では、そのレシピだけを読めば十分です。別の参照資料を読むのは、レシピで指定されている場合に限ります。検索結果だけ、記憶、または関連する別の参照資料を読むだけでは不十分です。読んだセクションが別のセクションを参照している場合は、そのセクションも読んでください。コンテキスト圧縮後や以前に読んだ内容を参照できない場合は、セクションを読み直してください。

26. ラベル名とタスク名は一意にします。 ステージの data.label 値はケース内で一意にします。タスクの displayName 値はすべてのステージを通じて一意にし、完全一致で、前後の空白を削除せず、: を含めないでください。display name が指定されていない場合はリソース名が割り当てられ、一意性の対象になります。条件の displayName 値は、4つすべての条件スコープを通じてケース内で一意にします。ただし、フロントエンド独自のデフォルト名（Entry rule <N>、Exit rule <N>、Completion rule <N>、Stage complete、Stage exit、Tasks completed rule、Previous task completed）は例外で、自由に重複でき、番号を付け直しません。独自に付ける名前には、ステージ単位やタスク単位ではなく、ラベルの種類ごとにケース全体で通し番号を付けてください（case-schema.md § Condition name uniqueness）。名前はフェーズ 1 で割り当ててください。後から名前を変更すると、SDD、計画、ID マップ、名前をキーとする参照にも手を加える必要があります。

ルーティング

条件	進行
新規ケース、SDD が提供されている、caseplan がない、または仕様から再構築する	グリーンフィールド： 必要に応じて引き継ぎを行い、その後フェーズ 1～7
既存の caseplan があり、対象を絞った編集の意図がある	ブラウンフィールド： 引き継ぎとフェーズ 1～7 を省略し、brownfield.md を使用

ブラウンフィールドでも、最新状態の取得、デバッグへの同意、Orchestrator への公開の同意が必要です。また、フェーズ 5～7 の契約を再利用します。

ユーザー向けロードマップ

ルーティング後、詳細な作業に入る前に一度だけ出力してください。5 行以内にしてください。フェーズ、モード、ファイル名、実装の仕組みは示さないでください。

• SDD のない新規ケース： 1. ご依頼内容を確認し、作業を進めながら UiPath テナントの状態を確認して設計上の判断を行います。 2. ケースのスナップショット、主要なジャーニー、その他の経路、SLA への対応、ビジネスルール、リソース、および行ったすべての判断をまとめたレビュー用資料を一度に提示します。ご確認のうえ、修正点をお知らせください。 3. 中断せずに構築と検証を行い、参考資料として完全な技術設計書も併せて保存します。 4. 実行または公開の前に、確認のため一時停止します。
• SDD のある新規ケース： 1. 設計を読み、利用可能な UiPath リソースを確認します。 2. 質問は一つです。最後まで続けて構築するか、途中のプレビューで一時停止するかをお選びください。 3. 以降は中断せずに計画、構築、検証を行います。 4. 実行または公開の前に、確認のため一時停止します。
• 対象を絞った編集： 1. ケースの最新状態を取得します。 2. ご依頼の変更を適用します。 3. 更新したケースを検証します。 4. 実行または公開の前に確認します。

ワークフロー

判断を先に済ませ、その後は承認が必要な地点まで無人で進めます：

必要に応じて設計を引き継ぐ → フェーズ 1 計画 → フェーズ 2 プロトタイピング → フェーズ 3 実装 → フェーズ 4 検証 → フェーズ 5 公開 → フェーズ 6 デバッグ → フェーズ 7 Orchestrator に公開。

呼び出し開始時に、以下の該当する開始ブロックを、引き継ぎの開始時またはフェーズ 1 の開始時に一度だけ提示します。ステータス文は「アンチパターン」の制限に従う必要があります。

新規開発の開始時：

このケースの構築方法と、判断を仰ぐために作業を止める箇所を説明します：

• 計画 — 仕様からタスク計画を作成して続行します。先に確認したい場合は、最初にお知らせください。
• プロトタイピング — レビュー可能なケースフロー（ステージ、タスク、トリガー、ルール、SLA／エスカレーション。コネクタルールではスタブを使用）を構築します。Studio Web のプレビューのためにここで一時停止するかどうかは、最初に決めていただきます。開始時に一度だけ確認し、構築の途中では確認しません。
• 実装 — タスクの入力／出力、コネクタスキーマ、解決済みのコネクタルールの詳細を接続します。
• 検証 — 検証を実行し、エラーを修正します。
• 公開（任意）— Studio Web にアップロードするかどうかは、お客様が選択します。
• デバッグ（任意）— ケースを実際に実行するかどうか（実際のメール／API 呼び出しを含む）は、お客様が選択します。
• Orchestrator に公開（任意）— ケースを Orchestrator に公開するかどうかは、お客様が選択します。

引き継ぎでは、次の文を前置きします：まず、いただいた情報をもとにケースを設計し、その過程で UiPath テナントを確認します。ケースの概要、主要なジャーニー、その他の経路、SLA 対応、ビジネスルール、リソース、行ったすべての判断を含む、判断優先のレビュー資料を一度提示します。確認は一度だけで、その後に構築します。詳細な技術設計書（sdd.md）は参照用として同じ場所に保存します。

既存案件の場合は、references/brownfield.md の簡潔な開始フローを使用します。

設計の引き継ぎ

トリガーは二者択一です。解決済みのパスにベース名に sdd を含む .md ファイルが存在しない場合は、引き継ぎます。プロンプトで別の SDD ベース名が指定されている場合は、Read + Write を使用して ./sdd.md にコピーし、レーンを呼び出してはいけません。.md ファイルが指定されていない場合は、./sdd.md を使用します。ケースレビューの前に、計画／プラグインの参照資料を読んだり、テナントコマンドを実行したりしてはいけません。明示的な構築なしの設計依頼の場合は、承認後にプラグイン参照、スキーマ、レジストリ、接続、ユーザーの調査を行わずに sdd.md を作成し、その時点で停止します。構築の代わりに計画ファイルを作成してはいけません。プランナーが作成したドラフトと sdd-viewer.html はプランナー側に残します。利用できない場合は、SDD を依頼して停止します。

フェーズ 1 — 解決

references/planning.md を読み、以下を作成します：

• tasks/registry-resolved.json：完全な解決監査記録。テナントの識別情報のみを含め、SDD の構造や契約を複製してはいけません。
• ルール 18 で Create が選択されている場合：許可されたサブエージェント経路を通じて、選択されたエージェント／API ワークフロー／ビジネスルールを同じソリューション内の兄弟要素として構築し、ソリューションが存在することを確認して登録し、リソースを更新し、再検出してバインドします。registry-discovery.md § Create-on-Missing を参照してください。

tasks/ は sdd.md と同じ階層に置き、ソリューション／プロジェクト内には置きません。依頼で構築前に停止するよう明示されていない限り、フェーズ 2 に自動で進みます。最初に sdd.md と台帳を再読します。

Phase 2 — プロトタイピング

references/implementation.md と references/phased-execution.md を読み、ステップ 6～11.9 に従います。

1. ステップ 6：uip solution init を実行し、次にソリューションディレクトリ内から uip maestro case init を実行します（ルール 24）。続いて sdd convert --out を使い、caseplan を case init がシードした計画ファイルに変換します（ルール 4）。インストール済み CLI に case init または sdd convert がない場合は、plugins/case/impl-json.md の T01 直接 JSON レシピを代替手段として使います。いずれの場合も、ルート構造の参考にしてください。

2. ステップ 6.1：ルール 9 のプレースホルダーを含む、手動、タイマー、イベントの各トリガーを設定し、トリガー ID を記録します。

3. ステップ 6.2：グローバル変数と引数を設定します。In 引数の elementId は sourceTriggers が指定するトリガーを参照します。空欄の場合はプライマリトリガーを参照します。

4. ステップ 6.3：entry-points-sync.md に従い、宣言された In/Out 引数から entry-points.json を同期します。job-attachment の definitions ブロックは、参照元からバイト単位でそのまま出力してください。MimeType.description 内側の引用符のエスケープ（\" の単一エスケープ）を正確に再現してください。再エスケープ（\\\"）したり、引用符の対応を調整したりしないでください。JSON が壊れます。

5. ステップ 7：ステージを設定します。

6. ステップ 9：タスク形状を設定します。コネクター以外は、空の値を含む完全な data.inputs[] を設定します。コネクターは typeId／connectionId のみとし、未解決のリソースにはプレースホルダーを使用します。

7. ステップ 11：安定した ID を持つ SLA／エスカレーションオブジェクトを設定します。

8. ステップ 10：4 種類すべての条件スコープを設定します。コネクターの待機処理には、解決済みかどうかにかかわらず、正規のスタブを使用します。

9. ステップ 11.9：ルール 12 のフォールバック動作を用いて、情報提供用のスケルトン検証を行います。

10. Phase 2→3 の設定を適用します。プレビュー分岐では、リソースを更新し、フィルター済みのソリューションをアップロードし、DesignerUrl を出力したうえで、規定の続行確認を行います。中止する場合は build-issues.md を作成して終了します。

Phase 3 — 実装

SDD のタスク詳細ブロック、tasks/registry-resolved.json、caseplan.case（ステップ 9.6）を再度読み、ステップ 9.7、9.8、10.5、11.5 に従います。

1. uip maestro case spec でコネクタースキーマ／デフォルト値を解決します。
2. io-binding/impl-json.md を使用して、すべてのタスククラスの I/O をバインドします。
3. 解決済みのコネクターにバインドされた条件スタブを、その場でアップグレードします。未解決のコネクターはスタブを保持し、報告します。
4. 式内の vars.$xref マーカーを解決します。
5. 解決済みリソースの出力、保持、resourceKey、およびコネクターの完全性を確認します。

Phase 3 のチェックに合格したら、Phase 4 に直接進みます。

Phase 4 — 検証

Phase 3 の境界でステップ 12 を 1 回実行します。このステップでは、チェック 1～15 を実行します。これには、チェック 7 のサイドカーとの整合性、チェック 8 のグローバル出力 ID の一意性、チェック 9 のリソース出力／保持、チェック 10 の正式引数 ID、チェック 11 の resourceKey の整合性、チェック 12 のコネクター完全性、チェック 15 のすべてのタスクに空でないエントリールールが設定されていることが含まれます（validate はエントリールールがない場合に警告するだけです）。次に、uip maestro case validate を完全に実行します。再試行は最大 3 回とし、再試行の前には毎回編集を行います。3 回目に失敗したら、AskUserQuestion で必ず停止し、次の選択肢を提示します：Retry with fix／Pause for manual edit／Abort。ステップ 12.1 を使って build-issues.md の内容を要約します。

Phase 5 — 公開

完了レポートを提示してから、AskUserQuestion で必ず停止し、次の選択肢を提示します：Publish to Studio Web／Skip to Debug（ステップ 13）。公開する場合は、リソースを更新し、必須の出力フィルターを使ってアップロードして DesignerUrl を出力し、いずれの場合も Phase 6 に進みます。

Phase 6 — デバッグ

AskUserQuestion（ステップ 15）で必ず停止し、次の選択肢を提示します：Run debug session／Continue to publish。実行する場合は、リソースを更新して uip maestro case debug を実行し、完了後は Continue to publish が選択されるまで繰り返します。デバッグを自動的に実行してはいけません。

フェーズ 7 — Orchestrator への公開

停止して確認する AskUserQuestion（ステップ 16）：Publish to Orchestrator / Done。公開する場合は、次の順に実行します。

1. uip solution resources refresh
2. uip maestro case pack <SolutionDir>/<ProjectName> <SolutionDir>/dist --output json
3. uip solution pack <SolutionDir> <SolutionDir>/dist --output json
4. uip solution publish <packagePath> --wait --output json

case pack は caseplan.case.bpmn を作成するため、必須です。validate では作成されません。case の .nupkg ではなく、solution pack の .zip を公開します。<packagePath> は推測せず、Data.Packages から読み取ってください。Done を選ぶと終了します。

リファレンスのナビゲーション

必要な情報	リファレンス
SDD を使わずに設計する	uipath-planner の Case Design Lane、ルール 16
SDD からリソースを解決する	references/planning.md
SDD から caseplan を構築する	references/implementation.md
Brownfield の編集	references/brownfield.md、一般的な編集：references/edit-recipes-guide.md
フェーズの契約	references/phased-execution.md
編集の仕組み	references/case-editing-operations.md
スキーマ	references/case-schema.md
使用可能な CLI	references/case-commands.md
トラブルシューティング	references/troubleshooting-guide.md
レジストリの解決	references/registry-discovery.md
バインディング／式	references/bindings-and-expressions.md
コネクターの統合	references/connector-integration.md
Case spec の入力詳細	references/case-spec-input-details.md
プレースホルダー	references/placeholder-tasks.md
バインディングのサイドカー	references/bindings-v2-sync.md
孤立した solution リソースの削除	bindings-v2-sync.md § 孤立した solution リソースの削除
エントリーポイント	references/entry-points-sync.md
SLA レスポンス	references/sla-response-shapes.md

プラグインインデックス

構造: case/planning.md、stages/planning.md、sla/planning.md、global-vars/planning.md、io-binding/planning.md、および logging/impl-json.md。

タスク:

スキーマの type / SDD 値	プラグインの計画リファレンス	CLI の describe type
process	process	process
agent	agent	agent
rpa	rpa	rpa
action	action	action
api-workflow	api-workflow	api-workflow
function	function	function
business-rule	business-rule	business-rule
case-management	case-management	case-management
execute-connector-activity	connector-activity	connector-activity
flow-process	flow-process	flow-process
http-request	http-request	—（sdd convert が書き込みます）
document-extraction	document-extraction	—（sdd convert が書き込みます）
wait-for-connector	connector-trigger	connector-trigger
external-agent	connector-activity § External agents and automations	external-agent
external-workflow	connector-activity § External agents and automations	external-workflow
wait-for-timer	wait-for-timer	wait-for-timer

Schema-kebab は唯一の JSON 値です。プラグイン名と CLI 名は相互に置き換えられません。サポート対象外の type には wait-for-event が含まれます。

トリガー: manual、timer、および event。

条件: stage-entry-conditions、stage-exit-conditions、task-entry-conditions、および case-exit-conditions。

いずれかの条件スコープでコネクターに紐づくルールを使用する場合は、case spec --type trigger で作成した rule.uipath が必要です。コネクターのルールだけでは、CLI の validate が通過しても Studio Web では無効です。connector-trigger-impl.md を参照してください。

アンチパターン

• 通常のステージにエントリー条件を設定せずに残さないでください。最初のステージでは case-entered を使用します。それ以外の通常ステージには、到達可能な先行ステージが必要です。エッジは廃止されています。validate はこれをエラーにします（CASE_MGMT_STAGE_ENTRY_CONDITION_MISSING）。
• ここで設計したり、Case Review の承認前に Phase 1 を開始したり、要約版の SDD から構築したりしないでください。設計、他の経路の分析、テンプレートへの準拠はプランナーが担当します。
• 各要素の後に検証したり、間に編集を挟まずに検証を繰り返したりしないでください。Phase 2 の検証は参考情報です。Phase 4 の検証が正式なもので、--strict を実行します。デフォルトプロファイルの Valid のまま完了しないでください。
• tasks/tasks.md、T 番号付きのタスクリスト、または SDD を別の形で書き直したものを作成しないでください。計画は SDD です。Phase 2 では sdd convert（Rule 4）で SDD から caseplan.case を生成して残りを完成させ、Step 12 の validate --strict --sdd sdd.md で成果物を SDD と照合します。生成された caseplan.case は成果物であり、書き直しではありません。この禁止事項は文章による計画に適用され、コンバーターの出力には適用されません。
• caseplan.case 全体を一度の Write で出力しないでください。sdd convert で生成し、それ以降の変更は、変更していない兄弟要素を保持する対象限定の Edit で行います。中断後は計画と sdd.md を読み直してください。まだ Write が必要なケース（ブラウンフィールドのセクション書き換え、case init を利用できない場合のスキャフォールド）の書き込み手順は、case-editing-operations.md § セクションごとの一括書き込み契約 にあります。
• ツール呼び出しの間に、独立した説明文を出力しないでください。状況説明は次のツール呼び出しにまとめます。通常の文章は 200 トークン未満にし、許可リストに含まれる着手説明、停止前の前置き、完了報告、DesignerUrl の表示、検証の要約は 500 トークン未満にしてください。Building、Composing、Writing、Drafting、Generating、Now I'll、Next、Approach、Strategy、Plan、Let me など、または同等の表現を使って、これから行う作業を予告しないでください。
• タスクの順序に関するセマンティクスを保持してください。順次モードでは、順序付きの data.tasks セットとタスクごとに 1 つの runs-sequentially ルールを使用します。これに current-stage-entered を追加しないでください。並列の current-stage-entered は独立した作業にのみ使用し、selected-tasks-completed は必須の合流にのみ使用します。イベント起動型タスクにはイベント／条件ルールを使用します。手動起動型／アドホックタスクには adhoc ルールを 1 つ使用し、isRequired: false を設定し、追加のエントリーイベントは設定しません。adhoc はアクティベーションモードであり、タスクの種類ではありません。
• セカンダリステージは割り込み型の例外レーンとしてモデル化します。case-management:Stage、data.stageType: "secondary"、isRequired: false を設定し、ステージとエントリーの両方に Interrupting: Yes を設定します。Interrupting: No は、並列の SLA 監視にのみ使用します。return-to-origin を使用してください。セカンダリステージを通常フローとして接続したり、必須完了の対象に含めたりしないでください。
• グローバルイベントや SLA ルールをプライマリステージごとに複製しないでください。ケースを完了するには、ルートの metadata.caseExitRules[] ルールで marksCaseComplete: true を設定する必要があります。ステージの完了だけでは不十分です。完了を伴わない結果には marksCaseComplete: false を使用します。
• 生成された caseplan.case.bpmn を編集しないでください。caseplan.case を content/ の下に配置しないでください。条件付き SLA の式構文を捏造しないでください。名前空間のない =js: 識別子は validate --strict でエラーになります（STRICT_JS_UNKNOWN_IDENTIFIER）。実行時に条件が解決されるまでは、条件を自然な文章で記述してください。
• ソリューション／プロジェクトに tasks/ を配置しないでください。tasks/ は sdd.md の隣に置きます。
• Rule 16 の設計引き継ぎと、Rule 18 でゲートにより選択されたエージェント／API ワークフロー／ビジネスルールのインライン作成を除き、他のスキルを自動的に呼び出さないでください。設計、草案の確定、計画のみの文書作成にサブエージェントを起動しないでください。
• インストール済み CLI を読んで、その出力を解釈しないでください。validate の指摘には要素のパスと修正方法が示されます。修正箇所は caseplan、またはその形状を定義している参照先であり、node_modules/@uipath/**/dist ではありません。バンドルされたチャンクを grep したり、node -e で比較処理を再実装して結果を予測したりすると、計画ではなくツールにターン数を費やすことになります。ある夜間タスクでは 151 回のコマンドのうち 56 回をそこで使い、時間切れになりました。指摘が不明確な場合は、指定された要素と参照先を読み直し、メッセージに示された内容を修正して先に進んでください。それでも指摘が続く場合は、/uipath-feedback で報告してください。
• 問題が発生した場合は uipath-feedback を使用してください。

お困りですか？ /uipath-feedback を使って報告を送信してください。