文档: 设计文档与问题记录归档

todo.md

@@ -107,3 +107,77 @@
   - 覆盖场景:意图增强/纠偏/递进(用户补充信息后发现之前目标提取偏了)
   - 优先级:中——价值高改动小,补全目标维护闭环
 
+## 上下文精细化管理(对齐 10-04 三层记忆设计)+ 工程可行性(AI-Ops 分析移交)
+
+> 分析来源:凌晨窗口实测(221 轮/508 条,prompt 均值 71K/峰值 135K,压缩 ~120K 才触发,tool 结果 4.9KB×279 条,cargo 验证同步阻塞占 45%)。
+> 方向定调(用户 10-05):1M 窗口下调阈值意义不大;主轴 = 按任务相关性精细组织上下文 + 自主管理,外置内容长久可找回并持续蒸馏进知识库。
+> 对齐结论:本组需求与「上下文三层记忆-设计-2026-10-04」高度同路,实施以该设计为准,不平行立方案。映射:相关性压缩/结构化 → C-m1 记忆卡;压缩时机 → C-m2 信息增益信号;外置找回/蒸馏知识库 → C-m3 提炼链与知识库衔接。
+
+### 实施序(按 10-04 分期 + 可行性排序)
+
+- [ ] **C-r0 验证命令后台化与降频**(独立,先行):全仓测试攒批收官一次(凌晨重复跑 2 次),中途只单包 check;长命令异步执行 + 完成回填。验收:>90s 同步等待占比 <15%(现状 45%)。
+- [ ] **C-m1 记忆卡产出**(10-04 分期一):按设计实施四类卡 + 渲染,压缩产物结构化。
+- [ ] **C-m2 压缩时机关联**(分期二):信息增益信号触发;AI-Ops 补充输入——相关性判据挂 pinned_goals,水位仅作失控兜底(窗口 80%),prompt_tokens 已逐轮在库可直读。
+- [ ] **C-r1 压缩可逆:按段重载**(AI-Ops 增量):compressed 原文全在库(status 标记未删),给 agent 按段重载手段,压缩从不可逆变可逆。
+- [ ] **C-m3 外置找回 + 蒸馏衔接**(分期三,依赖召回闭环):大内容外置区(上下文只留句柄 + 头部摘要,跨会话按任务索引,外置区是资产不是垃圾暂存);蒸馏接现有 knowledge 模块(提取侧 knowledge.rs、注入侧 knowledge_inject.rs 均已在)。
+
+### 设计风险与工程可行性(R 条款,实施前必读)
+
+- **R1 相关性判别的成本账**:"LLM 按段自评"若逐段调用,压缩一次 = 几十次 LLM 调用,成本延迟反噬。要求:规则初筛粗分,LLM 只评模糊带;或随摘要生成批量一次判定。验收加一条:压缩动作自身成本 < 被省成本的 10%。
+- **R2 目标漂移误压**:pinned_goals 中途变更后,按旧目标判"无关"的段对新目标可能关键。压缩判定带目标版本标记;目标变更时对判无关段重估。
+- **R3 盲区问题(压缩可逆的边界)**:被压内容里可能有关键细节而 agent 不知道存在,重载依赖"想起"。缓解:记忆卡必须带检索锚点(关键字/路径/数字清单),不只是叙述摘要——四类卡若无此字段,实施时补。
+- **R4 错误知识反哺循环(最危险)**:蒸馏出错条目 → auto_inject 污染后续会话 → 错误自我强化。准入门槛必须先于注入开关:条目带溯源 + 置信标记,被验证/被引用后才升格可注入;先建评测集再开 auto_inject。
+- **R7 知识库代谢:只进不出必腐化(用户 10-05 拍板)**:现状知识库只加条目、无 update 进化机制。蒸馏入库必须先查存量——相似条目走 update(合并/修正/增强)而非新增,防同主题碎片堆叠;条目短小精准(单条单事实,宁短勿滥)、带时效(过期检测)与使用频率,常用上浮、久未用沉降、被证伪淘汰,形成代谢闭环(参照 u-claw 知识库冷热分层:沉降/激活/消亡/代谢)。知识不在多,在于精、巧、即时。
+  - 精细化设计:`docs/02-架构设计/专项设计/知识库模型重审-精细化设计-2026-10-05.md`(六用例走查+五场景推演+实施序;现状实证:向量 0/1073、verified 2%、置信 87% high——三项地基数据)
+- **R8 架构统一性:三套体系并行 vs 统一条目模型(可扩张性/优雅性审查)**:现状压缩段(消息 id)、外置件(路径)、知识条目(知识 id)三套标识、三个模块并行,信息在热/温/冷三层流转时身份断裂,溯源靠约定。优雅解 = 统一信息条目模型:唯一 id + 内容 + 溯源 parent 链 + 元数据(相关性/时效/频率/归属),生命周期状态机 hot→warm→cold→dead,流转动作(compress/reload/distill/inject/merge/evict)即状态转移;新策略(相关性/时机/蒸馏)= 转移策略可插拔,新存储后端 = warm 层 trait 实现,四类卡/知识条目 = 同一 schema 的类型扩展。多 agent/云端多人预留:条目元数据现在就留归属字段(与设计 §十 演进预留对齐)。
+- **R5 外置区边界**:工具输出可能含密钥等敏感信息,外置明文落盘需权限面;清理策略(会话删除级联 vs 长期资产)需显式定,防两读。
+- **R6 效果度量**:无度量则无法迭代。三指标:重载命中率(重载后解决问题的比例)/ 误压率(重载回来说明压错的)/ 蒸馏采纳率(条目注入后被引用比例)。ai_messages 全程记录,评测基建现成,凌晨窗口数据即首个测试集。
+
+### 分工口径
+
+- 10-04 设计(记忆卡结构/压缩时机/分期路线)= 实施主依据;本段增量 = R1-R6 风险条款 + C-r0/C-r1 两个设计外条目 + 水位兜底与相关性判据输入。
+- 数据复现:ai_messages 按 conversation_id + timestamp 可复现全部实测。口径:AI-Ops 2026-10-05。
+
+## 提交纪律反馈-1005(AI-Ops 核查)
+
+> f6eb55b(11:56)审查:内容与敏感面✅,形式三处待改——①一笔混 4 功能(u-claw集成/WebChat/项目归档/审批重设计),下次按功能分组拆笔;②多主题细节下沉 body,不留空 body;③设计文档/问题记录独立「文档:」笔,不混功能提交。
+
+**根因(2026-10-05 AI-Ops 查证)**:提交纪律从未进入系统提示 — prompt.rs(981 行)工具纪律完备,「提交/commit/攒批」零命中;git 能力随工具下发而纪律未同源下发,违反本项目自己的「纪律随工具同源下发」原则(prompt.rs:213)。长会话中仅存于上下文的约定被稀释,提交质量全凭运气。
+
+- [ ] **P0(升级版,2026-10-05 拍板)行为规范数据化治理**:devflow 定位 ai-working,行为规范会持续增多,不走「每条硬编码 prompt.rs」。架构=三层(铁律层 prompt.rs 现有工具纪律不动 / 规范层知识库 review_rule 条目(提交规范 5 条落为首批,带 enabled/scope)/ 任务层 pinned_goals 已有)+ prompt.rs 增一个通用规范注入口(读启用的 review_rule 拼入 system_prompt,一处代码永久扩展点)。扩展=加条目零代码;治理复用知识库 R4/R7(置信/代谢);观测=违规事件反哺条目置信(与 UC3 同机制)。验收:提交规范 5 条以 review_rule 数据条目生效;新加一条规范不改代码。
+
+**首批规范条目扩容(2026-10-05 第二案,拆分提交卡循环触发停滞保护)**:任务策略类 2 条与提交规范同期落库——
+- *批量分类/分组任务*:先一次性取全貌(如 git show --stat),制定分组映射表再机械执行,禁止逐文件深潜分析(实证:56 文件拆分反复 grep 卡停靠)
+- *自换策略检查点*:同签名工具调用连续 2 次无新信息即主动停手换策略,不等熔断器(熔断是最后防线非第一反应)
+- *停滞保护提示增强*:停靠消息自动附疑似病因与建议方向(现状只说"补充新方向",用户无从下手)
+
+**审查修订(同日三维度红队)**:①review_rule 条目加 constraint 声明,注入时约束段「必须」句式独立成段,与参考记忆物理分开;先核 61 条存量语义纯度 ②注入配额:启用条目 ≤20 条/1.5K token,超出按 scope+置信+频次取 top,条目单条单规则 ③规范声明可执行性两级:可执行化(如提交规范→提交后确定性校验)配自动检查器,原则性走 LLM 低频抽查 ④agent 沉淀规范前一句话确认防误判临时要求;每轮组装读库保即时生效(成本实测);注入日志标记条目命中便于排查;管理 UI 复用知识库界面。
+
+## 基础设施走查-1005:存储空间治理与进程自检(AI-Ops 分析移交)
+
+> 实测:DB 168MB,实数据仅 ~69MB(ai_messages content 22MB + tool_executions.result 41MB + 其他 ~7MB),近 100MB 为 SQLite 空闲页/碎片空转;WAL 15.9MB;增速 1-5MB/天。核心查询 14ms 当前无性能压力——问题是空间,不是速度。
+
+### D1 空间止血(一次性)
+
+- [ ] **D1 VACUUM 回收**:①备份 DB 并登记台账(铁律)②关 devflow.exe(或空闲时)③`VACUUM` + `PRAGMA wal_checkpoint(TRUNCATE)`。预期 168MB → ~70MB。注意:VACUUM 全表锁,勿在会话进行中做。
+
+### D2 空间机制(防再膨胀)
+
+- [ ] **D2a tool_executions.result 过期外置**:超 30 天的执行结果本体移出库落归档文件,库内留路径句柄(与 C5 外置同构,一套机制两处用)。预期消掉 41MB 最大头的增长。
+- [ ] **D2b 定例化**:月度 VACUUM + 启动时 WAL checkpoint(挂启动流程)。
+- [ ] **D2c 体积水位监控**:文件/实数据比 >1.5 告警,进 agent-monitor。
+- [ ] **D2d 归档会话消息过期**(阈值待用户拍板,建议 90 天):archive 会话的消息到期物理清理+VACUUM。
+
+### D3 其他走查项(按优先级)
+
+- [ ] **D3a 换装后就绪自检**:换装重启后探测「DB 可写/IPC 通/provider 可达」再宣布就绪(凌晨换装引发消息闪失暂态的根治配套)。
+- [ ] **D3b timestamp 索引**:ai_messages 加 timestamp 索引(一条迁移,监控/统计类查询从全表扫变索引)。
+- [ ] **D3c 单连接 Mutex 复核**(08-02 存量 P1):挂机模式引入并发后复核触发条件是否已变,实测锁竞争再定方案。
+- [ ] **D3d df-nodes HTTP 连接池**(存量 P1):工作流高并发才触发,场景未到,标记缓治。
+
+> 分工口径:storage/migrations 机制内实施;D1 需用户配合关应用;D2d 阈值待拍板。走查口径:AI-Ops 2026-10-05。
+> 换库评估结论(用户问询 10-05):**现在不换**——PG 的 autovacuum/并发/网络优势在单机桌面场景用不上,迁移是周级工程;空间痛点 D1-D3 治理用 1/10 成本拿 80% 效果。云端多人(S3)启动时:**服务端用 PG**(多租户),桌面端 SQLite 不动(本地缓存/离线),同步桥连接——换库是分层不是替换。
+> 量级基准修正(用户 10-05:按全部 u-claw 实例+Claude Code 数据 ×10):实测全生态 ≈2.1GB(本机 ~/.claude 2.0G 大头是会话 jsonl 流水,六容器实例合计 <25MB),×10 ≈ 21GB。21GB 走分层不进主库——流水外置文件(Claude Code 自身即先例:jsonl 存会话不用 DB),主库装结构化条目,GB 级内 SQLite 稳定。结论不变:**现在不换库**;C5 外置分层从"优化项"升为"量级前提"。
+> **存储架构定稿**:`docs/02-架构设计/专项设计/数据存储架构-定稿-2026-10-05.md`(四维评估收敛:分层+统一条目模型+同步桥+治理度量,四预留字段随 C-m1 一次建齐)
+> 分布式跨端协同预留(用户 10-05):跨端协同靠同步层不靠换网络库——各端 SQLite 自治(离线优先),同步 = 条目级变更事件流(append-only)复用既有 u-relay/df-tunnel 通道;冲突普通条目 LWW、关键实体走状态机(task_state_machine CAS 先例);外置件用内容哈希做 id(去重/可验证/任意端拉取);云端多人时服务端 PG 作汇聚点。前提依赖 R8 统一条目模型——条目需带 origin(来源端)与修订标记,实施 C-m1 建模时一并落。
+