# シマビルダー用マイGPT 知識統合ルール（引き継ぎテンプレート統合版）

最終更新：2026-07-25
更新範囲：Prompt Compiler履歴復元、雪原UI、POS/NEG分離、品質セット、セット試着、出力先検索高速化、マイプリセット統一、作品形式スターター、衣装・装備・食・髪・ポーズ・武装・背景・演出の各アカシック、通常／成人衣装工房、アルカディア階級表示、成人スタートデッキ、遅延カード描画、スマホ一列、Android初回読み込み競争の解消、棚／選択中／出力ナビの自己修復、衣装棚の平時→深層7段階統制、湯浴み・追加18着の9系統再配置、食の組み立て航路、対象別handling、支持体32種、意味的ブースト・アカシック、通常／成人の意味表現分離、A/B/C意味調律、表情棚の7段階統制、基本14感情の復旧、表情A/B/C調律、人物同一性保護、相性診断、明示適用
今回追加：SHIMA FETISH LIMIT BREAK v5.3、成人おまかせ240から840への拡張、成人学園風・学生服／体操服・レオタード／水着／ドレス／チャイナドレス・文化礼装／美の女神／淫欲の悪魔／ランジェリー／成人制服・サービス職／神話種族・異世界女王の10テーマ各60件、成人専用計20群100カテゴリ1000件、通常660件維持、完成セット940・後付け部品720、全完成セットの内包4要素説明、成人・合意明記と未成年／性行為／強制語禁止、文化衣装の尊重、R-18未解放時input非生成、v5.2成人400件の構造・安定input ID全件維持、initial closed・スマホ一列・直接チェック、検索・お気に入り・選択中・履歴・マイプリセット・リセット互換、ロック／解放DOM実装監査

追補範囲（v5.4）：成人向け15テーマ・スタートデッキ、非選択ジャンプ、テーマ別選択数表示、成人1000安定inputを維持したカード遅延描画、検索一致カテゴリ先行描画、選択中・お気に入り・履歴・マイプリセットの安定ID復元、成人collector version 504、初期カード0枚の実DOM監査
今回追加（v5.4）：SHIMA ADULT START DECK v5.4。成人おまかせ15テーマを「今日はどの大人衣装？」の入口へ一列表示し、入口操作は選択を変えず対象群へだけ移動する。成人1000 inputは解放時に安定ID付きで先置きし、カード本文はカテゴリ展開、文字検索、選択中、お気に入り移動時だけ生成する。初期カード0、実操作後40、未描画960を仮想ブラウザで確認し、専用22 / 22・全回帰259 / 259へ更新した。

履歴（v5.5・先頭固定はv5.6で廃止）：衣装の埋もれ防止、発見入口の先頭固定、湯浴み・湯上がり・スパ衣装の専用化、既存語を消さない再発見完成セット7件、第1便新規18着、用途別9カテゴリ、全カードの内容説明、Positive通常・安定ID、検索・お気に入り・履歴・マイプリセット・リセット再同期
履歴詳細（v5.5）：SHIMA BATH DISCOVERY WAVE 1 v5.5では、衣装一覧の標準10棚より前へ「新着・埋もれない衣装入口」を固定していた。この先頭固定と一箱化はv5.6で廃止し、データ25件と安定IDだけを継承する。

追補範囲（v5.5.1）：Android初回読み込みが補助UIの固定待機時間を超えた時の欠落修正、マニフェスト完了通知、時間上限なしの低頻度再試行、棚／選択中／出力ナビの優先生成、部分生成からの再水和、DOM欠落の自己修復、イベントと監視の重複防止
今回追加（v5.5.1）：SHIMA UI BOOT GUARD v5.5.1。旧ZERO Assistは起動から約18秒、シマナビは約22秒で待機を打ち切っていたため、84本・約3.3万項目を組むAndroid初回だけ本体完成後も固定下部ナビが存在しない場合があった。固定回数制限を廃止し、`builder:mounted`、`promptPartMounted`、対象DOMのMutationObserver、1.2秒の低頻度保険再試行で実際の準備完了を待つ。三つの切替を優先生成し、既存DOMを再利用して成功後だけmountedを確定する。20.5秒遅延で旧版0表示・新版3表示、ナビ全削除後も3表示へ復旧、専用7 / 7・全回帰281 / 281を確認した。

追補範囲（v5.6）：衣装棚全体の統制、平時から深層へ進む7段階順、日常棚の先頭保証、発見時期ではなく用途による分類、湯浴み12件と追加13件の9カテゴリ統合、専門／創作／改造の特化棚分離、R-18最深部維持
今回追加（v5.6）：SHIMA ATTIRE DEPTH TAXONOMY v5.6。旧v5.5の「新着・埋もれない衣装入口」を廃止し、日常・ベーシックを必ず最初にした。表示順は `01 平時・日常 → 02 社会・公的 → 03 文化・余暇・私生活 → 04 非日常・世界観 → 05 専門・特化 → 06 創作・幻想技術 → 07 改造・ディテール → 08 R-18`。湯浴み12件と第1便残り13件は一箱のまま移動せず、既存9カテゴリを役割／伝統／サブカル／水着・室内・湯上がり／SFへ分配した。25件のinput ID・prompt・checked状態・履歴・お気に入り・マイプリセット互換を維持する。全回帰283 / 283、仮想DOM単体監査と全86スクリプト読込監査で、9カテゴリ・25 input・再整理後の選択維持を確認した。

追補範囲（v5.8）：食材選択後の `サイズ・量 → 扱い方 → 支持体 → 仕上げ` 航路、既存サイズcheckboxの代理操作、対象別handling 11種、vessel 32種、おすすめ先行＋全候補、同一対象の8軸工房handoff、履歴／全リセット時の安全close
今回追加（v5.8）：SHIMA FOOD ROUTE DECK v5.8。旧サイズ案内を削除せず、trustedな航路起動中だけ抑制して0段へ統合した。handlingはfoodStateConfigの8軸目として対象別保存し、弁当箱等16支持体を追加した。航路自体はaccessories version 6・単独タグ0で、既存version 1〜5のcollectorを再利用する。全量DOMで食棚11・1,999 input、鮭の切り身へunitサイズ／箸／弁当箱／焼きたて・大根おろしの一体Positive、詳細工房handoff、リセット／履歴closeを確認し、全回帰308 / 308へ更新した。

追補範囲（v5.9）：汎用品質語ではなく被写体の意味・魅力・存在感を強める専用アカシック、通常528件、成人専用216件、完成セット72件、詳細672件、標準／高水準／特盛り、8段階強度、用途別の非選択航路、品質・衣装・人種・髪色・背景との責務分離
今回追加（v5.9）：SHIMA SEMANTIC BOOST AKASHIC v5.9。表情と衣装の間へ独立した `semantic_boost` セクションを設けた。通常は16テーマ×3濃度の完成48件と、全体オーラ／女性的魅力／男性的魅力／中性・幻想・人外／顔／目／口元／体型／身体言語／肌・髪の微細表現を各8強度で選ぶ詳細480件。R-18解放後だけ、成人8テーマ×3濃度の完成24件と、成人女性／成人男性・中性・人外／視線・唇・呼吸／身体言語・距離感の詳細192件を追加する。全744件はPositive専用・安定ID付き。`masterpiece`、解像度、衣装、背景、人種、髪色を混ぜず、成人側216件は成人・合意を明記し、未成年・性行為・強制語を含めない。入口は11用途／成人5用途へ移動するだけでチェックを変更しない。手操作時だけ完成セットと同軸強度を排他にし、履歴復元時の重複は消さず警告する。全回帰325 / 325、実DOM通常528／成人216、Android幅412pxで横溢れ0・縦書き0・直接チェック・Positive同期を確認した。

追補範囲（v6.0）：既存744件だけを材料にした意味的ブースト調律室、対象・印象・濃度の3問、A／B／C候補比較、プレビュー非選択、置換／相性調整追加、同軸重複・意味対比・積みすぎ診断、通常／成人境界、Android一列UI
今回追加（v6.0）：SHIMA SEMANTIC TUNING LAB v6.0。通常9対象×16印象、成人5対象×8印象、4濃度から、A一押し完成型／B対象集中型／C均整レイヤー型を生成する。調律室自身はprompt語・input・collectorを追加せず、v5.9の完成セット72件と詳細部品672件だけを参照する。候補選択まではcheckboxを変えず、下部の明示適用時だけ反映する。置換は対象scopeだけを一度解除し、追加は完成セット競合と同軸強度だけを整理して他の意味表現を維持する。柔和×威圧等の対比は表現意図になり得るため警告だけを表示し、自動削除しない。R-18未解放時は成人調律室を生成しない。全回帰336 / 336、調律室専用11 / 11、実DOM通常528／成人216、Android幅412pxで候補3枚、プレビュー選択0、明示適用4、横溢れ0、縦書き0を確認した。

追補範囲（v6.1）：表情棚の増築順解消、完成から深層へ進む7段階、既存checkbox DOM移動、旧v1／v2初期化エラー遮断、基本感情14件の復旧、通常12／成人4用途のA/B/C表情調律、候補非選択、目の色・形・瞳孔保護、同役割・意味対比・積みすぎ診断、完全同語の互換保管庫、R-18境界、Android一列
今回追加（v6.1）：SHIMA EXPRESSION ATLAS v6.1。表情v1〜v5を `01 すぐ決める → 02 基本感情 → 03 目・視線・口元 → 04 赤面・涙・汗・漫符 → 05 場面リアクション → 06 深層演技 → 07 成人向け` へ再編した。既存inputは複製せずDOMごと移し、prompt・checked・イベント・collector互換を維持する。旧v1の `IS_UNLOCKED`、旧v2の `FACE_EFFECTS_GROUPS` 未定義をアカシック有効時だけ停止し、v3が包含しない基本14感情だけを元promptで回収した。入口は移動だけ、A／B／C候補も非選択で、置換／相性調整追加の明示操作時だけ反映する。目の色・形・瞳孔は人物同一性として解除しない。通常512件、解放時は成人303件を加え815件。全回帰353 / 353、専用17 / 17、412px Chromiumで横溢れ0・縦書き0・page error 0を確認した。

追補範囲（v6.1.1）：表情棚を開いた時の意図しない2列化修正、共通open-detailsグリッドとの競合遮断、棚本文・調律室・選択欄・候補・操作欄の常時一列固定
今回追加（v6.1.1）：SHIMA EXPRESSION ATLAS v6.1.1。共通規則 `.section-content details[open] > div` のauto-fillが、表情棚本文へ再適用され、説明文と表情調律室を左右へ分断していた。表情アカシックID配下へ高優先度の一列規則を置き、画面幅に関係なく `説明 → 調律室 → 既存完成束`、調律室内は `感情 → 濃度 → A／B／C候補 → 診断 → 適用` の順に縦へ流す。既存checkbox、prompt、stable ID、checked、候補生成、適用処理は変更しない。全回帰354 / 354、専用18 / 18、Android幅412pxの完全版Chromiumで全主要コンテナ1列、横溢れ0、縦書き0、page error 0、manifest成功96／失敗0を確認した。

## 0. この知識の目的
この知識は「イラスト生成AIプロンプトビルダーv5」の修復・拡張・棚整理・UI表示修正を安定して行うための共通ルール集である。特定案件だけに寄りすぎないよう、全カテゴリー共通ルールを先に置き、シマエナガ・なりきり・ペア補助・R-18・Raceなどはカテゴリ別補助ルールとして扱う。

このファイルはルール集であると同時に、別スレッド・別担当へ安全に作業を渡すための引き継ぎテンプレートでもある。新しい修正が確定したら、単発の作業メモで終わらせず、再発防止・互換性・確認手順まで含めて該当章へ反映する。

## 0A. スレッド開始時の引き継ぎテンプレート

新しいスレッドを開始する時は、最新zipとこのルールを添付し、分かる範囲で次を埋める。不明欄は推測で埋めず「未確認」とする。

```text
【シマビルダー引き継ぎ】
作業ベースzip：
基準バージョン / フォルダ名：
実機環境：Android機種 / ブラウザ / 画面幅（分かる範囲）

今回の目的：
ユーザーが見た症状：
再現手順：
対象の棚 / 機能：
対象候補ファイル：

必ず維持するもの：
出力先：POS通常 / POS抑制 / POS表現 / NEG専用 / 複数
安定ID・保存互換：
localStorage / 履歴 / マイプリセットへの影響：
manifest読込順・後勝ちデータへの注意：

今回の最小修正案：
自動テスト：
実機で確認する操作：
納品物：touch-only zip / 全体zip / 両方
確認済み：
未確認：
```

開始時の必須確認：
- 最新zipを唯一の作業ベースにする。
- 症状の画像だけでなく、実際のDOM・イベント・最終実行時データまで確認する。
- 以前の修正名やソース上の件数を、現在の実行状態だと決めつけない。
- 「確認済み」は、静的検査・自動テスト・Android実機確認のどれかを明記する。

## 0B. スレッド終了時の更新テンプレート

修正完了時は、ユーザーへの短い報告とは別に、次回担当が迷わない粒度でこのファイルへ結論を残す。

```text
【今回の確定事項】
症状 / 要望：
原因：
変更ファイル：
確定した仕様：
互換性対応：
再発防止ルール：

自動確認：node --check / DOMテスト / データ監査 / zip整合性
実機確認：確認済み / ユーザー確認待ち
未確認事項：
納品zip：
次の優先候補：
```

ルール更新時は、同じ意味の注意を末尾へ無制限に足さない。既存章へ統合できるものは統合し、案件固有の語彙だけなら「カテゴリ別案件メモ」に分離する。

## 1. 最重要作業原則
- ユーザーがアップロードした最新zipを唯一の作業ベースにする。
- 過去zip、過去スレ修正版、記憶上の旧ファイルを勝手に参照しない。
- 作業前に対象ファイルと関連ルールtxtを読む。
- 既存構造を壊さず、必要箇所だけを最小修正する。
- Android環境を考慮し、単体.jsではなくzipで返す。
- 基本は「触ったファイルだけのtouch-only zip」を返し、必要なら全体zipも返す。
- JSを修正したら可能な限り node --check で構文確認する。
- ソース上の追加だけで完了とせず、manifest読込後の最終実行時データと実DOMを確認する。
- 修正後は、変更点・確認結果・未確認点を短く報告する。

## 2. UIに出ない時の最優先診断
「データに追加した＝UIに出る」ではない。UIが参照する表示リスト・描画配列・grouped key・表示パスに入っているか確認する。

確認順：
1. データ側に追加されているか。
2. UI側の表示配列 / 描画対象 / initUI / buildUI / createSection に登録されているか。
3. 親棚のchildren内へ1段深く潜っていないか。
4. 後続 initUI、version順 mount、ext側append、normalize、parent.innerHTML = "" で消されていないか。
5. 並列トップ棚にしたい場合、rootを1個描くのではなく children を個別 append しているか。
6. 表示順はデータ順だけでなく、最終的に誰が最後にappendしたかで決まる。必要なら post-mount normalize で実DOMを整列する。

禁止：
- parent.innerHTML = "" で親全体を安易に全消しする。
- データだけ追加して表示確認を省く。
- bundle単独で最終順を保証したつもりになる。

## 3. 特化コレクション共通構造
特化コレクションは、単語の平置きではなく原則として以下の階層で設計する。

- 完成セット：方向性と主役の核。ワンクリック連動の起点。
- ベース：キャラ・衣装・物体・状態の土台。
- カスタマイズ：差分・強調・派生・小物・所作。
- 設定：空間・意味づけ・雰囲気・関係性。
- 必要に応じてクオリティセット / 完成セット別クオリティ微調整を追加してよい。

表示上の基本：
- 特化コレクションを親棚の奥に潜らせない。
- 複数特化コレクションは同格トップ棚として並べる。
- 特化群と通常棚は混ぜず、小さな見出しと区切り線で分ける。
- 特化コレクション名の変更は危険。UI分岐がtitle完全一致で組まれている場合があるため、名称変更前にbundle側の条件分岐を確認する。

## 4. 完成セット・クオリティセットのリセット規則
完成セット欄は「追加チェック」ではなく「完成セット基準で状態を再構築する起点」として扱う。

完成セットを新しく選ぶ時：
1. 既存の完成セットチェックを外す。
2. 既存の完成セット由来の下位連動を外す。
3. 新しい完成セットだけをONにする。
4. 対応するベース / カスタマイズ / 設定 / 必要ならクオリティへ連動する。
5. 連動した棚を開く。

完成セットを外す時：
- その完成セット由来の下位連動も外す。
- 完成セットOFFなのに下位連動だけ残す状態を作らない。

クオリティセットも同様に、セット選択・解除・切替時は由来項目をリセットして再構築する。下位の実クオリティ項目を手動変更したら、上段クオリティセット状態は解除する。

## 5. プロンプト設計・なりきり制御
- 否定語を過剰に並べない。禁止語の連打は、逆にモデルへその要素を思い出させる場合がある。
- 「出すな」より「こう出す」を優先する。
- 神獣・悪魔・融合・異形系は、別個体を呼ぶのではなく、身体接続型で固定する。
- 有効な肯定語例：single humanoid character focus / clearly human face / traits integrated into the character body / attached compact wings / horns attached to the head / single merged character design。
- 比喩が多すぎると絵に出ない。実際に見える語（衣装、角、翼、尾、手、視線、姿勢、背景、光、質感）を優先する。
- 髪色・肌色・体型など、ユーザーの「うちの子」を壊しやすい固定語は慎重に扱う。
- Quality Core と Quality Flavor を分け、異形・融合系ではFlavorを間引いて主題を守る。subject_profile を使う場合、bio_fusion / dragon_hybrid / silhouette_beast / symbolic_avatar / tech_fusion などで制御する。

## 6. ペア補助ルール
ペア補助は完成セットを 1girl + 1boy の男女ペア構図へ自然に接続する補助制御であり、完成セット本体を肥大化させるためのものではない。

基本：
- 完成セット選択だけで無言自動ONしない。
- 条件が揃ったら提案UIを出してよい。
- 提案は「入れますか？」ではなく「男主体 / 女主体 / 均衡ペア / 手動 / 今は閉じる」のように寄せ方を選ばせる。
- 今は閉じるは記憶しない。
- 提案条件は、1girl + 1boy、有効な完成セット、対応ペア補助が存在、未選択の4条件。
- 2girls / 2boys以上では提案しない。
- 再描画や履歴復元で連打しない。

構成：
- 💠 ペア補助本体
- ♂ 男側補強
- ♀ 女側補強
- 🤝 ペア構図・関係性

実装：
- 同じcollection内に置く。
- complete_seiryu / pair_seiryu / pair_male_seiryu のようにstemを揃える。
- script側に固有名ベタ書き例外を量産しない。
- 完成セット切替時は旧ペア補助の残骸を解除する。

## 7. R-18特化コレクション追加ルール
R-18では通常棚を増やすより、特化コレクション形式で整理する。完成セット / ベース / カスタマイズ / 設定の4層は必須。必要に応じてクオリティ棚を追加する。

重要：
- 最新安定版だけを使う。
- R-18見出し直下に特化コレクション本体を直接並べる。
- 「特化コレクションの中に特化コレクション」は禁止。
- 旧棚はいきなり消さない。新コレクション追加 → 表示確認 → 連動確認 → 差分移植 → 安定確認 → 旧棚整理の順。
- 1回で複数コレクションを追加しない。1本追加して確認してから次へ。
- 旧棚移植は、旧棚と新棚を実読し、未収録の差分だけを抽出する。旧棚を読まずに新語を発明しない。
- R-18表示条件を旧棚だけに依存させない。

確認項目：
- R-18カテゴリが表示される。
- 新特化コレクションが上段へ直接出る。
- 完成セットが排他で動く。
- 下位連動がリセット→再構築される。
- OFF時に下位連動も外れる。
- 旧棚整理後もR-18全体が消えない。

## 8. Raceセクションルール
Race > 身体パーツ・特徴 は、既存安定構造を壊さない。大改造禁止。

安定構造：
1. 🧬 種族パーツ：Marine / Dragon / Celestial-Abyssal / Vampire / Serpent / Beast / Insect など。
2. 🧠 頭部・顔パーツ：Head / Eye / Mouth / Ears / Horns など。
3. 🧍 身体・付属パーツ：Skin / Scales / Wings / Body / Animal / Fins / Tentacles / Tail など。

必ず維持：
- Celestial/Abyssal Traits Collection と Celestial / Demonic の子棚。
- Insect Traits Collection。
- Head & Face / Body & Attachments。

注意：
- CATEGORIESに追加しただけで出ない構造がある。表示配列へ追加する。
- 古い再編ロジックやsetTimeout競合を復活させない。
- 既存棚が空になる全置換をしない。

## 9. 折りたたみUI・見た目統一
- UI統一は共通CSSを1箇所へ集約し、section側はclass付与とinline style撤去を優先する。
- CSSが効かない時は、inline style優先、Shadow DOM、共通CSSの details[open] > div grid指定、キャッシュを疑う。
- Shadow DOM内のUIには document.head ではなく shadowRoot へCSS注入が必要なことがある。
- スマホでは1列表示を標準とする。`grid-template-columns: 1fr 1fr` や共通 `details[open] > div` の自動多列が残っていないか確認する。
- 案内文・カテゴリ・項目を同じgridの兄弟へ混ぜない。案内は全幅、カテゴリと項目は各一列にする。詳細は第21章に従う。
- デバッグ用outlineやマゼンタ枠を本番へ残さない。
- Unexpected token はIIFE外追記、閉じ忘れ、余計なカンマ、追記位置ミスを疑う。

## 10. シマエナガコレクション調整ルール
目標は「3秒で誰が見てもシマエナガ」。最低3要素を入れる。

明確シマ要素：
- 生体：本物のシマエナガを画面内に1羽以上。
- ぬい：シマエナガぬいを抱える、腰やバッグに付ける。
- 衣装：白頭フード、鳥顔ブローチ、羽襟、尾、丸ふわスカート、白×黒×淡グレー配色。

最低2段階、推奨は3段階全部。白頭、丸ふわ、鳥顔ブローチ、尾/羽の視認性を強める。世界観が勝つ場合は背景語を減らし、鳥要素を先頭に出す。

## 11. 納品・返答ルール
- まず簡単に診断する。
- 何を修正するか明確にする。
- 実装時はzipで返す。touch-only zipを基本に、必要なら全体zipも返す。
- node --check した場合は結果を書く。
- DOMテスト・最終データ監査・zip整合性確認をした場合は、実機確認と分けて結果を書く。
- 未確認・不確実な点は正直に書く。
- 返答は長くしすぎず、ユーザーがすぐテストできる形を優先する。

## 12. カテゴリ別案件メモの扱い
この統合ルールは全カテゴリー共通の土台。七つの大罪、特定衣装、特定背景、特定Race拡張などの濃い案件情報は、マイGPTの恒久知識ではなく、そのスレッド開始時の「案件メモ」として別途与える。恒久知識に特定案件を入れすぎると、他カテゴリー作業で思考が引っ張られる。

追加ルール：完成セット4系統の標準構成

特化コレクションやなりきり系コレクションを新設・増築する場合、可能な限り各テーマにつき以下の4系統を用意する。

完成セット / Core Set

そのテーマの基本形。

主題・人物像・最低限の外見特徴・主要演出をまとめる。

初回テストや標準利用の起点にする。

高画質セット / Safe Quality Set

完成セットの方向性を崩さず、画質・光・質感だけを安全に強化する版。

主題を増やしすぎず、描写密度・ライティング・質感・見栄えを補助する。

生成結果が崩れやすいテーマでは、否定語の過積載ではなく、肯定的な固定語と軽量な品質語で補強する。

2000字制限対応版 / 2000 Limit Compatible Set

2000字前後の制限がある生成AI向けに、完成セットの核を残して短縮した版。

重複語、効果の薄い比喩、長すぎる説明、過剰な否定語を削る。

ただし、主題の核、人物優先、重要な外見特徴、主要演出は必ず残す。

フルセット / Full Set

そのテーマの演出・設定・質感・構図補助を厚めに含めた全部乗せ版。

完成セット、ベース、カスタマイズ、設定、クオリティ補助をまとめて試したい時に使う。

ただし、長くなりすぎる場合は2000字制限対応版も必ず用意し、フルセットだけで運用しない。

標準の並び順

各テーマ内の完成セット欄では、原則として以下の順に並べる。

通常の完成セット / Core Set

高画質セット / Safe Quality Set

2000字制限対応版 / 2000 Limit Compatible Set

フルセット / Full Set

複数の派生系統がある場合は、系統ごとに4連でまとめる。

例：

王道 Core Set

王道 Safe Quality Set

王道 2000 Limit Compatible Set

王道 Full Set

まどろみ支配 Core Set

まどろみ支配 Safe Quality Set

まどろみ支配 2000 Limit Compatible Set

まどろみ支配 Full Set

魔王寄り Core Set

魔王寄り Safe Quality Set

魔王寄り 2000 Limit Compatible Set

魔王寄り Full Set

このように、フラットに種類別で並べるのではなく、系統単位で4連にすると、スマホ表示でも比較しやすく、テストもしやすい。

実装時の注意

4系統すべてに同じ語を丸ごとコピーしない。

Core Set は軽量な核。

Safe Quality Set は画質補助寄り。

2000 Limit Compatible Set は短縮・安定化寄り。

Full Set は全部乗せ寄り。

linked_ids は各セットの役割に合わせて調整する。

Full Set だけが極端に長くなりすぎた場合、効果の薄い比喩・重複・過剰否定を優先して整理する。

2000字制限対応版は、単なる短縮ではなく「そのテーマが最低限成立する最短の実戦版」として作る。

この4系統を作る目的

標準テスト用の Core Set

品質確認用の Safe Quality Set

制限モデル用の 2000 Limit Compatible Set

最大演出確認用の Full Set

この4つを揃えることで、ユーザーが生成モデルや文字数制限に合わせて使い分けられる。

ファイル反映メモ

この内容は、知識用統合ルールファイルにも追記して使う想定。

追加ルール：Prompt Compiler v2 出力順制御ルール

目的：
ユーザーがチェックした順番そのままではなく、生成に強い役割順で最終プロンプトを組み直す。
UI上の棚構造やチェック操作は維持し、最終出力時だけ Prompt Compiler v2 で並び替える。

基本方針：
- 主題が品質語に埋もれるのを防ぐ。
- ポーズが後半に沈むのを防ぐ。
- キャラ設計と表情・ポーズ・エフェクトを切り分ける。
- なりきり完成セット内の品質・演出混在による迷宮化を避ける。
- 既存データ棚は壊さず、最終出力側で整理する。
- アンカーは重要だが、アンカーだけで全部解決しない。
- 主題核はアンカーで固定し、出力順の問題は Prompt Compiler v2 側で解決する。

役割スロット：
1. person_anchor
   人物指定。
   例：1girl, 1boy, solo, faceless male, single human character focus

2. subject_anchor
   主題・なりきり・神獣・キャラ核。
   例：Dakki inspired, Belphegor motif, Seiryu incarnation, Fenrir traits

3. base
   ベース・人型維持・素体補助。

4. body_traits
   角、翼、尾、耳、鱗、牙、瞳、身体特徴。

5. attire
   衣装、ローブ、ドレス、装飾、鎧、宮廷服。

6. pose
   ポーズ、姿勢、動作。
   例：standing, idle pose, crouching, lying, raised hand

7. expression
   表情、視線、感情、口元、涙、汗、顔反応。

8. composition_camera
   構図、画角、カメラ。
   例：upper body, close-up, low angle

9. scene_background
   背景、場所、室内、宮殿、森、神殿など。

10. atmosphere_effect
   雰囲気、光、煙、霧、エフェクト、漫画記号、吹き出し、効果音。

11. quality
   画質、光、解像感、質感。
   例：masterpiece, best quality, cinematic lighting, global illumination

12. suppression
   抑制、外部獣抑制、人型維持補助。
   例：no separate beast, no companion creature

出力モード：

1. 通常
標準生成用。
主題・キャラ・衣装・ポーズ・表情・背景・品質の順で自然に並べる。

順序：
person_anchor
→ subject_anchor
→ base
→ body_traits
→ attire
→ pose
→ expression
→ composition_camera
→ scene_background
→ atmosphere_effect
→ quality
→ suppression
→ misc

用途：
通常の生成。最もバランスの良い基本モード。

2. ポーズ優先
ポーズを明確に出したい時の生成用。
ポーズが後半に沈む問題を避けるため、主題直後にポーズを寄せる。

順序：
person_anchor
→ subject_anchor
→ pose
→ base
→ body_traits
→ attire
→ expression
→ composition_camera
→ scene_background
→ atmosphere_effect
→ quality
→ suppression
→ misc

用途：
指定ポーズを強く出したい時。
例：座り、寝姿勢、戦闘姿勢、猫ポーズ、手の動きなど。

3. キャラ設計
キャラデザイン寄りの最終生成用。
表情・ポーズ・背景を完全には消さず、キャラ本体要素を前に寄せる。

順序：
person_anchor
→ subject_anchor
→ base
→ body_traits
→ attire
→ scene_background
→ atmosphere_effect
→ quality
→ suppression
→ pose
→ expression
→ composition_camera
→ misc

用途：
キャラの外見、衣装、種族特徴を重視した生成。
表情やポーズは残すが、主役ではなく後方に回す。

