主人实测:memory_items 1191 行、候选 77 条全 pending、memory_tidy_runs 仅 1 行、两晚定时没跑。 根因两条(都在这片里修掉): ① **以前根本没有执行面** —— 只有只读试算,候选永远 pending ② **调度被重启饿死** —— interval=24h 的 ticker 从进程启动算起,两天重启十几次 ⇒ 24h 永远走不完 - 应用路径:逐条 / 按 run 批量(默认 100、硬顶 500、超限 truncated)/ revert;**软合并** (status + merged_into/merged_from/merge_count,**绝不改 content、行不删**)+ 审计 (memory.tidy.apply / memory.tidy.revert)+ **幂等**(候选状态条件更新 + 行 status 闸两道) - 调度:改成**到点即跑**(catchUp:无历史+窗口内 / 距上次 run ≥ interval / 窗口起点晚于上次 run), 「上次 run」以 memory_tidy_runs 为**持久事实**;注入时钟用例证明**重启不饿死** - 手动真跑端点 POST /admin/memories/tidy/run(同档鉴权 + 审计 + 回执:新增/合并/软删/耗时) - 候选表加 run_id 列 + 索引(前滚;顺序=建表→补列→建索引,否则既有库会 no such column) - 3 个变异自检(删 catchUp / 去掉两道 status 闸 / truncated 恒 false) ⚠️ 生产库零动作:1191 行真跑与 77 条候选应用**未执行**(按红线由主人确认后主会话执行) ⚠️ 契约段在报告里(candidates 列表/apply/revert/tidy.run),Docs/ 待登记
【MT-A:护栏 + 诚实截断 + 试算异步】 - maxTidyCompareItems 400(写死)→2000 并开放为 MEMORY_TIDY_COMPARE_LIMIT; MEMORY_TIDY_CANDIDATE_LIMIT 默认 20→200(语义不变,仍每分区) - 依据是首跑实测:459 条的分区被 400 截断 ⇒ compared(705) < scanned(784), 候选数(77)由上限而不是规则决定;三处上限的 WARN 都补齐了总数/上限/分区名 - 新增「上限 + 时间预算」双闸(实测 2000 条/分区 ≈234s > 3 分钟墙钟): 整分区跳过 / 两两比对中途收手,一律如实记 (budget) + WARN - ?async=1 ⇒ 202 {runId,status};GET …/{runId} 轮询(writeAuth 同档); done 的 result 与同步 data 逐字节同形;并发=复用既有 runId、TTL 30min 自完成起算、 重启即如实 404 tidy_run_not_found;不带 async 时同步路径逐字不变 【MT-B:D3 入库前审查(design/23 §15.1)】 - 新记忆经 Store.Add(仓库里唯一 INSERT INTO memory_items)落库后,由独立记忆管理 会话(sess-memorytidy)在有界后台队列异步判定 skip/merge/modify/create - 软合并回写(status + merged_into/merged_from/merge_count,可 revert、绝不改 content) - 隔离来源(群聊/陌生人)**概不审查**、召回/超时失败**零改写**(fail-safe 结构性成立) - 写入侧仅 +62.7µs/条(非阻塞入队);默认 ENABLED=true(主人裁定:入库前先审查) 【耦合说明(重要)】两片同包且互相依赖:MT-B 的 preinsert_recall.go 用 MT-A 的 collectTidyPairs 新签名 + tidyBudget ⇒ **各自单独都 build 不过**,故一并落地。 MT-A 为让整包编译,最小幅度适配了 MT-B 的 preinsert_recall.go / preinsert_test.go (零值预算=行为不变;符号重名改名)。 【我的验收】隔离 worktree(37 文件)build/vet/linux/darwin 全过,切片包全绿; 我亲手打红两个变异:① 去掉 (compare) 截断标记 ⇒ TestTidyCompareLimit_HitIsLoud 红; ② 中和隔离来源守卫 ⇒ TestReviewRestrictedSourceIsNeverTouched 红。 唯一红是 internal/runtime/tool 的两条超时用例(该包无人改)⇒ 主仓库 -count=8 全绿, 判定为负载敏感 flake(当时两个整树验收 + 子代理并发),已记入开发习惯与约定 §7。 .env.example 补 MEMORY_REVIEW_* 四键(MT-B 无该文件权限,由我按其代码语义补写)。