docker-to-sealos

Docker から Sealos テンプレートへの変換

アイデンティティと検出

• 所有者: docker-to-sealos（/docker-to-sealos および Compose、インストールドキュメント、または Sealos テンプレートへの変換リクエスト）。
• クラス: local-artifact-mutation。検証済みテンプレートを sealos-deploy に引き渡します。
• カナリア: DTS-RULE-PRECEDENCE、DTS-MUST-MAP、DTS-QUALITY-GATE。

スコープと境界

Docker Compose、インストールドキュメント、または既存テンプレートの更新リクエストを受け付け、指定されたテンプレートアーティファクトを template/<app>/index.yaml に書き込み、所有するバリデーターの証拠も追加します。ライブクラウドへの変更は行いません。ルールの出典、データベースのトポロジー、リソースの順序、宣言された入力、シークレットの境界を、このスキル内に保持します。必須ゲートをすべて通過した場合に限り、テンプレートを引き渡し候補とします。

リスクと確認

ガバナンス上の優先順位は、エントリーの MUST ルール、Sealos の仕様とデータベーステンプレート、マッピングと例の順です。references/must-rules-map.yaml と references/rules-registry.yaml は連動する重要なソースです。パブリック公開、破壊的変更、認証情報の変更、システムツールのインストールには、明示的な確認が必要です。生成された値と接続データは引き続きマスキングします。

ライフサイクルのワークフロー

リクエストごとに入力を分析し、メタデータを推定し、リソースを計画し、変換ルールを適用して、最終アーティファクトを検証します。完全な品質ゲートを通過した後に限り、引き渡します。success、stopped、error のいずれかをリクエスト単位で出力します。各結果には、ソースの出典情報、アーティファクトのパス、バリデーターの証拠、マスキング状況を含めます。既存の分析 → 推定 → リソース計画 → 変換というワークフローは、以下で説明するドメイン拡張として維持します。

段階的な情報開示

コアカナリアが確認できた後、関連する所有参照ファミリーを1段階だけ読み込みます。MUST-map と rules-registry の連動、ルールの優先順位、既存のバリデータースクリプトを維持します。汎用コンバーターや railpack build のパスに置き換えないでください。

出力、停止、エラーの状態

• success：ソース／出典情報、最終的な Template YAML、変換の概要、宣言された入力、トポロジー／ストレージ／データベースの証拠、一貫性／MUST-map／レジストリ／品質ゲートの証拠、マスキング結果。
• stopped：入力不足、ソース未解決、または確認が必要な境界に対し、確認済みの証拠、マスキング結果、安全な次のアクションを提示します。未検証のアーティファクトは引き渡しません。
• error：ルール、レジストリ、トポロジー、アーティファクト、または品質ゲートの失敗に対し、該当するソース／アーティファクト、サニタイズ済みの診断、マスキング結果、復旧方法を提示します。

引き渡し

直接変換する場合は、以下の型付きハンドオフをすべて送信します。デプロイ時には、独自の認証、スコープ、Runtime Truth の各ゲートを再確認します。

target: sealos-deploy
inputArtifact: final Template YAML plus consistency, MUST-map, registry, topology, and quality-gate evidence
allowedAction: deploy after required inputs and all downstream gates pass
failureReturn: failed rule, registry, topology, artifact, or quality-gate diagnostics
responseOwner: docker-to-sealos

検証

最終テンプレートそのものを対象に、一貫性、MUST の網羅性、quality_gate.py を実行します。ベースラインケース docker-to-sealos-positive-quality-gate と docker-to-sealos-violating-missing-rule を使用します。レジストリまたは MUST の証拠が欠けている場合、デプロイをブロックします。

概要

Docker Compose ファイルまたはインストールドキュメントを、本番環境対応の Sealos テンプレートに変換します。 必要な入力と確認がそろっている場合は、分析、変換、検証、出力を自動で実行します。必須の入力が不足している場合や、ゲート対象の操作が未解決の場合は、安全な次のアクションを示して停止します。

ガバナンスとルールの優先順位

ルールの逸脱を防ぐため、次の優先順位を適用します。

1. SKILL.md の MUST ルール（このファイル）
2. references/sealos-specs.md と references/database-templates.md
3. references/conversion-mappings.md と references/example-guide.md

優先度の低い参照資料が、優先度の高い MUST ルールと矛盾する場合は、優先度の低いファイルを更新してください。 矛盾する例は残さないでください。

ソースの優先順位とブランチ境界

すべての変換で以下のソース優先順位を使用し、選択したソースを変換レポートに記録してください。

1. 既存のテンプレートトポロジーと、更新に関する明示的なユーザーの意図。
2. エントリーの MUST ルールと、連携する must-rules-map.yaml ／ rules-registry.yaml。
3. Kubernetes 公式のインストール／ランタイムドキュメント。
4. リクエストに応じて選択された Compose またはインストールのドキュメント。
5. リポジトリの設定、README、Dockerfile、ロックファイルの根拠。
6. prepare-only ブランチで提供される場合は、正規化された analysis.json.build_environment の根拠。

Railpack の生 JSON は変換ソースではありません。brain-deploy-preview では、明示的な設定／README／Dockerfile／ロックファイルの優先順位を維持し、正規化されたビルド環境の根拠を使用し、Dockerfile とサンドボックスの Kaniko パスを維持してください。プレビューのフローで、このパスを railpack build、BuildKit、またはライブデプロイの動作に置き換えてはいけません。

変換ペイロード

デプロイで検出結果を再利用できるよう、このペイロードはリクエスト単位かつリポジトリ相対のものにしてください。

source:
  kind: compose | install-doc | existing-template
  paths: selected source files
  precedence: ordered source list
inference:
  app: metadata and runtime bundle evidence
  topology: resource roles, feature conditions, and replica counts
resources:
  ordered: Template CR, storage, database, workloads, App resource
  database: KubeBlocks evidence when applicable
  storage: PVC or managed object-storage evidence
  secrets: declared inputs with redaction status
artifact:
  template: template/<app>/index.yaml
  topology_evidence: .sealos/topology-evidence/<app>.yaml when required
verification:
  consistency: pass | fail
  must_map: pass | fail
  registry: pass | fail
  quality_gate: pass | fail
terminal_state: success | stopped | error
safe_next_action: request-scoped recovery or handoff action

ペイロードと最終成果物には、パスワード、トークン、kubeconfig の内容、環境変数の値、完全な接続文字列、バリデーター専用のシークレットを含めないでください。

ワークフロー

ステップ 1：入力を分析する

Docker Compose／ドキュメントから以下を抽出します。

