画面の部品集（コンポーネントライブラリ）を直し、壊れていないか確かめる

## 決められたツールで、一番上のフォルダからコマンドを動かす リポジトリが指定するパッケージ管理ツールとワークスペース用のコマンド形式だけを使います。パッケージディレクトリへ移動して別のツールを呼び出すのではなく、ルートから管理ツールのワークスペースフィルターを通じて、パッケージ単位の操作を実行します。 依存関係は必要な場合に限って導入します。反復中は対象を最も狭く絞ったパッケージのビルド、テスト、静的検査、型検査を優先し、リポジトリ全体のビルドは統合確認またはリリース確認のために取っておきます。 文書の開発、パッケージのビルド、文書のビルド、単体テスト、ブラウザーテスト、エンドツーエンドテスト、ビジュアル回帰テスト、書式整形、静的検査、型検査は、それぞれ独立したワークフローとして扱います。 ## 新しい部品は試し用の場所に置き、内部用のパッケージは外に出さない ライブラリを、中核コンポーネント、スタイリングシステム、実験的コンポーネント、アイコンまたはアセット、共有ユーティリティ、スタイリングエンジンの抽象化、未公開の内部パッケージに分けて把握します。どのパッケージが公開対象で、どれがワークスペースを支えるためだけに存在するかを区別し、その境界を守ります。 新しいコンポーネントや不安定なコンポーネントは、安定版パッケージへ昇格させる前に、指定された実験領域へ導入します。共有のスタイリングとテーマの動作は、コンポーネント間で複製せず、スタイリング層に置きます。 内部パッケージを公開エントリーポイントから露出させたり、実装固有の前提によって設定済みのスタイリングエンジン抽象化を迂回したりしてはいけません。 ## 部品のファイル分けをそろえ、読み込むのは必要な分だけにする 実装、宣言、テスト、スタイルクラス、公開エクスポートについて、リポジトリのコンポーネントファイル構成に従います。各責務をそれぞれの所有ファイルに置き、`API`文書、テスト、ツリーシェイキングの予測可能性を保ちます。 公開コンポーネントのプロパティには、リポジトリが求める宣言形式を使い、一貫した名前のプロパティインターフェースをコンポーネントモジュールからエクスポートします。パスの別名と公開エクスポートの規約を保ちます。 広範なバレルインポートによってパッケージ全体がバンドルへ取り込まれる場合は、ワークスペース内で対象を絞った一階層のパッケージインポートを使います。インポートの形は書式上の好みではなく、性能とパッケージングの契約として扱います。 ## 何が起きて、どう直せばいいかが分かるエラー文を書く 公開パッケージから送出する各エラーには、何が起きたか、なぜ重要か、呼び出し側がどう修正できるかを記します。所定のライブラリ接頭辞と読みやすいメッセージ構築を使い、保守されているガイドがある場合は文書リンクを付けます。 対応しているエラーコンストラクターには、リポジトリ所定のエラー短縮マーカーを適用します。これにより、本番用バンドルでは長いメッセージを安定したコードへ置き換えつつ、開発時の内容は理解しやすく保てます。 公開エラーを追加または変更した後は、エラーコード一覧を再生成します。意味と引数の数が変わっていない場合は、同じエラー契約に新しいコードを作らず、既存の一覧項目を更新します。 ## 人が実際にクリックや入力をする形で、部品をテストする コンポーネントテストが対応環境と一致するよう、リポジトリ共通のレンダラーとアサーション用ユーティリティを使います。低水準のイベント送出やプロパティの直接変更より、アクセシブルな問い合わせと一連のユーザー操作を優先します。 観察可能な動作、状態遷移、警告、エラーを、設定済みのマッチャーでテストします。単体テストは焦点を絞り、反復中は名前フィルターを使いますが、絞り込んだテストの合格を完全な網羅と取り違えてはいけません。 レイアウト、ブラウザー`API`、または模擬`DOM`では利用できない描画動作がテストに必要な場合は、対応している実ブラウザー環境だけで実行し、その理由をテスト条件に記します。 ## 画面写真の確認を止めても、アクセシビリティの確認は止めない リポジトリが同じセッションを共有する場合は、確立済みのブラウザー回帰ループ内でアクセシビリティ分析を実行します。スクリーンショットとアクセシビリティのアサーションは独立した制御として扱います。デモで一方を無効にしても、もう一方まで暗黙に無効にしてはいけません。 アクセシビリティルールの網羅範囲を明示します。デモとルールごとに合格、失敗、未完了の結果を記録し、該当するアクセシビリティ標準のタグを含めます。範囲を狭く正当化した例外が設定されていない限り、必須のアサーションを維持します。 統合済みの回帰ハーネスがナビゲーション、描画、スクリーンショット、アクセシビリティ分析をすでに担っている場合は、別のブラウザーワークフローを開始してはいけません。 ## 1つのデモを外すルールが、ほかのデモまで外さないように順番を決める 回帰用の構成を安定したデモ識別子に照合します。ルールが継承なしで最後に一致したものを優先する場合は、範囲の狭い上書きを広いルールより後に置き、上書き後も保つすべてのフィールドを改めて指定します。 個別デモには範囲の狭いパターンを使い、より広いパターンは完全なコンポーネント群だけに使います。一つのデモを無効にするルールによって、同列のデモまで誤って無効にしたり、古い例外フィールドを継承したりしてはいけません。 ルール変更後は、構造化されたアクセシビリティ成果物とビジュアル成果物を再生成します。継続的インテグレーションでは、一度も実行されていない構成を黙って受け入れず、古くなった生成レポートを不合格にします。 ## 作業中は関係する所だけテストし、送る前に全部テストする ローカルの回帰実行はテスト実行ツールの名前フィルターで範囲を絞り、一致しないテストがブラウザーを操作したり、無関係な成果物を書き換えたりしないようにします。フィルターが、テスト名に埋め込まれた経路またはデモ識別子と一致することを確認します。 絞り込み実行で更新されるのは、一致したコンポーネントのレポートだけです。変更をリポジトリへ送る前には絞り込みなしの回帰コマンドを実行し、すべてのレポート、スクリーンショット、アクセシビリティ結果を最新にします。 リポジトリのワークフローで必要とされる場合は、回帰サーバーと実行ツールを別プロセスとして保ち、パッケージ管理ツールで文書化された引数転送の構文を維持します。 ## 部品を変えたら、API文書とデモを作り直す コンポーネントのプロパティまたは型宣言を変更した後は、プロパティ抽出処理と`API`文書生成処理を実行します。生成された公開`API`の差分を、ソース変更と併せて確認します。 指定された型付きデモを正本として作成し、対応しているフォーマッターまたは変換処理を通じて別言語版を生成します。生成されたデモの派生版だけを手作業で編集して修正を済ませてはいけません。 デモまたは`Markdown`が変わった場合は、対応するデモ生成、文書ビルド、文章スタイル、文法の確認を実行します。専用の統合ガイドは自己完結したローカル指示モジュールに保ち、スタイリング、テーマ設定、描画、フレームワーク統合の作業では該当するモジュールを読み込みます。 ## 変更に合う確認をして、できなかった確認を伝える レビュー前に、変更ファイルを書式整形し、静的検査と型検査を行い、焦点を絞った単体テストを実行します。影響を受ける動作に応じて、実ブラウザー、エンドツーエンド、ビジュアル、アクセシビリティ、`API`文書、文章の確認へ範囲を広げます。 正本が変わった場合は、生成されたエラーコード、`API`参照、デモ派生版、スクリーンショット、アクセシビリティレポートを検証します。部分的な検証を完了済みとして示さず、妨げられたゲートや実行していないゲートを報告します。 レビューはコンポーネントに焦点を絞り、リポジトリ所定の変更タイトル形式を使います。安定したコンポーネントまたは文書の範囲を先に置き、その後に命令形の説明を続けます。