T12を実装する

[goofmint]

@.tmp/tasks.mdを読んで、T11の実装計画を作成する。

[goofmint]

@coderabbitai 実装計画を日本語で作成して。完了要件も記載して。

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• T11の実装 #17

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• src/i18n/ja.tsとsrc/i18n/en.tsにフラットキー構造で全メッセージを集約し、型安全なgetMessage()ヘルパーで取得する方式を採用
• 既存の関数型パラメータ付きメッセージパターンを維持し、コードベースの一貫性を保つ
• 未ローカライズだったhistory、restore、serve、configコマンドも同時に日本語化
• キーセット一致テストとgrep検出テストで継続的な品質を担保

Design Choices

Design Choice 1: パラメータ付きメッセージの実装方式

Options Considered:

1. 関数型を維持：getMessage(lang, 'cli.search.badLimit')(got)のように呼び出す
2. テンプレート文字列方式：getMessage(lang, 'cli.search.badLimit', { got })でプレースホルダを置換

Chosen Option: 1

Rationale: 既存のコードパターンと一貫性があり、TypeScriptの型安全性も維持できるため関数型を維持する。

💡 User Tips

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

Implementation Steps

Phase 1: i18n基盤の構築

集約されたメッセージ辞書の型定義とja/enファイルを作成し、メッセージ取得ヘルパーを提供する。

Task 1: メッセージ辞書の型定義

i18n基盤の型定義を作成し、全メッセージキーとその型（stringまたは関数）を定義する。

• src/i18n/types.tsを新規作成し、MessageKey型とMessages型を定義
• フラットキー構造を採用（例：cli.add.usage、cli.search.badLimit、mcp.saveMemory.description）
• 静的メッセージはstring型、パラメータ付きメッセージは関数型（例：(got: string) => string）で定義

Task 2: 日本語メッセージ辞書の作成

全メッセージの日本語版を集約したファイルを作成する。

• src/i18n/ja.tsを新規作成
• 既存コマンドのMESSAGES.jaから全メッセージを移行
  • add.ts、update.ts、delete.ts、get.ts、search.ts、recent.ts、reindex.tsのMESSAGES
  • main.tsのUSAGEとUNKNOWN_COMMAND
• 未ローカライズコマンドの日本語メッセージを新規追加
  • history.ts: 使用法、ノット未検出エラー
  • restore.ts: 使用法、ノット未検出エラー、復元成功メッセージ
  • serve.ts: 予期しない引数エラー
  • config.ts: 各種使用法、不明なキーエラー、無効な値エラー等

Task 3: 英語メッセージ辞書の作成

全メッセージの英語版を集約したファイルを作成する。

• src/i18n/en.tsを新規作成
• 既存コマンドのMESSAGES.enから全メッセージを移行
• 未ローカライズコマンドの英語メッセージ（現在のハードコード文字列をそのまま移行）

Task 4: メッセージ取得ヘルパーの実装

言語とキーを指定してメッセージを取得するユーティリティ関数を実装する。

• src/i18n/index.tsを更新し、getMessage(lang: Lang, key: MessageKey)関数をエクスポート
• 型安全性を維持し、存在しないキーはコンパイルエラーとなるよう設計
• ja.tsとen.tsを内部でインポートし、langに応じた辞書から値を返却

🤖 Prompt for AI agents

フェーズ1では、i18nメッセージ管理の基盤となる型定義・辞書ファイル・ヘルパー関数を新規作成する。目的は、全CLIコマンドおよびMCPツールのメッセージを一元管理できる構造を整備することである。

**Task 1.1: `src/i18n/types.ts`の新規作成**
-
`MessageKey`型を定義し、フラットキー構造（例：`cli.add.usage`、`cli.search.badLimit`、`mcp.saveMemory.description`）を採用する
- `Messages`型を定義し、各キーに対して静的メッセージは`string`型、パラメータ付きメッセージは関数型（例：`(got: string) =>
string`）を割り当てる

**Task 1.2: `src/i18n/ja.ts`の新規作成**
-
以下の既存コマンドから`MESSAGES.ja`の内容を全て移行する：`add.ts`、`update.ts`、`delete.ts`、`get.ts`、`search.ts`、`recent.ts`、`reindex.ts`
- `src/cli/main.ts`の`USAGE`と`UNKNOWN_COMMAND`の日本語版も移行する
- 以下の未ローカライズコマンドの日本語メッセージを新規追加する：
  - `history.ts`：使用法、ノット未検出エラー
  - `restore.ts`：使用法、ノット未検出エラー、復元成功メッセージ
  - `serve.ts`：予期しない引数エラー
  - `config.ts`：各種使用法、不明なキーエラー、無効な値エラー等

