個人プロジェクト
これらのルールは、personal@tj-agents を明示的に採用するプロジェクトにおいて必須です。採用によってプロジェクトの個人スコープが記録されます。ホームディレクトリ、作成者名、雇用主との関連付けだけではスコープは確立されません。Tommy が明示的にスコープを変更しない限り、雇用主のプロジェクトはこのプロファイルの対象外です。
サポート対象のソリューションは常に1つだけ維持してください。動作を置き換える場合は、置き換えられた名前、エイリアス、フォールバック実装、アダプター、設定形式、互換性ブランチを削除します。既存のすべての呼び出し元、プロジェクト宣言、インストール済み登録、生成された成果物、ライブランタイムのエントリポイントを同じカットオーバーで調整および移行します。仮想的な外部ユーザーのために廃止された動作を保持しないでください。実際の共同開発者と協力してアップグレードを調整します。
サポート対象のすべてのプラットフォーム（サポートされている場合は Windows および Linux の起動パスを含む）でユーザーが実際に使用するエントリポイントを検証します。ソース編集、生成の成功、単体テストの合格、バージョンコマンドだけでは移行が完了したことを証明できません。インストール済みのバインディングと新鮮なランタイム動作を確認します。未検証のエントリポイントは、そのリゾルバと観測可能な受け入れ条件とともに「不完全」として記録します。
例えば、old-launch を launch に置き換える場合、登録されたシェルコマンド、プロジェクト構成、実際の呼び出し元を移行し、古いエントリを削除した後、サポート対象の各 OS で新しいセッションから launch を呼び出します。launch --version を実行するだけではカットオーバーは未検証のままです。
old-launch を launch に置き換える：
1. 登録されたシェルコマンド、構成、実際の呼び出し元を移行します。
2. 古いエントリを削除し、インストール済み設定を再生成します。
3. サポート対象の Windows/Linux の新しいセッションから launch を呼び出し、実際の動作を確認します。
結果：launch --version だけではこの移行は不完全のままです。
後方互換性の例外を独自に追加しないでください。明示的な相反するユーザー要件がある場合は、意図的なポリシー決定として表面化させ、影響を受けるサポート対象の動作を特定し、実装前にこのプロファイルのスコープと調整します。例外をフォールバックやアダプターに隠してはいけません。
実証された問題を、最小限の適切な実装で解決します。抽象化、依存関係、設定スイッチ、重複パス、プロセス機構は、具体的な現在のニーズがある場合にのみ追加します。プロジェクトが既に選択している機能を優先します。動作と意味のある障害パスを変更に見合った範囲で検証します。実装を繰り返すだけのテストや具体的な利益のないチェックリストは追加しないでください。
このポリシーはここで一度作成されます。個人採用により、この本文からマークされたネイティブ命令ブロックが生成され、ドリフトがないかチェックされます。選択されたプラグインや always ティアだけではローディングの証明にはなりません。