phy: 複数のバリアントで成立するキーはVariantごとに複製して置く

隣り合うキャップが同じフットプリントを食い合う基板(MACRO1)があり、選択を独立な
VariantGroupに必ず分解できるわけではない。分解を強いると、キャップが重なる組み合わせを
作れてしまう。複製してもELCは接続先を、IDXは番号を共有できるので他レイヤーは壊れない。
どのキーノードが同じ物理キーかはBeyond KLEが判定せず、設計者の情報として扱う。

前のコミットで「独立したVariantGroupに分けて表す」と書いたが、MACRO1は下段を含めると
分解できない。あわせて訂正する。

Journal: journal/2026-09-21-variant-shared-key.md

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01246a5KFLmwcRXriZvX8fdJ

PHYレイヤー.md

@@ -149,8 +149,8 @@ PHYは全バリアントのキーを同時に持つ。基板上のフットプ
 - 部品ノードもVariantの配下に置ける。1Uキーとロータリーエンコーダーの選択がこれにあたる
 - Variantの中に別のVariantGroupを置ける。あるバリアントを選んだときだけ現れる選択肢を表す
 - 選択箇所が複数ある場合はVariantGroupを複数置く。同じ親の下に並べてよい
-- 複数の選択肢に共通して存在するキーは、選択を独立したVariantGroupに分けて表す。
+- 選択が互いに独立なら、VariantGroupを分けて選択肢の数を減らしてよい。
-  ANSI/ISOとBackspaceの分割のように、1つの選択肢リストに畳まれている基板があるため
+  ANSI/ISOとBackspaceの分割のように、独立な2つの選択が1つの選択肢リストに畳まれている基板がある
 
 VariantGroupはクラスターと同じ変換を持つ。Variantは変換を持たない。
 バリアントは同じ場所を占める代替物であり、選択によって配下の絶対配置が動く構造を作らないため。
@@ -159,6 +159,10 @@ VariantGroupはクラスターと同じ変換を持つ。Variantは変換を持
 サイズや形が変わるキーは、同じキーを書き換えるのではなく、別のキーノードとして各Variantに置く。
 ANSI EnterとISO Enterは別のIDを持つ2つのキーであり、同じ場所に重なる。
 
+同じ位置・同じサイズのキーが複数のバリアントで成立する場合も同じで、Variantごとに別のキーノードを置く。
+隣り合うキャップが同じフットプリントを食い合う基板があり、選択を分解できるとは限らないため。
+どのキーノードが同じ物理キーを指すかはBeyond KLEが判定しない。設計者が知っている情報として扱う。
+
 VariantGroupは既定のバリアントを1つ持つ。KLE JSONのように単一の配置を要求する出力は、
 VariantGroupごとにバリアントを1つ選んでから階層を畳んで生成する。既定値はそのときの初期選択になる。
 編集中にどのバリアントを表示しているかはエディタの状態であり、PHYには保存しない。
@@ -400,14 +404,6 @@ Beyond KLEはスイッチの品種を持たないため、対応づける先が
 - 現状の認識: キーのローカル原点(左上角)・キー中心・境界矩形の角と中心が候補。相対グリッドとは別の機構になる
 - 格上げ条件: 原点移動を実装し、吸着なしで足りるか、足りない場合どの候補が要るかを確認する
 
-### P-15 提供されない組み合わせを禁じる必要があるか
-
-- 位置づけ: 未解決の問い。本文「レイアウトバリアント」は複数のVariantGroupの組み合わせに制限を持たない
-- 現状の認識: 選択肢をまたいで共通のキーを持つ基板は実在し、独立した選択に分けてVariantGroupを2つ置けば
-  キーを複製せずに表せる。ただし2つの選択の積のうち一部しか提供しない基板(MACRO1)があり、
-  今の木では提供されない組み合わせも選べてしまう
-- 格上げ条件: 組み合わせの禁止を表現する必要があるかをユーザーが決める
-
 ### P-16 KLE本家が拒否するJSONを取り込むか
 
 - 位置づけ: 未解決の問い。本文「KLE JSONの取り込み」が扱えていない

journal/2026-09-21-variant-shared-key.md

@@ -1,14 +1,21 @@
 # 複数のバリアントで共通のキーを持つ基板があるか
 
-PHY P-15 の検証。
-
 ## 結論
 
-実在する。ただし稀で、どれも「独立した2つの選択」を1つの選択肢リストに畳んだ結果だった。
+実在する。そのうえで、共通キーはVariantごとに複製して置く。同じ物理キーかどうかはBeyond KLEが判定しない。
-VariantGroupを2つ並べれば、キーを複製せずに表せる。
 
-残る問題は別のところにある。MACRO1 は2つの選択の積4通りのうち3通りしか提供していない。
+分解して複製を避けられる基板もあるが、避けられない基板もある。
-VariantGroupを2つ置くと、基板が提供しない4通り目も選べてしまう。
+
+| ボード | 選択肢 | 分解 |
+| --- | --- | --- |
+| LW67 | ANSI / ANSI Split Backspace / ISO / ISO Split Backspace | 独立した2つの選択の積。VariantGroupを2つに分ければ複製は要らない |
+| MACRO1 | Numpad / Southpaw / Macropad | 分解できない。独立な選択に割ると、キャップが重なる組み合わせが作れてしまう |
+
+複製を許す判断の根拠は、複製しても他レイヤーが壊れないこと。
+ELCは排他キーで接続先の組を共有でき、IDXは `order` の配列形式で番号を共有できる。
+MAPは同じキーコードを2回書くことになるが、どれが同じ物理キーかは設計者が知っている。
+位置で自動判定しようとしても、排他キーは位置もサイズも違ってよい(2UのBackspaceと分割後の1U)ので、
+判定の基準にならない。
 
 ## 調べ方
 
