1.14 Build the UI shell with empty slots

[goofmint]

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

Summary

Build the OpenTUI/React UI shell: layout regions, slot registry, focus-to-context tracking, and layout persistence.

Details

• Component tree (design.md §8.1): ThemeProvider (hardcoded base palette for now) → ContextFocusTracker → Shell with ActivityBar, Sidebar, EditorArea (tab bar + placeholder), Panel, StatusBar.
• Slot registry backing tecode.ui.registerView(slot, id, Component): per-slot ordered maps; regions re-render on registration; activityBar items pair 1:1 with sidebar views; status-bar items carry { side, priority } and render sorted.
• Focus tracking maps OpenTUI focus to context keys (editorFocus, etc.).
• Layout state { sidebarVisible, sidebarWidth, panelVisible, panelHeight, activeView } persists to ~/.config/tecode/state.json (debounced + on exit) and restores on start.

Completion requirements

• Headless-renderer snapshot: empty shell renders all regions
• Registering a view via the API re-renders its region (snapshot before/after)
• Status-bar side/priority ordering verified
• Layout state round-trips through state.json across a simulated restart
• Focus changes update context keys (asserted through the context service)
• bun test and lint pass

References

• requirements.md: Req 6.1–6.4
• design.md: §8.1, §8.2

Dependencies

