@lism-css/mcp 0.26.0 → 0.27.0

package/dist/data/guides/css-rules.md

@@ -37,10 +37,9 @@ Settings（トークン定義）
 
 `lism-block` は `lism-trait` / `lism-primitive` より弱い位置にあるため、`b--` のベーススタイルには、明示的に付与したクラス（`is--` / `has--` / `l--` など）が勝ちます。
 
-なお、この優先関係が保証されるのはレイヤーありの標準ビルド（`main.css` / `full.css`）だけです。`main_no_layer.css` / `full_no_layer.css` にはレイヤーがないため、読み込み順と詳細度に依存します。
+なお、レイヤーによるこの優先関係が保証されるのは標準ビルド（`main.css` / `full.css`）だけです。`main_no_layer.css` / `full_no_layer.css` では、Property Class は常に `!important`、`u--` クラスはセレクタ二重化（`.u--trim.u--trim` = 0-2-0）で「Property Class > Utility Class > 単一クラス」の序列だけを再現し、それ以外は読み込み順と詳細度に依存します。
 
-ユーザーが定義する独自クラス・上書きスタイルは、役割に合わせて適切なレイヤーに配置します。
-例えば、トークンやベーススタイルの上書きは `@layer lism-base`、`b--` のベーススタイルは `@layer lism-block`、それ以外の独自クラス（`c--`）は `@layer lism-custom` に置きます。
+独自クラス・上書きスタイルも対応するレイヤーに置きます。トークン・ベーススタイルの上書きは `@layer lism-base`、`b--` のベーススタイルは `@layer lism-block`、それ以外の独自クラス（`c--`）は `@layer lism-custom`（書き方は「カスタムCSS を追加する場合」）。
 
 ## クラス分類とプレフィックス
 
@@ -130,7 +129,7 @@ BEM 構造（本体クラス / Modifier / Element）を持つのは `b--` と `c
 | Element | `b--{name}_{element}` / `c--{name}_{element}` | `b--card_header`, `c--pricing_body` |
 
 - Modifier は本体クラスと併記して使用: `.b--btn.b--btn--outline` / `.c--pricing.c--pricing--featured`
-- Element は `_`（アンダースコア）一つ区切り
+- Element は `_`（アンダースコア）一つ区切り。CSS で参照する子要素にだけ付ける（[Custom Class（`c--`）](#custom-classc--)）
 - 同じプレフィックスの本体クラス同士の併用（`.b--xxx.b--yyy` / `.c--xxx.c--yyy`）は基本 NG。ただし次は許容される:
   - 本体クラスと自身の Modifier: `.c--xxx.c--xxx--modifier`
   - 本体クラスと他の本体クラスの Element: `.c--xxx.c--yyy_elem`
@@ -171,7 +170,7 @@ BEM 構造（本体クラス / Modifier / Element）を持つのは `b--` と `c
 
 他のLismクラス（Trait, Primitive, Property Class等）との組み合わせを前提に設計し、CSSへ残すのは、擬似要素・子孫セレクタ・状態セレクタなど、Props/Property Classで表現できないものだけです。（明確な意図があればCSSに一般的なスタイルを書くことも可）
 
