Model repeatedly violates explicit no-early-returns coding guideline in CLAUDE.md

Description

This is a re-submission of #25799, which was closed as a duplicate and later for inactivity without any maintainer acknowledgement or triage. The behavior remains present. The original issue is now locked and cannot be reopened.

The original report (#25799) included a full description, reproduction steps, and scoped examples. No information was requested by maintainers, and no resolution or workaround was provided.

---

When a project's CLAUDE.md contains an explicit coding style rule prohibiting early returns, the model consistently violates it when generating new code — despite the rule being clearly stated, with examples, and even stored in the model's own auto-memory file.

The Rule (from CLAUDE.md)

- **Avoid early returns and early loop exits**: Prefer positive logic (if-do) over negative logic (if-not-return/continue)
- **Success path first**: Code the expected/successful path, not the error path
- **Functions**: Use single return at end when possible
    - Good: `if (CreateSwapChain() && CreateImageViews()) { return true; } return false;`
    - Avoid: `if (!CreateSwapChain()) { return false; } if (!CreateImageViews()) { return false; } return true;`

What Happens

When asked to write new C++ functions, the model writes early returns like:

if (pid < 0)
{
    return false;
}
// ...
if (result < 0)
{
    return false;
}

Instead of the project's required style:

if (pid < 0)
{
    // fork failed
}
else
{
    // success path
}

return success;

Reproduction

1. Create a CLAUDE.md with the no-early-returns rule (with examples as shown above)
2. Also store the rule in auto-memory for reinforcement
3. Ask the model to write any new function with error handling
4. Observe: early returns are used despite the explicit rule

Scope of the Problem

In a single session, this affected 5+ functions across 4 files:

• RunProcess() — 3 early returns
• RunProcessWithOutput() — 4 early returns
• ProbeVideoDuration() — 2 early returns
• SendThumbnailReady() — 2 early returns
• WorkerThreadFunc() — 1 early return

The user had to point it out three separate times before all instances were fixed. The model acknowledged the rule existed each time but had already written violating code.

Likely Cause

General C++ training data overwhelmingly uses early returns as idiomatic "guard clause" style. This training prior appears strong enough to override explicit project-specific CLAUDE.md instructions during code generation, even when those instructions are loaded into context and acknowledged by the model.

Expected Behavior

Project-specific style rules in CLAUDE.md should be applied consistently during code generation, especially when:

• The rule is explicit and unambiguous
• Clear good/bad examples are provided
• The rule is reinforced in auto-memory

Environment

• Claude Code CLI
• Model: Claude Opus 4.6
• Rule location: both CLAUDE.md and auto-memory MEMORY.md

Reference

Original issue: #25799