4. キャラ確認
正式名称：
キャラ設計のみ確認用

UI表示名：
キャラ確認

このモードは最終生成用ではなく、確認用ビュー。
チェック状態を変えずに、出力欄だけ一時的にキャラ本体確認用へ絞る。

目的：
ポーズ・表情・背景・エフェクトを毎回チェック解除せず、キャラ本体だけ確認する。

順序：
person_anchor
→ subject_anchor
→ base
→ body_traits
→ attire
→ suppression
→ quality
→ misc

キャラ確認では以下を一時除外する。
- pose
- expression
- scene_background
- atmosphere_effect
- composition_camera

さらに、misc に残りやすい表情・感情・吹き出し・効果音・汗涙・口元反応・漫画記号・精神状態・ベッド姿勢・支配/従属状態なども、必要に応じて広域フィルターで一時除外する。

重要：
キャラ確認モードの除外辞書は完璧を目指しすぎない。
漏れを見つけたらその都度追加する。
このモードに力を入れすぎて、本来の Prompt Compiler v2 改善を止めない。

用途：
キャラ本体の確認。
ポーズや表情やエフェクトを外す手間を省くための仮想フィルター。

5. 旧順
従来のチェック順に近い出力。
比較用・保険用として残す。

用途：
Prompt Compiler v2 の並び替えが意図と違う時の逃げ道。
旧挙動との比較。

linked_ids の扱い：
完成セットを選んだ時、linked_ids によって下位棚が連動する。
ただし、連動項目をそのまま近くに出すのではなく、各項目の役割で再配置する。

基本方針：
- complete_set 本体 → subject_anchor
- base → base
- customize → body_traits / attire / atmosphere_effect など内容に応じて分類
- setting → scene_background / atmosphere_effect / suppression など
- quality_set / quality_detail → quality
- pose → pose
- expression → expression

つまり、連動は維持するが、出力位置は役割順で整理する。

なりきり完成セットの扱い：
なりきり完成セットには、主題・衣装・演出・表情・品質が混ざっていることがある。
これをデータ側で無理に全部分解しようとすると迷宮化する。

基本方針：
- 完成セットは主題アンカーとして前に出す。
- 品質は quality 側へ寄せる。
- 表情は expression 側へ寄せる。
- ポーズは pose 側へ寄せる。
- 背景・演出は scene_background / atmosphere_effect 側へ寄せる。
- 完成セット本体の val を過剰に削らない。
- 主題・キャラ核・最低限の外見特徴は残す。

アンカーの使い方：
アンカーで固定してよいもの：
- 誰なのか
- 何のなりきりなのか
- 何の神獣なのか
- 人型維持
- 単体キャラ focus
- 主題成立に必須の身体特徴

アンカーで抱え込みすぎないもの：
- 表情
- ポーズ
- 背景
- エフェクト
- 品質語
- 演出全部

アンカーで全部解決しようとすると、完成セットが肥大化し、棚の役割が曖昧になり、迷宮化する。

競合警告とモード案内：
Prompt Compiler v2 では、警告と案内を分けて扱う。

赤系の警告を出す対象：
1. 人物指定の競合
   例：1boy / faceless male と femme fatale / empress / queen が混在

2. 主役級なりきりの複数選択
   例：Dakki inspired と Taikobo inspired が同時に出ている

3. キャラ確認モード中
   キャラ確認は表情・ポーズ・背景・演出を一時除外するため、通常生成と誤解されないよう赤系警告を出す。

赤系警告から外す対象：
- 「ポーズ語が後半にあります」
- 「キャラ設計に表情・ポーズ語が残っています」

理由：
キャラのみセットや背景語に posture / standing などが含まれる場合、ユーザーに「キャラのみなのにポーズが混ざっている？」という不要な疑問を与える。
また、キャラ設計は表情・ポーズを消すモードではなく、後方に回すモードなので、警告扱いにしない。

モード案内テロップ：
ポーズ優先やキャラ設計を選んだ時は、警告ではなく短い青系・情報系テロップで説明する。

表示例：
- ℹ ポーズ優先：ポーズ語を主題近くへ前寄せします
- ℹ キャラ設計：キャラ本体要素を前寄せします

警告は混線や危険な誤解を防ぐために使い、通常のモード説明には使わない。

キャラ確認モードの注意：
キャラ確認は便利だが、除外辞書の完成を目的にしない。

理由：
- 表情・演出語は無限に増える。
- 一語ずつ潰すと不毛になる。
- 本来の目的は Prompt Compiler v2 による出力順改善。
- キャラ確認は一時確認用の補助モードに過ぎない。

運用方針：
- 大きな漏れだけ追加する。
- 普段の生成で気になった語を見つけた時に修正する。
- すべての表情棚を完全除外することを目標にしない。
- 固定デザイン語まで消しすぎない。

残す寄りの例：
- fangs
- shark teeth
- heterochromia
- slit pupils
- no pupils
- freckles
- lipstick
- bandage on face
- tsurime
- tareme
- jitome
- sanpaku

除外寄りの例：
- smile
- smirk
- blush
- tears
- sweat
- speech bubble
- sound effect text
- motion lines
- shock lines
- panting
- drooling
- trembling
- panic
- embarrassed
- pleading
- trance
- mind break
- lying on bed
- head on pillow
- seductive gaze
- emotional breakdown

実装方針：
主に触るファイル：
- builder_core.v1.js

基本的にはデータ側ではなく、最終出力組み立て側で処理する。
builder_data.preset_packs.js は、キャラのみセットの誤連動や linked_ids 汚染など、データ自体が壊れている場合のみ修正する。

実装時の注意：
- 既存棚構造を壊さない。
- データの val を大規模分解しない。
- 旧順モードを残す。
- AndroidでUIがはみ出さないよう、表示名は短くする。
- 「キャラ設計のみ確認用」はUI上では「キャラ確認」と短縮する。
- 警告文では「一時除外」と明記する。

現在の結論：
Prompt Compiler v2 の本命は、キャラ確認モードではない。

本命は：
- 通常
- ポーズ優先
- キャラ設計

この3つの出力順改善。

キャラ確認は、チェック解除の手間を省くための確認用モード。
今後は、漏れを見つけた時だけ軽く修正する。


## Prompt Compiler v2 安全UI追記：初期通常固定とモード案内

Prompt Compiler v2 の初期モードは必ず「通常」にする。
キャラ確認モードをデフォルトにしてはいけない。
localStorage に過去の選択が残っていても、リロード後や初回表示時は「通常」から始める。

理由：
初心者が以前のモード状態を知らずに開いた場合、キャラ確認のまま生成して表情・ポーズ・背景・演出が出ないと誤解する事故を防ぐため。
また、キャラ設計やポーズ優先も通常とは出力順が違うため、初期値にはしない。

キャラ確認モード：
キャラ確認は確認用の一時除外モードであり、通常生成用ではない。
表情・ポーズ・背景・演出を出力欄から一時除外する。
そのため、ユーザーが表情やポーズをチェックしているのに出力されないように見えることがある。
これは仕様だが、初心者には不具合に見えやすい。

実装方針：
- localStorage に character_pure / キャラ確認を初期値として残さない。
- リロード後や初回表示時は必ず「通常」から始める。
- キャラ確認を選択した時だけ、現在セッション内で一時的に有効にする。
- キャラ確認選択時は赤系の警告を必ず表示する。
- 警告文には「一時除外」を明記する。
- 可能なら「通常へ戻す」ボタンを表示する。

キャラ確認の警告表示例：
⚠ キャラ確認：表情・ポーズ・背景・演出を一時除外中

戻すボタン例：
通常へ戻す

ポーズ優先 / キャラ設計の案内：
ポーズ優先とキャラ設計は危険な除外モードではないため、赤警告ではなく短い情報テロップで説明する。
「ポーズ語が後半にあります」のような警告は出さない。
posture / standing などを含むキャラのみセットで不要な疑問を生むため、ポーズ位置警告は原則出さない。

案内表示例：
ℹ ポーズ優先：ポーズ語を主題近くへ前寄せします
ℹ キャラ設計：キャラ本体要素を前寄せします

UI表示名：
- セレクト内はスマホ幅を考慮して「キャラ確認」と短くする。
- 説明文や警告文では「確認用」「一時除外」と明記する。
- ポーズ優先 / キャラ設計は警告ではなく案内として扱う。

目的：
キャラ確認はチェック解除の手間を省くための仮想フィルターであり、通常生成モードではない。
初心者が誤ってキャラ確認のまま生成し、表情やポーズが出ないと誤解する事故を防ぐ。
一方で、ポーズ優先やキャラ設計は通常生成の派生モードなので、過剰な警告で不安を煽らない。
## Prompt Compiler v2 履歴復元ルール：静音トランザクション化

履歴復元は、チェックボックスを1件ずつ復元しながら大量の change イベントを発火させてはいけない。
大量発火すると、linked_ids 連動、完成セット切替、autosave、Prompt Compiler v2、UI同期、履歴復元ガードが同時に走り、以下のような不具合が起きることがある。

- 履歴復元後に、通常 / ポーズ優先 / キャラ設計 / キャラ確認 / 旧順 の切り替えが効かなくなる
- 出力順セレクトが通常に戻される、または選択が固まったように見える
- 完成セットの親チェックが復元されず、子棚だけが復元される
- Android環境で履歴復元が重くなる
- 復元中の予約処理が後から走り、UI状態を上書きする

履歴復元は、以下のように「静音トランザクション」として扱う。

推奨手順：

1. `window.__historyRestoring = true` などの復元中フラグを立てる。
2. チェック状態を静かに全解除する。
3. 履歴データに基づいて、対象チェックだけを静かにONへ戻す。
4. 復元中は checkbox ごとに `change` イベントを大量発火しない。
5. すべてのチェック状態を復元した後、最後に1回だけ出力生成を行う。
6. 必要なら `builderHistoryRestored` のような復元完了イベントを1回だけ発火する。
7. `finally` などで必ず復元中フラグを解除する。

重要：
履歴復元中に change を大量発火させる設計へ戻してはいけない。
履歴復元は「チェック状態を静かに復元 → 最後に1回だけ生成」が基本。

Prompt Compiler v2 との関係：

- 履歴復元時に Prompt Compiler v2 の現在モードを勝手に変更しない。
- 初期表示は通常でよいが、現在セッション内で選ばれているモードは履歴復元で潰さない。
- 復元後も、通常 / ポーズ優先 / キャラ設計 / キャラ確認 / 旧順 を切り替えられる状態を維持する。
- 履歴復元後の出力は、固定保存テキストだけに頼らず、復元済みチェック状態から再生成できるようにする。

履歴復元で親棚・完成セットが復元されない問題への注意：

以前の挙動では、履歴で完成セットの子棚だけが復元され、親の完成セットチェックが復元されないことがあった。
静音トランザクション化により、保存されたチェック状態を落ち着いて復元できるため、親棚チェックも復元されやすくなった。
今後、履歴仕様を改修する場合は、完成セット親チェックと linked_ids 由来の子棚チェックの両方が復元されるか確認する。

確認項目：

- 履歴復元後に、出力順セレクトを通常 / ポーズ優先 / キャラ設計 / キャラ確認 / 旧順へ切り替えられる。
- 履歴復元が重くならない。
- 完成セット親チェックが復元される。
- linked_ids 由来の子棚チェックも復元される。
- 復元後に生成ボタンを押しても、古い固定テキストではなく現在のチェック状態に基づいて出力される。
- `window.__historyRestoring` などの復元中フラグが残りっぱなしにならない。

将来の追加検討：

静音トランザクション化でも履歴復元が不安定な場合は、次段階として「全チェック項目へ一意のID番号を付与し、履歴はID番号のみで復元する方式」を検討する。
ただし、現状は静音トランザクション化で大きく改善しているため、ID全面管理への移行はすぐには行わない。
実装コストが高いため、必要性が明確になってから検討する。

## Creatures → Pose 動物ポーズ誘導ルール：Yes/Noショートカット方式

目的：
生物・動物カテゴリーで選んだ動物種と、Pose内の「動物ポーズ特化 v18 / 動物ポーズ特化コレクション」を整合させる。
動物種は Creatures 側で決め、ポーズ・姿勢・人物との関係性は Pose 側で決める。
これにより、シマリスを選んだのに完成ポーズがハムスター固定になる、人物と動物が融合する、動物ポーズが人物側へ吸われる、という事故を減らす。

基本方針：
- Creatures = 動物種・存在・同行・群れ・視線を決める場所。
- Pose = その動物に合う動き・姿勢・人物との配置を決める場所。
- 主体分離アンカー = 人物と動物を別個体として固定する補助。
- 動物選択だけでPose項目を自動チェックしない。
- 動物選択時は、対応ポーズへ移動するかをユーザーに確認する。
- 勝手にPose棚を開かない。勝手にチェックを増やさない。

推奨UI：
動物チェック時に、画面下部の固定カードで案内を出す。

表示例：
🐾 シマリスに合うポーズ候補があります。
Pose欄の「🐹 小型齧歯類・小動物」へショートカットしますか？チェックは自動ONにしません。
[いいえ] [はい：ポーズへ移動]

重要：
- 案内カードは、Creaturesセクション上部固定にしない。下の棚で選んだ時に見えなくなる。
- チェック項目直下のインライン表示も、固定フッターや生成欄に隠れることがあるため注意する。
- Android実機では、画面下部の固定カードがもっとも見つけやすい。
- ただし生成ボタンや出力欄を完全に塞がないよう、max-width、左右余白、z-index、下端位置を調整する。
- 案内カードは1つだけ表示し、別の動物を選んだら内容を差し替える。
- 「いいえ」は何もせず閉じる。
- 「はい」はPoseへ移動し、対応棚を開き、候補をハイライトする。チェックは自動ONにしない。
- 「はい」押下後に何も起きずカードだけ消える挙動は不可。移動中表示やfallbackを用意する。

実装の役割分担：
- `builder_ui.section.creatures.bundle.js`
  - 選択された動物のval / labelから分類を判定する。
  - 対応するPose棚、案内文、ハイライト対象を決める。
  - Yes/No案内カードを表示する。
  - Yes時にPose側のショートカット関数を呼ぶ。関数が未準備ならカスタムイベントを投げ、最低限Poseセクションへスクロールするfallbackを用意する。
- `builder_ui.section.pose.bundle.js`
  - 「動物ポーズ特化 v18」の実在を確認する。
  - Creatures側からのショートカット要求を受ける受け口を公開する。
  - Poseセクション、v18親棚、対応子棚を開く。
  - 対応候補を短時間ハイライトする。
  - v18が未描画ならpendingとして保持し、描画後に再処理する。
- `builder_core.v1.js`
  - 原則触らない。最終出力順や履歴復元などcore側でしか直せない場合のみ最小修正する。

分類は全動物1対1で作らない：
全動物ごとに専用完成ポーズを作ると破綻する。
基本は「動物ファミリー」へ分類し、Pose側はファミリー別の汎用ポーズ棚へ誘導する。

例：
- シマエナガ、スズメ、ツバメ、フクロウ、猛禽類 → 🐦 鳥・翼の動き
- ハムスター、シマリス、リス、デグー、チンチラ、モルモットなど → 🐹 小型齧歯類・小動物
- 猫、ライオン、トラ、ヒョウなど → 🐱 猫・ネコ科
- 犬、狼、狐、タヌキなど → 🐶 犬・狼・狐
- うさぎ、フェレット、ミンクなど → 🐰 うさぎ・小型哺乳類
- フクロモモンガ、gliding系、有袋類、珍獣系 → 🦘 有袋類・珍獣
- ガラゴ、アイアイ、メガネザル、マーモセット、タマリン、サル、ギボン、チンパンジー、ゴリラ、オランウータンなど → 🐒 霊長類・樹上動物
- 魚、イルカ、クジラ、クラゲなど → 水生動物・水中構図系
- 牡蠣、二枚貝、イソギンチャク、サンゴ、カツオノエボシ、管クラゲなど → 🪸 海洋無脊椎・浮遊生物
- 昆虫、蝶、蜂、甲虫など → 昆虫・翅の動き系
- ドラゴン、フェニックス、ユニコーンなど → 幻獣・大型生物系

海洋無脊椎の注意：
貝類・サンゴ・イソギンチャク・管クラゲは「ペットとして手に乗せる」より、形状・群体・水中構図・浮遊感の補助に回す。
人物＋動物の分離ポーズへ無理に寄せない。
「殻を見せる」「触手を広げる」「群体として広がる」「水中に漂う」などの構図補助として扱う。

Pose v18 側の棚設計：
動物ポーズ特化は、必ず以下を分ける。

1. 動物単体ポーズ
   - single animal subject
   - real animal
   - その動物だけの姿勢・動作を描く
2. 人物＋動物 分離ポーズ
   - human character and pet animal
   - separate characters
   - separate subjects
   - distinct bodies
   - different species
   - real pet animal
   - clear size difference
   - small pet animal in human hands
   - non-hybrid
   - separate anatomy
3. 動物モチーフ・なりきり寄り
   - hamster-inspired girl
   - animal-themed pose
   - kemonomimi style
   - これは融合・擬人化・なりきりとして別棚に分離する

禁止：
- 動物単体ポーズと人物＋動物分離ポーズを混ぜない。
- 動物モチーフ・なりきりを分離ポーズに混ぜない。
- hamster holding seed / tiny paws holding seed などを人物側へ吸われる形で完成セットに入れない。
- シマリスを選んだ時にハムスター固定完成セットへ誘導しない。
- 動物選択だけでPose完成セットを自動チェックしない。
- ユーザー確認なしでPose棚を勝手に開かない。
- 案内カードをセクション上部だけに出して、現在位置から見失わせない。
- parent.innerHTML = "" で広範囲を消さない。

完成セット名：
曖昧名は禁止。
NG：
- 猫らしさ一式
- 小型齧歯類ポーズ一式

OK：
- 人物＋選択中の小型齧歯類：手の上＋餌持ち＋別個体
- 人物＋シマリス：手の上＋木の実＋別個体
- 猫単体：香箱座り＋片前足上げ＋毛づくろい
- 犬単体：おすわり＋お手＋遊びの伏せ
- 人物＋猫：膝の上の猫＋撫でる手＋別個体
- 人物＋小鳥：肩に止まる鳥＋別個体

「選択中の動物」型の設計：
動物種そのものはCreatures側の出力に任せる。
Pose側は「選択中の小型齧歯類」「選択中の猫科」「選択中の鳥」のような汎用ポーズを提供する。
これにより、シマリス・ハムスター・リスなどの種差をCreatures側で維持しつつ、Pose側では共通する動作を選べる。

例：
Creatures側：
chipmunk, striped squirrel

Pose側：
human character and selected real pet animal
separate characters
distinct bodies
different species
small real pet animal in human hands
the selected small rodent holding food with tiny paws

主体分離アンカー：
人物＋動物の場合は、Pose側で以下を必要に応じてlinked_ids連動させる。
ただし否定語だけを過剰に増やさず、肯定的な分離指定を優先する。

- human character and pet animal
- separate characters
- separate subjects
- distinct bodies
- different species
- pet animal
- real pet animal
- selected real pet animal
- clear size difference
- small pet animal in human hands
- non-hybrid
- separate anatomy
- pet animal as a separate animal

完成セット連動：
完成セットを選んだ時は、linked_ids で以下を連動させる。
- 主体分離アンカー
- その動物ファミリーに合う具体ポーズ
- 配置・構図補助
- 必要なら軽い品質補助

ただし、Creaturesからのショートカット案内では完成セットを自動ONにしない。
ショートカットは「移動とハイライト」まで。
チェックするかどうかはユーザー操作に任せる。

UI・イベント実装注意：
- `change` イベントの大量発火や履歴復元中の誘導表示を避ける。
- `window.__historyRestoring` など復元中フラグがある場合は案内を出さない。
- reset中、履歴復元中、初期描画中、自動同期中は案内を出さない。
- ユーザーが実際に動物チェックをONにした時だけ案内する。
- チェックOFFでは案内しない。
- 案内カードは既存があれば再利用・差し替えし、複数枚出さない。
- Yes押下時は `window.__shimaOpenAnimalPoseShortcut` のようなPose側受け口を直接呼べるなら呼び、同時にCustomEvent fallbackも用意する。
- Pose側が未描画ならpendingに積み、描画後に開く。
- `scrollIntoView` はAndroidの固定フッターに隠れないよう、必要なら余白やblock指定を調整する。
- 候補ハイライトは一時的なoutline / background程度にし、デバッグ用の派手な枠を残さない。

表示位置の教訓：
- Creatures上部固定：下の棚で選んだ時に見失うため不向き。
- チェック項目直下：自然だが、固定生成欄・フッター・狭いスマホ画面で隠れる場合がある。
- 画面下部固定カード：Android実機で見つけやすい。今回の標準方式とする。
- ただしカードが出力欄やボタンを塞ぐため、閉じるボタン・いいえボタンを明確にし、Yes/Noの横幅をスマホ向けに調整する。

確認項目：
- シマエナガ、スズメ、フクロウで鳥・翼の動きへ誘導される。
- シマリス、ハムスター、リスで小型齧歯類・小動物へ誘導される。
- 猫で猫・ネコ科へ誘導される。
- 犬・狼・狐で犬・狼・狐へ誘導される。
- フクロモモンガで有袋類・珍獣へ誘導される。
- ガラゴ、アイアイ、メガネザル、サル、ギボン、類人猿で霊長類・樹上動物へ誘導される。
- 牡蠣、二枚貝、イソギンチャク、サンゴ、カツオノエボシで海洋無脊椎・浮遊生物へ誘導される。
- Yesを押すと案内が消えるだけでなく、Poseへ移動する。
- Noを押すと何も変えずに閉じる。
- ショートカットではチェックが自動ONにならない。
- Pose v18、対応子棚、候補ハイライトが開く。
- Android実機で案内カードが見える。
- `node --check builder_ui.section.creatures.bundle.js` と `node --check builder_ui.section.pose.bundle.js` が通る。

## 13. Positive / Negative 出力チャンネル分離ルール

### 13.1 四つの意味を混同しない

プロンプト語は、見た目が否定的かどうかではなく「どの出力欄へ、何の意図で出すか」で分類する。

| 区分 | 出力先 | 用途 | 例 |
|---|---|---|---|
| POS通常 | Positive | 描きたい主題・品質・演出 | masterpiece, cinematic lighting |
| POS抑制 | Positive | 不在・抑制・構成固定を肯定側から指示 | no humans, empty scene, textless |
| POS表現 | Positive | 意図的な劣化・年代感・画材感を描かせる | low quality, jpeg artifacts, pixelated |
| NEG専用 | Negative | 生成ツールのNegative専用欄で避ける | bad anatomy, watermark, extra fingers |

必須表示：
- POS側に「抑制・不在指定」の専用棚を作る。
- POS側に「意図的劣化・実験表現」の専用棚を作る。
- NEG棚には「Negative専用（Positive側には出力されません）」と明記する。
- 選択中トレイ・セット試着・診断でも、POS通常 / POS抑制 / POS表現 / NEG専用を見分けられるようにする。

重要：
- `low quality`、`worst quality`、`jpeg artifacts` などは、ドット絵・旧作アニメ・VHS・圧縮画像表現ではPOSの主役になり得る。語の字面だけでPOSから削除・NEGへ移動しない。
- `no human` なども、利用先によってはPositive欄へ入れる正しい抑制語である。POS抑制として維持する。
- 同じ語をPOSとNEGの両方で選べること自体は仕様。競合の可能性を警告してよいが、勝手に片方を解除・削除しない。
- 出力先が分かれた生成ツールでは、PositiveとNegativeを別々にコピーできるようにする。単一欄へ渡す場合も、元のチャンネル情報を失わせない。
- Negative出力は、NEG専用セットと必要なスタイルガードを統合して生成する。POS側の選択をNEGへ自動移送しない。

### 13.2 データ保持

- 各入力は `data-output-channel` または同等の `outputChannel` を持つ。
- POS内の意味差が必要な項目は `intent` などで normal / suppress / expression を保持する。
- 分解項目、履歴、マイプリセット、選択中トレイまで同じ情報を引き継ぐ。
- 既存データにチャンネル指定がない場合は、棚の既定値から補完する。文言だけで推測しない。
- 語の移動・棚の再編後も、安定IDと出力先を変えない。

### 13.3 NEG基本セットの語彙ルール

- `lowers` のような誤記を残さず、意図が解像度なら `lowres` にする。
- `bokeh` は表現として必要な場合があるため、基本破綻防止へ無条件に入れない。必要なら「ピント・鮮明さ」など用途別NEGセットに分ける。
- 基本画質、人体、文字・ロゴ、用途別スタイル抑制を分け、何を消すセットか説明する。
- NEG語を盛るだけで改善したと判断せず、POS側の描写指定・構成固定との釣り合いを見る。

## 14. おまかせ品質・品質語整理ルール

### 14.1 現行のおまかせ品質構造

品質を細かく選ぶ棚は維持しつつ、サクッと決める入口として「おまかせ品質」を置く。現行標準は2グループ・8系統・3段階とする。

高品質仕上げ系：
- リアルアニメ
- CGアニメ
- アニメ塗り
- フォト

表現特化系：
- ピクセル
- ローポリゴン
- 旧作アニメ
- アナログ

各系統の段階：
- 標準：核となる10語前後。
- 高水準：描写・光・素材・解像感を加えた20語前後。
- 特化盛り：高水準を土台に、その系統専用語を6語前後足した26語前後。

これはレシピ設計の基準であり、UIの件数表示を固定文字列にする指示ではない。実表示件数は最終実行時データから数える。

### 14.2 系統ごとの語彙整合

- リアルアニメ高水準では、肌・髪・目・光・素材分離・高精細をまとめてよい。ただし同義語の過積載を診断する。
- アニメ塗り・旧作アニメ・ピクセル・アナログなど画材性が主役の系統へ、PBR、ray-traced reflections、photo-realistic renderingを機械的に混ぜない。
- ピクセル、旧作アニメ、VHS、圧縮表現で必要な低解像・劣化語はPOS表現として残す。
- ローポリゴンでは面構成・頂点感・簡潔な材質を優先し、超微細皮膚語で方向性を壊さない。
- フォト系でも人物や用途に不要な反射語を盛りすぎない。
- 品質を上げる語と画風を決める語を分け、テーマを食う語は間引く。

### 14.3 品質NEG支援

- 8系統それぞれに、用途に合うNEG候補を用意する。目安は各6語程度だが、同義語の水増しをしない。
- 品質セット適用前にPositive追加分とNegative追加分を別々に試着表示する。
- 既に選ばれたNegativeを品質セット適用で消さない。
- 品質レシピ保存は、品質項目・Negative項目・各出力チャンネルを対象とし、無関係な人物・背景選択を巻き込まない。
- 完成セット / 品質セットは「追加」ではなく由来項目をリセットして再構築する起点。下位項目を手動変更したら親セット選択を解除する。
- おまかせ品質の親棚・各系統棚は初期状態で閉じる。

## 15. セット試着・カード操作分離ルール

複数語セットを適用する前に「PACK FITTING / 適用前確認」を表示し、適用後を理解してから選べるようにする。

試着画面の必須情報：
- セットに含まれる全ワード。
- 新しく追加されるワード。
- 解除・置換されるワード。
- 同じ出力先での重複。
- POS / NEG間の同語警告。
- 適用後のPositiveプレビュー。
- 維持されるNegativeを含むNegativeプレビュー。
- 適用先がPOSかNEG専用かを示す明確なバッジ。

操作原則：
- チェックボックスを直接タップした時は、その場でON/OFFする。
- カード本文・タイトルをタップした時だけ試着詳細を開く。
- チェック操作を親カードのクリック処理が奪い、詳細へ遷移させてはいけない。
- `target.closest('input, label, button, a')` などで直接操作を判定し、必要な場所だけ伝播を止める。
- 試着を開いただけではチェック状態を変更しない。
- 「セットを適用」「分解して調整」「やめる」の明示操作で初めて状態を変える。
- 「セットを解除」は既に選択中のセットにだけ出す。未選択セットへ誤った解除表示を出さない。

分解項目：
- 安定したinput ID、元pack ID、outputChannel、intentを保持する。
- 未分解時の内部候補は通常検索・選択中表示から除外するが、履歴・マイプリセット復元ではID解決できるようにする。
- 分解後は通常項目として選択・解除・保存できる。

## 16. 「出力先で探す」検索と大量DOM高速化ルール

対象が2万件を超える環境では、All / POS / NEG切替のたびに全ラベルを再検索するとAndroidでフリーズする。チャンネル絞り込みと文字検索を別処理として設計する。

### 16.1 空検索時

- 検索語が空なら、All / POS / NEGの切替で全文検索を再実行しない。
- 描画時または初回走査で作ったチャンネル索引・class・data属性を使って表示を切り替える。
- POSはPOS項目までの祖先だけ、NEGはNEG項目までの祖先だけを表示する。
- 対象項目がない大型棚の枠だけを残し、巨大な空白を作らない。
- 件数表示は最終実行時の索引から計算する。

### 16.2 文字検索時

- 全ラベル走査は1回にまとめ、その結果から一致input、一致Details、一致Sectionの集合を作る。
- 棚ごとに子孫を再走査する二重・三重ループを避ける。
- チャンネル切替時は、現在の文字検索結果に対してPOS / NEGを絞る。
- native searchや再描画を予約する場合は、古いtimerを必ず取り消し、最後の操作だけを反映する。
- 連打・高速切替で古い処理が後からDOMを上書きしない。

