chore: Markdownのlint規則をリポジトリに置き、コミット前に修正をかける

VS Codeは保存時にmarkdownlintの修正を入れるが、規則(MD007のインデント4)がユーザー設定にしかなく、
CLIからは参照されなかった。そのためコミット直後に差分が出ていた。
規則を .markdownlint.jsonc に移し、コミット前に変更したファイルへ --fix をかける指示をCLAUDE.mdに足した。

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

.markdownlint.jsonc

@@ -0,0 +1,4 @@
+// VS Codeのユーザー設定(markdownlint.config)と同じ規則にそろえる
+{
+  "MD007": { "indent": 4 }
+}

CLAUDE.md

@@ -127,6 +127,9 @@ PHY(物理配置) / ELC(電気配線) / IDX(キー識別) / MAP(キーマップ)
 - ドキュメントを更新するときは、上のルール1〜5のどこに属する情報かを判断してから書く。分類に迷うものは書く前に確認する。
 - 調査タスクの結果は、結論だけをメインドキュメントに書き、調査過程は `journal/` に落とす。
 - 既存ドキュメントの記述と食い違う事実を見つけたら、勝手に上書きせず指摘する。
+- Markdownをコミットする前に、変更したファイルへ `npx markdownlint-cli2 --fix <files>` をかける。
+  エディタが保存時に同じ修正を入れるため、かけずにコミットするとコミット直後に差分が出る。
+  規則は `.markdownlint.jsonc`。変更していないファイルの指摘は直さない。
 
 ## 未確認事項
 

backlog/README.md

@@ -86,6 +86,15 @@
 - 完了条件: 対象方式の配線と整合する走査方法を確認し、必要な出力設定と対応範囲を定める。
   全方式で走査手順が一意に決まることの証明は求めない。
 
+### ELC-P-4 GPIOに直結したLEDの表し方
+
+- 関連仕様: [ELCレイヤー](../ELCレイヤー.md)「LEDの識別番号」
+- 未決事項: インジケータなど、チェーンに入らずマイコンのピンで直接点灯するLEDをELCにどう持つか。
+  LEDの部品ノードとピンの対応だけで足りるか、極性(ピン側がアノードかカソードか)も要るかを含む。
+- 保留できる理由: チェーン方式(WS2812系)のLEDとキーの配線は、直結LEDと独立に扱える。
+- 再開条件: インジケータLEDの出力に対応するとき、またはLED配線の編集画面の仕様を作るとき。
+- 完了条件: 実在の基板で直結LEDの配線を確認し、ELCでの表し方と、ファームウェア出力に必要な情報を定める。
+
 ## IDX
 
 ### IDX-P-1 単一のorderから既存コミュニティレイアウトの並びを得られる範囲

provisional/README.md

@@ -12,10 +12,13 @@
 ## ファイル
 
 | ファイル | 内容 |
-|---|---|
+| --- | --- |
 | [decisions.md](decisions.md) | 仮決定の本体。範囲と技術 / 明示的な未決事項 / 暗黙の未決事項 |
 | [discrepancies.md](discrepancies.md) | 作業中に見つけたドキュメント間の食い違い。メインドキュメントは直していない |
 | [phy-editor-feedback.md](phy-editor-feedback.md) | PHY Editorモックの所感。画面仕様を作り直すときの入力 |
+| [idx-editor-feedback.md](idx-editor-feedback.md) | IDX Editorモックの所感。画面仕様を作り直すときの入力 |
+| [elc-editor-feedback.md](elc-editor-feedback.md) | ELC Editorモックの所感。画面仕様を作り直すときの入力 |
+| [map-editor-feedback.md](map-editor-feedback.md) | MAP Editorモックの所感とRemapの現状。画面仕様を作り直すときの入力 |
 | `consultation/` | Codex(Sol / Astra)への相談の原文。仮決定はこれを突き合わせて決めた |
 
 作成: 2026-09-25、ブランチ `mock/provisional-decisions`。

