1.11 Implement manifest validation and extension discovery

[goofmint]

Part of Phase 1 — Core skeleton (tasks.md Task 1.11).

Summary

Implement extension discovery, Manifest validation, contribution registration without code execution, and API-version checking.

Details

• Discovery order: embedded builtin/ registry → ~/.config/tecode/extensions/*/ → <workspace>/.tecode/extensions/*/ (Req 2.1).
• Hand-rolled validator in core/host/validate.ts with precise, path-annotated error messages (no runtime schema library — binary size).
• Invalid manifest → record HostError { extensionId?, path, message }, skip the extension, continue startup (Req 2.4).
• Duplicate IDs: later discovery wins (workspace > user > builtin); shadowed one reported as a warning.
• Registration walks contributes into: command registry (lazy commands), keymap layers, slot registry (lazy views), config schema registry, language registry, theme registry — without importing index.ts (Req 2.2).
• API-version check: same major, host minor >= requested; incompatible → skipped with surfaced error (Req 2.7).

Completion requirements

• Invalid manifest fixtures are skipped with useful errors; startup completes
• Shadowing order verified with same-ID fixtures across the three locations
• A module-load spy proves no extension index.ts executes during registration
• API-version accept/reject matrix tested (same major/minor, older minor, newer minor, different major)
• bun test and lint pass

References

• requirements.md: Req 2.1–2.4, 2.7
• design.md: §4.1, §4.3

Dependencies