### 16.3 移動・再構築との連携

- 検索結果から項目へ移動する時は、文字検索・選択中のみ・お気に入りのみ・チャンネルフィルターを必要に応じて解除する。
- 対象の全祖先棚を開き、固定ヘッダーに隠れない位置へスクロールし、一時ハイライトする。
- DOMへinputを追加・移動・分解した後は、`ShimaChannelSearch.invalidate()` または同等処理で索引を無効化する。
- mountのたびに全検索を無条件実行しない。

回帰確認：
- 空検索でPOS→NEG→Allを素早く連打しても固まらない。
- POSを押すとPOSだけ、NEGを押すとNEGだけが見える。
- 空の棚・大きな余白・三角だけ残る表示が出ない。
- 文字検索中にチャンネルを切り替えても最後の選択が勝つ。

## 17. リセット・選択中ビュー・固定ナビ回帰ルール

### 17.1 リセット

- リセットは履歴復元と同じく、一括トランザクションとして扱う。
- reset中フラグを立て、予約済み検索・同期timerを止め、チェックを静かに解除する。
- 各inputへ大量のchangeを連打せず、最後に出力・件数・トレイ・検索索引を1回ずつ同期する。
- `finally` でreset中フラグを必ず解除する。
- 初回タップで実行され、2回目でもフリーズしないことを回帰テストする。

### 17.2 選択中ビュー

- 「選択中」は、選択項目を一覧表示する正式機能。空白画面へ切り替えるだけの状態は不具合。
- 選択中トレイの項目名タップで、棚ビューへ戻し、干渉フィルターを解除し、対象の祖先棚を開いて移動する。
- view切替後の描画完了を待って移動し、非表示DOMへ先にscrollしない。
- 選択0件では空白だけにせず、何も選ばれていないことと棚へ戻る導線を表示する。
- 固定下部ナビは棚 / 選択中 / 出力の状態と件数を同期する。

## 18. マイプリセット・履歴・安定IDルール

### 18.1 ユーザー用保存先の一本化

- ユーザーが画面から保存・復元する入口は、ZERO ASSIST「選択をすぐ見つける」の「マイプリセット」に一本化する。
- ソースファイルを書き換えないと使えない「24. 保存済みプリセット」や、カスタムセットA/B・実験用メモなどの見本棚をユーザー機能として残さない。
- 旧24番棚を消しても、実データの入力IDや内部互換キーを不用意に削除しない。
- スタートデッキの「保存プリセット」導線も、同じマイプリセット画面を開く。

### 18.2 保存内容

- マイプリセットは安定input ID、値、outputChannel、必要なintentを保存する。
- 表示ラベルや棚番号だけで復元しない。棚移動・名称変更で壊れるため。
- 品質レシピ保存と全体マイプリセット保存を混同しない。
- 「うちの子」ルートでは登録設定を軸にし、無関係な背景・シーン選択をうちの子情報として数えない。
- メカ・ロボット等の別ルートも、無関係な選択だけで自動判定しない。

### 18.3 履歴互換

- 棚を移動しても安定IDを維持し、旧履歴をIDで復元する。
- 旧履歴の `sectionId` が古い棚を指す場合、安定input IDで実DOMを探すfallbackを持つ。
- 履歴復元は「Prompt Compiler v2 履歴復元ルール」の静音トランザクションを守る。
- 復元後は出力先・親セット・分解項目・選択中トレイを1回だけ同期する。

## 19. 背景棚・クイックシーン・プリセットパック統合ルール

### 19.1 役割分担

- 「18. 背景・場所」は、場所・時間・天候・光・空気を細かく組む部品棚として残す。
- 「クイック・シーンセット」は、場所・時間・光・空気を一押しでまとめる軽量セットとして扱う。
- 人物・衣装・構図まで含む大きな完成セットは、なりきり等の通常プリセットパックへ分ける。
- 背景部品とクイックセットは目的が違うため、内容が一部重なっても機能重複とはみなさない。説明で使い分けを明確にする。

### 19.2 配置

- クイック・シーンセットは独立した「24. シチュエーション棚」にせず、「プリセットパック」の先頭へ置く。
- 旧24番の外側UIは削除する。互換に必要な内部キー・安定IDは維持してよい。
- 背景18の上部に「細かく組む棚」と「まとめて決めるセット」の違いを短く説明し、クイック・シーンへ移動する導線を置く。
- 導線は移動とハイライトまで。勝手にチェックしない。
- クイックセット本体、朝 / 昼 / 夕方 / 夜 / 具体的な場所などの子棚は初期状態で閉じる。

### 19.3 データ互換

- 既存の `shima-situation-*` など安定ID、`data-val`、`data-ja`、POS出力先を維持する。
- 旧履歴やマイプリセットが `list-presets` 等の旧sectionIdを持っていても、安定IDで新位置へ復元する。
- `promptPartMounted` など実描画完了後に自分を正しい位置へmountする。
- mountが複数回起きても、二重構築・再選択・イベント多重登録を起こさない。
- 移動後の空の旧コンテナは削除し、余白を残さない。

### 19.4 配列・スマホ表示

- 案内文、カテゴリ、項目を同じ二列gridへ混ぜない。
- スマホではカテゴリも項目も基本一列。日本語が一文字ずつ縦に折り返される二列配置は禁止。
- 案内ブロックは横幅100%の独立行、その下に一列のカテゴリ、その中に一列の項目とする。
- PCで列数を増やす場合も、十分な最小幅と実機確認を条件にする。

## 20. 実行時データ・manifest・件数監査ルール

ソースファイルにデータがあることと、最終実行時データに残ることは別である。後から読まれるファイルが `window.__QP_DB = {}` のように全体を初期化すると、それ以前の追加は消える。

必須確認：
1. manifest / loaderの実読込順。
2. 各ファイルが既存オブジェクトへ追記するか、全体を再代入するか。
3. 全ファイル読込後の最終 `window.__QP_DB` 等の実体。
4. mount後の実DOM位置・件数・安定ID。
5. UIに表示される件数と、最終データから数えた件数の一致。

禁止：
- 早い段階のソースにある件数を、現行の正解としてハードコードする。
- ファイル名のversion番号だけで後勝ちを判断する。
- bundle内のappend順だけを見て最終DOM順を保証したとする。

現行クイック・シーンは、最終実行時データで5カテゴリ・33項目になった時点がある。以前の58項目は後続データに上書きされた旧状態だった。この数値は調査履歴であり、将来のUI固定値ではない。必ず現在の最終runtime DBから再計算する。

DOM項目を追加・移動・分解した時は、検索索引、件数、選択中トレイ、履歴解決表を無効化・再同期する。ソース検査に加えて、manifest全読込を模したデータ監査テストを持つ。

## 21. スマホ一列・雪原テーマ・可読性ルール

### 21.1 スマホ一列を既定にする

共通CSSの次のような規則は、モジュール内部の案内・カテゴリ・項目まで同じgrid子として扱い、狭い端末で日本語を縦折りさせることがある。

```css
.section-content details[open] > div {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(140px, 1fr));
}
```

対策：
- 子モジュールは専用classでスコープした規則を持ち、必要な場合だけ `!important` で共通規則を上書きする。
- スマホでは `grid-template-columns: minmax(0, 1fr)` を基準にする。
- 案内・説明は `grid-column: 1 / -1`、`width: 100%` の独立行にする。
- wrapper、details、カードへ `min-width: 0`、`max-width: 100%`、`box-sizing: border-box` を適用する。
- 日本語ラベルは通常の横書きを維持し、必要なら `overflow-wrap: anywhere` を使う。狭すぎる列を作って一文字ずつ折り返さない。
- PC向け多列はmedia query内だけで有効にする。
- CSSソースを見るだけでなく、実際の共通CSSを同時に読み込んだDOMで検証する。

### 21.2 シマエナガ雪原テーマ

- 背景は白いシマエナガと雪原を思わせる、白〜淡い水色を基調にする。
- 本文は濃い青緑・濃紺を基本にし、背景と同化させない。
- 選択中・展開中カードも本文コントラストを落とさない。濃色文字を半透明の濃色面へ載せない。
- チェック、説明、タグ、POS/NEGバッジ、件数を実機の明るさで読めるか確認する。
- 装飾の雪線・粒・ガラス感は操作領域と文字を邪魔しない濃度にする。
- 固定フッターは雪原本文と区別できる濃色でもよいが、ボタン文字とのコントラストを保つ。

### 21.3 初見で止まらない構造

- 開いた瞬間に「何を選び、どこから始めるか」が分かる入口を置く。
- SHIMA START DECK / 制作航路 / ZERO ASSISTは案内役であり、勝手に大量のタグを追加しない。
- 初期状態は主要棚を閉じ、入口・検索・現在位置を先に見せる。
- 高機能を一画面へ常時展開せず、棚→選択中→出力の固定ナビで現在の作業を見失わせない。

## 22. テスト・確認・納品ルール

ユーザーの実機確認と自動テストは別物であり、どちらか一方をもう一方の代わりにしない。

- 実機確認：本物のAndroid、実ブラウザ、タップ感、固定バー、スクロール、体感速度を確認する。
- 自動テスト：同じ不具合が次の修正で戻らないよう、操作列と期待状態を固定する。

変更に応じた最低確認：
- 変更した全JSへ `node --check`。
- 実際のイベント順を模したDOMテスト。
- manifest全読込後のデータ件数・ID・出力先監査。
- zip納品時は `unzip -t` などで整合性確認。
- touch-only zipの相対パスが元zipへ正しく上書きできることを確認。

重要な操作列：
- セットカードのチェックを直接タップ → 詳細を開かず選択できる。
- カード本文タップ → 試着を開くが、確定前は状態を変えない。
- POS→NEG→Allを高速連打 → 最後の選択が反映されフリーズしない。
- リセットを初回タップ → 即時解除。続けて再タップ → フリーズしない。
- 選択中→項目タップ → 棚へ戻り、対象が見える。
- マイプリセット保存→棚移動後に復元 → IDとチャンネルが維持される。
- 旧履歴復元 → 旧sectionIdでも安定IDから復元できる。
- 初回表示 → 指定棚が閉じ、スマホ一列で文字が横書き表示される。
- 共通の二列grid CSSをわざと共存させても、対象モジュールが一列を維持する。

大量データのDOMテストは最小stubで構造・イベントを速く確認してよい。ただし、それとは別に実manifestと実データを使った最終件数・後勝ち監査を行う。

報告時は「構文確認済み」「DOMテスト済み」「実データ監査済み」「Android実機はユーザー確認待ち」のように分ける。未実施を「問題なし」と書かない。

## 23. 現行回帰チェックリスト（このスレッドで確定）

- [ ] 雪原の白背景と濃い文字で、閉じた棚・開いた棚・選択カードの全文が読める。
- [ ] クイック・シーン、品質セットなど大きな棚は初期状態で閉じている。
- [ ] スマホでは案内・カテゴリ・項目が一列で、日本語が縦に崩れない。
- [ ] POS通常 / POS抑制 / POS表現 / NEG専用が表示と出力の両方で区別される。
- [ ] POSの `low quality` 等を意図的表現として選べ、NEG側の同語選択も自動解除されない。
- [ ] NEG専用棚に「Positive側には出力されません」と表示される。
- [ ] セットのチェック直押しと、カード本文の試着表示が干渉しない。
- [ ] おまかせ品質8系統は、系統に合わない品質語を混ぜない。
- [ ] 出力先検索の空検索切替で全件再検索せず、空白棚・フリーズが出ない。
- [ ] リセット初回・連続実行、選択中ビュー、出力ビューが正常に動く。
- [ ] ユーザー保存はZERO ASSISTのマイプリセットへ一本化され、ソース編集前提の見本棚がない。
- [ ] 背景18は細分部品、クイック・シーンはプリセットパック先頭の軽量セットとして共存する。
- [ ] クイック・シーン移動後も旧履歴・マイプリセットが安定IDで復元できる。
- [ ] 件数は最終runtime DBから計算され、旧ソースの数値を固定表示しない。
- [ ] 一般衣装アカシックは累計990項目、第三弾240項目が標準10棚へ同数の各24項目ずつ入る。
- [ ] 第二弾・第三弾データを再実行しても二重化せず、既存アルカディア特化棚144項目を変更しない。
- [ ] 第三弾項目を日本語検索で探せ、お気に入り・選択中・履歴・マイプリセットから復元できる。
- [ ] 起動直後はアカシックカード0枚で、カテゴリを1個開くとその8枚だけが生成される。
- [ ] 未描画inputも出力先件数、collector、リセット、履歴、マイプリセットの対象に残る。
- [ ] アルカディア白翼衣装庫は標準10棚の後、R18専用ゾーンの前にあり、初期状態で閉じている。
- [ ] アルカディア階級・役職別衣装の一般表示に固有の人物名が混ざらない。
- [ ] アルカディア衣装の出力promptへ人物名・髪・目・性別・背景・汎用品質語が混ざらない。
- [ ] v3.7以前の履歴・マイプリセットを旧安定IDで復元し、復元後は新しい階級・役職名を表示する。
- [ ] 衣装改造工房は5軸各20項目、合計100項目で、全件POS通常である。
- [ ] 改造工房はアルカディア後、R18専用ゾーン前の特化棚にあり、親棚・5軸が初期閉じである。
- [ ] 改造promptへ人物外見・性別・背景・ポーズ・照明・汎用品質語が混ざらない。
- [ ] 同一推奨軸を複数選んでも自動解除せず、軸重複数だけ表示する。
- [ ] 改造部品を日本語検索、お気に入り、選択中、履歴、マイプリセット、リセットで復元・解除できる。
- [ ] node構文、DOM操作列、実データ、zip整合性の結果を分けて報告する。

## 24. 作品形式スターターパックルール

作品形式スターターは「誰を・何を描くか」ではなく、「どのような完成物にするか」を決める軽量パックである。人物設定・衣装・画風・背景・品質の代わりにしてはいけない。

現行12形式：
1. 人物ポートレート
2. 全身立ち絵・設定画
3. 一枚絵・キービジュアル
4. 漫画表紙・ゲームカード
5. 背景コンセプトアート
6. メカ設計・機体展示
7. クリーチャー図鑑
8. 商品広告・パッケージ
9. 絵本・児童書
10. ピクセルゲーム画面
11. ローポリゴン・ジオラマ
12. ホラー・夢幻イラスト

配置・表示：
- 新しい番号付きセクションを増やさず、既存「プリセットパック」の先頭へ置く。
- 実DOMではクイック・シーンの次に見える順序にする。
- 親棚とカテゴリは初期状態で閉じる。
- スマホでは案内・カテゴリ・カードを一列表示にする。

プロンプト設計：
- 形式に必要な構図・視認性・画面用途だけを指定する。
- キャラ名、性別、衣装、髪色、世界観などを固定しない。
- `masterpiece`、`highest quality` など汎用品質語を形式パックへ混ぜない。品質はおまかせ品質等で別に選ぶ。
- ピクセル形式の `intentional low-resolution aesthetic` 等はPOS表現として維持し、NEGへ移さない。
- ホラーは流血へ固定せず、違和感・暗さ・空間歪みを中心にする。

選択・保存：
- 全形式をPOS通常として出力する。
- 作品形式同士だけを排他切替し、他棚の人物・背景・品質選択は解除しない。
- 各形式は安定input ID、data-pack-id、outputChannel、promptIntentを持つ。
- マイプリセット・履歴は安定IDまたはpack IDで復元する。

試着：
- □の直押しは詳細を開かず、その場でON/OFFする。
- カード本文は適用前確認を開き、追加後Positiveと維持されるNegativeを表示する。
- 確定前はチェックを変更しない。
- 必要なら語ごとに分解でき、分解語も安定ID・POS通常を保持する。

回帰確認：
- 3カテゴリ・12形式が重複IDなしで描画される。
- 親棚・カテゴリが初期状態で閉じている。
- 形式Aから形式Bへ切り替えるとAだけが外れ、他棚の選択は残る。
- カード本文からPOS通常の試着が開き、既存Negativeが維持表示される。
- Generate後に選択形式がPositiveへ出力される。

## 25. 衣装棚の用途別カタログ再編ルール

衣装棚は「元ファイルの追加順」ではなく、ユーザーが描きたい衣装へ辿り着く用途順で見せる。整理のために既存のチェック項目を作り直してはならない。安定ID・値・出力先・保存互換を維持するため、実在するinputとカードDOMをそのまま新しい棚へ移動する。

### 25.1 現行の標準10棚

1. すぐ使う・コーデセット
2. 日常・カジュアル
3. 仕事・役割・制服
4. フォーマル・季節イベント
5. 水着・リゾート
6. 和装・民族・地域衣装
7. ファンタジー・歴史・戦闘
8. SF・近未来・宇宙
9. サブカル・ステージ・スポーツ
10. パーツ・素材・着こなし調整

分類名は利用目的を表す。元の拡張番号や実装ファイル名をユーザー向け棚名にしない。親棚と子カテゴリは初期状態で閉じ、スマホでは説明・カテゴリ・カードを必ず一列表示にする。

v3.3監査値は、通常衣装3,778項目、標準10棚内1,363項目である。v3.4衣装アカシック第一弾では510項目を追加し、通常衣装4,288項目、標準10棚内1,873項目となる。v3.5白翼衣装庫では特化棚へ144項目を追加し、通常衣装の基準値は4,432項目となる。v3.6一般衣装アカシック第二弾では標準10棚へ同数の各24項目、計240項目を追加し、実runtimeで通常衣装4,672項目、標準10棚内2,113項目となった。v3.7第三弾でも同じ配分で240項目を追加し、一般衣装アカシック累計990項目、実runtimeで通常衣装4,912項目、標準10棚内2,353項目となった。残りはSHIMA・Spicy、中国／アイドル、モチーフ融合、サイバー／機械などの大規模な専門棚として直下に置く。件数は固定仕様ではなく監査時の基準値とし、追加後はruntime DOMから再計算する。

### 25.2 整理時に壊してはいけないもの

- checkboxをcloneして新規IDを振らず、元ノードを移動する。
- inputのid、value、data-en、data-val、data-output-channel等を維持する。
- 元source collectorが参照する専用classを残す。
- 同じclass名を別系統へ流用しない。サブカルとコーデ完成セットなど、値の属性形式が異なる系統は必ず別classにする。
- 分割表示された同一カテゴリは、単一のquerySelectorではなくquerySelectorAllで全rootから選択値を集める。
- 再編処理を再実行しても選択状態・お気に入り・履歴・マイプリセット復元を変えない。
- 未分類の通常項目だけを互換棚へ退避し、空の互換棚は表示しない。

### 25.3 R18判定の境界

子孫テキストに「拘束」「ランジェリー」等の語が一つあるだけで、巨大な親コンテナ全体をR18として除去してはならない。通常／R18の判定は、既知のR18 root class、専用属性、またはroot自身の見出しがR-18・NSFW・🔞で始まることを基準にする。

- 通常モードではR18 rootだけを非表示または除外する。
- R18解除時は専用ゾーンを衣装棚の最後に置く。
- R18の孤立項目が見つかった場合は通常の互換棚へ混ぜず、R18専用ゾーンへ移す。
- 通常棚の語を含む親全体が誤って消えていないか、変更前後の実DOM件数差を監査する。

### 25.4 専門棚と標準棚の関係

SHIMA・Spicy、巨大地域コレクション、モチーフ融合、サイバー／機械のように独自の選び方を持つ棚は、標準10棚の中へ細切れに混ぜない。標準棚の後、R18専用ゾーンの前に直下で置き、元の内部UIと出力collectorを維持する。

衣装を追加する時は、まず既存10棚のどこへ入るかを決める。新しい番号付き大棚は、既存用途へ収まらず、かつ独立した選択体験が必要な場合だけ増やす。

### 25.5 衣装棚の回帰確認

- 標準10棚が一列・初期閉じで並び、棚名が横書きで読める。
- 通常モードで全通常checkboxが一度だけ存在し、空の互換棚がない。
- R18解除時も標準10棚は変わらず、R18専用ゾーンが最後にある。
- 10棚から代表項目を選び、再編処理を再実行してもcheckedが維持される。
- 全source collectorから代表項目を選び、`undefined`、欠落、二重出力がない。
- `data-en`系、`data-val`系、分割role系をそれぞれ選び、Generate結果に値が入る。
- 検索で衣装名へ移動すると、新しい親棚と子カテゴリが開き、対象カードが見える。
- 選択後の検索移動、選択中ビュー、履歴復元、マイプリセット復元を確認する。
- Android実機で棚開閉、長い衣装名、固定フッターとの重なり、スクロールを確認する。

### 25.6 衣装アカシックへの追加ルール

大量の衣装を追加する時は、既存bundleへ直接追記せず、データ定義とUI／collectorを独立ファイルに分ける。用途別カタログより前に読み込み、追加カテゴリを既存の標準10棚へ直接収容する。

現行v3.4第一弾：
- 完成コーデ50
- 日常50
- 制服・職業50
- 正装・舞台50
- 水着・部屋着50
- 伝統・歴史50
- ファンタジー50
- SF・近未来50
- サブカル・トレンド50
- 形・柄・靴などの調整60
- 合計510項目、51カテゴリ

現行v3.6第二弾：
- 一般衣装側の追加であり、アルカディア特化棚の拡張ではない。
- 標準10棚へそれぞれ3カテゴリ、24項目を追加。
- 30カテゴリ、240項目。第一弾と合わせて累計750項目。
- ジャンル主人公、現代シーン、オリジナル概念服、工芸職、交通・インフラ、式典、水上競技、世界史、珍しいRPG職、宇宙開発、現代コア、特殊素材などを拡張。

現行v3.7第三弾：
- 一般衣装側の追加であり、アルカディア特化棚の拡張ではない。
- 標準10棚へそれぞれ3カテゴリ、24項目を追加。
- 30カテゴリ、240項目。第一弾・第二弾と合わせて累計990項目。
- 世界の旅、節目、オリジナル職業、季節、アダプティブ服、舞台裏、救助、食と農、礼装コード、水辺の仕事、地域礼装、幻想生活職、惑星環境、音楽シーン、メイカー、縫製仕上げなどを拡張。

データ設計：
- input IDは `attire-akashic-<棚>-<カテゴリ>-<slug>` 形式の安定IDにする。
- 日本語表示を `data-ja`、英語promptを `data-en` に保持する。
- 通常衣装は `data-output-channel="positive"`、`data-prompt-intent="normal"` を明示する。
- 完成コーデは複数の見える衣装要素を持たせ、単品・形状・素材調整とは区別する。
- 衣装セットへ `masterpiece`、解像度、照明、背景、人物固定語を混ぜない。
- 通常棚へ露骨なR18語を混ぜず、R18は既存の専用ゾーンへ置く。
- 地域衣装は地域名と主要構造を明確にし、異なる文化を一つの曖昧な「民族風」へ混ぜない。

重複防止：
- 新規データ内で安定ID、日本語名、正規化promptを重複させない。
- runtimeで既存checkboxのIDと `data-en` / `data-val` / `data-tags` を索引化する。
- 大文字小文字、全半角、空白、カンマ前後を正規化して完全一致を判定する。
- 一致候補は描画せず、スキップ件数と対象を監査レポートへ残す。
- 同じ衣装概念でも、形・時代・用途が明確に異なる派生は別項目としてよい。

表示・保存互換：
- 親棚・追加カテゴリは初期状態で閉じる。
- スマホではカードを一列・横書きにし、チェック、日本語名、POS表示、お気に入り星を重ねない。
- 新規カードもZERO ASSISTのお気に入り、選択中、履歴、マイプリセット、リセットの対象にする。
- `data-ja` を持たせ、選択中チップや保存画面に英語prompt全体ではなく日本語名を表示する。
- カタログ再整理時は新規checkbox DOMを複製せず、そのまま移動する。

追加後の最低監査：
- 候補数、実追加数、既存promptスキップ、ID衝突を報告する。
- 標準10棚すべてから代表項目を選び、UI_REGとGenerateのPositiveへ一度だけ出ることを確認する。
- 用途別再整理を再実行し、checkedと安定IDが維持されることを確認する。
- POS絞り込みでは表示、NEG絞り込みでは除外されることを確認する。
- 日本語名検索で新しい親棚とカテゴリが開くことを確認する。
- お気に入り星、履歴復元、マイプリセット復元を新規項目で確認する。
- R18解除時も標準10棚の件数が変わらず、R18専用ゾーンが最後に残ることを確認する。

### 25.7 オリジナルIP・階級／役職モチーフ衣装庫ルール

同じ世界観・組織・キャラクター群から大量の派生衣装を作る場合は、単発の完成セットだけを増やさず、「完成衣装」と「再利用部品」の二層にする。既存の標準10棚へばら撒くより、世界観として一つの選択体験が成立する場合は、独立した特化棚として標準10棚の後、R18専用ゾーンの前へ置く。

現行v3.8「白翼衣装庫 ― ARCADIA WARDROBE」：
- 階級・役職別完成衣装：9系統 × 8派生 = 72件。
- 艦・部門・航路の完成衣装：12件。
- 白翼モジュール：6カテゴリ × 10件 = 60件。
- 合計144件、完成衣装84件＋部品60件。

現行9階級・役職：
1. 艦隊総司令官：白・銀・航路青、指揮官／パイロット、帰還航路。
2. 士気支援官：白・若草、祝福リボン、乗員支援。
3. 作戦参謀長：白・黒・金、参謀／作戦、鋭い線と作戦図。
4. 主席操舵士：白・濃紫、艦橋操舵、光／闇反転構造。
5. 重砲隊長：黒・赤・金、重砲指揮、不壊帯と照準線。
6. 情報統制官：白・黒・深紅、通信・情報統制、データ層と防護羽襟。
7. 機関長：白・灰・機関青、機関部門統括、工具と可動装甲。
8. 軽飛行隊長：白・黒・紫、軽飛行指揮、省エネルギー構造。
9. 主席航海士：白・淡水色、航路策定、安全航路と柔らかな安定感。

共通8派生：
- 基本制服
- 戦闘・出撃
- 式典・礼装
- 私服・オフデューティー
- 雪原・冬装備
- DAYS SUMMER FES
- ダーク・Alter
- 幻想世界・再解釈

一般表示と再利用設計の境界：
- 一般利用者向けの棚名、カテゴリ名、項目名、検索名、選択中、お気に入り、履歴、マイプリセットへ固有の人物名を出さない。
- 階級・役職名は衣装の用途を示すラベルであり、特定人物の外見や設定を固定しない。
- 内部の旧カテゴリkeyと安定IDは保存互換の識別子としてのみ維持し、ユーザー向け表示には使わない。
- 出力promptには人物名を入れない。衣装の配色、形、役割、装飾、素材、装備へ分解する。
- 髪、目、肌、性別、人物数、体型を固定しない。別の「うちの子」に着せ替えられることを優先する。
- 背景、ポーズ、照明、画風、`masterpiece`等の汎用品質語を衣装へ混ぜない。
- 完成衣装は一着として成立する複数要素を持たせる。部品は既存衣装へ足せる一つの役割に絞る。
- オリジナル固有語だけでは画像モデルへ伝わらないため、見える衣装構造を英語で併記する。

実装：
- データとUI／collectorを独立ファイルにする。
- 安定IDは `attire-arcadia-<群>-<カテゴリ>-<slug>` とする。
- 既存ラベルを改称する時は安定ID、カテゴリkey、slug、英語promptを変えず、表示title、note、`data-ja`だけを更新する。
- 全項目に `data-en`、`data-ja`、`data-output-channel="positive"`、`data-prompt-intent="normal"` を持たせる。
- 読込順は衣装本体 → 衣装アカシック → アルカディアデータ → アルカディアUI → 用途別カタログ。
- 用途別カタログの特化selectorへ明示登録する。
- 旧 `__normalizeAttireLayout` と用途別カタログが同じDOMを再整列する場合、カタログ確定classを境界に旧整列を停止し、棚順の後戻りとMutationObserver競合を防ぐ。
- 親棚と全カテゴリを初期状態で閉じ、スマホは一列・横書きにする。

追加後の監査：
- 候補数、追加数、既存promptスキップ、ID衝突、群別件数を実DOMから取得する。
- 新規ID、日本語名、正規化promptの一意性を確認する。
- 新規promptへ人物外見、背景、汎用品質語が混ざっていないか禁止語監査する。
- 標準10棚より後、R18専用ゾーンより前にあることを子要素indexで確認する。
- 親棚・カテゴリの初期closed、POS一致、NEG不一致、collector一回出力を確認する。
- 日本語名検索、お気に入り、選択中、履歴、マイプリセット、リセットを代表項目で確認する。
- 旧ラベルを持つ保存スナップショットを安定IDで復元し、新ラベル表示とcheckedが一致することを確認する。
- 144件の安定ID列と英語prompt列のハッシュを前版と比較し、表示変更だけであることを証明する。
- Android実機では長い階級・役職名、8派生の開閉、固定フッターとの重なり、連続スクロールを確認する。

### 25.8 一般衣装アカシックの継続増築ルール

衣装を継続的に増やす時は、基礎510項目のファイルを毎回大きく書き換えない。一回の増築を1個のデータ拡張ファイルとし、基礎データの後・UI描画の前に読み込む。

