0 Fork 0

Files

T

admin 04776af4b1 docs: 工作区根项目文档批量入仓（04-调整方案 113–128 / 交接单 T09–T21 / ops / archive）

起因：用户 2026-09-17 明确「所有文档都要同步，都放在开发仓库 docs 对应文件夹下」。
判据：工作区根 *.md 中在仓库（git ls-files --quotepath=false）搜不到的那些。

入仓 33 份（一律复制，工作区根原件保留不动，避免引用断链）：
- 04-调整方案/113–128（16 份 · 原子占号后落盘）：覆盖网络 传输方案取舍 / 应用场景与待完善清单 /
  插件化vs改内核 / 问题逐条推演 / 参数表与观测口径；会合中继拆分取证与改造方案；
  集群化改造方案 Manager-Worker；跨节点迁移与节点自举；项目代码分层范式与迭代风险评估；
  搬运与共享重建方案 guest w47→w106；方案规划方法提炼；文档无效信息审计报告；
  会话接续机制复盘与修复；会话接续规范；dsh 客户端化部署方案；dsh 桌面客户端开发方案
- 交接单/archive/交接单-已完成/T09–T21（13 份 · 覆盖网络线已完成单归档）
- ops/（2 份运行态指针：接续入口 / 接续包 · 覆盖网络线）
- archive/（2 份临时与内部简报）

已排除（无需重复入仓）：覆盖网络线 10 份方案正文已入档案 103–112（文件名不同）。

登记：INDEX.md §二 新增 04-113–128 共 16 行 + §四 追加 T09–T21 说明 + 机器摘要行刷新
（⛔ 未跑 docs-index-stats.py --write：该脚本会按 \r\n 归一化全文件行尾，故改为字节级单行替换）；
README.md 追加 1 条入仓指针；docs-manifest.json 复跑 scripts/docs-manifest.py 刷新。

验收：工作区根 47 份 .md —— 同名已入仓 8 / 本次内容一致 29 / 已知改名映射 10 / 未入仓 0；
git status 待提交清单只含本次新增与登记 3 件（未涉 src/ 与 relay 代码面）。

2026-09-17 18:24:19 +08:00

5.5 KiB

Raw Blame History

文档无效信息审计报告（2026-09-16）

