ewdernaandClaude Opus 5
55243f626d
ルール策定前に書かれた設計ドキュメント7点を、以降の基準点として そのままの状態で記録する。CLAUDE.md のルール1〜4は未適用。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MdLT5x5ka5y6CaWLeE3EKb
4.8 KiB
4.8 KiB
Beyond KLE: キーボード設計レイヤー構造とツール設計方針
背景
KLEの問題点
- 物理配置と論理構造の混同: y座標や回転角度で行を判定するため、カラムスタッガードや曲線配列で大量の行が生成される
- データモデルの限界: 物理配置(PHY)のみを扱い、マトリックス座標やキーマップ情報を保持できない
- VIAのhackyな対応: ラベルフィールドに"1,5"と入れて
matrix:[1,5]を表現
設計思想
- 「Better KLE」ではなく「Beyond KLE」: UIではなくデータモデルとワークフロー全体の再設計
- UNIX哲想の適用: 小さな役割のツールがそれぞれしっかり機能する
- 統合環境(IDE)の提供: 独立したツール群をオーケストレート
レイヤー構造
1. PHYレイヤー (物理配置)
- 役割: キーの物理的な位置、サイズ、回転
- 対応ツール: PCBエディタ、KLE
- 出力: 座標とキーサイズの配列
2. ELCレイヤー (電気配線)
- 役割: マイコンのpinと各キーの対応
- 対応ツール: 回路図エディタ、ファームウェア
- 出力: ピン配列定義、マトリックス配線情報
- 備考: charlieplexingなど非標準的な実装にも対応
3. IDXレイヤー (キー識別)
- 役割: 物理位置と"キー番号"の対応付け
- 重要性: 物理世界と論理世界を繋ぐ最も重要な抽象化層
- 出力:
{x, y, matrix:[row,col], label}[] - 備考: 現状のエコシステムで最も欠けている層
4. MAPレイヤー (キーマップ)
- 役割: キー番号とキーコードの対応
- 対応ツール: ファームウェア、VIA、Remap
- 出力: レイヤー別キーコード配列
5. IMEレイヤー (入力変換)
- 役割: キーコードと実際の入力文字の対応
- 対応ツール: OS
- 備考: MAPレイヤー設計時に考慮が必要
ツール設計方針
個別ツール (独立動作可能)
PHY Editor
- 物理配置の視覚的編集
- KLE互換フォーマット対応
- 出力: PHY JSON
Matrix Mapper
- PHY Editorの出力を入力
- キーにrow/colを割り当て
- 視覚的にマトリックス配線を確認
- 出力: IDX JSON
Pin Configurator
- マトリックス定義を入力
- マイコンのピン配置を指定
- 配線図を出力
- 出力: ELC JSON
Keymap Designer
- キー識別子リストを入力
- レイヤー別キーコード割り当て
- VIA/Remapとの互換性
- 出力: MAP JSON
Firmware Generator
- 全レイヤーの情報を統合
- QMK/VIA/KMK等へ変換
- 出力: ターゲット固有の設定ファイル
統合環境 (IDE)
- プロジェクトファイル: 全レイヤーの状態を一元管理
- リアルタイムプレビュー: レイヤー間の依存関係を可視化
- バージョン管理統合: テキストベース定義でgit管理
- ワークフローサポート: ガイド付きウィザード、テンプレート
プロトコル設計
レイヤー間インターフェース
PHY → IDX
Input: KLE JSON (or compatible)
Output: Augmented layout (coordinates + key IDs)
IDX → ELC
Input: Key ID list
Output: Matrix definition + Pin mapping
IDX → MAP
Input: Key ID list
Output: Keymap arrays
All → Firmware
Output: QMK keyboard.json / VIA JSON / KMK .py
データフォーマット
- JSON Schema で各レイヤーの入出力を定義
- 後方互換性の維持 (KLE JSONからのインポート)
- 拡張可能な設計 (3D配置、非標準マトリックス対応)
実装戦略
Phase 1: プロトコル策定
- JSON Schemaでフォーマット定義
- TypeScriptでリファレンス実装
- CLIツールとして動作確認
Phase 2: 個別ツール開発
- 各レイヤー用エディタを独立開発
- 既存ツールからのインポート機能
- 単独利用可能な設計
Phase 3: IDE統合
- Electron/Tauri or Webアプリ
- プロジェクト管理機能
- ワークフロー支援
既存ツールとの関係
- KLE: PHY Editorの一実装、インポート対応
- VIA/Remap: MAP Layerクライアントとして連携
- QMK Configurator: Firmware Generatorのターゲット
配慮事項
学習コスト
- テンプレートプロジェクト提供 (60%, Split等)
- 簡易モード/詳細モードの切り替え
- 段階的な機能開示
互換性
- 既存KLE JSONの完全サポート
- 段階的移行パスの提供
- レガシーツールとの共存
次のステップ
- プロトコル仕様ドラフト作成
- GitHubでRFCリポジトリ立ち上げ
- 小規模コミュニティでフィードバック収集
- リファレンス実装の開発