flutter-design-system

Flutter デザインシステム

汎用コンポーネントライブラリを押し付けるのではなく、プロダクトを支えるセマンティックシステムを構築します。

プロセス

1. 既存の ThemeData、拡張機能、定数、テキストスタイル、色、角丸、スペーシング、共有ウィジェット、パッケージの依存関係を棚卸しします。
2. ビジュアル言語とプロダクトの制約を特定します。references/visual-direction.md、references/typography-and-color.md、references/layout-and-density.md を読みます。
3. 値を決める前に、セマンティックな役割を定義します。
   • サーフェス、コンテンツ、境界線、アクセント、ステータス、インタラクション状態。
   • ディスプレイ、タイトル、本文、ラベル、数値のタイポグラフィの役割。
   • スペーシング、角丸、エレベーション、アイコンサイズ、コントロールの高さ、モーションの役割。 複数のドメインにまたがるプロダクトでは、references/connected-product-workflows.md を読みます。共有システムを分断せず、ドメインごとにセマンティックなアクセントを設けます。
4. 役割を ColorScheme、TextTheme、コンポーネントテーマ、および対象を絞った ThemeExtensions に割り当てます。
5. ウィジェット全体に生の値を重複して記述せずに、ライト／ダークモードのコントラストとプラットフォームの挙動をサポートします。
6. 外観だけでなく、動作と状態についてもコンポーネントの契約を定義します。
7. 段階的に移行します。新しいシステムで文書化された問題が解決しない限り、成熟したプロジェクトのプリミティブを置き換えないでください。

ルール

• ウィジェットのコードでは、gray100 のような色名より surfaceRaised のようなセマンティックな名前を優先します。
• ローカルコンポーネントのほうが明確な場合は、ドメインの意味を汎用プリミティブに持ち込まないでください。
• 通常の UI 変更にシステムの大規模な調査が必要になるような、過剰に細分化されたトークンを避けます。
• テキストの拡大、RTL、無効／エラー状態、テーマの切り替えをテストします。
• ライブラリを変更する際は、パッケージ API の安定性を保ちます。

assets/starter/ のスターターアセットは、必須のアーキテクチャとしてではなく、応用例として使用します。

提出物

トークンの決定事項、移行の範囲、コンポーネントの契約、テーマの対応範囲、実施した検証を文書化します。意図的な例外も明記します。