変更を簡略化する
変更の作者による編集パスです。PRを開く前に自分のブランチで実行し、大規模な修正をプッシュする前にも再度実行します。レビューに先行するものであり、レビューを置き換えることはありません。タスクのスコープと修正権限を継承します。レビューのみを要求された場合、修正ではなく所見を生成します。選択されたメンテナー・ワークフローが公開、レビュー、マージを管理します。
差分は提案です。 テストが通っていることは動作を示しますが、そのアーキテクチャや追加されたすべてのテストが必要であることを示すものではありません。
ルール: ルート AGENTS.md の「設計の優先順位」「単一責任者、完全な切り替え」「ランタイムとコードのセーフガード」「プロダクトと検証」の各セクション、および最も近いスコープの AGENTS.md。ステップ2と3では、すべてのルールを変更されたすべてのファイルに適用します。
1. 最小限で完全な修正を再導出する
ユーザーの成果目標と最新のスコープ、ターゲットマージベースに対する完全な差分、および保持された証拠を読みます。既に収集されたセッションコンテキストを再利用します。次に、以下の質問をします。
ベースから始めて、すでに存在する所有者を使用した最小限で完全な修正は何か？ このアーキテクチャをまだ導入するだろうか？
最初に、最も大きな追加モジュール、状態、アダプタ、テスト用足場を検査します。それらの直接の呼び出し元と関連する履歴を読みます。一見冗長に見える動作は、出荷済みの設定や以前のリグレッションを保護している可能性があります。スコープは、変更されたシステムと、それが置き換えるパスです。
変更されたすべてのハンクを、述べられた成果目標にトレースします。別の目標を果たすハンクはこの変更から外します。ドロップするか、独自のPRに移動します。
機械的でない変更行数をカウントします。約800行以上、または複雑なロジックの場合は約500行以上の場合は、最初にランディング可能な最小の一貫したステージに名前を付け、変更をそのステージにまで削減します。
欠陥、必要な不変条件、最小限で完全な修正をそれぞれ一文で述べることができ、残りのすべてのハンクがその修正に貢献している場合に完了です。
2. 不要なアーキテクチャを削除する
差分内で、サポートされている各簡略化を適用します。
- 単一の意思決定者。 反復される呼び出し側のポリシーを、その決定を所有する操作に移動します。影響を受ける呼び出し側を移行し、古い実装、エクスポート、修正ブランチを削除します。異なるトランスポートは、独自の配信契約を維持しながら、決定を共有できます。
- 既存の状態を優先。 新しいスキーマ、マネージャー、キャッシュ、結合表現に挑戦します。ライフタイム、権限、原子性、クリーンアップが適合する既存の所有者を再利用します。提案された移行が本当に不要な場合にのみ削除します。既存の設定と状態が更新後も機能し続ける移行は維持します。新しい状態は、それを意味するフィールドに属します。
- 冗長なパスを削除。 並列レンダラー、重複パーサー、結果を得るためだけに使用される偽のライフサイクル操作、呼び出し側が既に取得できる派生状態、単に転送または名前変更するだけのラッパーを削除します。古いものの周りにフォールバックモードを置くよりも、より単純な単一の表現を優先します。
- 最後に polish。 変更されたすべてのハンクにおいて、周囲のファイルのメンテナーが書くであろうものだけを保持します。
- 所有権、ライフサイクル、順序付け、制約を説明するコメント。
- 周囲のモジュールに適合し、実際の状態をガードするチェックと
try/catchブロック。 - キャストを紛らわす (
as any、as unknown as T、ワイド化してからアサート) 代わりに、実際の型。 - ドメインの意味を追加し、重複を削除し、制御フローを簡略化する変数とヘルパー。
- 名前付きの出荷契約と削除計画に裏付けられたシム、エイリアス、リトライ、フォールバック。
- 周囲のファイルに一致する命名、制御フロー、インポート、フォーマット。
要求された修正とサポートされている動作は維持し、提案の偶発的な設計は維持しません。実際のドメインの違いと正当化されたパブリック互換性は維持します。履歴 (git log -p -S <symbol>) によってパスの目的が不明瞭な場合は、それを保持して報告します。新しいプロダクトの決定、互換性を破る契約、無関係なクリーンアップ、破壊的なブランチの置き換えは、所有者向けの所見として報告します。
3. 失敗のためのテストを維持する
追加または変更された各テストグループとそのセットアップヘルパーについて、それが捕捉する明確に区別可能な観測可能な障害に名前を付けます。
実際の欠陥と明確な境界に対するリグレッションを維持します: 順序付け、キャンセル、古い権限、再起動、拒否、実際のエラー、影響を受けるコンシューマの違い。実際の境界を独立して保護する静的コントラクトガードを維持します。同じパスの重複ケース、モックのエコー、偶発的なフィールドコピーや言い回しのアサーション、静的に定義された値に対するアサーション、削除されたロジックがなくなったことだけを証明するテスト、廃止された実装のテスト、テストのみのプロダクションフックや足場を削除します。有用なケースは、既存の所有者スイートに統合します。
テストを削除しても、残っているアサーション、実際の境界のカバレッジ、ベースラインが弱まることはありません。
残っているすべてのテストグループに名前付きの障害がある場合に完了です。
4. より小さな変更を証明し、引き継ぐ
編集をバッチ処理し、変更されたコントラクトと影響を受けるコンシューマに対して、再現テストとフォーカスされたチェックを再実行します。入力が変更されていない証拠は再利用します。保存された再起動、アップグレード、トランスポートの主張には、該当する証拠が必要です。既存のワークフローが、より広範なチェックを選択します。
完全な差分が検査され、すべてのルールが変更された各ファイルに対して評決を持ち、サポートされている簡略化が適用され、置き換えられたパスが到達不能になり、影響を受ける動作にまだ証拠がある場合に完了です。既存の形状が正当化されている場合、変更なしも有効な結果です。削除ノルマではなく、純コード削減を目指します。
PR本文または既存のタスク証拠に報告します: 消えた責任または機構、まだ保護されている動作、マージベースに対するプロダクション/テストの差分。以前のリビジョンに対する削減は、変更全体の差分とは別にラベル付けします。必要な残りの成長または未解決の決定に名前を付けます。
その後、PRを開くか更新します。後続の修正後は、プッシュする前に、新しい変更とそれが触れる所有者のみを簡略化します。