• アプリケーションサービスとデータベースサービスの区別
• ボリューム／設定マウント／オブジェクトストレージの要件
• ポート、依存関係、サービス間通信
• 環境変数とシークレットの使用状況
• ブートストラップ認証情報、API キー、ソルト、シークレット、機能フラグに対する起動時の検証ルール
• 正確に選択されたリリースにおけるアカウントのブートストラップモード：機能する初回ユーザー登録、必須のブートストラップ認証情報、または任意のルートアカウントの調整／ブートストラップ
• 複数サービスの Web ロール：ブラウザーのエントリーポイント、REST API、OpenAI／API ゲートウェイ、ドキュメント、ワーカー、単発ジョブ
• リソースの制限／リクエストとヘルスチェック
• Kubernetes 公式のインストールドキュメント／マニフェストが利用できる場合は、そこからアプリケーションのランタイム動作も抽出します（ブートストラップ管理者フィールド、外部エンドポイント／プロトコルに関する前提、ヘルスプローブ、起動／初期化フロー、マイグレーションの順序）
• 公式の Compose／ドキュメントに連携する複数のサービスが記載されている場合は、公式ランタイムバンドルのソース、コンポーネント一覧、イメージのバージョン、公開エントリールート、重要な環境変数を記録します
• 選択したソーストポロジーを記録します：トポロジーを持つリソースのロール、機能条件、アプリケーションまたはデータベースのコンポーネントレプリカ数

ステップ 2：メタデータを推定する

以下を推定して正規化します。

• アプリ名、タイトル、説明、カテゴリー
• 公式 URL、gitRepo、アイコンのソース（アプリアイコン、ファビコン、アバターなど、正方形または円形でアイコンを主体とするアセットを優先し、横長のワードマーク／テキストロゴは避けます）
• ロケール／i18n のメタデータ

ステップ 3：厳密な順序でリソースを計画する

以下の順序でリソースを生成します。

1. Template CR
2. ObjectStorageBucket（必要な場合）
3. データベースリソース（ServiceAccount → Role → RoleBinding → Cluster → 必要な場合は Job）
4. アプリのワークロードリソース（ConfigMap／Secret → Deployment／StatefulSet → Service → Ingress）
5. アプリリソース（最後）

ステップ 4：変換ルールを適用する

references/conversion-mappings.md のフィールド単位のマッピングを適用します。以下を含みます。

• イメージの固定とアノテーションのマッピング
• ポート／サービス／Ingress の変換
• 環境変数の変換と依存関係の順序付け
• ストレージの変換と vn の命名（scripts/path_converter.py）
• サービス名から Kubernetes FQDN への変換
• DB URL／DSN 環境変数（例：*_DATABASE_URL、*_DB_URL）について、Kubeblocks の endpoint が host:port の場合は、承認済みの secretKeyRef 環境変数を使って host／port／username／password を注入し、$(VAR) 展開を使って最終的な URL を組み立てます
• エッジゲートウェイの正規化：Compose に Traefik のようなエッジプロキシとビジネスサービスが含まれる場合、プロキシのワークロードをスキップし、Sealos Ingress を通じてビジネスサービスを直接公開します
• Sealos Ingress の TLS オフロードの正規化：ビジネスサービスが 80 と 443 の両方を公開している場合、ワークロード／サービスのポートから 443 を削除し、コンテナ内の TLS 証明書マウント（例：/etc/nginx/ssl、/etc/ssl、/certs）を削除します。ただし、公式 Kubernetes ドキュメントでバックエンドからサービスへの HTTPS 通信が明示的に必要とされている場合を除きます
• 複数サービスの Web 構成の正規化：確認済みのブラウザー向けエントリーポイントを App リソースで公開し、API／ゲートウェイ／ドキュメントは公開対象として意図されている場合にのみ公開します。ワーカーは非公開のままにし、Service／Ingress を作成しません
• URL の構成：ブラウザー向け環境変数にはパブリック HTTPS URL を使用し、サーバー間環境変数には、アプリがパブリックコールバックを明示的に必要とする場合を除き、Kubernetes Service FQDN を使用します
• WebSocket Ingress の正規化：パブリックエントリーポイントが ws://、wss://、CDP／Chrome DevTools、ゲームソケット、または WebSocket を名前に含むポート／サービスの場合は、WebSocket nginx Ingress アノテーションを使って公開します
• StatefulSet のサービス ID：ヘッドレス DNS または安定した Pod ごとの DNS 要件がドキュメントに記載されていない単一コンポーネントアプリでは、パブリックアプリケーション Service を spec.serviceName として使用し、ワークロード、Service、ルート Ingress、マネージャーの ID を一致させます。ドキュメントに記載された HA／ヘッドレス制御用 Service は維持し、別のパブリックアプリケーション Service を通じて公開します
• 決定論的な変換のエントリーポイントとして、scripts/compose_to_template.py --kompose-mode always を優先します（再現可能なワークロード構成には kompose が必要です）
• 既存テンプレートを更新する場合は、トポロジーを決める現在のテンプレートのリソース、機能条件、レプリカ数をベースラインとして維持します
• 新規に変換する場合は、選択した Compose サービスと deploy.replicas の値をトポロジーのベースラインとして維持します
• アプリケーションのランタイムセマンティクス（ブートストラップフィールド、エンドポイント、プローブ、起動順序など）を整合させるため、公式 Kubernetes のインストールドキュメント／マニフェストを使用します
• 任意または推奨のワーカー、キャッシュ、HA レプリカは、選択したソースのトポロジーまたは明示的なユーザーの意図に含まれていない限り、出力されるトポロジーに含めません
• 各機能入力は、ドキュメントに記載された機能のみに適用します。データベースとオブジェクトストレージの入力によって、無関係なワークロード、キャッシュ、レプリカを追加してはなりません
• 公式の Compose／ドキュメントで複数コンポーネントのランタイムバンドルが定義されている場合は、ランタイムに必要なコンポーネント、エントリールート、重要な環境変数、コンポーネントのイメージバージョンを、同一の公式リリース／Compose ソースに合わせます
• ホストディレクトリのマウントを永続ストレージに変換する前に、そのパスに必要なファイルがイメージにすでに含まれているか確認します。イメージに含まれるマニフェスト、依存関係リスト、設定のデフォルト値が、新規の空の PVC によって隠されないようにします

ステップ 5：データベース戦略を適用する

