diff --git a/CLAUDE.md b/CLAUDE.md
index 35ad4bb..c8cf8b2 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -52,5 +52,5 @@
 
 - 启动任何爬虫前，先跑 dry-run（`--limit 1 --no-write`），确认 schema 和速率正确。
 - 一次只推进 `plan.md` 的一个阶段，推进后更新 `log.md`。
-- 涉及数据删除（`rm` `data/`）必须先跟 Charles 确认。
+- 涉及数据删除（`rm` `data/`）必须先跟用户确认。
 - 新发现的反爬/法律坑录入 `docs/pitfalls.md`，不要只放在 log。
diff --git a/docs/sources/hf_bshada_open_schematics.md b/docs/sources/hf_bshada_open_schematics.md
index bf75e33..0012bd9 100644
--- a/docs/sources/hf_bshada_open_schematics.md
+++ b/docs/sources/hf_bshada_open_schematics.md
@@ -100,7 +100,7 @@ data/external/**/*.png      filter=lfs diff=lfs merge=lfs -text
 - **数据来源不透明**：作者没公开具体来源 repo 列表，去重时无法对齐到上游项目（可能与 oshwhub / KiCad repo 的部分项目重叠）
 - **KiCad 版本**：`.kicad_sch` 语法随 KiCad 5/6/7/8 大改，没有版本标注 → 下游若要 round-trip 需探测
 
-## 待 Charles 决策
+## 待决策
 
 1. 6.4 GB LFS 预算批准吗？
 2. 如果 oshwhub 放量 + HF 镜像并行，Gitea 实例磁盘要确认（之前已标记：需 `df -h` 看容量）
diff --git a/log.md b/log.md
index 91e90c5..e24388e 100644
--- a/log.md
+++ b/log.md
@@ -50,7 +50,7 @@ Charles 点名把 https://huggingface.co/datasets/bshada/open-schematics 纳入
 - `plan.md` 加 Phase 1.5
 - `README.md` 数据源表加一行
 
-**未下载**，等 Charles 拍板 6.4 GB LFS 预算。
+**未下载**，等拍板 6.4 GB LFS 预算。
 
 ---
 
@@ -102,7 +102,7 @@ Charles 点名把 https://huggingface.co/datasets/bshada/open-schematics 纳入
 - 新增：`crawlers/oshwhub/{__init__,__main__,crawler}.py`、`schemas/project.schema.json`、`docs/sources/oshwhub.md`、`pyproject.toml`
 - 修改：`.gitattributes`（缩窄到 `data/raw/**/files/**`）、`.gitignore`（移除 `data/raw/*` 排除）
 
-### 下一步建议给 Charles
+### 下一步建议
 
 1. 验收 10 个项目元数据质量（随机抽 2-3 条对照原站）
 2. 决定 Phase 1.4 放量目标（50？500？全量 12493？）
@@ -131,7 +131,7 @@ jsonschema 做两层校验：
 - `scripts/validate.py`
 - `pyproject.toml` 加 `jsonschema>=4.26`
 
-### 还是需要 Charles 决策
+### 待决策
 
 - 放量规模 —— 已提供实测数据：**median ≈ 110 GB，p90 上界 ≈ 660 GB，建议预算 150–180 GB**（见 `docs/sources/oshwhub_corpus_estimate.md`）
 - 是否需要抓 `u.lceda.cn` 的 EasyEDA 源 JSON（需登录，v0.1 跳过）
@@ -152,7 +152,7 @@ jsonschema 做两层校验：
 
 结果固化到 `docs/sources/oshwhub_corpus_estimate.md`，可随时重跑验证。
 
-### 给 Charles 的建议
+### 建议
 
 1. 存储预算定 **180 GB**（median + 15% buffer）
 2. Phase 1.4 前给 crawler 加 `--skip-ext` 开关滤视频
@@ -183,7 +183,7 @@ jsonschema 做两层校验：
   - 每个空目录放 `.gitkeep`
 - 首次提交 & 推送到 `origin main`
 
