Nextora デザインシステム は何をしますか？
このスイートにおける外観の単一権威です。子テーマコード、ブロックコード、テンプレート、パターンはすべて、パレット、タイポグラフィ、トークン、スタイルバリエーション、スイッチャーについてここに従います。新しい子テーマの場合はこのスキルを nextora-child-themes と一緒に読み込み、再スタイルまたは新規ブロックの場合は nextora-gutenberg-blocks と一緒に読み込んでください。
最初にこれらのリファレンスを読み込む
| ファイル | 読み込む目的 |
|---|---|
references/presets-and-switching.md | 正規プリセット ID、ロール変数、スコープ付きカラーストレージと PHP 解決、2 つのスタイルメカニズム、フィーチャーゲート、子テーマが貢献するもの、発見/マージルール、scheme-switcher.json のセマンティクス、実行時優先順位、新しい子テーマの :root ロールデフォルト、およびアンチクレームリスト。 |
../nextora-ecosystem/references/source-map.md | 出处とルート解決の語彙。 |
../nextora-ecosystem/references/quality-gates.md | ゲートと共有ダウンストリーム受け入れレシピ（§8）。 |
リファレンスに記載されている値はアンカーであり、現在のデータではありません。編集する前に、ターゲット自身の theme.json、CSS エントリ、styles/、スイッチャーファイルを再読み込みしてください。
順序付きワークフロー
1. ターゲットを特定し、ライブの外観ソースを識別する
親テーマルートとアクティブテーマルートを特定します。次に、次の順序で読み込みます：theme.json（パレット、グラデーション、フォントファミリー、サイズ、スペーシング、styles、customTemplates）、出荷される CSS エントリ（親テーマの場合は resources/css/app.css、子テーマの場合は独自のエントリ）、styles/ ツリー、scheme-switcher.json。スキル、スクリーンショット、サンプル子テーマからパレット値を取得しないでください。
2. 正しいメカニズムを決定する
| ニーズ | 使用するもの |
|---|---|
| 作成者がブロックラッパーの色/タイポグラフィ/スペーシングを選択する | コアブロック supports + get_block_wrapper_attributes() |
| ブロック自身の表面内の色 | プリセットスラッグとして保存され、出力時にプリセット変数に解決されるスコープ付き属性（§5） |
| 所有者が選択して保持するサイト全体の代替ルック | theme.json スタイルバリエーション（styles/*.json、styles/typography/*.json） |
| 訪問者向けプレビュー選択 | スイッチャー。ただしそのゲートの背後でのみ（§6） |
| 子テーマ全体のブランドデフォルト | 子テーマのパレット/フォントコントリビューション + :root ロールデフォルト（§7） |
まずネイティブサポートを優先してください。グローバルスタイルで表現できない場合にのみスコープ付きオーバーライドを追加し、これらの 2 つの外観システムの横に別のシステムを発明しないでください。
3. プリセットは追加的に、かつ識別子で変更する
スラッグを追加してください。継承されたコンテンツで既に使用されている親テーマのスラッグをリネームしたり再ポイントしたりしないでください。すべての表面は var(--wp--preset--color--<slug>)、var(--wp--preset--gradient--<slug>)、または var(--wp--preset--font-family--<slug>) を読み取るため、テーマ CSS 内のリテラルな 16 進数はその表面をパレット変更やスイッチャーから除外します。Tailwind @theme エイリアスは、CSS ビルドがそれを消費する場合にのみミラーリングし、古いガイドからエイリアスブロックをコピーするのではなく、各エイリアスが実際に何を指しているかを検証してください。親テーマの --color-secondary は現在 paragraph プリセットに解決されます。
4. タイポグラフィを Nextora ロール経由でルーティングする
ボディ、見出し、ボタンのタイポグラフィは --nextora-font-body、--nextora-font-heading、--nextora-font-button 経由で解決されます。theme.json は var(--nextora-font-body) を使用します。スイッチャーはこれら 3 つのプロパティを具体的なファミリースタックで <html> にインラインで書き込みます。プリセット変数を直接読み取る表面は、訪問者のフォント変更に追随しません。theme.json でフォントファミリーを追加または変更し（システムスタックでない場合は fontFace アセットを使用）、プリセット選択肢として提供する前にそれを読み込んでください。
5. スコープ付きカラーはプリセットとして保存し、出力時に解決する
blocks/advanced-icon/color-utils.ts（normalizeColorForStorage、colorValueForPicker）とその PHP 版（nextora_icon_resolve_color、nextora_icon_hex_to_preset_slug、nextora_ac_resolve_color）の既存のヘルパーパターンに従ってください。選択されたプリセットはそのスラッグを保存します。パレットエントリに一致する完全不透明な 16 進数はそのエントリのスラッグに正規化されます。カスタムカラーと部分アルファの 8 桁 16 進数はリテラルなまま保持されます。グラデーションも同様にプリセット ID を保持します。出力時、保存されたスラッグは var(--wp--preset--color--<slug>) になり、パレット変更が表面に到達します。8 桁 16 進数は sanitize_hex_color() の前に処理されます。空の値は「テーマデフォルト」を意味し、何も出力しません。実際のシグネチャを再利用し、パラレルなリゾルバーを書かないでください。カラーコントロールはサニタイザーではないことを覚えておいてください。保存された HTML はそれでも wp_kses_post() を通過します。
6. スイッチャーゲートを尊重し、コードではなくデータを貢献する
訪問者スイッチャーは NEXTORA_COLOR_SCHEME_SWITCHER が厳密に true の場合にのみ存在します。それ以外の場合は、ペイロード、スクリプト、ページテーマ CSS、ポップオーバーはありません。そして、そのギャップを埋めるために子テーマ側で代替手段を書くべきではありません。子テーマはデータを貢献します：styles/color-scheme/*.json、styles/font-preset/*.json、オプションでバンドルバリエーション用の styles/*.json、およびオプションの scheme-switcher.json 許可リスト。新しい子テーマを作成するときは、後で読み込まれる CSS の :root に子テーマ自身のデフォルトロールを設定し（リファレンスの§7）、プリセットフォントを固定しないでください。子テーマにスイッチャーの実装を決して追加しないでください。
7. 実際の表面で検証する
ターゲット自身のスクリプト（npm run build:css または npm run build）でビルドしてください。assets/css/* の出力を編集したり、ビルドが assets/js/scheme-switcher.js を再生成すると述べたりしないでください。これは手動でメンテナンスされており、パイプライン外です。次に、../nextora-ecosystem/references/quality-gates.md とその §8 デザインシステムレシピ、および references/presets-and-switching.md §10 のプリセット固有の手順を適用してください。
ハードリミット
- ブランドパレットをハードコードしないでください。値はターゲットのアクティブなプリセットから取得します。
- 古いドキュメントの古いフォールバック 16 進数を新しいテーマ CSS に伝搬しないでください。
- スイッチャーを再実装しないでください。また、サンプル子テーマが正しく見えるからといってそれが機能すると主張しないでください。サンプルは独自のフォントを固定し、子テーマ専用のパレットエントリを追加しています。
- カラー URL パラメータが既に解決されたバンドルテーマをオーバーライドできるとか、リセットがサイトエディターのスタイルを消去できると約束しないでください。
- テーマスタイルシートから
wp-adminのクロームを再スタイルしないでください。エディターリセットはエディターキャンバス内に留めてください。 - 宣言された WordPress/PHP の最低要件を静かに引き上げないでください。代わりにその要件を表面化してください。
- この作業の実行中に親テーマやサンプル子テーマを変更しないでください。
完了チェック
- ターゲットテーマが特定されました。参照されるすべてのプリセット、フォント、グラデーション、トークンがそのテーマ自身の
theme.json/バリエーションに存在します。 - ステップ 2 のメカニズム表に従いました。ネイティブサポートが十分な場合はそれを使用しました。
- タイポグラフィは
--nextora-font-*ロール経由で解決され、プリセット変更に追随します。 - スコープ付きカラーは、色がプリセットに一致する場合はプリセットスラッグを保存し、カスタムおよび部分アルファ値はリテラルなまま保持し、プリセット変数経由でレンダリングします。
- スイッチャーゲートが尊重されています。子テーマの貢献はデータのみです。新しい子テーマのデフォルトペアは
:rootでロール経由で宣言されています。 - スタイルバリエーション（永続的）とスイッチャー（実行時プレビュー）は異なるものとして説明され、テストされています。
- §8 の受け入れ手順が計算されたスタイルに対して実行されたか、未検証の表面が明確に報告されています。
境界
マークダウンインストラクションとソースバックアップのリファレンスのみ：ランタイムスクリプト、ジェネレーター、コピーされたテーマツリー、パッケージ管理、インストール自動化はなく、親テーマや子テーマのソースへの編集もありません。ダウンストリームのビルドおよびブラウザ検証コマンドはターゲットテーマに属し、../nextora-ecosystem/references/quality-gates.md にリストされています。