Compose Landing Page
user_config_info.json 設定を、業務的に正しく、視覚的にユニークで、ブラウザでそのまま実行可能な教育用ランディングページ単一ファイルHTMLに変換します。このプロセスは自己完結型で、外部システムには依存しません。
設定契約バージョン 3.0、核心：conversionFlow が変換フローの唯一の事実ソースとなります。
入力
| ファイル | 役割 |
|---|---|
user_config_info.json | 現在のプロジェクトの実際の設定（ユーザー提供） |
references/user-config-spec.md | フィールド仕様書：フィールドの意味、型、許可値、デフォルト値 |
references/business-rules.md | ビジネスガードレール：コンバージョン、予約、複数子供・複数教科などの振る舞い不変条件 |
references/frontend-design.md | ビジュアル方向性：テーマ素材、フォント、レイアウト、反テンプレート判断 |
references/engineering-conventions.md | エンジニアリングガードレール：CJK 対応、i18n レンダリングモード、命名分離、初期読み込み |
references/question-bank.json | 標準問題バンク：問題本文、選択肢、科目分類マッピング |
参照ファイルは内蔵されています。ユーザーは user_config_info.json のみを提供すれば十分です。
優先順位
有効な設定 → ビジネス不変条件 → ユーザーの明確な要求 → エンジニアリング規約 → 美的方向性
設定は読み取り専用の事実であり、生成、補完、検証は行いません。conversionFlow のフェーズ順序とノード順序は変更不可です。競合が生じた場合は、具体的なフィールドとルールを指摘し、黙って推測することはしません。
Workflow
ステップ 1：設定の取得
user_config_info.json を読み取ります。提供されていない場合は停止します。解析に失敗した場合はエラーの位置を指摘します。project.notes が空でない場合、構造、トーン、ビジュアルスタイルに関するユーザーの補足的な好みとみなし、ステップ5の美的方向性に直接影響を与えますが、構造化フィールドや機能スイッチを上書きすることはありません。
ステップ 2：フィールド仕様書の読み取り
user-config-spec.md を完全に読み取り、各フィールドのセマンティクスを理解します。特に conversionFlow の2層の順序（フェーズ順序 + ノード順序）と、5種類のアイテムタイプ（field / question / verification / booking / calendarSync）に焦点を当てます。スキーマ検証は実行しません。
ステップ 3：読み取り専用ビジネスモデルの構築
設定とフィールド仕様書に基づき、思考内で現在のプロジェクトのビジネスモデルを抽出します：
- 科目：入力科目（
project.subject）+ 追加科目（extraSubjects） - 変換フロー：
conversionFlowのフェーズ順序とノード順序、verificationノードが存在するフェーズが検証コードの位置 - フィールド：有効なもの、必須のもの、所属（親/子）、科目条件付きフィールド
- スイッチ：
booking/multiChild/multiSubject/syncCalendar/contactMode/flowMode - 事前要件ユニット：
leadフェーズ内のすべての field および question ノード（items の順序に従う） - 問題バンクマッチング：
kind=questionノードのquestionIdをquestion-bank.jsonと照合し、project.languageに従って中国語または英語のテキストを選択、送信データはoptionIdを使用
ステップ 4：ビジネスルールの読み取り
business-rules.md を完全に読み取り、満たすべきビジネス不変条件を抽出します。ビジネスルールは結果の制約であり、モジュールのリストではありません。AI はこれらの制約に基づいて情報アーキテクチャを自律的に決定します。
ステップ 5：美的方向性の形成
frontend-design.md を完全に読み取り、その指示に従って2段階のデザインプランを作成します：
- ブレインストーミング：色（4〜6の16進数）、タイポグラフィ（2つ以上のフォントロール）、レイアウト（1文 + ASCII ワイヤーフレーム）、シグネチャ（単一のユニークな要素）
- 批評：
project.theme、project.adScene、project.notesと照らし合わせて自己批評します。どの部分も汎用的なデフォルトのように読める場合は修正し、独自性を確認してからコードを書き始めます
ステップ 6：ページコードの生成
まず engineering-conventions.md を読み取り、現在の設定によってトリガーされるエンジニアリング制約（CJK 単位、i18n レンダリングモード、命名分離、初期読み込み）を理解します。これらはコード品質のガードレールであり、ビジネス結果を変更しません。
完全な単一ファイルHTMLを出力します：
<head>には meta、title、Google Fonts CDN の読み込み、インライン<style>を含む；<body>にはインライン<script>を含む- 外部ビルドツール、npm パッケージ、ローカルファイルに依存しない
- CSS はインライン化し、セレクタの特異性に注意；JS はインライン化し、設定で要求されるすべての業務フローを実装する
- すべてのインタラクションはブラウザ内で完了可能（フォーム送信はモック可能だが、明示的にラベル付けする必要がある）
- 装飾要素は優先的にインライン SVG を使用；写真素材は無料 CDN 画像ライブラリの直接リンクを使用し、サイズ制約を追加する
- モバイル対応のレスポンシブデザイン、キーボードフォーカスが可視、
prefers-reduced-motionを尊重する
業務動作は business-rules.md のセクション5〜11に従って実装します。コーディングレベルの追加要件：
- 検証コードコンテナは
data-verification-stage属性でフェーズをマークする - 実際の時間枠データがない場合は、明確にラベル付けされたプロトタイプデータを使用し、在庫を偽装しない
- 非表示フィールド、無効な機能、選択されていないブランチのデータは送信結果に含めない
ステップ 7：自己チェック
納品前に、チェックリストに照らして自己チェックを行います：
- 業務的正確性：
business-rules.mdの受入チェックリストに従って項目ごとに確認する - デザイン品質：プランは自己批評を通過、フォントと色はプランから導出、シグネチャはユニーク、レスポンシブ、キーボードフォーカス、
prefers-reduced-motion、CSS セレクタに打ち消しがないこと - エンジニアリング安定性：
engineering-conventions.mdの自己チェックリストに従って項目ごとに確認する（CJK 単位、i18n レンダリングモード、命名プレフィックス、スコープ分離、初期読み込み） - コード実行可能性：単一ファイルを直接開いて実行可能、外部依存なし、フォントはCDN経由
ステップ 8：納品
ファイルをユーザーの作業ディレクトリに保存します。ファイル名は project.name に基づきます。簡潔な自然言語で説明します：どの設定に基づいているか、どのコア機能を実装しているか、シグネチャ要素は何か、どのデータがプロトタイプで置き換えが必要か。
失敗モード
| 状況 | 処理 |
|---|---|
user_config_info.json が提供されていない | 停止し、設定ファイルが必要であることを伝える |
| JSON 解析失敗 | エラー位置を指摘し、修正を推測しない |
| 設定がビジネスルールと競合 | 具体的なフィールドとルールを指摘し、ユーザーに確認を求める |
conversionFlow に未知の kind が出現 | 具体的なノードを指摘し、黙ってスキップしない |
| 実際のデータが必要だが存在しない | 明確にラベル付けされたプロトタイプデータを使用し、実際のデータとして偽装しない |
| ユーザー要求と設定が競合 | 優先順位チェーンに従って処理し、ユーザーに説明する |