-スタイルが全くなく、何のパーツかを示す名前付けのためだけに使っても構いません。
+スタイルが全くなく、何のパーツかを示す名前付けのためだけに使っても構いません。ただし名前付けだけで残すのは本体クラス（`c--{name}`）だけです。Element（`c--{name}_{element}`）は、子孫セレクタ・擬似要素・状態切替など CSS でその子要素を参照する時だけ付けます（NG→OK 例は [antipatterns-layout.md](./antipatterns-layout.md#css-の無い-element-クラスを付ける)）。
 
 ```html
 <!-- HTMLで書く場合も、何のパーツかを示す名前 + Primitive + Property Class を優先 -->
@@ -214,9 +213,9 @@ CSSが空になる場合は、CSSファイル側に`.c--myCard {}`を書かず
 }
 ```
 
-カスタムCSS内でも、できる限り Lism のCSS変数（トークン）を使ってください。また、`c--` のクラスでは、`padding`/`border-radius`/`font-size`/`color`などProperty Class/Propsへ移せる宣言を、CSSに書く前にマークアップ側へ移します（NG→OK例は[antipatterns.md](./antipatterns.md#property-class-で書けるのに-css-で書く)を参照）。ただし`b--`のベーススタイルは対象外で、トークンを使って`@layer lism-block`で管理します。
+カスタムCSS内でも、できる限り Lism のCSS変数（トークン）を使ってください。`c--` でCSSに残す宣言の基準は [Custom Class（`c--`）](#custom-classc--)、`b--` は [Block Class（`b--`）](#block-classb--) を参照。
 
-明確にその数値に意図があり、トークン化・丸め・Property Class化ができない場合だけ、生のCSS値を例外として使用できます。その場合は実装プランに理由を残します。
+トークン外の生のCSS値は、[antipatterns.md の「直書きしてよい例外」](./antipatterns.md#px--固定値の直書き)に該当する場合だけ使い、実装プランに理由を残します。
 
 **レイヤー外に書く場合:**
 `@layer` の外（レイヤーなし）でカスタムCSSを書くのは、**Property Class（`-{prop}:{value}`）を拡張する場合のみ**としてください。それ以外のカスタムスタイルは必ずいずれかの `@layer` 内に記述します。
@@ -248,13 +247,6 @@ Lism のトークン変数のカスタマイズやベーススタイルの上書
 コンポーネント固有のスタイルは、そのコンポーネントを定義しているファイルに紐づけます。
 
 - `.jsx` / `.tsx` ファイル: CSS ファイルを `import` する
-- `.astro` ファイル: `import` するか、コンポーネントファイル内の `<style>` タグに記述
+- `.astro` ファイル: `import` するか、コンポーネントファイル内の `<style>` タグに記述（`<style>` 内でも `@layer` で囲む）
 
-```css
-/* 独自クラスの CSS は lism-custom 内に定義する（b-- のベーススタイルだけ lism-block） */
-@layer lism-custom {
-  .c--yourComponent {
-    ...
-  }
-}
-```
+置くレイヤーは「カスタムCSS を追加する場合」と同じです。

package/dist/data/guides/customize.md

@@ -12,8 +12,8 @@
 詳細（公式ドキュメント）:
 
 - 概要: [https://lism-css.com/docs/customize/](https://lism-css.com/docs/customize/)
-- CSSビルドの選択（`@layer` / `full.css` / `isFullMode`）: [https://lism-css.com/docs/customize/build/](https://lism-css.com/docs/customize/build/)
-- `lism.config.js`（props / tokens / traits・breakpoints・追加スタイル）: [https://lism-css.com/docs/customize/config/](https://lism-css.com/docs/customize/config/)
+- CSSファイルの種類（`@layer` なし版 / `full.css`）: [https://lism-css.com/docs/css-files/](https://lism-css.com/docs/css-files/)
+- `lism.config.js`（props / tokens / traits・breakpoints・`isFullMode`・追加スタイル）: [https://lism-css.com/docs/customize/config/](https://lism-css.com/docs/customize/config/)
 - SCSS（`$setting` / `$props`・BP上書き）: [https://lism-css.com/docs/customize/scss/](https://lism-css.com/docs/customize/scss/)
 - CSS Purge: [https://lism-css.com/docs/customize/purge/](https://lism-css.com/docs/customize/purge/)
 
@@ -22,7 +22,7 @@
 ## `@layer` をオフにする
 
 `lism-css/main.css` の代わりに `lism-css/main_no_layer.css` を読み込むだけで、`@layer` を使わない CSS に切り替えられます。
-なお、no-layer版ではレイヤーによる優先度管理（`b--`よりProperty Classが必ず強い等の保証）が効かず、読み込み順・詳細度に依存します。
+no-layer版は既存サイトや WordPress テーマなど、カスケードを制御できない環境向けです。レイヤーの代わりに、Property Class は常に `!important` 付き、`u--trim` / `u--trimAll` / `u--cbox` / `u--divide` / `u--enclose` はセレクタ二重化（`.u--trim.u--trim` = 0-2-0）で出力され、「Property Class > Utility Class > 単一クラス」の序列を再現します。`lism.config.js` の `defaultImportant: false`・`$default_important: 0`・`props` の個別 `important: 0` を指定しても `!important` は外れません。`b--` など上記以外のクラス同士の優先度は読み込み順・詳細度に依存します。
 
 ```js
 // 通常
@@ -48,7 +48,7 @@ import 'lism-css/main_no_layer.css';
 | --- | --- | --- |
 | `$breakpoints` | ブレイクポイント数値の定義（`0` は無効＝クエリを出力しない） | `('xs': 0, 'sm': '480px', 'md': '800px', 'lg': '1120px', 'xl': 0)` |
 | `$is_container_query` | コンテナクエリで出力するか（`1` = container query, `0` = media query） | `1` |
-| `$default_important` | Property Class にデフォルトで `!important` を付与するか | `0` |
+| `$default_important` | Property Class にデフォルトで `!important` を付与するか（no-layer版では無視され、常に付与） | `0` |
 | `$props` | Property Class ごとの個別出力設定 | `prop-config` のデフォルト |
 
 ### 基本フォーマット
@@ -183,7 +183,7 @@ export default {
 
 これだけで、ブレイクポイント対応の全 Property Class が `xs` / `xl` のレスポンシブクラス（`-p_xs` / `-p_xl` 等）も出力するようになります。prop ごとの個別指定は不要です。
 
-統合プラグイン（型自動生成が有効）を使っている場合、有効化したブレイクポイントを反映した `lism-env.d.ts` がプロジェクト直下に**自動生成**されます。型補完も有効化したブレイクポイントのキーを自動で提示するため、`BreakpointRegistry` をプロジェクト側の `.d.ts` で手書き拡張する必要はありません。`lism-env.d.ts` は git にコミットしてください（`astro check` 等の型チェックがこのファイルを拠り所にします）。
+統合プラグイン使用時は有効化したブレイクポイントがプロジェクト直下の `lism-env.d.ts` に自動反映され、`BreakpointRegistry` の手書き拡張は不要です。`lism-env.d.ts` は git にコミットしてください（`astro check` 等の型チェックがこのファイルを拠り所にします）。
 
 > SCSS を直接利用する構成では、`@use 'lism-css/scss/setting' with ($breakpoints: ...)` で有効化する方法も利用できます（[SCSS でのカスタマイズ](#scss-でのカスタマイズ) を参照）。
 
@@ -257,31 +257,18 @@ export default {
 
 ### 追加した prop / trait の型解禁
 
-統合プラグイン（型自動生成が有効）を使っている場合、`lism.config.js` で追加した **prop / trait も `lism-env.d.ts` 経由で型側に自動解禁**されます（`CustomPropRegistry` / `CustomTraitRegistry` の拡張として出力）。そのため上記の `<Box filter="blur" ... isHoge>` のような新規 prop / trait も、エディタや `astro check` で型エラーになりません。手書きの型拡張は不要です。
+統合プラグイン使用時は、追加した prop / trait も `lism-env.d.ts`（`CustomPropRegistry` / `CustomTraitRegistry` の拡張）で自動解禁され、手書きの型拡張は不要です。
 
 なお、既存 prop への値追加（`ta="justify"` 等）はもともと任意の文字列を受け付けるため、型エラーにはなりません（ただし補完候補には出ません）。
 
 
 ## 追加スタイルを読み込ませる方法
 
-`lism.config.js` で props を増やしただけでは、対応するユーティリティクラスのスタイルが必要になります。構成によって反映方法が異なります。
+`lism.config.js` で props を増やしただけでは、対応するユーティリティクラスのスタイルが必要になります。構成によって反映方法が異なります。`traits` はクラス名だけを追加するため、`is--*` のスタイルはどの構成でも手動追記 / SCSS で用意します。
 
 ### Vite / Astro（統合プラグイン使用時）は自動反映（手動ビルド不要）
 
-`@lism-css/plugin` の統合プラグインを登録している場合、`lism.config.js` に props / tokens を追加すると、**dev サーバ / ビルドの CSS に自動反映されます**。追加クラス分の CSS を手動で追記したり `npx lism-css build` を回したりする必要はありません。dev 中に `lism.config.js` を変更すると HMR で CSS が再生成され、型 `.d.ts` も追従します。
-
-参照先の **CSS 変数の値そのもの**（`:root { --lts--2xl: .5em }` のような定義）も、`tokens` に値を書けば自動生成されます。値の定義・ユーティリティ生成・props 受理がまとめて反映されるため、`global.css` への手書きは不要です（既定値の上書きも可能）。
-
-```js
-// lism.config.js — 値そのものも config に集約できる
-export default {
-  tokens: {
-    lts: { '2xl': '.5em' }, // :root { --lts--2xl: .5em } + .-lts:2xl を自動生成
-  },
-};
-```
-
-> `is--*` クラスのスタイルは `traits` ではクラス名のみを追加するため、対応するスタイルは別途必要です（後述の手動追記 / SCSS を参照）。
+`@lism-css/plugin` の統合プラグインを登録している場合、`lism.config.js` に props / tokens を追加すると、**dev サーバ / ビルドの CSS に自動反映されます**。手動追記や `npx lism-css build` は不要で、dev 中の変更は HMR で CSS と型 `.d.ts` が追従します。`tokens` に書いた値は CSS 変数の定義（`:root { --lts--2xl: .5em }`）・ユーティリティクラス・props 受理がまとめて反映されるため、`global.css` への手書きも不要です（既定値の上書きも可）。
 
 軽微な追加であれば、props を増やさず Lism Props の `:value` 記法（→ [property-class.md](./property-class.md)）と `global.css` への手書きだけで済ませることもできます。
 
@@ -317,8 +304,7 @@ npx lism-css build --full   # full.css / full_no_layer.css も生成
 ```
 
 > **注意**:
-> - `tokens` に値を書けば、`-lts:2xl` の **ユーティリティクラス**と、参照先の CSS 変数（`:root { --lts--2xl: .5em }` のような **値そのもの**）の両方が CLI ビルドでも出力されます。値が `'-'` のキーはカタログ登録のみで `:root` 宣言を出力しません（`lh` のように CSS 変数を持たないものや、実値を手書きSCSS側へ置くもの）。
-> - `is--*` クラスのスタイルは自動生成されないため、手動で追加してください。
+> - `tokens` の値は CLI ビルドでも CSS 変数とユーティリティクラスの両方が出力されます。値が `'-'` のキーはカタログ登録のみで `:root` 宣言を出力しません（`flow` や `bdrs.inner` のように実値を手書きSCSS側へ置くもの）。
 > - `lism-css` パッケージ自体を上書きする処理のため、**パッケージ更新ごとに再実行**が必要です。
 
 ### 手動で CSS を追記
@@ -337,16 +323,15 @@ CLI を使わず、追加クラス分の CSS をプロジェクト側で書い
 }
 ```
 
-### SCSS で `lism.config.js` と整合させる
+### SCSS だけで値を追加する（`lism.config.js` を使わない構成）
 
-SCSS 経由で読み込む構成なら、`lism.config.js` と同じ追加分を `$props` の `utilities` 設定として書いておけば、ビルドコマンドなしで反映できます。
+`@lism-css/plugin` を使わない構成では `lism.config.js` は読み込まれない。SCSS の `$props` の `utilities` で値を追加し、コンポーネントからは `:value` 記法（`p=":box"`）で強制クラス化するか、HTML に直接クラスを書いて使う。
 
 ```scss
 @use '../path-to/node_modules/lism-css/scss/setting' with (
   $props: (
     'ta': ( utilities: ( 'justify': 'justify' ) ),
     'p': ( utilities: ( 'box': '2em' ) ),
-    'filter': ( utilities: ( 'blur': 'blur(3px)' ) ),
     'lts': ( utilities: ( '2xl': 'var(--lts--2xl)' ) ),
   )
 );

package/dist/data/guides/naming.md

@@ -28,12 +28,11 @@
 | 表記 | 条件 | 例 |
 | --- | --- | --- |
 | `s`, `m`, `l`, `xl`... | ベース値を中心に大小の段階を示す | `--fz--s`, `--fz--l` |
-| `base` | `:root`/`body` の初期値にセットされるもの | `--fz--base`, `--lh--base` |
+| `base` | `:root`/`body` の初期値にセットされるもの | `--fz--base`, `--hl--base` |
 | `10`, `20`, `30`... | `0`(`none`)基準で段階的に増加 | `--bdrs--20`, `--bxsh--30` |
 | セマンティック名 | 上記に当てはまらない場合 | `--ar--og` |
 
-> 🎵 **例外: opacity トークン**
-> opacity（`--o--mp` / `--o--p` / `--o--pp` / `--o--ppp`）は、音楽の強弱記号（piano 系列）に由来するセマンティック命名を採用している。`p`（piano / 弱く）の反復回数が多いほど透明度が増す構造で、「文字の反復回数で段階を表す」命名は Lism 内で opacity のみの例外。
+例外: opacity トークン（`--o--mp` / `--o--p` / `--o--pp` / `--o--ppp`）は文字の反復回数で段階を表す（由来は [tokens.md](./tokens.md#透明度-o)）。
 
 ### Property Class 用の変数
 
@@ -185,23 +184,8 @@ NG例: `flex` → `fx` としたうえで `flex-shrink` を `fsh` にする（`f
 .-bdrs:20         → border-radius: var(--bdrs--20);
 ```
 
-opacity トークンは音楽記号に由来する例外的な命名で、そのままクラス化される。
-
-```
-.-o:mp            → opacity: var(--o--mp);
-.-o:p             → opacity: var(--o--p);
-.-o:pp            → opacity: var(--o--pp);
-.-o:ppp           → opacity: var(--o--ppp);
-```
+opacity トークンもそのままクラス化される（`.-o:p` → `opacity: var(--o--p)`）。
 
 ### 長いキーワード値の省略
 
-6文字以上かつ省略しても意味が通るものは省略可:
-
-| 実際の値 | 省略名 | クラスの例 |
-| --- | --- | --- |
-| `uppercase` | `upper` | `-tt:upper` |
-| `lowercase` | `lower` | `-tt:lower` |
-| `fit-content` | `fit` | `-w:fit`, `-h:fit` |
-| `space-between` | `between` | `-ac:between`, `-jc:between` |
-| `currentColor` | `current` | `-bdc:current` |
+6文字以上かつ省略しても意味が通るものは省略可（`uppercase` → `-tt:upper` 等）。一覧は [property-class.md](./property-class.md#値の省略形例外一覧) を参照。

package/dist/data/guides/property-class/all-props.md

@@ -25,14 +25,14 @@
 | `fw` | `font-weight` | `-fw:light`, `-fw:normal`, `-fw:bold`, `-fw:100`〜`-fw:900` | — |
 | `ff` | `font-family` | `-ff:base`, `-ff:accent`, `-ff:mono` | — |
 | `fs` | `font-style` | `-fs:italic` | — |
-| `hl` | `--hl`（ハーフレディング） | `-hl:base`, `-hl:xs`, `-hl:s`, `-hl:l`, `-hl:0` | ✔ |
-| `lh` | `line-height`（`--hl` 経由・互換） | `-lh:base`, `-lh:xs`, `-lh:s`, `-lh:l`, `-lh:1` | — |
+| `hl` | `--hl`（ハーフレディング） | `-hl:base`, `-hl:xs`, `-hl:s`, `-hl:l`, `-hl:xl`, `-hl:0` | ✔ |
+| `lh` | `line-height`（倍率・`--lh` 経由） | `-lh:xs`, `-lh:s`, `-lh:m`, `-lh:l`, `-lh:xl`, `-lh:1` | — |
 | `lts` | `letter-spacing` | `-lts:base`, `-lts:s`, `-lts:l`, `-lts:xl` | — |
 | `ta` | `text-align` | `-ta:center`, `-ta:left`, `-ta:right` | — |
 | `td` | `text-decoration` | `-td:none` | — |
 | `tt` | `text-transform` | `-tt:upper`, `-tt:lower` | — |
 
-**注意:** Lism はハーフレディングで `line-height` を管理します（`line-height: calc(1em + var(--hl) * 2)`）。正規のプロパティは `hl` で、`--hl` にトークン値をセットします（`hl="0"` でハーフレディングなし、BP 指定可）。`lh` は互換ショートカットで、トークン値・`1` は `--hl` を制御し、`lh="1.7"` のような任意値はそのまま CSS `line-height` を出力します。新規コードでは `hl` を推奨します。
+**注意:** `line-height` は全要素で `var(--lh, calc(1em + var(--hl) * 2))` として管理されます。基本は `hl`（fz 非依存の固定量）を使い、fz に比例した行送りを保ちたい場合だけ `lh`（倍率）を使います。`lh` を指定した要素の子孫では `hl` は効きません。
 
 ### 表示・可視性
 
@@ -101,7 +101,7 @@
 
 | Prop | CSS プロパティ | プリセット値クラス | BP |
 | --- | --- | --- | --- |
-| `bdrs` | `border-radius` | `-bdrs:0`, `-bdrs:10`, `-bdrs:20`, `-bdrs:30`, `-bdrs:40`, `-bdrs:99`, `-bdrs:inner` | ✔ |
+| `bdrs` | `border-radius` | `-bdrs:0`, `-bdrs:10`, `-bdrs:20`, `-bdrs:30`, `-bdrs:40`, `-bdrs:50`, `-bdrs:99`, `-bdrs:inner` | ✔ |
 | `bdrs-tl` | `border-top-left-radius` | — | — |
 | `bdrs-tr` | `border-top-right-radius` | — | — |
 | `bdrs-br` | `border-bottom-right-radius` | — | — |

package/dist/data/guides/property-class/bd.md

@@ -12,10 +12,13 @@ Lism CSS のボーダーは、CSS 変数（`--bds` / `--bdw` / `--bdc`）で管
 `-bd` または `-bd-{side}` クラスが付くと、以下の初期値がセットされる。
 
 ```scss
+/* 変数の初期値だけ弱い位置に置く（@layer ビルドでは @layer lism-base、no_layer ビルドでは :where()） */
 :where(.-bd, [class*=" -bd-"], [class^="-bd-"]) {
   --bds: solid;
   --bdw: 1px;
   --bdc: var(--divider);
+}
+.-bd, [class*=" -bd-"], [class^="-bd-"] {
   border-width: var(--bdw);
   border-color: var(--bdc);
 }

package/dist/data/guides/references/authoring.md

@@ -1,13 +1,9 @@
 # 実装プランの作り方（C0–C8詳細・出力フォーマット）
 
-Lism CSSで新規UI・セクション・コンポーネントを書く前に作る「実装プラン」の詳細編です。実装フローの全体像・資料確認トリガー表・判定記号は`SKILL.md`を正本とします。ここでは各チェック項目（C0–C8）の詳細とプランの出力フォーマットをまとめます。
-
-判定記号（✅/🔁/⏸、`✅新規`・`✅例外`の注記を含む）の定義は`SKILL.md`の「判定記号」を参照してください。
+Lism CSSで新規UI・セクション・コンポーネントを書く前に作る「実装プラン」の詳細編。実装フロー・資料確認トリガー・判定記号（✅/🔁/⏸と注記）は`SKILL.md`が正本で、ここではC0–C8の詳細とプランの出力フォーマットだけを扱う。
 
 ## 資料確認
 
-どの操作の手前で何を読むかは`SKILL.md`の「資料確認トリガー」を正本とする。
-
 ### 初期確認（C0前に実行）
 
 新規UI/コンポーネント/セクション、またはスクショ/Figma等のデザイン再現では、C0に入る前に対象へ明らかに関係する最小限の詳細ファイルを実際に開く。
@@ -18,15 +14,15 @@ Lism CSSで新規UI・セクション・コンポーネントを書く前に作
 初期確認した資料: primitives/l--stack.md, primitives/l--columns.md, tokens.md
 ```
 
-新規UI/コンポーネント/セクションで初期確認した資料が空のまま実装に入ってはいけない。「必要なら参照」とだけ書くのも不可。軽微な既存パターン内の修正で既存コード確認のみで足りる場合は、その旨を明記する。
+空のまま、または「必要なら参照」とだけ書いて実装に入らない。既存コード確認だけで足りる軽微な修正では、その旨を書く。
 
 ### 資料確認の記録
 
-読んだ資料は「初期確認」「実装中」を区別して資料確認ログに記録する。提出前に、🔁が✅または⏸へ解消されたかを照合する。
+読んだ資料は「初期確認」「実装中」を区別して資料確認ログ（「出力フォーマット」参照）に記録する。
 
 ## C0–C8 実装前チェック詳細
 
-各Cは「列挙/照合・判定/決め方/参照先/よい例・避けたい例」の観点で判断します。
+各Cは「列挙/照合・判定/決め方/参照先/よい例・避けたい例」の観点で判断する。
 
 ### C0: 入力整理
 
@@ -40,8 +36,7 @@ Lism CSSで新規UI・セクション・コンポーネントを書く前に作
 
 - **列挙**: 縦並び/横並び/カラム/メディア枠/幅制御/オーバーレイ/全体リンクなどの構造、要素、heading level、landmark。
 - **照合・判定**: 標準Primitiveで組める→✅。カラム系など迷う→🔁。`@lism-css/ui`で済む→✅または🔁。使うPrimitive詳細を未読なら🔁のまま実装しない。
-- **決め方**: Layout Primitive→Trait→Atomic→UIコンポーネントの順。`<div>`+Property ClassやCSSで押し切らない。
-- **Primitive優先ガード**: `<div>`+CSSで押し切らず、`SKILL.md`の「目的別実装ガイド」で候補を先に確認する。この判断を書かずに実装しない。
+- **決め方**: `SKILL.md`の「目的別実装ガイド」で候補を先に確認し、Layout Primitive→Trait→Atomic→UIコンポーネントの順に選ぶ。`<div>`+Property ClassやCSSで押し切らない。この判断を書かずに実装しない。
 - **参照先**: `SKILL.md`の「目的別実装ガイド」、`primitive-class.md`、`primitives/l--*.md`、`trait-class.md`、`components-core.md`、`components-ui.md`、`antipatterns-layout.md#レイアウト選択ミス`。
 - **よい例・避けたい例**: OK=`<Columns cols={3}>`、`<Frame ar="16/9">`、Astroなら`import { Stack, Columns, Frame } from 'lism-css/astro'`。罠=素の`<div>`だらけ、`<div -d:grid gtc=...>`、手組みメディア枠、最外殻Wrapper。
 
@@ -56,10 +51,10 @@ Lism CSSで新規UI・セクション・コンポーネントを書く前に作
 ### C3: 命名設計
 
 - **列挙**: 新設する`b--`/`c--`のクラス名とBlock/Element/Modifier構造、独自CSSを置くLayer。
-- **照合・判定**: プレフィックス後の名前が規約に合う→✅。ハイフンや`__`がある→🔁。ベーススタイルを CSS 側で管理する共通基礎部品→`✅新規`（`b--`）。それ以外のカスタムクラス→`✅新規`（`c--`）。公開API・CMS・外部JS・E2E依存→⏸。独自CSSがLayer外になる→🔁。
-- **決め方**: `naming.md`に従う。Block名にハイフンは使わず、Element区切りは`_`ひとつ、Modifierは`--`ふたつ（`b--`も`c--`と同記法）。分類は`b--`の3条件（サイト共通の繰り返し利用・ベーススタイルを CSS 側で管理・ボタン/バッジ/カード級の粒度。`css-rules.md#block-classb--`参照）で決める（すべて満たす→`b--`／それ以外→`c--`）。独自CSSは必ず`@layer lism-custom {}`内に置く（`b--`のベーススタイルだけ`@layer lism-block {}`）。
-- **参照先**: `naming.md`、`css-rules.md#block-classb--`、`css-rules.md#custom-classc--`、`css-rules.md#独自クラスの選び方2分類`、`antipatterns-layout.md#クラス名の命名ミス`。
-- **よい例・避けたい例**: OK=`c--featureCard`、`c--featureCard_body`、既存命名がアンダースコア寄せなら`c--feature_card`。罠=`c--feature-card`、`c--hero__inner`（正しくは`c--hero_inner`）、`c--feature-card__body`（正しくは`c--featureCard_body`）。
+- **照合・判定**: プレフィックス後の名前が規約に合う→✅。ハイフンや`__`がある→🔁。CSSで参照しないElement（`c--name_elem`）を付けている→🔁（外す）。ベーススタイルを CSS 側で管理する共通基礎部品→`✅新規`（`b--`）。それ以外のカスタムクラス→`✅新規`（`c--`）。公開API・CMS・外部JS・E2E依存→⏸。独自CSSがLayer外になる→🔁。
+- **決め方**: 記法とBlock名の付け方は`naming.md`、`b--`/`c--`の分類（`b--`は3条件をすべて満たす時だけ）と置くLayerは`css-rules.md`に従う。
+- **参照先**: `naming.md`、`css-rules.md#block-classb--`、`css-rules.md#custom-classc--`、`css-rules.md#独自クラスの選び方2分類`、`antipatterns-layout.md#クラス名の命名ミス`、`antipatterns-layout.md#css-の無い-element-クラスを付ける`。
+- **よい例・避けたい例**: OK=`c--featureCard`、`c--featureCard_body`、既存命名がアンダースコア寄せなら`c--feature_card`。罠=`c--feature-card`、`c--hero__inner`（正しくは`c--hero_inner`）、`c--feature-card__body`（正しくは`c--featureCard_body`）、CSSで参照しない`c--featureCard_title`（外す）。
 
 ### C4: 状態・バリエーション設計
 
@@ -72,24 +67,24 @@ Lism CSSで新規UI・セクション・コンポーネントを書く前に作
 ### C5: 値・トークン照合
 
 - **列挙**: spacing/color/fz/radius/shadow/size/lh/ltsなど、使う予定の値をすべて列挙。
-- **照合・判定**: `tokens.md`に完全一致→✅。typo・既存規約上明確な置換→🔁（`tokens.md`で正規トークンを確認して置換し✅へ）。近似丸め・任意色・ブランド色・再現度の判断→⏸。`antipatterns.md`の「直書きしてよい例外」に該当→`✅例外`。`✅例外`にできるのはこの許可リストだけで、「ユーザー指示に基づく実測値」のような例外カテゴリを自作しない。
+- **照合・判定**: 「照合の手順」の3に従う（完全一致→✅／typo等の明確な置換→🔁にして`tokens.md`で確認後✅／近似丸め・任意色・ブランド色→⏸／許可リスト該当→`✅例外`）。
 - **決め方**: トークン値を流用。⏸は本ファイルの「デザインデータ取り込みフロー」に従い、トークン候補と差分表を出して確認まで書かない。CSSへ書く前に、Lism Props/Property Classで表せる値かも同時に確認する。インストール済みの`lism-css`がある環境では、実CSS（`main.css`）やコンポーネント実装でトークン・クラスの実在を確認してから採用するとtypoを防げる。
 - **参照先**: `tokens.md`、`property-class.md`、`antipatterns.md#token-typo存在しない値`、`antipatterns.md#px--固定値の直書き`。
 - **よい例・避けたい例**: OK=`-fz:xs -p:10 -bgc:base-2 -bdrs:10`。罠=`padding:13px`、`bgc="secondary"`。
 
 ### C6: レスポンシブ方針
 
-- **列挙**: 各値のbaseの値、切替BP（sm/md/lg）、container queryかmedia queryか、container運用なら祖先`isContainer`の有無、固定Grid化していないか。
-- **照合・判定**: baseの値あり・標準BP・必要な祖先あり→✅。base抜け・xs誤用→🔁。`$is_container_query:0`等でmedia query運用が確認できる場合は`isContainer`必須にしない→✅。固定列をレスポンシブ化するなど挙動変更→⏸。
-- **決め方**: baseの値を必ず置く。標準BPへ寄せる。同じ値の繰り返しは省略する。等幅カラムはまず`Columns cols={[1, null, 3]}`などPrimitiveのレスポンシブAPIで表せるか確認し、できない場合だけ`@container`/`@media`を自分で書く。
+- **列挙**: 各値のbaseと切替BP（sm/md/lg）、container queryかmedia queryか、container運用なら祖先`isContainer`の有無、固定Grid化していないか。
+- **照合・判定**: 標準BP・必要な祖先あり→✅。xs誤用→🔁。`$is_container_query:0`等でmedia query運用が確認できる場合は`isContainer`必須にしない→✅。固定列をレスポンシブ化するなど挙動変更→⏸。
+- **決め方**: 標準BPへ寄せる。同じ値の繰り返しは省略する。等幅カラムはまず`Columns cols={[1, null, 3]}`などPrimitiveのレスポンシブAPIで表せるか確認し、できない場合だけ`@container`/`@media`を自分で書く。
 - **参照先**: `responsive.md`、`trait-class/is--container.md`、`property-class.md`、`primitive-class.md#カラムレイアウト-primitive-の使い分けガイド`。
-- **よい例・避けたい例**: OK=`p={{ base: '20', md: '30' }}`+祖先`isContainer`、`<Columns cols={[1, null, 3]}>`。罠=`gtc="repeat(3,1fr)"`固定、カード列数のためだけに`@container`直書き、base抜け、container祖先なし。
+- **よい例・避けたい例**: OK=`p={{ base: '20', md: '30' }}`+祖先`isContainer`、`<Columns cols={[1, null, 3]}>`。罠=`gtc="repeat(3,1fr)"`固定、カード列数のためだけに`@container`直書き、container祖先なし。
 
 ### C7: CSSに書くもの/Propsに移すもの
 
 - **列挙**: CSSへ書く予定の各宣言を「Property Class/Propsへ移す宣言」と「CSSにしか書けない宣言」に分ける。`c--*`のCSSに残る宣言を実装プランに明記する。
 - **照合・判定**: `c--*`のクラスで1つの要素にだけ効く見た目の指定→✅マークアップへ。擬似クラス・擬似要素・状態切替・子孫セレクタ→✅CSSへ残す。C3で`b--`と決めた部品のベーススタイル→✅`@layer lism-block`へ残す（トークン使用。BP切替・hover・例外調整はProperty Class）。下表の宣言が`.c--*` CSSに残る→🔁未通過。
-- **決め方**: `-{prop}:{value}`またはLism Propsへ移す。`.c--*`はCSSが空でも何のパーツかを示す名前として残す。
+- **決め方**: `-{prop}:{value}`またはLism Propsへ移す。本体クラス`c--name`はCSSが空でも何のパーツかを示す名前として残す。ElementはCSSで参照しなくなったら外す。
 - **参照先**: `property-class.md`、`css-rules.md#custom-classc--`、`antipatterns.md#property-class-で書けるのに-css-で書く`。
 - **移行表**:
 
@@ -110,23 +105,19 @@ Lism CSSで新規UI・セクション・コンポーネントを書く前に作
 
 ### C8: 既定値の確認
 
-- **列挙**: 使うPrimitiveが既に持つ既定CSSを確認し、同値をProps/Property Classで重ねていないか。
+- **列挙**: 使うPrimitiveが既に持つ既定CSSを確認し、同値をProps/Property Classで重ねていないか。セマンティックコンポーネント（`Text`/`Inline`/`Group`等）にデフォルト要素と同じ`as`を付けていないか。
 - **照合・判定**: 既定と同値→足さない。既定と違う意図的上書き→✅。ガイドに未整備のPrimitive既定→今後の整備対象にする。
 - **決め方**: `primitives/l--*.md`の「既定の挙動」を見る。念のための`ai="center"`/`ov="hidden"`/直下img`w/h/object-fit`を足さない。
-- **参照先**: `primitives/l--cluster.md`、`primitives/l--frame.md`、`primitive-class.md`、`components-core.md`。
-- **よい例・避けたい例**: OK=`<Cluster g="15">`、`<Frame ar="16/9"><img /></Frame>`。罠=`<Cluster fxw="wrap" ai="center">`、Frame直下imgに`-w:100%`や`object-fit`。
+- **参照先**: `primitives/l--cluster.md`、`primitives/l--frame.md`、`primitive-class.md`、`components-core.md#セマンティックコンポーネント`。
+- **よい例・避けたい例**: OK=`<Cluster g="15">`、`<Frame ar="16/9"><img /></Frame>`。罠=`<Cluster fxw="wrap" ai="center">`、Frame直下imgに`-w:100%`や`object-fit`、`<Text as="p">`。
 
 ## 出力フォーマット
 
-実装前チェックの成果物を実装プランと呼びます。各行に必ず判定記号（定義は`SKILL.md`参照）を付け、⏸が残る項目はその部分を実装しないで先にユーザー確認します。
-
-値照合付きレベルでは、実装プラン全体をチャットの返答としてではなく`.lism/plan.md`として保存します（固定名・上書き。冒頭のメタデータヘッダに日時・対象タスク・スケール前提とその判定根拠を書く）。規約は[`verification.md`](./verification.md)を参照してください。
+実装前チェックの成果物を実装プランと呼ぶ。各行に判定記号を付ける。値照合付きレベルでは`.lism/plan.md`へ保存する（規約は[`verification.md`](./verification.md)）。
 
 ### 軽量レベル
 
-小変更では3〜5行で十分です。
-
-例:
+例（3〜5行）:
 
 ```md
 - ✅ 構造: 既存`Stack`内へ1項目追加。Primitive変更なし。
@@ -138,7 +129,7 @@ Lism CSSで新規UI・セクション・コンポーネントを書く前に作
 
 #### 資料確認ログ
 
-SKILL.md以外に実際に開いたファイルや外部サイトのページurlを、「初期確認」と「実装中」に分けて列挙します。
+SKILL.md以外に実際に開いたファイルや外部サイトのページurlを、「初期確認」と「実装中」に分けて列挙する。
 
 例:
 | タイミング | 種類 | 確認した資料 | 用途 |
@@ -147,19 +138,17 @@ SKILL.md以外に実際に開いたファイルや外部サイトのページurl
 | 実装中 | 📄 | `tokens.md` | デザイン値とトークン照合（トークン丸めトリガー） |
 | 実装中 | URL | `https://lism-css.com/docs/naming.md` | `c--*`命名トリガー |
 
-各行は実装プランの判断項目（特に🔁）と対応させ、提出前に🔁が✅/⏸へ解消されたかを照合します。
+各行を実装プランの判断項目（特に🔁）と対応させる。
 
 #### 🔁判断行
 
-未読の判断項目そのものに🔁と読む資料を紐づけます。
+未読の判断項目そのものに🔁と読む資料を紐づける。資料を読んだら同じ行を✅または⏸へ更新する。
 
 | 判断項目 | 採用案 | 読む資料 | 判定 |
 | --- | --- | --- | --- |
 | カード一覧 | `Columns cols={[1, null, 3]}` | `primitives/l--columns.md` | 🔁 |
 | hover指定 | `hov={{ bgc: 'base-2' }}` | `property-class/hov.md` | 🔁 |
 
-対応資料を読んだら、同じ判断行を✅または⏸へ更新します。提出前に🔁が残っている場合は未通過です。
-
 #### 構造表
 
 | 対象領域 | 採用Primitive・コンポーネント | 理由 | 参照先 | 判定 |
@@ -168,7 +157,7 @@ SKILL.md以外に実際に開いたファイルや外部サイトのページurl
 
 #### トークン表
 
-値照合付きでは`デザイン値`と`差分`列を必須にします。
+値照合付きでは`デザイン値`と`差分`列を必須にする。
 
 | 用途 | デザイン値 | 採用トークン | 差分 | 判定 |
 | --- | --- | --- | --- | --- |
@@ -197,9 +186,9 @@ SKILL.md以外に実際に開いたファイルや外部サイトのページurl
 
 #### 入力種別と既定動作
 
-デザイン値の扱いは、入力の種類とプロジェクトの段階で決まります。「正確に再現して」等の指示があってもこの分岐が既定動作で、ユーザー指示を根拠に`✅例外`を自作してはいけません。
+デザイン値の扱いは、入力の種類とプロジェクトの段階で決まる。「正確に再現して」等の指示があってもこの分岐が既定動作。
 
-この表は⏸確認を省略する許可ではありません。丸め・任意色などの⏸判定自体は最小ゲート・C5のとおりで、既定動作は「確認時に第一候補として提示する案」と「確認が取れない場合に前提として選ぶ選択肢」を定めるものです（`SKILL.md`「判定記号」の⏸運用を参照）。
+この表は⏸確認を省略する許可ではない。既定動作は、確認時に第一候補として出す案と、確認が取れない時に`✅前提`として選ぶ選択肢（`SKILL.md`「判定記号」の⏸の項）を定める。
 
 | 入力 | 既定動作 |
 | --- | --- |
@@ -215,28 +204,27 @@ SKILL.md以外に実際に開いたファイルや外部サイトのページurl
    - 完全一致→✅そのまま採用。
    - typo・既存規約上明確な置換（`secondary`→`base-2`など）→`tokens.md`で正規トークンを確認して置換し、✅にする（ユーザー確認は不要）。
    - 近似丸め・任意色・ブランド色・密度/再現度の判断→⏸。A=最寄りトークンに丸める/B=カスタムトークン化または基準値（`--s-unit`等）の上書き/C=px直書き（例外）を提示する。この選択肢の定義はここが正本。
+   - `antipatterns.md`の「直書きしてよい例外」に該当→`✅例外`（条件は`SKILL.md`「判定記号」）。
 4. **カスタムトークン化の条件**: 同値が複数箇所で再利用される、またはデザインシステム上の意味を持つ場合は候補にする。1回限りの局所値は丸めか例外で済ませる。
 5. **デザインデータが無い場合**: 差分表は省略し、既存トークンから意味が近い値を選ぶ。新規数値が必要な時だけ⏸にする。
 
-`--s-unit`などの基準値をプロジェクトが上書きしているとpxの完全一致判定が変わります。値照合付きでは上書きの有無を先に確認してください。
-
-プロセス違反の実例（NG）:
+`--s-unit`などの基準値をプロジェクトが上書きしているとpxの完全一致判定が変わる。値照合付きでは上書きの有無を先に確認する。
 
-- C5に「ユーザー要件の『正確に再現』に基づくページ固有実測値として採用」のような1行を書いて値照合を包括免除し、差分表を省略する。値照合付きレベルでトークン差分表の無い実装プランは無効。
+実測pxを包括的に例外化するNG例は[`antipatterns.md`](../antipatterns.md#px--固定値の直書き)の「実測pxの包括例外化」。
 
 #### 値マッピングの初期すり合わせ
 
-デザインシステムが未確立のプロジェクトで初期実装を任された場合は、値ごとに⏸を出すのではなく、実装前にマッピング方針を一括ですり合わせます。トークン差分表と確認事項表をこの一括確認の提出物として使います。
+デザインシステムが未確立のプロジェクトで初期実装を任された場合は、値ごとに⏸を出すのではなく、実装前にマッピング方針を一括ですり合わせる。トークン差分表と確認事項表をこの一括確認の提出物として使う。
 
 - スペース・サイズ・タイポグラフィ: どの範囲を最寄りトークンへ丸め、どこを具体値（px直書き・カスタムトークン）にするかの境界。
 - カラー: デザイン内の各色をどのセマンティックカラー（`--brand`/`--accent`/`--base`/`--base-2`/`--text`/`--text-2`等）へ割り当てるか。
 - デザイン画像しか無い場合は、書き出し倍率・想定キャンバス幅の前提もここで確認する。倍率はC0の実測・整合チェックで確定してから提示する。
 
-ユーザー確認が取れない場合は、原則準拠側（最寄りトークンへの丸め・セマンティック割り当て案）を前提として実装プランに明示して進め、完了報告で代替案とともに列挙します（`SKILL.md`「判定記号」の⏸運用を参照）。
+確認が取れない場合の進め方は`SKILL.md`「判定記号」の⏸の項。
 
 ### 提出前セルフチェックへの接続
 
-実装後、実行レベルが「通常」「値照合付き」の場合は、実装プランと実装を1行ずつ照合します（チェック項目とレベル別の扱いは`SKILL.md`の「提出前セルフチェック」を参照）。この照合とルール照合は、サブエージェント／タスク委任機能が使える環境では評価サブエージェントに実行させ、報告を`.lism/review.md`へ保存します（[`verification.md`](./verification.md)）。
+`SKILL.md`「提出前セルフチェック」で実装プランと実装を照合した時の分類例:
 
 | 計画項目 | 実装結果 | 分類 | 対応 |
 | --- | --- | --- | --- |

package/dist/data/guides/references/verification.md

@@ -1,8 +1,8 @@
 # 検証の分離（`.lism/`規約と評価サブエージェント）
 
-提出前チェックの実行を実装担当の本人から分離し、実装プランと評価結果をユーザーが後から確認できるファイルとして残すための規約です。実装フロー・チェック項目の正本は`SKILL.md`（実装フロー・提出前セルフチェック）、実装プランの中身と書式は[`authoring.md`](./authoring.md)を参照してください。
+提出前チェックの実行を実装担当の本人から分離し、実装プランと評価結果をユーザーが後から確認できるファイルとして残すための規約。フローとチェック項目は`SKILL.md`、実装プランの書式は[`authoring.md`](./authoring.md)が正本。
 
-`lism-css-guide`の実装フローでは、事前チェック実行レベルが「通常」「値照合付き」の場合だけこの規約を適用します。「不要」「軽量」では`.lism/`へのファイル作成も評価サブエージェントへの委任も行いません（`SKILL.md`「事前チェック実行レベル」参照）。このレベル条件は`lism-css-guide`固有のもので、`.lism/`規約をここから参照する他のスキル（`lism-css-refactor`等）には適用されません。他のスキルからの利用時は、ファイルを作るかどうかは各スキル側の手順に従ってください。
+`lism-css-guide`では実行レベルが「通常」「値照合付き」の時だけ適用する（「不要」「軽量」では`.lism/`も評価委任も無し）。このレベル条件は`lism-css-guide`固有で、`.lism/`規約を参照する他のスキル（`lism-css-refactor`等）ではファイルを作るかどうかを各スキルの手順に従う。
 
 ## `.lism/`作業ディレクトリ
 
@@ -11,7 +11,7 @@ Lism実装作業の成果物（実装プラン・評価報告）は、プロジ
 | ファイル | 内容 | 作成タイミング |
 | --- | --- | --- |
 | `.lism/plan.md` | 実装プラン（トークン差分表・構成表を含む） | 値照合付きレベルの実装前チェック時 |
-| `.lism/review.md` | 評価サブエージェント（委任できない環境では本人）による評価報告 | 通常・値照合付きレベルの提出前セルフチェック時（不要・軽量では作成しない） |
+| `.lism/review.md` | 評価サブエージェント（委任できない環境では本人）による評価報告 | 通常・値照合付きレベルの提出前セルフチェック時 |
 
 - **固定名・上書き方式**。タスクごとに別名を作らない。照合先が一意に決まることが、評価サブエージェントや将来の機械チェックの前提になる。複数タスクの文脈は各ファイル冒頭のメタデータヘッダで区別する。
 - メタデータヘッダには日時・対象タスク・スケール前提（デザイン再現時。判定根拠付き）を書く。
@@ -30,7 +30,7 @@ scale: PNGは2880px幅=1440px設計の2x書き出し（画像実寸と行送り
 
 ## 評価サブエージェントへの委任
 
-提出前セルフチェックを実装した本人だけで行うと、「正確に再現する」等のゴールへの執着や、自分で立てたプランを疑いにくくなる心理から、例外を自己承認してしまいやすくなります。サブエージェント／タスク委任機能が使える環境では、照合を読み取り専用の評価サブエージェントに委任します。使えない環境では、同じ照合を本人が`SKILL.md`「提出前セルフチェック」の順に自分で実行します。
+本人だけの照合は自分のプランを疑いにくく、例外を自己承認しやすい。委任できる環境では読み取り専用の評価サブエージェントに委任し、できない環境では本人が`SKILL.md`「提出前セルフチェック」の順に行う。
 
 運用ルール:
 

package/dist/data/guides/responsive.md

@@ -34,7 +34,7 @@ Smartphone ──┬── Tablet (Portrait) ──┬── Tablet (Landscape)
 
 **`xs` / `xl` は opt-in**:
 - デフォルト値は `0`（無効）で、CSS は出力されません。`lism.config.js` の `breakpoints` でサイズを与えると有効化されます（customize.md 参照）。
-- 型（Lism コンポーネント）でも `sm` / `md` / `lg` のみがデフォルトで補完・許可されます。`xs` / `xl` を使う場合は `declare module 'lism-css'` で `BreakpointRegistry` を拡張して解禁します。
+- 型（Lism コンポーネント）でも `sm` / `md` / `lg` のみがデフォルトで補完・許可されます。`@lism-css/plugin` の統合プラグイン使用時は有効化した BP を反映した `lism-env.d.ts` が自動生成されるため手書き不要（customize.md 参照）。プラグインを使わない構成では `declare module 'lism-css'` で `BreakpointRegistry` を拡張して解禁します。
 
   ```ts
   // src/lism.d.ts など
@@ -85,6 +85,7 @@ Smartphone ──┬── Tablet (Portrait) ──┬── Tablet (Landscape)
 **仕組み:**
 - BPクラス `-{prop}_{bp}` は `@container (min-width: ...)` 内で発火し、`--{prop}_{bp}` 変数で切り替え先の値を指定
 - コンテナクエリ採用のため、レスポンシブ値を使うには祖先要素に `is--container` などコンテナ宣言が必要
+- base 値は任意。省くと BP 未満はそのプロパティの既定値のまま（例: `-d_sm` + `--d_sm: none` で sm 以上だけ非表示）
 - 出力形式はプロパティによって 2 パターン（基本 / 例外）
 
 **基本パターン** — BP 用変数を直接読む:
@@ -125,37 +126,16 @@ Smartphone ──┬── Tablet (Portrait) ──┬── Tablet (Landscape)
 
 ## Authoring時の確認ルール
 
-### base値を必ず置く
-
-BP専用値だけを書くと、BP未満で値が未指定になります。配列では先頭、オブジェクトでは`base`、HTMLでは`-{prop}:{value}`を必ず置きます。
-
-| NG | OK |
-| --- | --- |
-| `<Box p={{ sm: 30 }}>` | `<Box p={{ base: '20', sm: '30' }}>` |
-| `<div class="-p_sm" style="--p_sm:var(--s30)">` | `<div class="-p:20 -p_sm" style="--p_sm:var(--s30)">` |
+NG→OK例は [antipatterns-layout.md](./antipatterns-layout.md#レスポンシブ抜け) の「レスポンシブ抜け」「レスポンシブ配列の冗長指定」を参照。
 
 ### 冗長配列は圧縮する
 
-前のBPと同じ値を繰り返さない。変わらないBPは`null`でスキップし、全BPで同じ値なら単一値にします。
-
-| NG | OK |
-| --- | --- |
-| `fxd={['column', 'column', 'row']}` | `fxd={['column', null, 'row']}` |
-| `p={['20', '20', '20']}` | `p="20"` |
-| `cols={[1, 1, 3]}` | `cols={[1, null, 3]}` |
-
-ただし、既存コードの型・生成仕様で`null`が使えない場合は既存パターンを優先します。レスポンシブ差分を誤って単一値化しないでください。
+前のBPと同じ値を繰り返さない。変わらないBPは`null`でスキップし、全BPで同じ値なら単一値にします。ただし、既存コードの型・生成仕様で`null`が使えない場合は既存パターンを優先し、レスポンシブ差分を誤って単一値化しないでください。
 
 ### container query運用では祖先`isContainer`を確認する
 
 デフォルトではレスポンシブProperty Classは`@container`で発火します。レスポンシブ値を載せる要素の祖先に`isContainer`/`is--container`があるか確認してください。
 
-```jsx
-<Stack isContainer>
-  <Box p={{ base: '20', md: '40' }}>...</Box>
-</Stack>
-```
-
 `$is_container_query:0`などの設定でmedia query運用が確認できる場合は、`isContainer`祖先は必須ではありません。設定が不明な場合は、既存SCSS設定・`customize.md`・生成CSSを確認してから判断してください。
 
 ### `isContainer`を置く位置で挙動が変わる

package/dist/data/guides/set-class.md

@@ -74,7 +74,7 @@ Lism CSSでは、クラスを持つリスト（`ul` / `ol`）ではスタイル
 
 ## `set--bxsh`
 
-`SHADOW` トークン変数（`--bxsh--{N}`）を再計算するためのクラスです。`:root` で定義される `--shc`（影の色）を特定要素で上書きしたい時に利用します。
+`SHADOW` トークン変数（`--bxsh--{N}`）を再計算するためのクラスです。`:root` で定義される `--shc`（影の色）を特定要素で上書きしたい時に利用します。近い側の影色 `--shc--near` も `--shc` から再計算されるため、2層の影がまとめて変わります。
 
 使用例:
 ```html