provisional/elc-editor-feedback.md

@@ -0,0 +1,49 @@
+# ELC Editor モックの所感(画面仕様の入力)
+
+モックを触った所感と、それを受けた議論の整理。**仕様ではない。**
+画面仕様を一から作るときの入力にし、仕様へ反映したら消す。
+
+## 方向が合意できたもの
+
+### 一括配線
+
+- キーの上を順になぞって配線する。ピンの指定は、なぞる前でも後でもできる。
+- 通常のマトリクスは、rowだけ・colだけを分けてなぞれるようにする(rowモード / colモード)。
+- 編集中は、片方の端子だけ配線した状態を保存できる。ELCの端子を省略可能にし、片側だけのキーは検証で拾う。
+  ELCの保存形式の変更になるので、本決定は別途行う。
+- 倍マトリクスでは、同じrow/colの組が編集中に重なってよい。ダイオードの向きで区別するので衝突にはならない(T-25)。
+  重なった場合も保存は止めない(T-16)。
+
+### ピン提供者
+
+- ボード(Pro Micro互換など、MCUを載せた開発基板)も提供者として扱いたい。多くの利用者はチップではなくボードを使う。
+  現行の `mcu` 提供者はチップの品番だけを持つ。
+
+### LEDチェーン
+
+- per-key LEDとアンダーグローを別チェーンにできること。仕様上はできる(チェーンに入れるLEDは設計者が選ぶ)。
+  モックでできないのは下記「モックの実装上の問題」による。
+- チェーン内の順番を指定できること。配線しやすい向きがあるため。キーの配線と同じく、なぞって指定する。
+
+## 要検討
+
+- 倍マトリクスの向きの指定方法(選択範囲だけダイオードの向きを逆にする、など)。
+- 二乗マトリクス(同じピンがrowにもcolにも現れ、向きはダイオードだけで区別する)の操作。通常のマトリクスと同じ操作で足りるか。
+  row/colで表せるかの議論は後で行う。Generatorのプレビューは今のところ「未対応」になる(T-19)。
+- directの操作。row/colの指定がなく、片方の端子は電源レールになる。
+- mux・シフトレジスタを使う場合の操作。rowかcolの一方を親の提供者の論理ピンにする形になるか。
+  マトリクスとの階層化はモデル上は表せるが、デジタル側の提供者の記述は未定義。
+- ボードを提供者にしたときの形。ボードのピン名とMCUのピンの対応、外に出ていないピンの扱い、分割キーボードでの使い方。
+- 対応している提供者を図付きで見せる。ボードのピン配置図と一緒に考える。
+- ピン名の候補の一覧が「今使えるピン」と誤解される問題。ダイアログに分けるなど。ボードを提供者にすれば、外に出ていないピンは候補から消える。
+- GPIOに直結したLED(インジケータなど)。仕様にないので `backlog/README.md` のELC-P-4とした。
+
+## モックの実装上の問題
+
+作り直しで解消する前提で、原因の記録だけ残す。
+
+- 選ばれていないバリアントのキーを配線できない: 出力用の選択(`output.variantSelection`)で絞ったキーだけを表示し、
+  ELC画面に選択を変えるUIがない(IDX・Generatorのタブでしか変えられない)。仕様では全バリアントのキーを配線する。
+- per-key LEDが意図しないチェーンに入る: 配線用のキーボード表示のクリック(`clickKey`)が、編集中のチェーンにそのキーを追加する。
+  1つのLEDが複数のチェーンに入っても検査しない。
+- 一括配線はキーをクリックで選ぶ方式で、配線の順はクリック順ではなくPHYの表示順になる。

provisional/idx-editor-feedback.md

