設定ファイルに対応してほしい

[goofmint]

キーバインドなどを設定ファイルに対応してほしい。
起動時に指定するほか、デフォルトで読み込まれる設定ファイルをホームディレクトリ以下に用意してほしい。
例として、Emacsキーバインド・vimキーバインド・Windows風キーバインドのファイルを用意してほしい。

[goofmint]

@coderabbitai make plan

[coderabbitai]

Coding Plan

Summary

• 既存の「消費側でdeps.pathを上書きし、既定はpaths.tsヘルパーに委ねる」規約に従い、--configフラグをargv.ts→main.ts→createConfigServiceへ通す。paths.tsには環境変数分岐を追加しない。
• キーバインドプリセットはバンドル済みJSON資産として用意する。設定キーkeybindings.presetで選択し、defaults < preset < fallback < extension < userの新しいpreset層として合成する。fallbackKeybindings.tsとworkbench.colorThemeの既存パターンを再利用する。
• プリセット選択コマンドはtheme.selectの構造に倣う。選択結果はthemeSettingsWriter.tsのテキスト置換書き込みでsettings.jsonへ保存し、ユーザーのkeybindings.jsonをクロバーしない。
• spec駆動の規約に従い、requirements.md・design.md・tasks.mdを併せて更新する。

Design Choices

Design Choice 1: CLI起動時フラグが指定する対象は何か

Options Considered:

1. --config <file> で settings.json のパスのみを上書きする。
2. --config <dir> で設定ディレクトリ全体を上書きし、settings.json と keybindings.json の両方を導出する。
3. --config と --keybindings の2フラグに分ける。

Chosen Option: 2

Rationale: ticketは「起動時に指定する」とだけ述べる。指定対象が設定ファイル単体か設定ディレクトリ全体かが不明である。キーバインドを含む設定一式を起動時に指定できるため、ticketの意図に最も合致し、フラグの増加も抑えられる。

Design Choice 2: キーバインドプリセットをどう適用するか

Options Considered:

1. 設定キー keybindings.preset で選択し、バンドル済みプリセットJSONを新しいバインドレイヤーとして合成する。
2. コマンドでプリセットのエントリを keybindings.json に全体上書きで書き込む。

Chosen Option: 1

Rationale: プリセット選択後の適用方法に複数の選択肢がある。既存の4層合成モデルとfallbackKeybindings.tsの資産読み込みパターンを再利用でき、ユーザーのkeybindings.jsonをクロバーしない。workbench.colorThemeと同じライブリロード機構も使える。

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: 起動時設定パス指定（CLIフラグ）

起動時に設定ファイルの場所を指定するCLIフラグを追加する。既存の「消費側でdeps.pathを上書きし、既定はpaths.tsヘルパーに委ねる」規約に従う。paths.ts自体には環境変数分岐を追加しない。

Task 1: `--config` フラグの解析ヘルパーを追加する

起動引数から設定ディレクトリの上書き値を取り出す。

• packages/cli/src/argv.ts に純粋・同期の新ヘルパー（例: resolveConfigDirOverride(argv)）を追加する。--config の次のトークンを返す。値がなければ undefined を返す。
• resolveStartupTarget の位置引数走査を更新する。--config <path> の値トークンを位置引数として誤認しないようにする。
• 例外を投げず、不正時はundefinedに退避する既存方針を踏襲する。

Task 2: `ConfigService` にパス上書きの受け口を追加する

設定ディレクトリ上書きからsettings.jsonとkeybindings.jsonのパスを導出する。

• packages/core/src/config/service.ts の ConfigServiceDeps に任意の settingsPath? と keybindingsPath? を追加する。既定値は deps.settingsPath ?? getUserSettingsPath()、deps.keybindingsPath ?? getUserKeybindingsPath() とする。
• themeSettingsWriter.ts / keybindingsCommands.ts の deps.path ?? getUserXPath() 規約を踏襲する。
• ワークスペース設定層の解決は変更しない。

Task 3: CLI起動経路に上書き値を通す

解析した設定ディレクトリを合成ルートへ届ける。

• packages/cli/src/main.ts の main(argv) で --config を解析する（--version と同じ先行処理位置）。
• RunTecodeOptions に上書き値を追加する（既存のheadless/cwd等の上書き規約に合わせる）。
• buildAssemblyRoot の deps に上書き値を追加し、createConfigService({...}) 呼び出しへ settingsPath / keybindingsPath として渡す。指定した設定ディレクトリから両パスを導出する。