Blocked by: 1.3 (#4), 1.4 (#5), 1.10 (#11).

[goofmint]

@coderabbitai make plan in Japanese

---

Generated by Claude Code

[coderabbitai]

Coding Plan

Summary

• 探索・検証・登録をpackages/core/src/host/に集約する。documentManager.tsのfs注入シームとDIパターンを踏襲する。
• 手書きバリデータをvalidate.tsに実装する。ランタイムスキーマライブラリは使わず、パス注記付きエラーを生成する。無効manifestはスキップし、起動を継続する。
• 既存レジストリ（コマンド、キーマップ、config schema）へ直接登録する。未実装のslot・language・themeレジストリ向けには宣言のみを収集し、後続タスクへ委譲する。
• lazyコマンド表現のため、コマンドレジストリを最小限拡張する。アクティベーション動作は1.12へ残す。

Design Choices

Design Choice 1: コマンドレジストリへの「lazy command」登録方法

Options Considered:

1. commands/registry.tsを最小限拡張する。CommandEntryにextensionId?とlazyを追加し、handlerを任意にする。lazyエントリのexecuteは現時点ではHostErrorを送出する（実アクティベーションは1.12で追加）。
2. コアを変更せず、ホスト側でラッパークロージャを登録する。各コマンドに対して、後でアクティベーション後の実ハンドラを再登録（last-wins）で上書きする。

Chosen Option: 1

Rationale: チケットが「command registry (lazy commands)」への登録を明示している。設計§5が拡張形を記述している。この2点から、レジストリを最小限拡張してlazyエントリを一級で表現する方が意図に合致する。

現在のcommands/registry.tsのregister(id, handler, meta?)はハンドラを必須とし、extensionIdやlazyフラグを持たない。設計§5はCommandEntry = { handler?, meta, extensionId?, lazy }という拡張形を記述するが未実装である。アクティベーション時の再ディスパッチ動作は1.12の担当である。

Design Choice 2: まだ存在しないslot・language・themeレジストリへのcontribution登録の扱い

Options Considered:

1. 探索結果に生のcontribution宣言を型別に収集して保持し、後続タスクがそこから消費する。
2. 1.11で最小のレジストリファイルを新規作成する。

Chosen Option: 1

Rationale: 実レジストリは各担当タスク（1.14、2.6、2.8）の責務である。1.11では宣言の収集のみを行い、スコープの逸脱を避ける。

slotレジストリは1.14、themeレジストリは2.6、languageレジストリは2.8で実装される。1.11の時点では、これらの実レジストリは存在しない。

💡 User Tips

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

Implementation Steps

Phase 1: 探索基盤の構築

このフェーズは、拡張機能ディレクトリを走査するための基盤を用意する。ファイルシステムアクセスの注入シーム、パス解決、組み込み拡張の静的レジストリ、および3か所の探索順序と重複ID処理を実装する。

Task 1: ファイルシステムシームとパス解決の追加

探索に必要なディレクトリ走査とパス解決を用意する。

• packages/core/src/host/に新規モジュールを作成する。documentManager.tsのDocumentManagerFsパターンに従い、readdir・statを含む狭い注入可能なfsインターフェースを定義する。既定値はnode:fs/promisesとする。
• 3つの探索元パスを解決する関数を追加する。組み込み、~/.config/tecode/extensions（XDG_CONFIG_HOMEを尊重し、未設定時はos.homedir()を使用）、および<workspace>/.tecode/extensionsを対象とする。ワークスペースルートは呼び出し元から引数で受け取る。
• エラー描画にはdocumentManager.tsのdescribeError/errorCodeパターンを再利用する。

Task 2: 組み込み拡張の静的レジストリの作成

組み込み拡張のmanifestデータを静的に集約する。

• 設計§4.1「Built-ins are compiled into the binary as ordinary imports」に従い、組み込みmanifestを静的配列として集約する集約点を用意する。
• 現状のpackages/builtin/*はプレースホルダであり、manifest.tsを持たない。1.11のスコープでは、組み込み探索元を空または既知のmanifestデータの静的配列として扱えるようにする。探索コードが3か所すべてを均一に処理できる構造にする。

Task 3: 3か所探索と重複ID遮蔽の実装

探索順序と重複ID解決を実装する。

• packages/core/src/host/に探索関数discover()を追加する。探索順序は組み込み → ユーザ設定 → ワークスペースとする（Req 2.1）。
• 各ディレクトリでmanifest.tsまたはmanifest.jsを動的import(pathToFileURL(file).href)で読み込む。index.tsは読み込まない（Req 2.2）。
• 重複IDは後の探索元が優先する（workspace > user > builtin）。遮蔽された拡張はHostLogにwarningとして記録する。
• 探索結果として、有効なmanifestとそのソースパス・extensionIdを含む構造を返す。

🤖 Prompt for AI agents

このフェーズでは、拡張機能ディレクトリを走査する探索基盤を実装する。目標は、fs注入シーム、パス解決、組み込みmanifestの静的集約点、3か所探索と重複ID遮蔽の完成である。

1.
`packages/core/src/host/`に新規モジュールを作成する。`documentManager.ts`の`DocumentManagerFs`パターンに従い、`readdir`・`stat`を含む狭い注入可能なfsインターフェースを定義する。既定値は`node:fs/promises`とする。
2.
3つの探索元パスを解決する関数を追加する。対象は組み込み、`~/.config/tecode/extensions`（`XDG_CONFIG_HOME`を尊重し、未設定時は`os.homedir()`を使用）、`<workspace>/.tecode/extensions`である。ワークスペースルートは呼び出し元からの引数で受け取る。
3. エラー描画には`documentManager.ts`の`describeError`/`errorCode`パターンを再利用する。
4. 設計§4.1「Built-ins are compiled into the binary as ordinary
imports」に従い、組み込みmanifestを静的配列として集約する集約点を用意する。`packages/builtin/*`は現状プレースホルダで`manifest.ts`を持たないため、組み込み探索元を空または既知のmanifestデータの静的配列として扱えるようにする。探索コードが3か所すべてを均一に処理できる構造にする。
5. `discover()`関数を追加する。探索順序は組み込み → ユーザ設定 → ワークスペースとする（Req 2.1）。
6.
各ディレクトリで`manifest.ts`または`manifest.js`を動的`import(pathToFileURL(file).href)`で読み込む。`index.ts`は読み込まない（Req
2.2）。
7. 重複IDは後の探索元を優先する（workspace > user > builtin）。遮蔽された拡張は`HostLog`にwarningとして記録する。
8. 探索結果として、有効なmanifestとそのソースパス・extensionIdを含む構造を返す。

Phase 2: Manifest検証とAPIバージョン確認

このフェーズは、ランタイムスキーマライブラリを使わない手書きのバリデータと、APIバージョン互換性チェックを実装する。無効なmanifestはスキップし、起動を継続する。

Task 1: 手書きManifestバリデータの実装

Manifest型に対する手書き検証を実装する。

• packages/core/src/host/validate.tsを新規作成する。ランタイムスキーマライブラリは使用しない（バイナリサイズのため）。
• packages/api/src/manifest.tsのManifest形状を検証対象とする。必須トップレベルフィールド（id、version、apiVersion、activationEvents、contributes）を検証する。
• activationEventsの文字列パターン（onStartup、onCommand:<id>、onLanguage:<id>）、およびcontributesの各サブ要素（commands、keybindings、views、languages、themes、configuration）の必須フィールドと型を検証する。
• 検証失敗時は、フィールドパスを注記した明確なエラーメッセージを生成する（例: contributes.commands[0].id）。
• 検証失敗時はHostError { extensionId?, path, message }を記録し、その拡張をスキップし、起動を継続する（Req 2.4）。host/errors.tsのHostLog/StatusSinkを使用する。

Task 2: APIバージョン互換性チェックの実装

manifestのapiVersionとホストのAPI_VERSIONの互換性を判定する。

• validate.tsまたは近接モジュールに互換性判定を追加する。ホストは@tecode/apiのAPI_VERSION = "1.0"を参照する。
• 互換性ルールは「メジャーが同一、かつホストのマイナー ≥ 要求マイナー」とする（設計§4.3）。manifestは"1"または"1.x"形式で宣言する。
• 非互換の拡張は登録段階でスキップし、不一致をHostErrorとして送出する。クラッシュしない（Req 2.7）。

🤖 Prompt for AI agents

このフェーズでは、手書きManifestバリデータとAPIバージョン互換性チェックを実装する。目標は、ランタイムスキーマライブラリを使わずに検証を行い、無効なmanifestはスキップして起動を継続することである。

1. `packages/core/src/host/validate.ts`を新規作成する。ランタイムスキーマライブラリは使用しない（バイナリサイズのため）。
2.
`packages/api/src/manifest.ts`の`Manifest`形状を検証対象とする。必須トップレベルフィールド（`id`、`version`、`apiVersion`、`activationEvents`、`contributes`）を検証する。
3.
`activationEvents`の文字列パターン（`onStartup`、`onCommand:<id>`、`onLanguage:<id>`）を検証する。`contributes`の各サブ要素（`commands`、`keybindings`、`views`、`languages`、`themes`、`configuration`）の必須フィールドと型も検証する。
4. 検証失敗時は、フィールドパスを注記した明確なエラーメッセージを生成する（例: `contributes.commands[0].id`）。
5. 検証失敗時は`HostError { extensionId?, path, message }`を記録する。その拡張をスキップし、起動を継続する（Req
2.4）。`host/errors.ts`の`HostLog`/`StatusSink`を使用する。
6. `validate.ts`または近接モジュールに、apiVersion互換性判定を追加する。ホストは`@tecode/api`の`API_VERSION
= "1.0"`を参照する。
7. 互換性ルールは「メジャーが同一、かつホストのマイナー ≥
要求マイナー」とする（設計§4.3）。manifestは`"1"`または`"1.x"`形式で宣言する。
8. 非互換の拡張は登録段階でスキップする。不一致を`HostError`として送出する。クラッシュしない（Req 2.7）。

Phase 3: Contribution登録

このフェーズは、検証済みmanifestのcontributesを各レジストリへ登録する。index.tsは実行しない。既存レジストリには直接登録し、未実装レジストリ向けには宣言を収集する。

Task 1: コマンドレジストリのlazyコマンド対応

コマンドレジストリがlazyコマンドを表現できるようにする。

• packages/core/src/commands/registry.tsを更新する。CommandEntryにextensionId?とlazyを追加し、handlerを任意にする（設計§5）。
• lazyエントリに対するexecuteは、現時点では未アクティベーションを示すHostErrorを送出する。実アクティベーションと再ディスパッチは1.12の担当である。
• 既存のregister/execute/listのlast-wins・never-throw・Disposableの各セマンティクスは維持する。

Task 2: contribution登録の実装

contributesを各対象へ登録する登録ルーチンを実装する。

• packages/core/src/host/に登録ルーチンを追加する。検証済みmanifestごとにcontributesを走査する。
• contributes.commandsは、コマンドレジストリへextensionId付きのlazyエントリとして登録する。
• contributes.keybindingsは、KeymapLayers.extension用に累積する。bindingTable.tsは増分APIを持たないため、全拡張分を収集後にcreateBindingTableへ完全な4層オブジェクトを渡す設計とする。
• contributes.configurationは、config schemaレジストリ（1.10の成果物）へ登録する。config schemaレジストリのスキーマ登録APIを呼び出す。
• contributes.views（slot）、contributes.languages、contributes.themesは、実レジストリが未実装である（1.14、2.8、2.6）。1.11では生の宣言をextensionId付きで型別に収集し、探索結果に保持する。後続タスクがこれを消費する。
• 登録はindex.tsを一切importしない（Req 2.2）。

Task 3: ホストエントリポイントの公開

探索・検証・登録を1つのオーケストレーション関数として公開する。

• packages/core/src/host/index.tsを更新する。HOST_PLACEHOLDERを削除し、discover()・検証・登録を統合するエントリを公開する。
• 依存（HostLog、StatusSink、コマンドレジストリ、config schemaレジストリ、fsシーム）は引数で注入する。既存のDIパターンに従う。
• packages/core/src/index.tsから新しいホストAPIを再エクスポートする。

🤖 Prompt for AI agents

このフェーズでは、検証済みmanifestの`contributes`を各レジストリへ登録する処理を実装する。目標は、`index.ts`を実行せずに、既存レジストリへ直接登録し、未実装レジストリ向けには宣言を収集することである。

1.
`packages/core/src/commands/registry.ts`を更新する。`CommandEntry`に`extensionId?`と`lazy`を追加する。`handler`を任意にする（設計§5）。
2.
lazyエントリに対する`execute`は、現時点では未アクティベーションを示す`HostError`を送出する。実アクティベーションと再ディスパッチは1.12の担当である。
3.
既存の`register`/`execute`/`list`のlast-wins・never-throw・`Disposable`の各セマンティクスを維持する。
4. `packages/core/src/host/`に登録ルーチンを追加する。検証済みmanifestごとに`contributes`を走査する。
5. `contributes.commands`は、コマンドレジストリへ`extensionId`付きのlazyエントリとして登録する。
6.
`contributes.keybindings`は、`KeymapLayers.extension`用に累積する。`bindingTable.ts`は増分APIを持たないため、全拡張分を収集後に`createBindingTable`へ完全な4層オブジェクトを渡す設計とする。
7. `contributes.configuration`は、config schemaレジストリ（1.10の成果物）へ登録する。config
schemaレジストリのスキーマ登録APIを呼び出す。
8.
`contributes.views`（slot）、`contributes.languages`、`contributes.themes`は、実レジストリが未実装である（1.14、2.8、2.6）。1.11では生の宣言をextensionId付きで型別に収集し、探索結果に保持する。後続タスクがこれを消費する。
9. 登録処理は`index.ts`を一切importしない（Req 2.2）。
10.
`packages/core/src/host/index.ts`を更新する。`HOST_PLACEHOLDER`を削除し、`discover()`・検証・登録を統合するエントリを公開する。
11. 依存（`HostLog`、`StatusSink`、コマンドレジストリ、config
schemaレジストリ、fsシーム）は引数で注入する。既存のDIパターンに従う。
12. `packages/core/src/index.ts`から新しいホストAPIを再エクスポートする。

Phase 4: テスト

このフェーズは、チケットの完了要件を満たすテストを追加する。既存のbun:test + mkdtemp + DIパターンを使用する。モックライブラリは使用しない。

Task 1: 検証と探索のテスト

無効manifestのスキップ、遮蔽順序、コード非実行を検証する。

• packages/core/src/host/にテストを追加する。documentManager.test.tsに従い、mkdtempで一時ディレクトリを作成し、実際のmanifest.tsフィクスチャを書き込む。
• 無効なmanifestフィクスチャがスキップされ、HostLogに有用なエラーが記録され、起動が継続することを検証する。createRecordingSinkパターンを使用する。
• 3か所に同一IDフィクスチャを配置し、遮蔽順序（workspace > user > builtin）とwarning記録を検証する。
• 登録中に拡張のindex.tsが実行されないことを証明する。フィクスチャのindex.tsに、実行されたら副作用（フラグ設定または例外送出）を起こすマーカーを置き、import()されないことを確認する手書きスパイを用いる。

Task 2: APIバージョンマトリクスのテスト

互換性判定の受理・拒否を検証する。

• APIバージョンの受理／拒否マトリクスを検証する。同一メジャー・同一マイナー（受理）、同一メジャー・古いマイナー（受理）、同一メジャー・新しいマイナー（拒否）、異なるメジャー（拒否）の各ケースを検証する。
• 非互換時にHostErrorが送出され、クラッシュしないことを検証する。

🤖 Prompt for AI agents

このフェーズでは、探索・検証・登録・APIバージョン互換性のテストを追加する。目標は、チケットの完了要件を満たすことである。既存の`bun:test` +
`mkdtemp` + DIパターンを使用する。モックライブラリは使用しない。

1.
`packages/core/src/host/`にテストを追加する。`documentManager.test.ts`に従い、`mkdtemp`で一時ディレクトリを作成する。実際の`manifest.ts`フィクスチャを書き込む。
2.
無効なmanifestフィクスチャがスキップされることを検証する。`HostLog`に有用なエラーが記録されることを検証する。起動が継続することを検証する。`createRecordingSink`パターンを使用する。
3. 3か所に同一IDフィクスチャを配置する。遮蔽順序（workspace > user > builtin）とwarning記録を検証する。
4.
登録中に拡張の`index.ts`が実行されないことを証明する。フィクスチャの`index.ts`に、実行されたら副作用（フラグ設定または例外送出）を起こすマーカーを置く。手書きスパイで`import()`されないことを確認する。
5. APIバージョンの受理／拒否マトリクスを検証する。以下のケースを検証する:
同一メジャー・同一マイナー（受理）、同一メジャー・古いマイナー（受理）、同一メジャー・新しいマイナー（拒否）、異なるメジャー（拒否）。
6. 非互換時に`HostError`が送出されることを検証する。クラッシュしないことを検証する。

Research

本プロジェクトはBunネイティブのESMモノレポである。

packages/apiはManifest型（id、version、apiVersion、activationEvents、contributes）とAPI_VERSION = "1.0"を定義する。

packages/coreは実装層である。以下を含む。

• コマンドレジストリ（commands/registry.ts、1.3で実装済み）
• キーマップのバインディングテーブル（keymap/bindingTable.ts、1.5で実装済み）
• 共有エラー基盤（host/errors.tsのHostError/HostLog/StatusSink）

host/index.tsとconfig/index.tsはプレースホルダである。

packages/builtinの7つの拡張機能は、すべてプレースホルダのindex.tsのみを持つ。manifest.tsは存在しない。

テストはbun:testを使用する。モックライブラリではなく、依存性注入とmkdtempによる実ファイルフィクスチャを用いる。

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

このフェーズでは、拡張機能ディレクトリを走査する探索基盤を実装する。目標は、fs注入シーム、パス解決、組み込みmanifestの静的集約点、3か所探索と重複ID遮蔽の完成である。

1.
`packages/core/src/host/`に新規モジュールを作成する。`documentManager.ts`の`DocumentManagerFs`パターンに従い、`readdir`・`stat`を含む狭い注入可能なfsインターフェースを定義する。既定値は`node:fs/promises`とする。
2.
3つの探索元パスを解決する関数を追加する。対象は組み込み、`~/.config/tecode/extensions`（`XDG_CONFIG_HOME`を尊重し、未設定時は`os.homedir()`を使用）、`<workspace>/.tecode/extensions`である。ワークスペースルートは呼び出し元からの引数で受け取る。
3. エラー描画には`documentManager.ts`の`describeError`/`errorCode`パターンを再利用する。
4. 設計§4.1「Built-ins are compiled into the binary as ordinary
imports」に従い、組み込みmanifestを静的配列として集約する集約点を用意する。`packages/builtin/*`は現状プレースホルダで`manifest.ts`を持たないため、組み込み探索元を空または既知のmanifestデータの静的配列として扱えるようにする。探索コードが3か所すべてを均一に処理できる構造にする。
5. `discover()`関数を追加する。探索順序は組み込み → ユーザ設定 → ワークスペースとする（Req 2.1）。
6.
各ディレクトリで`manifest.ts`または`manifest.js`を動的`import(pathToFileURL(file).href)`で読み込む。`index.ts`は読み込まない（Req
2.2）。
7. 重複IDは後の探索元を優先する（workspace > user > builtin）。遮蔽された拡張は`HostLog`にwarningとして記録する。
8. 探索結果として、有効なmanifestとそのソースパス・extensionIdを含む構造を返す。
===============================================================================

Task: 2

このフェーズでは、手書きManifestバリデータとAPIバージョン互換性チェックを実装する。目標は、ランタイムスキーマライブラリを使わずに検証を行い、無効なmanifestはスキップして起動を継続することである。

1. `packages/core/src/host/validate.ts`を新規作成する。ランタイムスキーマライブラリは使用しない（バイナリサイズのため）。
2.
`packages/api/src/manifest.ts`の`Manifest`形状を検証対象とする。必須トップレベルフィールド（`id`、`version`、`apiVersion`、`activationEvents`、`contributes`）を検証する。
3.
`activationEvents`の文字列パターン（`onStartup`、`onCommand:<id>`、`onLanguage:<id>`）を検証する。`contributes`の各サブ要素（`commands`、`keybindings`、`views`、`languages`、`themes`、`configuration`）の必須フィールドと型も検証する。
4. 検証失敗時は、フィールドパスを注記した明確なエラーメッセージを生成する（例: `contributes.commands[0].id`）。
5. 検証失敗時は`HostError { extensionId?, path, message }`を記録する。その拡張をスキップし、起動を継続する（Req
2.4）。`host/errors.ts`の`HostLog`/`StatusSink`を使用する。
6. `validate.ts`または近接モジュールに、apiVersion互換性判定を追加する。ホストは`@tecode/api`の`API_VERSION
= "1.0"`を参照する。
7. 互換性ルールは「メジャーが同一、かつホストのマイナー ≥
要求マイナー」とする（設計§4.3）。manifestは`"1"`または`"1.x"`形式で宣言する。
8. 非互換の拡張は登録段階でスキップする。不一致を`HostError`として送出する。クラッシュしない（Req 2.7）。
===============================================================================

Task: 3

このフェーズでは、検証済みmanifestの`contributes`を各レジストリへ登録する処理を実装する。目標は、`index.ts`を実行せずに、既存レジストリへ直接登録し、未実装レジストリ向けには宣言を収集することである。

1.
`packages/core/src/commands/registry.ts`を更新する。`CommandEntry`に`extensionId?`と`lazy`を追加する。`handler`を任意にする（設計§5）。
2.
lazyエントリに対する`execute`は、現時点では未アクティベーションを示す`HostError`を送出する。実アクティベーションと再ディスパッチは1.12の担当である。
3.
既存の`register`/`execute`/`list`のlast-wins・never-throw・`Disposable`の各セマンティクスを維持する。
4. `packages/core/src/host/`に登録ルーチンを追加する。検証済みmanifestごとに`contributes`を走査する。
5. `contributes.commands`は、コマンドレジストリへ`extensionId`付きのlazyエントリとして登録する。
6.
`contributes.keybindings`は、`KeymapLayers.extension`用に累積する。`bindingTable.ts`は増分APIを持たないため、全拡張分を収集後に`createBindingTable`へ完全な4層オブジェクトを渡す設計とする。
7. `contributes.configuration`は、config schemaレジストリ（1.10の成果物）へ登録する。config
schemaレジストリのスキーマ登録APIを呼び出す。
8.
`contributes.views`（slot）、`contributes.languages`、`contributes.themes`は、実レジストリが未実装である（1.14、2.8、2.6）。1.11では生の宣言をextensionId付きで型別に収集し、探索結果に保持する。後続タスクがこれを消費する。
9. 登録処理は`index.ts`を一切importしない（Req 2.2）。
10.
`packages/core/src/host/index.ts`を更新する。`HOST_PLACEHOLDER`を削除し、`discover()`・検証・登録を統合するエントリを公開する。
11. 依存（`HostLog`、`StatusSink`、コマンドレジストリ、config
schemaレジストリ、fsシーム）は引数で注入する。既存のDIパターンに従う。
12. `packages/core/src/index.ts`から新しいホストAPIを再エクスポートする。
===============================================================================

Task: 4

このフェーズでは、探索・検証・登録・APIバージョン互換性のテストを追加する。目標は、チケットの完了要件を満たすことである。既存の`bun:test` +
`mkdtemp` + DIパターンを使用する。モックライブラリは使用しない。

1.
`packages/core/src/host/`にテストを追加する。`documentManager.test.ts`に従い、`mkdtemp`で一時ディレクトリを作成する。実際の`manifest.ts`フィクスチャを書き込む。
2.
無効なmanifestフィクスチャがスキップされることを検証する。`HostLog`に有用なエラーが記録されることを検証する。起動が継続することを検証する。`createRecordingSink`パターンを使用する。
3. 3か所に同一IDフィクスチャを配置する。遮蔽順序（workspace > user > builtin）とwarning記録を検証する。
4.
登録中に拡張の`index.ts`が実行されないことを証明する。フィクスチャの`index.ts`に、実行されたら副作用（フラグ設定または例外送出）を起こすマーカーを置く。手書きスパイで`import()`されないことを確認する。
5. APIバージョンの受理／拒否マトリクスを検証する。以下のケースを検証する:
同一メジャー・同一マイナー（受理）、同一メジャー・古いマイナー（受理）、同一メジャー・新しいマイナー（拒否）、異なるメジャー（拒否）。
6. 非互換時に`HostError`が送出されることを検証する。クラッシュしないことを検証する。

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

---