読込順の原則：
1. 一般衣装アカシック基礎データ。
2. 第二弾、第三弾などのデータ拡張を古い順。
3. 衣装アカシックUI / collector。
4. アルカディア等の独立特化棚。
5. 用途別衣装カタログ。

拡張データの必須仕様：
- 拡張ごとに一意の `EXPANSION_ID` を持つ。
- 適用済みIDを基礎DB側の配列へ記録し、同じ拡張を再実行しても二重追加しない。
- 基礎DBが未読込みの時は勝手に空DBを作らず、適用できないことを明示する。
- 対象群と新規カテゴリだけをappendし、`groups`全体を再代入しない。
- カテゴリkeyは拡張世代が分かるprefixを持たせ、既存keyと衝突させない。
- 追加後のversion、期待総数、今回追加数をデータAPIから取得できるようにする。

990項目以降の遅延描画仕様：
- 安定checkbox inputは全件を起動時にDOMへ置く。inputまで遅延させて履歴・マイプリセット・リセット・collectorから見えなくしてはならない。
- 起動時にhiddenにできるのは、安定ID、`data-ja`、`data-en`、`data-output-channel`、`data-prompt-intent`を持つ未描画inputである。
- 日本語名、英語prompt、POS badge、お気に入り星を含むカードDOMは、カテゴリを実際に使う時だけ生成する。
- カテゴリopen時は、そのカテゴリのpending inputだけをカードへ移す。全カテゴリを一括生成しない。
- 文字検索は本体検索のbubble処理より先のcapture段階で一致カテゴリをカード化し、その後に既存検索へ渡す。
- 選択中フィルターはchecked input、お気に入りフィルターは保存済み安定ID、選択チップ移動は対象inputだけを起点に必要カテゴリをカード化する。
- 履歴・マイプリセット復元は、未描画inputを安定IDまたは保存値で先に解決する。祖先detailsをopenした時にそのカテゴリをカード化する。
- 出力先検索の全件数にはpending inputも含める。カードがないことを「項目がない」と扱わない。
- 用途別カタログ再整理はpending inputと既描画カードのどちらも元ノードのまま移動し、checkedを変えない。
- カード化後は検索索引・選択中表示を必要な範囲だけ更新し、全UIの再マウントを行わない。

遅延描画の最低runtime確認：
- 起動時 `input=期待総数`、`card=0`、全カテゴリclosed。
- 8件カテゴリを1個開いた時、cardが8件だけ増え、pendingが8件減る。
- 未描画の日本語名検索で対象カテゴリだけがカード化され、対象が見える。
- 未描画項目をcheckedにし、collectorと選択中チップが正しく拾う。
- 未描画項目をお気に入り・履歴・マイプリセットへ保存し、解除後に復元できる。
- 選択チップ移動で対象カードと祖先棚が見える。
- 再整理後もcheckedが維持され、実行時エラーがない。
- v3.7基準値は起動時990 input / 0 card、1カテゴリopen後8 card、全操作監査後も696 pendingである。件数は将来の増築後に再計算する。

内容の増やし方：
- 過剰に一棚だけを太らせず、標準10棚の穴を見てバランスよく追加する。
- ユーザーが一押ししたい完成コーデと、細かく組みたい単品・素材・構造を両方増やす。
- 一般的なジャンル、仕事、地域、歴史、現代トレンド、オリジナル概念服を一般衣装側に入れる。
- 固有IPのキャラクター派生や組織モチーフは、一般衣装側と混ぜず独立特化棚の境界を守る。
- 概念が似ていても、用途・時代・構造が違う派生はよい。ただし表示名、slug、正規化promptは一意にする。

拡張後の必須監査：
- 基礎だけのテストと、全拡張適用後の統合テストを分ける。
- 拡張単体と基礎＋拡張全体の両方で、ID、slug、日本語名、正規化promptの一意性を確認する。
- manifestで `基礎 → 全拡張 → UI → 特化棚 → カタログ` の順になっているか確認する。
- 追加数、累計数、標準10棚の群別数、通常衣装全体を実runtime DOMから取得する。
- 代表10項目でcollector、POS / NEG検索、お気に入り、選択中、履歴、マイプリセット、棚再整理後のchecked維持を確認する。
- 既存特化棚の件数・位置・初期closedが変わっていないことを別に確認する。

### 25.9 衣装改造工房・非破壊派生ルール

衣装改造工房は、完成衣装を新しい完成セットへ置き換える棚ではない。先に選んだ衣装の主題を残し、外形・素材・環境適応・装飾・配色だけを後付けで変化させる。

現行v3.9第一弾：
- シルエット変換：20件、1つ推奨。
- 素材・表面置換：20件、1つ推奨。
- 状態・任務変化：20件、複数選択可。
- 装飾・ディテール追加：20件、複数選択可。
- 配色・光彩変換：20件、1つ推奨。
- 合計100件、すべてPositive通常。

出力境界：
- 改造promptは衣装の形、布地、硬質部品、表面、機能、縫製、装飾、配色に限定する。
- 人物名、髪、目、肌、性別、人物数、体型、ポーズを固定しない。
- 背景、照明、画風、`masterpiece`等の汎用品質語を混ぜない。
- 元衣装側のinput、安定ID、prompt、checked、保存データを書き換えない。
- 改造工房は新規checkboxとして追加し、選択した語だけをcollectorへ渡す。

軸重複の扱い：
- `single`は強制排他ではなく「1つ推奨」を意味する。
- 同一`single`軸を2件以上選んでも、先の選択も後の選択も勝手に解除しない。
- 警告は「軸重複 N」とし、重複している軸の数を表示する。項目数の超過数と混同しない。
- 意図したハイブリッド衣装を禁止しない。自動修正ではなく意思決定支援に留める。

実装：
- データとUI／collectorを `builder_data.attire_remix_lab.v1.js` と `ext_attire_remix_lab.v1.js` に分ける。
- 安定IDは `attire-remix-<axis>-<slug>` とする。
- 全inputに `data-en`、`data-ja`、`data-output-channel="positive"`、`data-prompt-intent="normal"`、`data-remix-axis`、`data-remix-selection` を持たせる。
- 読込順は衣装本体 → 一般衣装アカシック → アルカディア → 改造工房データ → 改造工房UI → 用途別カタログ。
- 用途別カタログと旧整列処理の両方で `.attire-v39-remix-lab` を特化棚として保護する。
- アルカディア後、R18専用ゾーン前へ配置する。
- 親棚と5軸は初期閉じ。スマホは案内、フロー、軸、カードを一列・横書きにする。

追加後の最低監査：
- 候補数、追加数、既存promptスキップ、ID衝突、軸別件数を実DOMから取得する。
- ID、slug、日本語名、正規化promptの一意性を確認する。
- 改造promptに人物・背景・品質の禁止語が混ざっていないか確認する。
- 日本語検索、POS絞り込み、選択中、お気に入り、履歴、マイプリセット、リセットを代表項目で確認する。
- 履歴・プリセット・リセットの直後にREMIX STATUSがcheckedと一致するか確認する。
- 同一`single`軸を2件選び、両方checkedのまま「軸重複1」になるか確認する。
- 用途別カタログ再整理後もcheckedと同一input DOMが維持されるか確認する。
- v3.9基準値は通常衣装5,012、標準10棚2,353、アルカディア144、改造工房100。件数は将来の増築後に再計算する。

### 25.10 通常／R-18衣装改造工房の統合・分離ルール

v4.0では、通常側の既存「形・柄・色・着こなし調整」と衣装改造工房を一つの入口へ統合する。一方、R-18側は通常工房へ混ぜず、R-18解放時だけ専用工房を生成する。

通常衣装改造工房：
- 上段はv3.9の5軸100部品を「おまかせ改造」として維持する。
- 旧トップレベル「形・柄・色・着こなし調整」380入力を、下段の「詳細加工庫」へDOM移管する。
- 合計は100＋380＝480部品。通常衣装全体は5,012入力のままで、コピーによる増加を起こさない。
- 用途分類データ上の10群と2,353入力は維持するが、画面上は旧調整棚を独立トップ棚として表示しない。
- 詳細加工庫には袖、襟、形、柄、配色、靴、レッグウェア、手袋、状態を収容する。
- 移管は既存checkboxそのものを `appendChild` で移動し、`cloneNode`、再生成、prompt再登録を行わない。
- input ID、`data-en`、`data-ja`、checked、既存collector、履歴、お気に入り、マイプリセットを維持する。
- 通常工房ステータスは、おまかせ100と詳細380を合算した選択数に加え、詳細選択数を別チップで表示する。
- 親工房と詳細加工庫は初回だけclosedにする。検索や履歴復元後まで強制的に閉じ続けてはならない。

用途別カタログ再整理との共存：
- カタログ再整理時はいったん380カテゴリが用途別adjust群へ戻ってよい。
- 整理完了イベント後に詳細加工庫へ再移管し、旧トップレベル調整棚を再び除く。
- 後勝ちのmountや遅延整理にも備え、`attireCatalogOrganized`、`promptPartMounted`、限定したMutationObserverで再統合する。
- MutationObserverはトップレベルadjust群の追加だけを監視し、全subtreeの連続再描画や無限再配置を起こさない。
- 再統合時にcheckedを変更しない。同一input DOMと安定IDを維持する。

R-18衣装改造工房：
- 名称は「R-18衣装改造工房 ― NIGHT REMIX」。R-18専用ゾーンの区切り直後、既存特化コレクションより前へ置く。
- 露出カット・開口設計：20件、1つ推奨。
- 破損・着崩れ進行：20件、複数選択可。
- 艶素材・密着置換：20件、1つ推奨。
- 留め具・拘束装飾：20件、複数選択可。
- 着こなし・保持限界：20件、1つ推奨。
- 合計100件、すべてR-18側のPositive出力部品。
- 既存R-18衣装1,199入力・23特化コレクションは複製・移動・改名せず、その下の詳細資料庫として維持する。
- R-18解放時は既存1,199＋工房100＝1,299入力。衣装全体は通常5,012＋R-18 1,299＝6,311入力。

R-18境界：
- `localStorage.MY_SECRET_UNLOCK !== "true"` の時はR-18工房DOMを一件も生成しない。
- 未解放時は通常衣装5,012入力、R-18工房0、`data-r18-only`要素0を維持する。
- 解放時だけ `#__attire_r18_last_zone__` 内へ生成する。通常工房の子孫へ置かない。
- 全inputに `data-r18-only="1"`、`data-output-channel="positive"`、`data-prompt-intent="normal"`、安定IDを持たせる。
- 未解放時の通常検索には存在させない。解放中は全体検索から日本語名で見つけられてよい。
- R-18専用promptは成人衣装であることを明示し、未成年を示す語を入れない。
- R-18衣装工房は衣装の開口、破損、素材、留め具、着用状態に限定し、性行為や人物年齢を衣装部品へ混ぜない。

R-18実装：
- データを `builder_data.attire_r18_remix_lab.v1.js`、UI／collectorを `ext_attire_r18_remix_lab.v1.js` に分離する。
- 安定IDは `attire-r18-remix-<axis>-<slug>` とする。
- 読込順は通常工房 → 用途別カタログ → 通常詳細統合 → R-18工房データ → R-18工房UI。
- 既存promptとIDを実DOMから索引化し、完全一致重複とID衝突を描画前に除外する。
- `single`は強制排他にしない。複数選択時も両方を維持し、「軸重複 N」の警告だけを表示する。
- 親棚と5軸は初期closed、Android幅ではカードを一列・横書きにする。
- 履歴、マイプリセット、選択中、お気に入り、検索、リセット、衣装棚クリア、collector一回出力へ対応する。

v4.0最低監査：
- 通常モード：通常入力5,012、通常工房100＋380＝480、旧トップレベルadjustなし、R-18工房なし、runtime error 0。
- R-18解放：通常5,012、既存R-18 1,199、新R-18工房100、合計6,311、runtime error 0。
- 代表的な通常おまかせ部品と詳細部品を同時選択し、各promptがUI_REGへ一度だけ出ることを確認する。
- 用途別カタログ再整理後、詳細380が工房内へ戻り、代表inputのcheckedとIDが維持されることを確認する。
- R-18 5軸から代表1件ずつ選び、各promptが一度だけPositiveへ出ることを確認する。
- R-18単一推奨軸を2件選び、両方checkedのまま軸重複1になることを確認する。
- R-18日本語検索、履歴復元、マイプリセット保存・復元、全体リセットを確認する。
- 通常ロック／R-18解放の両モードを別々のruntime DOMで監査し、片方だけの確認で完了にしない。

### 25.11 アクセサリー・装備アカシックの非破壊再編ルール

アクセサリー欄は項目数だけで充実度を判断しない。現行v4.0の通常1,482項目は、食べ物1,083、武器212を含み、人物が身につける装備は約50項目に留まっていた。食べ物や武器を削って数字を整えるのではなく、既存棚を保ったまま、人物装備を部位と用途で探せる独立アカシックを先頭へ追加する。

現行v4.1第一波：
- おまかせ装備セット：5カテゴリ40点。
- 頭・髪・顔・耳：5カテゴリ40点。
- 首・胸・肩：5カテゴリ40点。
- 腕・手・指：5カテゴリ40点。
- 腰・脚・足元：5カテゴリ40点。
- 背中・バッグ・携行：5カテゴリ40点。
- 生活・職業・趣味道具：5カテゴリ40点。
- 魔法・SF・戦術支援：5カテゴリ40点。
- 素材・色・状態調整：5カテゴリ40点。
- 合計9群45カテゴリ、360点。全件Positive通常。

役割の境界：
- 「おまかせ装備セット」は、4点以上の小物を組み合わせた軽量な完成セットにする。衣装、人物外見、背景、品質を固定しない。
- 部位群は身につける位置を基準にする。似た世界観でも、頭・手・腰など装着位置が違えば別群へ置く。
- 生活・職業・趣味道具は非武器の役割小物に限定する。武器種は既存の武器・兵器棚を使う。
- 魔法・SF・戦術支援は触媒、防護、救難、装着端末、支援ドローンに限定し、攻撃武器と混ぜない。
- 素材・色・状態調整は選んだ装備へ後付けできる修飾語とする。人物の髪、目、肌、衣装本体を上書きしない。
- 食べ物・飲み物はアクセサリー実装内に残っていても装備アカシックへ混ぜない。食べ物連動、量、トッピング等の既存ロジックを壊さない。

既存棚の非破壊維持：
- 既存通常134カテゴリ1,482項目を削除、改名、再生成しない。
- 既存R-18 5カテゴリ72項目を削除、通常化、装備アカシックへ移植しない。
- 新棚は `CATEGORIES` 全体を置換せず、データ読込後に専用prefixのカテゴリだけをappendする。
- 既存promptと新規promptを正規化索引で比較し、完全一致は追加しない。
- 新規ID衝突は追加前に除外し、候補数、実追加数、promptスキップ、ID衝突をruntime監査値として残す。
- 新しい棚を先頭へ出しても、既存の定番小物、財宝、食べ物、武器、状態・動作、R-18の相対順と専用境界を維持する。

データと読込順：
- データは `builder_data.accessory_akashic.v1.js` へ独立させる。
- 読込順は `builder_data.accessory_akashic.v1.js` → `builder_ui.section.accessories.bundle.js` とする。
- データAPIはversion、期待総数、群、カテゴリ、件数取得関数を持つ。
- 安定IDは `accessory-akashic-<群>-<カテゴリ>-<slug>` とする。
- 全inputに `data-en`、`data-ja`、`data-output-channel="positive"`、`data-prompt-intent="normal"`、群、カテゴリを持たせる。
- 新規promptに露骨なR-18語、`masterpiece`等の汎用品質語、人物外見、背景固定を混ぜない。
- データ上のslug、日本語名、正規化prompt、生成後の安定IDを一意にする。

UI：
- アクセサリー欄の見出しを「アクセサリー・装備・小物」とし、装備アカシックを既存定番小物より前へ置く。
- アカシック親棚、9群、45カテゴリはすべて初期closedにする。
- 案内文とカテゴリを同じ多列gridの兄弟へ混ぜない。
- Android幅では親、群、カテゴリ、項目カードを `minmax(0,1fr)` の一列へ固定する。
- 長い日本語名は横書きとし、チェック、お気に入り星、POS表示を重ねない。
- 初期closedは初回描画だけの既定値とし、検索、選択中、履歴復元後に勝手に閉じ直さない。

保存・検索・出力：
- 新規inputは起動時に全360件をDOMへ置き、検索、選択中、お気に入り、履歴、マイプリセット、リセット、collectorから見える状態にする。
- 日本語検索は該当カテゴリと全祖先detailsを開き、検索結果カードを表示する。
- ZERO ASSISTのお気に入りキーと保存復元は安定IDを優先する。
- マイプリセットは新規inputのIDとPositive出力先を保存する。
- 既存アクセサリーcollectorの `.accessories-section input:checked` を利用し、別collectorを二重登録しない。
- 選択promptはPositiveへ一度だけ出力する。Negativeへ自動送出しない。
- 全体リセットとアクセサリー棚クリアの対象から新規inputを外さない。

R-18境界：
- 未解放時は既存R-18 72入力をDOMへ生成しない。通常1,482＋新規360＝1,842を基準とする。
- 解放時は通常1,842＋既存R-18 72＝1,914を基準とする。
- 通常装備360点は解放状態に左右されず、ロック／解放で件数、ID、promptを変えない。
- 既存R-18は従来の専用親棚を末尾に維持し、初期closedとする。
- 通常装備の追加を理由にR-18語判定やR-18データを変更しない。

最低監査：
- 静的データ監査で9群、45カテゴリ、360点、各群40点を確認する。
- ID、slug、日本語名、正規化promptの一意性を確認する。
- 既存通常134カテゴリ1,482項目、既存R-18 5カテゴリ72項目がソース上で維持されることを確認する。
- runtime auditで候補360、追加360、promptスキップ0、ID衝突0を確認する。
- ロック時1,842、解放時1,914、両モードとも新規360を確認する。
- 親棚、9群、45カテゴリの初期closed、スマホ一列、横書きを確認する。
- 代表項目でチェック直押し、Positive一回出力、日本語検索、祖先棚open、お気に入り、マイプリセット保存・復元、リセットを確認する。
- ロック時にR-18項目0、解放時に既存72、専用親棚末尾・初期closedを確認する。
- 全回帰テストとロック／解放runtimeのruntime error 0を確認する。
- v4.1基準は自動テスト161 / 161成功、Android実機の最終タップ・折返し確認はユーザー側確認待ち。

次の増築：
- 第二波以降は同じ基礎ファイルを際限なく太らせず、世代別データ拡張に分ける。
- 追加前に既存360と既存通常1,482を索引化し、完全一致だけを除外する。
- 一群だけを肥大化させず、未充足の部位、文化、職業、時代、素材を実数で棚卸しして増やす。
- 固有キャラクター名は一般棚へ入れない。固有世界観として独立体験が成立する場合だけ特化棚へ分離する。

### 25.12 おまかせ・完成セットの構成説明ルール

セット名だけでは、ユーザーが想像する人物像や場面の幅が大きすぎる。たとえば「夜の街セット」は、女性のドレス小物、会社員の飲み歩き、サイバー都市、夜間警備など複数の解釈が成立する。データが実際に選ぶ小物を画面へ出さず、名前だけで選ばせてはいけない。

説明の必須要素：
- 何を狙うセットか：用途、雰囲気、人物の方向性、場面のうち必要なものを一文で示す。
- 何が入るか：実際にpromptへ含まれる主要部品を日本語で列挙する。
- 4部品セットなら4部品すべてを表示する。「など」で省略しない。
- データにない性別、年齢、職業、背景、物語を説明側で勝手に固定しない。
- 性別を明確に寄せた設計の場合だけ「男性寄り」「女性寄り」「中性的」を明記する。曖昧なセットを説明文だけで性別固定しない。

推奨表示形式：
```text
セット名
用途・方向性。部品A／部品B／部品C／部品D。
```

現行例：
```text
夜の街セット
都会的で中性的な夜歩き向け。色付き眼鏡／メタルイヤーカフ／小型クラッチ／淡く光るブレスレット。
```

データ実装：
- 安定ID、slug、日本語名、英語promptの後ろへ、表示専用の日本語descriptionを追加する。
- description追加を理由に既存ID、slug、prompt、出力先を変えない。
- データAPIのversionは表示仕様変更として更新してよいが、保存識別子は維持する。
- 説明は `data-description` とカード本文へ渡してよいが、collectorは `data-en`だけを出力し、説明をpromptへ混ぜない。
- 旧版との互換監査では、全ID＋prompt列を同順でハッシュ比較する。

UI実装：
- 説明をツールチップだけへ隠さず、セット名の直下へ常時表示する。
- セットカード内を「チェック／名称＋説明／お気に入り」に分け、説明が星やチェックへ重ならないようflexの中央領域へ置く。
- 説明は名称より一段小さくしてよいが、背景と同化しない文字色と十分な行間を使う。
- 説明部分をタップした時も、カードの通常選択操作が働くことを確認する。
- チェック直押し、星直押しは従来の役割を維持し、説明追加でイベントを横取りしない。
- Android幅ではカードを一列、横書き、自然な複数行折返しにする。固定高さを使って説明を切らない。

検索・保存：
- 日本語説明をlabel本文へ置く場合、全体検索の補助語として検索対象になってよい。
- 選択中チップ、履歴、お気に入り、マイプリセットの主表示名は従来の `data-ja` を維持し、長い説明全文へ置換しない。
- 説明変更だけで既存の履歴・お気に入り・プリセットを無効にしない。
- descriptionは表示情報であり、Positive／Negativeの出力先分類を持たない。

最低監査：
- 対象セット数とdescription保有数が一致する。
- descriptionに用途・方向性があり、主要部品が欠けず列挙されている。
- 代表的に曖昧だったセットを個別テストし、方向性と全内包物が画面に見える。
- 説明DOM数、カード数、セット数が一致する。
- 説明タップで選択、チェック直押しで解除、星直押しでお気に入りが動く。
- descriptionが生成promptへ混入しない。
- 旧版と新版のID＋prompt配列が完全一致し、ハッシュが同じである。
- 日本語検索、履歴復元、お気に入り、マイプリセット、リセットを代表セットで確認する。
- スマホ一列、横書き、長文折返し、星・チェック・固定フッターとの非重複を確認する。

v4.2確定値：
- おまかせ装備セット40件、description 40件、各説明は方向性＋内包4小物。
- v4.1／v4.2の360件ID＋prompt配列は完全一致。
- SHA-256は `e824df76201abda7e2712257758b7d4102234cc3baeb14cf28ea8fd9765209dc`。
- 自動テスト163 / 163、ロック／解放runtime error 0。
- Android実機の最終折返しとタップ感はユーザー確認待ち。

### 25.13 おまかせ装備第二弾・継続増築ルール

おまかせ装備は、単品を細かく選ぶ時間がない時に、役割の揃った小物だけを一度で加える入口である。数を増やす時も、衣装本体、背景、品質棚の代用品にしてはいけない。

第二弾の分類：
- 人物像・職業：役割を伝える携行品、記章、観察・作業道具。
- 時代・文化：年代や文化圏を感じさせる装飾、袋物、眼鏡、筆記・携行品。
- ジャンル・世界観：物語ジャンルを象徴する装置、護符、鍵、観測・通信小物。
- 行動・場面：通勤、観測、散策、旅行、鑑賞、制作など、その日の行動に必要な小物。
- 非アルカディア創作：既存作品、固有キャラクター、アルカディア設定へ依存しない完全創作モチーフ。

件数ルール：
- 第二弾は5カテゴリへ各12セット、合計60セットを同数で収録する。
- 既存40セットを削除・改称・移動せず、同じquick群の後半へ追加する。
- おまかせ装備は合計100セット、装備アカシック全体は420点、カテゴリは50となる。
- 次の増築では一カテゴリだけを先に肥大化させず、用途の空白を棚卸ししてから同数追加を検討する。

セット構成：
- 原則として英語promptはカンマ区切り4要素とする。
- 4要素は装飾、携行品、小型道具、身につける装置の範囲に収める。
- full outfit、complete outfit、背景、場所そのもの、人物外見、汎用品質語を入れない。
- 方向性を伝えるための職業名や場面名は表示名・説明へ使ってよいが、promptは小物だけで成立させる。
- 同じ部品を別表現で重ねて、実質1～2種類しかないセットにしない。

名称と説明：
- 名称は「誰・何をする・どの系統」の少なくとも一つが分かる具体名にする。
- 全セットへ25.12の形式で、方向性と実際の4小物を常時表示する。
- 「夜の街」「幻想」など幅の広い名前だけに頼る場合は、説明の一文目で人物像や用途を絞る。
- 性別固定はセット設計上必要な時だけ明記し、データにない性別を説明側で追加しない。

非アルカディア創作：
- アルカディア固有のキャラクター名、階級、組織、白翼記章を流用しない。
- 既存作品名、商標、著名キャラクターを直接参照しない。
- 月海、氷晶庭園、時計仕掛けの庭師、墨金幻想など、別作品にも転用できるモチーフ単位で作る。
- 独立した固有世界観へ育てる場合は、将来専用棚へ分離できる安定slugを使う。

安定IDと保存互換：
- 新規IDは `accessory-akashic-quick-{category}-{slug}` とし、既存IDへ再採番しない。
- v4.2の360件はIDと英語promptを全件維持する。
- 新規60件もPositive通常とし、既存アクセサリーcollectorから一度だけ出力する。
- 説明変更で履歴、お気に入り、マイプリセットの主キーを変えない。

最低監査：
- quick群100件、第二弾5カテゴリ各12件、装備全体420件を確認する。
- 420件のID、カテゴリ内slug、日本語名、正規化promptの一意性を確認する。
- おまかせ100件が英語4要素、description 100件が日本語4小物を持つことを確認する。
- 第二弾にfull outfit、背景、品質語、R-18語、Arcadia固有語がないことを確認する。
- v4.2既存360件のID＋promptをキー比較し、全件一致を確認する。
- runtimeで420件追加、prompt skip 0、ID collision 0を確認する。
- ロック時1,902、解放時1,974、解放差分72、runtime error 0を確認する。
- 第二弾代表で説明タップ、Positive一回出力、日本語検索、お気に入り、履歴、マイプリセット、リセットを確認する。
- 親群と50カテゴリの初期closed、スマホ一列、横書き、長文折返しを確認する。

v4.3確定値：
- 第二弾60セット＝5カテゴリ×12。
- おまかせ装備100セット、装備アカシック420点、9群50カテゴリ。
- v4.2既存360件のID＋prompt全件維持、追加60件。
- 既存360件のソート済みID＋prompt SHA-256は `17e3ec1ff4c1d224a05f13ca95589304d7c3c5f26bfec7a5f5201a49505d1b9e`。
- v4.3全420件のソート済みID＋prompt SHA-256は `102f17bafaff6508711f2be8f882bd12284776ca9f8d44af2bf65a2b2ea85d5c`。
- 自動テスト166 / 166、ロック／解放runtime error 0。
- Android実機の最終折返しとタップ感はユーザー確認待ち。

### 25.14 食のアカシック・非破壊再編ルール

食べ物ジャンルは、完成料理、食材、提供場面、調理演出、食べる動作、サイズ調整が同じ親棚に並び、目的から入口を判断しにくくなりやすい。一方で食データには対象連動が多く、単純なコピー、再生成、配列置換で整理すると、見た目が整っても合成機能と保存互換を壊す。食棚の整理は「データ追加」ではなく「既存機能を保ったDOM再配置」として扱う。

基本方針：
- 元データ `builder_ui.section.accessories.bundle.js` 内の `CATEGORIES` は書き換えない。
- 既存checkbox、label、detailsを `appendChild` で移動し、`cloneNode` やHTML文字列からの再生成をしない。
- checkboxのID、`data-en`、`data-ja`、選択状態、登録済みlistener、全食連動datasetを維持する。
- 新しいUI拡張はアクセサリーUI描画後に読み、既存DOMが揃ってから再編する。
- 再実行時は自分が作った10棚だけを一度ほどいて再配置し、入力を二重化しない。
- 元データに将来カテゴリが増えた場合、未認識ソースを完成料理棚へ互換収容し、消失させない。

標準10棚とv4.4基準件数：
1. おまかせ完成メニュー：5。
2. 完成料理・地域・世界観：336。
3. 提供場面・食卓：113。
4. デザート・トッピング：80。
5. 飲み物・容器・フレーバー：125。
6. 食材図鑑：226。
7. 特化調理工房：109。
8. 調理・温度・演出：36。
9. 食べる・飲む動作：33。
10. サイズ・量・個数：20。

移管構造：
- 既存トップレベル15系統を基準にする。
- 料理・ジャンル別の内側にある「デザート」は、トッピングとの距離を縮めるため独立ソースとして分離する。
- そのため移動対象は15ルート＋デザート1＝16ソースDOMになる。
- 合計は必ず1,083入力、未分類0を確認する。件数が合わない場合は表示だけ合わせず、追加・欠落したソースを先に特定する。
- 98カテゴリはデータ監査値として維持し、空の構造カテゴリも勝手に削除して件数定義を変えない。