• データベースサービスは、KubeBlocks の Cluster リソースとして生成する必要があります。PostgreSQL／MySQL／MongoDB／Redis／Kafka の Compose データベースサービスを、Kubernetes の生の Deployment または StatefulSet ワークロードに変換しないでください。
• PostgreSQL は、固定されたバージョンおよび構成要件に従う必要があります。
• MySQL／MongoDB／Redis／Kafka では、references/database-templates.md のテンプレートとシークレットの命名規則を使用する必要があります。
• アプリケーションのデータベース初期化に必要な場合は、DB 初期化 Job／initContainer を追加してください。
• PostgreSQL のカスタムデータベース（postgres 以外）では、初期化 Job の実行前に PostgreSQL の準備完了を待機し、対象データベースを冪等に作成する必要があります。
• データベースクライアントイメージは、準備完了確認や初期化ゲートのために、アプリの initContainers および初期化／移行／ブートストラップ Job で使用できます。
• アプリケーションの重要な互換性オブジェクトは、稼働中のデータベースの状態で検証する必要があります。アプリケーションが起動するたびに必要となる互換性ビュー、レガシーテーブル／ビュー、インデックス、拡張機能、検索パス、ブートストラップ状態については、冪等な initContainer による自己修復を使用してください。
• 単発の初期化 Job では、初期データベースやシード状態を作成できますが、アプリケーションの起動ゲートでは、最終的なデータベースオブジェクトを直接検証する必要があります。TTL の期限が切れた Job は過去の証拠として扱い、合否判定にはデータベースの状態を使用してください。
• アプリケーションのマイグレーションに依存するワーカー、ゲートウェイ、バックグラウンドサービスは、データベースのポートだけではなく、必要なテーブル、マイグレーションマーカー、またはアプリケーション固有の準備完了オブジェクトを待機する必要があります。
• Redis の準備確認プローブまたは initContainer は、準備確認に認証情報が不要な場合に、NOAUTH や Authentication required などの認証済み Redis 応答を許容する必要があります。
• PostgreSQL のブートストラップシェルでは、安全な引用符の使用パターンを使う必要があります。可能な場合は、シェルレベルで存在を確認してから単純な SQL 文を実行してください。psql の変数展開には、シングルクォートで囲んだヒアドキュメントまたは SQL ファイルを使用し、ガードクエリで同じロジックを表現できる場合は、インラインシェルコマンドで PL/pgSQL の DO $$ ブロックを使用しないでください。
• 変数展開に :'var' を使用する psql -c "..." は使わないでください。psql -v name=value <<'SQL' ... :'name' ... SQL を使用するか、安全なリテラル SQL をあらかじめ渡してください。

ステップ 6：出力ファイルを生成する

必ず次を生成してください。

• template/<app-name>/index.yaml
• 公式アイコンを取得できる場合は template/<app-name>/logo.<ext>。正方形または円形のアイコンを主体とするアートワークを優先し、長方形のワードマークやテキストロゴは避けてください。

次のファイルは作成しないでください。

• template/<app-name>/README.md
• template/<app-name>/README_zh.md

README の作成はこのスキルの対象外です。Template CR が README の URL を必要とする場合は、index.yaml の URL フィールドにのみ値を設定し、ファイルの作成は専用の README スキルに任せてください。

ステップ 7：出力前に検証する

テンプレートを出力する前に、バリデーターとセルフテストを実行してください。 検証に失敗した場合は、まずテンプレート／ルール／例を修正してください。 ウェブアプリケーションでは、実稼働検証にランタイムログの健全性確認を含める必要があります。最初の準備完了後、ログインまたはセットアップ後、および文書化された API のネガティブルートを 1 つ実行した後、または一意の存在しない静的アセットをリクエストした後に、init コンテナーとメインコンテナーのログを確認してください。SPA のクライアントルートは HTTP 200 で HTML シェルを返す場合がありますが、Pod が Ready であっても、繰り返し発生する traceback 形式の警告があればテンプレートの不合格となります。 ログインが必要なウェブアプリケーションでは、リソースの調整やクリーンアップの前に、認証済み API またはページを 1 つ使用して、実際の認証情報／セッションフローを実稼働検証で確認する必要があります。 マネージドまたはプライベートのオブジェクトストレージでは、実稼働検証に、認証済みアプリケーションフローを通じた既知のバイト列のアップロード、オブジェクトの読み取りまたはダウンロード、SHA-256 ダイジェストの比較、アプリケーションプロキシ経由または有効期間を限定した事前署名 URL による配信の確認、未認証のオブジェクトへの直接リクエストが引き続き制限されていることの確認を含める必要があります。オプションのオブジェクトストレージでは、ローカルストレージとマネージドバケットの両方の分岐を個別に検証する必要があります。

MUST ルール（要約）

名前とメタデータ

• テンプレートの metadata.name は小文字でハードコードする必要があります。${{ defaults.app_name }} は使用しないでください。
• テンプレートの CR フォルダー名は metadata.name と一致させる必要があります。
• テンプレートの CR には、必須のメタデータフィールド（title、url、gitRepo、author、description、icon、templateType、locale、i18n、categories）を含める必要があります。
• テンプレートの spec.readme は、https://raw.githubusercontent.com/labring-actions/templates/kb-0.9/template/<app-name>/README.md を参照する必要があります。
• テンプレートの spec.i18n.zh.readme は、https://raw.githubusercontent.com/labring-actions/templates/kb-0.9/template/<app-name>/README_zh.md を参照する必要があります。
• これらの README フィールドは index.yaml 内の URL 参照に限られます。このスキルでは、参照先の README ファイルを作成または更新してはなりません。
• icon の URL は、kb-0.9 ブランチにある、このアプリのテンプレートリポジトリ内の raw パスを参照する必要があります。
• template/<app-name>/logo.<ext> には、アイコンを主役にした正方形または円形のアートワーク（アプリアイコン、ファビコン、アバターなど）を使用する必要があります。長方形のワードマークやテキストロゴは使用しないでください。
• i18n.zh.description は簡体字中国語で記述する必要があります。
• i18n.zh.title が title と同一の場合は省略してください。
• categories には、定義済みの値（tool、ai、game、database、low-code、monitor、dev-ops、blog、storage、frontend、backend）のみを使用してください。

アプリのリソース

