Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
アプリケーションモダナイゼーション計画
目標
現在のワークフローを壊したり、広範なリファクタリングの中にリスクを隠したりすることなく、アプリケーションをよりクリーンで、高速で、保守しやすいプロダクトへと進めます。作業は、小さくレビューしやすい単位で着地させ、変更した各サーフェスに対する証拠を伴うべきです。原則
- 境界が churn、性能コスト、またはユーザーに見えるバグの原因であることが実証されない限り、現在のアーキテクチャを維持する。
- 各問題に対して最小の正しいパッチを優先し、それを繰り返す。
- 必須の修正と任意の磨き込みを分け、メンテナーが主観的な判断を待たずに高価値の作業を着地できるようにする。
- Plugin 向けの動作は文書化し、後方互換性を維持する。
- リグレッションが修正されたと主張する前に、実際に出荷されている動作、依存先コントラクト、テストを検証する。
- まず主要なユーザーパスを改善する: オンボーディング、認証、chat、provider セットアップ、Plugin 管理、diagnostics。
フェーズ 1: ベースライン監査
変更を加える前に、現在のアプリケーションを棚卸しします。- 上位のユーザーワークフローと、それを所有するコードサーフェスを特定する。
- 使われていない affordance、重複設定、不明瞭なエラー状態、高コストな render パスを列挙する。
- 各サーフェスの現在の検証コマンドを記録する。
- 問題を required、recommended、optional に分類する。
- 特に API、セキュリティ、リリース、Plugin コントラクト変更について、オーナーレビューが必要な既知のブロッカーを文書化する。
- repo-root のファイル参照付きで、1 つの issue リストがあること。
- 各 issue に重大度、オーナーサーフェス、想定されるユーザー影響、提案された検証パスがあること。
- 必須修正の中に推測ベースの cleanup 項目が混ざっていないこと。
フェーズ 2: プロダクトと UX の整理
目に見えるワークフローを優先し、混乱を取り除きます。- model auth、Gateway status、Plugin セットアップ周辺のオンボーディング文言と空状態を改善する。
- 実行可能なアクションがない場合は、使われていない affordance を削除または無効化する。
- 重要なアクションを壊れやすいレイアウト前提の裏に隠さず、レスポンシブ幅全体で見えるように保つ。
- 繰り返される status 文言を集約し、エラーに単一の情報源を持たせる。
- 高度な設定には段階的開示を加えつつ、コアセットアップは高速なままに保つ。
- 初回セットアップと既存ユーザー起動の手動ハッピーパス。
- ルーティング、config 永続化、status 導出ロジックに対する絞ったテスト。
- 変更したレスポンシブサーフェスのブラウザスクリーンショット。
フェーズ 3: フロントエンドアーキテクチャの引き締め
広範な書き換えなしで保守性を改善します。- 繰り返される UI 状態変換を、狭く型付けされたヘルパーに移す。
- データ取得、永続化、表示の責務を分離して保つ。
- 新しい抽象化よりも、既存の hooks、stores、component パターンを優先する。
- 巨大な component は、結合度を下げる、またはテストを明確にする場合にのみ分割する。
- ローカルな panel の操作のために広範なグローバル state を導入しない。
- ファイル分割の副作用として公開動作を変更しない。
- menus、dialogs、tabs、keyboard navigation のアクセシビリティ動作を維持する。
- loading、empty、error、optimistic state が引き続き描画されることを検証する。
フェーズ 4: パフォーマンスと信頼性
広範な理論上の最適化ではなく、測定された痛点を対象にします。- startup、route transition、大規模リスト、chat transcript のコストを測定する。
- プロファイリングで価値が証明された場合に限り、繰り返し発生する高コストな導出データを memoized selector または cached helper に置き換える。
- ホットパスで避けられる network または filesystem scan を減らす。
- model payload 構築前に、prompt、registry、file、plugin、network 入力の決定的順序を保つ。
- ホット helper とコントラクト境界に対する軽量なリグレッションテストを追加する。
- 各性能変更に、ベースライン、期待効果、実際の効果、残る差分が記録されていること。
- 安価な測定手段があるのに、直感だけで性能パッチを着地させないこと。
フェーズ 5: 型、コントラクト、テストの強化
ユーザーと Plugin 作者が依存する境界点での正しさを高めます。- 緩いランタイム文字列を discriminated union または閉じたコード一覧に置き換える。
- 外部入力を既存の schema helper または zod で検証する。
- Plugin manifest、provider catalog、Gateway protocol メッセージ、config 移行動作の周辺にコントラクトテストを追加する。
- 互換パスは、起動時の隠れた移行ではなく doctor または repair フローに置く。
- テスト専用の Plugin 内部結合を避け、SDK facade と文書化された barrel を使う。
pnpm check:changed- 変更したすべての境界に対するターゲットテスト。
- lazy 境界、パッケージング、または公開サーフェスが変わる場合は
pnpm build。
フェーズ 6: ドキュメントとリリース準備
ユーザー向け docs を動作と一致させます。- 動作、API、config、オンボーディング、または Plugin の変更に合わせて docs を更新する。
- changelog エントリは、ユーザーに見える変更に対してのみ追加する。
- Plugin 用語はユーザー向けに保ち、内部 package 名は contributor に必要な箇所でのみ使う。
- リリース手順とインストール手順が現在のコマンドサーフェスと引き続き一致していることを確認する。
- 関連 docs が、動作変更と同じブランチで更新されていること。
- 該当する場合、生成 docs または API drift チェックが通ること。
- handoff に、スキップした検証とその理由が記載されていること。
推奨される最初のスライス
範囲を絞った Control UI とオンボーディングの作業から始めます。- 初回セットアップ、provider auth readiness、Gateway status、Plugin セットアップサーフェスを監査する。
- 使われていないアクションを削除し、失敗状態を明確化する。
- status 導出と config 永続化に対する絞ったテストを追加または更新する。
pnpm check:changedを実行する。
フロントエンドスキル更新
このセクションを使って、モダナイゼーション作業に付属するフロントエンド重視のSKILL.md を更新します。これを repo ローカルの OpenClaw スキルとして採用する場合は、まず .agents/skills/openclaw-frontend/SKILL.md を作成し、その対象スキルに属する frontmatter を維持したうえで、本文ガイダンスに以下の内容を追加または置き換えてください。