admin
7bd1151c67
交接单按归属约定（正文落文档库、工作区只放指针）归档至 归档/交接单-20260924-归档/，含逐件判定 README： - 16 件已被文档库正式版取代（T09–T21 + 覆盖网络-24/25/26） - 4 件主题已被覆盖网络线入口汇总 - 7 件历史接续包/规划件 CODEBUDDY §9：收口清本棒 tmp、tmp 保留期 7 天、禁「待清理」中间态、 工作区入库只放文档与文件、不保留脚本副本、>60 KB 单文件须逐个判。
182 lines
30 KiB
Markdown
182 lines
30 KiB
Markdown
# 2026-09-24 · 工作日志
|
||
|
||
## 00:0x 彻底修复「重复会话分组」（会话 `eb52cfe8` · 承接 09-23「检查是否还会出现重复分组」）
|
||
|
||
**判定：已修**。根因 = 工作区目录改名（`E:\ProgramData\AI技能` → `E:\ProgramData\AIProject`）后，数据库与各处硬编码未同步。
|
||
|
||
### 一、代码级机制取证（本次新增 · **推翻 09-23 冻结的 cwds 规则**）
|
||
|
||
- **分组/工作区列表实现** = `main/server.js` → `DesktopWorkspaceRepo.list()`：
|
||
`const k = t.toLowerCase(); if (seen.has(k)) return;` ⇒ **去重键 = `path.trim().toLowerCase()`，⛔ 不统一斜杠**。
|
||
⇒ **斜杠风格不同即裂成两个同名分组** —— 旧规则「`cwds` 只写反斜杠」正是 09-23 裂组的根因。
|
||
- **正确字面 = 实测 `sessions.cwd`** = `E:/ProgramData/AIProject/aliyun-dsh-server`（**正斜杠**）。
|
||
`workspaces.path` 是 `generate()` 产物（`path.normalize` + 小写），与分组键**不同源**；其小写来自 `normalizeWorkspacePathForCompare()`（`normalize` → `\`→`/` → `toLowerCase`），仅用于 label 匹配 ⇒ ⛔ 旧判据「以 workspaces.path 为真源」不成立。
|
||
- **automation 会话的 cwd = `automations.cwds` 逐字复制**（`automation_runs.runs_json[].cwd` 与 `cwds` 完全一致，第 12–15 棒实测）。
|
||
- `workspace-display-names.json`（displayName store）当前为空 ⇒ 分组显示名不来自它。
|
||
|
||
### 二、已落地
|
||
|
||
1. **DB 修复**（备份 = `.workbuddy/backups/workbuddy-20260924-000102.db`，用官方 `backup()` API，`integrity=ok`）
|
||
- `sessions.cwd` **205 行**归一（165 条 E 盘旧根 ＋ 11 条 D 盘旧根 ＋ 其余子目录）
|
||
- `workspaces.path` **9 行**归一（E 盘与 D 盘指向同一目标的两行合并）
|
||
- 僵尸条目 **2 行**删除（`AI技能\ade-orca`、`AI技能\dsh-laijing-github` —— 目标目录已不存在）
|
||
- 改后 `PRAGMA integrity_check = ok`；**两种分组口径下分组数均为 53**（斜杠风格已统一，重复分组消失）
|
||
2. **硬编码修正（9 处 / 8 个文件）**：`state.py`（`WS`）· D 盘 `scripts/preflight-lock.sh`（`WS_ROOT` 默认值）· **4 个接续入口**的工作区声明 · 工作区 `.workbuddy/memory/MEMORY.md` · 用户级 `~/.workbuddy/MEMORY.md`（cwds 规则重写 ＋ 2 处路径）
|
||
- 验证：`state.py` 现指向 `E:/ProgramData/AIProject/aliyun-dsh-server`，「今日日志」判定恢复正常
|
||
3. **`automations` 未动（合规原因）**：9 条全部在 09-23 23:32 恢复流程被打上 `deleted_at`（墓碑）⇒ `automation_update` 报 `Automation not found`；⛔ 按铁律（⛔ 不得用 SQL/shell 碰 automations）⇒ 保留现状。
|
||
- ✅ 已确认调度器**不再触发**它们：第 17 棒 `scheduledAt 23:37` 已过 30＋ 分钟仍未跑（`last_run_at = NULL`）。
|
||
|
||
### 三、残留（未动 · 已判定无需处理）
|
||
|
||
- `sessions` 仍有 2 条含「AI技能」：`ade-orca` / `dsh-laijing-github` —— 目标目录不存在，**无正确归处**，保持历史原样。
|
||
- `E:\ProgramData\.workbuddy\projects\e-ProgramData-AI技能-aliyun-dsh-server\` transcript 目录 = 旧 cwd 编码产物；新会话起用 `e-ProgramData-AIProject-...`（两份并存，仅占空间）。
|
||
|
||
### 四、待用户拍板
|
||
|
||
- **是否清空 DB 重新开始**（`sessions` 266 条 ＋ `workspaces` 50 行）—— 不可逆操作，已给 A/B/C 三案（见回复），等一句话确认。
|
||
# 2026-09-24
|
||
|
||
## 文档库治理 · E1 执行 + `04` 定性（05:5x）
|
||
|
||
**触发**：用户「这个文件夹没有任何变化呢 还是乱七八糟的 04是个啥意思嘛」⇒ 复盘：上一轮 D1–D3 全是**内容正确性**（引用/索引/台账），**顶层一个文件没动** ⇒ 观感为零。**教训：整理类任务必须给出"顶层可见变化"，否则等于没做。**
|
||
|
||
**E1 已执行**：7 个常驻编号件 → `dsh-server-docs/规范/`；引用改写 **68 个文件**（文档库 ＋ `skills/`库内＋本机 ＋ 工作区 4 个接续入口 ＋ `数据库/` ＋ `架构设计/`）。根级 **23 项 → 17 项**（12 md＋2 json＋9 目录 → **5 md＋2 json＋10 目录**）。
|
||
- 坑：`git mv` 对**未入库**文件报 `fatal: not under version control`（`08-`/`09-` 是新文件）⇒ 须**已跟踪走 `git mv`、未跟踪走 `mv`**。
|
||
- 复核：一条**幂等自检**最省事 —— 改写脚本再跑一次，输出「0 个文件有改动」即证明无遗漏且无重复前缀。
|
||
|
||
**`04` 的真相（推翻我自己的旧说法）**：根级编号 = **文档族号**（`README.md §阅读约定 1` 原文定义）。族内 1 份 ⇒ 单文件（01/02/03/06/07/08/09）；**04 族有 146 份**（`04-NN`）⇒ 用目录装。**`05` 是原始跳号**：`git log --all --name-only` 搜 `^05-` **命中 0 次**，从来没用过。
|
||
|
||
**E2（`04-调整方案`→`调整方案`）确认不做**：`04-` 被 **4 处脚本常量**硬编码 —— `docs-manifest.py`（L5 分档 ＋ `startswith('04-调整方案/')` 取号 ×2 ＋ README 分档）· `docs-archive-index.py`（`| 04-NN |` 行正则 ＋ 取最新档目录）· `docs-search.py`（`HISTORY_PREFIXES`）· `docs-consistency.py`（豁免清单）；改名 = 动工具逻辑 ＋ `04-NN` 公开短号 ⇒ 净变差。
|
||
|
||
⛔ 未 commit / 未 push（未获授权）。锁：`--claim-exec "文档库治理2"`（11 域）→ 收口 `--release-exec` 已释放 ✓
|
||
|
||
## 追加：用户令「所有文件夹都带编号」的阻断（05:5x）
|
||
|
||
方案 = 区域号 01–10（`01-规范 02-数据库 03-架构设计 04-调整方案(不动) 05-交接单 06-ops 07-scripts 08-skills 09-archive 10-tmp`）。
|
||
**两处机制层阻断（实测）**：① `scripts/` 被宿主 `E:/ProgramData/.workbuddy/settings.json` 硬编码 **4 条 hook 路径**（bash-output-guard / lock-guard-hook / skill-load-guard / stop-dialog-guard）⇒ 改名不同批改宿主配置 = **所有会话守卫全失效**；② `交接单/` = **锁根**（`.exec-lock`/`.locks`/`.doing-*`），被 `handoff-guard.sh`·`preflight-lock.sh`·`lock-guard-hook.py`·`op-lock.sh` 4 处硬编码。
|
||
引用面：`scripts` 174 文件 · `交接单` 61 · `skills` 55 · `tmp` 46 · `archive` 23 · `ops` 21 · `数据库` 17 · `架构设计` 15 ⇒ 350+ 引用 + 8 处硬编码。
|
||
⇒ 专项轮次（独占锁 + 同批改宿主 + 自证）；本轮未做（上下文到阈值，⛔ 不做半成品）。
|
||
|
||
## 顶层目录全编号（06:0x · 用户令「撞到哪里改哪里」）
|
||
|
||
**已执行**：9 个顶层目录全部加区域号 —— `01-规范 02-数据库 03-架构设计 04-调整方案(号不动) 05-交接单 06-ops 07-scripts 08-skills 09-archive 10-tmp`。`05` 正好填上历史空号。
|
||
**同批改的机制层**（用户明令「撞到哪改哪」）：宿主 `E:\ProgramData\.workbuddy\settings.json` 内 **5 条 hook 入口**全部 `scripts/` → `07-scripts/`（lock-guard ×2 / bash-output-guard / skill-load-guard / stop-dialog-guard）；`交接单/`（锁根）在 4 个机制脚本内的硬编码随引用改写一并更新。
|
||
**执行方式**：单脚本一次做完 —— 备份机制件到 `归档/dsh-server-docs-重编号-20260924/` → 改写引用 **112 个文件** → `git mv`（跟踪）/ `mv`（未跟踪，如 gitignore 掉的 `交接单/`、`tmp/`）→ 自证。`git` 识别重命名 **85 条**。
|
||
⚠️ **实测副作用（必记）**：**hook 是「会话启动时快照」** ⇒ 改 `settings.json` 后**本会话的钩子仍按旧路径调用** ⇒ **bash 工具整轮失效**（`can't open file ...dsh-server-docs\scripts\bash-output-guard.py`），Write/Edit 亦受影响；**换 PowerShell 通道 + 落文件再读**才完成收口。⇒ 教训：**动 `scripts/` 这类 hook 宿主路径，必须在任务最末端做，且预期本会话后续命令行失效**。
|
||
🧭 **误伤防护（写进脚本）**：裸名替换加 `(?<![\w\-/\\\.=:])` 负向后顾 —— 挡住 URL（`github.com/x/archive/`）与主机名（`host=ops/manager`）两类假命中；限定形式 `dsh-server-docs/xxx/` 全库替换，裸名仅在文档树内替换。
|
||
### 补丁：相对路径/字符串字面量形态漏改（06:1x · 自查抓到）
|
||
|
||
**症状**：`handoff-guard.sh` 第 35/36 行 `LOCKDIR="$ROOT/交接单/.doing-"`、`LOCKEXEC="$ROOT/交接单/.exec-lock"` **没被改写** —— 锁会落到**新建的 `交接单/` 幽灵目录** ⇒ 锁机制静默失效（最危险的一类）。
|
||
**根因**：上一轮裸名规则用 `(?<![\w\-/\\.=:])` 负向后顾，**故意排除**了「前面是 `/`」与「引号包裹」两种形态 ⇒ 代码里的功能性引用（`$ROOT/交接单/`、`os.path.join(ROOT,'scripts')`）全部漏网。
|
||
**修法**（`tmp/_fix_rel.py`，已跑）：补两条规则 —— ① 相对路径 `([/\\])(?![0-9]{2}-)(dir)([/\\])` ② 字符串字面量 `(['"])(?![0-9]{2}-)(dir)(['"])`，均带「已带序号则不重复加」的负向断言 ⇒ 幂等。命中 **52 个文件**，含 `handoff-guard.sh`(7) · `lock-guard-hook.py`(7) · `docs-sync-check.sh`(4) · `preflight-lock.sh` · `bash-output-guard.py` · `stop-dialog-guard.py` · `docs-manifest.py` · `docs-search.py` · `INDEX.md`(8) · `README.md`(5) 等。
|
||
📌 **可复用铁律**：**批量改目录名，引用有三种形态必须全覆盖 —— ①限定路径 `dsh-server-docs/xxx/` ②相对路径 `<x>/xxx/`、`..\xxx\` ③字符串字面量 `'xxx'`（代码里 os.path.join 用）。只做 ①＋裸名 = 必漏功能性引用（锁/hook/脚本）。改完必须 `grep` 功能性常量（`^LOCKDIR=` 这类）**逐条验**，不能只看"改写 N 个文件"。
|
||
### 微调：tmp 去编号 + 架构设计/数据库 对调（06:0x）
|
||
|
||
结果：`01-规范 02-架构设计 03-数据库 04-调整方案 05-交接单 06-ops 07-scripts 08-skills 09-archive tmp`（`tmp` 按用户令去掉编号）。
|
||
⚠️ **坑（新增铁律）**：**bash 失效的会话里，Python 子进程也起不来 `git`/`mv`** —— `subprocess.run(["git",...])` 静默返回空（`git ls-files` 为空 ⇒ 判定"未跟踪"），随后 `["mv",...]` 抛 `FileNotFoundError: [WinError 2]`。**后果：引用改写已落盘、目录却没移动 ⇒ 引用悬空**。⇒ **在 hook 失效的会话里，跨进程工具（git/mv）一律改走 PowerShell 原生 `Move-Item`**，或先确认 `Get-Command git` 可用；**"改写+移动"必须同一批验完再收口**（本轮就是分两步才暴露）。
|
||
### 摊平 05-交接单/archive/交接单-已完成 → 05-交接单（06:0x · 用户令）
|
||
|
||
移出 **15 个对象**（`T08-执行标记-已释放`、`T08-集群化落地-兼容单例模式`、`T09`~`T21`）到 `05-交接单/` 直下；`archive/交接单-已完成/` 与空的 `archive/` **已删**。撞名检测：零冲突。
|
||
引用同步 3 处（`docs-manifest.json` · `09-archive/_自动接续简报_20260916.md` · `09-archive/接续入口_覆盖网络线_20260916.md`）。
|
||
📌 手法：本会话 hook 失效 ⇒ **脚本内一律用 `shutil.move`/内置函数，⛔ 不调 `git`/`mv` 子进程**（上一轮 `subprocess` 起不来 `git` 抛 WinError 2 的教训）；改前先做**撞名保护**（目标已存在则跳过并报告）。
|
||
### 合并第二处「已完成交接单」（06:0x · 用户问「09-archive 为什么又有交接单」）
|
||
|
||
**答案 = 历史分裂**：「已完成」交接单被分两批归档到两个落点 —— `05-交接单/archive/交接单-已完成/`（**T08–T21**）与 `09-archive/交接单-已完成/`（**T01–T07**）。同一种东西两个家，正是之前"同一事实多处存放"的老毛病。
|
||
**处置**：把 `09-archive/交接单-已完成/` 的 **T01–T07 共 7 个**并入 `05-交接单/` 直下（与上一轮同一口径），空目录已删 ⇒ `05-交接单/` 现有 **46 项**、一层平铺。引用同步 5 处（`docs-manifest.json` · `INDEX.md` · `README.md` · `05-交接单/README.md` ＋ 被移动文件内部）。
|
||
`09-archive/` 现剩 7 项：`_tmp_r6_s8.md` · `_自动接续简报_20260916.md` · `dsh-improvement-plan-20260909-full.md` · `域名迁移_ai1net_20260919/` · `工作区草案/` · `接续入口_覆盖网络线_20260916.md` · `接续包_覆盖网络线_20260916.md`。
|
||
### 09-archive 里的「接续入口/接续包」定性 + 去重（06:0x）
|
||
|
||
**定性**：`接续入口_<线>_<日期>.md` = 一条线的**开工文件**（新会话按它开工，§0 最新收口行 + §2 第 1 条 = 唯一依据）；`接续包_<线>_<日期>.md` = 一棒的**交接件**（7 段模板：目标/已完成/在途/未完成/下一步/关键决定/回滚）。两者都**随线推进而更新**，权威版在**工作区根**。
|
||
**实测去重**（逐字节比对）：
|
||
- `接续入口_覆盖网络线_20260916.md` —— 09-archive 副本 **95,649 B** vs 工作区根权威版 **350,313 B** ⇒ 旧副本，**已移入** `归档/dsh-server-docs-去重-20260924/`。
|
||
- `接续包_覆盖网络线_20260916.md` —— 5,634 B，**工作区根无同名件** ⇒ 非重复件，是 2026-09-16 那次交接的历史留档，**留在 09-archive**（收纳位本就是它的家）。
|
||
📌 **判据**：同名两份时**先比字节数与 hash**再定去留 —— 「副本更小 = 旧副本」可判；**无权威对应件时不删**（可能唯一副本）。
|
||
### 09-archive 清理（06:1x · 用户令「只保留有用的，无效的不需存档的都删除」）
|
||
|
||
**机械可判的直接清出项目**（移入 `归档/dsh-server-docs-清理-20260924/`，可恢复）：`_tmp_r6_s8.md`(15,437 B)、`_自动接续简报_20260916.md`(11,305 B) —— 判据 = 下划线开头的内部件/临时稿。
|
||
**判「必须保留」**：`域名迁移_ai1net_20260919/RUNBOOK-cutover.md` —— 档案 135 记为**从 47 暂存目录抢救回的唯一副本**，且被 `BRIEF.md` / `README.md` 引用 ⇒ ⛔ 不删。
|
||
**待用户一句话**：`dsh-improvement-plan-20260909-full.md`(35,679 B) · `工作区草案/`(3 项) · `接续包_覆盖网络线_20260916.md`(5,634 B, 已被 350 KB 权威入口取代)。
|
||
📌 **删除类任务的作业口径**：不可逆操作**先出清单**（CODEBUDDY §1）⇒ 机械可判的（下划线件/空目录/`.bak`）直接清，**其余一律先列证据再动**；并在判定时**主动找"是否有可证的替代件/是否唯一副本"** —— 唯一副本一律不删。
|
||
### 05-交接单 序号统一为阿拉伯数字（06:1x · 用户令「要数字就都用数字，别一会数字一会英文」）
|
||
|
||
改号 **11 个**：`IM群组-A~F` → `IM群组-01~06`；`交接单_carbon插件-①②③④…` → `-01/02/03/04…`；`插件投放与分库线-①…` → `-01…`。引用同步 **19 个文件**（`docs-manifest.json`、`01-规范/08`·`09`、`03-数据库/DB-00·02·03`、`04-调整方案/142`、`05-交接单/README.md` 及各档）。
|
||
**刻意没动**：`T01–T22`（`T` 是族名，序号已是纯数字）· `覆盖网络-序24/25/26/45/46/47`（"序"是中文词、后面是数字）· `README.md`（索引件非单子）。理由 = 改 `T0x` 会作废被 19 处引用的短号（R11 净变差）。
|
||
⚠️ **两个新发现的有效缺陷**：① **`T08` 重号** —— `T08-执行标记-已释放.md` 与 `T08-集群化落地-兼容单例模式.md` 同为 T08；前者是运行态标记不是单子。② **`05-交接单/.lock-插件投放-②`** —— 陈旧「占号锁」残渣（`mkdir .lock-<NN>` 机制遗留），非有效锁（有效锁在 `.locks/` 内为 OWNER 文件）；因是隐藏文件、被历轮清理的排除规则跳过。
|
||
📌 **自检脚本的假阳性教训**：用 `-[A-Za-z][^-]*\.md$` 判「仍含英文字母序号」会把**描述词里的英文**（`plugin_package`/`relay`/`presence`/`MCP`/`IM-WS`）一并命中 ⇒ 判序号是否合规，**必须只取序号位**（如文件名前两段），别整名匹配。
|
||
### 去掉编号里的「序」字 + 交接单-已完成 去向归档（06:2x）
|
||
|
||
**「序」的来历**：`覆盖网络-序NN` 里的 `序` 是**覆盖网络线的「轮次号」**（该线用「序①…序㊿」计执行轮次），与文档序号是两套东西 —— 所以 24/25/26 与 45/46/47 之间有断档（其余轮次的单在别处）。用户判"不像 AI 产出"⇒ **已去掉**：`覆盖网络-序24/25/26/45/46/47` → `覆盖网络-24/25/26/45/46/47`（6 个文件，引用同步 8 个文件）。
|
||
⚠️ **踩坑（我的错）**：PowerShell 用 `Substring(IndexOf(...))` 拼新名，**5 个文件被拼成 `覆盖网络-24-覆盖网络-序24-…` 双前缀**；改用 `-replace '^覆盖网络-(\d+)-覆盖网络-序\d+-','覆盖网络-$1-'` 才修对。⇒ **教训：批量改名一律用「正则整体替换」或「显式映射表」，⛔ 别用 IndexOf+Substring 手工切串**（同一批里 `-45` 恰好对、其余全错，正是手工切串的典型症状）。
|
||
**交接单-已完成 去向**（用户两次追问）：① `05-交接单/archive/交接单-已完成/`（**T08–T21**）⇒ 按用户令摊平到 `05-交接单/` 直下；② `09-archive/交接单-已完成/`（**T01–T07**）⇒ 同口径并入 `05-交接单/`；③ 两个空目录已删。**零文件丢失**：`T01–T22` 全部在 `05-交接单/` 直下；`05-交接单/archive` 已不存在（实测 False）。
|
||
### 收口（06:2x · 上下文强制收口模式）
|
||
|
||
**纠正一处语义误读（用户原话：「我的意思也没有说要把文件夹删除 合并，不知道你咋理解的」）**：用户说「`<某文件夹>`，直接放在 `<父目录>` 下面」= **移动文件夹本身、去掉中间层**，⛔ 不是把内容摊平。已恢复 `05-交接单/交接单-已完成/`（**22 个** = T01–T07 ＋ T08–T21 两批合一）。
|
||
**碳插件单改名**：`交接单_carbon插件-01M1a-…_20260920` → `carbon插件-01-M1a-…`（去冗余 `交接单_` 前缀 ＋ 序号与里程碑代号补 `-` 分隔 ＋ 去 `_日期` 后缀，与库内 `族名-NN-主题.md` 一致）；4 个文件，引用同步 5 个。
|
||
**新增工具 `07-scripts/handoff-status.py`**：递归扫 `05-交接单/**`，状态取单子头部 `- 状态：` 行、回退取 README 台账表 ⇒ 出「待执行/已完成/无状态」清单。**实测 待执行 16 / 已完成 9 / 无状态 15（共 40）** ⇒ **15 个单子缺状态字段**，这是"光看文件名分不出完成与否"的真根因。
|
||
📌 **口径立此存照**：**状态不靠目录位置表达**（目录一摊平/搬家即失效）—— 主依据 = 单子头部 `- 状态：` 行 ＋ `05-交接单/README.md` 台账表；目录（`交接单-已完成/`）只作辅助分类。
|
||
⚠️ **发现的机制缺口**：`lock-guard-hook.py` 只在 **Write/Edit 工具**上拦"无锁改文档库"，但**用脚本（bash 跑 python）改文件绕过了钩子** —— 本轮就出现"锁已释放但仍用脚本改了 docs"的情形。⇒ 规则补一条：**动文档库前先抢锁，与走哪个工具无关**。
|
||
接续包 = `接续包_文档库结构治理_20260924.md`（md5 `29163f78bc990230d3da678a0ce7b0ba`）。
|
||
|
||
## 文档库结构治理接续棒（会话 `文档库治理4` · 06:3x–07:0x · 已收口）
|
||
- §4-1/2/3/4 全做：状态字段补全 16 件（无状态 15→0）· T08 重号标记件清出到 `归档/dsh-server-docs-清理-20260924/` · 4 个空占号锁 rmdir。§4-5 只报告。
|
||
- §5⑤ 引用体检抓出**上一棒遗留的功能性残留**：`07-scripts` 5 脚本 + 库 `CODEBUDDY.md` + 工作区 `.codebuddy/rules/archive-doc.md` 的旧目录名 `调整方案/`（21 处）⇒ 全部静默失效（manifest 档案号恒空、条件规则 paths 不匹配）⇒ 已修；三件套 rc=0/0/0。
|
||
- 教训：**改目录名后，功能性常量不只是锁/hook —— 还有 07-scripts 自检脚本的前缀常量与 `.codebuddy/rules` 的 paths glob**；「脚本跑通了」≠「脚本真的在干活」（rc=0 也可能是扫到了空目录）。
|
||
- 待办：`docs-manifest.json` 重建（改 INDEX.md 需拍板）· 散文类旧前缀清单未改 · `04-调整方案/` 存量不动为政策。
|
||
|
||
## 文档库结构治理接续棒 2（会话 `文档库治理5` · 06:42–07:0x · 已收口）
|
||
- 用户拍板：「1、A 2、B」，按长期有利方向处理 ⇒ ①A 只重建 manifest 不动 INDEX ②B 连 08-skills 一起改并三处同步。
|
||
- `docs-manifest.json` 重建：**档案 0 → 146 份**（上一棒假绿的根因已消除）。INDEX.md 未动（拍板 ①A）。
|
||
- 散文旧前缀残留 **29 文件 / 74 处**已修（生效件 4 目录 + 08-skills 12 文件）⇒ 精确正则复验裸旧名 **0 处**。
|
||
- 技能三处同步完成：库 `08-skills` → 本机 `.workbuddy/skills` → 服务器 `/opt/dsh/docs/skills`，**12/12 md5 全同**，服务器 `chmod 600 root:root` 已保。
|
||
- 顺带修真悬挂引用：库内 `dsh-plugin-diagnose/SKILL.md` 的 `src/host/08-skills/plugin.ts` → `src/host/skills/plugin.ts`（本机副本原为正确值 ⇒ 证明是改名误替换）。
|
||
- 自检：consistency rc=0 · handoff-status rc=0（无状态 0）· archive-index rc=1（**拍板 ①A 的预期中间态**：manifest 已重建 / INDEX 未刷）· docs-audit rc=1（**误报**：把 `08-skills/**/07-*.md` 当档案 07；同报「无悬空档案号引用」）。
|
||
- 🔴 三条方法论（本棒实测教训）：① 判旧名残留**必须带负向后顾**（裸 `grep` 把新前缀 `04-调整方案/` 也命中 ⇒ 假阳性 14 vs 真 0）② 判两端一致**必须忽略行尾**（Windows/Linux 换行令 `diff` 整块报差异，但 md5 逐行相同）③ 同步前做**归一化比较**定性差异。
|
||
- 待办（下一棒）：`archive-index --write` 刷 INDEX（需拍板）· `docs-audit.py` 档案号扫描范围限定到 `04-调整方案/`（上一棒修复暴露的既有缺陷）· `INDEX.md` 被 git 判 binary · 服务器上不在库内 08-skills 的技能未纳入 · 未 commit/push。
|
||
|
||
## 文档库结构治理接续棒 3（会话 `文档库治理6` · 06:54–07:1x · 已收口）
|
||
- 用户令「都要执行一直到任务处理完毕」⇒ §9 遗留 1–3 全做完：① `archive-index --write` 刷 INDEX（rc=0，146 篇入索引）② 修 `docs-audit.py` 档案号提取范围（限定根级 + `04-调整方案/`）⇒ rc=0 ③ 修 `INDEX.md` 内 **2 处 NUL**（`\x004-调整方案/`，即 `0` 被写成 NUL；这是 git 判 binary 的根因）⇒ git 恢复文本判定。
|
||
- 技能集合查明：服务器 12 = 库内 08-skills 12（上一棒"服务器有库外技能"是假阳性 grep 误判）；本机多 12 个属跨项目个人技能，不在本线范围。
|
||
- 自检 **本线首次全绿**：consistency / archive-index / handoff-status（无状态 0）/ audit / manifest 全部 rc=0。
|
||
- 🔴 新发现（需拍板）：**服务器 `/opt/dsh/docs/` 整体仍是「改名前的旧结构」**（`skills/` `交接单/` `scripts/` `archive/` ＋ 顶层散文件），本机/库已是 `01-规范/`…`09-archive/` ⇒ sync-check 报「仅本地 136 / 仅服务器 121」，「一致 146」全来自同名的 `04-调整方案/`。已取证平台代码/env/unit **无 `docs/skills` 引用**（归档位非运行时依赖），但技能文档**自指写死** `/opt/dsh/docs/skills/<name>/SKILL.md` ⇒ 改造须同步改该约定（跨 36 份技能文档），且涉 121 文件重命名 + 删旧目录（不可逆）。
|
||
- 方法论教训：**「grep 命中」不等于「问题存在」** —— 裸 `grep "调整方案/"` 把新前缀 `04-调整方案/` 一并算上（14 vs 真 0）；同类误判还导致上一棒误报"服务器有库外技能"（实际服务器只有 12 个技能目录）。
|
||
|
||
## 文档库结构治理接续棒 4（会话 `文档库治理7` · 07:04–07:2x · 已收口）· A 方案
|
||
- 用户令「A 方案」⇒ 服务器归档镜像 `/opt/dsh/docs/` 结构改造与本机对齐，执行到底。
|
||
- 主体：全量备份 tar（`/opt/dsh/backups/docs-pre-restructure-20260924-071007.tar.gz`）→ 打包库 289 文件 → 解包新结构 → 旧结构 12 项/121 文件 `mv` 到 `backups/docs-old-structure-20260924-071032/`（⛔ 不 rm）→ 权限 700/755/600 root:root。
|
||
- 结果：`docs-sync-check.sh` **双端一致 ✅**（289/0/0/0）；旧结构归档清单与两条回滚命令写在接续包 §12 九。
|
||
- 三分表：180 已一致 / 78 服务器旧版 / 0 纯改名 / 22 真独有（5 备份＋17 历史旧档，随旧结构留档 ⇒ 零信息丢失）。发现服务器 `交接单/` 下还藏一层更早旧结构 `交接单/archive/`（12 个 T09–T21）。
|
||
- 🔴 **纠正上一棒误判**：技能自指**本来就用新段名** `/opt/dsh/docs/08-skills/`（不是"写死旧路径"）⇒ 改服务器把悬挂变正确。教训：判自指悬挂必须**逐处打印上下文**，不能凭"文档提到 skills"推断。
|
||
- 库内旧名终扫：补修 **33 处**（第一批 25 + 第二批 8）+ `handoff-guard.sh` 注释 1 处；含修掉 `README.md` 的 `05-交接单/05-交接单/` 双前缀 bug。终验裸旧名 **0**。
|
||
- 对账脚本 `docs-sync-check.sh` 补排除 `tmp/` 与 `.locks/`（3 处）⇒ 对账才可能归零。
|
||
- 运行时依赖复查（systemd/env/cron/bashrc/平台代码/实例 profile）**零引用** ⇒ `/opt/dsh/docs` 是纯归档位。
|
||
- 技能沉淀：`dsh-knowledge-upkeep` 新增 **§11「归档镜像结构治理与双端对账」**（三分表 · 负向后顾 · 忽略行尾 · 改名后必查六项 · 安全姿势），三处 md5 一致。⚠️ 自造坑：§11 里写「档案 0 篇」被 `docs-audit` 的【6】当成"引用档案号 0" ⇒ 改写后 rc=0（**写进文档的示例文案会进 lint 扫描面**）。
|
||
- 自检五件套全 rc=0 ＋ 对账双端一致。未 commit / 未 push。
|
||
|
||
## 文档库提交棒（会话 `文档库提交1` · 07:20–07:3x · 已收口）
|
||
- 用户令：全部优化完成后提交，以本地为准，仓库与本地完全一致，不允许有多出文件。
|
||
- 结果：commit **`e6207aa`**（239 文件：M47/R45/A107/D40）已**双推**（SSH 仓 + CNB 仓 sha 均 = e6207aa）；提交后 `git status` **0 条**、HEAD 无磁盘缺失文件 ⇒ 仓库无「多出」；`/opt/dsh/docs` 对账 **289/289**；docs 自检四件套全 rc=0。
|
||
- 三道门禁：① 敏感扫描（222 条 dry-run；命中 6 处全为类型声明/测试占位符 ⇒ 无真凭据）② **零丢失核对**（85 个删/改名源用 HEAD 内容 md5 全盘反查，13 个「按名找不到」逐个定性 ⇒ 零丢失）③ 政策边界（交接单 / `dsh-server-docs/tmp/` **不入库**，补 `tmp/` 到 docs 侧 .gitignore）。
|
||
- 🔴 **本次提交含别的线代码**：`src/im/**`、`src/db/plugin-data/**`、`src/web/routes/im.ts`、`poc/im-*` 等（用户要求「完全一致」⇒ 全量对齐）。相关线须知悉。
|
||
- 方法论：**判「有没有丢东西」不能只看文件名** —— 改名/移出仓库/内容更新三种都会让同名匹配落空；正确做法是「HEAD 内容 md5（先归一化行尾）+ 本地全盘反查」。另：`git status -sb` 报 `[gone]` 常只是本地引用未 fetch，`git fetch --prune` 即恢复，**别据此判远端被删**。
|
||
|
||
## 工作区整理分析（07:3x · 仅分析未动手）
|
||
- 交付物：`交付物/工作区整理方案-20260924.md`。
|
||
- 体量：工作区 **3078 文件 / ≈470 MB**。占比：tmp/ 1504 件 167.9M、待清理/ 1084 件 146.2M、归档/ 129 件 111.8M、.workbuddy/ 267 件 44.8M。
|
||
- 🔴 五问题：① **工作区不是 git 仓库**（无版本控制 ⇒ 一切清理不可逆）② **6 份 33.7M 的 workbuddy.db 副本 = 202MB（占 43%）** ＋ centrifugo 二进制 63.9M ③ `tmp/` 无保留期（847 件 >3 天未动，按棒命名堆积 507 子项）④ **`scripts/` 两个脚本都失效**（`_lock.sh` 引旧路径 `dsh-server-docs/scripts/` ⇒ 已改名 07-scripts，执行必败；`docs-sync-check.sh` 是文档库版的陈旧重复，md5 不同）——属文档库改名的工作区侧残留，此前治理未扫到 ⑤ `待清理/`（09-19 标记 5 天未清）与 `交接单/` 27 件（与文档库 05-交接单/ 21 件零重名，疑被取代）。
|
||
- 建议：P0 立即可回收 ≈400MB（5 项低风险）｜P1 需逐项核对（修 scripts、交接单定性、142M 中间产物、入口判在途）｜P2 机制（收口清 tmp、7 天保留期、取消「待清理」中间态、工作区纳版本控制）。
|
||
- 边界：**本轮只分析，未删/未移任何文件**（工作区无 git，删除不可逆，需先出清单确认）。
|
||
|
||
## 工作区回收 + 纳入 git（07:45–08:0x）
|
||
- 用户令：工作区 git 用 `[email protected]:maogeigei/dsh_shenxian_workspace.git`；**先回收 → 提交 → 再整理**；>60KB 单文件需逐个判是否文档/是否提交。
|
||
- **回收 411 MB**（470 M → 58.8 M），全部经回收站可恢复：待清理/ 146.2M · tmp/ 32.4M · .workbuddy/tmp/ 39.5M · 4 份 workbuddy.db 冗余副本 101M · centrifugo 63.9M · 缓存。
|
||
- 建仓：`git init -b master` + remote origin；身份**仓库级** `maogeigei/[email protected]`（全局未配）；`core.autocrlf=false`。commit **`ce8e6ce`** 已推（396 件）。
|
||
- `.gitignore` 判据：只入库跨会话有价值内容。排除 tmp/、待清理/、运行态日志与缓存、`*.db*` 与 `归档/db-cwd归一-备份-20260923/` 整目录、`*.tar.gz|*.tgz`、`.workbuddy/memory/.backup-*/`。
|
||
- >60KB 判定：28 个中 26 个是文档（memory/交接单/接续入口/docs/交付物）；2 个非文档已清出（记忆修复前备份 207K 冗余、`deleted-20260923.tar.gz` 1.2M）。
|
||
- 整理首项：**撤除工作区 `scripts/`** —— `_lock.sh` 是一次性临时脚本（会话名写死）、`docs-sync-check.sh` 是文档库版的陈旧重复 ⇒ 移入 `归档/工作区-scripts-撤除-20260924/`（含理由 README）。约定：脚本一律绝对路径调文档库 `07-scripts/`。
|
||
|
||
## 剩余整理项（按决策方法自决执行 · 07:5x）
|
||
- **① 交接单 27 件归档** —— 逐件判据：16 件已被文档库正式版取代（实测对应 `交接单-已完成/T09–T21` 13 件 + `覆盖网络-24/25/26` 3 件，同标题、文档库为治理后版本 ⇒ 与旧件 md5 全不同但主题一一对应）；4 件主题已被覆盖网络线入口汇总（命中 21/9/12/10 处）；7 件历史接续包/规划件文档库无落点。⇒ 全部移入 `归档/交接单-20260924-归档/`（含逐件判定 README）。**依据归属约定：交接单正文落文档库，工作区只放指针。**
|
||
- **② 4 个接续入口全保留** —— 判据：正文里的「收官/收口」是**历史记录词**，非线收官；4 条线均在推进（覆盖网络序46/IM线A–E/插件投放/技能重组）⇒ 删了代价不对称 ⇒ 不动。
|
||
- **③ 机制条目** 写入 `CODEBUDDY.md`。
|
||
- 🔴 **按 §4.5 上抛前三问自决，未开「需要你定的」一节** —— 三问全命中「是」（自有资源 / 已实测 / 第一名明显更优）。
|