report-creator

レポート作成

dxs CLI を使用して RDLX-JSON レポートを作成し、デプロイするワークフローです。レポートは Datex Studio 内の ActiveReportsJS でレンダリングされます。

重要な原則： コードを書く前に計画します。最終的な JSON を作成する前に、レイアウトのプロトタイプを構築します。

プロトタイピングとデザイン： このスキルには専用のビジュアルプロトタイピングワークフローがあります。ブラウザーでライブプレビューを行うには、dxs report create + dxs report batch + dxs studio open を使用します。ユーザーから明示的な依頼がない限り、外部のブレインストーミング用ビジュアルツール、ブラウザーベースのモックアップツール、その他のプロトタイピングツールは使用しないでください。Studio のライブプレビューがデザインツールです。

作成方法：

• 新しいレポートでは、ライブプロトタイピングを使用します。空の .rdlx-json を作成し、dxs report create + dxs report batch を使って段階的にレイアウトを構築し、Studio でライブプレビューします。
• レイアウトの反復中に対象を絞って編集する場合は、段階的な CLI 操作（add/set/move/remove/batch）を使用します。
• CLI でまだサポートされていない高度な構造（複雑な BandedList のグループ化、単純なヘッダー／詳細を超えるカスタム Tablix の列／行階層など）に限り、JSON を直接編集します。

リファレンス（共通）：

• ../datex-studio-shared/branch-setup.md — ブランチと接続の選択
• ../datex-studio-shared/report-authoring/design-standards.md — Datex のデザイン言語： カラーパレット、タイポグラフィ、テーブルのスタイル、フィールドのラベルと値のパターン、グリッド配置、レポートのカテゴリ
• ../datex-studio-shared/report-authoring/json-structure.md — ドキュメントテンプレート、要素の JSON 形式、式のクイックリファレンス
• ../datex-studio-shared/report-authoring/design-patterns.md — 座標系、レイアウトパターン、要素のサイズ設定
• ../datex-studio-shared/report-authoring/cli-commands.md — CLI の詳細な構文：バッチ操作、tablix、画像、データセット、set/move/remove
• ../datex-studio-shared/report-authoring/sample-data.md — ライブプレビュー用の対応する .data.json ファイル
• ../datex-studio-shared/report-authoring/dataset-rules.md — DataSet の管理：CommandText のルール、コレクションの処理、日付の注釈
• ../datex-studio-shared/report-authoring/deploy-patterns.md — アップロード、プレビュー、検証のパターン
• ../datex-studio-shared/report-authoring/troubleshooting.md — よくある RDLX-JSON と CLI の間違いおよび修正方法
• ../datex-studio-shared/studio-management.md — Studio のライフサイクル：確認、起動、クリーンアップ

リファレンス（作成固有）：

• references/ssrs-migration.md — 従来の SSRS（.rdl）レポートを NextGen RDLX-JSON に変換する方法
• references/examples/ — 理想的な例： 実環境のコーパス分析から抽出した、一般的なレポートタイプの標準パターン

オーケストレーションモデル

このスキルは、新しいレポート作成の最上位オーケストレーターです。 検証ゲートを各フェーズの間に設けながら、依存スキルを順番に呼び出します。このスキルを実行する前に、依存スキルを個別に呼び出さないでください。このスキルが適切なタイミングで適切なコンテキストとともに呼び出します。

report-creator (this skill — orchestrates everything)
  │
  ├── Phase 1: Setup + Requirements
  │     ├── Select branch + connection
  │     └── Invoke `requirements-gathering` skill (routes to right source)
  │           ├── DevOps work item → invokes `devops-requirements` skill
  │           ├── Mockup/screenshot → visual analysis
  │           ├── User conversation → structured Q&A
  │           ├── Existing report (.rdl, .rdlx-json) → extract structure
  │           └── Document/spec → extract fields and layout
  │     Output: standardized requirements brief
  │
  ├── Phase 2: Schema Discovery + Datasource Creation
  │     ├── Invoke `schema-explorer` (via `datasource-creator`) for EVERY entity
  │     ├── Invoke `datasource-creator` for EVERY datasource
  │     ├── Invoke `odata-execution` to verify queries
  │     │
  │     ├── ▶ COVERAGE GATE: requirements brief vs datasource fields
  │     │   For EVERY field in the requirements brief:
  │     │   - Is it mapped to an OData path? If not, why?
  │     │   - Is it included in a datasource config? If not, why?
  │     │   - Does it need a calculated expression? Document it.
  │     │   Present gap report to user. Do NOT proceed until gaps are
  │     │   resolved or explicitly accepted.
  │     │
  │     └── Output: validated datasource configs + field coverage report
  │
  ├── Phase 3: Layout Prototype (live in Studio)
  │     ├── Create report + open in Studio
  │     ├── Build sections incrementally with user feedback
  │     ├── Add DataSets + sample data
  │     └── Output: working .rdlx-json with sample data preview
  │
  ├── Phase 4: Report Finalization
  │     └── Verify DataSets, refine expressions, validate
  │
  └── Phase 5: Deploy & Verify
        └── Upload, preview with real data, provide test parameters