Blocked by: 1.13 (#14).

[goofmint]

@coderabbitai make plan in Japanese

---

Generated by Claude Code

[coderabbitai]

Coding Plan

Summary

• Phase 1 で React と OpenTUI の依存および JSX ビルド設定を整える。これは全 UI 実装の前提となる。
• Phase 2 で UI 非依存のスロットレジストリとレイアウト永続化サービスを実装する。実装は既存のファクトリ規約（createX(deps)、Disposable、logSafely/notifySafely、注入 seam）に従う。
• Phase 3 と Phase 4 で design.md §8.1 の構成木に沿って UI コンポーネントを作る。作成したコンポーネントは tecode.ui 名前空間へ配線し、バレルエクスポートを更新する。
• Phase 5 で単体テストとヘッドレスレンダラのスナップショットテストを実施する。これにより、チケットの全完了要件を検証する。

Design Choices

Design Choice 1: OpenTUI ヘッドレスレンダラでのスナップショットテスト方法

Options Considered:

1. OpenTUI の bufferedOutput を使い、固定サイズ・注入クロックでレンダリングし、セルグリッド文字列をスナップショットとして比較する。
2. react-test-renderer などの外部ライブラリを追加し、React 要素ツリーをスナップショットする。

Chosen Option: 1

Rationale: design.md §16 は「OpenTUI のヘッドレスレンダラでセルグリッドをスナップショットする」と明記している。この方針は外部依存を増やさない方針に合致する。なお、OpenTUI の公式ドキュメントはテストハーネスの API を明確に定義していない。Web 検索の結果、bufferedOutput（メモリ内出力先）と OptimizedBuffer によるセルグリッド取得が利用できることを確認した。

Design Choice 2: レイアウト状態永続化のデバウンス実装

Options Considered:

1. サービス内部に注入可能なタイマー（setTimeout seam）を持ち、変更をデバウンスして書き込み、flush() を終了時に呼ぶ。
2. 変更毎に即時書き込みし、デバウンスを省略する。

Chosen Option: 1

Rationale: チケットの完了要件はデバウンスと終了時保存の両方を要求する。注入可能タイマーを使うことで両方の要件を両立できる。なお、config/service.ts は意図的にデバウンスを持たない設計である。しかし、レイアウト状態はリサイズ毎に頻繁に変化するため、通常の設定サービスとは異なる扱いが必要である。

💡 User Tips

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

Implementation Steps

Phase 1: 依存関係とビルド設定の追加

UI シェルは React と OpenTUI を必要とする。両者は未インストールのため、まずパッケージ依存とビルド設定を整える。この作業は後続の全 UI 実装の前提となる。

Task 1: React と OpenTUI の依存を追加する

UI コンポーネントの実行に必要なランタイム依存を導入する。

• packages/core/package.json に react、@opentui/core、@opentui/react を dependencies として追加する。
• bun install を実行して bun.lock を更新する。
• @types/react を devDependencies に追加して型を有効にする。
• レイヤリング規約を維持する。packages/builtin/* は @tecode/core を直接 import しない。React/OpenTUI 依存は core に閉じる。

Task 2: tsconfig に JSX 設定を追加する

.tsx コンポーネントをコンパイル可能にする。

• packages/core/tsconfig.json に "jsx": "react-jsx"（または OpenTUI が要求する jsxImportSource）を追加する。
• ルートの共通 tsconfig を壊さないよう、core パッケージ固有の設定として追加する。

🤖 Prompt for AI agents

このフェーズは、React と OpenTUI をビルドに組み込むための準備を行う。目的は、後続フェーズで `.tsx`
コンポーネントを実装できる状態を整えることである。

次の作業を行う。
- `packages/core/package.json` の dependencies に
`react`、`@opentui/core`、`@opentui/react` を追加する。
- `bun install` を実行し、`bun.lock` を更新する。
- `@types/react` を devDependencies に追加する。
- レイヤリング規約を守る。`packages/builtin/*` から `@tecode/core` を直接 import
してはならない。React/OpenTUI への依存は `core` パッケージ内に閉じる。
- `packages/core/tsconfig.json` に `"jsx": "react-jsx"`（または OpenTUI が要求する
`jsxImportSource`）を追加する。この設定は `core` パッケージ固有とし、ルートの共通 tsconfig には影響を与えない。

Phase 2: スロットレジストリとレイアウト永続化サービス（コアロジック）

UI 描画から独立したコアロジックを先に実装する。これらは既存のファクトリ規約に完全に従い、単体でテスト可能である。

Task 1: スロットレジストリを実装する

tecode.ui.registerView を背後で支えるレジストリを新規作成する。

• packages/core/src/ui/ に新規ファイル（例 slotRegistry.ts）を作成し、createSlotRegistry(deps) ファクトリを実装する。
• スロット毎に順序付きマップを保持する。キーは (slot, id) とする。
• registerView(slot, id, component) を提供する。登録は冪等な Disposable を返す。同一 (slot, id) は後勝ちとし、警告を logSafely で記録する。これは commands/registry.ts の register を範とする。
• 構築時に LoadExtensionsResult.pendingViews（PendingViewContribution[]）を受け取り、遅延ビューエントリとして格納する。registerView が実コンポーネントで遅延エントリを上書きする。これは registry.ts の registerLazy を範とする。
• レジストリ変更時に発火する onDidChange（Set<Listener> + スナップショット + try/catch ガード）を提供する。シェル領域はこれを購読して再描画する。これは keymap/context.ts の onDidChange を範とする。
• 遅延ビューの描画要求時に ExtensionHost.activateExtension(extensionId) を呼ぶフックを提供する。host/activation.ts の遅延活性化を範とし、決して throw しない。
• activityBar.item と同一 id の sidebar.view を 1:1 で対応付ける参照ロジックを含める。
• statusBar.item エントリは { side, priority } を保持し、side と priority でソートして列挙するヘルパを提供する。

Task 2: レイアウト状態の永続化サービスを実装する

レイアウト状態を state.json に保存・復元する。

• packages/core/src/host/paths.ts に getUserLayoutStatePath() を追加し、join(getUserConfigDir(), "state.json") を返す。
• packages/core/src/ui/（または config/）に新規ファイルを作成し、createLayoutStateService(deps) ファクトリを実装する。
• 状態形状は { sidebarVisible, sidebarWidth, panelVisible, panelHeight, activeView } とする。
• 注入可能な FS seam（readFile/writeFile）を定義する。既定は node:fs/promises。これは config/service.ts の ConfigServiceFs seam を範とする。
• 起動時に state.json を読み込み、パース失敗時は既定値を保持する（last-good ポリシー）。読み込みは非ブロッキングで ready: Promise<void> として公開する。
• 状態更新をデバウンスして書き込む。デバウンスは注入可能タイマー seam で実装する。書き込みは直列化チェーン（saveChain = saveChain.then(doSave, doSave)）で競合を防ぐ。
• 終了時に未保存分を確実に書き込む flush() を提供する。
• 全ての I/O 失敗を logSafely/notifySafely で報告し、公開 API から throw しない。log: HostLog と sink: StatusSink を deps として受け取る。

🤖 Prompt for AI agents

このフェーズは、UI
描画に依存しないコアロジックを実装する。目的は、スロットレジストリとレイアウト永続化サービスを、既存のファクトリ規約に従って単体テスト可能な形で実装することである。

スロットレジストリの実装:
- `packages/core/src/ui/` に新規ファイル（例
`slotRegistry.ts`）を作成し、`createSlotRegistry(deps)` ファクトリを実装する。
- スロット毎に順序付きマップを保持する。キーは `(slot, id)` とする。
- `registerView(slot, id, component)` を提供する。登録は冪等な `Disposable` を返す。
- 同一 `(slot, id)` の登録は後勝ちとする。上書き時は `logSafely` で警告を記録する。この動作は
`commands/registry.ts` の `register` を範とする。
- 構築時に
`LoadExtensionsResult.pendingViews`（`PendingViewContribution[]`）を受け取り、遅延ビューエントリとして格納する。`registerView`
が実コンポーネントで遅延エントリを上書きする。この動作は `registry.ts` の `registerLazy` を範とする。
- レジストリ変更時に発火する `onDidChange` を提供する。`Set<Listener>`、スナップショット、try/catch
ガードを用いる。シェル領域はこれを購読して再描画する。この動作は `keymap/context.ts` の `onDidChange` を範とする。
- 遅延ビューの描画要求時に `ExtensionHost.activateExtension(extensionId)`
を呼ぶフックを提供する。`host/activation.ts` の遅延活性化を範とする。このフックは決して throw してはならない。
- `activityBar.item` と同一 `id` の `sidebar.view` を 1:1 で対応付ける参照ロジックを含める。
- `statusBar.item` エントリは `{ side, priority }` を保持する。`side` と `priority`
でソートして列挙するヘルパを提供する。

レイアウト状態の永続化サービスの実装:
- `packages/core/src/host/paths.ts` に `getUserLayoutStatePath()` を追加する。この関数は
`join(getUserConfigDir(), "state.json")` を返す。
- `packages/core/src/ui/`（または
`config/`）に新規ファイルを作成し、`createLayoutStateService(deps)` ファクトリを実装する。
- 状態形状は `{ sidebarVisible, sidebarWidth, panelVisible, panelHeight, activeView
}` とする。
- 注入可能な FS seam（`readFile`/`writeFile`）を定義する。既定実装は `node:fs/promises` とする。この
seam は `config/service.ts` の `ConfigServiceFs` seam を範とする。
- 起動時に `state.json` を読み込む。パースに失敗した場合は既定値を保持する（last-good
ポリシー）。読み込みは非ブロッキングとし、`ready: Promise<void>` として公開する。
- 状態更新はデバウンスして書き込む。デバウンスは注入可能タイマー seam で実装する。書き込みは直列化チェーン（`saveChain =
saveChain.then(doSave, doSave)`）を用いて競合を防ぐ。
- 終了時に未保存分を確実に書き込む `flush()` を提供する。
- 全ての I/O 失敗は `logSafely`/`notifySafely` で報告する。公開 API から throw してはならない。`log:
HostLog` と `sink: StatusSink` を deps として受け取る。

Phase 3: テーマと Shell コンポーネント（OpenTUI/React）

UI 描画層を実装する。既存の実行時実装が無いため、design.md §8.1 の構成木に従って新規作成する。

Task 1: ThemeProvider と useTheme を実装する

ハードコードのベースパレットを React コンテキストで供給する。

• packages/core/src/ui/ に ThemeProvider コンポーネントと useTheme() フックを作成する。
• packages/api/src/theme.ts の ResolvedTheme 形状を満たす。colors は 55 個全ての UiColorKey に RGB を割り当てる。tokens は 9 個の BaseCaptureName に最小限の Style を割り当てる。
• 具体的な色値は実装上の選択とする。design.md は具体値を規定しない。将来 themes-default が実テーマを登録した際に差し替え可能な構造にする。
• ComponentType（(props) => unknown）を実 React コンポーネント型に対応付ける。@tecode/api は React 非依存のため、core 側で境界を橋渡しする。

Task 2: Shell レイアウト領域を実装する

シェルの各領域コンポーネントを作成する。

• packages/core/src/ui/ に Shell、ActivityBar、Sidebar、EditorArea（TabBar + プレースホルダ EditorView）、Panel、StatusBar を作成する。
• Shell は VS Code 配置（アクティビティバー、サイドバー、タブ付きエディタ領域、下部パネル、ステータスバー）を構成する（Req 6.1）。
• 各領域は Task 2.1 のスロットレジストリを購読し、onDidChange で再描画する。
• ActivityBar はアイコンを表示し、クリックまたは workbench.view.<id> コマンド実行で同一 id の sidebar.view に切り替える（Req 6.2）。
• StatusBar は side/priority 順にアイテムを描画する。
• MVP はエディタグループ 1 個・複数タブのみを対象とする（Req 6.5）。EditorView はプレースホルダとする。
• レイアウトの表示状態と寸法は Task 2.2 のサービスから復元し、変更時にサービスへ通知する。

Task 3: ContextFocusTracker を実装する

OpenTUI のフォーカスをコンテキストキーに写像する。

• packages/core/src/ui/ に ContextFocusTracker コンポーネントを作成する。
• OpenTUI のフォーカス状態を購読し、フォーカス移動時に editorFocus などのコンテキストキーを設定する。
• 設定には既存の createContextService() の set(key, value) を用いる。新たなコンテキストストアは作らない。
• キー設定は当該領域のフォーカス取得・喪失に対応させる。

Task 4: 共通コンポーネントの最小実装を用意する

UiNamespace が要求する共通コンポーネントを満たす。

• packages/core/src/ui/ に List、Tree、Input、Tabs の最小コンポーネントを作成する。
• 本タスクの範囲は空スロットのシェルであるため、機能は最小限とする。将来のタスク（explorer 等）が拡張する。

🤖 Prompt for AI agents

このフェーズは、design.md §8.1 の構成木に従って UI
描画層を実装する。目的は、テーマ供給、シェルのレイアウト領域、フォーカス連携、共通コンポーネントの最小実装を用意することである。

ThemeProvider と useTheme の実装:
- `packages/core/src/ui/` に `ThemeProvider` コンポーネントと `useTheme()` フックを作成する。
- `packages/api/src/theme.ts` の `ResolvedTheme` 形状を満たす。`colors` には 55 個全ての
`UiColorKey` に対応する `RGB` を割り当てる。`tokens` には 9 個の `BaseCaptureName` に対応する最小限の
`Style` を割り当てる。
- 具体的な色値は実装上の選択とする。design.md は具体値を規定していない。将来 `themes-default`
が実テーマを登録する際に差し替え可能な構造にする。
- `ComponentType`（`(props) => unknown`）を実 React コンポーネント型に対応付ける。`@tecode/api` は
React に依存しないため、`core` 側で両者の境界を橋渡しする。

Shell レイアウト領域の実装:
- `packages/core/src/ui/` に
`Shell`、`ActivityBar`、`Sidebar`、`EditorArea`（`TabBar` とプレースホルダ `EditorView`
で構成）、`Panel`、`StatusBar` を作成する。
- `Shell` は VS Code 配置を構成する。配置はアクティビティバー、サイドバー、タブ付きエディタ領域、下部パネル、ステータスバーで構成する（Req
6.1）。
- 各領域は Task 2.1 のスロットレジストリを購読する。レジストリの `onDidChange` を受けて再描画する。
- `ActivityBar` はアイコンを表示する。クリックまたは `workbench.view.<id>` コマンド実行によって、同一 `id` の
`sidebar.view` に切り替える（Req 6.2）。
- `StatusBar` は `side` と `priority` の順にアイテムを描画する。
- MVP の対象範囲は、エディタグループ 1 個と複数タブのみとする（Req 6.5）。`EditorView` はプレースホルダとする。
- レイアウトの表示状態と寸法は、Task 2.2 のレイアウト永続化サービスから復元する。状態が変化した場合は、当該サービスへ通知する。

ContextFocusTracker の実装:
- `packages/core/src/ui/` に `ContextFocusTracker` コンポーネントを作成する。
- OpenTUI のフォーカス状態を購読する。フォーカス移動時に `editorFocus` などのコンテキストキーを設定する。
- キーの設定には既存の `createContextService()` の `set(key, value)`
を用いる。新たなコンテキストストアを作ってはならない。
- キー設定は、当該領域のフォーカス取得とフォーカス喪失の両方に対応させる。

共通コンポーネントの最小実装:
- `packages/core/src/ui/` に `List`、`Tree`、`Input`、`Tabs` の最小コンポーネントを作成する。これらは
`UiNamespace` が要求するコンポーネントである。
- 本タスクの範囲は空スロットのシェルであるため、機能は最小限に留める。将来の explorer 等のタスクが拡張する前提とする。

Phase 4: API 配線とエクスポート

コアロジックと UI を tecode.ui 名前空間に接続し、バレルエクスポートを更新する。

Task 1: tecode.ui 名前空間を組み立てる

スロットレジストリと UI 要素を UiNamespace に接続する。

• packages/core/src/api/index.ts（Task 1.13 で組み立て済みの想定）に対し、tecode.ui の registerView・useTheme・List・Tree・Input・Tabs を Task 2.1/3.1/3.4 の実装に配線する。
• registerView は Task 2.1 のレジストリの同名メソッドへ委譲する。
• 名前空間はシャローフリーズ規約に従う（Task 1.13 の方針を維持する）。

Task 2: バレルエクスポートを更新する

新しい UI モジュールを公開する。

• packages/core/src/ui/index.ts の UI_PLACEHOLDER を、Shell・ThemeProvider・useTheme・createSlotRegistry・createLayoutStateService などの実エクスポートに置き換える。
• packages/core/src/index.ts の ./ui/index 再エクスポート行を、上記に合わせて更新する。
• packages/core/src/host/paths.ts の新規 getUserLayoutStatePath を必要に応じて host/index 経由で公開する。
• packages/core/src/index.test.ts は列挙型の契約テストではないため、更新は不要である。

🤖 Prompt for AI agents

このフェーズは、コアロジックと UI コンポーネントを `tecode.ui`
名前空間に接続し、バレルエクスポートを更新する。目的は、実装済みの機能を外部から利用可能な形で公開することである。

tecode.ui 名前空間の組み立て:
- `packages/core/src/api/index.ts`（Task 1.13 で組み立て済みの想定）を対象とする。`tecode.ui` の
`registerView`・`useTheme`・`List`・`Tree`・`Input`・`Tabs` を、Task 2.1/3.1/3.4
の実装に配線する。
- `registerView` は Task 2.1 のレジストリが持つ同名メソッドへ委譲する。
- 名前空間はシャローフリーズ規約に従う。Task 1.13 で確立した方針を維持する。

バレルエクスポートの更新:
- `packages/core/src/ui/index.ts` の `UI_PLACEHOLDER`
を、`Shell`・`ThemeProvider`・`useTheme`・`createSlotRegistry`・`createLayoutStateService`
などの実エクスポートに置き換える。
- `packages/core/src/index.ts` の `./ui/index` 再エクスポート行を、上記の変更に合わせて更新する。
- `packages/core/src/host/paths.ts` に追加した新規 `getUserLayoutStatePath` を、必要に応じて
`host/index` 経由で公開する。
- `packages/core/src/index.test.ts` は列挙型の契約テストではないため、更新は不要である。

Phase 5: テスト

チケットの完了要件を検証する。全て bun test で実行し、lint を通す。

Task 1: スロットレジストリとレイアウト永続化の単体テストを追加する

UI 非依存ロジックを検証する。

• スロットレジストリのテストを追加する。登録/破棄の対称性、後勝ち上書き、onDidChange 発火、statusBar.item の side/priority ソートを検証する。
• レイアウト永続化のテストを追加する。注入 FS seam で state.json への書き込みと読み込みを検証し、シミュレートした再起動で状態がラウンドトリップすることを確認する。
• デバウンスと flush() の動作を注入タイマー seam で検証する。

Task 2: ヘッドレスレンダラでのスナップショットテストを追加する

UI 描画とフォーカス連携を検証する。

• OpenTUI の bufferedOutput を使い、固定サイズでシェルをレンダリングする。
• 空シェルが全領域を描画することをセルグリッドのスナップショットで検証する。
• API 経由でビューを登録すると当該領域が再描画されることを、登録前後のスナップショットで検証する。
• フォーカス変更がコンテキストキーを更新することを、createContextService() の get(key) で検証する。

🤖 Prompt for AI agents

このフェーズは、チケットの完了要件を検証するテストを実装する。全てのテストは `bun test` で実行可能とし、lint を通す。

スロットレジストリとレイアウト永続化の単体テスト:
- スロットレジストリのテストを追加する。登録と破棄の対称性、同一 `(slot, id)` の後勝ち上書き、`onDidChange`
の発火、`statusBar.item` の `side`/`priority` ソートを検証する。
- レイアウト永続化のテストを追加する。注入した FS seam を用いて `state.json`
への書き込みと読み込みを検証する。シミュレートした再起動を通して、状態がラウンドトリップすることを確認する。
- デバウンスと `flush()` の動作を、注入したタイマー seam を用いて検証する。

ヘッドレスレンダラでのスナップショットテスト:
- OpenTUI の `bufferedOutput` を使い、固定サイズでシェルをレンダリングする。
- 空シェルが全領域を描画することを、セルグリッドのスナップショットで検証する。
- API 経由でビューを登録した場合に、当該領域が再描画されることを検証する。検証は、登録前後のスナップショットを比較して行う。
- フォーカス変更がコンテキストキーを更新することを検証する。検証には `createContextService()` の `get(key)` を用いる。

Research

本プロジェクトは Bun / TypeScript のモノレポである。

packages/api は実行時依存ゼロの型定義パッケージである。UiNamespace・SlotId・ComponentType・ResolvedTheme・UiColorKey（55 キー）などをすでに型として定義済みである。

packages/core は各サービスをファクトリ関数 createX(deps) として実装する層である。commands/registry.ts・keymap/context.ts・config/service.ts・host/* は共通の規約に従う。共通規約は次のとおりである。

• Map による状態管理
• Set<Listener> による購読
• 冪等な Disposable
• logSafely/notifySafely によるガード

packages/core/src/ui/index.ts と packages/core/src/api/index.ts は現在プレースホルダである。

host/registration.ts は contributes.views を PendingViewContribution[] に収集する。スロットレジストリ（本タスク）がこれを消費することを想定している。

OpenTUI と React はまだ未インストールである。tsconfig に JSX 設定は無い。

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

このフェーズは、React と OpenTUI をビルドに組み込むための準備を行う。目的は、後続フェーズで `.tsx`
コンポーネントを実装できる状態を整えることである。

次の作業を行う。
- `packages/core/package.json` の dependencies に
`react`、`@opentui/core`、`@opentui/react` を追加する。
- `bun install` を実行し、`bun.lock` を更新する。
- `@types/react` を devDependencies に追加する。
- レイヤリング規約を守る。`packages/builtin/*` から `@tecode/core` を直接 import
してはならない。React/OpenTUI への依存は `core` パッケージ内に閉じる。
- `packages/core/tsconfig.json` に `"jsx": "react-jsx"`（または OpenTUI が要求する
`jsxImportSource`）を追加する。この設定は `core` パッケージ固有とし、ルートの共通 tsconfig には影響を与えない。
===============================================================================

Task: 2

このフェーズは、UI
描画に依存しないコアロジックを実装する。目的は、スロットレジストリとレイアウト永続化サービスを、既存のファクトリ規約に従って単体テスト可能な形で実装することである。

スロットレジストリの実装:
- `packages/core/src/ui/` に新規ファイル（例
`slotRegistry.ts`）を作成し、`createSlotRegistry(deps)` ファクトリを実装する。
- スロット毎に順序付きマップを保持する。キーは `(slot, id)` とする。
- `registerView(slot, id, component)` を提供する。登録は冪等な `Disposable` を返す。
- 同一 `(slot, id)` の登録は後勝ちとする。上書き時は `logSafely` で警告を記録する。この動作は
`commands/registry.ts` の `register` を範とする。
- 構築時に
`LoadExtensionsResult.pendingViews`（`PendingViewContribution[]`）を受け取り、遅延ビューエントリとして格納する。`registerView`
が実コンポーネントで遅延エントリを上書きする。この動作は `registry.ts` の `registerLazy` を範とする。
- レジストリ変更時に発火する `onDidChange` を提供する。`Set<Listener>`、スナップショット、try/catch
ガードを用いる。シェル領域はこれを購読して再描画する。この動作は `keymap/context.ts` の `onDidChange` を範とする。
- 遅延ビューの描画要求時に `ExtensionHost.activateExtension(extensionId)`
を呼ぶフックを提供する。`host/activation.ts` の遅延活性化を範とする。このフックは決して throw してはならない。
- `activityBar.item` と同一 `id` の `sidebar.view` を 1:1 で対応付ける参照ロジックを含める。
- `statusBar.item` エントリは `{ side, priority }` を保持する。`side` と `priority`
でソートして列挙するヘルパを提供する。

レイアウト状態の永続化サービスの実装:
- `packages/core/src/host/paths.ts` に `getUserLayoutStatePath()` を追加する。この関数は
`join(getUserConfigDir(), "state.json")` を返す。
- `packages/core/src/ui/`（または
`config/`）に新規ファイルを作成し、`createLayoutStateService(deps)` ファクトリを実装する。
- 状態形状は `{ sidebarVisible, sidebarWidth, panelVisible, panelHeight, activeView
}` とする。
- 注入可能な FS seam（`readFile`/`writeFile`）を定義する。既定実装は `node:fs/promises` とする。この
seam は `config/service.ts` の `ConfigServiceFs` seam を範とする。
- 起動時に `state.json` を読み込む。パースに失敗した場合は既定値を保持する（last-good
ポリシー）。読み込みは非ブロッキングとし、`ready: Promise<void>` として公開する。
- 状態更新はデバウンスして書き込む。デバウンスは注入可能タイマー seam で実装する。書き込みは直列化チェーン（`saveChain =
saveChain.then(doSave, doSave)`）を用いて競合を防ぐ。
- 終了時に未保存分を確実に書き込む `flush()` を提供する。
- 全ての I/O 失敗は `logSafely`/`notifySafely` で報告する。公開 API から throw してはならない。`log:
HostLog` と `sink: StatusSink` を deps として受け取る。
===============================================================================

Task: 3

このフェーズは、design.md §8.1 の構成木に従って UI
描画層を実装する。目的は、テーマ供給、シェルのレイアウト領域、フォーカス連携、共通コンポーネントの最小実装を用意することである。

ThemeProvider と useTheme の実装:
- `packages/core/src/ui/` に `ThemeProvider` コンポーネントと `useTheme()` フックを作成する。
- `packages/api/src/theme.ts` の `ResolvedTheme` 形状を満たす。`colors` には 55 個全ての
`UiColorKey` に対応する `RGB` を割り当てる。`tokens` には 9 個の `BaseCaptureName` に対応する最小限の
`Style` を割り当てる。
- 具体的な色値は実装上の選択とする。design.md は具体値を規定していない。将来 `themes-default`
が実テーマを登録する際に差し替え可能な構造にする。
- `ComponentType`（`(props) => unknown`）を実 React コンポーネント型に対応付ける。`@tecode/api` は
React に依存しないため、`core` 側で両者の境界を橋渡しする。

Shell レイアウト領域の実装:
- `packages/core/src/ui/` に
`Shell`、`ActivityBar`、`Sidebar`、`EditorArea`（`TabBar` とプレースホルダ `EditorView`
で構成）、`Panel`、`StatusBar` を作成する。
- `Shell` は VS Code 配置を構成する。配置はアクティビティバー、サイドバー、タブ付きエディタ領域、下部パネル、ステータスバーで構成する（Req
6.1）。
- 各領域は Task 2.1 のスロットレジストリを購読する。レジストリの `onDidChange` を受けて再描画する。
- `ActivityBar` はアイコンを表示する。クリックまたは `workbench.view.<id>` コマンド実行によって、同一 `id` の
`sidebar.view` に切り替える（Req 6.2）。
- `StatusBar` は `side` と `priority` の順にアイテムを描画する。
- MVP の対象範囲は、エディタグループ 1 個と複数タブのみとする（Req 6.5）。`EditorView` はプレースホルダとする。
- レイアウトの表示状態と寸法は、Task 2.2 のレイアウト永続化サービスから復元する。状態が変化した場合は、当該サービスへ通知する。

ContextFocusTracker の実装:
- `packages/core/src/ui/` に `ContextFocusTracker` コンポーネントを作成する。
- OpenTUI のフォーカス状態を購読する。フォーカス移動時に `editorFocus` などのコンテキストキーを設定する。
- キーの設定には既存の `createContextService()` の `set(key, value)`
を用いる。新たなコンテキストストアを作ってはならない。
- キー設定は、当該領域のフォーカス取得とフォーカス喪失の両方に対応させる。

共通コンポーネントの最小実装:
- `packages/core/src/ui/` に `List`、`Tree`、`Input`、`Tabs` の最小コンポーネントを作成する。これらは
`UiNamespace` が要求するコンポーネントである。
- 本タスクの範囲は空スロットのシェルであるため、機能は最小限に留める。将来の explorer 等のタスクが拡張する前提とする。
===============================================================================

Task: 4

このフェーズは、コアロジックと UI コンポーネントを `tecode.ui`
名前空間に接続し、バレルエクスポートを更新する。目的は、実装済みの機能を外部から利用可能な形で公開することである。

tecode.ui 名前空間の組み立て:
- `packages/core/src/api/index.ts`（Task 1.13 で組み立て済みの想定）を対象とする。`tecode.ui` の
`registerView`・`useTheme`・`List`・`Tree`・`Input`・`Tabs` を、Task 2.1/3.1/3.4
の実装に配線する。
- `registerView` は Task 2.1 のレジストリが持つ同名メソッドへ委譲する。
- 名前空間はシャローフリーズ規約に従う。Task 1.13 で確立した方針を維持する。

バレルエクスポートの更新:
- `packages/core/src/ui/index.ts` の `UI_PLACEHOLDER`
を、`Shell`・`ThemeProvider`・`useTheme`・`createSlotRegistry`・`createLayoutStateService`
などの実エクスポートに置き換える。
- `packages/core/src/index.ts` の `./ui/index` 再エクスポート行を、上記の変更に合わせて更新する。
- `packages/core/src/host/paths.ts` に追加した新規 `getUserLayoutStatePath` を、必要に応じて
`host/index` 経由で公開する。
- `packages/core/src/index.test.ts` は列挙型の契約テストではないため、更新は不要である。
===============================================================================

Task: 5

このフェーズは、チケットの完了要件を検証するテストを実装する。全てのテストは `bun test` で実行可能とし、lint を通す。

スロットレジストリとレイアウト永続化の単体テスト:
- スロットレジストリのテストを追加する。登録と破棄の対称性、同一 `(slot, id)` の後勝ち上書き、`onDidChange`
の発火、`statusBar.item` の `side`/`priority` ソートを検証する。
- レイアウト永続化のテストを追加する。注入した FS seam を用いて `state.json`
への書き込みと読み込みを検証する。シミュレートした再起動を通して、状態がラウンドトリップすることを確認する。
- デバウンスと `flush()` の動作を、注入したタイマー seam を用いて検証する。

ヘッドレスレンダラでのスナップショットテスト:
- OpenTUI の `bufferedOutput` を使い、固定サイズでシェルをレンダリングする。
- 空シェルが全領域を描画することを、セルグリッドのスナップショットで検証する。
- API 経由でビューを登録した場合に、当該領域が再描画されることを検証する。検証は、登録前後のスナップショットを比較して行う。
- フォーカス変更がコンテキストキーを更新することを検証する。検証には `createContextService()` の `get(key)` を用いる。

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

---