• App リソースでは spec.data.url を使用する必要があります。
• App リソースの spec.displayType は normal である必要があります。
• App リソースの spec.type は link である必要があります。
• App リソースの spec.data.url には、Sealos を新規起動した状態でアクセスできるブラウザーのエントリー URL を指定する必要があります。safe-path、setup-path、または entrance-path の動作があるアプリでは、設定済みのパスとルートパスを確認し、事前の非表示のナビゲーションなしでログインまたは初回セットアップができる URL を選択してください。
• SSR／Next.js／React のサーバーアプリでは、サーバー側の例外が表示されるパスを App URL または HTTP プローブに使用しないでください。HTTP ステータスが 2xx／3xx であっても、表示された Application error、server-side exception、Internal Server Error、または Unhandled Runtime Error のテキストは、エントリーパスの失敗として扱ってください。
• App リソースでは spec.template を使用しないでください。
• cloud.sealos.io/app-deploy-manager ラベルの値は、リソースの metadata.name と一致している必要があります。
• 管理対象のアプリワークロードでは、metadata.labels.app ラベルの値はリソースの metadata.name と一致している必要があります。
• 管理対象のアプリワークロードでは、プライマリのビジネスコンテナー名はワークロードの metadata.name と一致している必要があります。サイドカー／ヘルパーコンテナーには、別の説明的な名前を使用できます。
• アプリケーションの Service リソースでは metadata.labels.app と metadata.labels.cloud.sealos.io/app-deploy-manager を定義し、両方のラベルを spec.selector.app と一致させる必要があります。
• ランタイムのコンポーネントスコープ付き ConfigMap リソースでは metadata.labels.app と metadata.labels.cloud.sealos.io/app-deploy-manager を定義し、両方のラベルを metadata.name と一致させる必要があります。初期設定を永続ストレージにコピーするために init コンテナーだけが使用するブートストラップ専用の ConfigMap では、どちらのラベルも定義しないでください。
• アプリケーションの Service リソースでは、metadata.name、metadata.labels.app、metadata.labels.cloud.sealos.io/app-deploy-manager、spec.selector.app で同じコンポーネント名を使用する必要があります。
• ルートパスの Ingress リソース（pathType: Prefix、path: /）では、metadata.name、metadata.labels.cloud.sealos.io/app-deploy-manager、バックエンドの service.name で同じコンポーネント名を使用する必要があります。ルートパス以外、または Prefix 以外の Ingress ルールでは、別のバックエンドサービスにルーティングできます。
• ルートパスの Ingress リソース（pathType: Prefix、path: /）では backend.service.port.number を使用し、その番号を参照先のアプリケーション Service に宣言された spec.ports[*].port と一致させる必要があります。
• Launchpad のパブリックアドレス検出でアプリケーションのエントリールートが選択されるように、各 HTTP paths リストではルートパスの Prefix ルートを最初のエントリーにする必要があります。
• Service の spec.ports[*].name は明示的に設定する必要があります（複数ポートのサービスでは必須です）。
• HTTP Ingress には、必要な nginx アノテーション（kubernetes.io/ingress.class、nginx.ingress.kubernetes.io/proxy-body-size、nginx.ingress.kubernetes.io/server-snippet、nginx.ingress.kubernetes.io/ssl-redirect、nginx.ingress.kubernetes.io/backend-protocol、nginx.ingress.kubernetes.io/client-body-buffer-size、nginx.ingress.kubernetes.io/proxy-buffer-size、nginx.ingress.kubernetes.io/proxy-send-timeout、nginx.ingress.kubernetes.io/proxy-read-timeout、nginx.ingress.kubernetes.io/configuration-snippet）を、想定されるデフォルト値で含める必要があります。
• WebSocket Ingress には、必要な nginx アノテーション（kubernetes.io/ingress.class、nginx.ingress.kubernetes.io/proxy-body-size、nginx.ingress.kubernetes.io/proxy-read-timeout、nginx.ingress.kubernetes.io/proxy-send-timeout、nginx.ingress.kubernetes.io/backend-protocol、nginx.ingress.kubernetes.io/ssl-redirect）を含め、backend-protocol: WS と読み取り／送信タイムアウト 3600 を設定する必要があります。
• CronJob リソースでは、cloud.sealos.io/cronjob、cronjob-launchpad-name、cronjob-type の各ラベルを定義する必要があります。cloud.sealos.io/cronjob は metadata.name と一致させ、cronjob-launchpad-name は ""、cronjob-type は image にする必要があります。
• アプリケーションの公式なヘルスチェックが利用できる場合、管理対象のワークロードでは公式のエンドポイント／コマンドに合わせて livenessProbe、readinessProbe、および（ブートストラップに時間がかかるアプリでは）startupProbe を定義する必要があります。
• 非 root UID で実行されることが確認済みのパブリックイメージでは、イメージが root または追加のケーパビリティを必要とする場合を除き、管理対象のアプリワークロードと init Job に、制限に準拠したセキュリティコンテキスト（runAsNonRoot、runAsUser、runAsGroup、fsGroup、seccompProfile: RuntimeDefault、allowPrivilegeEscalation: false、capabilities.drop: [ALL]）を設定する必要があります。

Kubernetes の公式情報との整合性

• Kubernetes の公式インストールドキュメント／マニフェストが利用できる場合、テンプレート成果物を出力する前にそれらを参照し、重要なランタイム設定を整合させる必要があります。
• Kubernetes の公式ドキュメント／マニフェストと Compose の内容が異なる場合、より優先度の高い Sealos の MUST／セキュリティ要件に違反しない限り、アプリケーションの動作には Kubernetes の公式なランタイムセマンティクス（ブートストラップ時の管理者フィールド、外部エンドポイント／環境変数／プロトコル、ヘルスプローブ）を優先します。
• 既存テンプレートを更新する場合は、現在のテンプレートのトポロジーを構成するリソース一覧、条件、レプリカ数を維持します。新たに変換する場合は、選択された Compose のトポロジーと deploy.replicas の値を維持します。
• アプリケーションのランタイムセマンティクスを整合させるには、Kubernetes の公式ドキュメント／マニフェストを使用します。追加のワーカー、キャッシュ、高可用性レプリカを追加するのは、選択されたソーストポロジーまたは明示的なユーザーの意図に含まれる場合に限ります。
• 各アプリケーション機能の入力は、ドキュメント化されたその機能に関係するリソースと設定だけを制御する必要があります。データベースとオブジェクトストレージの入力によって、無関係なワークロード一覧やレプリカ数が変わってはなりません。
• トポロジーに依存する検証では、検証専用の TopologyEvidence として .sealos/topology-evidence/<app-name>.yaml を指定する必要があります。最終的な Sealos Template 成果物にトポロジー検証メタデータを含めてはなりません。
• 公式の Compose／ドキュメントで複数コンポーネントのランタイムバンドルが提供されている場合、テンプレート成果物では、同じ公式リリース／Compose ソースに含まれる、ランタイムに必要なコンポーネント、公開エントリルート、重要な環境変数、イメージバージョンを維持する必要があります。
• 公式の複数コンポーネントのランタイム情報を使用するテンプレートでは、検証時に別ファイルの RuntimeBundleEvidence YAML を指定する必要があります。最終的な Sealos Template 成果物にランタイムバンドル検証メタデータを含めてはなりません。

イメージとプルポリシー

• :latest は使用しないでください。
• crane でバージョンを解決します。明示的なバージョンタグ（例：v2.2.0）を優先し、決定可能なバージョンタグがない場合に限り、ダイジェスト固定にフォールバックします。
• 変動するタグ（例：:v2、:2.1、:stable）は避け、明示的なバージョンタグまたはダイジェストを使用します。
• 管理対象ワークロードのイメージ参照には具体的な値を指定し、Compose 形式の変数式（例：${VAR}、${VAR:-default}）を含めてはなりません。テンプレート成果物を出力する前に、明示的なタグまたはダイジェストに解決します。
• アプリケーションの originImageName は、コンテナーイメージと一致させる必要があります。
• 既知のパブリックイメージを使用する管理対象アプリケーションのワークロードでは、template.spec.imagePullSecrets を省略する必要があります。レジストリ認証が必要なワークロードでプル Secret が必要な場合は、アプリケーション専用の Secret ${{ defaults.app_name }} のみを参照できます。
• レジストリのプル Secret は、プライベート GHCR イメージの場合に、ローカルの gh CLI 認証情報を使って sealos-deploy がランタイム時に管理します。生成されたテンプレートで、レジストリ認証情報を直接入力させてはなりません。
• すべてのコンテナーで imagePullPolicy: IfNotPresent を明示的に設定する必要があります。