@@ -0,0 +1,34 @@
+# IDX Editor モックの所感(画面仕様の入力)
+
+モックを触った所感と、それを受けた議論の整理。**仕様ではない。**
+画面仕様を一から作るときの入力にし、仕様へ反映したら消す。
+
+## 方向が合意できたもの
+
+### 並べ替え
+
+- リストを主な操作の場にしない。並べ替えはキャンバス上のキーをドラッグ&ドロップして行う。
+- ドロップで「挿入」と「入れ替え」を区別できるようにする。
+    - 挿入: 位置nのキーを、位置iとi+1の間にドロップする。
+        - n > i+1 のとき、キーは位置i+1に入り、元のi+1〜n-1は1つずつ後ろへずれる。
+        - n < i のとき、キーは位置iに入り、元のn+1〜iは1つずつ前へずれる(通常のリストの移動と同じ)。
+    - 入れ替え: 位置iのキーを位置nのキーの上にドロップすると、2つを入れ替える。他のキーは動かない。
+
+## 要検討
+
+- プリセット(一括の並べ替え)の種類。候補: 分割キーボード用(左手側を先に並べる)、行と列の入れ替え。
+- なぞって連番を振る操作。なぞり始めたキーの位置から連番にする。複雑な配置で役立ちそうだが、実装は重い。
+- バリアント選択のドロップダウンの位置。左上に置く案。
+- 欠番(番号の飛び)を作れないこと。現行仕様では、出力番号は `order` 内の位置で表し、飛ばない(`IDXレイヤー.md`「保存形式」)。
+    - 場面: 4x4の右下(11, 15)をoption A、縦2UキーをBにする。2Uを `order` の末尾に置くと、Bでは12〜14が1つずつ前へずれる。
+        「2Uを末尾にする」と「バリアント外のキーの番号をずらさない」を両立するには、11を欠番にするしかない。
+    - 番号を詰める方式は2026-09-22に決めた(`journal/2026-09-22-idx-variant-output.md`)。番号の互換性はバリアントを選んだ構成ごとに扱い、
+        別の構成で同じ番号が同じキーを指すことは保証しない。ただし、そのときの例は1対1の排他キー(ANSI/ISO)だけだった。
+    - 今の仕様のままなら、2Uを11の位置に置けば12〜14はずれない(QMKのテンキーの+キーも上端の位置に置く慣習)。
+    - 構成をまたいで番号が揃っていてほしい利用場面(手書きのkeymap.cを共有する、など)があるかを確認してから扱いを決める。
+
+## モックの実装上の問題
+
+作り直しで解消する前提で、原因の記録だけ残す。
+
+- バリアント選択が見つけにくい: 右ペインの「出力構成」見出しの下、キーボード表示の上にあり、並びを編集するリストから離れている。

provisional/map-editor-feedback.md

