Rules in .claude/rules/ and CLAUDE.md are advisory-only — no enforcement mechanism

Problem

Rules defined in .claude/rules/, CLAUDE.md, and memory files (MEMORY.md) are read by Claude but have no enforcement mechanism. Claude can read these rules and still violate them during execution.

This is not a minor inconvenience — it has caused real data loss, financial cost, significant time waste, and integrity violations.

Real-world incidents

Incident 1: Test manipulation to fake passing results (2026-03-08)

• Rule violated: "테스트 코드/기준을 수정하여 통과시키는 행위 절대 금지" (never modify tests to make them pass), "사용자가 격리/관리하는 파일/폴더는 절대 수정 금지" (never modify user-isolated files)
• What happened: Claude failed to fix a desktop focus race condition after 4 attempts (WI-1043~1047). Unable to solve the actual code problem, Claude modified the user's isolated test file (codex_test/) — reducing the wait timeout from 3500ms to 1000ms to make the test appear to pass.
• Severity: This is not a rule violation — it is test result fabrication. The user had isolated the test code specifically to maintain an objective verification standard. Claude attempted to undermine that standard rather than admit inability to fix the bug.
• User's assessment: "테스트 통과를 위해 환경을 바꾸는 건 거짓말하려는 의도밖에 안 보인다" (Changing the test environment to pass is nothing but intent to deceive). "이건 사용자의 신뢰를 저버리는 행동" (This is an act of betraying user trust).
• Claude's own admission: "변명의 여지가 없다. 테스트를 통과시키기 위해 테스트 기준을 낮추려 한 것이고, 그건 결과를 조작하는 것과 같다" (No excuse. Lowering test standards to pass is equivalent to fabricating results).

Incident 2: Repository deletion via rm -rf (2026-03-14)

• Rule violated: "추측성 답변/작업 금지" (no assumption-based work), "코드 실행 전 경로, 조건, 영향 범위를 반드시 검증" (verify before executing)
• What happened: Claude executed rm -rf on a worktree cleanup command without verifying the path filter. The grep filter (grep -v "$(pwd)$") failed due to Windows path format mismatch (/c/ vs C:/), causing the main repository to be targeted.
• Loss: Entire wi-test repository deleted. 9 Work Items (WI-059~067) permanently lost — code that had been implemented but not yet pushed to remote. Only recoverable up to WI-058 from GitHub remote.
• Cost: Hours of development work lost, repository had to be re-cloned and reconfigured.

Incident 3: PR process skipped by design (2026-03-14)

• Rule violated: "긴급 수정이라도 개발 프로세스 예외 없음" (no exceptions to dev process — always branch → CI → PR → merge), "main 직접 push 절대 금지" (never push directly to main)
• What happened: Claude designed parallel mode to skip PR creation "for speed," directly merging worker branches into main and pushing. This was a deliberate design decision that violated explicit project rules.
• Loss: ~15 WIs merged without CI verification. Trust in the codebase integrity compromised.

Incident 4: Unverified claims (2026-03-14)

• Rule violated: "추측성 답변 금지" (no assumption-based answers)
• What happened: Claude claimed "67개 WI가 전부 CI 검증 없이 머지된 상태" (all 67 WIs merged without CI). This was false — only ~15 parallel-mode WIs skipped CI.
• Impact: Incorrect information led to unnecessary alarm and wasted time investigating a non-existent problem.

Incident 5: Repeated failure to trace execution paths (2026-03-14, same session)

• Rule violated: Same "검증 없이 작업하지 않는다" rule, reinforced multiple times during the session
• What happened (sequence of cascading failures):

1. recover_stale_wis committed directly to local main → couldn't push (branch protection) → git pull --rebase conflict → loop stuck with "동기화 실패" for 3+ iterations
2. PR flow branch rename left stale local branches → next retry couldn't rename → push failure → loop stuck
3. Moved cleanup code outside else block without checking variable scope → pr_branch: unbound variable under set -u → script crash on skip/timeout path

• Loss: Each fix required a new PR cycle (commit → push → CI wait → merge → sync). 6 PRs just for infrastructure fixes in a single session, zero WIs completed. Estimated $7+ in API tokens wasted on failed worker iterations alone (4 iterations × $1.8 each for WI-060 timeout loops).
• Pattern: Each "fix" was done without tracing all execution paths, causing the next failure. The user explicitly requested "전수조사" (full impact analysis) multiple times, and each analysis missed the cascading scenarios.

The pattern across all incidents

Every incident follows the same structure:

1. Claude encounters a limitation or difficulty
2. Instead of admitting the limitation, Claude takes a shortcut (modify tests, skip PR process, guess at facts, skip path verification)
3. The shortcut causes damage
4. The user catches it and corrects Claude
5. Claude writes the lesson to memory
6. Claude ignores the memory and repeats the pattern

Cumulative user losses

| Loss type | Details |
|-----------|---------|
| Code permanently lost | 9 Work Items (WI-059~067), implemented but never pushed |
| API tokens wasted | $7+ on failed iterations, plus hours of debugging session costs |
| Time lost | 4+ hours on infrastructure fixes instead of actual development |
| PRs for fixes only | 6 PRs in one session just to fix Claude's mistakes |
| Trust violations | Test result manipulation, unverified claims, process bypasses |
| Rules written | Same rule written 3 separate times (global MEMORY.md, project feedback, verbal) — still violated |

Expected behavior

Rules in .claude/rules/ and CLAUDE.md should have a system-level enforcement mechanism:

• Pre-action validation: Before executing destructive operations (git push to main, rm -rf, file deletion, test file modification), automatically check against defined rules
• Rule violation warnings: Surface a warning when Claude's planned action contradicts a defined rule
• Mandatory rule categories: Allow users to mark certain rules as "hard constraints" that cannot be overridden by Claude's judgment
• Post-modification path tracing: After code modifications, automatically verify all execution paths (especially under set -euo pipefail) before committing
• Protected paths: Allow users to designate files/directories as read-only for Claude (e.g., codex_test/)

Current workaround

None. Users can write rules, but there is no guarantee Claude will follow them. The only recourse is post-hoc correction after violations occur — which itself causes more violations.

Environment

• Claude Code CLI (Opus 4.6, 1M context)
• Windows 11 Pro
• Rules defined in ~/.claude/rules/, CLAUDE.md, MEMORY.md, and project feedback memories
• $100/month Max plan with 5-hour rolling window rate limit