القائمة
バグ修正時のリグレッションテスト作成義務と、グローバル状態共有の禁止ルール。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | bug_fix_protocol |
| description | バグ修正時のリグレッションテスト作成義務と、グローバル状態共有の禁止ルール。 |
[!CAUTION] 最重要ルール: テストの Source of Truth は「現在のコード」ではなく「Blueprint（要件仕様）」である。
AIが「現在のコードの挙動」を正解としてテストを書くと、バグを保護するテストが出来上がる。 これは通常のバグより遥かに危険で、「テストがパスしている＝正しい」という誤った安心感を与え、バグの発見を困難にする。
1. AIが仕様にない挙動を勝手に実装する（例: 全IDにデモデータを返す）
2. テスト作成時、AIが「コードがこう動いているから正しい」と判断
3. テストが「バグの挙動」を期待値として検証するコードになる
4. テストがパスするのでバグが固定化される
テストのアサーションは blueprint.md / README.md の仕様から導出する
仕様が定義されていない挙動を実装する場合
既存テストを修正する場合
getCreatorData が全creatorIdにデモデータを返す実装に対し、data-flow.test.ts が「デモデータが返ること」をアサーションとして記述。テストがパスしたためバグが長期間放置された。getCreatorData の仕様（IDごとの分岐ルール）を blueprint.md に起案バグを発見・修正する際、以下の順序を必ず守る：
regression: was returning demo data for ALL IDs）npm run test で全テスト実行し、既存テストが壊れていないか確認する[!CAUTION] 「修正してからテストを書く」は禁止。 修正後にテストを書くと、テストが本当にバグを検出できるか保証できない。
// ❌ 危険: 全てのcreatorIdで共有される
let mockStats = { totalRevenue: 500 };
let mockSupportersMap: Record<string, any> = {};
// ✅ 安全: creatorIdごとに独立
let creatorDataStore: Record<string, CreatorInMemoryData> = {};
function getCreatorInMemory(creatorId: string): CreatorInMemoryData {
if (!creatorDataStore[creatorId]) {
creatorDataStore[creatorId] = { supportersMap: {}, stats: createInitialStats() };
}
return creatorDataStore[creatorId];
}
let でモジュールスコープに状態を持つ変数がないか？resetData() でグローバルストア全体がクリアされるか？マルチテナント（複数のエンティティIDが存在する）システムでは、以下を必ずテストする：
| 観点 | テスト内容 |
|---|---|
| データ分離 | entityAへの操作がentityBのデータに影響しないこと |
| 初期状態 | 新規entityは空（またはデフォルト）のデータで開始すること |
| 永続化の整合性 | writeしたデータがreadで正しく返ること |
| リセット | resetが全entityのデータをクリアすること |
| 特殊IDの分岐 | デモ用IDなどの特殊分岐が正しく動作すること |
mockSupportersMap と mockStats がモジュールスコープのグローバル変数で、全creatorIdで共有されていた。Record<creatorId, CreatorInMemoryData> 構造に変更し、creatorIdごとに完全分離。addSupportEvent for creatorA must NOT affect creatorB stats — 修正前は totalRevenue: 500 → 50500 で失敗。AI開発チームの役割定義。各エージェントの責務・行動指針・実行ステップを規定する。
AI同士のバトンタッチ（タスク委譲）とチェック体制。セッション開始時のPR確認から終了時のIssue作成までのルールを定義する。
コーディング規約。ESLint/TypeScript/React/Next.jsの品質基準と、AIエージェントがコミット前に守るべきルールを定義する。
Defines the standard format and rules for git commit messages in this project.
README.mdとblueprint.mdの役割分担と更新義務を定義するドキュメント管理ポリシー。
ロジックの変更とUIの変更に対するテスト戦略と基準を定義する。