**Task 1.3: `src/i18n/en.ts`の新規作成**
- 同じキー構造で、既存コマンドの`MESSAGES.en`の内容を全て移行する
- 未ローカライズコマンドの現在のハードコード英語文字列をそのまま移行する

**Task 1.4: `src/i18n/index.ts`の更新**
- `getMessage(lang: Lang, key: MessageKey)`関数をエクスポートする
- 内部で`ja.ts`と`en.ts`をインポートし、`lang`の値に応じて対応する辞書から値を返す
- 存在しないキーはコンパイルエラーになるよう、TypeScriptの型安全性を維持する

Phase 2: CLIコマンドの移行

全CLIコマンドを集約辞書に移行し、ハードコードされた文字列を排除する。

Task 1: 既存ローカライズ済みコマンドの移行

現在MESSAGES定数を持つコマンドを集約辞書使用に切り替える。

• 対象ファイル：src/cli/commands/add.ts、update.ts、delete.ts、get.ts、search.ts、recent.ts、reindex.ts
• 各ファイルからMESSAGES定数を削除
• getMessage(lang, 'cli.xxx.yyy')呼び出しに置換
• src/i18nからgetMessageをインポート

Task 2: main.tsの移行

CLIメインエントリーポイントのUSAGEとUNKNOWN_COMMANDを集約辞書に移行する。

• src/cli/main.tsのUSAGEとUNKNOWN_COMMAND定数を削除
• getMessage(lang, 'cli.usage')およびgetMessage(lang, 'cli.unknownCommand')(cmd)に置換

Task 3: 未ローカライズコマンドの国際化

現在英語のみのコマンドを多言語対応にする。

• 対象ファイル：src/cli/commands/history.ts、restore.ts、serve.ts、config.ts
• resolveLang()のインポートを追加
• ハードコード文字列をgetMessage(lang, 'cli.xxx.yyy')呼び出しに置換
• 終了コードを名前付き定数（EXIT_SUCCESS、EXIT_USER_ERROR、EXIT_INTERNAL_ERROR）に統一

🤖 Prompt for AI agents

フェーズ2では、全CLIコマンドファイルをフェーズ1で構築したi18n基盤に移行する。目的は、各コマンドファイルからローカルの`MESSAGES`定数およびハードコード文字列を削除し、`getMessage()`ヘルパーに一本化することである。

**Task 2.1: 既存ローカライズ済みコマンドの移行**
-
対象ファイル：`src/cli/commands/add.ts`、`update.ts`、`delete.ts`、`get.ts`、`search.ts`、`recent.ts`、`reindex.ts`
- 各ファイルから`MESSAGES`定数の定義を削除する
- メッセージ参照箇所を`getMessage(lang, 'cli.xxx.yyy')`の呼び出しに置換する
- `src/i18n`から`getMessage`をインポートする

**Task 2.2: `src/cli/main.ts`の移行**
- `USAGE`と`UNKNOWN_COMMAND`の定数定義を削除する
- 参照箇所をそれぞれ`getMessage(lang, 'cli.usage')`および`getMessage(lang,
'cli.unknownCommand')(cmd)`に置換する

**Task 2.3: 未ローカライズコマンドの国際化**
- 対象ファイル：`src/cli/commands/history.ts`、`restore.ts`、`serve.ts`、`config.ts`
- `resolveLang()`のインポートを追加し、言語を解決する
- 既存のハードコード文字列を`getMessage(lang, 'cli.xxx.yyy')`の呼び出しに置換する
- 終了コードを名前付き定数（`EXIT_SUCCESS`、`EXIT_USER_ERROR`、`EXIT_INTERNAL_ERROR`）に統一する

Phase 3: MCPツールの国際化と検証テスト

MCPツールのdescriptionを多言語化し、品質保証のためのテストを追加する。

Task 1: MCPツールdescriptionの辞書追加

全MCPツールのdescription文字列を辞書に追加する。

• src/i18n/ja.tsにmcp.saveMemory.description等のキーで日本語説明を追加
• src/i18n/en.tsに現在の英語descriptionをそのまま移行
• 対象：save-memory、update-memory、delete-memory、search-memory、list-recent、get-note、status

