0 Fork 0

Files

T

admin c1b5e4d966 chore(工作区): 全量入库 + 补齐 .gitignore（以工作区为准）

- 变更规模：新增 514 / 修改 62 / 重命名 155 / 删除 4（归档重组与文档轮次）
- .gitignore 修：`归档/**/db-cwd归一-备份-*/` —— 原规则写绝对层级（归档/db-cwd归一-…），
  目录搬进 归档/配置与备份/ 后**静默失效**，43 MB 的 DB 备份又变成未跟踪
- .gitignore 补：嵌套 git 内部数据（归档/内嵌git-20261008/、归档/skills-git-旧线-20261007/dotgit-原样移出/）
- .gitignore 补：运行态与部署副本（.workbuddy/collab/、.workbuddy/tools/、.workbuddy/.load-pending、.workbuddy/tmp-*）
- .gitignore 补：备份件（*.bak-*）
- 未跟踪文件从 2190 降到 890（其余为 归档/ 归档件与 .workbuddy/memory/ 知识文件，按口径入库）

2026-10-10 23:13:22 +08:00

5.5 KiB

Raw Permalink 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/AIProject/ai1net-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 Permalink Blame History Unescape Escape