過去の自作 kbd-editor を土台にせず、コードも持ち込まない

kbd-editor はフラットな絶対座標の Key[] を直接書き換える作りで、
kle-ng と同じく PHY の相対座標の木とは合わない。加えて作者の記憶では
KLE本体(全権利留保)を参考に書いた部分が多く、由来を切り分けられない。
概念の参考は可とした。

P-2 に振り返りで得た材料(Nuxt不要・SVG描画が有力)を追記し、
格上げ条件から「振り返り」を外した。

Journal: journal/2026-09-19-kbd-editor-review.md

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

journal/2026-09-19-kbd-editor-review.md

@@ -0,0 +1,49 @@
+# 過去の自作エディタ kbd-editor の振り返り
+
+## 結論
+
+- kbd-editor は PHY Editor の土台にしない。コードも持ち込まない
+- 理由1: データモデルがフラットな絶対座標の Key[] で、PHY の相対座標の木と逆向き。kle-ng を見送ったのと同じ理由
+- 理由2: 作者本人の記憶では、多くを KLE 本体(全権利留保)のコードを参考に書いた。どこが KLE 由来か切り分けられない
+- 概念(プロファイルの定義項目、KLE属性の一覧)は読んで参考にしてよい
+- P-2 への材料: SSR はほぼ使わないので Nuxt は不要、素の Vue/React を想定(ユーザー談、未決)。描画は SVG が有力
+
+## 案の比較
+
+| 案 | 評価 |
+|---|---|
+| kbd-editor を土台にする | データモデル・編集操作は作り直し。書き出しは未実装。残るのは描画と読み込みだが、どちらも出自に懸念 |
+| 部品だけ流用 | deserializer は npm の kle-serial(MIT)で代替できる。Key.vue は KLE 由来の懸念。流用の利点が薄い |
+| 持ち込まない(採用) | 失うのは約2,000行。概念だけ参考にする |
+
+## 検証ログ
+
+### kbd-editor の状態 (Documents/Dev/kbd-editor, 2026-09-19 確認)
+- 初回コミット ef25631 のみ。ブランチ master / develop / feature/base-ui は同一内容
+- Nuxt 3.17 + Nuxt UI 3.2 + Pinia。テストなし(utils/test-deserializer.ts は手動実行用スクリプト)
+- 規模: KeyPropEditor.vue 710, stores/keys.ts 305, deserializer.ts 277, Key.vue 262, types 355, LayoutEditor.vue 152 行ほか
+- types/keyboard.ts: Key は x, y, rotation_x/y/angle の絶対座標。kle-serial と同じ形
+- stores/keys.ts: keys をフラット配列で保持。移動は keys[i].x = Math.max(0, x + dx) と直接書き換え(負座標を切り捨て)
+- 回転は KeyPropEditor から rotation_angle / rotation_x / rotation_y を直接書き換えるだけ。ドラッグ・undo・グループなし
+- utils/serializer.ts は `return []` のみ。KLE書き出し未実装
+- 描画: Key.vue が div + CSS mm 単位。outline / shadow / fill の3層、x2/y2 の第2矩形あり。回転は CSS transform + transform-origin
+- stores/displayConfig.ts のプロファイル: pitch{w,h}, gap{x,y}, top{l,r,t,b,c}, cornerRadius。PHY のプロファイル(ユニットサイズ、内側オフセット、R)とほぼ同じ概念
+
+### 出自
+- 作者本人: 「多くはkle本体のコードを参考にしていたと思います」(2026-09-19)
+- deserializer.ts の LABEL_MAP 等は kle-serial(MIT)にも同じものがある。kle-serial 経由か KLE 本体経由かは不明
+- Key.vue の3層構造は KLE の keycap 描画と同じ形
+
+### 描画方式: DOM(div) と SVG
+- 当時 DOM を選んだ理由: クリック判定をブラウザに任せられる(ユーザー談)
+- SVG 要素も DOM 要素なのでイベントを受けられ、判定もブラウザが行う。自前で判定が要るのは Canvas
+- `<g transform="translate(x y) rotate(θ)">` の入れ子は PHY の Translate(x,y)·Rotate(θ) と同じ定義。回転中心は g のローカル原点
+- ヒットテストは入れ子の変換を適用した後の形で行われる。非矩形キーは path か、rect 2つを1つの g にまとめる
+- element.getScreenCTM().inverse() で画面座標 → ローカル座標の行列が取れる。ドラッグの逆変換がほぼこれで済む
+- viewBox を U か mm で切れば単位をそのまま扱える
+- 弱点: 文字の自動折り返しがない。必要なら foreignObject で部分的に HTML。ラベルは pointer-events="none" で本体にクリックを通す
+- いずれも仕様上の挙動。本プロジェクトでの試作はしていない
+
+### フレームワーク
+- エディタは SSR もルーティングもほぼ使わない。Nuxt の利点は小さい
+- ユーザー: 「素のVue/Reactでいいのかなとは思っています」。未決