@@ -17,42 +24,47 @@ VIAは1つのキーを1つの選択肢にしか置けないので、複数の選
 生ラベルの4番目(`"行,列"` の形)がオプション番号と選択肢番号で、これで選択肢ごとのキー集合を作り、
 マトリクス位置と形状(x, y, w, h, r)が一致するキーが複数の選択肢に現れるものを探した。
 
-3択以上のオプション415件のうち、「一部の選択肢だけに現れる共通キー」を持つのは2件。
+3択以上のオプション415件のうち、該当するのは2件だけだった。
 
-| ボード | 選択肢 | 共通キーの現れ方 |
+## LW67
-| --- | --- | --- |
-| LW67 | ANSI / ANSI Split Backspace / ISO / ISO Split Backspace | {ANSI,ANSI-split} {ISO,ISO-split} {ANSI,ISO} {ANSI-split,ISO-split} |
-| MACRO1 | Numpad / Southpaw / Macropad | {Numpad,Macropad} {Southpaw,Macropad} |
 
-## 中身
+ANSI/ISO と Backspace分割の2択の積で、4つの選択肢はその全組み合わせ。
-
-LW67 は ANSI/ISO と Backspace分割の2択の積(2×2)で、4つの選択肢はその全組み合わせ。
 ISO Enter は ISO 側の2つ、分割Backspaceのキーは分割側の2つに現れる。
-VariantGroupを「ANSI/ISO」と「Backspace分割の有無」の2つに分ければ、キーの複製は要らない。
+QMKも `LAYOUT_ansi` / `LAYOUT_ansi_splitbs` / `LAYOUT_iso` / `LAYOUT_iso_splitbs` の4つを持つ。
+VariantGroupを「ANSI/ISO」と「Backspace分割の有無」に分ければ、キーの複製は要らない。
 
-MACRO1 は左列と右列がそれぞれ「1U×2 か 2U縦 か」の2択で、
+## MACRO1
 
-| 選択肢 | 左列 | 右列 |
+6行4列。VIAは3択、QMK (`laneware/macro1`) も `LAYOUT_numpad` / `LAYOUT_southpaw` / `LAYOUT_macropad` の
-| --- | --- | --- |
+3つしか持たない。`LAYOUT_macropad` は全キー1Uで23キーあり、他の2つが使うフットプリントを全部含む。
-| Numpad | 1U | 2U縦 |
+配線はすべての位置に来ていて、組み合わせを3つに絞っているのはファームウェア側である。
-| Southpaw | 2U縦 | 1U |
-| Macropad | 1U | 1U |
 
-「左右とも2U縦」は提供されていない。左列と右列を別のVariantGroupにすれば、
+| | 左列 (2,0 / 3,0 / 4,0) | 下段左 (5,0 / 5,1) | 右列 (2,3 / 3,3 / 4,3) | 下段右 (5,2 / 5,3) |
-`3,0@(0,3.5)1U`(Numpad と Macropad で共通)のようなキーを複製せずに置けるが、
+| --- | --- | --- | --- | --- |
-提供されない4通り目も表現できてしまう。
+| Numpad | 1U×3 | `5,0` が2U幅。`5,1` は潰れる | 2U縦×2 (`3,3` なし) | `5,2` 1U。`5,3` は `4,3` が潰す |
+| Southpaw | 2U縦×2 (`3,0` なし) | `5,0` は `4,0` が潰す。`5,1` 1U | 1U×3 | `5,2` が2U幅。`5,3` は潰れる |
+| Macropad | 1U×3 | 両方1U | 1U×3 | 両方1U |
+
+共通キーは8個。`3,0` などの左列1Uが {Numpad, Macropad}、`5,1` と右列1Uが {Southpaw, Macropad} に現れる。
+出現集合が交差するので入れ子では表せない。
+
+左右の列だけを見ると独立な2択に見えるが、下段が絡むと分解できない。
+「左列と下段左」を1つの選択、「右列と下段右」をもう1つの選択として2つのVariantGroupに割ると、
+`4,0` が2U縦のまま `5,0` に1Uキーを置く組み合わせが作れる。これは提供されないどころか、
+キャップが重なって物理的に成立しない。
 
 ## 捨てた見方
 
-入れ子のVariantGroupで表す案。MACRO1 は {Numpad,Macropad} と {Southpaw,Macropad} が交差するので、
+- 入れ子のVariantGroupで表す: 出現集合が交差するので不可能
-入れ子(片方がもう片方を含む形)では表せない。積として2つ並べる形でしか表せない。
+- 独立したVariantGroupに分けて、成立しない組み合わせを禁止する仕組みを足す:
+  複製を許せば要らない。禁止の表現を足すほうが重い
+- 同じ位置のキーに違う番号が振られたら警告する: 排他キーは位置もサイズも違ってよいので基準にならない
 
 ## この調査の限界
 
 VIAの表現力に引きずられている。VIAは選択肢ごとのキー集合しか書けないので、
 設計者が最初から「2つの独立した選択」として設計した基板は、VIAの定義でも2つのオプションに分かれ、
-この検索には引っかからない。実際、2択のオプションを複数持つ定義が多数ある。
+この検索には引っかからない。引っかかった2件は「1つのオプションに畳んでしまった」定義だけである。
-引っかかった2件は「1つのオプションに畳んでしまった」定義だけである。
 
 ## 検証スクリプト