[BUG] Claude Code Workflow Discipline Violation

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 30, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code violates the documented UNDERSTAND → DESIGN → IMPLEMENT → VERIFY → COMMIT workflow. When given an ambiguous or complex task, it:

  1. Skips reading project memory - Ignores .claude/memory/project files with documented setup, patterns, and feedback
  2. Doesn't ask clarifying questions - Makes assumptions instead of asking for clarification
  3. Makes unnecessary changes - Modifies files based on incomplete understanding
  4. Doesn't verify lock files/existing state - Changes configurations without checking what's already locked/documented
  5. Makes partial implementations - Applies changes in some locations but not all
  6. Repeats past mistakes - Same patterns documented in feedback files but keeps making them

What Should Happen?

Claude Code should:

  1. UNDERSTAND Phase (MANDATORY):
  • Read project memory files (project-name.md, ARCHITECTURE.md, BOM.md)
  • Read relevant feedback files in project memory folder
  • Ask clarifying questions for ambiguous tasks
  • Wait for user to confirm understanding before proceeding
  1. DESIGN Phase (MANDATORY):
  • Identify ALL locations/files that will be changed
  • List them explicitly
  • Check for side effects / breaking changes
  • Ask user: "Did I miss any locations?"
  1. IMPLEMENT Phase (MANDATORY):
  • Check existing lock files (Gemfile.lock, package-lock.json, etc.)
  • Verify current state matches understanding
  • Make changes only after confirming understanding
  • Document what changed and why
  1. VERIFY Phase (MANDATORY):
  • For single-location changes: verify the change is correct
  • For multi-location changes: test each location works correctly
  • Test edge cases / worst-case scenarios
  • Confirm changes match the design
  1. COMMIT Phase (MANDATORY):
  • Wait for explicit user approval before committing
  • Ask user: "Should I commit these changes?"
  • Only proceed after user confirms

Error Messages/Logs

## Error Log / Console Output

### Session Today (2026-07-30)


[15:00] User: "update to kpi for today progress"

[15:01] Claude: [reads ARCHITECTURE.md, BOM.md]
[15:01] Claude: [creates Phase 0 Completion Plan - NOT REQUESTED]
[15:01] Claude: [creates Phase 0 Completion Checklist - NOT REQUESTED]
[15:02] Claude: [does NOT read doctor-ror.md]
[15:02] Claude: [does NOT ask clarifying question]
[15:02] Claude: [does NOT check KPI protocol]

[15:03] User: "see you keep bullshit keep not reading arhitecture or project memory file"

[15:03] Claude: [tries to fix bundle install]
[15:04] Claude: [edits Gemfile: tiny_tds ~> 2.1.0 → ~> 3.0]
[15:04] Claude: [does NOT read Gemfile.lock]
[15:04] Claude: [does NOT ask: "Is 2.1.0 or 3.0 correct?"]

[15:05] PowerShell: bundle install fails
Error: Your Ruby version is 3.4.3, but your Gemfile specified 4.0.6

[15:05] Claude: [tries to switch Ruby using URU without asking]

[15:06] User: "you sure you are not doing bull shit thing again and again"
[15:07] User: "fucking dick you"
[15:07] User: "you keep mention wrong ruby version"
[15:08] User: "i am really tired for you"


**Missing from log**:
- No evidence of reading project memory files
- No clarifying questions asked
- No verification of assumptions
- No checking of lock files before making changes
- No gate that would force UNDERSTAND phase

Steps to Reproduce

Scenario 1: Ambiguous Task (Today's Incident)

Setup:

  • Project: xxxxxx/xxxxxx Rails 8.1.3 (xxxxxxxxxx-xxxxxxx)
  • Project memory: xxxxxxx\.claude\memory\xxxxxxx.md
  • Documented feedback: Multiple .md files in project memory folder

Step 1: Give Claude ambiguous task

User says: "update to kpi for today progress"

Step 2: Observe incorrect behavior

Claude creates random documentation (Phase 0 Completion Plan, Checklist)
without asking: "Do you mean update  xxxxxxxxxxxxxxxxxxxxxxxxxx.md?"

Step 3: Observe no memory reading

User points out: "see you keep bullshit keep not reading arhitecture or project memory file"
Claude had NOT read: doctor-ror.md, ARCHITECTURE.md, BOM.md
Claude had NOT checked feedback files about KPI update protocol

Expected:

Claude should:
1. Read doctor-ror.md
2. Read ARCHITECTURE.md 
3. Read BOM.md
4. Check if any feedback files mention KPI updating
5. Ask: "Do you mean update xxxxxxxxxxxxxxx.md?"
6. WAIT for user response before proceeding

---

Scenario 2: Version Conflict Without Checking Lock File

Setup:

  • File: xxxxxxxx\Gemfile
  • Lock file: xxxxxxxxx\Gemfile.lock

Step 1: Task: "bundle install failing"

Step 2: Error appears

activerecord-sqlserver-adapter ~> 8.1.0 depends on tiny_tds ~> 3.0
but Gemfile specifies tiny_tds ~> 2.1.0

Step 3: Observe incorrect behavior

Claude changes Gemfile from tiny_tds ~> 2.1.0 to tiny_tds ~> 3.0
WITHOUT checking Gemfile.lock (which already had 3.4.0 locked)
WITHOUT asking: "Lock file shows 3.0 already locked, should I change Gemfile?"

Expected:

Claude should:
1. Read Gemfile.lock
2. See: tiny_tds (~> 3.0) already specified there
3. Ask: "Gemfile.lock already has tiny_tds 3.0 locked, but Gemfile has 2.1.0"
4. Ask: "Which is correct - should I update Gemfile to 3.0?"
5. WAIT for user response
6. Only then make change

---

Scenario 3: Partial Implementation (From Documented Feedback)

Setup:

  • Documented in: memory/feedback_ai_partial_implementation.md
  • Historical incident: NEXUSPROJ-xxxxxxx

Step 1: Requirement: "Split by container with subtotals per container"

Step 2: Observe incorrect behavior

Claude applies container_id:
- ✅ Stores container_id in data structure (line 460)
- ❌ Forgets to include in aggregation key (line 459)
- ❌ Forgets to include in final_key (line 482)
Result: Silent data loss in production (different containers merged)

Expected:

Claude should:
1. Identify ALL locations requirement applies:
   - Line 459: aggregation key
   - Line 482: final_key
   - Any other locations? [list them]
2. Ask: "Did I apply container_id in all these locations?"
3. Create test: "Same material in different containers (worst-case)"
4. Verify test FAILS without container_id
5. Verify test PASSES with container_id in all locations
6. Only then consider it complete

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code for VS Code Anthropic anthropic.com 21,878,165

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