連動機能の保護：
- 量はportion、unit、count、volume等のmodeと、対象kind・target keyを維持する。
- デザートは本体のdecoration targetと、果物・クリーム・ソース等のmodifier groupを維持する。
- 飲み物はdrink base typeとフレーバーmodifierを維持する。
- おにぎりは本体とフィリング／トッピングの対象紐付けを維持する。
- 丼完成セットはcomplete ID、collection role、linked IDsを維持する。
- ピザ完成セットもcomplete ID、collection role、linked IDsを維持する。
- 動作、演出、提供場面は通常Positive部品として従来どおり出力し、別collectorを追加しない。
- 対象連動を使う棚は、対象本体を先に選んでから部品を選ぶ案内を画面へ表示する。

検索・保存・出力：
- 日本語検索は再編後の全祖先detailsを開き、該当inputへ到達できること。
- お気に入りは既存checkboxの安定キーを使い、再編専用キーを新設しない。
- 履歴とマイプリセットは従来のinput IDと出力先を保存し、棚経路を保存識別子にしない。
- 再編前の保存データから復元でき、再編後に保存したデータも同じIDで戻ること。
- 既存collectorを共有し、一つの料理を複製出力しない。
- 全体リセットとアクセサリー棚クリアから食入力を外さない。

UI：
- 親見出しは「CULINARY AKASHIC / 食のアカシックレコード」とし、総数1,083を表示する。
- 入口では「完成料理を先に選び、必要な時だけ食材・仕上げ・演出・動作・サイズを足す」手順を短く示す。
- 親棚と10棚は初回描画時closedにする。
- 初期closedは初回だけの既定値とし、検索、履歴復元、選択中移動の後に強制的に閉じ直さない。
- Android幅では親、10棚、内側の既存カテゴリ、項目カードを一列にする。
- `writing-mode: horizontal-tb` を明示し、長い日本語名の縦崩れを防ぐ。
- 案内文とカテゴリカードを多列gridの同じ行へ混ぜない。
- 固定フッター、目次、i18nボタンと項目を重ねない。

最低監査：
- 既存食データが98カテゴリ、1,083入力であることを確認する。
- 元データ構造を正規化してハッシュ固定し、再編以外の意図しない変更を検知する。
- 10棚の入力数を個別確認し、合計1,083、未分類0を確認する。
- 再編前後の全入力についてID、英語prompt、食連動datasetのソート済み配列を比較する。
- `cloneNode` 不使用、16ソースDOM移動、再実行時二重化0を確認する。
- 代表操作として、完成料理一回出力、料理＋量、デザート＋トッピング、飲料＋味、おにぎり＋具を確認する。
- 丼完成セットとピザ完成セットで、linked IDsの全構成部品が連動することを確認する。
- 食名の日本語検索、祖先棚open、お気に入り、履歴保存・復元、マイプリセット保存・復元、リセットを確認する。
- R-18未解放／解放の既存差分72と専用境界を維持する。
- 親・10棚の初期closed、Android一列、横書き、runtime error 0を確認する。
- Android実機ではチェック直押し、対象連動、棚の折返し、固定フッターとの重なり、連打時フリーズなしを最終確認する。

v4.4確定値：
- 既存食98カテゴリ、1,083入力、既存トップレベル15系統。
- 10棚、移管ソースDOM 16、未分類0。
- 食データ構造 SHA-256は `aa427325a8e7894a1ef631a1294d9c25e971ace6ef2416458f87f1fce7fed934`。
- 未解放時アクセサリー1,902、解放時1,974、既存R-18差分72。
- 食専用テスト9 / 9、全回帰テスト175 / 175、ロック／解放runtime error 0。
- Android実機の最終折返し、直押し、連動、固定フッター非重複はユーザー確認待ち。

### 25.15 食のアカシック第一弾・継続増築ルール

食のアカシックは、棚整理だけで完成ではない。ユーザーが「描きたい食事」を文化圏や場面から選べるよう、完成献立と地域料理を主力にしつつ、甘味、飲料、食材、演出、動作も同じ世代単位で増築する。

データ分離：
- 既存1,083項目が入る `builder_ui.section.accessories.bundle.js` を追記先にしない。
- 世代別データは `builder_data.food_akashic.expansion.vN.js` へ独立させる。
- 世代別UIも `ext_food_akashic_expansion.vN.js` へ分け、基礎再編UIの後に読む。
- 読込順は、追加データ→既存アクセサリーUI→食の10棚再編→追加UIとする。
- 次の波で第一弾ファイルを無制限に太らせず、第二弾は別世代ファイルへ追加する。

第一弾の配分：
- おまかせ完成メニュー80。
- 完成料理・地域・世界観160。
- 提供場面・食卓40。
- デザート・トッピング40。
- 飲み物・容器・フレーバー30。
- 食材図鑑40。
- 特化調理工房10。
- 調理・温度・演出10。
- 食べる・飲む動作10。
- 合計42カテゴリ、420項目とする。

完成献立：
- 和朝食、洋ブランチ、弁当、カフェ軽食、家庭夕食、屋台、パーティー、幻想・未来食の8カテゴリへ各10件とする。
- 一項目で一食が成立するよう、主食、主菜、副菜、汁物、飲み物等から必要な構成を英語promptへ含める。
- セット名だけで内容を推測させず、実際の主要構成を日本語descriptionへ全件表示する。
- descriptionは「部品A／部品B／部品C／部品D」のように4要素以上を省略せず示す。
- descriptionは表示専用で、生成promptへ二重追加しない。

地域料理：
- 第一弾は16文化圏へ各10品、計160品とする。
- 対象は日本、中国、台湾、ベトナム、フィリピン、インドネシア／マレーシア、イギリス／アイルランド、ドイツ／オーストリア、スペイン／ポルトガル、北欧、東欧、中央アジア／コーカサス、北アフリカ、サブサハラ、ブラジル、カリブ。
- 有名料理だけで一国を代表させず、主食、麺、肉魚、家庭料理、屋台、甘味の幅を持たせる。
- 文化名は棚分類に使ってよいが、人物の国籍、民族、肌、服装、背景をpromptで固定しない。
- 固有の料理名は一般に通じる英語表記と視覚要素を併記し、名前だけの弱いpromptにしない。

役割と連動：
- 追加項目は全件Positive通常とする。
- 料理、完成献立、鍋は `foodTarget=true` とし、盛り量 `portion` を使えるようにする。
- 飲料は容量 `volume`、食材は単品サイズ `unit` を使う。
- 甘味はdessert decoration targetを持ち、既存の果物、クリーム、ソースを適用先として受けられるようにする。
- 演出は通常のPositive部品、調理・配膳は既存食動作と同じactionとして扱う。
- 既存collectorを共有し、別collectorを追加して二重出力しない。
- 既存の丼、ピザ、おにぎり、飲料フレーバー等の連動datasetを変更しない。

安定IDと重複防止：
- 第一弾IDは `food-akashic-v45-<群>-<カテゴリ>-<slug>` とする。
- slug、日本語名、正規化英語prompt、生成IDを追加世代内で一意にする。
- 追加前に既存1,083件の正規化英語prompt索引と照合し、完全一致を追加しない。
- UI起動時も既存input IDとpromptを索引化し、ID衝突とprompt重複を個別に監査する。
- candidate、added、ID collision、prompt duplicate、カテゴリ別件数をruntime reportへ残す。
- promptへ `masterpiece` 等の汎用品質語、R-18語、人物外見、背景固定を混ぜない。

UI：
- 10棚の中へ第一弾ソースを9本追加し、サイズ棚自体は増やさない。
- 第一弾ソース9本と42カテゴリは初期closedにする。
- 初期closedは初回既定値であり、検索、選択中、履歴復元後に強制的に閉じ直さない。
- 完成献立カードだけは名称の直下へ構成descriptionを常時表示する。
- Android幅はソース、カテゴリ、項目、説明を一列・横書きにし、固定高さで説明を切らない。
- 既存食の金色系テーマと区別しすぎず、第一弾であることが見出しから分かる程度に留める。

検索と保存：
- 新規inputは起動時に全420件をDOMへ置き、日本語検索、出力先検索、選択中、お気に入り、履歴、マイプリセット、リセットから見えるようにする。
- 追加後にチャンネル検索索引とZERO ASSISTを再読込し、件数と星を同期する。
- 履歴とマイプリセットは安定IDとPositive出力先を保存し、棚経路を主キーにしない。
- 日本語検索は第一弾カテゴリ、第一弾ソース、10棚、食親棚の全祖先を開く。

現在の10棚基準値：
- おまかせ完成メニュー85。
- 完成料理・地域・世界観496。
- 提供場面・食卓153。
- デザート・トッピング120。
- 飲み物・容器・フレーバー155。
- 食材図鑑266。
- 特化調理工房119。
- 調理・温度・演出46。
- 食べる・飲む動作43。
- サイズ・量・個数20。
- 合計1,503、未分類0。

最低監査：
- 第一弾42カテゴリ、420項目、約束した群別配分を確認する。
- 完成献立80件が4構成以上の英語promptと日本語descriptionを持つことを確認する。
- 地域料理16カテゴリが各10品であることを確認する。
- 追加420件のslug、日本語名、正規化prompt、生成IDの一意性を確認する。
- 既存1,083件とのprompt完全重複0、runtime ID衝突0を確認する。
- 10棚の現在件数合計1,503、追加ソース9、全ソース25、未分類0を確認する。
- 代表完成献立のPositive一回出力、追加料理＋大盛り、追加甘味＋既存トッピング、追加飲料＋大容量を確認する。
- 日本語検索、祖先棚open、お気に入り、履歴保存・復元、マイプリセット保存・復元、リセットを追加項目で確認する。
- 既存ジェラート、飲料、おにぎり、丼、ピザ連動が継続することを確認する。
- 未解放2,322、解放2,394、既存R-18差分72、runtime error 0を確認する。
- Android実機で一列、長文折返し、チェック直押し、固定フッター非重複、連打時フリーズなしを確認する。

v4.5確定値：
- 第一弾42カテゴリ、候補420、実追加420、重複prompt 0、ID衝突0。
- 既存食1,083＋第一弾420＝1,503。
- 追加データ構造 SHA-256は `fa8845caad0cd9d0b6b248b7229bd81b7084537086ef77f4f975dd498241f493`。
- 第一弾専用テスト13 / 13、全回帰188 / 188、ロック／解放runtime error 0。
- Android実機の最終折返し、直押し、連動、固定フッター非重複はユーザー確認待ち。

### 25.16 食のアカシック第二弾・世界料理と薄棚補強ルール

目的：
- 第一弾までに薄かった完成献立、食卓、甘味、飲料、食材、特化工房、演出、動作を均等に厚くする。
- 未収録だった人気文化圏を足し、「どんな料理を描くか」から広く選べる状態にする。
- 既存1,083件と第一弾420件を編集せず、後から第二弾だけ外せる独立層として積む。

データ分離と読込順：
- 第二弾データは `builder_data.food_akashic.expansion.v2.js` に置く。
- 第二弾UIは `ext_food_akashic_expansion.v2.js` に置く。
- 読込順は第一弾data→第二弾data→アクセサリー基礎UI→食10棚再編→第一弾UI→第二弾UIとする。
- 第二弾UIは第一弾9ソースの設置完了を確認してから動き、重複索引に第一弾420件も含める。
- 第一弾のファイル、安定ID、英語prompt、保存データを変更しない。

第二弾の配分：
- おまかせ完成メニュー60。
- 完成料理・地域料理120。
- 提供場面・食卓30。
- デザート・甘味40。
- 飲料30。
- 食材40。
- 特化調理工房20。
- 調理・温度・演出30。
- 食べる・作る・配膳動作30。
- 40カテゴリ、400項目、全項目Positive通常とする。
- サイズ棚は既存4モード20件がcollectorの定義値であるため、表示数を盛る目的だけで増やさない。

完成献立：
- 四季の和献立、韓国完成食卓、東南アジア完成食卓、家族の祝い、旅・野外、学校・職場・乗り物の6カテゴリへ各10件追加する。
- 第二弾60件も名称だけで内容を推測させず、日本語descriptionへ構成4要素以上を常時表示する。
- descriptionは表示専用とし、英語promptへ二重出力しない。
- 公共食や移動食は人物の年齢、性別、職業外見を固定せず、食事と食器・場面だけを記述する。

地域料理：
- 韓国、タイ、インド、ヒマラヤ、レバント、トルコ、ギリシャ／バルカン、イタリア、フランス、北米、メキシコ、ペルー／アンデスの12文化圏へ各10品、計120品追加する。
- 料理名だけで終わらせず、主要食材、調理法、ソース、付け合わせ、器の視覚要素を英語promptへ含める。
- 地域分類は料理の検索用であり、人物の国籍、民族、肌、衣装、背景を固定しない。
- 甘味を含む地域料理もcompleted群では一皿の完成料理として扱い、dessertトッピング対象にはしない。

薄棚の補強：
- 食卓場面は暮らし、市場・屋台、儀礼・上質会食の3カテゴリとする。
- 甘味は四季の和菓子、欧州パティスリー、アジア甘味、冷菓・祝祭菓子の4カテゴリとする。
- 飲料は世界の茶、珈琲・ココア、祝祭ノンアルコールの3カテゴリとする。
- 食材は青果、肉・蛋白、製菓材料、豆・茸・海藻の4カテゴリとする。
- 特化工房は世界のパンと完成麺の2カテゴリとする。
- 演出は温度・香り、食感・断面、料理構図の3カテゴリとする。
- 動作は下ごしらえ、加熱、配膳・食事の3カテゴリとする。
- 演出promptへ `masterpiece` 等の汎用品質語を混ぜず、料理にだけ作用する状態と構図を記述する。

役割と連動：
- 完成献立、地域料理、甘味、パン、麺は `foodTarget=true`、盛り量 `portion` とする。
- 飲料は容量 `volume`、食材は単品サイズ `unit` とする。
- 第二弾甘味はdessert decoration targetを持ち、第一弾・既存と同じ果物、クリーム、ソースを受けられるようにする。
- 食卓場面と料理演出は通常Positive部品とし、独立した量対象にしない。
- 調理・配膳動作は既存action collectorへ渡し、別collectorで二重出力しない。

安定IDと重複防止：
- 第二弾IDは `food-akashic-v46-<群>-<カテゴリ>-<slug>` とする。
- slug、日本語名、正規化英語prompt、生成IDを第二弾400件内で一意にする。
- 既存1,083件と第一弾420件の正規化prompt索引へ照合し、完全一致を追加しない。
- UI起動時も現在DOMのpromptと全input IDを索引化し、prompt duplicateとID collisionを個別記録する。
- promptへ汎用品質語、R-18語、人物外見固定を混ぜない。
- 第二弾データ構造SHA-256は `35038ec919606b003efcb18c65e3f93be0eaefa4e7feeff6d150b7a1ffbb9d74`。

UIと保存：
- 第二弾はサイズ以外の9棚へ9ソースを追加する。
- 第二弾9ソースと40カテゴリは初期closedとし、検索・履歴復元後に強制閉鎖しない。
- 第一弾の一列・横書きCSSクラスを共有し、同じ視覚文法を維持する。
- 新規400 inputは起動時DOMへ置き、日本語検索、出力先検索、選択中、お気に入り、履歴、マイプリセット、リセットから見えるようにする。
- 追加後にチャンネル索引とZERO ASSISTを再同期する。
- 保存は棚経路ではなく安定IDとPositive出力先を用いる。

v4.6現在の10棚基準値：
- おまかせ完成メニュー145。
- 完成料理・地域・世界観616。
- 提供場面・食卓183。
- デザート・トッピング160。
- 飲み物・容器・フレーバー185。
- 食材図鑑306。
- 特化調理工房139。
- 調理・温度・演出76。
- 食べる・飲む動作73。
- サイズ・量・個数20。
- 合計1,903、未分類0。

最低監査：
- 第二弾40カテゴリ、400項目、9群の配分を確認する。
- 完成献立60件が4構成以上の日本語descriptionを持つことを確認する。
- 12文化圏が各10品であることを確認する。
- 第二弾slug、日本語名、正規化prompt、生成IDの一意性を確認する。
- 既存1,503件とのprompt完全重複0、runtime ID衝突0を確認する。
- 食総数1,903、10棚、全ソース34、未分類0を確認する。
- 第二弾完成献立のPositive一回出力、日本語検索、祖先棚open、お気に入り、履歴、マイプリセット、リセットを確認する。
- 第二弾料理＋大盛り、第二弾甘味＋既存トッピング、第二弾飲料＋大容量を確認する。
- 既存食1,083件のID、prompt、役割datasetがbyte相当で維持されることを確認する。
- 未解放2,722、解放2,794、R-18差分72、runtime error 0を確認する。
- Android実機で長い献立説明の折返し、チェック直押し、固定フッター非重複、連打時フリーズなしを確認する。

v4.6確定値：
- 第二弾40カテゴリ、候補400、実追加400、重複prompt 0、ID衝突0。
- 既存食1,083＋第一弾420＋第二弾400＝1,903。
- 第二弾専用テスト13 / 13、全回帰201 / 201、ロック／解放runtime error 0。

### 25.17 水着アカシック・独立特化棚ルール

目的：
- 既存の標準棚「水着・インナー・部屋着」を残したまま、水着だけを深く探せる専門入口を追加する。
- 細かく形を選びたい時と、完成コーデを一押しで決めたい時の両方を一つの棚で支える。
- 一般水着、衣装の汎用改造、R-18衣装を役割ごとに分離し、数を増やしても境界を曖昧にしない。

独立棚にする条件：
- 一般衣装の一カテゴリでは収まらず、完成セット、主要形状、競技用途、文化・幻想派生、専用部品まで一つの選択体験が成立する場合は独立特化棚にする。
- 既存「水着・インナー・部屋着」は定番を素早く探す互換棚として削除・移動・改名しない。
- 新棚は標準10棚の後にある「特化・テーマ衣装」へ置き、R-18専用ゾーンより前で保護する。

現行v4.7「AQUA WARDROBE / 水着アカシックレコード」の配分：
- おまかせ完成水着60。
- ワンピース・モノキニ40。
- ビキニ・セパレート50。
- 競泳・サーフ・機能水着40。
- メンズ・ユニセックス40。
- レトロ・リゾート・文化モチーフ30。
- ファンタジー・SF・特殊水着40。
- 水着専用カスタム40。
- カバーアップ完成コーデ20。
- 9群、36カテゴリ、360項目。
- 完成セット80、単体水着240、水着専用部品40。

完成セットの説明：
- おまかせ60件とカバーアップ20件は、名前だけで内容を推測させない。
- 水着、羽織、足元、小物等の構成4要素以上を日本語descriptionへ入れ、カード上で常時表示する。
- descriptionは検索の補助語として画面に置いてよいが、英語promptへ二重出力しない。
- 完成セットは一項目だけで衣装コーデが成立する。人物、背景、品質、ポーズは含めない。

単体水着と着用者の境界：
- ワンピース、モノキニ、ビキニ、タンキニ、競泳、ラッシュガード、ボードショーツ等は水着の形と構造だけを記述する。
- 人物の年齢、性別、髪、目、肌、体格、国籍、背景、ポーズ、照明をpromptで固定しない。
- 「メンズ・ユニセックス」はユーザーが探すための日本語分類であり、英語promptでは `man`、`male`、`woman`、`female`を使わず、衣服をunisex構造として記述する。
- 文化モチーフは人物属性を固定せず、模様を抽象化した衣装意匠として敬意を持って扱う。

水着専用カスタム：
- 通常の衣装改造工房にある汎用シルエット、素材、装飾、配色を複製しない。
- 水着専用部品は次の4軸に限定し、各10件とする。
  1. ストラップ・ネックライン。
  2. カット・カバー範囲。
  3. 水着素材・表面。
  4. 水辺機能・着こなし。
- 部品promptは `swimsuit`、`swimwear`、`aquatic`、`rash-guard`等の対象語を持ち、水着以外を無差別に変えない。
- 複数選択を許可し、自動解除しない。完成水着カテゴリは1つ推奨と表示するが、意図した混成を禁止しない。

Positive / Negative / R-18境界：
- v4.7の360件はすべて `data-output-channel="positive"`、`data-prompt-intent="normal"` とする。
- `masterpiece`、`best quality`、`16k`、`absurdres`等の汎用品質語を混ぜない。
- 通常水着へ露骨なR-18語、破損・露出限界・拘束等の成人専用改造を混ぜない。
- R-18水着を増やす場合は、通常Aqua Wardrobeへ条件分岐で混在させず、R-18専用ゾーン内に別データ・別UI・別安定IDで作る。
- 未解放時にR-18水着inputを通常検索索引へ存在させない。

安定IDと重複防止：
- データは `builder_data.aqua_wardrobe.v1.js`、UIは `ext_attire_aqua_wardrobe.v1.js` に分ける。
- 安定IDは `attire-aqua-v47-<群>-<カテゴリ>-<slug>` とする。
- 全項目に安定ID、`data-ja`、`data-en`、出力先、用途、Aqua群・カテゴリ・種別を持たせる。
- slug経路、日本語名、正規化prompt、生成IDを360件内で一意にする。
- 実行時は現在DOMの全衣装promptとIDを先に索引化し、完全prompt重複とID衝突を追加しない。
- v4.7データ構造SHA-256は `8b53dafa2e5dce618beaa300f07b51c114a07a10584ebbaa3b1539bc53fc122d`。

読込順と棚保護：
- 読込順は、衣装本体→一般衣装アカシック→アルカディア→通常衣装改造工房→Aquaデータ→Aqua UI→用途別衣装カタログ→通常工房詳細統合→R-18工房とする。
- 用途別カタログの特化selectorと、旧衣装整列のspecial判定の両方へ `.attire-v47-aqua-wardrobe` を登録する。
- 用途別カタログの再整理後も同一input DOMを維持し、checked、listener、ID、保存値を変更しない。
- 特化棚の並びは現行でアルカディア→通常衣装改造工房→Aqua Wardrobe→既存特化群とする。将来変更する場合もAquaを標準10棚やR-18へ混ぜない。

UI：
- 親棚、9群、36カテゴリは初回描画時closedにする。
- 初期closedは初回の既定値であり、検索、選択中移動、履歴復元後まで強制的に閉じ続けない。
- 棚、カテゴリ、カードはデスクトップを含め一列を基本とし、Androidでは必ずflex一列・横書きにする。
- 共通の `details[open] > div` grid指定を専用classで明示的に打ち消す。
- 固定高さを使わず、日本語descriptionと英語promptを自然に複数行折返しする。
- チェック枠の直押しはpreviewや詳細画面に横取りさせず、その場でcheckedを切り替える。
- 完成セット、単体水着、部品をSET / SWIM / PARTバッジで区別する。
- AQUA STATUSは全選択、完成セット、専用部品の件数を表示し、履歴・リセット・カテゴリクリア後に再同期する。

検索・保存・出力：
- 新規360 inputは起動時DOMへ置き、日本語検索、出力先検索、選択中、お気に入り、履歴、マイプリセット、リセットから見えるようにする。
- 追加後にチャンネル検索索引とZERO ASSISTを再同期する。
- 保存と復元は棚経路ではなく安定IDとPositive出力先を使う。
- collectorはAquaでcheckedの項目だけを一回ずつ返し、既存衣装collectorと同じpromptを二重登録しない。
- 全体リセットと衣装棚クリアの対象からAqua inputを外さない。

最低監査：
- 9群、36カテゴリ、360件と群別配分を確認する。
- 完成セット80件が構成4要素以上の日本語descriptionを持つことを確認する。
- 安定ID、slug経路、日本語名、正規化promptの一意性を確認する。
- 既存一般衣装アカシック990、アルカディア144、通常工房100との完全prompt重複0を確認する。
- 人物固定、背景、品質語、R-18語が0であることを確認する。
- 親、9群、36カテゴリの初期closed、一列、横書き、固定高さなしを確認する。
- checkbox直押しで詳細を開かずON/OFFでき、Positiveへ一回だけ出ることを確認する。
- 日本語検索で祖先3段が開くこと、お気に入り、選択中、履歴、マイプリセット、リセットを確認する。
- リセットを2回連続実行し、フリーズせず選択中0へ戻ることを確認する。
- R-18未解放／解放の両方でAquaが通常特化区画、R-18専用ゾーンが最後に残ることを確認する。
- Android実機で長い説明、英語prompt、星、チェック、固定フッターの非重複と連打時フリーズなしを確認する。

v4.7確定値：
- 候補360、9群、36カテゴリ、ID重複0、日本語名重複0、正規化prompt重複0。
- 既存衣装アカシック990＋アルカディア144＋通常工房100との完全prompt重複0。
- Aqua専用テスト17 / 17、全回帰218 / 218、変更JS構文・manifest parse合格。
- v4.0通常衣装5,012を基準にした計算上の通常衣装は5,372。R-18解放時は既存1,299を加えて6,671。最終値は実DOMで再確認する。
- Android実機の最終表示、検索ジャンプ、履歴／マイプリセット復元、リセット連打はユーザー確認待ち。

### 25.18 全分野特化コレクション・OMNI AKASHIC継続増築ルール

目的：
- 衣装・水着・装備・食だけでなく、イラスト制作の主要要素を同じ使い勝手の専門棚で揃える。
- 既存の細分棚を削除・置換せず、「迷った時の完成形」と「深掘りする部品」を独立入口として追加する。
- 大量追加でも、髪・ポーズ・武装・背景・演出・衣装・乗り物の責務を混ぜない。

現行v5.0「SHIMA OMNI AKASHIC」の配分：
- 髪型アカシック：9群、36カテゴリ、360件。完成髪型80、基本髪型240、髪専用状態／仕上げ40。
- ポーズ・行動記録庫：9群、36カテゴリ、360件。完成ポーズ60、通常姿勢260、手・腕部品40。
- 武装アカシック：9群、36カテゴリ、360件。武器本体320、携行／握り／状態調整40。
- 背景・建築アカシック：9群、36カテゴリ、360件。場所本体300、季節／奥行き／密度部品60。
- 魔法・必殺演出工房：8群、30カテゴリ、300件。通常演出210、後付け演出60、フィニッシュ30。
- ドレス・礼装アカシック：8群、24カテゴリ、240件。完成礼装220、礼装専用調整20。
- 鎧・戦闘衣装庫：8群、24カテゴリ、240件。完成防具200、装甲改造／損耗40。
- 乗り物・メカ・騎乗工房：8群、24カテゴリ、240件。乗り物本体190、騎乗具／改造50。
- 合計8コレクション、68群、246カテゴリ、2460件。

カテゴリ責務の境界：
- 髪型は形、結び方、毛束、濡れ、風、髪表面だけを扱う。完成髪型へ髪色、顔、目、肌、性別、年齢、背景、照明、品質を混ぜない。
- ポーズは重心、関節、手、行動、人物間配置だけを扱う。複数人物を前提にする語は「二人・複数人物」群へ限定する。
- 武装は武器本体、盾、術具、携行、表面状態だけを扱う。人物、衣装、戦闘ポーズ、背景を同梱しない。実在メーカー名・固有作品名を使わない。
- 背景は人のいない場所、建築、環境層だけを扱う。人物、群衆、衣装、ポーズを含めず、クイック・シーンより細かく場所を決める棚として説明する。
- 演出は画像に見える炎、水、雷、術式、衝撃、粒子、線、ホログラム等へ分解し、能力名や固有作品名だけで済ませない。
- 礼装と鎧は着用者を固定しない。`girl`、`boy`、`woman`、`man`、`female`、`male`、髪、目、肌、体型を英語promptへ入れない。
- 乗り物は運転者・操縦者・乗客を含めない。動物騎乗具は「鞍／荷車のみ、動物未指定」とし、生物棚と組み合わせる。
- 全系統へ `masterpiece`、`best quality`、解像度、汎用照明等を混ぜず、品質棚の役割を守る。
- 通常OMNIへ露骨なR-18語を混ぜない。成人専用派生が必要ならR-18専用ゾーンへ別データ・別UI・別IDで作る。

完成形と後付け部品：
- 完成形は一項目で対象の基本構成が成立し、日本語descriptionへ構成または用途を常時表示する。
- 部品は元の選択を保ったまま足す一つの役割に絞る。髪状態、手、武器状態、季節、粒子、礼装装飾、装甲損耗、車両改造等を本体と区別する。
- カテゴリの「1つ推奨」は案内であり、意図的な混成を自動解除しない。「複数OK」は重ねる前提とする。
- SET / ITEM / PARTとPositive出力先をカード上で区別する。

データ・安定ID：
- データは `builder_data.omni_akashic.v1.js`、共通UI／collectorは `ext_omni_akashic.v1.js` に分ける。
- 安定IDは `shima-v50-<collection>-<group>-<category>-<slug>` とし、表示名や棚順だけで保存しない。
- 全inputへ `data-ja`、`data-en`、`data-output-channel="positive"`、`data-prompt-intent="normal"`、collection／group／kindを持たせる。
- collection／group／category／slug経路、生成ID、日本語名、正規化promptを全2460件で一意にする。
- v5.0データ構造SHA-256は `9b1c5e4c8a2041939562591e06a22a5477905e3d821aebdf1c6a7e3f052b6f2b`。
- 既存DOMのIDと正規化promptを先に索引化し、完全一致とID衝突は描画せず監査レポートへ残す。