意図の振り分け：新規作成と既存レポートの変更

ブランチ上の既存レポートを変更するようユーザーから依頼された場合（例：「受領レポートに列を追加して」「BOLのラベルを変更して」「ブランチ64のレポートを更新して」）、代わりにreport-editorスキルを呼び出します。Report-creatorはレポートをゼロから新規作成するためのものです。

ユーザーが「変更」と言っていても、そのレポートがブランチ上にまだ存在しない場合は、ユーザーに確認します：「そのレポートはまだこのブランチにありません。ゼロから作成しますか？」承諾された場合は、report-creatorを続行します。

計画の境界： フェーズ1～3は計画中（ExitPlanModeの前）に完了します。プロトタイプはレポートファイルそのものです。フェーズ4はフェーズ3の続きから始まります。フェーズ4～5は計画の承認後に実行します。

フェーズ1：セットアップと要件

ブランチの選択

branch-setup.mdに従って、アクティブな組織を特定し、リポジトリを一覧表示して機能ブランチを選択し、API接続を確認します。

成果物の収集（任意）

プロセスの成果物（スキーマのメモ、クエリ、レポートファイル、サンプルデータ、プレビュー画像）をディスクに保存するか、ユーザーに尋ねます。推奨場所：./reports/<report-name>/。

保存する場合は、成果物用のディレクトリを作成し、次の命名規則を使用します。

ファイル名	内容
01-schema-exploration.md	エンティティの説明、フィールド一覧、関連
02-field-mapping.md	フィールドマッピング表
<report-name>.rdlx-json	レポートファイル（フェーズ3で作成し、フェーズ4で調整）
<report-name>.data.json	Studioのライブプレビュー用サンプルデータ
04-query-building.md	段階的なクエリ作成手順と、最終確認済みクエリ
<report-name>-preview.svg	dxs report previewによるプレビュー画像
requirements/	ダウンロードした添付ファイルと要件概要（DevOps）

要件の収集

スキーマの調査やデータソースの作成を行う前に、必ず要件を収集して文書化してください。ユーザーが「とにかく作って」と言ったり、曖昧な説明をしたりした場合でも、この手順を省略してはいけません。要件は後続のすべての作業の基盤です。この手順を省略すると、フィールドマッピングの誤り、データの不足、レイアウトのやり直しにつながります。

requirements-gatheringスキルを呼び出してください。 このスキルは適切な情報源（DevOpsの作業項目、モックアップ、会話、ドキュメント、既存レポート）への振り分けを行い、次の内容を含む標準化された要件概要を作成します。

• フィールド一覧と意味上の役割（各フィールドの名前だけでなく、意味も記載）
• レイアウトへの期待
• ビジネスルールと計算フィールド
• パラメーター

要件概要は、フェーズ2（スキーマの調査とデータソースの作成）への入力であり、その後に続く網羅性チェックの基準となります。

理想形： レポートの種類に合った標準パターン（例：ナンバープレートラベル、BOL、納品書）について、references/examples/を確認してください。これらは実際のレポートのコーパス分析から抽出され、必須要素、一般的な任意フィールド、レイアウトプロパティ、構造上の類型を定義しています。理想形を使って要件の網羅性を確認し、レイアウトの判断を導いてください。これにより、この種類のレポートの典型的な外観と、どのようなバリエーションがあるかを把握できます。

SSRSから移行する場合： ソースに.rdlファイルが含まれている場合は、読み取り方とSQLからODataへの変換方法について、references/ssrs-migration.mdも参照してください。

フェーズ 2：スキーマの調査とデータソースの作成