-**下一步建议给 Charles**：
+**下一步建议**：
 1. 拍板存储方案（本地盘 / Gitea LFS / 外部 OSS）—— 影响 Phase 1.4 放量时机
 2. 目标规模（1 万 / 10 万 / 全量）
 3. 决定是否保留二进制附件或只存 URL
diff --git a/plan.md b/plan.md
index 7c250e9..c293ef3 100644
--- a/plan.md
+++ b/plan.md
@@ -12,7 +12,7 @@
 
 1. 每个数据源先做一份 "可行性调研"（一页纸，放 `docs/sources/<site>.md`），明确：访问形式、速率限制、许可证分布、ToS 摘要、数据字段覆盖。
 2. 每个站点实现一个最小 MVP 爬虫，**单项目跑通** → 然后才全量化。
-3. 全量化之前先跟 Charles 对齐抽样结果与存储开销。
+3. 全量化之前先对齐抽样结果与存储开销。
 4. 所有站点输出统一到 `schemas/project.schema.json` 定义的结构，不要让下游消费者去适配 N 种 schema。
 
 ---
@@ -50,12 +50,12 @@
 ### 1.3 验收 ⏳
 
 - [x] 10/10 成功，产出符合 `schemas/project.schema.json`
-- [ ] **待 Charles**：随机抽查 2-3 条对照原站
+- [ ] **待人工**：随机抽查 2-3 条对照原站
 - [ ] `scripts/validate.py` 自动 schema 校验（未写，后续补）
 
 ### 1.4 放量（待决策）
 
-- [ ] Charles 定目标规模：50 / 500 / 5000 / 全量 12493
+- [ ] 定目标规模：50 / 500 / 5000 / 全量 12493
 - [x] 实测规模分布（见 `docs/sources/oshwhub_corpus_estimate.md`）：
   - median/proj 9 MB → 全量 **~110 GB**（合理预算）
   - p90 上界 **660 GB**
@@ -71,7 +71,7 @@
 **目标**：补 KiCad 原生生态，与 oshwhub (EasyEDA) 互补。
 
 - [x] 调研（见 `docs/sources/hf_bshada_open_schematics.md`）
-- [ ] **待 Charles 拍板** 6.4 GB LFS 预算
+- [ ] **待拍板** 6.4 GB LFS 预算
 - [ ] 目录：`data/external/huggingface/bshada--open-schematics/`
   - 整包镜像，**不**拆成 per-project 目录（10K+ 条记录）
   - 78 parquet shards + README + 封面 + 追加 `ATTRIBUTION.md`
@@ -147,7 +147,7 @@
 | GitHub API rate limit | Phase 2 慢 | 使用已登录 `gh` token；必要时换 fine-grained PAT |
 | 站点改版 | 爬虫失效 | 爬虫带 schema 自检，HTML 结构变化时告警 |
 
-**未决**（需要 Charles 定）：
+**未决**：
 - 数据存储方案：本地盘（够吗？）、Gitea LFS、或外挂对象存储？
 - 是否要保留图片/Gerber/STEP 的二进制，还是只存 URL？
 - 目标规模：第一版想要 1 万 / 10 万 / 全量？
diff --git a/scripts/estimate_size.py b/scripts/estimate_size.py
index 55550c0..84ec66c 100644
--- a/scripts/estimate_size.py
+++ b/scripts/estimate_size.py
@@ -1,8 +1,7 @@
 """Estimate full-corpus storage by sampling oshwhub detail pages (no downloads).
 
 从列表 API 取 N 个项目，解析每个详情页的 `attachments[]`，把 `size` 字段求和。
-不下载任何附件，仅抓 HTML 页，对服务器压力小；可用来快速给 Charles 一个
-放量存储估计。
+不下载任何附件，仅抓 HTML 页，对服务器压力小；可用来快速给出放量存储估计。
 
 Usage:
     uv run python scripts/estimate_size.py --pages 5 --sort hot