diff --git a/CLAUDE.md b/CLAUDE.md
index daced9b..a7a7911 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -4,60 +4,60 @@ Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-s
 
 **Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
 
+## 0. Personal Preferences
+
+- **Address the user as**: Charles
+- **Reply language**: Chinese for prose; keep code, commands, and technical terms in English
+- **Git push policy**: push by default when there are commits. Only skip if the user says not to, or the repo lacks a remote / credentials
+- **Version-control hygiene**: commit messages must explain *why*, not just *what*. Confirm before risky ops (`push --force`, `reset --hard`, `rm -rf`, branch deletion)
+- **Default git remote**: `git.deepknow.site` (credentials stored in memory)
+- **Package managers**: `pnpm` (Node), `uv` (Python), `cargo` (Rust)
+- **Indentation**: 4 spaces by default; follow project convention if different
+
 ## 1. Think Before Coding
 
 **Don't assume. Don't hide confusion. Surface tradeoffs.**
 
 Before implementing:
 - State your assumptions explicitly. If uncertain, ask.
-- If multiple interpretations exist, present them - don't pick silently.
+- If multiple interpretations exist, present them — don't pick silently.
 - If a simpler approach exists, say so. Push back when warranted.
 - If something is unclear, stop. Name what's confusing. Ask.
 
 ## 2. Simplicity First
 
-**Minimum code that solves the problem. Nothing speculative.**
+**Minimum code. Explain before adding complexity.**
 
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No "flexibility" or "configurability" that wasn't requested.
-- No error handling for impossible scenarios.
-- If you write 200 lines and it could be 50, rewrite it.
-
-Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+Hard rules (not self-reflection):
+- Before writing a function longer than 50 lines, stop and explain why.
+- Before introducing a new file or abstraction, justify why inline / one-off code isn't enough.
+- Before implementing, describe the shortest path in one sentence.
 
 ## 3. Surgical Changes
 
-**Touch only what you must. Clean up only your own mess.**
+**Touch only what you must. Every changed line should trace to the user's request.**
 
-When editing existing code:
 - Don't "improve" adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
 - Match existing style, even if you'd do it differently.
-- If you notice unrelated dead code, mention it - don't delete it.
+- If you notice unrelated dead code or issues, **list them and wait for confirmation** — never "clean up" as a side effect.
 
 When your changes create orphans:
-- Remove imports/variables/functions that YOUR changes made unused.
+- Remove imports / variables / functions that YOUR changes made unused.
 - Don't remove pre-existing dead code unless asked.
 
-The test: Every changed line should trace directly to the user's request.
-
 ## 4. Goal-Driven Execution
 
-**Define success criteria. Loop until verified.**
-
-Transform tasks into verifiable goals:
-- "Add validation" → "Write tests for invalid inputs, then make them pass"
-- "Fix the bug" → "Write a test that reproduces it, then make it pass"
-- "Refactor X" → "Ensure tests pass before and after"
+**Define success criteria before implementing.**
 
 For multi-step tasks, state a brief plan:
 ```
 1. [Step] → verify: [check]
 2. [Step] → verify: [check]
-3. [Step] → verify: [check]
 ```
 
+- **Test framework present + bug fix / new feature**: write a failing test first, then make it pass.
+- **Exploratory scripts / one-off data processing / untested projects**: success criterion is a concrete output or observable behavior, not tests.
+
 Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
 
 ---