このフェーズでは、すべてのデータソースについて、必ず `datasource-creator` スキルを呼び出してください。この手順を省略してはいけません。以下の場合も同様です。 - 正確なデータモデルを示す既存の例やテンプレートを見つけた場合 - ユーザーがフローデータソースを求めている場合（フローデータソースは OData クエリのデータを集約しますが、基盤となるエンティティにはスキーマ検証が必要です） - 以前の調査ですでにエンティティ構造を把握していると思う場合

例やテンプレートは仮説にすぎません。現在の接続に対するスキーマの調査が検証となります。エンティティの利用可否、プロパティ名、型、リレーションシップは接続ごとに異なります。

Footprint レポート — まず footprint-entity-expert を確認してください。 レポートが Footprint WMS エンティティ（Tasks、Shipments、ArchivedShippingLicensePlateContents、LicensePlate、Lot、Material など）をクエリする場合、footprint-entity-expert スキルには、スキーマメタデータだけでは分からないナビゲーションチェーン、重量計算のルール、エンティティ選択の指針があります。適切なエンティティを対象にスキーマを調査できるよう、datasource-creator を呼び出す前にこのスキルを参照してください。Footprint 以外のアプリでは、この手順を省略してください。

レポートに必要な各データソースについて、次の手順を実行します。

1. datasource-creator スキルを mode = owned で呼び出します（これがデフォルトです）。オーバーライドが適用される場合に限り、standalone を使用します。たとえば、別のレポートまたはコンポーネントが同じクエリを本当に必要とする場合や、フローデータソースが $datasources.<Package>.<name> 経由でアクセスする必要がある場合です（フローの依存関係は常に standalone です）。全リストは ../datasource-creator/references/datasources.md → デフォルトは Owned を参照してください。レポートの場合、「owned」とは、データソースが独立したファイルのまま、フォルダーマニフェストに --owned FILE:ALIAS で登録されることを意味します。レポート JSON にブロックを差し込むことではありません。
2. Datasource-creator は schema-explorer と odata-execution を呼び出し、ライブ接続に対してエンティティとプロパティを検証します。
3. フローデータソースの場合：スキーマの調査で、フローコードがクエリする OData エンティティとフィールドを特定し、例ではなく検証済みのスキーマに基づいて型定義を作成します。
4. 戻り値の概要を収集します。JSON 設定ファイルのパス、参照名、結果の型、in_params、フィールドの概要（フェーズ 3 のステップ 5 で DataSet を作成する際に使用します）。

レポートに必要なデータソースごとに繰り返します。

データ量に関する注意：OData の 5,000 レコード上限

OData エンドポイントは、1 回のリクエストにつき最大 5,000 件のレコードを返します。日付範囲、複数の所有者／プロジェクト、またはレコード数が多くなるその他のディメンションで集約するデータソース（Tasks、ArchivedShippingLicensePlateContents、Shipments など）では、基盤となるフローでページネーションを行わないと、レポートには先頭の 5,000 行だけが通知なく表示されます。

データソースの設計時：

• 単一レコードの OData データソース（例：--param-keys、Shipments(0)）— ページネーションは不要です。
• Tablix を支えるコレクション OData データソース（一般的な明細行クエリ）— 親フィルターで行数がすでに制限されている場合（例：ShipmentLines?$filter=ShipmentId eq X）、通常はページネーションは不要です。
• 日付範囲、倉庫、所有者などにわたって集約するフローデータソース — ページネーションが必須です。datasource-creator の呼び出し時にこの点を伝え、作成する standalone OData データソースで skip inParam を宣言し、フローコードが短いページが返るまでループするようにします。

配線の詳細と標準的なループについては、../datex-studio-shared/flow-code-patterns.md#odata-pagination--the-5000-record-cap を参照してください。必要な場合にページネーションを行わないと、混雑する倉庫ではエラーが発生しないままレポートの集計数が少なくなります。症状は、データが通知なく欠落することです。

カバレッジゲート：要件とデータソースのフィールド

すべてのデータソースを作成した後、要件概要に対するカバレッジを確認してください。このゲートを通過するか、ユーザーが不足を明示的に受け入れるまで、フェーズ 3 に進まないでください。

要件概要のすべてのフィールドについて、次の項目を確認してください。

確認項目	不合格の場合の対応
フィールドにスキーママッピング内の OData パスがある	調査します。エンティティが不足していませんか？パスが深すぎませんか？リンクデータソースまたはフローデータソースを提案します。
フィールドがデータソースの設定に含まれている	追加します。$select／$expand パスを追加して、データソースを再生成する必要がある場合があります。
フィールドに計算が必要（例：tareWeight = GrossWeight - NetWeight）	フェーズ 3 用に式を記録します。入力として必要なフィールドも記録します。
フィールドに対応する OData がない（例：SQL 関数、カスタムビュー）	フローデータソースを提案するか、ユーザーが判断できるよう既知の不足として記録します。

