コンソールUIツールキットを最新の資料どおりに直し、実際の画面で確かめる

## 古い版のやり方ではなく、今のリポジトリの資料に従う - プロジェクトが大規模な書き直しを明示している場合、名前が似ていても、以前に学んだパターンには互換性がない可能性があると考える。 - コードの設計、編集、レビューを始める前に、リポジトリの現行移行入門を読む。 - バージョン管理されたソース文書にある、現行の最小アプリケーションパターン、用語、ライフサイクル、互換性に関する注意事項を使用する。 - 記憶や旧バージョンの例よりも、プロジェクトの憲章、コントリビューションガイド、機械可読コンテキスト、階層化されたルールを優先する。 - 現行文書と事前知識が食い違う場合、両方の設計を混ぜず、現行リポジトリに従って相違点を記録する。 ## 作業前に、アプリ作りかツールキット本体の修正かを見分ける - 最初に、依頼をアプリケーション構築、ツールキットへのコントリビューション、バグ修正、視覚的な記録と検証のいずれかに分類する。 - 利用側のアプリケーションには、専用のアプリケーションガイドとパターン集を使用する。 - ライブラリの機能と不具合には、コントリビューター向けワークフローを使用する。 - 目に見えるUI変更と操作証拠には、記録ワークフローを使用する。 - ライフサイクル、ビュー階層、レイアウト、キャンセル可能なイベント、ドメイン用語に関わる領域を変更する前に、該当する主要概念の文書を読む。 - コントリビューター専用の内部機構をアプリケーション例に適用したり、アプリケーション向けの近道をコアライブラリの作業に適用したりしてはならない。 ## 編集の前とコードを書いた後に、チェックリストを通す - すべてのファイル編集前に、よくある間違いとローカル制約を確認するため、リポジトリの再確認チェックリストを実施する。 - コードの作成または変更後に、生成後検証チェックリストをすべて適用する。 - 書式、型宣言、構築構文、イベントパターン、Unicodeテキスト、コード配置、文書、テスト、診断、壊れやすい領域など、影響を受ける各トピックの詳細ルールを読む。 - 計画モードでは、実装手順、影響を受けるファイル、再利用できる箇所、検証方法を記載したMarkdown計画を、指定の計画ディレクトリに作成する。 - 計画を実際の範囲と一致させ、証拠によって実装経路が変わった場合は更新する。 ## 新しいテストは、基本は並列で動くスイートに入れる - 依存関係を復元し、一度ビルドして、そのビルドがまだ最新であれば再ビルドせずに対象を絞ったテストを実行する。 - 新しいテストは、原則として並列実行可能なスイートに入れる。 - プロセス全体の静的状態を避けられない場合に限り非並列スイートを使用し、その依存関係を説明する。 - 書き直しまたは削除が予定されている旧式スイートに、新しいカバレッジを追加してはならない。 - 反復中は単一のメソッドまたはクラスを選び、対象を絞った結果が通ったら関連プロジェクトまで広げる。 - 統合、ストレス、ベンチマーク、並列、非並列のどのカバレッジを選ぶか決める前に、テスト一覧を参照する。 ## 動いている端末の画面を記録して、UIの変更を確かめる - 実行中のインターフェースを観測せずに、視覚的な変更をリリースしてはならない。 - 疑似端末でアプリケーションを実行し、代表的なキー入力を注入して、描画されたセッションを記録する。 - 人間向けプレビューだけを信用せず、機械可読な記録をフレーム単位で読み、実際に表示された内容を検証する。 - レビュアーが外観や操作を評価する必要がある場合は、視覚成果物を添付する。 - 決定的なアサーションには、プロセス内入力注入、仮想時間、ドライバーレベルの画面キャプチャを使用する。 - 変更の影響範囲に応じて、レイアウト、フォーカス、入力処理、Unicode書記素、キャンセル、再描画の動作を検証する。 ## リポジトリで決められた空白と型の書き方に従う - 呼び出しとインデックス参照の周囲に必要な空白、波括弧の配置、空行の規則を維持する。 - ローカルガイドで許可された少数の組み込みプリミティブ型を除き、明示的な型を使用する。 - 必須とされている場合は、ターゲット型を利用した構築とコレクション式構文を優先する。 - ファイルごとにpublic型またはinternal型を一つだけ置く。 - コード配置規則に従って、メンバーとバッキングフィールドを並べる。 - 未使用のコールバック引数には、リポジトリ所定の破棄規約を使用する。 - リポジトリのフォーマッターと生成後チェックを実行し、スタイルの違いを見た目だけの問題として片づけてはならない。 ## 早めに抜ける書き方と、プロジェクトの用語をそろえて使う - ガード節と早期終了を優先し、成功経路を深くネストするのではなく条件を反転する。 - メソッド、コールバック、ループにも同じ早期終了規則を適用する。 - プロジェクトの包含関係を表す用語を一貫して使用し、一般的な関係用語は包含ではない参照のために取っておく。 - コメントを追加する前に、名前、型、構造によってコード自体が意図を説明するように書く。 - リファレンス、操作手順、API文書では、目標を述べてから直接的な命令形で操作を示す。 - 公開契約、キャンセル可能なワークフローの動作、Unicode書記素の処理、明白でない不変条件を、リポジトリ所定の文書形式で記述する。 ## カバレッジを減らさず、不具合が戻らないテストを足す - エージェントが生成したテストには、リポジトリで認められたエージェントとモデルの注釈を付ける。 - 変更を通すためにカバレッジを下げてはならない。 - 動作がプロセス全体の状態を明確に必要とする場合を除き、テストでアプリケーション全体を初期化しない。 - 分離されたセットアップ、決定的な入力、仮想時間、観測可能なアサーションを優先する。 - 各テストは、単にファイル名が最も近いスイートではなく、その状態モデルに合うスイートに配置する。 - ユーザーに見える不具合や動作に対する回帰カバレッジを追加し、関連する場合はレイアウトとイベント順序のケースも含める。 ## リポジトリのログ機能を使い、壊れやすい所や関係ない所を触らない - リポジトリのロギング、テストロギング、トレース機能を使用し、ライブラリやテストのコードからコンソールへ直接書き込んではならない。 - 壊れやすいと文書化されたサブシステムを、ついでの整理としてリファクタリングしてはならない。 - 対象を絞った機能や修正を実装する際に、無関係なコードを変更してはならない。 - コンパイラー、アナライザー、文書、テストの警告を新たに発生させてはならない。 - 完了を報告する前に、書式、用語、テストの配置、意図しない範囲拡大がないか差分を再確認する。 - 壊れやすい領域の変更が必須なら、必要最小限の編集に分離し、その領域固有の動作を検証してから、より広いテストへ進む。