Task 4: フラグ解析とパス上書きのテストを追加する

新しい挙動を検証する。

• packages/cli/src/argv.test.ts に --config 解析と位置引数の非誤認を検証するテストを追加する。
• packages/core/src/config/service.ts 用のテストで、上書きパスからの読み込みを検証する。既存の注入fsシームとbun:test規約を用いる。

🤖 Prompt for AI agents

このフェーズでは、起動時に設定ファイルの場所を指定するCLIフラグ`--config`を実装する。目的は、設定ディレクトリの上書きを`argv.ts`から`main.ts`を経て`createConfigService`まで通すことである。既存の「消費側で`deps.path`を上書きし、既定は`paths.ts`ヘルパーに委ねる」規約に従う。`paths.ts`自体には環境変数分岐を追加しない。

手順は次の順で行う。

1. `packages/cli/src/argv.ts` に純粋・同期の新ヘルパー（例:
`resolveConfigDirOverride(argv)`）を追加する。このヘルパーは `--config` の次のトークンを返す。値がなければ
`undefined` を返す。例外を投げず、不正時は`undefined`に退避する既存方針を踏襲する。`resolveStartupTarget`
の位置引数走査を更新し、`--config <path>` の値トークンを位置引数として誤認しないようにする。

2. `packages/core/src/config/service.ts` の `ConfigServiceDeps` に任意の
`settingsPath?` と `keybindingsPath?` を追加する。既定値は `deps.settingsPath ??
getUserSettingsPath()`、`deps.keybindingsPath ?? getUserKeybindingsPath()`
とする。`themeSettingsWriter.ts` / `keybindingsCommands.ts` の `deps.path ??
getUserXPath()` 規約を踏襲する。ワークスペース設定層の解決は変更しない。

3. `packages/cli/src/main.ts` の `main(argv)` で `--config` を、`--version`
と同じ先行処理位置で解析する。`RunTecodeOptions`
に上書き値を追加する（既存の`headless`/`cwd`等の上書き規約に合わせる）。`buildAssemblyRoot` の `deps`
に上書き値を追加し、`createConfigService({...})` 呼び出しへ `settingsPath` / `keybindingsPath`
として渡す。指定した設定ディレクトリから両パスを導出する。

4. テストを追加する。`packages/cli/src/argv.test.ts` に `--config`
解析と位置引数の非誤認を検証するテストを追加する。`packages/core/src/config/service.ts`
用のテストで、上書きパスからの読み込みを検証する。既存の注入`fs`シームと`bun:test`規約を用いる。

Phase 2: キーバインドプリセット基盤

Emacs風・vim風・Windows風のプリセットをバンドルする。設定キーkeybindings.presetで選択し、新しいバインドレイヤーとして合成する。fallbackKeybindings.tsの資産読み込みパターンとworkbench.colorThemeのライブリロード機構を再利用する。

Task 1: プリセットJSON資産を追加する

3種類のプリセットをバンドル済み資産として用意する。

• packages/core/src/keymap/presets/ に keybindings.preset.emacs.json、keybindings.preset.vim.json、keybindings.preset.windows.json を作成する。形式は既存の KeybindingContribution[]（{ key, command, when? }）に合わせる。
• 各プリセットは本リポジトリの実在コマンドのみを対象とする。-command 削除構文でデフォルトを無効化できる。

Task 2: プリセット読み込みローダを追加する

選択名からプリセットのエントリ配列を返す。

• packages/core/src/keymap/ に keybindingPresets.ts（仮）を追加する。名前（emacs/vim/windows/default）を受け取り、対応するバンドル資産を返すローダを実装する。
• fallbackKeybindings.ts の防御的な読み込み方針を踏襲する。未知の名前や default は空配列を返す。例外を投げない。

Task 3: プリセットレイヤーをバインドテーブルに追加する

プリセットをデフォルトとユーザーの中間に配置する。

• packages/core/src/keymap/bindingTable.ts の LAYER_ORDER に preset 層を追加する。優先順位は defaults < preset < fallback < extension < user とする。プリセットはデフォルトを上書きし、ユーザーのkeybindings.jsonはプリセットを上書きする。
• packages/cli/src/keymapState.ts に setPresetEntries(entries) を追加する。preset 層を置き換え、BindingTable を再構築する。

Task 4: 設定キーとライブリロードを配線する

keybindings.preset を読み、プリセットを適用する。