カバレッジレポートをユーザーに提示します。

### Coverage Report: Requirements → Datasources

✅ Covered (N fields): [list]
⚠️ Calculated (N fields): [field → expression]
❌ Not available (N fields): [field → reason + proposed solution]

Proceed to layout? [Y / resolve gaps first]

このゲートにより、次のようなエラーを検出できます。

• Shipper を誤ったエンティティにマッピングしている（Owner ではなく Account）
• データソースから明細フィールドが漏れている（tareWeight、packUOM）
• 代替手段を設けずに深いナビゲーションパスを省略している（Owner の住所）

フェーズ 3：レイアウトのプロトタイプ（Studio でライブ表示）

実際の RDLX-JSON レポートを作成し、Datex Studio でライブプレビューします。 プロトタイプがそのままレポートファイルとなり、フェーズ 4 はこのフェーズの続きから始まります。ユーザーは変更をリアルタイムですべて確認できます。

ステップ 1：空のレポートを作成する

dxs report create <artifact_dir>/<report_name>_report --page letter --margins 0.5in

標準サイズ（letter、legal、a4、4x6、4x8）またはカスタムサイズ（WxH）には --page を使用します。横向きにするには --landscape を追加します。--margins は CSS スタイルの短縮記法に対応しています。

命名規則： フォルダー名がレポートの referenceName になります。Datex Studio プラットフォームはこれを使って TypeScript サービスクラスを生成します。有効な JavaScript 識別子である必要があり、使用できるのは英字、数字、アンダースコア、$ のみです。ハイフン、ピリオド、スペースは使用できません。_report 接尾辞の規則に従ってください。

不適切	適切	理由
srs-bol	srs_bol_report	ハイフンが TS クラス名の妨げになります
srs-bol.rdlx-json	srs_bol_report	ピリオドと拡張子が TS インポートの妨げになります
my report	my_report	スペースは識別子として無効です

所有データソースのエイリアス規則： dxs report datasource add --owned FILE:ALIAS で所有データソースを追加する場合、エイリアスは JSON 設定ファイル内のデータソースの referenceName と一致させる必要があります。プラットフォームは referenceName でサービスを登録する一方、レポートはエイリアスで参照するため、一致しないと「property does not exist」という TS エラーが発生します。例：設定に "referenceName": "ds_bol_header" がある場合は、--owned ds_bol_header.json:ds_bol_header を使用します。

ステップ 2：Studio で開く

dxs studio open <artifact_dir>/<report_name>_report/report.rdlx-json

これにより、Studio のデザインキャンバス（http://127.0.0.1:5051/design）でレポートが開きます。ファイルの変更はすべてリアルタイムで反映されます。

../datex-studio-shared/studio-management.md に従って Studio を自動管理します。状態を確認し、必要に応じて準備完了を確認しながらバックグラウンドで起動し、レポートを開き、フェーズ 5 の後にクリーンアップします。

ステップ 3：dxs report batch でレイアウトを段階的に作成する

dxs report batch を使い、要素をグループ単位で追加します。操作をファイルに記述し、--ops-file を使用すると、シェルのエスケープに関する問題を避けられます。1 回のバッチで指定できる操作は最大 25 件です。

../datex-studio-shared/report-authoring/design-standards.md にある Datex のデザイン言語を適用してください。すべてのテキスト要素に FontFamily: Arial を設定し（数値とバーコードのキャプションには Courier New を使用）、公式のカラーパレット（Black、DimGray、LightGray、Gray、Datex Purple #5B08B2）を使用します。テーブルは紫のヘッダー罫線と LightGray の行区切り線でスタイルを設定し（背景色は使用しません）、フィールドのラベルと値のパターン（8pt の DimGray のラベルを 10pt の Black の値の上に配置）に従い、位置を 0.25in のグリッドに合わせます。

長方形のコンテナーを使って、論理的なセクションごとに作成します。 ヘッダー、情報フィールド、住所ブロック、フッターなどの主要なセクションはすべて長方形で囲みます。最初に長方形を追加し、次に "parent": "RectangleName" を指定して子要素を追加します。子要素の座標は長方形の左上隅（0,0）を基準とするため、長方形を移動すると、その中の要素もすべて移動します。レイアウトを調整する際に重要です。長方形を使わない場合、セクションの位置を変更するには各要素を個別に移動する必要があります。バッチのパターンについては、../datex-studio-shared/report-authoring/cli-commands.md を参照してください。テーブルはそれ自体で完結するため、長方形で囲む必要はありません。