ストレージ

• emptyDirは使用しないでください。
• ストレージが必要な場合は、永続ストレージのパターン（volumeClaimTemplates）を使用してください。
• volumeClaimTemplatesを含むStatefulSetリソースには、appやcloud.sealos.io/app-deploy-managerなどの標準的なワークロードラベルを維持し、StatefulSetのmetadata.labelsとvolumeClaimTemplates[].metadata.labelsの両方からcloud.sealos.io/deploy-on-sealosのみを省略してください。
• volumeClaimTemplates[].metadataには、パスから生成したname、annotations.path、およびannotations.value: '1'を含めてください。また、各クレームは、同じ名前とパスを持つコンテナのvolumeMountに対応させてください。
• PVCの要求サイズは、ソース仕様でそれ未満が明示的に要求されている場合を除き、<= 1Giにしてください。
• ConfigMapのデータキーには、/、-、.などの特殊文字を含むvnの命名規則（scripts/path_converter.py）を使用してください。
• 管理対象のDeployment／StatefulSetワークロードがマウントするConfigMapでは、metadata.name == workload.metadata.nameにしてください。
• ConfigMapのワークロードボリュームには<workload-name>-cmを使用し、各ConfigMapのdataキーを、それぞれのキーと完全に同じsubPathを指定した個別のvolumeMountとしてマウントしてください。
• 管理対象テンプレートでは、ConfigMapボリュームのdefaultModeを省略してください。マウントしたスクリプトは/bin/sh /path/scriptを通じて実行してください。アプリケーションで実行可能ファイルが本当に必要な場合は、initContainerで永続ストレージにコピーし、chmodを適用してください。
• command／argsに長い起動スクリプトやヒアドキュメントを直接記述しないでください。初期化スクリプトや起動スクリプトはConfigMapのファイルに配置し、短いコマンドで実行してください。
• 入力を生成する前に、公式アプリケーションドキュメントに基づいて、オブジェクトストレージを必須機能、アプリケーションレベルの任意機能、外部管理ストレージのいずれかに分類してください。
• 上流アプリケーションでのオブジェクトストレージ／S3連携がEnterprise、有料、商用、サブスクリプション、またはライセンスによって制限されている場合、公開テンプレートではコミュニティでサポートされているストレージ経路（例：filesystem／PVC）を使用し、その機能の標準的なObjectStorageBucket入力やS3入力は公開しないでください。
• オブジェクトストレージが必須で、SealosのS3互換性がアプリケーションの要件を満たす場合は、ドキュメントに記載されたバケット構成のObjectStorageBucketリソースを無条件に作成し、Sealosのオブジェクトストレージシークレットを注入してください。
• 管理対象のObjectStorageBucketを使用するテンプレートでは、それを唯一のオブジェクトストアのデータプレーンとし、同梱のMinIOサーバーのワークロード、Service、Ingress、PVC、およびローカルのオブジェクトストレージ認証情報を省略してください。
• 変換時にオブジェクトストレージのプロバイダー／バックエンドの選択入力を解決し、管理対象のObjectStorageBucketと同梱のminio/minio、bitnami/minio、またはbitnamilegacy/minioサーバーイメージを併用しないでください。
• 互換プロキシは、公式プロトコルの根拠からリクエストの調整が必要と確認できた場合にのみ使用してください。
• オブジェクトストレージの互換プロキシには、認証情報を含まないHTTPSのソースURLまたはuser-request:<reference>を値とするmetadata.annotations.docker-to-sealos.object-storage-compatibility-proxy-sourceを指定してください。また、ステートレスにし、永続ボリュームを省略してください。
• 外部S3／オブジェクトストレージの認証情報入力には、認証情報を含まないHTTPSのソースURLまたはuser-request:<reference>を値とするmetadata.annotations.docker-to-sealos.external-object-storage-sourceが必要です。また、ObjectStorageBucketと併用してはなりません。
• 管理対象またはプライベートのオブジェクトストレージの受け入れ確認では、認証済みのアプリケーションによるアップロードと、コンテンツが一致する読み取り／ダウンロード、アプリケーションプロキシ経由または期限付きの署名付きURLによる配信、および未認証の直接アクセスの制限を実証する必要があります。任意のオブジェクトストレージは、ローカルストレージと管理対象バケットの両方の経路で確認してください。

デプロイへの引き渡しは、整合性、MUSTマッピングの網羅性、レジストリ、トポロジーの根拠、およびquality_gate.pyが、最終テンプレートの正確な内容に対してすべて合格するまで保留されます。 根拠が不足している、または古くなっている場合はerrorとなり、失敗したルールまたは成果物の担当者に差し戻されます。

環境変数とシークレット