配置と登録：
- `hair`へ髪型、`pose`へポーズ、`background`へ背景、`effect`へ演出を登録する。
- `accessories`へ武装と乗り物を別versionで登録し、collectorと状態を分ける。
- `attire`へ礼装と鎧を別versionで登録し、用途別衣装カタログの特化selectorと旧整列のspecial判定の両方で保護する。
- 同一sectionの複数棚は異なる整数versionを使う。v5.0では礼装／武装を500、鎧／乗り物を501とする。
- 読込順は既存section bundle群→Aqua→OMNIデータ→OMNI UI→衣装用途別カタログ。後から用途別整理されても同一input DOMとcheckedを維持する。

UI・操作：
- 8親棚、68群、246カテゴリを初期closedにする。検索、選択中移動、履歴復元で開いた棚を再び強制closedにしない。
- 親、群、カテゴリ、カードはデスクトップを含めflex一列を基本にし、Androidでは専用classで完全一列・横書きを強制する。
- 案内文、日本語description、英語promptは固定高さを使わず自然に折り返す。
- チェック枠の直押しはpreviewや詳細画面へ横取りせず、changeで状態表示だけを同期する。
- 各棚のSTATUSは選択総数、完成形、後付け部品を表示し、履歴・全体リセット・カテゴリクリア後に再同期する。
- 全inputを日本語検索、出力先検索、選択中、お気に入り、履歴、マイプリセット、リセットの対象にする。追加後はチャンネル索引とZERO ASSISTを一度だけ再同期する。

大量追加時の性能：
- 空検索のPOS／NEG切替では全ラベルを再検索しない既存高速化を維持する。
- mountごとに検索索引を即時全再構築せず、複数棚の追加を短いdebounceで一回へまとめる。
- 同じsectionへ二棚を登録する時、既存prompt索引には先に描画した新棚も含め、二棚間の完全重複を防ぐ。
- 将来件数がさらに増えてAndroid起動時間が悪化した場合は、安定inputを保持したままカード本文だけを遅延描画する。input自体を遅延させて履歴・保存・検索から消してはならない。

最低監査：
- 8コレクション、68群、246カテゴリ、2460件と各棚の配分を確認する。
- 生成ID、経路、日本語名、正規化promptの重複0、空値0、prompt長上限を確認する。
- 髪色／人物属性、背景内人物、礼装／鎧の着用者固定、乗り物の運転者／動物本体、汎用品質、R-18、固有作品名の禁止語監査を行う。
- 親・群・カテゴリinitial closed、スマホ一列、横書き、固定高さなしを確認する。
- checkbox直押し、collector一回出力、STATUS、リセット再同期をDOMで確認する。
- 日本語検索、POS絞り込み、NEG除外、お気に入り、選択中、履歴、マイプリセット、全体リセットを各棚代表1件で確認する。
- 衣装用途別再整理後も礼装・鎧が通常特化区画にあり、R-18専用ゾーンが最後に残ることを確認する。
- Android実機で長い説明、英語prompt、星、チェック、固定フッターの非重複、連続開閉、検索ジャンプ、リセット2回を確認する。

v5.0確定値：
- データ監査：2460件、ID重複0、経路重複0、日本語名重複0、正規化prompt重複0、最大prompt 201文字。
- 専用自動テスト19 / 19、既存を含む全回帰237 / 237、変更JS構文・manifest JSON合格。
- 仮想ブラウザDOM：8棚、68群、246カテゴリ、2460 input、全階層initial closed、直接チェック、8 collector、リセット再同期を確認済み。
- Android実機の最終表示、検索ジャンプ、履歴／マイプリセット復元、固定フッター重なりはユーザー確認待ち。

### 25.19 フェチ・ディテールアカシック通常／成人分離ルール

目的：
- フェチ表現を「露骨さ」だけで扱わず、脚線、手元、素材、着こなし、部位の見せ方、状態、構図へ分解し、通常イラストでも使える衣装ディテールとして整備する。
- 完成衣装を置き換えず、必要な部品だけ後付けできるようにする。
- 通常側と成人専用側をデータ、UI、安定ID、描画条件の四重で分け、検索や保存からの漏出を防ぐ。
- おまかせセットは名称だけで推測させず、内包する部位・衣装・素材・見せ方を日本語descriptionへ常時表示する。

現行v5.1の配分：
- 通常「フェチ・ディテール特化コレクション」：12群、66カテゴリ、660件。
- 通常おまかせ完成セット100、脚線・レッグウェア80、手元・指先60、素材・表面80、着崩し・隙間60。
- 通常うなじ・肩・背中・鎖骨40、眼鏡・仮面・ヴェール40、ベルト・ストラップ・ハーネス40。
- 通常の雨・運動後・雪解け・風40、フェチ構図40、身長差・体格差・硬軟対比40、人外耳・角・尾・翼・機械関節40。
- 成人専用「成人向けフェチ・ディテール工房」：6群、20カテゴリ、200件。
- 成人向け完成セット40、開口・被覆40、艶・透過素材30、着崩れ・損傷30、合意済み装飾ハーネス30、成人向け構図30。
- 合計18群、86カテゴリ、860件。完成セット140、後付け部品720。

通常側の責務：
- 通常側は衣装と視線誘導を扱い、性行為、完全裸、性器、絶頂、強制、拘束行為等の露骨な成人語を入れない。
- レッグウェアは丈、素材、縁、靴との接続を扱い、人物の性別・年齢・外見を固定しない。
- 手元は手袋、指輪、ネイル、袖口、保持手を扱い、人物全体のポーズを置き換えない。
- 素材は既存衣装の形を維持してパネル、縁、袖、胴衣、下衣、小物だけを置換する。
- 着崩しは袖まくり、緩いネクタイ、片肩落とし、開いた外衣、非対称レイヤー、片側タックイン等の非露骨な範囲に限る。
- 部位フォーカスは衣装設計、髪、光、構図でうなじ、肩、背中、鎖骨を見せ、身体特徴を勝手に固定しない。
- ストラップは衣装上の装飾・実用品として扱い、拘束行為を含めない。
- 環境状態は元衣装を保持し、雨、発汗、雪解け、風による表面変化だけを足す。
- 構図は対象部位を見やすくするが、極端なパース、欠損、関節破綻を要求しない。
- 対比は成人人物間の身長・体格、衣装素材・服装系統を扱い、性別や固有キャラを固定しない。
- 人外部品は衣装互換の後付け意匠として耳、尾、角、環、翼、機械関節を扱う。

成人専用側の境界：
- 成人側は `MY_SECRET_UNLOCK === "true"` の時だけR-18専用ゾーン内へ描画する。
- 未解放時は棚をCSSで隠すだけで済ませず、成人input自体をDOMへ生成しない。したがって通常検索、選択中、お気に入り、保存候補へ出さない。
- 成人200件の英語promptはすべて `adult character, consensual` で始める。
- `child`、`minor`、`underage`、`teen`、`schoolgirl`、`schoolboy`、`loli`、`shota`等の未成年語を禁止する。
- 性行為、挿入、絶頂、強姦、強制、非合意を成人ディテール棚へ含めない。衣装設計、素材、着こなし、装飾、構図に限定する。
- 装飾カフ、首輪、ハーネスは合意済みファッション表現とし、`no coercion`を明記する。暴力や拘束行為の状態を要求しない。
- 成人項目もNegative専用へ送らず、Positiveの衣装・演出語として一度だけ出力する。

完成セットと後付け部品：
- 通常100、成人40の全完成セットはdescriptionに `構成：` を含め、最低4構成要素を可視化する。
- SETは一つで方向性が成立する。PARTは元衣装を残し、一つの変更責務だけを追加する。
- 「1つ推奨」は警告の基準であり、自動排他にしない。意図した混成を勝手に解除しない。
- 同じ単一推奨カテゴリを複数選んだ時はSTATUSへ軸重複数を表示する。

データ・安定ID：
- データは `builder_data.fetish_detail_akashic.v1.js`、UIは `ext_fetish_detail_akashic.v1.js` に分ける。
- 通常IDは `shima-v51-fetish-<群>-<カテゴリ>-<slug>`、成人IDは `shima-v51-adult-fetish-<群>-<カテゴリ>-<slug>` とする。
- 通常はattire version 502、成人は503で別collectorとして登録する。
- 全inputへ安定ID、`data-ja`、`data-en`、`data-output-channel="positive"`、`data-prompt-intent="normal"`、group／category／kindを持たせる。
- 成人inputはさらに `data-r18-only="1"` を持たせる。
- 経路、生成ID、日本語名、正規化promptを860件内で一意にする。
- v5.1データ構造SHA-256は `db76c7a6fe9c610db81a60981d422216e6d8ea4f505e9615c4972496fcb16c06`。
- 既存DOMのIDと正規化promptを先に索引化し、完全一致またはID衝突は追加せず監査レポートへ残す。

配置・競合防止：
- 通常棚は衣装用途別カタログの `.shima-v51-fetish-detail` 特化selectorと、旧衣装整列のspecial判定の両方で保護する。
- 通常特化棚の現行順は、少なくとも礼装→鎧→フェチディテールを維持し、R-18専用ゾーンより前へ置く。
- 先行した用途別整理が新棚を `compat-root` として互換棚へ仮分類する場合がある。専用class付与後、仮のcatalog origin／order／group属性だけを外し、同じinput DOMのまま再整理する。
- 再整理のためにcheckboxを複製・再生成せず、checked、listener、ID、履歴・お気に入り参照を保持する。
- 成人棚は用途別カタログへ渡さず、既存NIGHT REMIXの後、R-18専用ゾーン内へ直接置く。

UI・操作：
- 通常1親・12群・66カテゴリ、成人1親・6群・20カテゴリを初回描画時closedにする。
- 初期closedは既定値であり、検索、選択中移動、履歴復元後まで強制的に閉じ続けない。
- 親、群、カテゴリ、カードをデスクトップを含め一列とし、Androidではflex一列・横書きを専用classで強制する。
- 固定高さを使わず、日本語descriptionと英語promptを自然に折り返す。
- checkbox直押しはpreview、詳細、試着画面へ横取りせず、changeでSTATUSだけを同期する。
- 通常は既存OMNIのSTATUSを共有し、成人は選択総数、SET、PART、軸重複を表示する。
- 履歴復元、全体リセット、カテゴリクリア後にSTATUSと検索索引を短いdebounceで再同期する。

検索・保存・出力：
- 通常660 inputは起動時DOMへ置き、日本語検索、出力先検索、選択中、お気に入り、履歴、マイプリセット、リセットへ参加させる。
- 成人200 inputは解放時だけ同じ機能へ参加させ、未解放時は存在させない。
- 保存・復元は棚順ではなく安定IDとPositive出力先を使う。
- 通常と成人は別collectorでchecked項目だけを返し、同じpromptを二重出力しない。
- 空検索のPOS／NEG切替高速化を維持し、860件追加ごとに全検索を多重再実行しない。

最低監査：
- 通常12群66カテゴリ660件、成人6群20カテゴリ200件、合計860件と群別配分を確認する。
- 完成セット140件に `構成：` 説明があり、名称だけの曖昧セットが0であることを確認する。
- 経路、ID、日本語名、正規化promptの重複0、空値0、prompt長上限を確認する。
- 通常側のR-18語、性行為、品質語、固有作品名が0であることを確認する。
- 成人200件が成人・合意を明記し、未成年語、性行為、強制・非合意語が0であることを確認する。
- ロック時に成人棚・成人inputが0、解放時に200 inputがR-18専用ゾーン内だけにあることをDOMで確認する。
- 全階層initial closed、一列、横書き、直接チェック、STATUS、collector、リセット再同期を確認する。
- 衣装再整理後に礼装→鎧→フェチディテールの順、成人棚がR-18境界内にあることを確認する。
- 日本語検索、出力先検索、お気に入り、選択中、履歴、マイプリセット、リセット2回を通常・成人の代表項目で確認する。
- Android実機で長文、構成説明、英語prompt、星、チェック、固定フッターの非重複を確認する。

v5.1確定値：
- データ監査：860件、経路重複0、日本語名重複0、正規化prompt重複0、最大prompt 226文字。
- 専用自動テスト19 / 19、既存を含む全回帰256 / 256、変更JS構文・manifest JSON合格。
- 仮想ブラウザDOMロック時：通常12群、66カテゴリ、660 input、成人0、特化棚順と直接チェック／collector／リセット合格。
- 仮想ブラウザDOM解放時：通常660＋成人6群20カテゴリ200 input、成人棚のR-18専用ゾーン内配置、直接チェック／collector／リセット合格。
- Android実機の最終表示、検索ジャンプ、保存復元、固定フッター重なりはユーザー確認待ち。

### 25.20 成人おまかせ特盛り・テーマ分割ルール

目的：
- 成人向け完成セットを、数だけ増やした長い一群にせず、描きたい方向から短時間で選べるテーマ棚へ分ける。
- 「細部を一つずつ選ぶ」成人後付け部品160件は維持し、サクッと決める完成セットだけを40件から240件へ厚くする。
- R-18未解放時の完全非生成、Positive出力、成人・合意、安全語彙、既存保存IDの互換性を同時に維持する。

v5.2の配分：
- 成人おまかせは5テーマ、24カテゴリ、各カテゴリ10派生、合計240件。
- 夜会・ラウンジ：6カテゴリ60件。
  夜会ドレス・大胆アレンジ、黒レース・カクテル、高級サテン・ラウンジ、カジノ・グラマー、ベルベット仮面舞踏会、着崩れ礼装。
- 光沢・レース・脚線：6カテゴリ60件。
  光沢ハーネス衣装、シアーヴェール・ストッキング、コルセット・ガーター、ボディストッキング・レイヤー、濡れ光沢・雨夜、レザーライダー・夜走り。
- 職業・ステージ：4カテゴリ40件。
  深夜エグゼクティブ、キャバレー舞台、大人の舞台魔術師、成人クラシックメイド。
- 幻想・人外：4カテゴリ40件。
  成人デーモン夜装、吸血鬼貴族・夜宴、月夜の成人魔女、猫系ナイトライフ。
- SF・サイバー：4カテゴリ40件。
  サイバーボディスーツ、アンドロイド継ぎ目ドレス、ホログラムラウンジ、成人ステルス潜入。
- 各カテゴリは漆黒、象牙白、深紅、紫紺、古金、月銀、薄手、高光沢、レース、虹彩の10派生を同じ順で持つ。
- 後付け部品は開口40、艶・透過素材30、着崩れ・損傷30、合意済み装飾ハーネス30、成人向け構図30の合計160件を維持する。
- 成人専用全体は10群、40カテゴリ、400件。通常660件と合わせて22群、106カテゴリ、1060件。
- 完成セットは通常100＋成人240＝340件、後付け部品は通常560＋成人160＝720件。

完成セットの責務：
- 一つのチェックだけで、衣装本体、脚衣または靴、装飾、素材または見せ方まで方向性が成立するようにする。
- 全240件の日本語descriptionに `構成：` を含め、最低4要素を常時見せる。
- セット名だけで人物像や用途を推測させない。夜会、仕事、舞台、幻想、SFのどこへ向かうかが名称とテーマ名で判断できるようにする。
- 人物の固有名、既存作品名、背景、汎用品質語を固定しない。別の人物設定、背景、品質セットと組み合わせ可能にする。
- おまかせは各カテゴリ1つ推奨とするが、複数選択を勝手に解除しない。意図的な混成は維持し、STATUSで軸重複だけを警告する。

成人・合意と出力境界：
- 成人400件はすべて英語promptを `adult character, consensual` で始める。
- 未成年語、性行為、挿入、絶頂、強姦、強制、非合意を含めない。衣装、素材、装飾、着こなし、構図に限定する。
- 成人おまかせもNegative専用語ではなく、成人衣装を成立させるPositive表現として出力する。
- `MY_SECRET_UNLOCK !== "true"` の時は、成人棚をCSSで隠すだけにせず400 inputをDOMへ生成しない。
- 解放時だけ既存 `#__attire_r18_last_zone__` 内へ描画し、通常特化棚、通常検索、通常保存候補へ漏らさない。

テーマ分割と安定ID：
- データ上の群keyは `quick-night`、`quick-material`、`quick-role`、`quick-fantasy`、`quick-sf` とし、UIで5テーマを明確に分ける。
- v5.1に存在した夜会ドレス・大胆アレンジ、光沢ハーネス衣装、シアーヴェール・ストッキング、着崩れ礼装の4カテゴリ40件は、旧群key `quick` をinput IDと `data-fetish-id` にだけ維持する。
- 旧ID例は `shima-v51-adult-fetish-quick-evening-reveal-black`。テーマ分割を理由に既存40件のIDを変更しない。
- 新規200件は新テーマ群keyをIDへ使う。例は `shima-v51-adult-fetish-quick-night-lace-cocktail-black`。
- 実input ID、経路、日本語名、正規化promptを全1060件で一意にする。
- 保存、履歴、お気に入り、マイプリセットは表示順やテーマ名ではなく安定input IDで復元する。

UI・操作：
- 成人親棚、10群、40カテゴリは初期closed。検索や選択中移動で開いた後まで強制的に閉じ戻さない。
- テーマ、カテゴリ、カードはデスクトップとAndroidの両方で一列・横書きとし、固定高さを使わない。
- カードへ日本語名、内包構成、英語prompt、SET／PART・R-18・POSバッジを表示する。
- checkbox直押しはdetails、preview、詳細画面を開閉せず、その場でcheckedとSTATUSだけを更新する。
- 検索、お気に入り、選択中、履歴、マイプリセット、カテゴリクリア、全体リセット後は索引とSTATUSを短いdebounceで再同期する。

最低監査：
- 成人おまかせのテーマ件数が60／60／40／40／40、24カテゴリ240件であることを確認する。
- 成人全体が10群40カテゴリ400件、通常と合計1060件、完成セット340、後付け720であることを確認する。
- 全340完成セットに `構成：` があり、各成人カテゴリが10派生を持つことを確認する。
- 成人400件が成人・合意を明記し、未成年語、性行為、強制・非合意語が0であることを確認する。
- 旧40件の4代表IDがv5.1と一致し、新規IDを含め重複0であることを確認する。
- ロック時に成人棚・成人inputが0、解放時に400 inputがR-18専用ゾーン内だけにあることをDOMで確認する。
- 解放DOMで10群40カテゴリ、完成セット240、全階層initial closed、チェック直押し、複数選択警告、collector、リセット再同期を確認する。
- Android実機でテーマ名、構成説明、長い日本語名、英語prompt、星、チェック、固定フッターが重ならないことを確認する。

v5.2確定値：
- データ監査：1060件、22群、106カテゴリ、完成セット340、後付け部品720。
- 経路重複0、日本語名重複0、正規化prompt重複0、実input ID重複0、最大prompt 239文字。
- データ構造SHA-256：`16c5c8ab312ed2a1eb8a4ff16496af58583f417cedbbf194679d4240b46c4f68`。
- 専用自動テスト20 / 20、既存を含む全回帰257 / 257、変更JS構文・manifest JSON合格。
- 仮想ブラウザDOMロック時：通常660 input、成人0、登録APIと通常collector合格。
- 仮想ブラウザDOM解放時：通常660＋成人400 input、10群40カテゴリ、完成セット240、旧40件ID維持、R-18専用ゾーン内配置、直接チェック／軸重複／collector／リセット合格。
- Android実機の最終表示、検索ジャンプ、保存復元、固定フッター重なりはユーザー確認待ち。

### 25.21 成人おまかせ限界突破・幅広い衣装テーマ規約

目的：
- 成人おまかせを特定の夜会・艶素材へ偏らせず、日常モチーフ、競技、リゾート、文化礼装、神性、悪魔、寝室礼装、職業、神話種族まで横断する。
- ユーザーが細部を一つずつ選ばなくても、一つのセットで衣装本体、脚衣・靴、装飾、素材・見せ方が成立するようにする。
- 学生服、体操服等の年齢誤認が起こり得る衣装は、成人コスチュームであることを表示名、説明、英語promptで三重に固定する。
- 成人専用の厳密境界と、v5.2までの保存データを壊さないことを、追加量より優先する。

v5.3の追加配分：
- 10テーマ、各6カテゴリ、各カテゴリ10派生、合計600完成セットを追加する。
- 成人学園風・学生服：成人向け学生服風ブレザー、成人向けセーラー襟制服風、成人キャンパスカーディガン、成人アカデミー評議会、成人卒業式セレモニー、成人芸術学院制作服。
- 成人体操服・レオタード：成人向け体操服トレーニング、成人体操レオタード、成人新体操リボン、成人バレエ練習レオタード、成人フィギュアスケート衣装、成人レトロエアロビクス。
- 成人水着・リゾート：成人グラマラスビキニ、成人プールサイドモノキニ、成人競泳スタイル水着、成人レトロピンナップ水着、成人トロピカルカバーアップ、成人ナイトビーチウェットスーツ。
- ドレス・ガウン：リトルブラックドレス夜装、マーメイドラインガウン、背中開きコラムドレス、王道プリンセス舞踏会、成人ブライダル祝宴ドレス、レッドカーペット非対称ドレス。
- チャイナドレス・文化礼装：成人チャイナドレス祝宴、成人モダンチャイナドレスラウンジ、成人着物夜会アレンジ、成人漢服天上舞台、成人アオザイ夜庭、成人サリーガラ。
- 美の女神・神性：美の女神神殿礼装、海の女神真珠潮流、月の女神銀夜、暁の女神朝焼け、宝石の女神結晶礼装、翼ある勝利の女神。
- 淫欲の悪魔・誘惑魔：淫欲の悪魔深紅夜宴、成人サキュバス月夜、煉獄公爵夫人礼装、夢魔薄明ヴェール、深紅の契約悪魔正装、堕天の誘惑者黒翼。
- ランジェリー・寝室礼装：サテンキャミソールナイト、レーステディジュエル、コルセットローブ、成人ブライダルランジェリー、高級ナイトウェアラウンジ、ガーターブドワール。
- 成人制服・サービス職：成人カジノディーラー制服、成人カクテルバーテンダー、成人キャビンクルー風、成人メディカルクチュール、成人パトロールファッション制服、成人士官ガラ制服。
- 神話種族・異世界女王：成人エルフ女王森冠、成人竜皇后鱗甲、成人海妖セイレーン、成人狐霊月宴、成人闇司祭儀式、成人星界託宣者。
- 各カテゴリは漆黒、象牙白、深紅、紫紺、古金、月銀、薄手、高光沢、レース、虹彩の10派生を同じ順で持つ。

累計配分：
- v5.2の5テーマ240件と合わせ、成人おまかせは15テーマ、84カテゴリ、840件。
- 後付け部品160件は変更せず、成人専用全体を20群、100カテゴリ、1000件とする。
- 通常12群66カテゴリ660件と合わせ、全体は32群、166カテゴリ、1660件。
- 完成セットは通常100＋成人840＝940件、後付け部品は通常560＋成人160＝720件。

成人学園風・競技衣装の安全規約：
- 学生服・体操服・レオタードの人物は必ず `adult character` とし、説明にも成人向け衣装であることを明記する。
- `child`、`children`、`minor`、`underage`、`teen`、`schoolgirl`、`schoolboy`、`loli`、`shota`を禁止する。
- 成人学園風の英語promptでは `mature academy-inspired` または `adult graduation` 等を使い、年齢を曖昧にしない。
- 競技衣装は体操、新体操、バレエ、フィギュアスケート、エアロビクスの衣装構造を扱い、性的行為や強制場面を加えない。
- 別棚の人物設定と組み合わせる場合も成人設定を維持するよう、適用ガイドへ明記する。

文化礼装の規約：
- チャイナドレス、着物、漢服、アオザイ、サリーは、文化衣装の構造、布、帯、ドレープ、装飾を尊重する。
- 文化そのものを性的属性として扱わず、成人の祝宴、舞台、夜会向け衣装として説明する。
- 固有人物名、作品名、民族の人格的ステレオタイプ、背景、品質語をpromptへ固定しない。

神性・悪魔・寝室礼装の境界：
- 美の女神、淫欲の悪魔、サキュバス、夢魔は衣装意匠として表現し、性行為、挿入、絶頂、強姦、強制、非合意を含めない。
- 成人1,000件はすべて `adult character, consensual` で始める。
- ランジェリーは衣装本体、ローブ、ストッキング、宝飾、履物の組み合わせとして扱い、行為や相手を要求しない。
- 成人おまかせはすべてPositiveの衣装表現であり、Negative専用棚へ送らない。

構成説明：
- 新規600件を含む全940完成セットはdescriptionに `構成：` を持つ。
- 各セットは最低4要素を日本語で表示し、名称だけで内容を推測させない。
- 10色・質感派生を選んでも、セット内の4要素が保持される。
- 一つ推奨カテゴリの複数選択は自動解除せず、STATUSの軸重複警告だけで知らせる。

安定ID・非破壊継承：
- v5.2成人群 `quick-night`、`quick-material`、`quick-role`、`quick-fantasy`、`quick-sf`、`exposure`、`material`、`disarray`、`restraint`、`framing` のデータ構造を変更しない。
- v5.2成人400件の継承構造SHA-256は `733e843f6115afc8042d8bb386748b126bb8c09d6114f2dfe0bfe6cc92d73d44` とする。
- v5.1由来4カテゴリ40件の旧群key `quick` によるinput IDも維持する。
- 新規群keyは `quick-academy`、`quick-athletic`、`quick-swim`、`quick-dress`、`quick-cultural`、`quick-divine`、`quick-demon`、`quick-boudoir`、`quick-service`、`quick-mythic` とする。
- 新規input IDは `shima-v51-adult-fetish-<新規群>-<カテゴリ>-<派生>` とし、既存IDと重複させない。
- 履歴、お気に入り、マイプリセット、選択中は棚順や表示名でなく安定input IDから復元する。

UI・R-18境界：
- `MY_SECRET_UNLOCK !== "true"` の時は成人棚をCSSで隠すだけにせず、成人1000 inputをDOMへ生成しない。
- 解放時だけ既存 `#__attire_r18_last_zone__` 内へ描画し、通常特化棚へ混ぜない。
- 成人親棚、20群、100カテゴリを初期closedにし、デスクトップとAndroidの両方で一列・横書きとする。
- 固定高さを使わず、長い日本語名、構成説明、英語promptを自然に折り返す。
- checkbox直押しはdetails、preview、詳細画面を開閉せず、checkedとSTATUSだけを同期する。
- 検索、出力先検索、お気に入り、選択中、履歴、マイプリセット、カテゴリクリア、リセット後の索引同期を維持する。

最低監査：
- 新規10テーマが各6カテゴリ60件、合計60カテゴリ600件であることを確認する。
- 成人おまかせ15テーマ84カテゴリ840件、成人全体20群100カテゴリ1000件、全体1660件であることを確認する。
- 完成セット940、後付け720、全完成セットの `構成：` 説明を確認する。
- 経路、日本語名、正規化prompt、実input ID重複0、空値0、最大prompt長を確認する。
- 成人1000件の成人・合意接頭辞、未成年語0、性行為・強制・非合意語0を確認する。
- v5.2成人400件の継承SHA-256と、解放DOM上の全400 IDが一致することを確認する。
- ロックDOMで成人0、解放DOMで成人1000、20群100カテゴリ840 SET、R-18専用ゾーン内配置を確認する。
- 代表として学生服、レオタード、水着、チャイナドレス、美の女神、淫欲の悪魔の新規IDを確認する。
- 全階層initial closed、直接チェック、軸重複警告、collector、リセット再同期を確認する。
- Android実機で1000件追加後の検索体感、長文折返し、星・チェック・固定フッター非重複、リセット2回を確認する。

v5.3確定値：
- データ監査：1660件、32群、166カテゴリ、完成セット940、後付け部品720。
- 成人おまかせ15テーマ84カテゴリ840件、成人専用計1000件。
- 経路重複0、日本語名重複0、正規化prompt重複0、実input ID重複0、最大prompt 239文字。
- 全データ構造SHA-256：`1ec2659b1a4314c9abf5a390a64534d3f1620306d2bcbed33d409ca47aeb4254`。
- v5.2成人400件継承SHA-256：`733e843f6115afc8042d8bb386748b126bb8c09d6114f2dfe0bfe6cc92d73d44`。
- 専用自動テスト20 / 20、既存を含む全回帰257 / 257、変更JS構文・manifest JSON合格。
- 仮想ブラウザDOMロック時：通常660 input、成人0、登録APIと通常collector合格。
- 仮想ブラウザDOM解放時：通常660＋成人1000 input、20群100カテゴリ、完成セット840、v5.2既存400 ID全件維持、R-18専用ゾーン内配置、直接チェック／軸重複／collector／リセット合格。
- Android実機の最終表示、1000件追加後の検索体感、保存復元、固定フッター重なりはユーザー確認待ち。

### 25.22 成人15テーマ・スタートデッキと遅延カード描画規約

目的：
- 成人おまかせ840件を細部棚から順に探させず、15テーマから最初の方向を決められる入口を置く。
- 1000件の安定input IDと保存互換を維持したまま、スマホ起動時に1000枚の重いカード本文を生成しない。
- 検索、選択中、お気に入り、履歴、マイプリセット、collector、リセットを、未描画inputでも従来どおり成立させる。

スタートデッキ：
- 成人親棚の案内直後へ `ADULT START DECK / 入口` と「今日はどの大人衣装？」を置く。
- 対象は `quick-` で始まる15テーマだけとし、後付け部品5群を入口へ混ぜない。
- テーマボタンはデスクトップ・Androidとも必ず一列。テーマ名、用途説明、内包セット数、現在の選択数を表示する。
- ボタン操作は成人親棚と対象テーマ群を開いて移動・強調するだけとし、checkboxを勝手にON/OFFしない。
- 選択数は各テーマ群内のchecked inputから毎回算出する。未選択は「未選択」、選択後は「n選択」と表示する。
- 親棚、20群、100カテゴリの初期closed規約は維持する。入口を置くために成人棚を起動時展開しない。

