[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:
- Skips reading project memory - Ignores .claude/memory/project files with documented setup, patterns, and feedback
- Doesn't ask clarifying questions - Makes assumptions instead of asking for clarification
- Makes unnecessary changes - Modifies files based on incomplete understanding
- Doesn't verify lock files/existing state - Changes configurations without checking what's already locked/documented
- Makes partial implementations - Applies changes in some locations but not all
- Repeats past mistakes - Same patterns documented in feedback files but keeps making them
What Should Happen?
Claude Code should:
- 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
- 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?"
- 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
- 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
- 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_