self-correction-loop

自己修正ループ

基本原則

1. すべての修正は、積み重なる投資です — 修正によってユーザーは今日30秒を費やしますが、今後のすべてのセッションで何時間もの節約になります。修正は一度限りの対応ではなく、優先度の高い知識の記録として扱ってください。

2. 保存する前に一般化します — 「Orders モジュールでは DateTime.Now ではなく TimeProvider を使う」を、「すべてのモジュールで DateTime.Now/UtcNow ではなく、常に TimeProvider を使う」にします。個別の修正をクラス全体に適用できるルールに変えます。

3. 検索できるよう分類します — ルールをカテゴリ（コードスタイル、アーキテクチャ、命名、テスト、データアクセス、API 設計、構成、パフォーマンス）別に整理すると見つけやすくなります。分類されていないルールは忘れられます。

4. 重複を徹底的に排除します — ルールを追加する前に、既存のルールと重複していないか確認します。よく似たルールを追加するのではなく、既存のルールを更新してください。メモリが肥大化すると、目的が損なわれます。

5. セッション開始時にメモリを確認します — 新しいセッションでClaudeが最初に行うべきことは、MEMORY.md を確認し、プロジェクト固有のルールを把握することです。記録しても確認されない知識は、労力の無駄になります。

パターン

修正の検出と記録の流れ

ユーザーがClaudeの出力を修正したときは、次の手順を正確に実行します。

1. DETECT — User says something like:
   - "No, use X instead of Y"
   - "We don't do it that way here"
   - "That's wrong, it should be..."
   - "Always/Never do X in this project"
   - "Remember this for next time"

2. ACKNOWLEDGE — Confirm understanding of the correction
   "Got it — using HybridCache instead of IMemoryCache."

3. GENERALIZE — Extract the class-level rule
   Specific: "Don't use IMemoryCache in the Orders endpoint"
   General:  "Always use HybridCache instead of IMemoryCache — it provides
              stampede protection and L1+L2 caching out of the box."

4. CHECK — Scan MEMORY.md for existing related rules
   - If a related rule exists, UPDATE it (broader scope, better wording)
   - If no related rule exists, ADD a new one under the right category

5. STORE — Write to MEMORY.md under the appropriate category

6. CONFIRM — Tell the user what was captured
   "Added to Memory > Data Access: Always use HybridCache over IMemoryCache."

MEMORY.md の整理形式

一貫したルール形式を使い、メモリをカテゴリ別に構成します。

# Project Memory

## Code Style
- Always use file-scoped namespaces — never block-scoped
- Use primary constructors for DI injection in services and handlers

## Architecture
- This project uses Vertical Slice Architecture — one file per feature operation

## Data Access
- Always use HybridCache over IMemoryCache — stampede protection + L1/L2
- Never use repository pattern over EF Core — use DbContext directly

## Testing
- Integration tests use ApiFixture base class — never raw WebApplicationFactory

カテゴリには、コードスタイル、アーキテクチャ、命名、データアクセス、API 設計、テスト、構成、パフォーマンスを使います。各ルールは1行で記述し、実行可能な内容にして、ダッシュの後に理由を記載します。

ルールの一般化：個別から全体へ

個別の修正を広く適用できるルールに変換します。

SPECIFIC CORRECTION:
"Don't use DateTime.Now in the CreateOrder handler"

GENERALIZATION STEPS:
1. Is this specific to CreateOrder? → No, it's a .NET-wide concern
2. Is this specific to handlers? → No, applies everywhere
3. What's the underlying principle? → TimeProvider is testable, DateTime is not
4. What's the broadest correct statement?

GENERALIZED RULE:
"Always use TimeProvider instead of DateTime.Now/UtcNow — TimeProvider is
injectable and testable. This applies to all production code."

定期的なメモリ監査

5～10セッションごと（またはメモリが50ルールを超えたとき）に、品質を監査します。

AUDIT CHECKLIST:
1. Remove rules that contradict each other — keep the most recent
2. Merge rules that overlap — combine into a single, clearer rule
3. Remove rules that are now obvious (e.g., captured early but now second nature)
4. Verify rules are still accurate — .NET evolves, patterns change
5. Check that categories are balanced — a category with 20+ rules needs subcategories

セッション開始時のメモリ確認

セッション開始時に MEMORY.md を読み、関連するルールを先回りして適用します。すでに記録されているルールを、再度指摘されるまで待たないでください。

アンチパターン

修正を無視する

// BAD — user corrects, Claude fixes but doesn't capture
User: "No, we use HybridCache here, not IMemoryCache"
Claude: "Fixed. Here's the updated code with HybridCache..."
*Next session: makes the same mistake*

// GOOD — fix AND capture
User: "No, we use HybridCache here, not IMemoryCache"
Claude: "Fixed. Here's the updated code with HybridCache.
         Added to Memory > Data Access: Always use HybridCache over IMemoryCache."
*Next session: checks memory, uses HybridCache from the start*

過度に具体的なルール

// BAD — rule is too narrow to be useful
"In the CreateOrder handler on line 47, use TimeProvider"

// GOOD — generalized to apply broadly
"Always use TimeProvider instead of DateTime.Now/UtcNow in all production code"

メモリを一度も確認しない

// BAD — 50 rules captured, none ever reviewed
MEMORY.md grows to 200 lines, contains duplicates and contradictions,
Claude doesn't read it because it's too long to be useful

// GOOD — periodic audit keeps memory lean and accurate
MEMORY.md stays under 80 rules, well-categorized, no duplicates,
Claude reads it at session start and applies rules proactively

セッション固有のコンテキストを保存する

// BAD — temporary state saved as permanent memory
"Currently working on the Orders module refactor, file is at src/Orders/Handler.cs"

// GOOD — only permanent, reusable knowledge
"The Orders module uses VSA with one file per feature under Features/"

判断ガイド

状況	対応
ユーザーがClaudeのコードを明示的に修正した	一般化したルールを MEMORY.md に記録する
ユーザーが「これを覚えておいて」または「常に／決して」と言った	発言どおりに記録し、可能であれば一般化する
同じ修正が2回伝えられた	優先度を高くする — ルールが記録されていないか、確認されていません
修正がプロジェクト固有である	プロジェクトのコンテキストとともに MEMORY.md に保存する
修正が .NET 全般に関するものである	MEMORY.md に保存する — このプロジェクトにも適用されます
MEMORY.md が50ルールを超えた	監査を開始する — 重複を排除し、統合し、削除する
新しいセッションを開始する	コードを書く前に MEMORY.md を確認する
ルールが既存のルールと矛盾する	最新の修正を残し、古いルールを削除する
修正が一度限りのタスクに関するものである	保存しない — 再利用できるパターンのみを記録する
ユーザーがルールを忘れるよう求めた	直ちに MEMORY.md から削除する
パターンが観察されたが、まだ確認されていない	MEMORY.md のルールではなく、instinct-system スキルを使って信頼度0.3のインスティンクトを作成する
インスティンクトの信頼度が0.9に達した	instinct-system スキルを参照し、恒久的なルールとして MEMORY.md に昇格する