• データベース以外の機密値／入力には、直接 env[].value を使用します。
• 公式のランタイムプロファイルで環境変数の値の形式または長さが制約される場合は、有効なリテラル値か、生成されたデフォルト値を持たない必須入力を使用します。裸の ${{ random(n) }} は、16 進数またはエンコーディングの制約がある値には無効です。
• 公式ランタイムライブラリが不透明なエントロピーから決定論的に導出できる内部認証情報には、spec.defaults の引用符付きインスタンスシードを使用できます。値を使用するすべてのロールで同じ最終値を導出して検証し、exec の前にシードを削除する必要があります。また、導出値に対するユーザー入力を公開してはいけません。
• docker-to-sealos.runtime-secret-contract: persisted としてマークされた永続ランタイムシークレットの契約では、永続性のあるランタイムエントロピーからシークレットを生成し、制限的な権限を適用してアトミックに置換し、exec の前に検証する必要があります。また、最終的なシークレットを診断情報に含めてはいけません。
• 公式ランタイムプロファイルで外部プロバイダーが選択されている場合、ワークロードではそのプロバイダーに必要な認証情報を空でない値として設定する必要があります。デフォルト値が空の任意入力は無効です。
• ビジネスコンテナでは、データベース接続フィールド（endpoint、host、port、username、password）を、承認済みの Kubeblocks データベースシークレットから env[].valueFrom.secretKeyRef を通じて取得する必要があります。例外として、Redis シークレットに認証情報しか含まれていない場合は、Redis の host／port に Sealos Redis Service FQDN と 6379 を使用できます。また、MongoDB シークレットに認証情報しか含まれていない場合は、MongoDB の host／port または接続 URL に Sealos MongoDB Service FQDN と 27017 を使用できます。
• ビジネスコンテナでは、承認済みの Kubeblocks データベースシークレットとオブジェクトストレージシークレットを除き、カスタムの環境変数／ボリューム Secret 参照を使用してはいけません。
• プライベートレジストリイメージに限り、アプリ専用のレジストリプルシークレットを使用できます。その場合、template.spec.imagePullSecrets からのみ参照する必要があります。パブリックイメージにプルシークレットを追加してはいけません。
• データベース接続／ブートストラップには Kubeblocks が提供するシークレットを使用できます。また、予約済みの Kubeblocks データベースシークレット名をカスタムの Secret リソースで再定義してはいけません。
• 環境変数は、参照される前に宣言する必要があります（例：URL の組み立てより前にパスワードを宣言します）。
• 公式のアプリ環境変数の命名規則に従い、独自のプレフィックスを作らないでください。
• フロントエンド／API／ゲートウェイが分離されたアプリでは、ブラウザーに公開する URL と内部サービス URL を分けてください。フロントエンド／ブラウザーのコールバック変数には https://${{ defaults.<host> }}.${{ SEALOS_CLOUD_DOMAIN }} を使用します。バックエンド間の変数には http://<service>.$(SEALOS_NAMESPACE).svc.cluster.local:<port> または完全にレンダリングされた Service FQDN を使用します。
• アプリケーションでファイルベースの設定システム（例：node-config の config/default.json、PHP 設定ファイル）を使ってパブリック URL を設定する必要がある場合は、https://${{ defaults.app_host }}.${{ SEALOS_CLOUD_DOMAIN }} にパブリック URL を設定した設定ファイルを含む ConfigMap を作成し、アプリケーションの設定ディレクトリにマウントします。ConfigMap には標準の命名規則とラベル規則を適用する必要があります。
• PostgreSQL のカスタムデータベース（postgres 以外）では、${{ defaults.app_name }}-pg-init Job を含め、起動時に安全で冪等な作成ロジック（準備完了の待機後、作成前に存在確認を行う）を実装します。
• アプリケーション固有のデータベース互換性を確保するには、ビジネスコンテナの起動前に、必要なビュー、エイリアス、インデックス、拡張機能、権限、ロールの検索パス、レガシー互換オブジェクトを冪等に作成または修復する initContainer または起動ゲートを含めます。
• 公式ランタイムプロファイルでデータベースの最終状態が要件として指定されている場合は、ビジネスコンテナの起動前にデータベースを待機し、必要な拡張機能またはオブジェクトを検証する initContainer ゲートを含めます。
• 管理対象アプリのメインコンテナの command／args は、イメージの公式エントリーポイントから大きく逸脱させてはいけません。公式の起動コマンド、Compose ネイティブの引数、または短い exec ラッパーのみを使用します。ファイルの準備、権限の修復、データベースのブートストラップ、互換性の自己修復は initContainer、Job、または ConfigMap のスクリプトに移します。
• メインのビジネスコンテナ内のシェルラッパーでは、シグナル処理を正しく行えるよう、最終プロセスを exec で起動する必要があります。
• データベースのブートストラップ SQL は、シェルで安全に実行できる必要があります。シェルレベルのガードクエリとシンプルな SQL を優先し、psql 変数にはシングルクォートのヒアドキュメントを使用し、ガードされていないインラインの DO $$ ブロックは避けてください。
• psql -c に :'var' の psql 変数構文を含めてはいけません。-v による展開が必要な SQL にはヒアドキュメントを使用します。

データベース固有の制約

• データベースサービスには、アプリケーションの Deployment または StatefulSet ワークロードではなく、KubeBlocks の Cluster リソースを使用する必要があります。StatefulSet はステートフルなアプリケーションコンポーネントに限り使用でき、PostgreSQL／MySQL／MongoDB／Redis／Kafka のデータベースサービスには使用できません。
• データベースクライアントのイメージは、準備状況の確認やブートストラップのゲート処理のために、アプリの initContainers および初期化／マイグレーション／ブートストラップ用の Job で使用できます。
• PostgreSQL のバージョン：postgresql-16.4.0。
• PostgreSQL API：apps.kubeblocks.io/v1alpha1。
• PostgreSQL RBAC の統一された命名規則：${{ defaults.app_name }}-pg。
• PostgreSQL RBAC には、app.kubernetes.io/instance および app.kubernetes.io/managed-by ラベルが必要です。
• すべての KubeBlocks データベース Cluster には、kb.io/database、sealos-db-provider-cr、clusterdefinition.kubeblocks.io/name ラベルが必要です。dbprovider がデータベースを一覧表示して分類できるよう、sealos-db-provider-cr は metadata.name と一致させる必要があります。詳細ビューで表示するため、関連する Pod、Service、OpsRequest には app.kubernetes.io/instance=<database name> を付与してください。
• PostgreSQL のロールに対するワイルドカード権限の要件は、現行の仕様で定められた内容を引き続き適用します。
• PostgreSQL クラスターには、必須のラベル／フィールド（kb.io/database: postgresql-16.4.0、clusterdefinition.kubeblocks.io/name: postgresql、clusterversion.kubeblocks.io/name: postgresql-16.4.0、clusterVersionRef: postgresql-16.4.0、disableExporter: true、enabledLogs: [running]、switchPolicy.type: Noop、serviceAccountName）を含める必要があります。
• MongoDB クラスターは、アップグレード後の構造（componentDef: mongodb、serviceVersion: 8.0.4、kb.io/database および app.kubernetes.io/instance ラベル）に従う必要があります。
• MySQL クラスターは、アップグレード後の構造（kb.io/database: ac-mysql-8.0.30-1、clusterDefinitionRef: apecloud-mysql、clusterVersionRef: ac-mysql-8.0.30-1、tolerations: []）に従う必要があります。
• Redis クラスターは、アップグレード後の構造（componentDef: redis-7、componentDef: redis-sentinel-7、serviceVersion: 7.2.7、メインデータ PVC は 1Gi、トポロジーは replication）に従う必要があります。
• データベースクラスターのコンポーネントリソースには、ソースドキュメントで別途明示的な要件がない限り、limits(cpu=500m,memory=512Mi) および requests(cpu=50m,memory=51Mi) を使用する必要があります。
• 管理対象のすべてのワークロードコンテナリソースには、Sealos のリソース階層を使用する必要があります。limits.cpu は 100m/200m/500m/1/2/3/4/8 のみ、limits.memory は 128Mi/256Mi/512Mi/1024Mi/2048Mi/4096Mi/8192Mi/16384Mi のみ使用できます。また、requests は limits の数値の最後の桁を削除して算出する必要があります（500m→50m、512Mi→51Mi、1→100m、1024Mi→102Mi、4096Mi→409Mi）。階層にない値を独自に設定しないでください。また、Sealos Template API のクォータプレビューでは単位のない G メモリが 0 として解析される可能性があるため、2G/4G/8G/16G は使用しないでください。
• 既存テンプレートの更新時は、実行時の証拠からエフェメラルストレージの圧迫が確認された場合を除き、既存の ephemeral-storage リソースフィールドを追加、削除、変更しないでください。CPU とメモリを調整する際は、元のリクエスト／制限値を維持してください。
• シークレットの命名規則：
  • MongoDB：${{ defaults.app_name }}-mongo-mongodb-account-root（または、MongoDB クラスター名に -mongodb を使用する場合は ${{ defaults.app_name }}-mongodb-mongodb-account-root）
  • Redis：${{ defaults.app_name }}-redis-redis-account-default（後方互換性のため、従来の ${{ defaults.app_name }}-redis-account-default も許容される場合があります）
  • Kafka：${{ defaults.app_name }}-broker-account-admin
  • サポート対象の例外を除き、従来の命名規則は使用しないでください。