安定input先置き・カード遅延描画：
- R-18未解放時は従来どおり成人inputを0件とする。解放時だけ1000 inputをR-18専用ゾーンへ作る。
- 解放時には1000 inputすべてへ従来と同じID、prompt、表示名、出力先、group、category、kindを付けてDOMへ先置きする。
- 未描画inputは `hidden`、`aria-hidden=true`、`data-adult-fetish-pending=1` とし、カテゴリ内に保持する。別の仮IDや複製inputを作らない。
- カード化時は同じinput DOMをlabelへ移動する。inputを再生成せず、checked、listener、ID、履歴・お気に入り・保存参照を維持する。
- カテゴリを開いた時だけ、そのカテゴリ10件をまとめてカード化する。一件だけ見つかった検索でもカテゴリ単位で描画し、表示の整合を保つ。
- 全件描画APIは保守・監査用に持ってよいが、通常の起動、空検索、POS/NEG切替では呼ばない。

検索・選択中・お気に入り・履歴：
- 本体文字検索のcapture段階で、入力語が日本語名、英語prompt、説明のいずれかへ一致する未描画カテゴリだけを先にカード化する。
- 空文字では成人カテゴリをカード化しない。出力先フィルターの切替だけで1000枚を生成しない。
- 選択中フィルターへ移動する直前に、checkedかつ未描画のinputを含むカテゴリをカード化する。
- お気に入りフィルターへ移動する直前に、保存キーの `|id:<stable-id>` から対象inputを引き、該当カテゴリだけをカード化する。
- 選択中チップ等のジャンプは安定IDから対象inputを確定し、ジャンプ前に同じinputをカード化する。
- 履歴・マイプリセットの復元処理は未描画inputのcheckedを直接復元できること。表示が必要になった段階でカード化する。
- カード化後は検索索引とZero Assistを短いdebounceで更新し、古い索引を残さない。

出力・状態同期：
- 成人collectorはattire version 504として登録し、描画済み・未描画を問わず `input.shima-v51-adult-fetish-checkbox:checked` だけをPositiveへ返す。
- STATUS、テーマ別選択数、軸重複警告はinputのcheckedから算出し、カード数を選択数として使わない。
- 全体リセット、カテゴリクリア、履歴復元後も未描画inputを対象に再同期する。
- materializedとpendingの監査値は `materialized + pending = added` を常に満たす。

最低監査：
- ロックDOM：通常660 input、成人input 0、通常502・成人504の登録APIが存在すること。
- 解放直後：成人1000 input、20群、100カテゴリ、完成セット840、入口15、成人カード0、pending 1000であること。
- 入口ボタンを押してもchecked 0のまま、対象群だけが開くこと。
- 1カテゴリの明示描画後もinput総数1000、安定ID1000、カード10、pending 990であること。
- 日本語検索で一致カテゴリ、選択中でcheckedカテゴリ、お気に入りで保存IDのカテゴリだけが描画されること。
- v5.2成人400件の安定IDが全件残り、通常／成人collector、直接チェック、軸重複警告、リセットが成立すること。
- Android実機で入口15件の一列表示、スクロール移動、検索体感、固定フッターとの非重複を確認する。

v5.4確定値：
- データ件数と構造SHA-256はv5.3から不変。成人1000、通常660、全1660、全構造 `1ec2659b1a4314c9abf5a390a64534d3f1620306d2bcbed33d409ca47aeb4254`。
- UI/API version 1.3.0、成人collector version 504。
- 専用自動テスト22 / 22、既存を含む全回帰259 / 259、変更JS構文・manifest JSON合格。
- 仮想ブラウザDOM解放直後：入口15、input 1000、初期カード0、pending 1000。
- カテゴリ展開、検索、選択中、お気に入りの実操作後：materialized 40、pending 960、input 1000、v5.2既存400 ID全件維持。
- Android実機の最終表示、体感速度、固定フッター重なりはユーザー確認待ち。

### 25.23 衣装棚の深度順統制・湯浴み／追加衣装の用途統合規約

目的：
- 衣装棚の先頭をリリース時期や新着都合で奪わず、初見時は必ず日常・平時から始める。
- 下へ進むほど、公的役割、文化・私生活、非日常、専門特化、創作技術、改造、成人向けへ深くする。
- 追加時期だけを理由に複数系統の衣装を一箱へ束ねない。項目は本来の用途系統へ帰属させる。
- 既存input、安定ID、prompt、checked状態、履歴、お気に入り、マイプリセットをDOM移動だけで維持する。

確定する棚順：
1. `01 平時・日常`：日常・ベーシック → 完成コーデ・おまかせ。
2. `02 社会・公的`：制服・仕事・スポーツ → 正装・舞台・イベント。
3. `03 文化・余暇・私生活`：伝統・民族・歴史 → サブカル・年代・トレンド → 水着・室内・湯上がり。
4. `04 非日常・世界観`：ファンタジー・戦闘 → SF・サイバー・特殊。
5. `05 専門・特化コレクション`：礼装、水着、中華、アイドル等。
6. `06 創作・幻想技術`：シマエナガ、アルカディア、鎧、モチーフ融合、機械衣装等。
7. `07 改造・ディテール`：形・柄・色・着こなし、通常衣装改造工房、通常フェチディテール、互換未分類。
8. `08 R-18専用衣装`：解放時だけ最深部に表示。

順序ルール：
- 最初の選択可能な親棚は `日常・ベーシック` とする。完成セットは便利でも日常より前へ置かない。
- 水着・インナー・部屋着は `水着・室内・湯上がり` へ改称し、湯浴み・スパを同じ私生活系統に収める。
- 標準棚、専門特化、創作特化、改造特化を一括の「特化・テーマ衣装」へ混ぜない。
- 特化棚は `SPECIAL_STAGES` で focused / creative / craft に分け、同一段階内も明示したselector順で並べる。
- R-18ゾーンは通常の分類対象・fallback対象にせず、存在する時は必ず最後にappendする。
- 親棚と子棚は初期closed、Androidでは一列・横書きを維持する。

湯浴み・追加25件の用途統合：
- 旧 `.attire-v55-bath-discovery` の親箱は最終UIへ残さない。中の9カテゴリを既存DOMのまま取り出し、親箱だけを削除する。
- `bath-rediscovery` と `bath-wave1` は swim。
- `special-protective`、`special-sports`、`medical-patient-wear` は role。
- `historical-indoor` と `world-ceremonial` は traditional。
- `experimental-material` は subculture。
- `space-systems` は sf。
- 分配後もカテゴリは `.attire-v55-category`、カードは `.attire-v55-bath-checkbox` を維持する。
- 再整理時は `data-attire-catalog-integrated="v1"` を持つカテゴリへ通常classifyを再適用しない。これを忘れるとfallbackへ戻る。

データと互換性：
- データは25件・2群・9カテゴリ、再発見7、追加18のまま。安定IDは `attire-bath-v55-<群>-<カテゴリ>-<slug>` を変更しない。
- 配置変更のためにgroup key、category key、slug、英語promptを変更しない。
- 表示用の親タイトル、カテゴリタイトル、案内文は用途中心へ改めてよい。
- 全件Positive通常、人物属性・背景・照明・汎用品質・R-18表現を固定しない。
- 旧バスローブ、バスタオル、旅館浴衣等の既存入力を削除せず、再発見完成コーデも完全prompt複製にしない。

最低監査：
- 日常→完成コーデ→役割→正装→伝統→サブカル→水着・湯上がり→幻想→SFの順を確認する。
- stageが everyday / public / culture / world / focused / creative / craft、解放時は最後に adult となることを確認する。
- `.attire-v55-bath-discovery` 親が最終DOMに残らず、統合カテゴリ9、bath input 25を維持することを確認する。
- 9カテゴリそれぞれのclosest親グループが上記routeと一致することを確認する。
- 同じorganizeを再実行してもstage重複0、input増減0、checked状態維持、R-18末尾を確認する。
- 検索、お気に入り、選択中、履歴、マイプリセット、リセット、Positive collectorを確認する。
- Android実機で先頭が日常、全段階が一列、長い文字が縦書き化しないことを確認する。

v5.6確定値：
- 配布名：`SHIMA ATTIRE DEPTH TAXONOMY v5.6`。
- カタログ登録version 34、UI API 1.2.0、湯浴みデータ／UI 1.1.0。
- データ：25件、2群、9カテゴリ、再発見7、追加18。データ構造SHA-256：`84e1774eab1b14aaa993f9e5bb6a29db565c17b4f8c0c573c29a5e54b3e48ec6`。
- 全回帰283 / 283、変更JavaScript構文・manifest JSON合格。
- 単体仮想DOM：8段階、統合9カテゴリ、25 input、再整理後checked維持、R-18末尾。
- 全体仮想DOM：86スクリプト読込成功、失敗0。通常モード7段階、標準10棚、統合9カテゴリ、25 input、再整理後checked維持。
- Android実機の最終表示順、検索ジャンプ、履歴・マイプリセット復元はユーザー確認待ち。

### 25.24 Android初回起動・補助UI完了待機・三表示自己修復規約

症状：
- 初回読み込み時だけ固定下部の `棚`、`選択中`、`出力` が出ないことがあり、リロードすると表示される。
- 本体ログは成功・失敗0・UI mount開始まで到達していても、補助UIだけ欠落する。
- 読み込み本数や項目数が多いAndroidほど再現しやすい。

確定原因：
- `ext_zero_assist.v1.js` はDOM準備前から180ms間隔で再試行するが、旧実装は100回超、約18秒で終了していた。
- `ext_shima_navigation.v1.js` も120回超、約22秒で終了していた。
- マニフェストは非同期で84本を順次読み、約3.3万項目を組み上げる。初回だけ準備が上限を超えると、後から `#ui-search-bar` が生成されても再試行者が残っていない。
- リロードではブラウザキャッシュにより準備が上限内へ収まるため、一見直ったように見える。

起動契約：
- マニフェスト完了後、`window.__triggerUIMount()` の直後に `builder:mounted` を明示送出する。
- ZERO Assistとシマナビは、推測時間ではなく実DOMの存在を成功条件にする。
- 起動待機は `builder:mounted`、`promptPartMounted`、`pageshow`、対象DOMのMutationObserverで再開する。
- 保険のタイマーは1.2秒の低頻度とし、成功するまで固定回数で打ち切らない。成功時はタイマーと起動待ちObserverを必ず解除する。
- 大規模DOM全体を常時監視しない。起動前は `#sections` の直下、ナビ保全は `#mini-ui-fixed` の子孫だけを監視する。

mounted確定と再水和：
- `state.mounted = true` は、必要要素を作り終えた後にだけ設定する。処理開始時に先行設定しない。
- スマホの脱出経路である三表示ナビを最優先で作る。
- create関数は既存要素があれば参照を再取得し、二重生成しない。部分生成から再試行しても同じIDを一つだけ維持する。
- document全体のclick/changeリスナーは `eventsBound` で一度だけ登録する。
- 初期化例外時はmountedをfalseへ戻し、次の完了通知・DOM変化・保険再試行で回復できるようにする。

三表示ナビの保全：
- ZERO Assistは `棚` と `出力`、シマナビはその間の `選択中` を確実にそろえる。
- 必須IDは `zero-mobile-view-switch`、`shima-mobile-selected-view`、`zero-mobile-selection-count`、`shima-mobile-selected-count`。
- `#mini-ui-fixed` 内でナビ本体または必須ボタンが失われた時は、既存要素を再利用しながら不足分だけ作り直す。
- ZERO Assist側の復旧後は `zeroAssistMobileSwitchReady` を送出し、シマナビに `選択中` の再挿入を促す。
- 復旧はchecked、出力本文、mobileView保存値、履歴、マイプリセットを変更しない。

最低監査：
- JavaScript構文とmanifest JSONを確認する。
- 起動ガードの専用テストで、完了通知、固定上限廃止、mounted確定順、DOM監視、三表示、既存UI再利用、イベント重複防止を検査する。
- 仮想DOMで本体準備を20秒以上遅らせ、旧版は補助UIなし、新版はZERO Assist・シマナビ・三表示・toolbar・trayが全て生成されることを確認する。
- 初期化成功後に `#zero-mobile-view-switch` をDOMから削除し、短時間で `shelf / selected / output` の順へ自動復旧することを確認する。
- Android実機ではキャッシュ消去相当の初回起動を一度行い、リロードせず読込完了を待って三表示を確認する。
- 三表示を各1回切り替え、棚、選択中一覧、Positive/Negative出力が従来どおりであることを確認する。

v5.5.1確定値：
- 配布名：`SHIMA UI BOOT GUARD v5.5.1`。
- 変更ランタイム：`ext_manifest_loader.v1.js`、`ext_zero_assist.v1.js`、`ext_shima_navigation.v1.js`。
- ZERO Assist / Shima Navigation UI API version：`1.2.0`。
- 起動ガード専用7 / 7、既存を含む全回帰281 / 281。
- 20.5秒遅延：旧版はZERO Assist false・シマナビ false・ナビ0、新版は両API true・`shelf / selected / output` 3表示。
- ナビ全削除試験：`shelf / selected / output` 3表示へ自動復旧、エラー0。
- Android実機のキャッシュなし初回起動はユーザー確認待ち。

### 25.25 食材状態カスタマイズ・対象連動・食材拡張規約

目的：
- 食材名だけで終わらせず、「丸ごと／切り身」「焼く／蒸す」「皿／串／氷」「添え物」「表面」「温度」まで一つの食べ物へ連動して決められるようにする。
- 迷わず一発で決める完成状態セットと、必要な時だけ使う細分軸を同じ工房に置く。
- 状態語だけが食べ物なしでPositiveへ流れる事故、完成料理を未調理へ上書きする事故、対象Aの状態が対象Bへ漏れる事故を防ぐ。

食材追加：
- v5.7は6カテゴリ各16件、計96件を追加する。
- `鮮魚・切り身`、`カニ・海老・甲殻類`、`貝・軟体・魚卵・珍味`、`精肉・加工肉`、`基本調味料・粉・油・和素材`の80件は食材図鑑へ置く。
- `焼き魚・干物`16件は特化調理工房へ置く。
- 全件を通常Positive、安定ID `food-akashic-v57-<group>-<category>-<slug>` とする。
- 人物、背景、照明、汎用品質、R-18を固定せず、既存1,903件と完全prompt重複させない。
- 各項目は `foodStateProfile` を持ち、魚、蟹、大型海老、海老、貝、魚卵、肉、調味料、完成魚の用途を明示する。

食の棚順：
- 食のアカシックは11棚、総prompt input 1,999件とする。
- 順番は、完成メニュー → 完成料理 → 提供場面 → デザート → 飲み物 → 食材 → 特化調理 → 食材状態カスタマイズ → 演出 → 動作 → サイズ。
- 状態工房は特化調理の直後へ置く。状態を料理本体より先へ置かない。
- 状態工房はprompt checkboxを持たないため、件数バッジは0ではなく `7軸` と表示する。
- 親棚、11棚、状態工房、各軸は初期closed。Androidでは一列・横書き、固定高さなしを維持する。

対象連動契約：
- 状態工房は食材または料理のchecked inputを適用先として使う。対象未選択時は操作を待機させる。
- 状態ボタンはcheckboxとして登録せず、状態工房の `getTags()` は常に空配列を返す。
- 状態を単独タグとしてcollectorへ渡してはならない。
- 選択対象の元promptを `data-food-state-base-en` に保存し、7軸設定から合成した結果だけを同じinputの `data-en` へ書く。
- 既存accessories collectorは変更せず、checkedになった対象食材を一度だけPositiveへ出す。
- 対象をuncheckedにすると合成promptも出力されない。再選択のため対象別設定は保持してよい。
- 全体リセットは全対象の状態を空にし、`data-en` を元promptへ戻す。
- カテゴリクリアは、そのカテゴリで解除された対象の状態を元へ戻す。
- 状態変更後は本体検索索引とZero Assistを更新する。

用途互換：
- 各状態候補は `profiles` を持ち、現在対象の用途と一致する候補だけを表示・適用する。
- 魚へ殻開き、肉へ魚卵の濃厚感、調味料へ串焼き等の非互換候補を出さない。
- `prepared-fish` は魚候補を一部共有してよいが、形・下処理と調理・保存を固定する。
- 一般の完成料理も形・調理を固定し、器・盛り方・添え物・質感・温度だけを追加可能とする。
- プリセット内に非互換候補があっても、その軸だけ静かに除外し、他の互換軸を適用する。

7軸：
1. `form` 形・下処理：単一選択。
2. `cooking` 調理・保存：単一選択。
3. `vessel` 器・支持体：単一選択。
4. `arrangement` 盛り方・配置：単一選択。
5. `garnish` 薬味・添え物：複数選択。
6. `texture` 表面・質感：複数選択。
7. `temperature` 温度・鮮度：単一選択。

一発プリセット：
- 和の焼き魚皿。
- 炉端の串焼き。
- 港の鮮魚氷台。
- 刺身の和皿。
- 蟹のごちそう盛り。
- ウニの木箱。
- 浜焼き。
- 海鮮・食材の贈答箱。
- プリセット名だけで迷わせず、器、配置、添え物、質感、温度等の内容を日本語で常時説明する。

カードと移動：
- v5.7追加96カードはチェック領域と `状態調整` ボタンを分離する。
- checkbox直押しは従来どおり選択だけを切り替え、詳細画面や状態工房へ横取りしない。
- `状態調整` は対象を未選択なら選択し、適用先へ指定し、検索・選択中・お気に入り絞り込みを解除して状態工房へ移動する。
- 移動時に文字検索が残って状態棚が空白化しないよう、検索語を解除してから親棚・状態棚・工房を開く。
- 複数の食材がcheckedなら適用先selectorで切り替え、設定を対象ごとに独立保持する。
- 適用後の英語promptはreadonlyプレビューで常時確認できるようにする。

履歴・マイプリセット：
- 保存対象へ `foodStateConfig`、`foodStateBaseEn`、`foodStateProfile`、`foodStateLockedAxes` を追加する。
- 復元開始時は現在の全食材状態を静かに解除し、元promptへ戻してからinputを解決する。
- 対象inputを解決した後、checkedにする前に保存済み状態を復元・再合成する。
- 保存済みの合成済み `data-en` だけへ依存しない。元promptと軸設定を正とする。
- 旧履歴・旧マイプリセットに状態フィールドがない場合は、従来どおり元promptの選択として復元する。

最低監査：
- データ6カテゴリ、96件、食材80、完成焼き魚16、7軸、8プリセットであること。
- 追加96件内のslug、日本語名、正規化promptが一意で、既存1,903件との完全prompt重複が0であること。
- 食の親棚11、input 1,999、食材386、特化調理155、状態棚バッジ7軸であること。
- Prompt Part登録がaccessories version 1 / 2 / 3 / 4 / 5の順で成立すること。
- 対象未選択時の状態タグ0、対象選択時の合成Positive一回出力を確認すること。
- 完成魚のform / cooking固定、用途非互換候補の除外、複数対象の設定分離を確認すること。
- 対象解除、再選択、全リセット、カテゴリクリア、履歴復元、マイプリセット復元を確認すること。
- Android実機で一列・横書き、適用先表示、状態調整ボタン、プレビュー、固定フッターとの非重複を確認すること。

v5.7確定値：
- 配布名：`SHIMA FOOD STATE FORGE v5.7`。
- 新規データ／UI：`builder_data.food_state_forge.v1.js` / `ext_food_state_forge.v1.js`、API 1.0.0、accessories登録version 5。
- 食のアカシック：11棚、1,999 input。追加96、重複0、7軸、8セット。
- 全回帰293 / 293、変更JavaScript構文・manifest JSON合格。
- 仮想ブラウザDOM：11棚、1,999 input、状態棚、7軸バッジ、追加96、重複0、合成Positive一回出力。
- Android実機の最終操作感、固定フッターとの重なり、履歴／マイプリセット実操作はユーザー確認待ち。

### 25.26 既存食材カードの状態入口・実行版識別規約

発覚した問題：
- v5.7のカード右 `状態調整` は、新規追加96件にだけ存在していた。
- 既存の `漫画肉`、既存魚介、既存精肉、既存焼き魚等をチェックしても、カード右から状態工房へ入れなかった。
- 「食材をチェック → カード右の状態調整」という確認手順が全食材共通に見え、実装範囲と説明が一致していなかった。
- 起動中の旧フォルダと新しい配布フォルダを画面だけで判別しにくく、旧件数の画面を新機能として確認してしまう可能性があった。

入口の適用範囲：
- `食材図鑑`（`ingredients`）と `特化調理工房`（`specialized`）にある、状態対象として有効な既存inputへ右端 `状態調整` を自動付与する。
- v5.7追加96件と既存349件、合計445件を同じ入口契約へそろえる。
- 飲み物、状態部品、演出、動作、サイズ、対象連動用の補助部品へは入口を付けない。
- `data-food-target="true"`、飲料除外、所属棚の三条件から実行時に判定し、固定ID一覧を別管理しない。

非破壊DOM契約：
- 既存label、checkbox input、お気に入り星を複製・置換しない。
- 既存labelを `.food-state-legacy-shell` で一度だけ包み、右隣へbuttonを追加する。
- input ID、dataset、checked、change listener、履歴、お気に入り、マイプリセット、collector参照は元DOMのまま維持する。
- 再インストール・再整理・再マウント時は既存shellとbuttonを再利用し、同じカードへ2個以上追加しない。
- `cloneNode` を使わない。検索や選択中から元labelへ戻れる関係を保持する。

ボタン操作：
- checkbox直押しは従来どおり選択ON/OFFを行い、既存の単品サイズ案内等も従来機能として維持する。
- `状態調整` 直押しは未選択対象を選択し、状態工房の適用先に設定してから移動する。
- 移動前に文字検索、出力先検索、選択中、お気に入り等の表示絞り込みを解除し、空白画面化を防ぐ。
- 親食棚、状態棚、工房を開き、対象名、8おすすめセット、7軸、適用後プレビューを表示する。
- button押下はlabelのcheckbox既定動作へ伝播させず、二重反転を防ぐ。

実行版の識別：
- 工房見出しを `🧩 食材状態カスタマイズ工房 v5.7.1` と表示する。
- 工房DOMへ `data-food-state-forge-version="v5.7.1"` を持たせる。
- v5.7.1を確認する時は、旧画面の件数や説明だけで判断せず、この見出しと右端buttonを確認する。
- 既に開いている `127.0.0.1` の旧フォルダは自動的に新配布へ切り替わらない。完全版を新規展開し、そのフォルダの `builder_main..html` を開く。

最低監査：
- `漫画肉`を含む既存食材label、input、お気に入り星のDOM identityが入口追加後も同一であること。
- 既存349＋新規96＝状態入口445、button445、重複button0であること。
- 2回installしても `漫画肉`のbuttonが1個、工房が1個であること。
- 未選択の `漫画肉`からbuttonを押し、checked、適用先、状態棚open、工房openが一回で成立すること。
- 食prompt input 1,999、食棚11、追加96、安定ID、英語prompt、Positive collectorを変更しないこと。
- Androidで右端buttonがカード文字・星・checkbox・固定フッターと重ならず、横書き一列を維持すること。

v5.7.1確定値：
- 配布名：`SHIMA FOOD STATE ENTRY FIX v5.7.1`。
- 変更ランタイム：`ext_food_state_forge.v1.js`、API 1.0.1、accessories登録version 5は据え置き。
- 実行時：11棚、1,999 input、状態入口候補445、button445、既存入口349、新規入口96、`漫画肉`入口あり。
- 軽量DOM：未選択の既存 `漫画肉`から一回で選択・状態棚・工房open、再install後button1・工房1。
- 全回帰294 / 294、変更JavaScript構文、manifest JSON合格。

### 25.27 状態工房へのroot-local移動・Android再配置耐性規約

発覚した問題：
- 既存食材カード右の `状態調整` 自体は表示・選択できたが、Androidで状態工房ではなく19番の影棚付近へ移動した。
- 旧移動処理は `document.querySelector` でページ内最初の食rootを選び、状態groupを `:scope >` の直下固定で探していた。
- 棚再整理、入れ子wrapper、古いroot残存、details展開による大幅な高さ変更があると工房を見失い、食root全体へのfallback scrollが誤位置を生んだ。
- 巨大なopen後detailsをsmooth scroll対象にすると、Android Chromeのscroll anchoringと再レイアウト中の座標が競合した。

移動先の決定：
- `状態調整` を押したinput自身から `closest("details.food-akashic-root")` を取得し、そのrootだけを正規探索範囲にする。
- ページ内最初の食rootを優先してはならない。古い／重複rootが残っても、押したカードと別rootなら触らない。
- 状態groupはroot直下を前提にせず、同じroot内の `[data-food-state-forge-source="true"]` から実際のancestor groupを逆引きする。
- 工房sourceへ安定ID `shima-food-state-forge` と実行版 `data-food-state-forge-version` を付ける。
- 工房が一時的に見つからない場合だけ同じrootへ `ensureStateGroup` を実行し、上限付きで再探索する。別棚へfallback scrollしない。

表示経路：
- 工房sourceからbody／状態group／食root／sectionまで祖先をたどり、全detailsをopenにする。
- 検索・選択中・お気に入り由来の `.zero-assist-filter-hidden`、`hidden`、`display:none` を移動経路から解除する。
- スクロール対象は高さが大きく変わる工房details全体ではなく、先頭のsummary見出しとする。
- 2段の `requestAnimationFrame` 後にsummaryへ即時位置合わせし、棚再配置後の180ms／420msにも同じrootから再探索して再整列する。
- route sequenceを発行し、連打で古い予約が残っても最後に押した入口以外は移動させない。
- 成功時は工房見出しだけを短く強調し、ユーザーが到着先を視認できるようにする。

イベント境界：
- `状態調整` buttonは `preventDefault`、`stopPropagation`、`stopImmediatePropagation` でlabel／カード／別ジャンプ処理へ渡さない。
- 未選択対象は同じcheckboxを一度だけcheckedにし、synthetic changeで既存出力・履歴同期を行う。
- checkbox直押しの単品サイズ案内は従来機能として維持する。
- 食材データ、合成prompt、安定ID、状態設定、Positive collectorを移動修正のために変更しない。

最低監査：
- 先頭へ古い食root、後方へ操作対象root、その後ろへ影棚を置く誤移動再現DOMを作る。
- 操作対象root内では状態groupを直下でなくwrapper内へ入れ、旧 `:scope >` 前提が成立しない条件にする。
- button操作後、対象root／状態group／工房だけがopenになり、古いrootと影棚がclosedのままであること。
- 複数回の再位置合わせがすべて工房summaryを対象とし、食root全体・影棚・別sectionをscroll対象にしないこと。
- 全量DOMで11棚、1,999 input、入口445、既存入口349、新規入口96を維持すること。
- Android実機で `食材状態カスタマイズ工房 v5.7.2` へ一押しで着き、影／雰囲気／エフェクトへ誤移動しないこと。

v5.7.2確定値：
- 配布名：`SHIMA FOOD STATE NAV FIX v5.7.2`。
- 変更ランタイム：`ext_food_state_forge.v1.js`、API 1.0.2、accessories登録version 5は据え置き。
- 工房anchor：`shima-food-state-forge`、画面識別：`🧩 食材状態カスタマイズ工房 v5.7.2`。
- 誤移動再現DOM：対象root true、入れ子状態group true、工房 true、古いroot false、影棚 false、scroll対象は3回とも工房summary。
- 全量DOM：11棚、1,999 input、入口候補445、button445、既存入口349、漫画肉入口あり、状態工房由来error 0。
- 全回帰295 / 295、変更JavaScript構文、manifest JSON合格。

### 25.28 食の組み立て航路・サイズ先行・対象別扱い方規約

目的：
- 食材を選んだ後に、離れたサイズ棚、動作棚、器棚、状態工房をユーザー自身で探し回る負担をなくす。
- 一品ごとの組み立て順を `食材 → サイズ・量 → 扱い方 → 支持体 → 仕上げ` の一本線にする。
- 既存のサイズcheckbox、Positive collector、食材状態、履歴、マイプリセット、安定IDは正として再利用し、案内のためだけに同義promptを複製しない。
- サクッと決める航路と、従来の8軸状態工房を両立させる。

航路の固定順：
0. `size` 単品サイズ・量。
1. `handling` 扱い方。
2. `vessel` 支持体。
3. `finish` 仕上げ。
- 画面見出しは `FOOD ROUTE / 食の組み立て航路` とし、`🍣 鮭の切り身を選択中` のように現在対象を明記する。
- 各段は現在値を角括弧で常時表示する。未指定は `［未指定］`、サイズ未指定は `［標準（指定なし）］` とする。
- 一つ選ぶと次段を開くが、前段へ戻って変更可能とする。
- 下端に `このまま完成` と `細かく調整` を常設する。
- `このまま完成` は現在設定を保持して航路だけ閉じる。勝手に追加選択しない。
- `細かく調整` は同じ対象を既存の `食材状態カスタマイズ工房` へ渡す。

