5 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	44c25eb03b	refactor(memory): 到期清扫挂点从 wait 注入缝改为 TidyService.Start ... 塔裁定：清扫不许挂在注入缝上 —— 包一层 s.wait 会让「清扫是否存活」依赖于 「loop 每一轮都调 s.wait」这个**没有任何契约固定**的假设；将来谁换了等待原语、 或把循环改成 select + 自己的 timer，清扫会**静默消失**（不报错、不红测试， 只是临时期限再也删不掉）。后台件起在 Start 里，读者一眼看到它们同生共死。 - tidy_service.go：Start 里紧跟 go s.loop(cctx) 起 go s.expirySweepLoop(cctx)， wg 计数与既有那一笔同处（同一把锁内加，避免 Add 与 Stop 的 wg.Wait 相撞）。 `if !s.cfg.Enabled { … return }` 仍在其前 ⇒ 语义与改动前逐字相同：整理被关掉 ⇒ 清扫不跑（与 preinsert_gc 随审查服务启停同口径）。 - expire_loop.go：删掉 AttachExpirySweep 与对 s.wait 的包裹；文件头写明 「挂点必须是 Start 里那处显式的 go」，防止后人改回注入缝。 - expire_loop_test.go：那条运行时对照改写成 TestTidyServiceStart_清扫随服务起停 —— 真 Start、真 Stop（Stop 不超时即证明清扫随 ctx 退出且登记在同一个 wg）。 - wire_memory_tidy.go：去掉组合根的挂载调用，注释改成「起在 Start 里，组合根零接线」。 - wire_memory_tidy_test.go：把 go s.expirySweepLoop(cctx) 钉进 TestMemoryTidyIsWired 的 seams（摘掉那一行 ⇒ 用例红，已实测）。	2026-10-13 21:43:27 +08:00
AskaEth	23b6e3fe1e	feat(memory): 启动时自动播种面板配置文件（缺失才写、绝不覆盖） ... 主人 2026-10-07：「后端自动创建独立的面板配置文件要做」。 - 启动路径（wireMemoryTidy → applyMemoryTidyTuning 之后）若 $DATA_DIR/config/memory-tidy.json 不存在或全空白 => 写一份「当时生效值」 （十键：既有六键 + 频率四键），此后面板接管 - 已存在（非空）=> 跳过，该分支没有任何写盘语句；损坏 => WARN + 按 .env 跑、 一个字不写盘（不「修好它」） - 幂等（第二次启动必落到跳过分支）；原子写（tmp 0600 + rename） - 落盘前完整性闸：缺键 / 非正周期 / 钟点越界 => WARN + 不落盘 - 值来自 TidyTuningSnapshot（先跑两个归一化再翻回正向键）=> 播种那一刻运行 行为零变化，有强断言（归一化后配置逐字相等） - 零新增依赖、零 env 键变更；5 个变异（含「让已存在走写盘」=> 红）	2026-10-07 20:38:37 +08:00
AskaEth	d680390300	feat(memory): 整理频率走面板配置（面板 > env > 默认）+ 分时段动态间隔 ... 主人 2026-10-07：「.env 只做兜底…优先从面板配置上取」+「频率必须调…或者动态 分配，比如白天间隔短一点 晚上到了静默时期稍微长一点」。 - memory-tidy.json 新增四键：intervalSec / quietIntervalSec / quietStartHour / quietEndHour（*int + 指针判定 => 显式 0 是合法值、缺位才回落） - 优先级逐键三档：面板 > env（既有键，未增删）> 代码默认；坏值不覆盖 + WARN， 且不启动失败 - 动态间隔由纯函数 intervalAt(at) 决定，调度侧每一拍现算 => 跑完按当时时段重算 - 🔴 语义变更（有意，代码注释已登记，待补设计修订）：安静时段从「唯一可跑时段」 变成「降频时段」—— 旧的「安静窗外一律 continue」被删，否则 intervalSec 永远 是空壳（白天唤醒必被跳过）；窗口仍决定档位与补跑判据 - 6 个变异（含「加回旧的那道门」=> 端到端用例红）	2026-10-07 19:21:32 +08:00
AskaEth	6d92536276	feat(memory): 整理不再只产建议 —— 轮末自动落地高置信 + 停产 link 候选 ... 主人原话：「那么多 link 是干什么的？该删就删，怎么这个记忆整理机制这么保守呢」。 ① **link 停产**（依据 design/23 §14 把它列为「未细化」⇒ 既无落点也无数据模型； `applyable()` 也只认 merge/archive/reclassify ⇒ 应用 link 恒 `skipped`，是纯噪音）： - 规则层 `containNone` 判定改为 `keep`（不再产出 501 条不可应用的待办）； - `TidyLink` 常量保留，只为**读历史行**与「不可应用」判定； - 存量出路：新端点 `POST /api/v1/admin/memories/candidates/reject?action=&limit=` （**幂等、只改候选 status、不碰记忆**），主会话用它清掉存量 501 条。 ② **轮末自动落地**（默认开，仅两类，判据是纯函数）： - `merge`：**字面重复** ∨「事实集合等价 ∧ 相似度 ≥ 0.95」； - `archive`：理由 = `one_off_event` **且不像习惯**（`design/23 §5.2-1` 红线： 习惯类会因正文带钟点被误判成一次性事件，归档它是错的）。 - **不自动**：`reclassify`、低置信 merge、跨分区/跨角色、任何改正文、受限来源 （群聊/陌生人）—— 新增执行面守卫 `tidySkipSourceRestricted`。 ③ **六条护栏**（缺一不可）：软动作（复用既有 apply 路径）/ 每轮上限 50（硬顶 500， 超限如实 `Truncated` + 真总数）/ 审计 `memory.tidy.apply`（`auto=true`，不带正文）/ **可 revert**（复用既有回滚）/ 幂等（复用候选状态条件更新）/ **一键关回只产建议** （`$DATA_DIR/config/memory-tidy.json` 的 `autoApply:false`，**零新 env 键**）。 验收（主会话复跑 + 亲自变异）：memory 与 gateway 两包 build/vet/test 全绿；我用 -overlay 短路「习惯不归档」守卫 ⇒ TestTidyAutoNeverArchivesHabitMisjudgedAsOneOff 变红（逐字报「作息习惯被自动归档了 …design §5.2-1 红线」）。 ⚠️ 未部署（要 build+restart 才生效）；⚠️ 契约欠登记（新端点 B25 + §7.2），主会话补； ⚠️ 真机端到端未跑（不能重启后端）。	2026-10-07 11:07:00 +08:00
AskaEth	91a3209c9b	feat(memory): 记忆整理 v1（design/23）——低峰定期扫描 + 事实包含判定 + 规则否决 + 只产建议队列（不自动应用）	2026-10-05 11:29:36 +08:00