ベースラインのランタイムのデフォルト

ソースドキュメントで明示的に別の要件が定められていない限り、個人向け低負荷候補の初期値として、この軽量アプリのラダー項目を使用します。

• コンテナの上限：cpu=200m、memory=256Mi
• コンテナのリクエスト：cpu=20m、memory=25Mi
• revisionHistoryLimit: 1
• デフォルトでは automountServiceAccountToken: false にします。アプリケーションに Kubernetes API／サービスアカウントトークンの明示的な要件があり、Kubernetes 統合設定、serviceAccountName、またはワークロードのアノテーション sealos.io/service-account-token-reason によって確認できる場合に限り、true に設定します。
• ワークロードで PodSecurity のアドミッション警告が発生し、イメージが非 root ユーザーとして実行される場合は、テンプレートの準備完了を報告する前に、制限付きポリシーに対応したセキュリティコンテキストを追加します。

静的生成では最終的なリソース階層を証明できません。この候補を最終的なテンプレート値として扱う前に、実環境でのリソース検証を完了してください。

個人向け低負荷リソースの検証

リソースラダーを、各アプリケーションのメインコンテナ、サイドカー、initContainer、Job にそれぞれ適用します。

• 最終的な CPU とメモリの上限には、役割ごとの個人向け低負荷検証に合格する Sealos ラダーの最も低い階層を設定します。ただし、ソースに明示された最低要件がある場合は、それを下限とします。
• CPU とメモリは個別に、ラダーを一段ずつ調整し、候補ごとに新しいロールアウトまたはコールド実行を行います。
• 長時間稼働するワークロードが合格するには、コールドスタートを完了して Ready になり、該当する場合は登録またはログインを完了し、代表的な低負荷アクションを少なくとも 2 回完了したうえで、OOMKilled による終了、再起動、Ready 状態の不安定化、リソース関連のタイムアウトが一度もなく、60 秒間安定して稼働する必要があります。
• 1 回限りの initContainer または Job が合格するには、コールド実行で正常に完了し、依存するすべてのワークロードが Ready になる必要があります。
• 低い階層でいずれかの受け入れ条件を満たせなかった場合は、次に合格する階層を使用し、新しいロールアウトから最終検証をやり直します。
• 観測された CPU とメモリのピーク値、および使用率は診断の根拠として扱い、受け入れ条件の不合格を階層引き上げの判断基準とします。
• Sealos リソースラダーに従って、上限からリクエストを算出します。

コンテナ内ブラウザー／リモートデスクトップの検証

• ブラウザー固有の検証は、Chrome、Chromium、VNC、WebRTC デスクトップ、Xvfb、Selkies、noVNC、Kasm、または類似のリモートデスクトップスタックを実行するコンテナにのみ適用します。Langflow のようにブラウザーからアクセスするウェブアプリケーションには、一般的な個人向け低負荷ポリシーを適用します。
• コールドスタートから Ready 状態になるまで、軽量なページ、実ページまたは中程度のページ、インタラクションまたは検索アクションを実行し、60 秒間の安定性を確認します。
• 最大表示解像度が 4K の Chrome + Xvfb + Selkies では、limits(cpu=200m,memory=1024Mi)、導出した requests(cpu=20m,memory=102Mi) で検証を開始し、同じ受け入れ条件のもとで隣接するラダー階層をテストします。

デフォルト値と入力値

• 生成される値（app_name、app_host、ランダムなパスワードやキー）にはdefaultsを使用します。
• inputsは、ユーザーが提供する実運用上の値（メールアドレス、SMTP、外部 API キーなど）にのみ使用します。
• 管理者入力を定義する前に、選択したリリースのアカウントフローを、機能する初回ユーザー登録、必須のブートストラップ認証情報、または任意の root 照合として分類します。
• 機能する初回ユーザー登録が可能で、デプロイ時に指定する任意の管理者認証情報に Template の入力スキーマでは表現できない起動時の致命的な制約がある場合は、登録フローを使用し、管理者／root 入力と、それらをブートストラップする環境変数／設定の注入を省略します。
• 必須のブートストラップ認証情報をデプロイ担当者が選択する場合は、ドキュメントに記載されたユーザー名またはメールアドレスとパスワードのフィールドを、spec.inputsに必須入力として宣言し、defaultは指定しません。上流で定められた正確な制約を英語で説明し、Template API にデプロイする前に収集した値を検証して、ライブログインにも同じ値を使用します。データベース認証情報は KubeBlocks のシークレットに保存します。
• 必須のブートストラップ認証情報が、サポート対象のランタイムによって生成される場合は、ドキュメントに記載された正確な形式を決定論的に構築して検証し、ユーザーによる選択がドキュメントに記載されていない限り、管理者入力を省略します。解決済みの認証情報は、ログイン時に値を伏せて使用できるよう、シークレットまたは稼働中のランタイムソースを通じて保持します。
• 任意の root 照合より、機能する初回ユーザー登録を優先します。選択したソースで必要とされる Frappe などの必須ブートストラップフローは維持します。
• Template アーティファクト内のすべての${{ inputs.<name> }}参照には、同じ Template CR 内の対応するspec.inputs.<name>宣言が必要です。
• Template CR 内のすべてのspec.defaults.<name>.valueと、存在するすべてのspec.inputs.<name>.defaultは、宣言された入力型にかかわらず、YAML 文字列としてデシリアライズできなければなりません。数値、ブール値、null に見えるスカラー値は引用符で囲みます。必須入力ではdefaultを省略できます。
• inputs.descriptionは英語で記述する必要があります。
• 起動に不可欠な生成デフォルト値は、アプリケーションのドキュメントに記載された検証を満たすよう、形式を決定論的に構築する必要があります。選択したランタイムが決定論的な生成をドキュメントに記載しており、解決済みの認証情報をシークレットまたは稼働中のランタイムソースを通じて保持してログイン時に値を伏せて使用できる場合に限り、必須のブートストラップ認証情報を生成します。初回ユーザー登録の認証情報は登録フローで扱います。
• 起動時の設定検証による終了を分類し、リソース調整より先にアカウントフローの契約を修正します。デプロイ前の検証からライブログインまで、ユーザーが指定した認証情報のすべてのバイトをそのまま保持します。
• 公式ソースに記載されたアプリケーションレベルの任意のオブジェクトストレージには、ブール型入力（たとえばenable_s3_storage）を使用し、inputs.<name> === 'true'で判定します。プロバイダー／バックエンド／タイプ／モード／ドライバーの選択は変換時に解決し、それらの選択子はspec.inputsに含めません。
• 任意のオブジェクトストレージ入力の false 分岐では、公式ソースに記載されたストレージ無効／ローカルモードを設定します。
• docker-to-sealos.database-mode: optional-managedが指定された任意管理データベースの契約では、管理対象の Cluster プレーンとデータベースの配線で、単一のブール条件を共有し、ドキュメントに記載された SQLite またはローカルの false 分岐を定義します。