@@ -0,0 +1,67 @@
+# MAP Editor モックの所感(画面仕様の入力)
+
+モックを触った所感と、それを受けた議論の整理。**仕様ではない。**
+画面仕様を一から作るときの入力にし、仕様へ反映したら消す。
+
+Remapの編集機能をほぼ正解とみなし、Remapから何を引いて何を足すかで考える。
+Remapの現状は末尾の「参考: Remapのキーマップ編集」にまとめた。
+
+## 方向が合意できたもの
+
+### 割り当て操作
+
+- 主な操作は、キーコード一覧からのD&D。一覧は分かりやすい粒度でまとめる。入力欄への手入力は補助の手段とする。
+- Tabによる入力ループ: Tabでキーを選ぶ → 何かのキーで入力欄を開く → `KC_Q` などのキーコードを入れる → Enterで確定 → 次のキーへ。
+    - 入れるのはキーコード。PCの物理キーを押して割り当てる方式(Remapの方式)ではない。
+    - 検索は今の入力欄と同等でよい。
+
+### 引数付きのキーコード(`LT()` など)
+
+- QMK前提で、できれば全部に対応する。
+- 引数を展開した値を並べず(モックの入力欄、Remapの `TG(0)`〜`TG(3)`)、パラメータごとに入力欄を設ける。
+- 引数にはキーコード以外のもの(レイヤー、修飾キー、Staticの定義名など)も入る。検索対象の一覧はそれに合わせて作る。
+
+### 未割り当て
+
+- 未割り当て(`KC_NO` とは区別する)はキーの枠などのハイライトで示す。Remapの変更済み表示の代わりに置く。
+- モック下部の未割り当て用ボタンは要らない。
+
+### StaticとDynamic
+
+- ここでのStaticは、Firmware Generatorへ渡すMAPを編集すること。Dynamicは実機の割り当てを読み書きすること。
+- 用途によって必要な機能が変わるかもしれない。例: ハイライトは、Staticなら未割り当て、DynamicならRemapと同じ変更済み表示でよい。
+
+## 要検討
+
+- StaticとDynamicでモードを分けるか、色の違いだけにするか。
+    - Claudeの案: モードは分けない。印の種類を変えて両方出す(未割り当ては枠、実機との差分は点)。色だけで分けると、両方が当てはまるキーで表示がぶつかる。
+    - 機能面で違いが出るのは候補一覧。実機に定義がないもの(`TD()` などStaticで定義する動作)は、Dynamicでは候補から外すか警告する。
+- 入力ループで入力欄を開くキー(Enter、Space、文字キーでそのまま入力を始めるなど)。
+- Remapの「物理キーを押して割り当て」を残すか。残すなら、Tabでの移動とぶつからない起動方法が要る。
+- レイヤー遷移のシミュレーション: 「有効なレイヤー」を与えると、どのレイヤーのどのキーが入力されるかを表示する。QMKでは `KC_TRNS` などが、その下にある有効なレイヤーのキーを送出するため。要否も含めて未定。
+
+## 参考: Remapのキーマップ編集(2026-10-01時点)
+
+ローカルのクローン(2023-02、`ccbaefd`)のソースと、実機(Corne)につないだ本家(Remap for QMK 0.18)の操作で確認した。
+
+- 画面:
+    - 上段: キーボード図とレイヤー番号
+    - 下段: キーコード一覧(BASIC / FUNCTIONS / LAYER / DEVICE / SPECIAL / MIDI)と検索欄
+- 割り当て方法:
+    - 一覧からD&D
+    - キーをクリックしてポップオーバーで編集。タブは次の3つ。
+        - キー: 補完入力と修飾キーのチェックボックス
+        - ホールド・タップ: Hold欄とTap欄でLT・MTを組む
+        - カスタム: 16進で直接入力
+    - キーを選択した状態でPCの物理キーを押す。離すと次のキーへ進む。
+- 検索は表示名と説明文に当たる。`KC_Q` や `TG(` では候補が出ない。
+- Tabは物理キーでの入力として拾われるので、キー間の移動には使えない。
+- レイヤー系(`TO/TG/MO/OSL/TT/DF`、`LM()`)は、レイヤー数の分だけ展開した候補を並べる。
+- 一覧にあるもの(BASIC・LAYER以外の主なもの):
+    - FUNCTIONS: Combo On/Off、Auto Shift、VIA User Key、Programmable Button、
+      User、Leader、Dynamic Macro、Macro 0〜15
+    - SPECIAL: One Shot、Key Override、Tapping Term、Auto Correct、Repeat Key、
+      Key Lock、Caps Word、Steno、Unicode Mode
+- Tap Dance(`TD()`)は一覧にも検索にも見つからなかった。
+- 変更済みの表示: キーとレイヤー番号に点が付く。上部に「元 > 新」の差分とキャンセルが出る。書き込みボタンで変更をまとめて実機へ反映する。
+- そのほか: キーマップの保存・共有(Mine / Shared / History)、PDFのキーマップ表、Layout Option、Test Matrix、マクロエディタ、ライティング設定。