テーブル： 明細項目には dxs report add tablix を使用し、--header-cell、--detail-cell、--footer-cell（セルごとにオプションを繰り返し指定）と、行レベルの既定値として --header-style／--detail-style／--footer-style を指定します。合計には、単独のテキストボックスよりフッター行を優先してください。

線では、バッチ内で start-x／start-y／end-x／end-y を使用します（left／top／width／height は使用しません）。線に対して move は機能しないため、JSON を直接編集してください。

画像： 埋め込み画像には dxs report add image --file logo.png を使用します。データにバインドする画像には --source Database --value '=Fields!X.Value' を使用します。データベースにバインドする画像では、サンプルデータファイルにデータ URI が必要です。../datex-studio-shared/report-authoring/sample-data.md を参照してください。

PageHeader／PageFooter： これらはドキュメントルートの要素であり、JSON を直接編集する必要があります。../datex-studio-shared/report-authoring/json-structure.md を参照してください。

すべてのバッチ操作、tablix の作成、画像の処理、要素の編集に関する詳細な構文と例については、../datex-studio-shared/report-authoring/cli-commands.md を参照してください。

ステップ 4：サンプルデータファイルを作成する

レポートと同じ場所に、対応する <report-name>.data.json を作成します。Studio はこのファイルを自動検出します。

DataSets からひな形を生成する — ステップ 5 で DataSets を追加した後、次のコマンドでテンプレートを生成します。

dxs report data generate <report-name>.rdlx-json -o <report-name>.data.json

その後、プレースホルダーを現実的なサンプル値に置き換えます。データセットごとに 3～5 行を用意してください。フィールド名には、ドット表記の DataField パスではなく、DataSet フィールドの Names（例：Lines_Material_LookupCode のようなアンダースコア表記）を使用する必要があります。

形式と例の詳細については、../datex-studio-shared/report-authoring/sample-data.md を参照してください。

ステップ 5：レポートに DataSet を追加する

Studio プレビューでは必須です。 DataSet 定義がないと、Studio で「レポートに一致する DataSet がありません」というエラーが表示され、フィールド式がそのままのテキストとして描画されます。

DataSet の作成、CommandText のパターン、コレクションの処理、日付アノテーション、機密性プロパティについては、dataset-rules.md に従ってください。

フィールド名の主要な情報源として、datasource-creator の戻り値に含まれるフィールドサマリーを使用してください。生成された設定の型定義から直接抽出されているため、信頼できる情報源です。式で使用されるフィールドだけでなく、すべてのフィールドを含めてください。フィールドマッピング成果物は、レイアウトを決める際の参考となる人が読みやすいコンテキストを提供しますが、DataSet のフィールド名の主要な情報源としては使用しないでください。

dataset add の直後に、CommandText が Phase 2 の datasource-creator の戻り値にあるデータソースの結果型と一致することを確認してください。

• Result type: collection の場合、CommandText は 必ず .* で終わる必要があります（例：$.ds_name.result.*）。
• Result type: single の場合、CommandText は .* で終わってはいけません（例：$.ds_name.result）。

ここを間違えると、エラーもデータも警告もないまま、レポートが空になります。 これは DataSet のバインドで最もよくあるミスです。

Phase 4 では、実際のデータソース（スタンドアロンの場合）または設定 JSON（所有データソースの場合）と照合して検証します。

DataSet 内のコレクションフィールドの処理：

datasource-creator の戻り値で [collection] とマークされたフィールドを確認してください。これらは、単一結果の DataSet にフラットな DataSet フィールドとして追加できません。追加すると、何も表示されないままになります。

推奨する方法：フローデータソース。 datasource-creator の戻り値に、スタンドアロンのテキストボックスで必要なフィールドを含むコレクションがある場合は、Phase 2 に戻り、そのデータソースをフローとして再構築してください。フローコードは OData データを取得し、コレクションをスカラー値のフィールドに平坦化します。これは、複雑なナビゲーションを含む既存の Datex Studio レポートすべてで使われている本番環境向けのパターンです。

代替方法：CommandText の深いパスを使った子 DataSet。 フローへの書き換えが現実的でない場合は、コレクション内をたどる別の DataSet を作成してください。