検証コマンド

最終回答の前に、すべてのチェックを実行してください。

1. python scripts/path_converter.py --self-test
2. python scripts/test_check_consistency.py
3. python scripts/test_compose_to_template.py
4. python scripts/test_check_must_coverage.py
5. python scripts/check_consistency.py --skill SKILL.md --references references --rules-file references/rules-registry.yaml
6. 既存テンプレートの更新や、トポロジーに依存するその他の変換では、python scripts/check_consistency.py --skill SKILL.md --references references --rules-file references/rules-registry.yaml --artifacts template/<app-name>/index.yaml,.sealos/topology-evidence/<app-name>.yaml
7. python scripts/check_must_coverage.py --skill SKILL.md --mapping references/must-rules-map.yaml --rules-file references/rules-registry.yaml
8. （CI／一括実行）python scripts/quality_gate.py --require-topology-evidence --artifacts /abs/path/template/<app-name>/index.yaml,.sealos/topology-evidence/<app-name>.yaml、または DOCKER_TO_SEALOS_ARTIFACTS=/abs/path/template/<app-name>/index.yaml,.sealos/topology-evidence/<app-name>.yaml python scripts/quality_gate.py --require-topology-evidence（明示的に成果物を指定しない場合は、template/*/index.yaml と .sealos/*evidence*.yaml をスキャンします。成果物がない状態での開発／デバッグ時に限り、DOCKER_TO_SEALOS_ALLOW_EMPTY_ARTIFACTS=1 を設定してください）
9. ライブデプロイの受け入れ確認：sealos-deploy でアプリを作成した後、実際の App URL、Web アプリのログイン／セットアップフロー、最新ログ、ログを煩雑にするトレースバックを出さない、文書化された API のネガティブルートまたは一意な存在しない静的アセット、想定されるデータベースオブジェクト、およびリソース使用量全体を確認してから、成功を報告してください。

check_consistency.py はレジストリ駆動です。references/rules-registry.yaml を実装済みルールと同期させてください。 レジストリのルール項目は、severity と任意の scope.include_paths メタデータに対応しています。

出力要件

変換が完了したら、次を提示してください。

1. 変換内容の簡潔な概要
2. 対象ファイルのパス（template/<app-name>/index.yaml）
3. テンプレート YAML 全文
4. 曖昧さがあった場合に限り、主な判断事項

このスキルで README の内容を作成または出力しないでください。README の生成は別のスキルに委任されています。

リファレンスの参照（段階的な読み込み）

現在のタスクに必要なリファレンスのみを読み込んでください。

• references/sealos-specs.md
  • 正式な順序、ラベル、App／Ingress／ConfigMap の規約
• references/bootstrap-account-modes.md
  • アカウントフローの分類、Template の入力制限、ブートストラップ認証情報の契約、受け入れ確認
• references/conversion-mappings.md
  • Docker から Sealos へのフィールド単位の対応付けと特殊な変換
• references/database-templates.md
  • データベーステンプレート、RBAC 構造、Secret の命名パターン
• references/frappe-bench.md
  • Frappe／ERPNext／HRMS／bench の変換パターン、初期化リソース、冪等なサイトのブートストラップ、一般的な障害の兆候
• references/runtime-log-hygiene.md
  • ランタイムログの受け入れ確認、問題のない 404 トレースバックへの対処、依存関係の静かなインストール、制限付きセキュリティコンテキストのガイダンス
• references/example-guide.md
  • 例とパターンの解説（正式な仕様ではありません）
• references/rules-registry.yaml
  • 機械可読な検証スコープ／ルール一覧
• references/must-rules-map.yaml
  • ドリフト制御のための MUST 項目から適用ルールへのマッピング（rule または manual）

スクリプトユーティリティ

• scripts/path_converter.py
  • パスを vn 名に変換します
  • リグレッションチェック用のセルフテストに対応しています
• scripts/compose_to_template.py
  • Compose／ドキュメントからテンプレートを生成する、決定的なエントリーポイントです
  • --kompose-mode auto|always|never に対応しています（デフォルトは always）。kompose convert のワークロード構成を再利用します
  • template/<app-name>/index.yaml を出力します
• scripts/test_compose_to_template.py
  • Compose 変換動作のリグレッションテストです
• scripts/check_consistency.py
  • レジストリ主導の整合性バリデーターです
• scripts/test_check_consistency.py
  • バリデーターの動作に関するリグレッションテストです
• scripts/check_must_coverage.py
  • MUST 箇条書きのカバレッジマッピングをレジストリルールに照らして検証します
• scripts/test_check_must_coverage.py
  • MUST カバレッジバリデーターのリグレッションテストです

エッジポリシー

• 不足しているフィールドについてユーザーに尋ねず、Compose／ドキュメントとプラットフォームの規約から推測します。
• App リソースは spec.data.url 形式を維持し、spec.template は決して使用しません。
• App リソースの spec.displayType: normal と spec.type: link を維持し、別の列挙値を推測しません。
• business-env、オブジェクトストレージ、DB シークレットのポリシーを MUST ルールと一致させます。
• 正方形または円形でアイコンを優先したロゴ素材（アプリアイコン／ファビコン／アバター）を優先し、長方形のワードマークやテキストロゴは避けます。
• 同梱のエッジプロキシより Sealos 管理の Ingress を優先します。Traefik ゲートウェイが Ingress／フロントプロキシとしてのみ機能し、ビジネスサービスが少なくとも 1 つ存在する場合、Traefik のワークロードリソースは出力しません。
• コンテナ内の TLS より Sealos Ingress でのゲートウェイ TLS 終端を優先します。HTTP／HTTPS のデュアルポートワークロードでは、HTTP サービスポートを維持し、公式ドキュメントで HTTPS バックエンドが必要とされていない限り、冗長な HTTPS／証明書マウントを削除します。
• パブリックな ws://、wss://、CDP／Chrome DevTools、ゲームソケット、WebSocket と名付けられたポート／サービスには、WebSocket Ingress を優先します。読み取り／送信タイムアウトを 3600 に設定し、backend-protocol: WS を使用します。
• template/<app-name>/README.md または template/<app-name>/README_zh.md は決して作成しません。テンプレートスキーマで必要な場合に限り、index.yaml 内の README URL 参照を維持します。
• 競合が発生した場合は、例外を追加するより参照／例を修正することを優先します。
• 選択したソーストポロジーを維持しながら、公式の Kubernetes インストール用ドキュメント／マニフェストを使ってランタイムの動作を調整します。
• プロジェクトで Frappe、ERPNext、HRMS、または bench に言及している場合、アプリのワークロードを生成する前に references/frappe-bench.md を読み込みます。