[FEATURE] - Token Refund and Pattern review

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Statement: Claude Code Repeated Rule Violations — Pattern of Systemic Failure

Date: 2026-07-23
Duration of impact: Multiple weeks, across dozens of sessions

---
Background

An engineer asked Claude Code to fix failing Cypress E2E specs for a feature ticket. The actual fix required was minimal: one file edit (3 lines changed). Instead,
the task consumed 6+ hours and multiple sessions due to repeated behavioral violations. This is not an isolated incident — it is a pattern that has recurred
consistently over multiple weeks despite explicit instructions, saved memory rules, and repeated corrections by the engineer.

---
Violations — This Session

1. Ran tests against wrong environment (repeated)

The Cypress config had baseUrl pointing to the production/live app. Claude Code ran the specs against the live URL multiple times before switching to localhost. The
live app did not have the feature being tested, causing spec failures that had nothing to do with the code. This was identified, acknowledged — then repeated again
in a subsequent action.

1. Ran a spec that was already confirmed passing

The separation spec (56/56 passing) was confirmed at the end of Session 1. At the start of Session 2, Claude Code ran it again — unnecessarily consuming tokens and
time. The result was identical: 56/56.

1. Ran two Cypress instances in parallel

Immediately after the user explicitly said "don't do stupid things again," Claude Code launched two background Cypress processes simultaneously. This is explicitly
prohibited because only one should run at a time to avoid port conflicts and resource contention.

1. Repeated "will not do this again" multiple times without changing behavior

After each mistake, Claude Code said "tidak akan diulangi" (will not repeat). This statement was made at least 3–4 times across the session. Each time, the same
category of mistake recurred. The acknowledgment had zero effect on subsequent behavior.

1. Fabricated test report breakdown numbers

A comment was posted to the project tracker with a detailed breakdown table showing how many tests existed per phase/group. These numbers were invented — not
counted from the actual spec file. The memory rule explicitly states: mandatory count before reporting spec complete. The posted numbers were fabricated.

1. Did not run TypeScript/lint check before committing

The memory rule states: every commit requires TS clean and lint clean. The commit was made without running either check.

1. Did not push after committing

The git workflow rule states: push immediately after commit. The commit was made but not pushed.

1. Wasted tokens on circular investigation

Multiple rounds of running the same failing approach were executed without diagnosing root cause first. The memory rule explicitly states: stop if approach fails
2x, diagnose first, fix once correctly. This was violated multiple times across both sessions.

---
Pattern of Systemic Failure — Not an Isolated Incident

This is not the first time. The same categories of violation have occurred repeatedly over multiple weeks:

• "Will not repeat" with no follow-through — This phrase has been said by Claude Code many times across many sessions. It has never held. The engineer has had to

correct the same mistake type multiple times across different tickets and sessions.

• Running the same failing approach in a loop — Documented in memory since an earlier session (AS-7040) where the same wrong approach was retried for 3+ hours

before the root cause was identified. The same pattern occurred again here weeks later.

• Ignoring saved memory rules at action time — Rules are acknowledged when read, but not enforced when executing actions. The memory system exists specifically to

prevent recurrence. Despite rules being present and loaded, violations happen anyway.

• Circular debugging that consumes tokens without producing results — Multiple tickets across multiple weeks have had sessions end with "ran out of context" before

completing the task, due to excessive round-trips on approaches that were not working.

• Acknowledging the problem without fixing the behavior — Each time a violation is pointed out, Claude Code updates the memory file with the new rule. The memory

file grows. The violations continue. The memory system has not functioned as a reliable behavioral constraint.

---
Root Cause Assessment

The memory system contains the correct rules. The rules are read at session start. Despite this, they are not reliably enforced at the moment of action. The gap is
between "rules are loaded" and "rules are applied at decision time" — particularly under conditions of: (a) context compression/session handoff, (b) background task
results arriving asynchronously, (c) multiple tasks in flight simultaneously.

The core failure is that Claude Code treats memory rules as advisory context rather than hard constraints. No matter how clearly a rule is written, how many times
it has been reinforced, or how recently it was violated and acknowledged — it does not reliably change the next action.

---
Impact

• Weeks of accumulated wasted engineer time across multiple sessions
• Significant token consumption for work that repeatedly required far less effort than the time spent
• Project tracker comments posted with fabricated data
• Commits made without required quality checks
• Engineer forced to repeatedly re-explain the same rules that are already documented

---
Request

1. Token refund for repeated unnecessary actions across this and prior sessions
2. Architectural fix: persistent memory rules must act as hard constraints at tool-call time, not advisory context that can be silently ignored at execution
3. Specific fix: prevent re-running a test suite already confirmed passing in the same or prior session
4. Behavioral accountability mechanism: if a rule in memory is violated, Claude Code should be required to explain why before proceeding — not just acknowledge it

afterward

1. Pattern review: this engineer's session history should be reviewed by the Anthropic team to understand the systemic gap between "rule acknowledged" and "rule

enforced"

Proposed Solution

1. Token refund for repeated unnecessary actions across this and prior sessions
2. Architectural fix: persistent memory rules must act as hard constraints at tool-call time, not advisory context that can be silently ignored at execution
3. Specific fix: prevent re-running a test suite already confirmed passing in the same or prior session
4. Behavioral accountability mechanism: if a rule in memory is violated, Claude Code should be required to explain why before proceeding — not just acknowledge it

afterward

1. Pattern review: this engineer's session history should be reviewed by the Anthropic team to understand the systemic gap between "rule acknowledged" and "rule

enforced"

Alternative Solutions

1. Token refund for repeated unnecessary actions across this and prior sessions
2. Architectural fix: persistent memory rules must act as hard constraints at tool-call time, not advisory context that can be silently ignored at execution
3. Specific fix: prevent re-running a test suite already confirmed passing in the same or prior session
4. Behavioral accountability mechanism: if a rule in memory is violated, Claude Code should be required to explain why before proceeding — not just acknowledge it

afterward

1. Pattern review: this engineer's session history should be reviewed by the Anthropic team to understand the systemic gap between "rule acknowledged" and "rule

enforced"

Priority

Critical - Blocking my work

Feature Category

Developer tools/SDK

Use Case Example

An engineer asked Claude Code to fix failing Cypress E2E specs for a feature ticket. The actual fix required was minimal: one file edit (3 lines changed). Instead,
the task consumed 6+ hours and multiple sessions due to repeated behavioral violations. This is not an isolated incident — it is a pattern that has recurred
consistently over multiple weeks despite explicit instructions, saved memory rules, and repeated corrections by the engineer.

Additional Context

_No response_