docs: 保留課題をbacklogへ分離し、運用ルール5を追加
未確認事項が「現在の仕様が答えに依存するもの」と「答えが出なくても進められる もの」を混ぜて抱えていた。後者を backlog/README.md へ移し、仕様書の未確認事項を 前者だけに絞る。移す際は保留中の対応範囲・暫定仕様を仕様書本文に明記し、 backlogへの移動が仮説の採用を意味しないようにする。 PHY・ELC・IDXの10件を移し、3ファイルとも未確認事項が空になった。 ルール4では、事実確認の「格上げ条件」と意思決定の「完了条件」を区別する。 仕様書側の保留課題はbacklogの区分へのリンク箇条書きだけに固定し、 末尾は保留課題 → 検討済み・非採用 → 未確認事項の順に置く。 doc-lintをルール5に対応させ、backlogを検査対象に加えた。回帰テストを追加。 Journal: journal/2026-09-22-document-backlog.md Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DKW58HEg8zAQoLrkWByPfD
This commit is contained in:
Claude Opus 5
+19
-37
@@ -101,6 +101,8 @@ LED・OLED・ロータリーエンコーダ・ネジ穴のように、設計者
|
||||
フットプリントの選択には使わない。予約名以外および省略時は既定の形で描く。
|
||||
ユーザーが付ける名前は `@` で始めない限り予約と衝突しない。
|
||||
|
||||
当面は表裏の描き分けを行わない。描画用の予約グループ名を、PCB上の実装面の指定としては使わない。
|
||||
|
||||
部品ノードはクラスターの子になれる。クラスターを動かせば配下の部品も追随する。
|
||||
|
||||
LEDの配線はPHYが持たない。LEDの識別番号もPHYは持たない。番号は配線で決まるため、ELCが持つ。
|
||||
@@ -113,6 +115,7 @@ IDXはLEDの番号を持たない。RGB効果が必要とする位置と区分
|
||||
### ラベル
|
||||
|
||||
キーはラベルを参考情報として持つ。KLE JSONの取り込みでは照合に使う。
|
||||
当面はラベルからMAPへの自動適用は行わない。
|
||||
|
||||
### グルーピング
|
||||
|
||||
@@ -198,6 +201,9 @@ Transform は回転と平行移動だけを持つ剛体変換であり、合成
|
||||
ただし選択したノード全部が同じ回転角度を持つ場合はその角度を基準角度に採り、境界矩形もその角度の座標系で取る
|
||||
- 組み替えで生じた非グリッド値はそのまま保持する。クラスターを解除して親に戻ったノードも同じ
|
||||
|
||||
当面、reframeは通常の移動・回転と別の明示的な操作とし、原点の指定は数値入力で行う。
|
||||
原点の吸着やフォーカス状態・ハンドルに連動した操作は、試作後に検討する。
|
||||
|
||||
## 保存形式
|
||||
|
||||
各ノードは親から見た変換を持つ。キー・クラスター・部品ノード・バリアントノードを混在させた木構造として保持する。
|
||||
@@ -342,6 +348,10 @@ const kleData = (ConfigObject | KeyLabel)[][]
|
||||
|
||||
### KLE JSONの取り込み
|
||||
|
||||
当面は新規PHYとしての読み込みを対象とする。既存PHYへの照合・更新は、照合規則を検証するまで未対応とする。
|
||||
以下は照合・更新に対応する際の制約であり、曖昧な対応を自動確定しない。
|
||||
誤照合で既存IDを別のキーに割り当てると、他レイヤーの参照にも影響するため。
|
||||
|
||||
既存のPHYデータを畳んだ配置に対して、KLE JSONの各キーを形状(位置・サイズ・回転)とラベルで照合する。
|
||||
|
||||
- 照合できたキーは元のノードとして扱う。KLE側で配置が変わっていれば、元の親から見た相対座標に戻して反映する
|
||||
@@ -356,10 +366,17 @@ KLE本家はこの位置の r, rx, ry をエラーにするが、VIAとRemapは
|
||||
|
||||
KLEの rx, ry, r はキーの絶対配置 (x, y, rotation) に変換して取り込む。元の rx, ry は保持しない。
|
||||
|
||||
見た目の属性(c, t, p, a, f, f2, fa, l, n)は、KLE JSONへ書き戻せるように保持する。どの層で持つかは決まっていない。
|
||||
見た目の属性(c, t, p, a, f, f2, fa, l, n)は、KLE JSONへ書き戻せるように保持する。
|
||||
当面はキー単位の `kleCompatibility` に不透明なデータとして退避し、見た目の編集機能は持たない。
|
||||
|
||||
KLEの sm, sb, st(ファイル単位では switchMount, switchBrand, switchType)も同様に、不透明なまま保持して書き戻す。
|
||||
Beyond KLEはスイッチの品種を持たないため、対応づける先がない。
|
||||
ファイル単位の属性(switchMount, switchBrand, switchType, backcolor, radii, background, css)は、
|
||||
ファイル単位の `kleCompatibility` に退避する。正式な所属層を決めるまでは、この退避先で保持する。
|
||||
|
||||
## 保留課題
|
||||
|
||||
- [PHYの保留課題](backlog/README.md#phy)
|
||||
|
||||
## 検討済み・非採用
|
||||
|
||||
@@ -371,39 +388,4 @@ Beyond KLEはスイッチの品種を持たないため、対応づける先が
|
||||
|
||||
## 未確認事項
|
||||
|
||||
### P-2 KLE JSON取り込み時の照合基準
|
||||
|
||||
- 位置づけ: 本文「KLE JSONの取り込み」の具体化に必要な未解決の問い
|
||||
- 現状の認識: 形状の許容誤差、ラベルの扱い、複数候補がある場合の決め方が未定
|
||||
- 格上げ条件: 照合規則を決めたうえで、KLE本家でキーの移動・追加・削除をしたJSONを取り込み、意図どおりに対応づくことを確認する
|
||||
|
||||
### P-6 キーキャップの見た目情報を持つ層
|
||||
|
||||
- 位置づけ: 本文「見た目の属性は保持する。どの層で持つかは決まっていない」の未解決部分
|
||||
- 現状の認識: c, t, p, a, f系に加え、l, n もキーキャップの見た目属性であり、PHYとは別の層が要りそう。退避だけして書き戻す sm, sb, st も同じ置き場の問題を持つ。そもそもキーキャップは設計時に決める必要が薄く、カスタムキーボードの文脈に属するため、Beyond KLEの扱う範囲かどうかも未定。ファイル単位の backcolor, radii, background, css も同じ問いに含まれる
|
||||
- 格上げ条件: キーキャップの情報をBeyond KLEの範囲に含めるかをユーザーが決め、保持する層を決める
|
||||
|
||||
### P-8 ラベルをMAPに適用するか
|
||||
|
||||
- 位置づけ: 未解決の問い。本文ではラベルを参考情報として持つことだけを決めている
|
||||
- 現状の認識: どのラベルがMAPに適用できるかは、おそらく機械的には判断できない。自動で適用してユーザーが不要なものを落とす方式も考えられる
|
||||
- 格上げ条件: 適用するか、する場合は自動適用とユーザーによる取捨の流れをユーザーが決める
|
||||
|
||||
### P-12 部品の表裏を描画でどう扱うか
|
||||
|
||||
- 位置づけ: 本文「部品ノードは表裏を持たない」の残余
|
||||
- 現状の認識: どちらの面に載るかはPCB設計ツールが決める情報なのでPHYには持たない。ただしエディタ上で裏面の部品を描き分けたくなる可能性があり、`@` 始まりの予約グループ名だけで表現できるかは未検証
|
||||
- 格上げ条件: 予約グループ名による描画を実装し、表裏の描き分けが必要になるか、必要なら予約名で足りるかを確認する
|
||||
|
||||
### P-13 reframeと通常の移動・回転をエディタ上でどう区別するか
|
||||
|
||||
- 位置づけ: 本文「クラスターの組み替え」の残余。データモデル側は決まっており、操作系だけが未定
|
||||
- 現状の認識: クラスターへのフォーカス状態に紐づけ(中に入っている間は配下の絶対配置が変わらない)、
|
||||
そのうえで原点ハンドルと通常の移動・回転ハンドルを分ける案が有力。専用モードを設ける案もある
|
||||
- 格上げ条件: 操作系をユーザーが決める
|
||||
|
||||
### P-14 クラスター原点の吸着先
|
||||
|
||||
- 位置づけ: 未解決の問い。数値入力以外に、原点をどこへ吸着させるか
|
||||
- 現状の認識: キーのローカル原点(左上角)・キー中心・境界矩形の角と中心が候補。相対グリッドとは別の機構になる
|
||||
- 格上げ条件: 原点移動を実装し、吸着なしで足りるか、足りない場合どの候補が要るかを確認する
|
||||
(なし)
|
||||
|
||||
Reference in New Issue
Block a user