1.12 Implement activation and the extension context

[goofmint]

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

Summary

Implement lazy extension activation, ExtensionContext, and clean deactivation.

Details

• Activation events (Req 2.5): onStartup (after first frame), onCommand:<id> (lazy command activates its extension, then re-dispatches), onLanguage:<id> (from DocumentManager open notifications). Lazy views likewise activate on first reveal.
• activate(ctx) receives ExtensionContext { api, extensionUri, subscriptions: Disposable[], storagePath }.
• Shutdown/deactivation: dispose subscriptions in reverse order, then call deactivate() if exported (Req 2.6).
• Failed activation (throw): extension marked failed and quarantined — its contributions stay registered, but invoking its commands reports the failure; no crash.

Completion requirements

• Fixture extensions verify each activation event fires exactly once at the right trigger
• Lazy command: first execute activates, then runs the real handler; second execute skips activation
• Dispose order is reverse of push order; deactivate() called on shutdown
• Throwing activate quarantines the extension and surfaces the error; other extensions unaffected
• bun test and lint pass

References

• requirements.md: Req 2.5, 2.6
• design.md: §4.2

Dependencies

Blocked by: 1.11 (#12).

[goofmint]

@coderabbitai make plan in Japanese

---

Generated by Claude Code

[coderabbitai]

Coding Plan

Summary

• ライフサイクル専用のアクティベーションランタイムをpackages/core/src/host/に新設し、ExtensionContext構築、try/catchアクティベーション、隔離、逆順破棄、deactivate()呼び出しを担わせる。
• Tecode APIと拡張レコードは注入依存として受け取り、1.11（ディスカバリ）と1.13（API組み立て）から責務を分離する。
• 3種のアクティベーションイベントは、コマンドレジストリの遅延ディスパッチ拡張、DocumentManagerの既存onLanguageActivationフック、CLIが呼ぶonStartup入口として配線する。
• テストはbun:testの既存規約（deps注入、createRecordingSink()、never-throw検証）を踏襲し、インライン・フィクスチャ拡張で全完了要件を検証する。

Design Choices

Design Choice 1: 遅延コマンドのアクティベーションをコマンドレジストリとどう連携させるか。

Options Considered:

1. コマンドレジストリを拡張し、extensionId付きの遅延エントリと注入可能なactivateExtensionフックを持たせる。execute()はハンドラー未解決時にフックを呼び、アクティベーション後に再検索して実行する。
2. アクティベーションランタイム側でexecuteをラップ（デコレート）し、レジストリ本体は変更しない。

Chosen Option: 1

Rationale: design.md §4.2/§5が「レジストリが各コマンドを所有拡張へマップする」と記述しており、既存のDisposable返却規約と一貫するため。

Design Choice 2: 拡張レコードの供給元とctx.api（Tecode）の供給元。

Options Considered:

1. アクティベーションランタイムは、1.11が生成する拡張レコード（id、manifest、extensionUri、storagePath、モジュールローダー）を消費し、Tecode APIは注入された依存として受け取る。
2. アクティベーションランタイム自身が拡張ディスカバリとAPI構築を行う。

Chosen Option: 1

Rationale: ライフサイクルの責務を1.11/1.13から分離し、依存グラフと既存のDI規約に沿うため。

💡 User Tips

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

Implementation Steps

Phase 1: アクティベーションランタイムのコア

このフェーズは、拡張のライフサイクル状態とExtensionContextの構築、アクティベーションのtry/catch、隔離、および逆順デアクティベーションを担うコアモジュールを作る。まだアクティベーションイベントの配線は行わず、単一拡張のアクティベート/デアクティベートの契約を確立する。

Task 1: 拡張レコードとモジュール型、状態モデルの定義

アクティベーションランタイムが消費するデータ形状と拡張の状態を定義する。

• packages/core/src/host/に新規モジュール（例: activation.ts）を追加する。
• 拡張レコード型を定義する。フィールドはid、manifest、extensionUri、storagePath、およびモジュールを遅延取得するloadModule()（index.tsを動的importする関数）である。1.11がこの形状を生成する前提とし、1.11が未提供の場合は本モジュールで型を定義する。
• 拡張モジュール型を定義する。形状は{ activate?(ctx: ExtensionContext): void | Promise<void>; deactivate?(): void | Promise<void> }である。この型はcore内に置き、@tecode/apiは変更しない。
• 拡張状態を"registered" | "active" | "failed"の3値で持つ内部レコードを定義する。既定は"registered"である。

Task 2: アクティベーションコアと隔離の実装

1拡張のアクティベート処理、ExtensionContext構築、失敗時の隔離を実装する。

• createExtensionHost(deps)（または同等のファクトリ）をactivation.tsに実装する。depsは拡張レコード配列、api: Tecode（1.13が構築、テストではスタブ注入）、commandRegistry、log: HostLog、sink: StatusSinkを含む。
• activateExtension(id)を実装する。状態が"registered"のときのみ処理し、"active"/"failed"のときは何もしない（各イベントがちょうど1回だけアクティベートする保証）。
• アクティベート時にExtensionContextを構築する。apiは注入値、extensionUriとstoragePathはレコード値、subscriptionsは空のDisposable[]である。
• loadModule()で拡張モジュールを取得し、activate(ctx)をtry/catchで呼ぶ。成功時は状態を"active"にし、ctx（subscriptionsとモジュール参照を含む）を保持する。
• activateが例外を投げた場合は状態を"failed"にする。HostError（extensionIdとメッセージを含む）をlog.append("error", ...)で記録し、sink.error(...)で通知する。contributionは登録されたまま残す。他拡張の処理は継続する（クラッシュしない）。
• logまたはsink自体が例外を投げてもactivateExtensionが例外を伝播しない、never-throw契約を守る（registry.tsのlogSafely/notifySafelyの防御パターンを踏襲）。

Task 3: デアクティベーションと逆順破棄の実装

シャットダウン時のsubscriptions逆順破棄とdeactivate()呼び出しを実装する。

• deactivateExtension(id)および全拡張向けのdisposeAll()（シャットダウン用）を実装する。
• "active"な拡張について、ctx.subscriptionsをプッシュ順の逆順でdispose()する。個々のdispose()が例外を投げても続行し、logへ記録する。
• モジュールがdeactivateをエクスポートしていれば、subscriptions破棄後にtry/catchで呼ぶ。例外は記録し、伝播させない。
• デアクティベーション後は状態を戻し、二重破棄を防ぐガードを入れる（既存のdispose冪等パターンを踏襲）。

🤖 Prompt for AI agents

このフェーズでは、拡張のライフサイクル管理を担うコアランタイムモジュールを`packages/core/src/host/`に実装する。目標は、単一拡張のアクティベート/デアクティベートの契約を確立することである。イベント配線はこのフェーズでは行わない。

- `packages/core/src/host/activation.ts`を新規作成する。
-
拡張レコード型を定義する。フィールドは`id`、`manifest`、`extensionUri`、`storagePath`、および`index.ts`を動的importする`loadModule()`である。1.11がこの形状を生成する前提とし、未提供の場合はこのモジュールで型を定義する。
- 拡張モジュール型を定義する。形状は`{ activate?(ctx: ExtensionContext): void | Promise<void>;
deactivate?(): void | Promise<void> }`とし、core内に置く。`@tecode/api`は変更しない。
- 拡張状態を`"registered"` | `"active"` |
`"failed"`の3値で管理する内部レコードを定義する。既定値は`"registered"`とする。
- `createExtensionHost(deps)`を実装する。`deps`は拡張レコード配列、`api:
Tecode`、`commandRegistry`、`log: HostLog`、`sink: StatusSink`を含む。
-
`activateExtension(id)`を実装する。状態が`"registered"`のときのみ処理を行い、`"active"`または`"failed"`のときは何もしない。各イベントがちょうど1回だけアクティベートすることを保証する。
-
アクティベート時に`ExtensionContext`を構築する。`api`は注入値を使い、`extensionUri`と`storagePath`はレコード値を使い、`subscriptions`は空の`Disposable[]`とする。
-
`loadModule()`で拡張モジュールを取得し、`activate(ctx)`をtry/catchで呼ぶ。成功時は状態を`"active"`にし、`subscriptions`とモジュール参照を含む`ctx`を保持する。
-
`activate`が例外を投げたら状態を`"failed"`にする。`extensionId`とメッセージを含む`HostError`を`log.append("error",
...)`で記録し、`sink.error(...)`で通知する。contributionは登録されたまま残す。他拡張の処理は継続させ、ホストをクラッシュさせない。
-
`log`または`sink`自体が例外を投げても`activateExtension`から例外を伝播させない、never-throw契約を守る。`registry.ts`の`logSafely`/`notifySafely`の防御パターンを踏襲する。
- `deactivateExtension(id)`と、全拡張を対象とするシャットダウン用`disposeAll()`を実装する。
-
`"active"`な拡張について、`ctx.subscriptions`をプッシュ順の逆順で`dispose()`する。個々の`dispose()`が例外を投げても処理を続行し、`log`へ記録する。
- モジュールが`deactivate`をエクスポートしていれば、`subscriptions`破棄後にtry/catchで呼ぶ。例外は記録し、伝播させない。
- デアクティベーション後は状態を戻し、二重破棄を防ぐガードを入れる。既存の`dispose`冪等パターンを踏襲する。

Phase 2: アクティベーションイベントの配線

このフェーズは、3種のアクティベーションイベント（onStartup、onCommand:<id>、onLanguage:<id>）をコアランタイムへ接続する。各拡張のmanifest.activationEventsを読み、対応するトリガーでactivateExtension(id)を呼ぶ。

Task 1: onStartupトリガーの実装

最初のフレーム後に発火するonStartupの入口を提供する。

• activation.tsにactivateStartupExtensions()を実装する。activationEventsに"onStartup"を含む全拡張をactivateExtensionする。
• 本メソッドはレンダーループを所有しない。CLI（タスク1.15）が最初のフレーム後の遅延フェーズで呼ぶ前提とする。設計上の「first frame後」の順序保証は呼び出し側に委ねる。

Task 2: onCommandによる遅延コマンド再ディスパッチ

コマンド実行時に所有拡張をアクティベートし、実ハンドラーを実行する。

• packages/core/src/commands/registry.tsを更新する。CommandEntryに任意のextensionIdとlazyフラグを追加する。1.11がこれら遅延エントリを登録する前提とする。
• createCommandRegistryのdepsに任意のactivateExtension(extensionId): Promise<void>フックを追加する。
• execute(id, ...args)を更新する。ハンドラーが未解決（エントリなし、またはlazyでハンドラー未設定）かつextensionIdが既知の場合、activateExtension(extensionId)をawaitし、その後commands.get(id)を再検索して実行する。
• アクティベーション後もハンドラーが解決しない、または対象拡張が"failed"の場合は、既存の「見つからない」経路と同様にHostErrorをログ/シンクへ出す。never-throw契約を維持する。
• アクティベーションランタイム側でcreateExtensionHostがactivateExtensionをレジストリのdepsへ提供するよう配線する。

Task 3: onLanguageトリガーの配線

ドキュメントを開いたときにonLanguage:<id>をトリガーする。

• activation.tsにonLanguage(languageId)ハンドラーを実装する。activationEventsに`onLanguage:${languageId}`を含む拡張をactivateExtensionする。
• このハンドラーをDocumentManagerのonLanguageActivationコールバックとして供給する（既存のフックを再利用、documentManager.tsは変更不要）。実際の結線は組み立て段階（1.15）で行う。テストでは本ハンドラーを直接呼んで検証する。
• design.md §4.2の遅延ビューは、スロットレジストリ（タスク1.14）が未実装のため、汎用のactivateExtension(id)を再利用する差し込み口として残す。本タスクではビュー固有の配線を追加しない。

🤖 Prompt for AI agents

このフェーズでは、3種のアクティベーションイベント（`onStartup`、`onCommand:<id>`、`onLanguage:<id>`）をPhase
1のコアランタイムへ接続する。各拡張の`manifest.activationEvents`を読み取り、対応するトリガーで`activateExtension(id)`を呼び出す。

-
`activation.ts`に`activateStartupExtensions()`を実装する。`activationEvents`に`"onStartup"`を含む全拡張を`activateExtension`する。このメソッドはレンダーループを所有しない。CLI（タスク1.15）が最初のフレーム後の遅延フェーズで呼び出す前提とする。「first
frame後」の順序保証は呼び出し側に委ねる。
-
`packages/core/src/commands/registry.ts`を更新する。`CommandEntry`に任意の`extensionId`と`lazy`フラグを追加する。1.11がこれらの遅延エントリを登録する前提とする。
- `createCommandRegistry`の`deps`に任意の`activateExtension(extensionId):
Promise<void>`フックを追加する。
- `execute(id,
...args)`を更新する。ハンドラーが未解決（エントリなし、または`lazy`でハンドラー未設定）かつ`extensionId`が既知の場合、`activateExtension(extensionId)`を`await`してから`commands.get(id)`を再検索して実行する。
-
アクティベーション後もハンドラーが解決しない場合、または対象拡張が`"failed"`の場合は、既存の「見つからない」経路と同様に`HostError`をログ/シンクへ出す。never-throw契約を維持する。
- `createExtensionHost`が`activateExtension`をコマンドレジストリの`deps`へ提供するよう配線する。
- `activation.ts`に`onLanguage(languageId)`ハンドラーを実装する。`activationEvents`に``
`onLanguage:${languageId}` ``を含む拡張を`activateExtension`する。
-
このハンドラーを`DocumentManager`の既存`onLanguageActivation`コールバックとして供給できるようにする。`documentManager.ts`自体は変更しない。実際の結線は組み立て段階（1.15）で行い、本タスクではハンドラーを直接呼び出して検証できる形にする。
- design.md
§4.2の遅延ビューについては、スロットレジストリ（タスク1.14）が未実装のため、汎用の`activateExtension(id)`を再利用する差し込み口として残すのみとし、ビュー固有の配線は追加しない。

Phase 3: フィクスチャ拡張、テスト、エクスポート

このフェーズは、各アクティベーションイベントを検証するフィクスチャ拡張とテストを追加し、公開バレルを更新する。

Task 1: フィクスチャ拡張の作成

各アクティベーションイベントと隔離を検証するための最小フィクスチャを用意する。

• ハウス規約に従い、フィクスチャは実ファイルではなくテスト内のインライン・オブジェクト（{ manifest, loadModule }と、activate/deactivateを持つモジュール）として構築する。documentManager.test.ts/service.test.tsのフェイク注入方式に合わせる。
• フィクスチャは各イベント種別（onStartup、onCommand:<id>、onLanguage:<id>）と、activateが例外を投げるケースを網羅する。activate呼び出し回数をカウントするクロージャ配列を用いる。

Task 2: アクティベーションテストの実装

完了要件を満たすテストを1ファイルに集約する。

• packages/core/src/host/activation.test.tsを新規作成する。単一ファイル内でdescribeブロックをイベント種別ごとに分ける規約に従う。
• 各アクティベーションイベントが正しいトリガーでちょうど1回発火することを検証する。
• 遅延コマンド: 1回目のexecuteでアクティベートして実ハンドラーを実行し、2回目のexecuteはアクティベーションをスキップすることを検証する（registry.test.tsも更新）。
• subscriptionsの破棄順がプッシュ順の逆であること、シャットダウン時にdeactivate()が呼ばれることを検証する。
• activateが例外を投げると当該拡張が隔離（"failed"）され、log/sinkへエラーが表面化し、他拡張が影響を受けないことを検証する。createRecordingSink()ヘルパーとcreateHostLog()を再利用する。
• log/sink自体が投げてもactivateExtensionが投げないハードニングを検証する。

Task 3: バレルエクスポートの更新

新モジュールを公開面へ露出する。

• packages/core/src/host/index.tsを更新し、HOST_PLACEHOLDERを新しいアクティベーションランタイムのファクトリと関連型に置き換える（または追加する）。
• packages/core/src/index.tsの再エクスポートを更新する。bun testとlintが通ることを確認する。

🤖 Prompt for AI agents

このフェーズでは、各アクティベーションイベントと隔離を検証するフィクスチャ拡張とテストを追加し、公開バレルを更新する。

- フィクスチャは実ファイルではなくテスト内のインライン・オブジェクト（`{ manifest, loadModule
}`と、`activate`/`deactivate`を持つモジュール）として構築する。ハウス規約に従い、`documentManager.test.ts`/`service.test.ts`のフェイク注入方式に合わせる。
-
フィクスチャは各イベント種別（`onStartup`、`onCommand:<id>`、`onLanguage:<id>`）と、`activate`が例外を投げるケースを網羅する。`activate`呼び出し回数をカウントするクロージャ配列を用いる。
-
`packages/core/src/host/activation.test.ts`を新規作成する。単一ファイル内で`describe`ブロックをイベント種別ごとに分ける規約に従う。
- 各アクティベーションイベントが正しいトリガーでちょうど1回発火することを検証する。
-
遅延コマンドについて、1回目の`execute`でアクティベートして実ハンドラーを実行し、2回目の`execute`ではアクティベーションをスキップすることを検証する。`registry.test.ts`もこれに合わせて更新する。
- `subscriptions`の破棄順がプッシュ順の逆であること、シャットダウン時に`deactivate()`が呼ばれることを検証する。
-
`activate`が例外を投げたとき、当該拡張が隔離（`"failed"`）され、`log`/`sink`へエラーが表面化し、他拡張が影響を受けないことを検証する。`createRecordingSink()`ヘルパーと`createHostLog()`を再利用する。
- `log`または`sink`自体が例外を投げても`activateExtension`が例外を投げないハードニングを検証する。
-
`packages/core/src/host/index.ts`を更新し、`HOST_PLACEHOLDER`を新しいアクティベーションランタイムのファクトリと関連型に置き換えるか、追加する。
- `packages/core/src/index.ts`の再エクスポートを更新する。
- `bun test`とlintが通ることを確認する。

Research

本リポジトリはBunワークスペースのモノレポである。@tecode/apiは型のみを提供し、Disposable、ActivationEvent（onStartup | onCommand:${string} | onLanguage:${string}）、Manifest、ExtensionContext { api, extensionUri, subscriptions, storagePath }、およびTecodeネームスペース群を定義済みである。

packages/core側は各サブシステムを実装するが、拡張ホスト（host/index.ts）とAPIビルダー（api/index.ts）はプレースホルダーである。

host/errors.tsは共有のHostError / HostLog / StatusSinkを提供する。

コマンドレジストリ（commands/registry.ts）は事前登録のみで、遅延アクティベーションの差し込み口をexecute()に残している。

DocumentManagerはonLanguageActivation(languageId)コールバックのフックを既に備え、onLanguage:*用の連携点としてタスク1.12に予約されている。

テストはbun:testのみを使い、モックライブラリを使わず、depsオブジェクト経由の手書きフェイクを注入する規約である。

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

このフェーズでは、拡張のライフサイクル管理を担うコアランタイムモジュールを`packages/core/src/host/`に実装する。目標は、単一拡張のアクティベート/デアクティベートの契約を確立することである。イベント配線はこのフェーズでは行わない。

- `packages/core/src/host/activation.ts`を新規作成する。
-
拡張レコード型を定義する。フィールドは`id`、`manifest`、`extensionUri`、`storagePath`、および`index.ts`を動的importする`loadModule()`である。1.11がこの形状を生成する前提とし、未提供の場合はこのモジュールで型を定義する。
- 拡張モジュール型を定義する。形状は`{ activate?(ctx: ExtensionContext): void | Promise<void>;
deactivate?(): void | Promise<void> }`とし、core内に置く。`@tecode/api`は変更しない。
- 拡張状態を`"registered"` | `"active"` |
`"failed"`の3値で管理する内部レコードを定義する。既定値は`"registered"`とする。
- `createExtensionHost(deps)`を実装する。`deps`は拡張レコード配列、`api:
Tecode`、`commandRegistry`、`log: HostLog`、`sink: StatusSink`を含む。
-
`activateExtension(id)`を実装する。状態が`"registered"`のときのみ処理を行い、`"active"`または`"failed"`のときは何もしない。各イベントがちょうど1回だけアクティベートすることを保証する。
-
アクティベート時に`ExtensionContext`を構築する。`api`は注入値を使い、`extensionUri`と`storagePath`はレコード値を使い、`subscriptions`は空の`Disposable[]`とする。
-
`loadModule()`で拡張モジュールを取得し、`activate(ctx)`をtry/catchで呼ぶ。成功時は状態を`"active"`にし、`subscriptions`とモジュール参照を含む`ctx`を保持する。
-
`activate`が例外を投げたら状態を`"failed"`にする。`extensionId`とメッセージを含む`HostError`を`log.append("error",
...)`で記録し、`sink.error(...)`で通知する。contributionは登録されたまま残す。他拡張の処理は継続させ、ホストをクラッシュさせない。
-
`log`または`sink`自体が例外を投げても`activateExtension`から例外を伝播させない、never-throw契約を守る。`registry.ts`の`logSafely`/`notifySafely`の防御パターンを踏襲する。
- `deactivateExtension(id)`と、全拡張を対象とするシャットダウン用`disposeAll()`を実装する。
-
`"active"`な拡張について、`ctx.subscriptions`をプッシュ順の逆順で`dispose()`する。個々の`dispose()`が例外を投げても処理を続行し、`log`へ記録する。
- モジュールが`deactivate`をエクスポートしていれば、`subscriptions`破棄後にtry/catchで呼ぶ。例外は記録し、伝播させない。
- デアクティベーション後は状態を戻し、二重破棄を防ぐガードを入れる。既存の`dispose`冪等パターンを踏襲する。
===============================================================================

Task: 2

このフェーズでは、3種のアクティベーションイベント（`onStartup`、`onCommand:<id>`、`onLanguage:<id>`）をPhase
1のコアランタイムへ接続する。各拡張の`manifest.activationEvents`を読み取り、対応するトリガーで`activateExtension(id)`を呼び出す。

-
`activation.ts`に`activateStartupExtensions()`を実装する。`activationEvents`に`"onStartup"`を含む全拡張を`activateExtension`する。このメソッドはレンダーループを所有しない。CLI（タスク1.15）が最初のフレーム後の遅延フェーズで呼び出す前提とする。「first
frame後」の順序保証は呼び出し側に委ねる。
-
`packages/core/src/commands/registry.ts`を更新する。`CommandEntry`に任意の`extensionId`と`lazy`フラグを追加する。1.11がこれらの遅延エントリを登録する前提とする。
- `createCommandRegistry`の`deps`に任意の`activateExtension(extensionId):
Promise<void>`フックを追加する。
- `execute(id,
...args)`を更新する。ハンドラーが未解決（エントリなし、または`lazy`でハンドラー未設定）かつ`extensionId`が既知の場合、`activateExtension(extensionId)`を`await`してから`commands.get(id)`を再検索して実行する。
-
アクティベーション後もハンドラーが解決しない場合、または対象拡張が`"failed"`の場合は、既存の「見つからない」経路と同様に`HostError`をログ/シンクへ出す。never-throw契約を維持する。
- `createExtensionHost`が`activateExtension`をコマンドレジストリの`deps`へ提供するよう配線する。
- `activation.ts`に`onLanguage(languageId)`ハンドラーを実装する。`activationEvents`に``
`onLanguage:${languageId}` ``を含む拡張を`activateExtension`する。
-
このハンドラーを`DocumentManager`の既存`onLanguageActivation`コールバックとして供給できるようにする。`documentManager.ts`自体は変更しない。実際の結線は組み立て段階（1.15）で行い、本タスクではハンドラーを直接呼び出して検証できる形にする。
- design.md
§4.2の遅延ビューについては、スロットレジストリ（タスク1.14）が未実装のため、汎用の`activateExtension(id)`を再利用する差し込み口として残すのみとし、ビュー固有の配線は追加しない。
===============================================================================

Task: 3

このフェーズでは、各アクティベーションイベントと隔離を検証するフィクスチャ拡張とテストを追加し、公開バレルを更新する。

- フィクスチャは実ファイルではなくテスト内のインライン・オブジェクト（`{ manifest, loadModule
}`と、`activate`/`deactivate`を持つモジュール）として構築する。ハウス規約に従い、`documentManager.test.ts`/`service.test.ts`のフェイク注入方式に合わせる。
-
フィクスチャは各イベント種別（`onStartup`、`onCommand:<id>`、`onLanguage:<id>`）と、`activate`が例外を投げるケースを網羅する。`activate`呼び出し回数をカウントするクロージャ配列を用いる。
-
`packages/core/src/host/activation.test.ts`を新規作成する。単一ファイル内で`describe`ブロックをイベント種別ごとに分ける規約に従う。
- 各アクティベーションイベントが正しいトリガーでちょうど1回発火することを検証する。
-
遅延コマンドについて、1回目の`execute`でアクティベートして実ハンドラーを実行し、2回目の`execute`ではアクティベーションをスキップすることを検証する。`registry.test.ts`もこれに合わせて更新する。
- `subscriptions`の破棄順がプッシュ順の逆であること、シャットダウン時に`deactivate()`が呼ばれることを検証する。
-
`activate`が例外を投げたとき、当該拡張が隔離（`"failed"`）され、`log`/`sink`へエラーが表面化し、他拡張が影響を受けないことを検証する。`createRecordingSink()`ヘルパーと`createHostLog()`を再利用する。
- `log`または`sink`自体が例外を投げても`activateExtension`が例外を投げないハードニングを検証する。
-
`packages/core/src/host/index.ts`を更新し、`HOST_PLACEHOLDER`を新しいアクティベーションランタイムのファクトリと関連型に置き換えるか、追加する。
- `packages/core/src/index.ts`の再エクスポートを更新する。
- `bun test`とlintが通ることを確認する。

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

---