AskaEth/Cyrene_v2
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
809 Commits 7 Branches 0 Tags
dev
Commit Graph
11 Commits
Author SHA1 Message Date
AskaEth 4df8d6f53a fix(memory): 按字段扫清 s.cfg 的其余无锁读（P1）+ 回显文案按 rune 截断 
review P1：applyTidyConfig 在运行期**整体覆写** s.cfg，而我只把调度读收进了持锁
访问器 —— 同一字段还有几处无锁读，其中两处是**活端点**：

- TidyService.DryRun 的开关判定（在取 runMu **之前**）⇒ POST …/tidy/dry-run 与
  ?async=1 那条会起后台 goroutine 的版本（真机 90s 级）；
- TidyService.ManualRun 的开关判定（同样在 runMu 之前）⇒ POST …/tidy/run；
- （原本也漏的）Enabled() 与 Start 的启动日志块。

按**字段**重扫了一遍（不按文件）：现在生产代码里对 s.cfg 的读**只剩**三个持锁访问器
内部（enabled / cfgSnapshot / scheduleSnapshot），写点只有 applyTidyConfig 一处；
s.tidier.cfg 的读点全在持 runMu 的轮次 / 试算路径上（含异步版经 DryRun）。

新增第三条并发回归哨兵：真并发跑「试算 + 手动真跑」两个活端点 × 面板保存。
修前红/修后绿：撤回 DryRun 的同步 ⇒ 报「写 applyTidyConfig × 读 DryRun」；撤回
ManualRun 的同步 ⇒ 报「写 applyTidyConfig × 读 ManualRun」；两次变异都逐字还原
（diff 0 差异）。

顺手两条（塔指定）：
- 那条并发哨兵的 doc 与实现相反（还写着「正确顺序是 Stop → 写 → Start」），已改成
  唤醒机制下的说法 —— 与「注释与实现不符」同类，不留旧说法。
- 非法值的回显文案原按**字节**截断（s[:40]），中文会被切成半截（非法 UTF-8，经
  JSON 编码变成 U+FFFD 替换符）。改成按 **rune** 截断，直接复用同包既有的
  clipRunes；用例取值刻意让截断点落在多字节字符中间（JSON 引号 + 一个 ASCII 前缀
  错开对齐），并做过变异复验：改回按字节 ⇒ 用例红（切出半个汉字）。
 2026-10-13 22:33:07 +08:00
AskaEth 97c0c1b94a feat(memory): 调优重排改为唤醒通道，不再 Stop/Start（消灭与到期清扫的耦合） 
按塔的裁定把「重排心跳」从生命周期操作改成唤醒通道，调优路径上一个 Start/Stop
都没有了。

- tidy_service.go：TidyService 新增 wake（cap 1 + 非阻塞发）与 wakeMu/wakeCancel；
  loop 的等待段抽成 waitForTick，三态判定（睡满 / 被调优唤醒 / 停）；被唤醒只
  重算下一拍、**绝不**跑轮。调度读（nextDelay / dueNow）改走 scheduleSnapshot，
  在同一把锁下同取「cfg + lastRun」，于是运行期写 cfg 不必再把后台件停下来。
  Start / Stop / wg / running 与 Enabled 早退语义**一个字节没动**。
- tidy_service_tuning.go：ApplyPanelTuning 变成「持 runMu 写 cfg → 发一次唤醒」。
  唤醒 = 一次性标记（保证不丢：心跳不在等时标记留在缓冲里）**加上**取消当前那次
  等待（保证立刻生效，否则 24h→3h 要等原来那一觉睡完）。

两条冲突就此消失，各配一条可复现断言：
- **面板保存不再触发到期清扫、也不重置清扫 ticker**：新用例在保存前后各造一行已
  到期的记忆，保存之后那行必须**还在**、清扫审计计数必须不变；该用例自带活对照
  （启动清扫会删掉第一行），因此「行还在」不是量具失灵。若保存走 Stop/Start，清扫
  的「启动即扫一轮」会立刻把它删掉。
- **调优路径上不再存在任何 Start 调用**（结构上消灭交叉 Start/Stop）：包内生产代码
  已 grep 不到任何 `.Start(` / `.Stop(` 调用，Start 与 Stop 各只剩组合根那一处调用点
  （`cmd/cyrene/main.go` / `cmd/cyrene/wire_services.go`），M3 注释里那条「Start/Stop
  各只调用一次」的不变式因此重新成立；交叉场景由带真心跳的调优用例在 `-race` 下跑过
  （不再 panic）。

热生效没退化：原来那条「23h30m → 30m」的断言按新机制重写 —— 用一个「听得懂 ctx
取消」的假等待看两觉的时长（保存前 23h30m、保存当场的第二觉 30m），并补上「唤醒不
跑轮（lastRun 不前移）」「唤醒后 running 仍为 true」。

变异自证（都跑过再还原，`diff` 逐字一致）：
- 去掉 `notifyReschedule` 调用 ⇒「被唤醒后的第二觉」等不到 ⇒ 用例红；
- 只留标记、去掉「取消当前等待」那一半 ⇒ 同一条红（两半都必需）。

M3 的守卫 `expire_loop_test.go` **一行未动**：它的假 wait 只认 ctx，父 ctx 取消时
返回 false，在新机制下语义不变（无人唤醒时照样把心跳停住）。
 2026-10-13 22:17:22 +08:00
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「全自动挡吧」）
CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled
Details
CI / Frontend (tsc + vite build) (push) Has been cancelled
Details 
自动落地现在三类：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 候选
CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled
Details
CI / Frontend (tsc + vite build) (push) Has been cancelled
Details 
主人原话：「那么多 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，主人投诉的根因）
CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled
Details
CI / Frontend (tsc + vite build) (push) Has been cancelled
Details 
主人实测：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 入库前审查（耦合两片一起落）
CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled
Details
CI / Frontend (tsc + vite build) (push) Has been cancelled
Details 
【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）——低峰定期扫描 + 事实包含判定 + 规则否决 + 只产建议队列（不自动应用）
CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled
Details
CI / Frontend (tsc + vite build) (push) Has been cancelled
Details
2026-10-05 11:29:36 +08:00