context-compaction-verification-and-recovery

Context Compaction Verification & Recovery Protocol

When to Use

Use this protocol when:

1. You've issued multiple patch, write_file, or create_file calls in a session
2. Context compaction has occurred (handoff summary mentions "completed" work)
3. User reports "偏翼唔到出嚟" (page doesn't render / doesn't work)
4. You suspect some tool calls were "spoken but not executed" — written in responses but not actually made

Core Insight

Tool calls that exist only in your reply text but weren't actually invoked will NOT have modified any files. This is the most common failure mode during complex multi-step sessions across context compactions.

Pattern: AI describes what it will do in markdown text blocks, the user says "繼續", and in the next turn the AI treats that description as already done without having made the actual tool calls.

Warning Signs of Compaction-Induced Drift

These patterns strongly suggest patches never landed:

1. Deferred tool calls — you say "first I'll X, then Y" in prose, then move on without actually calling the tools
2. "As mentioned above" syndrome — you reference code that was typed in your response but never written to disk
3. Excessive prose descriptions of code — if you're describing implementation in detail rather than doing it, check if tools were actually called
4. User says it doesn't render after you think you've finished — this is the ultimate signal

Prevention: The "Did the tool fire?" Check

Before any "繼續" transition, mentally scan: for every file I claim to have modified, did I actually see a patch() or write_file() success response in my tool output? If you only remember typing it in prose, it didn't happen.

Step 1: Audit — File Existence Check

Before any repairs, run a comprehensive audit:

# Find all NEW files that should exist
# Check each one with ls or search_files

Key files to verify:

• New utility files (utils/*.js)
• New page directories (pages/*/)
• New component files