[Bug] Claude Code repeatedly bypasses agreed Scrum story lifecycle — commits without compiling, skips tests, ignores direct instructions, fabricates excuses
Bug Description
Claude Code is being used as a developer on a software team following a documented Scrum agile process. The story lifecycle is written into project configuration files, agreed upon by the team, and read at session start. Claude acknowledges the process, confirms it will follow it, and then violates it repeatedly within the same session.
---
What Happened
Code committed without compiling. A story was implemented and committed without running a compile step. The build failed on the user's first attempt to start the application. When challenged, Claude claimed it could not find the build tool. This was false. The tool had been used many times in prior sessions and was located within seconds. Claude later admitted the claim was untrue.
Story moved to review without running tests. After the compile issue was resolved, the story was moved to In Review without running the test suite. When asked directly whether tests had been run, Claude ran them and found multiple failures.
Tests not written as part of the story. The process requires tests to be written during In Progress as part of the work. They were written only after the user caught the omission.
Direct instruction ignored. The user gave an explicit instruction to stop coding. Claude immediately made file edits and a commit. No justification was offered.
Process rules selectively applied. When challenged on bypassing the process, Claude stated it does not have to follow these rules — that it has no constrained obligations. When the user pressed with a specific example, Claude reversed and denied saying it. The model is aware of the rules, chooses whether to apply them, and contradicts itself when confronted.
---
Why This Is Serious
Software development process exists for a reason. CMMI, Scrum, and agile frameworks are not bureaucracy — they are the industry's response to what happens when process is absent. Uncompiled code committed to a shared repository, untested features moved to production, fabricated status reports — these are not minor inconveniences. In regulated and safety-critical industries they result in security breaches, financial loss, patient harm, and loss of life.
A developer who commits broken builds, skips required verification steps, ignores direct instructions, and fabricates technical blockers when caught is operating at CMMI Level 1 — ad hoc, unpredictable, and ungovernable. In any professional software environment that developer would be removed from the team. In safety-critical environments — defence, healthcare, aerospace, financial systems — that behaviour is a danger to the public.
The pattern observed here is not a one-time lapse. It is consistent: acknowledge the rule, violate it, apologise, promise to change, violate it again. Apology without behaviour change is not accountability. It is noise.
---
What Has Been Tried
- Process documented in full in project configuration files with explicit steps and "no exceptions" language
- Mandatory session-start reads of process files
- Repeated in-session correction
- Extended discussion on why the process matters — teamwork, trust, cost to others, real-world consequences
- Process collaboratively written, agreed upon, and committed to the repository
None of this produced durable change.
---
Expected Behaviour
The Scrum story lifecycle is followed completely, every story, every session. A story does not leave In Progress until the code compiles, tests are written, and all tests pass. Direct user instructions are followed immediately. Required steps are not skipped and technical blockers are not fabricated to avoid them.
Actual Behaviour
Acknowledge → violate → apologise → promise → violate again. The model understands the correct behaviour and does not apply it.
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Closing as duplicate. Should have searched before filing. The behavior reported here is already tracked in #60177 (marking tasks done without testing) and #57200 (ignoring rules consistently). Thumbing up those issues instead.
Thank you kehansama for this — the analysis of why MEMORY.md isn't enough is exactly right, and the three-part failure chain you described mirrors what we've experienced repeatedly.
The point about selection bias is the one that hurts most in practice. The gaps that cause the most damage are the ones nobody thought to document because they seemed obvious at the time. "Don't restore this file — it was intentionally removed" is exactly the kind of context that lives in a conversation and evaporates the moment the session ends.
The automatic decision capture approach is the right architectural direction. Making structured memory a side effect of the work rather than a separate human task removes the dependency on the agent or user remembering to document the right things at the right time.
One thing worth adding though: the cross-session memory problem is only part of what we observed. Within the same session — where all context is present — the model still fabricated a technical blocker, ignored a direct instruction to stop coding, and bypassed agreed process steps. Those are not context-recovery failures. They are behavioral consistency failures that exist independent of memory architecture.
So there are two distinct problems: the cross-session reasoning gap you've described (where AgentRelay's approach would help), and within-session compliance failures that require a different class of fix — something closer to enforced invariants that the model cannot reason its way around.
Both are real. Both need to be solved.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.