1.13 Assemble the tecode API object

[goofmint]

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

Summary

Build the concrete tecode namespace object handed to every extension, and the contract-test suite that gates API versioning.

Details

• core/api/create.ts wires every namespace from Req 10.1 to the services from Tasks 1.3–1.12 (commands, workspace incl. fs wrapper over node:fs/promises + fs.watch, window stubs where UI lands later, editor, ui, config, context, languages, themes).
• Shallow Object.freeze per namespace to prevent cross-extension monkey-patching.
• Register a Bun module alias so import { commands } from "tecode" resolves to this object in dev and compiled mode.
• tecode.editor calls with no active editor no-op with a status-sink notice.
• Contract tests: a fixture extension activated against the real core exercises every namespace — register/dispose symmetry, event firing order, frozenness. This suite is the compatibility gate for future API_VERSION bumps.

Completion requirements

• Every namespace in Req 10.1 is reachable from a fixture extension via both ctx.api and import ... from "tecode"
• Namespaces are frozen (mutation attempts throw in tests)
• No-active-editor editor calls no-op with a surfaced notice
• Contract suite passes and is wired into CI as a named job/step
• bun test and lint pass

References

• requirements.md: Req 10.1, 10.2
• design.md: §12, §16

Dependencies

Blocked by: 1.12 (#13) and all of 1.3–1.10.

[goofmint]

@coderabbitai make plan in Japanese

---

Generated by Claude Code

[coderabbitai]

Coding Plan

Summary

• core/api/create.ts を新設し、既存サービス（commands／config／workspace／context）と型準拠スタブ（window／editor／ui／languages／themes）を Tecode 型に配線する。名前空間ごとに浅く凍結する。
• node:fs/promises と fs.watch 上に FileSystem ラッパを実装し、tecode.workspace.fs を提供する。サンドボックスは課さない。
• Bun.plugin の builder.module で素の "tecode" 指定子を組み立て済みオブジェクトへ解決する。開発実行と compiled モードの両方で import ... from "tecode" を有効にする。
• フィクスチャ拡張機能とコントラクトテストで register/dispose 対称性・イベント順序・凍結性を検証する。bun test と eslint . を名前付きジョブとして新規 CI に接続する。

Design Choices

Design Choice 1: `tecode` モジュールエイリアスの指定子形式

Options Considered:

1. Bun.plugin の builder.module("tecode", ...) で素の指定子を完全一致登録し、loader: "object" で凍結済みオブジェクトを返す。
2. "tecode:api" などコロン付き指定子にして onResolve／onLoad で解決する。

Chosen Option: 1

Rationale: チケットが素の import { commands } from "tecode" を明示要求するため、完全一致の builder.module で素の指定子を登録する。コロン付き指定子は要件を満たさない。なお、Bun のプラグインフィルタは . または : を含む指定子を対象とする仕様がある。

Design Choice 2: `tecode.window`／`tecode.editor`／`tecode.ui`／`tecode.languages`／`tecode.themes` の実装レベル

Options Considered:

1. 型を満たす no-op スタブ名前空間として組み立て、後続タスクで差し替える。
2. 本タスクで実サービスまで実装する。

Chosen Option: 1

Rationale: design.md §12 と tasks.md の分割方針に従い、本タスクでは凍結済みの型準拠スタブを配線する。実装は後続タスク（Phase 2／Phase 3 の別タスク：2.1、2.6、2.9、3.1）の責務である。

Design Choice 3: 「アクティブエディタなし」通知の経路

Options Considered:

1. 既存の StatusSink.error を再利用して HostError を通知する。
2. StatusSink に情報レベルのメソッドを追加する。

Chosen Option: 1

Rationale: host/errors.ts の StatusSink は error(err: HostError) のみを持つ。commands/registry.ts が既に StatusSink.error でエラー系を通知する確立済みパターンに合わせ、新規メソッドは追加しない。

💡 User Tips

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

Implementation Steps

Phase 1: FileSystem ラッパと tecode オブジェクトの組み立て

このフェーズは core/api/create.ts を新設する。既存サービスと新規スタブを Tecode 型に配線する。名前空間ごとに浅い Object.freeze を適用する。依存タスク 1.3〜1.12 が完了している前提で作業する。

Task 1: `node:fs/promises` 上の `FileSystem` ラッパを実装する

tecode.workspace.fs の実体を提供する。

• packages/core/src/buffer/ 配下に FileSystem 実装（例: fileSystem.ts）を新設する。
• @tecode/api の FileSystem インターフェイス（read／write／stat／readdir／watch）を満たす。
• read／write／stat／readdir は node:fs/promises に委譲する。stat は FileStat（type／size／mtime／ctime）へ、readdir は DirEntry[]（name／type）へ変換する。
• watch は node:fs の fs.watch に委譲し、FileChangeEvent（created／changed／deleted）へ写像し、監視を停止する Disposable を返す。
• サンドボックスは課さない（Req 10.2）。

Task 2: 未実装名前空間の型準拠スタブを用意する

window／editor／ui／languages／themes を凍結可能な no-op として提供する。

• packages/core/src/api/ 配下にスタブ生成関数を新設する。
• 各スタブは対応する名前空間インターフェイスを型どおりに満たす。
• EditorNamespace の revealLine／insertSnippet／applyEdits は、アクティブエディタが存在しないため常に no-op とする。呼び出し時に StatusSink.error で「No active editor」の HostError を通知する。
• EditorNamespace.selections は空配列、cursor は原点位置を返す。
• LanguagesNamespace.register／ThemesNamespace.register／UiNamespace.registerView は、house style（Set<Listener<T>> + ガード付き dispose）に従い、有効な Disposable を返すレジストリスタブとする。register／dispose の対称性をテストで検証できる形にする。

Task 3: `create.ts` で `tecode` オブジェクトを組み立てる

9 名前空間を配線し、名前空間ごとに浅く凍結する。

• packages/core/src/api/create.ts を新設する。packages/core/src/api/index.ts のプレースホルダを置き換え、create.ts を re-export する。
• 依存サービスを引数で受け取る合成ルート関数（例: createTecodeApi(deps)）を定義する。deps には CommandRegistry、DocumentManager、ConfigService、ContextService、FileSystem、StatusSink を含める。
• commands は CommandRegistry の register／execute／list のみを射影する（registerLazy は公開しない）。
• workspace は DocumentManager の openDocument／documents／onDidOpen／onDidClose／onDidSave に委譲し、fs（Task 1.1）と rootUri を組み込む。
• config は ConfigService の get／onDidChange のみを射影する。
• context は ContextService の set／get のみを射影する（onDidChange は公開しない）。
• window／editor／ui／languages／themes は Task 1.2 のスタブを配線する。
• 組み立て後、各名前空間オブジェクトに Object.freeze を適用する（浅い凍結）。集約 Tecode オブジェクト自体も凍結する。
• 既存 Event<T> は各サービスのプロパティへ直接委譲する。新規エミッタユーティリティは作成しない。

🤖 Prompt for AI agents

このフェーズでは `core/api/create.ts` を新設し、`Tecode` 型に沿った 9 名前空間の実オブジェクトを組み立てる。

1. `packages/core/src/buffer/` 配下に `FileSystem` 実装（例:
`fileSystem.ts`）を新設する。`@tecode/api` の `FileSystem`
インターフェイス（`read`／`write`／`stat`／`readdir`／`watch`）を満たすこと。`read`／`write`／`stat`／`readdir`
は `node:fs/promises` に委譲する。`stat` の戻り値は
`FileStat`（`type`／`size`／`mtime`／`ctime`）へ変換する。`readdir` の戻り値は
`DirEntry[]`（`name`／`type`）へ変換する。`watch` は `node:fs` の `fs.watch`
に委譲し、`FileChangeEvent`（`created`／`changed`／`deleted`）へ写像し、監視を停止する `Disposable`
を返す。サンドボックスは課さない。

2. `packages/core/src/api/` 配下に、`window`／`editor`／`ui`／`languages`／`themes`
のスタブ生成関数を新設する。各スタブは対応する名前空間インターフェイスを型どおりに満たす。`EditorNamespace` の
`revealLine`／`insertSnippet`／`applyEdits` は常に no-op とし、呼び出し時に `StatusSink.error`
で「No active editor」の `HostError` を通知する。`EditorNamespace.selections`
は空配列、`cursor`
は原点位置を返す。`LanguagesNamespace.register`／`ThemesNamespace.register`／`UiNamespace.registerView`
は `Set<Listener<T>>` + ガード付き `dispose` の house style に従うレジストリスタブとし、有効な
`Disposable` を返す。`register`／`dispose` の対称性がテスト可能な構造にする。

3. `packages/core/src/api/create.ts` を新設する。既存のプレースホルダ
`packages/core/src/api/index.ts` を置き換え、`create.ts` を re-export
する形にする。依存サービスを引数で受け取る合成ルート関数（例: `createTecodeApi(deps)`）を定義する。`deps` には
`CommandRegistry`、`DocumentManager`、`ConfigService`、`ContextService`、`FileSystem`、`StatusSink`
を含める。

4. 名前空間ごとの配線ルール:
- `commands`: `CommandRegistry` の `register`／`execute`／`list`
のみを射影する。`registerLazy` は公開しない。
- `workspace`: `DocumentManager` の
`openDocument`／`documents`／`onDidOpen`／`onDidClose`／`onDidSave` に委譲し、Task 1.1 の
`fs` と `rootUri` を組み込む。
 - `config`: `ConfigService` の `get`／`onDidChange` のみを射影する。
 - `context`: `ContextService` の `set`／`get` のみを射影する。`onDidChange` は公開しない。
 - `window`／`editor`／`ui`／`languages`／`themes`: Task 1.2 のスタブを配線する。

5. 組み立て後、各名前空間オブジェクトに `Object.freeze` を適用する（浅い凍結）。集約 `Tecode` オブジェクト自体も凍結する。既存の
`Event<T>` は各サービスのプロパティへ直接委譲し、新規エミッタユーティリティは作成しない。

Phase 2: tecode モジュールエイリアスの登録

このフェーズは Bun の仮想モジュール機構で素の "tecode" 指定子を解決する。開発実行（bun run）と bun build --compile の両方を対象とする。

Task 1: `Bun.plugin` による仮想モジュールプラグインを実装する

組み立て済みの凍結オブジェクトを "tecode" として公開する。

• packages/core/src/api/ 配下にエイリアス登録関数（例: registerTecodeAlias(api)）を新設する。
• Bun.plugin の builder.module("tecode", () => ({ exports: api, loader: "object" })) で登録する。
• エイリアスは組み立て済み tecode オブジェクトを指すため、createTecodeApi の後に登録する。
• 登録関数は冪等とし、二重登録を避けるガードを持つ。

Task 2: 開発実行と合成ルートへエイリアス登録を組み込む

import { commands } from "tecode" を評価前に解決可能にする。

• packages/cli/src/main.ts の起動シーケンス（本タスクの合成ルート）で、拡張機能をロードする前に createTecodeApi を呼び、続けて registerTecodeAlias を呼ぶ。ESLint 境界により @tecode/core を import できるのは packages/cli のみである点に従う。
• プラグインはインポート対象モジュールの評価前に登録する。bun build --compile では、ビルドエントリからプラグインを登録して実行ファイルへ埋め込む方針とする（bunfig.toml の preload には依存しない）。
• 本タスクでは実行ファイルのビルドスクリプトは未整備でよい。開発実行での解決を優先し、compiled モードの登録経路（ビルドエントリからの registerTecodeAlias 呼び出し）を明記する。

🤖 Prompt for AI agents

このフェーズでは Bun の仮想モジュール機構を用いて、素の `"tecode"` 指定子を組み立て済みオブジェクトへ解決する。

1. `packages/core/src/api/` 配下にエイリアス登録関数（例:
`registerTecodeAlias(api)`）を新設する。`Bun.plugin` の `builder.module("tecode", () =>
({ exports: api, loader: "object" }))` を使って `"tecode"` を完全一致で登録する。この登録は Phase 1
の `createTecodeApi` の後に行う。登録関数は冪等にし、二重登録を避けるガードを設ける。

2. `packages/cli/src/main.ts` の起動シーケンスに、拡張機能をロードする前に `createTecodeApi` を呼び出し、続けて
`registerTecodeAlias` を呼び出す処理を組み込む。ESLint のレイヤ境界により `@tecode/core` を import
できるのは `packages/cli` のみである点を守る。

3. プラグイン登録は、インポート対象モジュールの評価前に行う。`bun build --compile`
の場合は、ビルドエントリからプラグインを登録し、実行ファイルへ埋め込む方針とする。`bunfig.toml` の preload には依存しない。

4. 本タスクでは実行ファイルのビルドスクリプトは未整備のままでよい。開発実行での解決を優先しつつ、compiled モードの登録経路（ビルドエントリからの
`registerTecodeAlias` 呼び出し）を明記する。

Phase 3: コントラクトテストと CI 連携

このフェーズはフィクスチャ拡張機能を実コアに対して有効化し、全名前空間の契約を検証する。テスト一式を CI の名前付きジョブに接続する。

Task 1: フィクスチャ拡張機能を用意する

全名前空間を行使する最小の拡張機能を追加する。

• packages/core/src/api/ 配下（またはテスト用フィクスチャ用ディレクトリ）にフィクスチャ拡張機能を新設する。
• activate(ctx) を定義し、ctx.api から 9 名前空間すべてにアクセスする。
• import { commands } from "tecode" 経由の解決も行使する（両経路が同一オブジェクトに解決されることを検証可能にする）。
• 各名前空間の register／dispose を呼び、onDid* を購読する。

Task 2: コントラクトテスト一式を実装する

契約の 3 点（register/dispose 対称性、イベント発火順序、凍結性）を検証する。

• packages/core/src/api/ 配下に bun:test のコントラクトテストファイル（例: create.contract.test.ts）を新設する。
• 合成ルートを直接組み立てる（createCommandRegistry、createDocumentManager、createConfigService、createContextService、FileSystem、createNoopStatusSink を合成）。既存の合成ルート／統合テストは無いため、新規に構築する。
• ctx.api と "tecode" import の両経路で全名前空間へ到達できることを検証する。
• 各名前空間への代入・変更がエラーを投げること（凍結性）を検証する。
• register の戻り値 Disposable を dispose した後にリスナが発火しないこと（対称性）を検証する。
• workspace.onDidOpen／onDidClose／onDidSave の発火順序を検証する。
• アクティブエディタが無い状態で editor.applyEdits などが no-op となり、注入した StatusSink に HostError が届くことを検証する。
• このテスト一式が将来の API_VERSION 引き上げの互換ゲートである旨をファイル冒頭コメントに明記する。必要に応じて checkApiVersionCompatibility を参照する。

Task 3: CI ワークフローを新設しコントラクトジョブを接続する

bun test と eslint . を名前付きジョブとして実行する。

• .github/workflows/ に CI ワークフロー（例: ci.yml）を新設する。既存の CI は無いため新規作成する。
• Bun をセットアップし、bun install を実行する。
• 名前付きステップ（例: contract-tests）で bun test を実行する。この実行は Task 3.2 のコントラクトテストを含む。
• 名前付きステップ（例: lint）で eslint . を実行する。ESLint のレイヤ境界に違反しないことを保証する。

🤖 Prompt for AI agents

このフェーズではフィクスチャ拡張機能とコントラクトテスト一式を実装し、CI に接続する。

1. `packages/core/src/api/`
配下（またはテスト用フィクスチャ用ディレクトリ）にフィクスチャ拡張機能を新設する。`activate(ctx)` を定義し、`ctx.api` から 9
名前空間すべてにアクセスする処理を書く。`import { commands } from "tecode"` 経由の解決も行使し、`ctx.api` 経路と
`"tecode"` import 経路が同一オブジェクトに解決されることを検証可能にする。各名前空間の `register`／`dispose`
を呼び、`onDid*` を購読する処理を含める。

2. `packages/core/src/api/` 配下に `bun:test` のコントラクトテストファイル（例:
`create.contract.test.ts`）を新設する。合成ルートは
`createCommandRegistry`、`createDocumentManager`、`createConfigService`、`createContextService`、`FileSystem`、`createNoopStatusSink`
を組み合わせて新規に構築する（既存の合成ルート／統合テストは無い）。以下を検証する:
 - `ctx.api` と `"tecode"` import の両経路で全名前空間へ到達できること。
 - 各名前空間への代入・変更がエラーを投げること（凍結性）。
 - `register` の戻り値 `Disposable` を `dispose` した後、リスナが発火しないこと（対称性）。
 - `workspace.onDidOpen`／`onDidClose`／`onDidSave` の発火順序。
- アクティブエディタが無い状態で `editor.applyEdits` などが no-op となり、注入した `StatusSink` に
`HostError` が届くこと。
- ファイル冒頭コメントに、このテスト一式が将来の `API_VERSION` 引き上げの互換ゲートである旨を明記する。必要に応じて
`checkApiVersionCompatibility` を参照する。

3. `.github/workflows/` に CI ワークフロー（例: `ci.yml`）を新設する。Bun をセットアップし、`bun install`
を実行するステップを設ける。名前付きステップ（例: `contract-tests`）で `bun test`
を実行する。この実行にはコントラクトテストを含める。名前付きステップ（例: `lint`）で `eslint .` を実行し、ESLint
のレイヤ境界に違反しないことを保証する。

Research

本リポジトリは Bun ワークスペースのモノレポである。

• packages/api は型のみを提供する。API_VERSION = "1.0" を定義する。namespaces.ts の Tecode 型で 9 個の名前空間インターフェイスを定義する。
• packages/core は各サービスを実装する。以下は該当する名前空間の実装を既に持つ。
  • commands/registry.ts
  • config/service.ts
  • buffer/documentManager.ts
  • keymap/context.ts
• window／editor／ui／languages／themes の実サービスは Phase 2 以降の別タスクである。本タスクではスタブで足りる。
• packages/core/src/api/index.ts は現在プレースホルダである。
• host/errors.ts は StatusSink と createNoopStatusSink を提供する。
• host/validate.ts は checkApiVersionCompatibility を提供する。
• 共通のイベントエミッタユーティリティは存在しない。各サービスがローカルな Set<Listener<T>> パターンで Event<T> を実装する。
• CI 設定（.github/workflows）と bunfig.toml は存在しない。
• ESLint フラット設定は「@tecode/core を直接 import できるのは packages/cli のみ」というレイヤ境界を強制する。

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

このフェーズでは `core/api/create.ts` を新設し、`Tecode` 型に沿った 9 名前空間の実オブジェクトを組み立てる。

1. `packages/core/src/buffer/` 配下に `FileSystem` 実装（例:
`fileSystem.ts`）を新設する。`@tecode/api` の `FileSystem`
インターフェイス（`read`／`write`／`stat`／`readdir`／`watch`）を満たすこと。`read`／`write`／`stat`／`readdir`
は `node:fs/promises` に委譲する。`stat` の戻り値は
`FileStat`（`type`／`size`／`mtime`／`ctime`）へ変換する。`readdir` の戻り値は
`DirEntry[]`（`name`／`type`）へ変換する。`watch` は `node:fs` の `fs.watch`
に委譲し、`FileChangeEvent`（`created`／`changed`／`deleted`）へ写像し、監視を停止する `Disposable`
を返す。サンドボックスは課さない。

2. `packages/core/src/api/` 配下に、`window`／`editor`／`ui`／`languages`／`themes`
のスタブ生成関数を新設する。各スタブは対応する名前空間インターフェイスを型どおりに満たす。`EditorNamespace` の
`revealLine`／`insertSnippet`／`applyEdits` は常に no-op とし、呼び出し時に `StatusSink.error`
で「No active editor」の `HostError` を通知する。`EditorNamespace.selections`
は空配列、`cursor`
は原点位置を返す。`LanguagesNamespace.register`／`ThemesNamespace.register`／`UiNamespace.registerView`
は `Set<Listener<T>>` + ガード付き `dispose` の house style に従うレジストリスタブとし、有効な
`Disposable` を返す。`register`／`dispose` の対称性がテスト可能な構造にする。

3. `packages/core/src/api/create.ts` を新設する。既存のプレースホルダ
`packages/core/src/api/index.ts` を置き換え、`create.ts` を re-export
する形にする。依存サービスを引数で受け取る合成ルート関数（例: `createTecodeApi(deps)`）を定義する。`deps` には
`CommandRegistry`、`DocumentManager`、`ConfigService`、`ContextService`、`FileSystem`、`StatusSink`
を含める。

4. 名前空間ごとの配線ルール:
- `commands`: `CommandRegistry` の `register`／`execute`／`list`
のみを射影する。`registerLazy` は公開しない。
- `workspace`: `DocumentManager` の
`openDocument`／`documents`／`onDidOpen`／`onDidClose`／`onDidSave` に委譲し、Task 1.1 の
`fs` と `rootUri` を組み込む。
 - `config`: `ConfigService` の `get`／`onDidChange` のみを射影する。
 - `context`: `ContextService` の `set`／`get` のみを射影する。`onDidChange` は公開しない。
 - `window`／`editor`／`ui`／`languages`／`themes`: Task 1.2 のスタブを配線する。

5. 組み立て後、各名前空間オブジェクトに `Object.freeze` を適用する（浅い凍結）。集約 `Tecode` オブジェクト自体も凍結する。既存の
`Event<T>` は各サービスのプロパティへ直接委譲し、新規エミッタユーティリティは作成しない。
===============================================================================

Task: 2

このフェーズでは Bun の仮想モジュール機構を用いて、素の `"tecode"` 指定子を組み立て済みオブジェクトへ解決する。

1. `packages/core/src/api/` 配下にエイリアス登録関数（例:
`registerTecodeAlias(api)`）を新設する。`Bun.plugin` の `builder.module("tecode", () =>
({ exports: api, loader: "object" }))` を使って `"tecode"` を完全一致で登録する。この登録は Phase 1
の `createTecodeApi` の後に行う。登録関数は冪等にし、二重登録を避けるガードを設ける。

2. `packages/cli/src/main.ts` の起動シーケンスに、拡張機能をロードする前に `createTecodeApi` を呼び出し、続けて
`registerTecodeAlias` を呼び出す処理を組み込む。ESLint のレイヤ境界により `@tecode/core` を import
できるのは `packages/cli` のみである点を守る。

3. プラグイン登録は、インポート対象モジュールの評価前に行う。`bun build --compile`
の場合は、ビルドエントリからプラグインを登録し、実行ファイルへ埋め込む方針とする。`bunfig.toml` の preload には依存しない。

4. 本タスクでは実行ファイルのビルドスクリプトは未整備のままでよい。開発実行での解決を優先しつつ、compiled モードの登録経路（ビルドエントリからの
`registerTecodeAlias` 呼び出し）を明記する。
===============================================================================

Task: 3

このフェーズではフィクスチャ拡張機能とコントラクトテスト一式を実装し、CI に接続する。

1. `packages/core/src/api/`
配下（またはテスト用フィクスチャ用ディレクトリ）にフィクスチャ拡張機能を新設する。`activate(ctx)` を定義し、`ctx.api` から 9
名前空間すべてにアクセスする処理を書く。`import { commands } from "tecode"` 経由の解決も行使し、`ctx.api` 経路と
`"tecode"` import 経路が同一オブジェクトに解決されることを検証可能にする。各名前空間の `register`／`dispose`
を呼び、`onDid*` を購読する処理を含める。

2. `packages/core/src/api/` 配下に `bun:test` のコントラクトテストファイル（例:
`create.contract.test.ts`）を新設する。合成ルートは
`createCommandRegistry`、`createDocumentManager`、`createConfigService`、`createContextService`、`FileSystem`、`createNoopStatusSink`
を組み合わせて新規に構築する（既存の合成ルート／統合テストは無い）。以下を検証する:
 - `ctx.api` と `"tecode"` import の両経路で全名前空間へ到達できること。
 - 各名前空間への代入・変更がエラーを投げること（凍結性）。
 - `register` の戻り値 `Disposable` を `dispose` した後、リスナが発火しないこと（対称性）。
 - `workspace.onDidOpen`／`onDidClose`／`onDidSave` の発火順序。
- アクティブエディタが無い状態で `editor.applyEdits` などが no-op となり、注入した `StatusSink` に
`HostError` が届くこと。
- ファイル冒頭コメントに、このテスト一式が将来の `API_VERSION` 引き上げの互換ゲートである旨を明記する。必要に応じて
`checkApiVersionCompatibility` を参照する。

3. `.github/workflows/` に CI ワークフロー（例: `ci.yml`）を新設する。Bun をセットアップし、`bun install`
を実行するステップを設ける。名前付きステップ（例: `contract-tests`）で `bun test`
を実行する。この実行にはコントラクトテストを含める。名前付きステップ（例: `lint`）で `eslint .` を実行し、ESLint
のレイヤ境界に違反しないことを保証する。

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

---