9 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	8a274e120d	docs(memory): 到期清扫的注释改用符号引用，不再写会漂的行号 ... review r2（p2-1items）指出：r1 那笔注释里的行号是旧值 —— 我在文件更前面插了 12 行之后 `Stop` 整体下移，而注释里仍写着「`Stop` 在 `tidy_service.go:214` 就放锁， 到 `:219` 才 Wait」（214 是 `Stop` 的文档注释行、219 是 `s.mu.Lock()`）。 行号会漂、符号不会，因此改成符号 + 相对位置： - 「在同一个 `func (s *TidyService) Stop` 里，`s.mu.Unlock()` 在前、`s.wg.Wait()` （另一个 goroutine 里）在后，两者之间没有锁」； - 「`Start` 只在组合根启动期调一次（`cmd/cyrene/main.go` 的 `a.memoryTidy.Start(ctx)`）、`Stop` 只在关停链里调一次（`cmd/cyrene/wire_services.go` 的 `_ = a.memoryTidy.Stop(ctx)`）」。 同一类问题只此一处遗留（`expire.go` 里「照 `preinsert_gc.go:65-69` 的批删范式」 同样改成符号：`ingestReviewSweepBatchSize` / `maxIngestReviewSweepBatches` 那一对 常量）。已 grep 全部改动文件确认再无 `*.go:<行号>` 形式的引用。 （本提交信息刻意不复述任何行号。）	2026-10-13 21:54:38 +08:00
AskaEth	69210a8586	docs(memory): 改正 Start 里那笔 Add 的并发注释，并补 Enabled=false 回归测试 ... review r1（p2-1items）指出：`tidy_service.go` 新加的那段注释（以及 2ba0a40 的提交 信息）写着「计数在这把锁里加 …… `Stop` 也持这把锁，这样 Add 与 Stop 的 `wg.Wait` 不可能撞在一起」。**这句不成立**：`Stop` 在 `tidy_service.go:214` 就放锁，到 `:219` （另一个 goroutine 里）才 `wg.Wait`。锁只串行化 `running` 翻转与两笔 Add， **不覆盖 Wait**。reviewer 用交叉 Start/Stop 探针在 -race 下复现了 `panic: sync: WaitGroup is reused before previous Wait has returned`，并实测该 panic 在 M3 之前的基线（20051f0）上同样可复现 ⇒ 既有性质，本切片不改行为，只改说法： - 照真实理由改写注释：锁内加是为了让 `Stop` 的 `running` 判定与这两笔 Add **原子化**（杜绝「Stop 已看到 running=false 早退」与「Wait 漏掉一笔尚未 Add 的 goroutine」两个窗口）； - 明确写出这把锁**不**覆盖 `Stop` 的 `wg.Wait`，WaitGroup 的复用纪律靠 「`Start`/`Stop` 在进程生命周期各只调一次」维持； - 并写明那个交叉探针的**当前调用点不可达**（`Start` 只在 `cmd/cyrene/main.go:97` 调、`Stop` 只在 `cmd/cyrene/wire_services.go:212` 调），免得后人看到「有窗口但 不可达」以为是漏改。 同时补上 reviewer 点出的真实缺口：`Enabled=false ⇒ 清扫不跑` 此前只有注释、没有 已提交的回归测试。新增 TestTidyServiceStart_整理关掉时清扫不跑，真跑 Start 后断言 「没有删除发生 + 没有审计 + running 保持 false」三件一起（不是只断言 cfg.Enabled 字段那种假牙）。两条断言各有牙：把 Enabled 闸改成恒 false ⇒ 红在 running 那一条； 在 Enabled 早退分支里偷偷起一个清扫（running 仍为 false）⇒ 红在「到期行却被删了」。	2026-10-13 21:46:24 +08:00
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	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	f310173b4c	feat(memory): reclassify 纳入自动档（主人 2026-10-07「全自动挡吧」） ... 自动落地现在三类：merge（字面重复 ∨ 事实等价 ∧ ≥0.95）· archive（one_off_event 且不像习惯）· **reclassify（新增）**。reclassify 只改 `kind` 一列 （`reclassifyTidyItemSQL` 只写 kind+updated_at），**不动正文、不动作用域、不碰第二条行**。 判据（纯函数 `tidyAutoReclassifyKind`，四个条件全中才自动）： ① 恰 1 个 source 且无 target；② 理由 = `kind_mismatch`；③ 建议 kind 合法； ④ **改前 kind 合法且 ≠ 建议值** —— ③④ 是 **revert 抓手**：没有它自动落地就不可回滚。 **边界**：只读 ProposedKind / KindA，**一概不读** ProposedContent / MergedContent / ContentA/B / 分区 / 时间字段。 六条护栏逐条覆盖它：软动作（同一条 apply 路径）/ 每轮上限（三类同占一个池子， 默认 50 硬顶 500，混合时截断如实）/ 审计 `memory.tidy.apply`（`auto=true`， `reclassified=%d` + stats + 日志 + run 审计，**只带计数与理由、不带正文**）/ **可 revert**（`revertTidyReclassify` 按 KindA 写回，且只在当前 kind 仍等于建议值时生效）/ 幂等（候选条件更新 + 行 `AND status='active'` 双闸）/ 开关关闭 ⇒ 连查询都不发。 另补一道本片新增的门：**受限来源**（群聊/陌生人）与跨分区的 reclassify **skipped** （原先只有 merge/archive 有这道门）。 验收（主会话复跑 + 亲自变异）：整树 `go build ./...` + vet 绿；memory/gateway 两包 测试绿；我用 -overlay 禁掉「必须真的变了」那一格 ⇒ `…EligibilityBoundary` **3 条子例变红** （改前 kind 缺失/非法/与建议值相同 ⇒ 都"没法回滚"）。子代理另做 4 个变异（连正文一起写 / 摘受限来源门 / 去掉 reclassified 计数 / 不要求可回滚抓手）全红。 🔴 **未动的红线（一行未改）**：`archive` 的「习惯类不归档」守卫（design/23 §5.2-1） —— `looksLikeHabit` / `tidyHabitMarkers` / `tidyReasonOneOffEvent` 零改动， `TestTidyAutoNeverArchivesHabitMisjudgedAsOneOff` 仍绿。要连它也自动请主人明说。 ⚠️ 未部署（要一次 build + restart）；⚠️ design/23 的 §7「reclassify 交人工」与 §13 开放点 5「全部人工应用」**现已过期**，主会话同步。 ⚠️ 已知遗留（需新授权）：历史积压里指向**已被吸收行**的 reclassify 候选会每轮被选中 又永远 `source_not_active` 跳过，白占一次每轮名额；彻底解法是「永久不可用的候选自动 标 rejected」（新行为）。	2026-10-07 11:26:34 +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	454ddb0b70	feat(memory): 记忆整理**应用路径 + 调度修复 + 手动真跑**（TIDY-1，主人投诉的根因） ... 主人实测：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/ 待登记	2026-10-06 22:39:35 +08:00
AskaEth	6e28b38b08	feat(memory): 护栏抬高+时间预算闸+试算加性异步 与 D3 入库前审查（耦合两片一起落） ... 【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 无该文件权限，由我按其代码语义补写）。	2026-10-06 08:04:12 +08:00
AskaEth	91a3209c9b	feat(memory): 记忆整理 v1（design/23）——低峰定期扫描 + 事实包含判定 + 规则否决 + 只产建议队列（不自动应用）	2026-10-05 11:29:36 +08:00