• packages/core/src/config/coreDefaults.ts に keybindings.preset（string、既定 "default"）を登録する。workbench.colorTheme の登録に倣う。
• packages/cli/src/main.ts の buildAssemblyRoot で初期の keybindings.preset 値を読み、ローダで解決し keymap.setPresetEntries(...) を呼ぶ。
• ConfigService.onDidChange を購読し、keybindings.preset 変更時にプリセットを再解決して setPresetEntries を呼ぶ。再起動なしで切り替わる。

Task 5: プリセット基盤のテストを追加する

プリセット選択と合成順を検証する。

• 各プリセットJSONが parseJsonc で配列に解析でき、compileEntry が警告を出さないことを検証する。sampleConfig.test.ts のパターンに倣う。
• preset 層のエントリがデフォルトに勝ち、ユーザー層に負けることを bindingTable.ts のテストで検証する。

🤖 Prompt for AI agents

このフェーズでは、Emacs風・vim風・Windows風のキーバインドプリセットをバンドルし、設定キー`keybindings.preset`で選択できる仕組みを実装する。目的は、選択したプリセットを新しいバインドレイヤーとして合成することである。`fallbackKeybindings.ts`の資産読み込みパターンと`workbench.colorTheme`のライブリロード機構を再利用する。

手順は次の順で行う。

1. `packages/core/src/keymap/presets/` に
`keybindings.preset.emacs.json`、`keybindings.preset.vim.json`、`keybindings.preset.windows.json`
を作成する。形式は既存の `KeybindingContribution[]`（`{ key, command, when?
}`）に合わせる。各プリセットは本リポジトリの実在コマンドのみを対象とする。`-command` 削除構文でデフォルトを無効化できる。

2. `packages/core/src/keymap/` に
`keybindingPresets.ts`（仮）を追加する。名前（`emacs`/`vim`/`windows`/`default`）を受け取り、対応するバンドル資産を返すローダを実装する。`fallbackKeybindings.ts`
の防御的な読み込み方針を踏襲する。未知の名前や `default` は空配列を返し、例外を投げない。

3. `packages/core/src/keymap/bindingTable.ts` の `LAYER_ORDER` に `preset`
層を追加する。優先順位は `defaults < preset < fallback < extension < user`
とする。プリセットはデフォルトを上書きし、ユーザーの`keybindings.json`はプリセットを上書きする。`packages/cli/src/keymapState.ts`
に `setPresetEntries(entries)` を追加し、`preset` 層を置き換えて `BindingTable` を再構築する。

4. `packages/core/src/config/coreDefaults.ts` に `keybindings.preset`（string、既定
`"default"`）を登録する。`workbench.colorTheme` の登録に倣う。`packages/cli/src/main.ts` の
`buildAssemblyRoot` で初期の `keybindings.preset` 値を読み、ローダで解決し
`keymap.setPresetEntries(...)` を呼ぶ。`ConfigService.onDidChange`
を購読し、`keybindings.preset` 変更時にプリセットを再解決して `setPresetEntries`
を呼び、再起動なしで切り替わるようにする。

5. テストを追加する。各プリセットJSONが `parseJsonc` で配列に解析でき、`compileEntry`
が警告を出さないことを検証する（`sampleConfig.test.ts` のパターンに倣う）。`preset`
層のエントリがデフォルトに勝ち、ユーザー層に負けることを `bindingTable.ts` のテストで検証する。

Phase 3: プリセット選択コマンドとサンプル・仕様更新

プリセットをアプリ内で選択するコマンドを追加する。選択結果をsettings.jsonへ書き込む。サンプルとドキュメント、spec文書を更新する。

Task 1: プリセット選択コマンドを追加する

クイックピックでプリセットを選ぶ。

• packages/builtin/keybindings-editor/ に keybindings.selectPreset コマンドを追加する（manifest.ts と index.ts）。theme.select の薄いラッパー構造に倣う。
• 選択肢は「Default / Emacs / Vim / Windows」とする。選択結果は特権ブリッジコマンド経由で永続化する。

Task 2: プリセット選択を`settings.json`へ書き込む

keybindings.preset キーを設定ファイルへ書き込む。

• packages/core/src/ui/keybindingsCommands.ts に特権ハンドラ（例: keybindings.internal.setPreset）を追加する。keybindings.preset を settings.json に書き込む。
• themeSettingsWriter.ts の単一キー・テキスト置換書き込み（コメント・他設定を保持、直列化書き込みチェーン、例外を投げない）を再利用する。書き込み後はConfigServiceのfs.watchが変更を検知し、Task 2.4のリロードが適用される。

