PHY: KLE固有の形状・属性の受け止め先を決める(P-4解消)

- 長方形でないキーは Size に x2, y2, w2, h2 を加えて持つ
- デカール・ゴーストはキーとして持ち、フラグで区別する
- ラベルは参考情報として持つ(取り込み時の照合に使う)
- 見た目の属性はKLEへ書き戻せるよう保持する。保持する層は未決
未決部分は P-5〜P-8 に分離。空の見出し「何かある？」も削除。

Journal: journal/2026-09-19-kle-key-attributes.md

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

PHYレイヤー.md

@@ -44,6 +44,17 @@ KLE JSONやPCB向けの出力は、階層を畳んで絶対座標に変換した
 0.25U単位でスナップするが正規化しない。  
 サイズはローカルの値であり、親の変換を受けない。
 
+ISO Enterのように長方形でないキーは、サイズに2つ目の矩形(x2, y2, w2, h2)を加えて表す。
+2つ目の矩形の位置は、キーのローカル原点からの相対値とする。
+
+### デカールとゴースト
+
+デカールとゴーストはキーとして扱い、フラグで区別する。KLEの d, g に対応する。
+
+### ラベル
+
+キーはラベルを参考情報として持つ。KLE JSONの取り込みでは照合に使う。
+
 ### グルーピング
 
 複数のキーを「クラスター」としてまとめて運用することができる。  
@@ -61,12 +72,12 @@ KLE JSONやPCB向けの出力は、階層を畳んで絶対座標に変換した
 
 - クラスター構造はBeyond KLEのデータにのみ存在する。外部形式へは階層を畳んだキー配置だけを出力する
 
-### 何かある？
-
 ## 保存形式
 
 各ノードは親から見た変換を持つ。キーとクラスターを混在させた木構造として保持する。
 
+`phase1-json-schema.md` のPHYスキーマは、この節の Key 型(x2〜h2, decal, ghost, labels)にまだ追従していない。
+
 ```ts
 type Transform = {
     x: number,        // 親座標系での位置
@@ -75,12 +86,19 @@ type Transform = {
 }
 type Size = {
     w: number,        // ローカル値。親の変換を受けない
-    h: number
+    h: number,
+    x2?: number,      // 長方形でないキーの2つ目の矩形。ローカル原点からの相対値
+    y2?: number,
+    w2?: number,
+    h2?: number
 }
 type Key = {
     transform: Transform,
     size: Size,
-    profile: Profile
+    profile: Profile,
+    decal?: boolean,
+    ghost?: boolean,
+    labels?: string[] // 参考情報
 }
 type Cluster = {
     transform: Transform,
@@ -153,12 +171,15 @@ const kleData = (ConfigObject | KeyLabel)[][]
 
 KLEの rx, ry, r はキーの絶対配置 (x, y, rotation) に変換して取り込む。元の rx, ry は保持しない。
 
+見た目の属性(c, t, p, a, f, f2, fa, l, n)は、KLE JSONへ書き戻せるように保持する。どの層で持つかは決まっていない。
+
 ## 検討済み・非採用
 
 - キーごとの絶対座標保持 (journal/2026-09-18-phy-coordinate-model.md)
 - 相対座標と絶対座標の併記 (journal/2026-09-18-phy-coordinate-model.md)
 - ノードごとの回転中心パラメータ (journal/2026-09-18-phy-coordinate-model.md)
 - KLE JSONへの識別・構造情報の埋め込み(labelのID、`_beyondkle` メタデータ、ゴーストキー) (journal/2026-09-18-kle-roundtrip.md)
+- KLEのデカール・ゴースト・見た目属性を取り込み時に捨てる (journal/2026-09-19-kle-key-attributes.md)
 
 ## 未確認事項
 
@@ -181,11 +202,26 @@ KLEの rx, ry, r はキーの絶対配置 (x, y, rotation) に変換して取り
 - 現状の認識: 採用しない可能性が高い。ただし代わりに欲しい機能があり、それを思い出すきっかけとして残している
 - 格上げ条件: 代わりの機能を定義し、この推定を採るか捨てるかをユーザーが決める
 
-### P-4 KLE固有の形状と属性の受け止め先
+### P-5 キャップ形状とスイッチ位置の関係
 
-- 位置づけ: 本文「過去のKLE JSONは読み込めなければならない」を満たすために必要な未解決の問い
-- 現状の認識: 現在の Key 型(transform, size, profile)では次を受け止められない
-  - 長方形でないキー(x2, y2, w2, h2。ISO Enterなど)。受け止められないとISO配列が読めない。ローカルの値なので Size の拡張で相対座標モデルに収まる見込み
-  - デカールとゴースト(d, g)。PHYで持つか、取り込み時に捨てるか
-  - 見た目の属性(ラベル、c, t, p, f系, l, n)。落としてよいか、別の層で保持するか。ラベルは照合にも使う
-- 格上げ条件: 各項目について、PHYで持つ・他の層で持つ・捨てるのいずれかをユーザーが決め、Key 型に反映する
+- 位置づけ: 本文「キャップの位置・サイズからスイッチ座標を特定する」と食い違う事実がある
+- 現状の認識: Stepped Caps Lockのように、スイッチ位置がキャップ中心からずれるキーがある。一方でステップキー(KLEの l)なら必ずずれるわけではない(昔のXFERなど)。キャップ形状だけではスイッチ位置が決まらない
+- 格上げ条件: キャップに対するスイッチ位置の表し方(オフセットを持つか等)を決め、本文と Key 型を改める
+
+### P-6 キーキャップの見た目情報を持つ層
+
+- 位置づけ: 本文「見た目の属性は保持する。どの層で持つかは決まっていない」の未解決部分
+- 現状の認識: c, t, p, a, f系に加え、l, n もキーキャップの見た目属性であり、PHYとは別の層が要りそう。そもそもキーキャップは設計時に決める必要が薄く、カスタムキーボードの文脈に属するため、Beyond KLEの扱う範囲かどうかも未定。ファイル単位の backcolor, radii, background, css も同じ問いに含まれる
+- 格上げ条件: キーキャップの情報をBeyond KLEの範囲に含めるかをユーザーが決め、保持する層を決める
+
+### P-7 スイッチ種別の保持先
+
+- 位置づけ: 未解決の問い。KLEの sm, sb, st(ファイル単位では switchMount, switchBrand, switchType)の扱い
+- 現状の認識: PCB設計に使う情報なのでPHYで持つ候補。一部のキーだけ別のスイッチを使う前提のキーボードもあるため、キーごとの上書きが必要になりうる
+- 格上げ条件: PHYで持つかを決め、持つ場合はファイル単位の既定値とキーごとの上書きの形を決める
+
+### P-8 ラベルをMAPに適用するか
+
+- 位置づけ: 未解決の問い。本文ではラベルを参考情報として持つことだけを決めている
+- 現状の認識: どのラベルがMAPに適用できるかは、おそらく機械的には判断できない。自動で適用してユーザーが不要なものを落とす方式も考えられる
+- 格上げ条件: 適用するか、する場合は自動適用とユーザーによる取捨の流れをユーザーが決める