サイズ・量の互換契約：
- 航路内へ別のサイズ語データを作らない。
- 対象の `data-food-size-target-mode` から既存 `portion / unit / count / volume` を解決する。
- 航路のサイズ候補は、既存の `input[data-food-size-mode][data-food-size-preset]` を代理操作する。
- `標準（指定なし）` は同modeの既存サイズcheckboxを全解除する。
- サイズ変更はsynthetic changeを送り、既存の排他、出力、履歴、検索、リセット処理を通す。
- 現行仕様では同じsize modeの指定は共有である。対象別サイズ保存へ無断で変更しない。

旧案内との競合防止：
- trustedな食材checkbox直押しをdocument captureで先に受け、同一イベント中だけ `__suppressFoodSizeShortcut` を有効にする。
- 旧「単品サイズを指定しますか？」を同時表示せず、航路の0段へ統合する。
- synthetic change、履歴復元、初期同期、全リセットでは航路を自動表示しない。
- 飲み物は既存容量・フレーバー案内を維持し、v5.8航路の対象外とする。
- デザート／おにぎり等の `foodDecorationTarget` は既存トッピング案内との二重表示を避け、v5.8では航路対象外とする。

対象別の扱い方：
- 状態設定へ `handling` 軸を追加し、状態工房を7軸から8軸へ更新する。
- `handling` は選んだ食べ物の `foodStateConfig` へ保存し、別の食材へ漏らさない。
- 片手、両手、指、箸、箸で口元、フォーク、スプーン、ナイフとフォーク、トング、串、差し出すの11候補を持つ。
- 既存の「食べる動作」棚は人物全体や場面を組む上級者用として残す。航路の対象別handlingと削除・統合しない。
- 合成順は、元食材へform／cookingを適用した後、`handling → vessel → arrangement → garnish → texture → temperature` とする。

支持体の拡張：
- vesselは既存16候補を保持し、16候補を追加して32候補とする。
- 追加範囲は、ディナープレート、浅鉢、汁椀、丼、弁当箱、配膳トレー、食堂トレー、石板、ケーキスタンド、フライパン、調理鍋、卓上鍋、ワイヤーバスケット、バナナ葉、紙包み、クッキングシート。
- `弁当箱` は `in a compartmented bento lunch box` として対象食材へ連動し、完成料理「鮭弁当」等を自動追加しない。
- おすすめは対象profileと名称から上位表示するだけとし、残り候補を `すべての候補を見る` から必ず選べるようにする。

仕上げセット：
- 航路用仕上げは支持体と扱い方を上書きしない。
- 対象軸は `arrangement / garnish / texture / temperature` とする。
- 焼きたて・大根おろし、熱々・香ばしい、冷製・透明感、獲れたて氷鮮、照り艶、贈答向け整列、素朴な盛りの7セットを持つ。
- `焼きたて・大根おろし` は中央盛り、大根おろし、すだち、香ばしい皮、ふっくらした身、`freshly grilled and served hot` を合成する。
- 非互換の質感や温度は状態工房の既存sanitizerで静かに除外する。
- 詳細工房で変更した設定も航路を開き直した時に現在値として読む。航路固有の独立promptを保存しない。

複数食材・解除：
- 複数食材がcheckedなら対象selectorを表示し、各対象のサイズ表示、handling、vessel、finishを読み直す。
- 航路中の対象がuncheckedになった時は、残る最後の選択対象へ切り替える。対象が0なら閉じる。
- 全リセットと履歴復元開始時は航路を閉じる。復元完了のsynthetic changeで再表示しない。
- `builderResetAll`、`builderHistoryRestored` の双方を閉じる契約として監査する。

UI境界：
- 航路は棚の巨大DOM内へ挿入せず、body直下の固定bottom sheetとする。
- 固定フッター高 `--builder-footer-height` の上へ配置し、fallbackは88pxとする。
- Androidは画面左右6px以上を残し、最大高75vh、内部だけ縦スクロール、一列・横書き、固定項目高なしとする。
- グローバルheader／footer CSSの干渉を避けるため、航路見出しと操作帯はclass付きdivで構築する。
- おすすめと全候補は同じ一列カード規約で表示し、長い日本語名を縦書き化しない。

API・登録：
- 新規データ／UIは `builder_data.food_route_deck.v1.js` / `ext_food_route_deck.v1.js`。
- 航路はaccessories Prompt Part version 6として登録し、`getTags()` は常に空配列を返す。
- 状態工房はaccessories version 5のまま、API 1.1.0へ更新する。
- 状態工房APIは `getSelectedTargets`、`getCurrentTarget`、`getTargetByKey`、`setAxisChoice`、`patchTargetConfig`、`clearAxes`、`getAxisChoices` を公開する。
- version 6はUI orchestrationだけを担当し、Positive collectorを重複登録しない。

最低監査：
- manifest順が状態データ → 航路データ → accessories本体、状態UI → 航路UIであること。
- Prompt Part登録がaccessories version 1 / 2 / 3 / 4 / 5 / 6の順で成立すること。
- 航路4段、handling 11、vessel 32、仕上げ7、航路単独タグ0であること。
- 鮭の切り身へ既存unitサイズ、箸、弁当箱、焼きたて・大根おろしを適用し、一つのPositive語へ合成されること。
- 合成結果にサイズ、`held with chopsticks`、`compartmented bento lunch box`、`grated daikon`、`freshly grilled and served hot` が含まれること。
- `細かく調整` で同じ対象の状態工房がopenになり、航路が閉じること。
- 全リセット、履歴復元で航路が閉じること。
- 食棚11、food input 1,999、既存96追加、安定ID、状態入口445を変えないこと。
- 全既存回帰と、航路専用の静的・全量DOM試験を両方行うこと。

v5.8確定値：
- 配布名：`SHIMA FOOD ROUTE DECK v5.8`。
- 状態データAPI 1.1.0、状態UI API 1.1.0、航路データ／UI 1.0.0。
- accessories登録version：1 / 2 / 3 / 4 / 5 / 6。
- 全量食DOM：11棚、1,999 input、航路4段、handling 11、vessel 32。
- 鮭の切り身実動：unitサイズ、箸、弁当箱、焼きたて・大根おろしが一つのPositiveへ合成。
- 詳細工房handoff、全リセットclose、履歴復元close、航路単独タグ0。
- 全回帰308 / 308、変更JavaScript構文、manifest JSON合格。

### 25.29 意味的ブースト・アカシック責務分離規約

目的：
- `masterpiece`、`best quality`、解像度、レンダリング方式のような技術品質とは別に、被写体が「どう魅力的に見えるか」を意味として補強する。
- 「セクシー」「グラマラス」「端正」「可憐」「威厳」「神秘」「悪役のカリスマ」等を、衣装や人物属性を勝手に固定せず再利用可能にする。
- サクッと決める完成ブーストと、顔・視線・体型・身体言語等を細かく調整する部品を同じ庫で迷わず使えるようにする。

配置と責務：
- トップレベルsection IDは `semantic_boost`。表情の直後、衣装の直前へ置く。
- 制作航路の「キャラ設計」「登場人物」から `list-semantic_boost` へ到達できるようにする。
- ここへ技術品質、解像度、画風、衣装、アクセサリー、背景、人種、髪色を入れない。
- 表情棚は具体的な表情、体型棚は素体、衣装棚は着用品、意味的ブースト棚はそれらをどう魅力的・印象的に見せるかだけを担当する。
- 全項目をPositive通常へ出力する。Negative専用語の置場にはしない。

通常側の固定構造：
- 親名は `💎 意味的ブースト・アカシック`。R-18未解放でも利用できる非露骨な意味強化とする。
- 完成ブーストは16用途×標準／高水準／特盛りの3濃度、計48件。
- 完成用途は、端正美、艶麗グラマラス、上品な色香、可憐、健康美、モデル級、ハンサム、ワイルド、中性的、英雄、王者、ファムファタール、神秘、神性、悪役、人外・機械。
- 詳細は10群×6軸×8強度、計480件。
- 詳細群は、全体オーラ、女性的魅力、男性的魅力、中性・幻想・人外、顔立ち、目元、口元、体型・シルエット、ポーズ・身体言語、肌・髪・微細な動き。
- 通常側合計は528件。

成人側の固定構造：
- 既存の `MY_SECRET_UNLOCK === "true"` の時だけDOMを生成する。未解放時はinput 0、collector 0とする。
- 親名は `🔞 成人向け意味的ブースト`。衣装や具体的行為を固定せず、成人の色香、視線、呼吸、身体言語、距離感を担当する。
- 完成ブーストは8用途×3濃度、計24件。
- 詳細は4群×6軸×8強度、計192件。
- 成人側合計は216件。
- 全216件のprompt先頭へ `adult subject, consensual sensual presentation` を付ける。
- 未成年語、具体的性行為、強制・非合意表現を含めない。
- 成人側inputと親棚へ `data-r18-only="1"` を付け、通常側へ混ぜない。

濃度と強度：
- 完成ブーストの標準は核4要素、高水準は顔・視線・姿勢まで7要素、特盛りは10要素。
- 完成ブーストの重み上限は1.30。意味語を増やすために品質語を足さない。
- 詳細強度は `ほのか → 自然 → 洗練 → 明瞭 → 惹きつける → 劇的 → 象徴的 → 最大強調` の8段階。
- 詳細も重み上限1.30とする。
- 同じ軸の8強度は手操作時に一つだけとし、別軸は積み重ね可能とする。

入口と選択挙動：
- 通常入口は `今日は何を強く魅せる？`、成人入口は `成人の何を強く魅せる？`。
- 入口buttonは対象群を開いてsummaryへ移動するだけ。checkboxをONにしない。
- 通常入口は完成セットを含む11用途、成人入口は5用途を一列表示する。
- 親、群、カテゴリはすべて初期closed。
- 完成セットは手操作時に同じ意味棚の別完成セットを解除し、一つだけにする。
- 詳細の単一推奨軸は同カテゴリの別強度を解除する。
- 履歴・マイプリセット復元のsynthetic changeでは自動解除しない。保存済み状態を保ち、`同軸重複` 警告だけを表示する。
- `この棚をクリア` は当該通常棚または成人棚だけを解除し、他sectionを触らない。

安定ID・互換：
- ID形式は `semantic-boost-v59-<scope>-<group>-<category>-<slug>`。
- `data-stable-id` はinput IDと同一、`data-output-channel="positive"`、`data-prompt-intent="normal"` を必須とする。
- `semantic_boost` Prompt Part version 590を通常、591を成人に使用する。
- 検索、出力先検索、選択中、お気に入り、履歴、マイプリセット、全リセット、カテゴリクリアへ再索引する。
- 検索語のため日本語名、英語prompt、用途説明をinput／labelへ保持する。

UI規約：
- Androidを含め、親、入口、群、カテゴリ、カードを完全一列・横書きにする。
- 固定高さを使わず、日本語名・説明・promptを `overflow-wrap:anywhere` で収める。
- checkbox直押しは詳細画面へ横取りせず、その場でON/OFFする。
- カードへ用途説明と実際の英語promptを常時表示し、名前だけで内容を推測させない。
- STATUSは選択総数、完成数、詳細数、同軸重複数を表示する。

最低監査：
- データ528＋216＝744、完成48＋24＝72、詳細480＋192＝672であること。
- 744件の経路、安定ID、日本語名、正規化promptが一意であること。
- `masterpiece / best quality / 8k / 16k`、衣装、背景、人種、髪色の禁止代表語が0件であること。
- 全重みが1.30以下であること。
- R-18未解放は通常528・成人0、解放後は成人216であること。
- 通常入口11、通常群11、通常カテゴリ76、成人入口5、成人群5、成人カテゴリ32であること。
- 入口button前後でchecked数が変わらず、直接checkbox操作ではSTATUSとPositive出力が1件増えること。
- Android幅412pxでdocument／棚／カードの横溢れ0、縦書き0であること。
- 全既存回帰に意味的ブースト専用テストを加え、全件合格を確認すること。

v5.9確定値：
- 配布名：`SHIMA SEMANTIC BOOST AKASHIC v5.9`。
- 新規データ／UI：`builder_data.semantic_boost_akashic.v1.js` / `ext_semantic_boost_akashic.v1.js`。
- 通常：11群、76カテゴリ、528件。成人：5群、32カテゴリ、216件。総計744件。
- 完成セット72件、詳細部品672件、完成3濃度、詳細8強度、最大重み1.30。
- manifest順：表情bundle → 意味データ → 意味UI → ポーズbundle。
- section順：表情 → 意味的ブースト → 衣装。
- 全回帰325 / 325、意味専用17 / 17、実DOM通常／成人、Android幅412px実ブラウザ検査合格。

### 25.30 意味的ブースト調律室・候補比較・相性診断規約

目的：
- 744件の意味ブーストを細かく選べる自由度は維持しつつ、初見でも3問で完成候補へ到達できるようにする。
- 似た語を追加して弾薬庫を二重化せず、既存の完成セットと詳細部品を「調律レシピ」として組み替える。
- 候補を眺める操作と、実際にcheckboxを変更する操作を明確に分離する。

配置と責務：
- 通常側は `.shima-v59-guide` の直後、成人側は成人意味棚の同位置へ、初期closedの `details` として置く。
- 通常見出しは `意味的ブースト調律室`、成人側は `成人向け意味的ブースト調律室`。
- データは `builder_data.semantic_tuning_lab.v1.js`、UIは `ext_semantic_tuning_lab.v1.js`。
- 調律室はUI composerであり、新規prompt語、新規checkbox、新規stable ID、Prompt Part、collectorを作らない。
- 参照元は `SHIMA_SEMANTIC_BOOST_AKASHIC_V1` の既存quick themes／detail axesだけとする。

3問と固定選択肢：
- 問1 `どこを強く魅せる？`。通常9対象、成人5対象。
- 通常対象は、全体、女性的魅力、男性的魅力、中性・幻想・人外、顔立ち、目元、体型・シルエット、身体言語、肌・髪・微細な動き。
- 成人対象は、成人全体、成人女性、成人男性・中性・人外、成人の顔・視線、成人の身体言語・距離感。
- 問2 `どんな印象にする？`。通常16印象、成人8印象。
- 通常印象は、端正、グラマラス、上品な色香、可憐、健康美、モデル級、ハンサム、ワイルド、中性的、英雄、王者、ファムファタール、神秘、神性、悪役、人外・機械。
- 成人印象は、成人グラマラス、成人エレガント、成人ファムファタール、成人の焦らし、成人男性、成人中性、成人神性、成人悪魔。
- 問3 `どこまで盛る？`。ほのか、標準、高水準、特盛りの4段階。

候補A／B／C：
- A `一押し完成型` は、既存のquick themeを1件だけ提案する。
- B `対象集中型` は、選んだ対象に関係する既存detailを2〜5件提案する。
- C `均整レイヤー型` は、複数groupへ分散した既存detailを3〜6件提案する。
- 各候補は日本語の構成名、実際のPositive語、既選択数、同軸置換数、意味対比警告、積みすぎ警告を表示する。
- 候補カードを押すだけではcheckedを変更しない。プレビュー中の選択数は必ず不変とする。

適用モード：
- `選択中をこの案へ置き換える` は、現在の通常／成人scope内だけを解除して候補を適用する。他scopeや他sectionへ触れない。
- `現在を残して相性調整しながら追加` は、同scope内の競合quick setと同じdetail軸の別強度だけを解除し、候補を追加する。
- 追加時も、別軸・別の意味対比・他sectionの選択を勝手に消さない。
- `細かく調整する棚へ` は候補に対応する既存棚を開いて移動するだけで、checkboxを変更しない。
- 適用後は通常のchange経路を通し、選択中、Positive、履歴、マイプリセット、検索表示へ同期する。

相性診断：
- 現在scopeの選択件数、正規化後の意味語数、同軸競合数、意味対比数を表示する。
- 同じaxisIdに複数のdetail強度がある時は同軸競合とする。
- 柔和×威圧、可憐×捕食的、儚さ×荒々しさ、自然体×演出型、端正×野性、親和×威嚇を意味対比の代表ペアとする。
- 意味対比は創作上の意図になり得るため警告だけを表示し、自動解除しない。
- 積みすぎ目安は通常22件、成人24件。閾値超過も警告だけとし、強制削除しない。
- 状態表示は待機／良好／要確認の三段階とする。

成人境界：
- 成人調律室は `MY_SECRET_UNLOCK === "true"` の時だけmountする。
- 未解放時は成人調律室、成人候補、成人inputを一切生成しない。
- 通常候補から成人IDを参照せず、成人候補から通常scopeを置換しない。
- 成人側の語彙安全性はv5.9データを正とし、調律室で別の成人promptを生成しない。

起動・復元・UI：
- `semanticBoostAkashicReady`、`builderHistoryRestored`、`builderResetAll`、`visibilitychange` で重複なく再評価する。
- mount先が遅れて現れる場合は低頻度で再試行し、同じ調律室を重複生成しない。
- リセット後は診断と表示を再同期する。履歴復元では既存checkedを尊重し、自動適用しない。
- Androidでは全要素を一列・横書きにし、固定高さを使わず、長い日本語名とpromptを折り返す。
- select、候補カード、診断、操作buttonはタップ領域を確保し、候補比較中も画面横溢れを出さない。

公開API：
- `window.__SHIMA_SEMANTIC_TUNING_LAB_V1__.generate(scope, target, impression, intensity)` はA／B／C候補を返す。
- `.apply(scope, candidate, mode)` は `replace` または `add` で明示適用する。
- `.diagnose(scope)` は現在scopeの診断結果を返す。
- 公開APIを自動選択や外部prompt注入の近道として使わず、既存checkbox操作へ必ず収束させる。

最低監査：
- manifest順が意味データ → 調律データ → 意味UI → 調律UIであること。
- 通常9対象・16印象、成人5対象・8印象、濃度4であること。
- 全target／impression／intensity組み合わせがA／B／Cを返し、参照先が既存v5.9項目だけであること。
- プレビュー、候補選択、`細かく調整する棚へ` でchecked数が増えないこと。
- replace／addを明示実行した時だけcheckedとPositiveが同期すること。
- 同軸重複は置換候補として数え、意味対比は警告だけで残ること。
- R-18未解放で成人調律室0、解放後だけ1であること。
- リセット、履歴復元、再mountで重複UIや勝手な選択が発生しないこと。
- Android幅412pxで候補3枚、横溢れ0、縦書き0であること。
- 全既存回帰に調律室専用テストを加え、全件合格を確認すること。

v6.0確定値：
- 配布名：`SHIMA SEMANTIC TUNING LAB v6.0`。
- 新規データ／UI：`builder_data.semantic_tuning_lab.v1.js` / `ext_semantic_tuning_lab.v1.js`。
- 調律室データ1.0.0、UI API 1.0.0。
- 通常9対象×16印象、成人5対象×8印象、4濃度、A／B／Cの3方式。
- 参照する意味ブーストは既存通常528／成人216、総計744。新規prompt 0、新規input 0、新規stable ID 0。
- 全回帰336 / 336、調律室専用11 / 11、Android幅412px実ブラウザ検査合格。

### 25.31 表情アカシック・深度分類・調律規約

目的：
- 表情を追加時期やbundle version順ではなく、ユーザーが顔を決める思考順で探せるようにする。
- 既存の大量表情を削除せず、初心者の一押し完成と上級者の部品調整を同じ棚で両立する。
- 棚へ移動する操作、候補を比較する操作、実際に選択する操作を分離する。

固定する棚順：
1. `01 すぐ決める・完成束`
2. `02 基本感情・感情の核`
3. `03 目・視線・口元`
4. `04 赤面・涙・汗・漫符`
5. `05 場面リアクション`
6. `06 深層演技・キャラ性`
7. `07 成人向け表情`

分類原則：
- 初めに一押し完成、次に笑顔・怒り・悲しみ等の核、続いて目・口の部品、見た目に出る演出、場面反応、複雑な演技、成人向けの順にする。
- 成人棚は必ず末尾に置き、R-18未解放時は棚そのものを生成しない。
- 食事、事故、恐怖、疲労、勝利等は場面リアクションへ置く。
- 悪役、企み、闘志、余韻、とろけ、人物性の強い完成顔は深層演技へ置く。
- 目の色、目の形、瞳孔・ハイライトは表情の人物同一性部品として扱い、表情完成束の置換で解除しない。

既存DOMの扱い：
- 既存checkboxを新しいcheckboxへ作り直さない。
- 元のdetails／label／inputを `appendChild` で新しい棚へDOM移動する。
- `data-val`／`data-en`、checked、イベント、既存input ID、履歴、マイプリセット、検索、お気に入り、選択中、collectorを維持する。
- IDが存在しない旧表情inputだけへ、scope・元カテゴリ・promptから決定的な `data-stable-id` を補う。
- 同一scopeの完全同promptは削除せず、実label/inputを初期closedの `互換・同語保管庫` へ移す。
- Positiveと成人等のscopeを越えて重複扱いしない。

旧versionエラーの扱い：
- v1は `IS_UNLOCKED` 欠落、v2は `FACE_EFFECTS_GROUPS` 欠落で実行時例外になっていた。
- 表情アカシックのscriptをbundle直後に読み、`window.__SHIMA_EXPRESSION_ATLAS_ACTIVE__` を先に立てる。
- bundle側はこの印がある時だけ旧v1／v2 `initUI` をreturnし、v3／v4／v5を維持する。
- v3が旧v2相当を包含することを実DOMで確認してから旧v2を止める。
- v1だけにあり実DOMから欠ける基本感情14件は、元promptを一字も変えず安定ID付きで回収する。
- エラーをcatchするだけで完了せず、欠落した項目数と後続versionの実DOMを監査する。

入口：
- 見出しは `今日はどんな顔にする？`。
- 通常入口は、サクッと完成、感情から選ぶ、顔パーツから調整、場面・演技から選ぶの4種類。
- 成人解放時だけ成人向け入口を加える。
- 入口buttonは対象棚をopenにして移動するだけ。checkboxを変更しない。
- サクッと完成だけは01棚と表情調律室を開いてよいが、候補の適用は行わない。

表情調律室：
- データは `builder_data.expression_atlas.v1.js`、UIは `ext_expression_atlas.v1.js`。
- 通常12用途は、喜び、好意、照れ、悲しみ、怒り、恐怖、驚き、落ち着き・真剣、悪役、闘志、疲労、食・味覚。
- 成人4用途は、誘い、我慢、主導、とろけ。
- 濃度は、ほのか2部品、標準3部品、高水準4部品。
- A `軽量完成束` は既存quick itemを一つ提案する。
- B `場面完成顔` は既存scene faceを一つ提案する。
- C `部品調律` は既存の感情・視線・口・演出を2〜4件組む。
- 全候補は既存表情inputを参照し、候補用prompt、候補用checkbox、候補用collectorを新造しない。
- 候補カードを押す操作は比較対象を切り替えるだけ。checkedを変更しない。

適用モード：
- `選択中の表情をこの案へ置き換える` は、同scopeの感情核、完成顔、場面顔、action、視線、口、演出だけを解除して候補を適用する。
- 目の色、目の形、瞳孔・ハイライトは解除対象外とする。
- `現在を残して相性調整しながら追加` は、完成顔同士、同じ視線、同じ口、同じactionだけを整理する。
- 別scope、他section、人物同一性部品へ触れない。
- change eventを通常経路へ送り、選択中、Positive、履歴、マイプリセットへ同期する。
- 表情アカシックPrompt Part version 610はUI orchestrationだけを担当し、`getTags()` は空配列を返す。

相性診断：
- 表情選択数、完成顔数、同役割数、意味対比、積みすぎを表示する。
- 感情核・quick・sceneの複数選択、視線複数、口元複数を同役割警告とする。
- 喜び×悲しみ、穏やか×激怒、真剣×パニック、無表情×大笑いを代表対比とする。
- 対比は複雑な演技として意図される場合があるため、自動解除しない。
- 積みすぎ目安は通常10表情部品、成人12表情部品。超過は警告だけとする。

成人境界：
- `MY_SECRET_UNLOCK === "true"` の時だけ成人棚、成人入口、成人recipe optionを生成する。
- 未解放時は公開 `.generate(adultRecipe)` も空配列を返す。
- 成人レシピが通常inputへfallbackして見かけ上の成人候補を作ることを禁止する。
- 成人棚の既存prompt内容は旧表情データを正とし、調律室が別の成人語を追加しない。

起動・復元・UI：
- manifest順は `expression atlas data（guard） → expression bundle → expression atlas UI → semantic boost`。
- v1／v2 guard用の印を先に立てるため、atlas UI scriptはPrompt Part mount開始前にロードされていなければならない。
- `builderHistoryRestored`、`builderResetAll`、`visibilitychange`、関連ready eventで重複なく再同期する。
- 再mount時は既存atlasを再利用し、二重UI、二重collector、二重inputを作らない。
- 親7棚、子棚、調律室、互換保管庫は初期closed。
- Androidを含め完全一列・横書き、固定高さなし、長文折り返し、横溢れなしとする。

公開API：
- `window.__SHIMA_EXPRESSION_ATLAS_V1__.reorganize()` は既存DOMを再整理する。
- `.generate(recipeId, intensityId)` は候補のstable IDとpromptを返すが、選択しない。
- `.apply(mode, candidateIndex)` は直前に生成・表示した候補を明示適用する。
- `.diagnose(scope)` は現在選択を診断する。
- `.jump(zoneId, openTuner)` は棚へ移動するだけで選択しない。

最低監査：
- 旧v1／v2のmount errorが0、v3／v4と解放時v5がmountしていること。
- 通常input 512、成人未解放0、解放時成人303、合計815であること。
- 基本感情14件が回収され、棚外input 0、stable ID欠落0、重複0であること。
- 通常6棚／解放時7棚が固定順で、初期open 0であること。
- 通常4入口／解放時5入口で、入口前後のchecked数が不変であること。
- 通常12／成人4レシピが、解放時に各A／B／Cを返すこと。
- 未解放時の成人4レシピが候補0であること。
- 候補カード前後のchecked数が不変で、明示適用後だけ増えること。
- 目の色・形・瞳孔を選んでreplaceしてもcheckedが維持されること。
- Android幅412pxで横溢れ0、縦書き0、page error 0であること。
- 全既存回帰と表情アカシック専用試験を合格させること。

v6.1確定値：
- 配布名：`SHIMA EXPRESSION ATLAS v6.1`。
- 新規データ／UI：`builder_data.expression_atlas.v1.js` / `ext_expression_atlas.v1.js`。
- expression登録version：1 / 2 / 3 / 4 / 610、R-18解放時は5も追加。
- 通常512、成人303、解放時合計815。基本感情回収14、棚外0、stable ID重複0。
- 通常12／成人4レシピ、3濃度、A／B／C。
- 全回帰353 / 353、専用17 / 17、Linkedom通常／成人、Android幅412px Chromium監査合格。

### 25.32 表情棚・展開本文の一列固定規約

症状：
- 棚見出しは一列でも、棚を開くと説明文と内側の棚／工房が左右2列へ分かれる場合がある。
- 原因は個別UIのgrid指定不足ではなく、`builder_main..html` の共通規則 `.section-content details[open] > div` が、全details直下divへ `repeat(auto-fill, minmax(140px, 1fr))` を与えるためである。
- 子カードだけを一列化しても、親の展開本文が2列なら画面全体は一列にならない。

固定規則：
- 新しい棚UIでは、親details直下の本文wrapper自身へ、対象root IDを含む高優先度セレクタで一列を指定する。
- 最低限 `display:grid!important`、`grid-template-columns:minmax(0,1fr)!important`、`grid-auto-flow:row!important`、`width:100%!important` を指定する。
- 内側に別detailsを持つ工房・調律室は、その直下本文wrapperにも同じ一列規則を置く。
- 選択欄、候補一覧、診断、適用ボタン等へPC幅だけ2列へ戻すmedia queryを置かない。
- 見出し内部のアイコン／題名／件数は操作部品の並びであり、棚カード2列とは別扱い。読みやすい横並びを維持してよい。
- 一列化のためにDOMを複製・再生成せず、CSSだけで既存input、イベント、保存互換を保つ。

最低監査：
- 対象棚を実際にopenにした後、親本文wrapperの計算後 `grid-template-columns` が単一値であること。
- 工房／調律室もopenにし、本文、選択欄、候補、操作欄それぞれの子要素が同じX座標列へ縦に並ぶこと。
- 412pxだけでなく780px以上でも一列のままであること。
- 横溢れ0、縦書き0、候補閲覧によるchecked変更0を維持すること。
- HTML内の共通CSSを削って他棚へ影響させず、対象root内だけで競合を遮断すること。

v6.1.1確定値：
- 配布名：`SHIMA EXPRESSION ATLAS v6.1.1`。
- runtime変更：`ext_expression_atlas.v1.js` の表情アカシック専用CSSのみ。データ、prompt、stable ID、Prompt Part version 610は維持。
- Android幅412px計算後：棚本文324px×1、棚リスト324px×1、調律室300px×1、感情／濃度300px×1、候補300px×1、操作300px×1。
- 幅900px計算後：棚本文808px×1、調律室・感情／濃度・候補・操作784px×1。広い画面でも2列へ戻らない。
- manifest成功96／失敗0、表情input通常512、R-18解放時815を維持。
- 全回帰354 / 354、専用18 / 18、横溢れ0、縦書き0、page error 0。
