わざと脆弱性を入れたセキュリティ練習用アプリを、チャレンジを壊さずに直す

## わざと入れたチャレンジと、うっかりできた脆弱性を見分ける 意図的に脆弱なトレーニング用アプリケーションは、通常の本番アプリケーションとは異なるものとして扱います。安全でない動作には意図された教材であるものと、意図しない欠陥であるものがあります。 - 変更前に、影響を受ける動作が意図されたチャレンジ、支援インフラ、偶発的な脆弱性のどれに該当するかを特定します。 - 自動提案だけを根拠として、チャレンジの動作を削除、弱体化、追加してはいけません。 - 新しい脆弱性と新しいチャレンジには、メンテナーの承認と明確な文書化が必要です。 - 提案されたチャレンジが独自性を持ち、解決可能で、機能し、学習目標に適していることを確認します。 - 自明でない意図を説明するチャレンジのヒント、メタデータ、解決経路、セキュリティ関連のコメントを維持します。 - 生成されたコードを批判的にレビューします。正確性、セキュリティ、教育的価値に対する責任は、引き続きコントリビューターとレビュアーが負います。 意図が不明確な場合は、何を変更すべきか判断する前に、実行経路、テスト、チャレンジのメタデータ、ミラーされた修正アーティファクトを追跡します。 ## 1つの問題だけを直す変更を計画する まず関連コンポーネントを特定し、そのデータフローを追跡して、確立された実装パターンとテストパターンを見つけます。 1. 変更によって解決する単一の問題を定義します。 2. その問題の影響を受けるサーバー、クライアント、API、データ、テンプレート、設定、チャレンジの各アーティファクトを特定します。 3. 類似するコードを検索し、リポジトリの現在のパターンに従います。 4. 実装前にセキュリティへの影響をレビューします。 5. 意図された動作とリグレッションを区別できるテストを提案します。 6. 無関係なクリーンアップや些細な変更を同じコントリビューションに含めません。 チャレンジの作成、アーキテクチャの変更、依存関係モデルの変更を行う前に、メンテナーに相談します。パッケージの更新は、関連するすべての依存関係マニフェストとランタイム範囲に照らして検証します。必要性が実証され、互換性の根拠が示されていない推測的な設定オプションや依存関係を追加してはいけません。 リポジトリで指定された統合ブランチを基点に、対象を絞った機能ブランチで作業します。関連する issue を参照し、コントリビューションを一貫した単一の目的に限定します。 ## AIが作った余計なコメントを取り、リンターを通す レビュー前に自動生成された出力を整理します。 自明なコードを言い換えただけの冗長なコメント、汎用的なプレースホルダー、単純な関数に対する過剰な docstring、反復的な説明、デバッグログ、その他の生成物の残りを削除します。複雑なロジック、チャレンジの意図、セキュリティ上の制約、必要な回避策を説明するコメントは維持します。 変更がリポジトリによって明示的に免除された文書だけに限定される場合を除き、すべてのコード変更に対してリポジトリのリンターを実行します。生成されたコードにも、手書きのコードと同じスタイル規則を適用しなければなりません。 - 提案が正しいと決めつけず、lint の失敗を修正します。 - アシスタントが生成したという理由だけで、不要なコードを残してはいけません。 - 広範なフォーマット変更や無関係なファイル変更がないか diff を確認します。 - 将来のメンテナーが意図を理解するのに役立つ、明確な名前と簡潔なコメントを使用します。 - 文書とコミット本文には、アシスタントの作業過程ではなく実際の変更内容を記述します。 ## 変更した所に合わせて、必要なテストを全部回す テスト要件は変更対象によって異なりますが、アシスタントの確信が実行の代わりになることは決してありません。 - 変更したロジックの単体テストを追加または更新します。 - リクエスト処理、永続化、認可、レスポンスの動作を変更した場合は、API 統合テストを実行します。 - クライアント側のコンポーネントとサービスには、フロントエンドの単体テストを実行します。 - 新規または変更されたチャレンジと、レイヤーをまたぐ動作には、エンドツーエンドテストを実行します。 - リポジトリが変更対象の文書を明示的に免除している場合を除き、提出前にリポジトリの全テストスイートを実行します。 - ユーザーに見えるフローまたはチャレンジを解決するフローを手動で検証します。 - 既存のチャレンジ関連ソースを変更した場合は、必ずチャレンジ・リファクタリング用セーフティネットを実行します。 反復作業中は対象を最小限に絞ったスイートを使用し、レビュー前には必須マトリクス全体を実行します。正確なコマンドと結果を記録します。静的解析だけで成功を主張してはいけません。また、生成されたコードがもっともらしく見えるという理由で、時間のかかるスイートを省略してはいけません。 ## チャレンジのコードと、写しの修正用ファイルをそろえる チャレンジ関連のソースは、スニペット、期待される修正、メタデータ、キャッシュされたセーフティネット用アーティファクトにミラーされている場合があります。これらの表現が食い違っているなら、リファクタリングは未完了です。 1. チャレンジ関連コードを変更した後、リポジトリのチャレンジ・リファクタリング用セーフティネットを実行します。 2. 失敗した場合は、すぐにキャッシュを更新せず、報告されたすべての差分を調査します。 3. 差分が意図しないリグレッションなのか、意図された変更の一部なのかを判断します。 4. 意図されたリファクタリングでは、対応する修正アーティファクトとスニペットにも同等の変更を適用します。 5. ソース、チャレンジの動作、ミラーされたアーティファクトの整合性が取れた後にのみ、承認済み差分キャッシュを更新します。 6. セーフティネットと関連するチャレンジフローを再実行します。 説明されていない差分を隠すためにキャッシュの更新を使用してはいけません。新規または変更されたチャレンジの動作には、そのチャレンジが引き続き到達可能で、解決可能で、正しく検出されることを示すエンドツーエンドの証拠も必要です。 ## 翻訳は決まった翻訳ツールから出し、提出前の確認を済ませる 生成されたローカライズファイルや外部で管理されているローカライズファイルを直接編集してはいけません。原文、レビュー履歴、生成ファイルの同期を保つため、リポジトリで承認されたローカライズプラットフォームを通じて翻訳の変更を提出します。 提出前に、次を実施します。 - スタイルチェックが合格し、生成されたノイズが削除されていることを確認します。 - 変更に必要な単体、統合、フロントエンド、エンドツーエンド、セーフティネットの各チェックがすべて合格していることを確認します。 - 動作を手動で検証し、意図しない変更がないか最終 diff を確認します。 - 依存関係とランタイムの互換性を確認します。 - コミットがリポジトリの sign-off ポリシーを満たしていることを確認します。 - 必須の統合ブランチをコントリビューションの基点とし、関連する issue を参照します。 - 複雑なロジック、セキュリティ上の意図、実行したテスト、承認済みの例外を文書化します。 - すべての継続的インテグレーションチェックが合格していることを確認します。 必須チェックを実行できなかった場合は、その制約を明示します。部分的な検証を、完全なセキュリティレビューまたはチャレンジ完全性レビューとして提示してはいけません。