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）、记忆修复前备份。
8.8 KiB
工作区整理与优化方案 · 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 天；收口必清本棒
三个关键收敛：
- 「待清理」这个概念取消 —— 要么进
归档/（要留），要么删（不留）。不留中间态。 tmp/加保留期纪律 —— 到期未动的棒目录自动进归档/tmp-<日期>/。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
执行前三件事（红线）：
- 先抢全局执行锁（
handoff-guard.sh --claim-exec） - 本次不碰
docs/、交付物/、CODEBUDDY.md、README.md、state.py（无问题项） - 每一项动用手前先出受影响清单，确认后再落
六、一句话结论
工作区的问题不在结构乱，而在没有回收机制：归档/、docs/、交付物/ 三处结构本已合理，真正失控的是 tmp/（1504 件、只增不减）、待清理/（承诺未兑现 5 天）和 6 份 33.7 MB 的 DB 副本（占总体积 43%）；另有两个失效脚本是文档库改名留下的工作区侧残留。先做 P0 可回收约 400 MB（占总体积 85%），再做 P2 加保留期纪律，才能不再堆积。