{
    "Name": "ds_shipment_OrderLookups",
    "Fields": [
        {"Name": "Order_OwnerReference", "DataField": "Order.OwnerReference"},
        {"Name": "Order_Account_Name", "DataField": "Order.Account.Name"}
    ],
    "Query": {
        "DataSourceName": "Datasource",
        "CommandText": "$.ds_shipment.result.OrderLookups.*"
    }
}

スタンドアロンのテキストボックスでは、=First(Fields!Order_OwnerReference.Value, "ds_shipment_OrderLookups") のようにフィールドを参照します。ネストされたコレクション（コレクション内のコレクション）の場合は、パスを連結します：$.ds_shipment.result.OrderLookups.*.Order.Addresses.*。

CommandText の .* サフィックスルール：

• 単一結果、スカラーフィールド：$.ds_name.result（.* なし）
• コレクション結果（table／tablix）：$.ds_name.result.*
• 単一結果内のコレクション：$.ds_name.result.CollectionPath.*

ステップ 6：プレビューで検証する

dxs report preview <file> -o /tmp/preview.svg
dxs report preview <file> --bbox Title:red --bbox LinesTable:blue -o /tmp/inspect.svg

色付きのバウンディングボックスで視覚的にデバッグするには、--bbox NAME[:COLOR] を使用してください。

フィードバックの反復ループ

各セクションを作成した後、Studio でどのように見えるかユーザーに確認してください。変更には set／move／remove オペレーションを指定して dxs report batch を使用します。ユーザーが承認するまで繰り返してください。

レイアウトの参考資料

パターン例（Shipping Label、GS1、BOL、Tabular Report）と要素サイズの表については、../datex-studio-shared/report-authoring/design-patterns.md を参照してください。

Phase 4：レポートの仕上げ

レイアウト、要素、サンプルデータ、DataSet 定義を含む .rdlx-json ファイルは、Phase 3 ですでに作成されています。このフェーズでは、デプロイに向けて仕上げを行います。

最終確認チェックリスト

1. DataSets を確認する — スタンドアロンのデータソースの場合：フィールドの Names/DataFields を dxs report datasource-fields <ref> --branch <id> の出力と比較します。所有データソースの場合：Phase 2 のフィールド概要と比較します（datasource-fields はアップロード後にのみ使用できます）。不足しているフィールドは dxs report dataset add-field で追加します。CommandText = $.{ds_name}.result.* になっていることと、すべての機密性プロパティが設定されていることを確認します。
2. 式を調整する — プレースホルダー値を最終的な =Fields!Name.Value の式に更新します。式のクイックリファレンスについては、../datex-studio-shared/report-authoring/json-structure.md を参照してください。
3. 検証する：

   dxs report validate my-report.rdlx-json
   

最終調整中に段階的に編集する場合は、set/move/remove/dataset add-field の構文について、../datex-studio-shared/report-authoring/cli-commands.md を参照してください。

Phase 5: デプロイと検証

アップロード（所有データソースとスタンドアロンデータソース）、プレビュー、検証、テストパラメーターの確認については、deploy-patterns.md に従ってください。

成果物： dxs report preview <report>.rdlx-json -o <artifact_dir>/<report-name>-preview.svg でプレビューを保存します。

仕上げ（アップロードの検証後）

ブランチ上で設定が確認できたら：

1. ファイル： deploy-patterns.md の Cleanup プロンプトに従います。セッションファイルを削除する前にユーザーに確認してください。黙ってクリーンアップしてはいけません。Phase 1 でユーザーが成果物の収集を選択した場合は、成果物を保持することをデフォルトとします。
2. プロセス： studio-management.md の Cleanup セクションに従って、自分が起動したものを停止します。Studio をバックグラウンドで起動した場合は dxs studio stop を実行します（確認は不要です。ユーザーが起動したサーバーは決して停止しないでください）。また、残存するプレビュープロセス（agent-browser セッションデーモン／preview-arjs／validate-arjs によるヘッドレス Chrome）がないか確認します。終了しないプロセスや、ターミナルを妨げる残存プロセスは報告対象の CLI ライフサイクル不具合です。無闇に強制終了せず、症状の発生順序を記録してください。

トラブルシューティング

よくある RDLX-JSON の式に関する問題やレイアウト／CLI の誤りについては、troubleshooting.md を参照してください。

---

編集後、post-edit-verification を呼び出して、description／JSON／schema の違反を検出してください。最終レビューでは、component-validator を呼び出してください。