Task 3: サンプルとドキュメントを更新する

プリセットの利用方法を文書化する。

• samples/ に各プリセットの参照用ファイルと、settings.json への keybindings.preset 設定例を追加する。
• docs/extension-authoring-guide.md（またはユーザー向けドキュメント）に、--config フラグとプリセット選択の使い方を追記する。
• packages/cli/src/sampleConfig.test.ts にサンプルプリセットの正当性検証を追加する。

Task 4: spec文書を更新する

spec駆動の規約に従い要件を追記する。

• requirements.md に「起動時設定パス指定」と「キーバインドプリセット」の要件を追記する。既存のEARS形式・番号付けに合わせる。
• design.md の §6（Keymap Service）と §11（Configuration）に、プリセット層とCLIフラグの設計を追記する。
• tasks.md に対応タスクを追加する。

🤖 Prompt for AI agents

このフェーズでは、アプリ内でキーバインドプリセットを選択するコマンドを実装し、選択結果を`settings.json`へ永続化する。加えて、サンプル・ドキュメント・spec文書を更新する。

手順は次の順で行う。

1. `packages/builtin/keybindings-editor/` に `keybindings.selectPreset`
コマンドを追加する（`manifest.ts` と `index.ts`）。`theme.select` の薄いラッパー構造に倣う。選択肢は「Default /
Emacs / Vim / Windows」とする。選択結果は特権ブリッジコマンド経由で永続化する。

2. `packages/core/src/ui/keybindingsCommands.ts` に特権ハンドラ（例:
`keybindings.internal.setPreset`）を追加する。このハンドラは `keybindings.preset` を
`settings.json` に書き込む。`themeSettingsWriter.ts`
の単一キー・テキスト置換書き込み（コメント・他設定を保持、直列化書き込みチェーン、例外を投げない）を再利用する。書き込み後は`ConfigService`の`fs.watch`が変更を検知し、Phase
2のリロード処理が適用される。

3. `samples/` に各プリセットの参照用ファイルと、`settings.json` への `keybindings.preset`
設定例を追加する。`docs/extension-authoring-guide.md`（またはユーザー向けドキュメント）に、`--config`
フラグとプリセット選択の使い方を追記する。`packages/cli/src/sampleConfig.test.ts`
にサンプルプリセットの正当性検証を追加する。

4. spec駆動の規約に従い、`requirements.md`
に「起動時設定パス指定」と「キーバインドプリセット」の要件を追記する（既存のEARS形式・番号付けに合わせる）。`design.md` の §6（Keymap
Service）と §11（Configuration）に、プリセット層とCLIフラグの設計を追記する。`tasks.md` に対応タスクを追加する。

Research

本リポジトリはspec駆動である。requirements.md・design.md・tasks.mdが要件番号で相互参照される。

設定の読み込みはpackages/core/src/config/service.tsのcreateConfigService()が担当する。読み込み元は次の3層である。

• ~/.config/tecode/settings.json（Windowsは%APPDATA%\tecode\settings.json）
• ワークスペースの.tecode/settings.json
• ~/.config/tecode/keybindings.json

パス解決はpackages/core/src/host/paths.tsが担当する。

キーバインドはpackages/core/src/keymap/bindingTable.tsがdefaults < fallback < extension < userの4層で合成する。keybindings.fallback.jsonはバンドル済みJSON資産である。fallbackKeybindings.tsがこれを読み込む。

CLI引数の解析はpackages/cli/src/argv.tsが位置引数のみを処理する。

設定書き込みの前例はpackages/core/src/ui/themeSettingsWriter.tsにある。

ホームディレクトリからのデフォルト設定読み込みは既に存在する。存在しないのは次の2点である。

• 起動時に設定ファイルの場所を指定するCLIフラグ
• キーバインドのプリセット機構

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

このフェーズでは、起動時に設定ファイルの場所を指定するCLIフラグ`--config`を実装する。目的は、設定ディレクトリの上書きを`argv.ts`から`main.ts`を経て`createConfigService`まで通すことである。既存の「消費側で`deps.path`を上書きし、既定は`paths.ts`ヘルパーに委ねる」規約に従う。`paths.ts`自体には環境変数分岐を追加しない。

手順は次の順で行う。

