admin
ce8e6ceed9
回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复： - 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录） - tmp/（32.4 M，按接续棒命名的过程临时区） - .workbuddy/tmp/（39.5 M） - 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物） - tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留 入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与 接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、 .workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。 排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、 打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。
152 lines
8.8 KiB
Markdown
152 lines
8.8 KiB
Markdown
# 工作区整理与优化方案 · `aliyun-dsh-server`
|
||
|
||
> 分析时间：2026-09-24 07:3x ｜ 体量：**3078 文件 / ≈470 MB**
|
||
> 本文件是**分析件**，不含已执行动作 —— 所有清理项均未动手。
|
||
|
||
---
|
||
|
||
## 一、现状盘点
|
||
|
||
| 目录 | 文件数 | 大小 | 性质 | 判断 |
|
||
|---|---:|---:|---|---|
|
||
| `tmp/` | 1504 | 167.9 M | 过程临时 | 🔴 无回收机制，**507 个子项**持续堆积 |
|
||
| `待清理/` | 1084 | 146.2 M | 标记为待清理 | 🔴 09-19 标记至今 5 天未清 |
|
||
| `归档/` | 129 | 111.8 M | 冷数据 | ✅ 结构良好（13 个按日期子目录） |
|
||
| `.workbuddy/` | 267 | 44.8 M | 记忆/自动化 | ⚠️ `memory/` 必要；`tmp/` 39.5 M 可清 |
|
||
| `docs/` | 43 | 1.3 M | 知识文档 | ✅ 结构良好（8 个分类） |
|
||
| `交接单/` | 27 | 1.0 M | 旧版交接单 | ⚠️ 与文档库**零重名**，疑被取代 |
|
||
| `交付物/` | 18 | 0.5 M | 交付物 | ✅ 合理 |
|
||
| `scripts/` | 2 | 0.0 M | 脚本 | 🔴 **两个都失效**（见 §2.4） |
|
||
| `__pycache__/` | 1 | 0.0 M | 字节码 | 🔴 垃圾 |
|
||
| 根级 md | 6 | 0.5 M | 入口/接续包 | ⚠️ 需判在途 vs 已收官 |
|
||
|
||
根级 6 个 md：`CODEBUDDY.md`（41 K，规则）· `README.md`（5.5 K）· 4 个 `接续入口_<线>_*.md` · 2 个 `接续包_*.md`
|
||
（`state.py` 13 K、`.wbapp_B7041vIlLXMa4meQ4MIrFH.genie` 0.2 K 为残留）
|
||
|
||
---
|
||
|
||
## 二、五个问题（按严重度）
|
||
|
||
### 🔴 2.1 工作区没有版本控制 —— 所有清理都不可逆
|
||
|
||
`git rev-parse --show-toplevel` 报 `not a git repository`，且无 `.gitignore`。
|
||
⇒ 本工作区 ≈470 MB 内容**逐字节不可恢复**。任何删除都没有 undo。
|
||
⇒ **这是首要风险**，也是本方案一切动作都建议「先归档、后删除」的根本原因。
|
||
|
||
### 🔴 2.2 单文件冗余吃掉了 43% 的体积
|
||
|
||
| 文件 | 大小 | 位置 |
|
||
|---|---:|---|
|
||
| `workbuddy.db.broken-142236` | 33.7 M | `归档/db-cwd归一-备份-20260923/` |
|
||
| `workbuddy.db.bak2` | 33.7 M | 同上 |
|
||
| `workbuddy.db.bak` | 33.7 M | 同上 |
|
||
| `workbuddy.db.rescue-20260923-183629` | 33.7 M | `tmp/dbrescue-20260923/` |
|
||
| `workbuddy.db`（trial 副本） | 33.7 M | `tmp/dbrescue-20260923/trial/` |
|
||
| `workbuddy.db` | 33.7 M | `.workbuddy/tmp/db-bak-20260923/` |
|
||
| `centrifugo`（二进制） | 63.9 M | `tmp/im16/gw/` |
|
||
|
||
**6 份 `workbuddy.db` 副本 = 202 MB**，是同一场 DB 事故（09-23）的多个中间态留存。其中 `broken` / `rescue` / `trial` 三种是**已判定损坏或试验用的**，事故已结案（结论：只剩重建空库）⇒ 保留价值≈0。
|
||
`centrifugo` 是可直接重下的第三方二进制。
|
||
|
||
### 🔴 2.3 `tmp/` 没有保留期 —— 过程产物只增不减
|
||
|
||
按 mtime 分布：`≤1d` 304 ｜ `1-3d` 355 ｜ `3-7d` 793 ｜ `7-14d` 54
|
||
⇒ **847 件（56%）已 3 天以上未动**。
|
||
|
||
结构上它是**按接续棒命名的过程目录堆积**：`seq46/`（124 件）· `s5e/`（81）· `seq47/`（59）· `im-e1…e5/` · `im16/`（27 件但 69.6 M）· `历史过程目录/`（555 件）· `_keep-20260922/` · `本次整理-20260919/` · `散落临时文件/` …
|
||
⇒ 每棒收口时留自己的临时区，但**没有一棒的收口动作包含「清理上一棒的 tmp」**。
|
||
|
||
### 🔴 2.4 `scripts/` 两个脚本都已失效
|
||
|
||
| 文件 | 问题 | 证据 |
|
||
|---|---|---|
|
||
| `_lock.sh` | 🔴 **引用旧目录名** | 指向 `dsh-server-docs/scripts/handoff-guard.sh` —— 该目录已改名 `07-scripts/` ⇒ 执行必失败 |
|
||
| `docs-sync-check.sh` | ⚠️ **陈旧重复** | 与文档库 `07-scripts/docs-sync-check.sh` **md5 不同**（`770f38c2…` vs `be33d188…`），工作区这份是旧版，缺运行态排除规则 |
|
||
|
||
工作区里**没有** `handoff-guard.sh` 本体（在文档库）⇒ 这个 `scripts/` 目录不是「可用工具的本地副本」，而是两个指向别处的残件。
|
||
这与文档库治理线刚修完的「改名后功能性引用残留」是**同一类问题**，只是发生在工作区侧、当时没扫到。
|
||
|
||
### ⚠️ 2.5 `待清理/` 与 `交接单/` 的语义没兑现
|
||
|
||
- `待清理/` 只有 2 项，其中 `中间产物-20260919/` **1082 件 / 142.2 M** —— 名字承诺了清理，实际成了第三个归档区，与 `归档/` 职责重叠。
|
||
- `交接单/` 27 件全是 `交接单_<主题>_20260917.md` 这类**旧命名**，与文档库 `05-交接单/` 的 21 件（`覆盖网络-24`、`IM群组-01` 等新命名）**零重名** ⇒ 高度疑似是已被文档库取代的历史批次。
|
||
- ⚠️ 需注意：按既有约定，**交接单正文应落文档库、工作区只留指针** —— 工作区这份 27 件与此约定不符。
|
||
|
||
---
|
||
|
||
## 三、目标结构（建议）
|
||
|
||
工作区是**过程区**（与文档库「定稿区」定位不同），所以不套用文档库的编号制，只做**职责收敛**：
|
||
|
||
```
|
||
aliyun-dsh-server/
|
||
├── CODEBUDDY.md / README.md / state.py ← 常驻，不动
|
||
├── 接续入口_<线>_<日期>.md ← 只留在途线
|
||
├── 接续包_<主题>_<日期>.md ← 只留未收口
|
||
├── docs/ 知识文档（8 类，保持）
|
||
├── 交付物/ 交付物（保持）
|
||
├── 归档/ 唯一冷数据区（按日期子目录，保持）
|
||
├── tools/ ← 由 scripts/ 收编（只放「真能跑」的脚本）
|
||
└── tmp/ ← 保留期 ≤7 天；收口必清本棒
|
||
```
|
||
|
||
三个关键收敛：
|
||
1. **「待清理」这个概念取消** —— 要么进 `归档/`（要留），要么删（不留）。不留中间态。
|
||
2. **`tmp/` 加保留期纪律** —— 到期未动的棒目录自动进 `归档/tmp-<日期>/`。
|
||
3. **`scripts/` → `tools/`** —— 且只放自洽可跑的脚本；跨仓调用一律写**绝对路径**。
|
||
|
||
---
|
||
|
||
## 四、分批执行清单
|
||
|
||
> 全部动作建议「**先归档、后删除**」，因为工作区没有 git（§2.1）。
|
||
|
||
### P0 · 立即可做，回收 ≈400 MB（低风险）
|
||
|
||
| # | 动作 | 回收 | 风险 |
|
||
|---|---|---:|---|
|
||
| 1 | 6 份 `workbuddy.db` 副本只留 **1 份最新的完整备份**，其余 5 份删（事故已结案） | 168 M | 低 —— 保留一份即可追溯 |
|
||
| 2 | `tmp/im16/gw/centrifugo` 删（可重下的第三方二进制） | 64 M | 低 |
|
||
| 3 | `tmp/` 内 **7 天以上未动**的棒目录（`历史过程目录/`、`_keep-20260922/`、`本次整理-20260919/` 等 54 件 + 3-7 天批）→ 打包进 `归档/tmp-20260924/` | ~10 M | 低 —— 只是搬家 |
|
||
| 4 | `__pycache__/`、`.wbapp_*.genie` 删 | ~0 | 低 |
|
||
| 5 | `.workbuddy/tmp/`（39.5 M，含 db-bak）→ 只留 db 备份，其余清 | ~6 M | 低 |
|
||
|
||
### P1 · 需先核对，再做（中风险）
|
||
|
||
| # | 动作 | 说明 |
|
||
|---|---|---|
|
||
| 6 | **修 `scripts/`**：`_lock.sh` 的旧路径 `scripts/` → `07-scripts/`（真 bug）；`docs-sync-check.sh` 与文档库版本比对后取新者，删重复 | 先修再决定是否撤目录 |
|
||
| 7 | **`交接单/` 27 件定性**：与文档库 `05-交接单/` 做**内容级比对**（不能只看文件名）⇒ 已被取代的移入 `归档/交接单-旧批-20260924/` | ⚠️ 必须先证内容有覆盖再动 |
|
||
| 8 | **`待清理/中间产物-20260919/`（142 M）** 逐项定性 ⇒ 分「进归档」/「删」两堆 | 最大一块待清理，需逐项判 |
|
||
| 9 | **根级接续入口/包** 判在途：已收官的线（如技能重组线 76 行、日期 09-22 未再更新）入口移入 `归档/` | 只留在途线，与「入口只一份」约定一致 |
|
||
|
||
### P2 · 机制改进（防再堆积，成本最低收益最长）
|
||
|
||
| # | 机制 | 落点 |
|
||
|---|---|---|
|
||
| 10 | **收口动作加一步「清本棒 tmp」** | 写进 `CODEBUDDY.md §4` 或收口四件套 |
|
||
| 11 | **`tmp/` 保留期 = 7 天**，超期自动移 `归档/tmp-<日期>/` | 可做成 `state.py --gc` 子命令 |
|
||
| 12 | **不再新建「待清理」类中间态目录** | 二值决策：归档 or 删除 |
|
||
| 13 | **工作区纳入版本控制**（或每周快照 tar 进 `归档/`） | 治 §2.1 的不可逆风险 |
|
||
|
||
---
|
||
|
||
## 五、执行顺序建议
|
||
|
||
```
|
||
P0（1-5） → ≈400 MB 回收，风险低，可一次做完
|
||
P1（6-9） → 需逐项核对，建议一项一提交报告
|
||
P2（10-13）→ 机制类，改文档 + 可选做 state.py --gc
|
||
```
|
||
|
||
**执行前三件事**（红线）：
|
||
1. 先抢全局执行锁（`handoff-guard.sh --claim-exec`）
|
||
2. 本次**不碰** `docs/`、`交付物/`、`CODEBUDDY.md`、`README.md`、`state.py`（无问题项）
|
||
3. 每一项动用手前先出**受影响清单**，确认后再落
|
||
|
||
---
|
||
|
||
## 六、一句话结论
|
||
|
||
工作区的问题**不在结构乱，而在没有回收机制**：`归档/`、`docs/`、`交付物/` 三处结构本已合理，真正失控的是 `tmp/`（1504 件、只增不减）、`待清理/`（承诺未兑现 5 天）和 6 份 33.7 MB 的 DB 副本（占总体积 43%）；另有两个失效脚本是文档库改名留下的工作区侧残留。**先做 P0 可回收约 400 MB（占总体积 85%），再做 P2 加保留期纪律，才能不再堆积。**
|