Task 2: MCPツールのdescription動的取得

MCPサーバー起動時に言語に応じたdescriptionを使用するよう修正する。

• src/mcp/server.tsでresolveLang()を呼び出し、言語を決定
• 各ツール登録時にgetMessage(lang, 'mcp.xxx.description')でdescriptionを取得
• 必要に応じてツールファイル（src/mcp/tools/*.ts）のDESCRIPTION定数を削除

Task 3: キーセット一致テストの作成

ja.tsとen.tsが同一のキーセットを持つことを検証するユニットテストを作成する。

• src/i18n/__tests__/keys.test.tsを新規作成
• ja辞書とen辞書のキー一覧を取得し、集合比較
• 不一致があればテスト失敗とし、差分を出力

Task 4: ハードコード文字列検出テストの作成

CLIコマンドにハードコードされた日本語/英語文字列が残っていないことを検証する。

• src/cli/__tests__/no-hardcoded-strings.test.tsを新規作成
• src/cli/commands/*.tsとsrc/cli/main.tsを対象にgrepパターンでチェック
• 許可リスト（コマンド名、フラグ名等）以外のユーザー向け文字列を検出したらテスト失敗

🤖 Prompt for AI agents

フェーズ3では、MCPツールのdescriptionを多言語化し、辞書の品質を保証するテストを追加する。目的は、MCPツールの説明文もi18n基盤に統合し、キーセット一致・ハードコード文字列不在を自動検証できる体制を整えることである。

**Task 3.1: MCPツールdescriptionの辞書追加**
-
`src/i18n/ja.ts`に`mcp.saveMemory.description`等のキーで、以下7ツールの日本語説明を追加する：save-memory、update-memory、delete-memory、search-memory、list-recent、get-note、status
- `src/i18n/en.ts`に同キーで現在の英語descriptionをそのまま移行する

**Task 3.2: `src/mcp/server.ts`の更新**
- `resolveLang()`を呼び出して言語を決定する
- 各ツール登録時のdescriptionを`getMessage(lang, 'mcp.xxx.description')`で動的取得するよう変更する
- `src/mcp/tools/*.ts`内の`DESCRIPTION`定数が不要になった場合は削除する

**Task 3.3: `src/i18n/__tests__/keys.test.ts`の新規作成**
- ja辞書とen辞書のキー一覧をそれぞれ取得し、集合比較を行うユニットテストを実装する
- キーセットに不一致がある場合はテストを失敗させ、差分を出力する

**Task 3.4: `src/cli/__tests__/no-hardcoded-strings.test.ts`の新規作成**
- `src/cli/commands/*.ts`と`src/cli/main.ts`をgrepパターンでスキャンする
- 許可リスト（コマンド名、フラグ名等）以外のユーザー向けハードコード文字列が検出された場合はテストを失敗させる

Research

dennohはBunランタイムで動作するローカルファーストのナレッジ管理システム。CLIエントリーポイントはsrc/cli/main.tsで、14個のサブコマンドがsrc/cli/commands/配下に実装済み。現在、add、update、delete、get、search、recent、reindex、mainはMESSAGES: Record<Lang, {...}>パターンでja/en対応済みだが、history、restore、serve、configは英語のみ。MCPツールはsrc/mcp/tools/配下で、descriptionは全て英語ハードコード。src/i18n/index.tsは現在空のプレースホルダー。言語解決はsrc/config/index.tsのresolveLang()で実装済み（T12.2完了）。

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

フェーズ1では、i18nメッセージ管理の基盤となる型定義・辞書ファイル・ヘルパー関数を新規作成する。目的は、全CLIコマンドおよびMCPツールのメッセージを一元管理できる構造を整備することである。

**Task 1.1: `src/i18n/types.ts`の新規作成**
-
`MessageKey`型を定義し、フラットキー構造（例：`cli.add.usage`、`cli.search.badLimit`、`mcp.saveMemory.description`）を採用する
- `Messages`型を定義し、各キーに対して静的メッセージは`string`型、パラメータ付きメッセージは関数型（例：`(got: string) =>
string`）を割り当てる

**Task 1.2: `src/i18n/ja.ts`の新規作成**
-
以下の既存コマンドから`MESSAGES.ja`の内容を全て移行する：`add.ts`、`update.ts`、`delete.ts`、`get.ts`、`search.ts`、`recent.ts`、`reindex.ts`
- `src/cli/main.ts`の`USAGE`と`UNKNOWN_COMMAND`の日本語版も移行する
- 以下の未ローカライズコマンドの日本語メッセージを新規追加する：
  - `history.ts`：使用法、ノット未検出エラー
  - `restore.ts`：使用法、ノット未検出エラー、復元成功メッセージ
  - `serve.ts`：予期しない引数エラー
  - `config.ts`：各種使用法、不明なキーエラー、無効な値エラー等

**Task 1.3: `src/i18n/en.ts`の新規作成**
- 同じキー構造で、既存コマンドの`MESSAGES.en`の内容を全て移行する
- 未ローカライズコマンドの現在のハードコード英語文字列をそのまま移行する

**Task 1.4: `src/i18n/index.ts`の更新**
- `getMessage(lang: Lang, key: MessageKey)`関数をエクスポートする
- 内部で`ja.ts`と`en.ts`をインポートし、`lang`の値に応じて対応する辞書から値を返す
- 存在しないキーはコンパイルエラーになるよう、TypeScriptの型安全性を維持する
===============================================================================

Task: 2

フェーズ2では、全CLIコマンドファイルをフェーズ1で構築したi18n基盤に移行する。目的は、各コマンドファイルからローカルの`MESSAGES`定数およびハードコード文字列を削除し、`getMessage()`ヘルパーに一本化することである。

**Task 2.1: 既存ローカライズ済みコマンドの移行**
-
対象ファイル：`src/cli/commands/add.ts`、`update.ts`、`delete.ts`、`get.ts`、`search.ts`、`recent.ts`、`reindex.ts`
- 各ファイルから`MESSAGES`定数の定義を削除する
- メッセージ参照箇所を`getMessage(lang, 'cli.xxx.yyy')`の呼び出しに置換する
- `src/i18n`から`getMessage`をインポートする

**Task 2.2: `src/cli/main.ts`の移行**
- `USAGE`と`UNKNOWN_COMMAND`の定数定義を削除する
- 参照箇所をそれぞれ`getMessage(lang, 'cli.usage')`および`getMessage(lang,
'cli.unknownCommand')(cmd)`に置換する

**Task 2.3: 未ローカライズコマンドの国際化**
- 対象ファイル：`src/cli/commands/history.ts`、`restore.ts`、`serve.ts`、`config.ts`
- `resolveLang()`のインポートを追加し、言語を解決する
- 既存のハードコード文字列を`getMessage(lang, 'cli.xxx.yyy')`の呼び出しに置換する
- 終了コードを名前付き定数（`EXIT_SUCCESS`、`EXIT_USER_ERROR`、`EXIT_INTERNAL_ERROR`）に統一する
===============================================================================

Task: 3

フェーズ3では、MCPツールのdescriptionを多言語化し、辞書の品質を保証するテストを追加する。目的は、MCPツールの説明文もi18n基盤に統合し、キーセット一致・ハードコード文字列不在を自動検証できる体制を整えることである。

**Task 3.1: MCPツールdescriptionの辞書追加**
-
`src/i18n/ja.ts`に`mcp.saveMemory.description`等のキーで、以下7ツールの日本語説明を追加する：save-memory、update-memory、delete-memory、search-memory、list-recent、get-note、status
- `src/i18n/en.ts`に同キーで現在の英語descriptionをそのまま移行する

**Task 3.2: `src/mcp/server.ts`の更新**
- `resolveLang()`を呼び出して言語を決定する
- 各ツール登録時のdescriptionを`getMessage(lang, 'mcp.xxx.description')`で動的取得するよう変更する
- `src/mcp/tools/*.ts`内の`DESCRIPTION`定数が不要になった場合は削除する

**Task 3.3: `src/i18n/__tests__/keys.test.ts`の新規作成**
- ja辞書とen辞書のキー一覧をそれぞれ取得し、集合比較を行うユニットテストを実装する
- キーセットに不一致がある場合はテストを失敗させ、差分を出力する

**Task 3.4: `src/cli/__tests__/no-hardcoded-strings.test.ts`の新規作成**
- `src/cli/commands/*.ts`と`src/cli/main.ts`をgrepパターンでスキャンする
- 許可リスト（コマンド名、フラグ名等）以外のユーザー向けハードコード文字列が検出された場合はテストを失敗させる

💡 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.

---

💬 Have feedback or questions? Drop into our discord!

[goofmint]

@coderabbitai MCPサーバーとして利用する前提のツールで日本語化する意味はある？