1. `packages/cli/src/argv.ts` に純粋・同期の新ヘルパー（例:
`resolveConfigDirOverride(argv)`）を追加する。このヘルパーは `--config` の次のトークンを返す。値がなければ
`undefined` を返す。例外を投げず、不正時は`undefined`に退避する既存方針を踏襲する。`resolveStartupTarget`
の位置引数走査を更新し、`--config <path>` の値トークンを位置引数として誤認しないようにする。

2. `packages/core/src/config/service.ts` の `ConfigServiceDeps` に任意の
`settingsPath?` と `keybindingsPath?` を追加する。既定値は `deps.settingsPath ??
getUserSettingsPath()`、`deps.keybindingsPath ?? getUserKeybindingsPath()`
とする。`themeSettingsWriter.ts` / `keybindingsCommands.ts` の `deps.path ??
getUserXPath()` 規約を踏襲する。ワークスペース設定層の解決は変更しない。

3. `packages/cli/src/main.ts` の `main(argv)` で `--config` を、`--version`
と同じ先行処理位置で解析する。`RunTecodeOptions`
に上書き値を追加する（既存の`headless`/`cwd`等の上書き規約に合わせる）。`buildAssemblyRoot` の `deps`
に上書き値を追加し、`createConfigService({...})` 呼び出しへ `settingsPath` / `keybindingsPath`
として渡す。指定した設定ディレクトリから両パスを導出する。

4. テストを追加する。`packages/cli/src/argv.test.ts` に `--config`
解析と位置引数の非誤認を検証するテストを追加する。`packages/core/src/config/service.ts`
用のテストで、上書きパスからの読み込みを検証する。既存の注入`fs`シームと`bun:test`規約を用いる。
===============================================================================

Task: 2

このフェーズでは、Emacs風・vim風・Windows風のキーバインドプリセットをバンドルし、設定キー`keybindings.preset`で選択できる仕組みを実装する。目的は、選択したプリセットを新しいバインドレイヤーとして合成することである。`fallbackKeybindings.ts`の資産読み込みパターンと`workbench.colorTheme`のライブリロード機構を再利用する。

手順は次の順で行う。

1. `packages/core/src/keymap/presets/` に
`keybindings.preset.emacs.json`、`keybindings.preset.vim.json`、`keybindings.preset.windows.json`
を作成する。形式は既存の `KeybindingContribution[]`（`{ key, command, when?
}`）に合わせる。各プリセットは本リポジトリの実在コマンドのみを対象とする。`-command` 削除構文でデフォルトを無効化できる。

2. `packages/core/src/keymap/` に
`keybindingPresets.ts`（仮）を追加する。名前（`emacs`/`vim`/`windows`/`default`）を受け取り、対応するバンドル資産を返すローダを実装する。`fallbackKeybindings.ts`
の防御的な読み込み方針を踏襲する。未知の名前や `default` は空配列を返し、例外を投げない。

3. `packages/core/src/keymap/bindingTable.ts` の `LAYER_ORDER` に `preset`
層を追加する。優先順位は `defaults < preset < fallback < extension < user`
とする。プリセットはデフォルトを上書きし、ユーザーの`keybindings.json`はプリセットを上書きする。`packages/cli/src/keymapState.ts`
に `setPresetEntries(entries)` を追加し、`preset` 層を置き換えて `BindingTable` を再構築する。

4. `packages/core/src/config/coreDefaults.ts` に `keybindings.preset`（string、既定
`"default"`）を登録する。`workbench.colorTheme` の登録に倣う。`packages/cli/src/main.ts` の
`buildAssemblyRoot` で初期の `keybindings.preset` 値を読み、ローダで解決し
`keymap.setPresetEntries(...)` を呼ぶ。`ConfigService.onDidChange`
を購読し、`keybindings.preset` 変更時にプリセットを再解決して `setPresetEntries`
を呼び、再起動なしで切り替わるようにする。

5. テストを追加する。各プリセットJSONが `parseJsonc` で配列に解析でき、`compileEntry`
が警告を出さないことを検証する（`sampleConfig.test.ts` のパターンに倣う）。`preset`
層のエントリがデフォルトに勝ち、ユーザー層に負けることを `bindingTable.ts` のテストで検証する。
===============================================================================

Task: 3

このフェーズでは、アプリ内でキーバインドプリセットを選択するコマンドを実装し、選択結果を`settings.json`へ永続化する。加えて、サンプル・ドキュメント・spec文書を更新する。

