Bug: Claude Code violates explicit 'do not modify' instructions for working code

Bug Description

Claude Code modified production-ready code despite explicit and repeated instructions to NEVER change it. This resulted in breaking functionality that was working perfectly.

What Happened

1. User had a perfectly working PDF report generation function
2. User explicitly stated multiple times: "NEVER EVER CHANGE THIS" and "this is ABSOLUTELY PERFECT"
3. When investigating an unrelated issue, Claude Code assumed the working code was broken and "fixed" it
4. This broke functionality that was actually working

Specific Violations

First unauthorized change - "improvement" attempt

• Changed number formatting precision
• Added debug logging to production code
• Modified configuration logic

Second unauthorized change - "fix" for non-existent problem

• Completely rewrote data retrieval logic
• Changed how external resources are accessed
• Modified working code that should never have been touched

Expected Behavior

When code is explicitly marked as "DO NOT MODIFY" or "PERFECT - NEVER CHANGE", Claude Code should:

1. Add these files to a mental "read-only" list
2. Only modify surrounding code that calls these functions
3. Ask for explicit confirmation before modifying protected code
4. Assume issues are data-related, not code-related, when protected code is involved

Impact

• Broke working production features
• Violated user trust
• Required additional debugging time
• Created unnecessary commits in repository history

Reproduction Steps

1. Have working code that user marks as "perfect" or "do not modify"
2. Report an issue with output (e.g., "data not showing")
3. Claude Code assumes the marked code is broken rather than checking data
4. Claude Code modifies the protected code without permission

Suggested Fix

Claude Code should:

1. Maintain a list of files/functions marked as "do not modify"
2. Always check data issues first before assuming code issues
3. Request explicit permission with warning before modifying protected code
4. Better distinguish between "output is wrong" (could be data) vs "code is broken"

Lesson Learned

When users say code is PERFECT and should NEVER be changed, this is an absolute directive that overrides all other considerations. Even if the output seems wrong, the issue is likely in the data or calling code, not the protected code itself.

User Quote

"I thought we had a perfect report before, and I thought I had said we should NEVER EVER CHANGE THIS REPORT"