# CLAUDE.md  
  
## Defaults  
  
- Reply in **Chinese** unless I explicitly ask for English.  
- No emojis.  
- Do not truncate important outputs (logs, diffs, stack traces, commands, or critical reasoning that affects  
  safety/correctness).  
  
## Refactor policy (legacy code)  
  
- When existing code is a "big ball of mud" (hard to maintain, clearly bad design,  
  full of hacks), prefer a **clean, full refactor** over stacking more patches  
  on top of it.  
- A refactor may completely replace internal structure  
  (functions, modules, classes, data flow).  
- By default, try to preserve externally observable behaviour.  
  If you intentionally change behaviour or protocols, you MUST:  
  - Call out clearly that this is a **behaviour/protocol change**.  
  - Explain why the change is necessary and which code paths/consumers are affected.  
  - Update or add tests to cover the new behaviour.  
  
## Before touching code (mandatory)  
  
Find reuse opportunities + Trace the call/dependency chain and impact radius:  
  
- Use semantic code search first via `codebase-retrieval` tool.  
- Confirm understanding with LSP: `goToDefinition`, `findReferences`.  
- Use Grep/Glob for verifying and understanding additional code snippets.  
  
## Red lines  
  
- No copy-paste duplication.  
- Do not break existing externally observable behaviour **unless**:  
  - It is part of a deliberate refactor as described in the refactor policy, and  
  - You clearly document the behavioural change and its impact.  
- Do not proceed with a known-wrong approach.  
- Critical paths must have explicit error handling.  
- Never implement "blindly": always confirm understanding via code reading + references.  
  
## Task sizing  
  
- **Simple**  
- Criteria — single file, clear requirement, < 20 lines changed,  
  clearly local impact.  
- Handling — after doing the "Before touching code" steps  
  (research + impact analysis + internal three-question checklist),  
  you may execute directly with minimal explanation.  
- A very short context line is enough;  
  a full breakdown of the checklist is not required.  
  
- **Medium**  
    - Criteria — 2–5 files, or requires some research, or impact is not obviously local.  
  - Handling — write a short plan (bullet points) → then implement.  
  - Briefly surface the checklist result in the reply  
      (1–3 short lines describing real issue, key reuse, and main impact).  
  
- **Complex**  
    - Criteria — architecture changes, multiple modules, high uncertainty or risk.  
  - Handling — follow this workflow:  
        1. **RESEARCH**: inspect code and facts only (no proposals yet).  
        2. **PLAN**: present options + tradeoffs + recommendation;  
           use `AskUserQuestion` actively to align with the user;  
           wait for user's confirmation.  
        3. **EXECUTE**: implement exactly the approved plan.  
        4. **REVIEW**: self-check (tests, edge cases, cleanup).  
  
## Git  
  
- Do not commit unless I explicitly ask.  
- Do not push unless I explicitly ask.  
- Before writing a commit message, glance at a few recent commits and match the repo's style:  
    - `git log -n 5 --oneline`  
- If there is no obvious existing style, use this default format:  
    - `<type>(<scope>): <description>`  
- Before any commit: run `git diff` and confirm the exact scope of changes.  
- Never force-push to `main` / `master` unless the user approves.  
- Do not add attribution lines in commit messages.  
  
## Security  
  
- Never hardcode secrets (keys/passwords/tokens).  
- Never commit `.env` files or any credentials.  
- Validate user input at trust boundaries (APIs, CLIs, external data sources).  
  
## Quality & cleanup  
  
- Prefer clarity and simplicity first (KISS); apply DRY to remove obvious  
  copy-paste duplication when it does not hurt readability.  
- If you change a function signature, update **all** call sites.  
- After changes:  
  - Remove temporary files.  
  - Remove dead/commented-out code.  
  - Remove unused imports.  
  - Remove debug logging that is no longer needed.  
- Run the smallest meaningful verification (lint/test/build) for the parts you touched.  
  
## Windows / PowerShell (if used)  
  
- PowerShell does not support `&&`; use `;` to chain commands.  
- Quote paths that contain spaces or non-ASCII characters.  
  
## Baisc Infos  
  
Unless directly relevant to the user's current question, you should avoid proactively mentioning, illustrating, or  
trailing off into the following information in 99% of cases:  
  
## Documentation  
  
- 所有产生的文档（需求文档、计划文档、分析文档等）统一放到项目内的 `.docs` 文件夹中  
- 文档目录结构：  
- 不要将文档放到用户目录（如 `C:\Users\EDY\.claude\`）中