手順は次の順で行う。

1. `packages/builtin/keybindings-editor/` に `keybindings.selectPreset`
コマンドを追加する（`manifest.ts` と `index.ts`）。`theme.select` の薄いラッパー構造に倣う。選択肢は「Default /
Emacs / Vim / Windows」とする。選択結果は特権ブリッジコマンド経由で永続化する。

2. `packages/core/src/ui/keybindingsCommands.ts` に特権ハンドラ（例:
`keybindings.internal.setPreset`）を追加する。このハンドラは `keybindings.preset` を
`settings.json` に書き込む。`themeSettingsWriter.ts`
の単一キー・テキスト置換書き込み（コメント・他設定を保持、直列化書き込みチェーン、例外を投げない）を再利用する。書き込み後は`ConfigService`の`fs.watch`が変更を検知し、Phase
2のリロード処理が適用される。

3. `samples/` に各プリセットの参照用ファイルと、`settings.json` への `keybindings.preset`
設定例を追加する。`docs/extension-authoring-guide.md`（またはユーザー向けドキュメント）に、`--config`
フラグとプリセット選択の使い方を追記する。`packages/cli/src/sampleConfig.test.ts`
にサンプルプリセットの正当性検証を追加する。

4. spec駆動の規約に従い、`requirements.md`
に「起動時設定パス指定」と「キーバインドプリセット」の要件を追記する（既存のEARS形式・番号付けに合わせる）。`design.md` の §6（Keymap
Service）と §11（Configuration）に、プリセット層とCLIフラグの設計を追記する。`tasks.md` に対応タスクを追加する。

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

[goofmint]

実装完了につきクローズします。PR #85（起動時指定）と PR #86（プリセット）の 2 本に分けてマージしました。

自動クローズされなかったのは、PR #86 の本文に "Completes #81" と書いており、GitHub が認識する closing keyword（fix / closes / resolves）ではなかったためです。

対応内容

起動時の指定 — --config <dir> を追加しました。設定ディレクトリを指し、そこから settings.json と keybindings.json の両方を導出します。上書きはユーザー層のみで、ワークスペース設定（.tecode/settings.json）は従来どおりです。

ホームディレクトリからの既定読み込み — これは着手前から既に動作していました（~/.config/tecode/、Windows は %APPDATA%\tecode\）。本 Issue で不足していたのは起動時の上書き手段のみだったので、そこだけを足しています。

キーバインドのサンプル — Emacs と Windows 風をバンドル済みプリセットとして同梱し、keybindings.preset 設定で選択できます。再起動なしで反映されます。

vim を含めていない理由

「vimはいいや」とのご指示に従い外しました。記録として残しておくと、tecode にはモードの概念がありません。when 句で使えるコンテキストは editorTextFocus / editorFocus / quickPickFocus / inputBoxFocus / findWidgetFocus / explorerFocus / editorLangId のみで、すべてフォーカス基準です。vim の本質はモーダル編集なので、単なるキー再割り当てで作った「vim プリセット」は期待を裏切るものになっていたはずです。将来モード機構を入れる際に、改めて別 Issue として起こすのが妥当だと考えます。

実装上の注意点 2 点

Windows プリセットは薄いです。 既定キーマップが既に VS Code 風なので、実質的な差分は行移動が alt+meta+up / alt+meta+down（Cmd 前提の macOS イディオム）になっている点を alt+up / alt+down で補うことと、shift+alt+down の複製の計 3 件だけです。水増しせず、薄いことを README とローダの TSDoc に明記しています。

バインド層の順序を変更しました。 当初計画は defaults < preset < fallback < extension < user でしたが、これでは動きません。bindingTable.ts の visibleEntries は -command 削除より厳密に小さい order のみをマスクするため、preset が extension より下だと拡張のバインドを削除も上書きもできません。正しくは defaults < fallback < extension < preset < user です。

これは Emacs プリセットに必須でした。keybindings-editor が ctrl+k ctrl+s を既定で持っており、chords.ts は完全一致より先に無条件で prefix を判定する（「prefix wins」）ため、ctrl+k → kill-line を素朴に足しても 2 打鍵目を待つだけで発火しません。プリセット側に削除レコードを置く必要があり、それが機能するのはこの順序のおかげです。

あわせて design.md §6.2 と Req 4.1 が 3 層のままだった点も修正しました。preset だけでなく、Task 4.2 から存在する fallback 層も記載が漏れていました。

---

Generated by Claude Code