判据 = dsh-knowledge-upkeep §8（六类无效信息 + 五条"不能删"的红线）范围 = .workbuddy/memory/*.md（31 份 / 1,325 KB）｜技能 *.md（12+ 份 / 348 KB）｜工作区根方案文档（23 份 / 964 KB）⇒ 合计 66 份 / 2,643 KB 方法 = 两个只读脚本机械扫描 + 人工复核（脚本在 _中间产物_待清理/auto-continue-20260916/，可复跑）性质 = 一次性产物；读完可归档到 _中间产物_待清理/，⛔ 别让它自己也变成"根目录堆积"

一、判定

✅ 整体健康。无效信息不弥散，只集中在 2 处。

§8 六类检查项	实测结果
③ 同一事实多处重复	memory 17.5 KB / 1.3%｜技能 0.3%｜根方案 0.0% ⇒ 无大段重复
⑥ 只写"给人看的套话"	0 处
④ 过程流水挤掉结论	日志类 0.5–0.67 属正常（日志本就是流水）；正式文档无异常
⑤ 中间产物混进正式文档	机械命中 45 处 → 人工复核真命中 0
① 与可执行体不符／ ② 过期结论占"生效位"	见 §二（1 处真实问题）
悬空引用（辅助项）	机械命中 30 个 → 真命中 0

⚠️ 方法学如实说明：第 ⑤ 类与悬空引用的机械检测器噪声很高 —— 45 处命中全是"文档把 _tmp_* 当反例讲"或"点名真实的 _verify_tsc.mjs"，30 个悬空引用全是 package.json/SKILL.md 这类裸文件名。六类里真正能机械判定的只有 ③ 重复、④ 流水占比、⑥ 套话；⑤ 与引用类必须人工复核。⇒ 这类审计的价值在「定量 + 复核」，不在全自动。

二、真实问题（按影响排序）

1. 工作区根 _中间产物_待清理/sess-forensics-20260916/会话脉络_ddea70b7_20260916.md = 589.6 KB，占根方案文档 61%

类别：§8.2 第 ④/⑤ 类（过程流水 + 取证中间产物混进正式区）
判据（§8 唯一判据：去掉它，下一个会话会不会做错事/变慢？）：内容是「AI 为何上抛」的会话转录摘录，其结论已被三处吸收 —— 会话复盘_AI为何上抛_20260916.html、.workbuddy/memory/2026-09-16.md、两个技能的修订 ⇒ 去掉不会导致做错事
已处置（2026-09-16 修复轮）：移入 _中间产物_待清理/sess-forensics-20260916/，并同步修正 3 处引用（审计报告 / 简报 / 会话复盘 HTML）；历史日志中的路径按 append-only 原则不改
效果：工作区根 .md 由 23 份 / 964.1 KB → 22 份 / 375.0 KB（-61%）

2. 每轮注入层：用户级 E:\ProgramData\.workbuddy\MEMORY.md 被截断（已修）

实测：20,977 B / 11,712 chars；宿主 注入上限 ≈ 4,000 chars
原排序的后果：注入窗口只覆盖「钩子配置 + 环境路径」——一条行为规则都没进去（Preferences 整节在窗口外）
类别：这是 §8.2 第 ② 类的变体 —— 内容没错，排序错；而"排在窗口外"在效果上等于"这条规则不存在"
已修：分层重排（零删除）+ 文件头加排序契约（⛔ 新增内容按序插入对应小节，别追加到末尾）

三、"不能删"红线的分布（供后续清理避让）

五条红线（判据与阈值 / 命令原文与路径 / 反例踩坑 / 为什么 / 失效标注）在 66 份里几乎每份都有。机械兜底已就位：docs-shrink-guard.py 基线覆盖 151 个文件（行数骤降 >30% 且 >20 行即报警）⇒ 后续任何整编都会被它抓出来。

四、建议（⛔ 本轮未做，留待下个会话决定）

✅ 已落地（2026-09-16 修复轮）：dsh-knowledge-upkeep 1.1.0 → 1.2.0，新增 §8.6「注入预算」维度 —— 「每轮注入有上限 ⇒ 长文件后半段等于不存在；先重排、后删减；文件头必须写排序契约」。md5 6249caaa…，本机 / 文档库 / 镜像三处一致。同时用户级记忆头部已写入排序契约。
根目录方案文档：⛔ 不搬（结论已在修复轮修正）。复核后实测：10 份 覆盖网络_*.md / 可行性评估在档案 103–112 里的行覆盖率 98.5–99.0%（差异 = 一级标题行），另 3 份与文档库 archive/工作区草案/ 字节完全相同。 ⚠️ 但"搬走"是净变差：这 10 份被 11 处引用（含 接续入口_覆盖网络线_20260916.md），搬走会大面积断链 ⇒ 改为加归档指针（正文以档案 103–112 为准，根副本保留为工作副本）。 🔴 本报告首版的一处错误（已修）：首版用「归一化整串包含」判定，得出"档案未包含根文档"的假阴性（因为档案按约定删了 H1 标题行）⇒ 正确判据是行级覆盖率，不是整串包含。这与本报告 §一记的"检测器噪声"是同一类错误：机械判据必须先验证判据本身。
日志分片不需要瘦身：2026-09-16.md 已 88 KB、2026-09-下19.md 流水占比 0.67 —— 但日志按需读取、不进每轮上下文，不构成水位成本。按维护规则，10 月后把 9 月日志按主题蒸馏进 MEMORY.md 再删旧片即可。

附：可复跑命令

cd "E:/ProgramData/AI技能/aliyun-dsh-server"
PYTHONIOENCODING=utf-8 "<managed python>" "_中间产物_待清理/auto-continue-20260916/audit_docs.py"    # 六类机械扫描
PYTHONIOENCODING=utf-8 "<managed python>" "_中间产物_待清理/auto-continue-20260916/audit_pass2.py"  # 重复字节定量

5.5 KiB Raw Blame History Unescape Escape