34 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	6c30ca540a	fix(memory): 冷启动放宽改为一次性 + 试算轮区分「没候选」与「向量不可用」 ... review round1 的 p1/p2 收口（commit 5967272 之后）。 p1：旧实现 `warmed` 只在 2xx 之后才翻 ⇒ 注释里写的「只在第一次成功响应之前」 实际是「服务坏着的全部时间」。reviewer 实测「接受连接但永不回包」时**每次**调用 都等满 30s（fail-fast 变 fail-slow）：审查 20s 预算被一次吃光、索引写入拖成 8×30s、开机探针阻塞 30s。 - `warmupLeft` 改为**一次性许可**（CompareAndSwap 取走即失效，成败都算花掉） ⇒ 挂死时只有第一个请求慢一次，此后一律 DefaultRequestTimeout。 - `warmupTimeout` 30s → 8s：与常态 5s 同一量级（≤2×），且严格小于审查总预算 20s（一次冷启动不许吃光整轮）；两条界都由 TestDefaultRequestTimeout 守住。 - 放宽被花掉且没成功时留一条 WARN（事后可复核「第一个请求」这个判据）。 - 更正两处自述：api.go 的「不会被 30s 拖住」与 budget.go 的不变式说明（批次形状 永远按稳态超时推导；冷启动只放宽第一个请求的截止时刻）。 - p2：删掉零调用者的 `WithRequestTimeout` —— 单次超时只允许改常量，批次上限与它 同源并由编译期/常量断言复核。 p2：试算轮在向量源不可用时 `RecallMode` 与「没有候选可比」同为空串。 - `recallLedger` 增 `unavailable` 计数 + `noteUnavailable()`（strictRecall 失败 那一笔记一笔）；试算汇总行新增 `recall_unavailable_partitions`，**成败都记**。 - 不扩 `recallMode` 取值集合：失败那一路不序列化 result（响应是 500 tidy_recall_unavailable），新取值只会出现在日志里却要动一次契约，不划算。 测试：三种失败形态 × 两次调用的耗时断言（连接被拒 / 500 / 永不回包）， 试算轮的「不可用」与「没候选」两态日志断言；两处变异自证（warmupTimeout 调回 30s ⇒ TestDefaultRequestTimeout 红；去掉 noteUnavailable ⇒ 试算汇总行退化成 recall_mode="" + recall_unavailable_partitions=0）。	2026-10-13 20:51:10 +08:00
AskaEth	59672720bd	fix(memory): embedding 批上限与超时同源 —— 不再「客户端先放弃、服务端继续算」 ... M9（EMBRECALL）。故障机制（M6 + 本次复测）：客户端 5s 单次超时先放弃，服务端仍在 算那一批 ⇒ 本机 llama.cpp 被自己顶住 ⇒ 后续每个请求（含写向量索引的单条请求） 排队到自己的超时 ⇒ 召回全线降级。 - embedding/budget.go（新）：把「一次请求的耗时上界 ≤ 单次超时的一半」写成不变式， 批上限（条数 4 / 字符 480）与 5s 超时由**同一个不等式**解出；实测依据与复跑命令 写进注释（空闲态摊销曲线 1→0.19s / 8→1.1s / 12→1.3s / 64→8.5s，约 50ms 固定 + 2.7~3.9ms/字符，n≥32 起有数倍放大 ⇒ 余量取一半）。 - embedding/api.go：Embed 按同一对上限**自己切片**（不变式与调用方无关）；冷启动 首次调用单独给 warmupTimeout，拿到第一个成功响应后立刻回常态超时。 - memory/tidy_config.go：tidyEmbedBatch = embedding.DefaultBatchLimit（同源）， 并加编译期断言 —— 调回 64 会直接编译失败（constant -60 overflows uint）。 - memory/tidy.go | tidy_recall.go | tidy_dryrun.go：recall_mode 改报**实际发生** 的来源（""=本轮没候选可比 / embedding / lexical / mixed），新增 recall_degraded_partitions；试算轮 RecallMode 同口径（M6 medium finding）。 - 测试：embedding 侧用「实测曲线 + 会睡够时间的假客户端」钉住两态 （批内 < 超时 ⇒ 不降级；旧配对 64 条 ⇒ 必然超时），并断言 abandoned == 0； memory 侧钉住降级/健康/没候选三态与试算轮的如实上报。 不改 preinsert*、不改 .env、不动判定规则与任何阈值。	2026-10-13 20:33:26 +08:00
AskaEth	0c5fa7b2ae	docs(memory): timegate.go 登记「审查留痕读侧不过闸」—— 留痕表结构上无该三列，无可加之闸	2026-10-13 19:54:36 +08:00
AskaEth	9a3b3cff8b	feat(memory): 读侧时效闸（四条列表读路径）+ Add 落 expires_at 列 ... 主人裁定「临时记忆到期删除 / 任何调用记忆的地方都要正常调用到」的读侧 第 ① 步（隐藏）：design/03 §9.6 / §11.2 的时效闸下沉到共享底层，不写在 任何调用点。 - timegate.go（新）：timeGateClause = (expires_at = '' OR expires_at > ?) AND (valid_to = '' OR valid_to > ?)；timeGateNow() 与列值同源（同一个 formatTime 的定宽 30 字节 UTC 文本），expiryText() 负责写入侧编码。 - Store.ListByPersona / List / ListScope / ListProject 四条列表读路径 的 WHERE 在既有 status 闸之后拼上时效闸；Retriever.visibleCandidates 组合前两条，检索入口因此自动继承同一判据（无第二处判据）。 - Store.Get 与整理/审查的内部召回 SQL 刻意不过闸，理由写在各自注释里 （listTidyPartitionItemsSQL 原位注释在本切片；listReviewCandidatesSQL 的原位注释按塔裁定改派 M2，timegate.go 头注登记了这条拆分）。 - Store.Add 的 INSERT 补上 expires_at 列（MemoryItem.ExpiresAt）：Add 是 全仓唯一 INSERT 路径，时效列的真生产者只能在这里，否则闸退化成空壳。 - timegate_test.go（新）：过期/失效行在四条路径与 visibleCandidates 上 都不可见、空值与未来值可见、Get 仍能读过期行、Add 真的落库该列； 外加时间口径同源钉（文本序==时间序 + 跨格式 'T' vs ' ' 陷阱实证）。 验收：go build ./internal/runtime/... 通过；go vet 通过；go test ./internal/runtime/memory/... 全绿；internal 全包 62 个 ok / 0 FAIL； GOOS=darwin GOARCH=arm64 交叉构建通过。	2026-10-13 19:54:19 +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	a684328b76	feat(memory): T1 加保守全局速率限流（防每天数百到上千次调用失控） ... 主人 2026-10-07 裁定：按最优解加全局限流。 - 新增 t1RateGate（滑动窗口、可注入时钟，~70 行）；默认 120 次 / 60 分钟（现网 700-1000 条新记忆/天 ≈ 25-42/小时， 取 120 留约 3-5 倍余量） - 过闸摆在「t1Enabled + 有灰区候选」两个守卫之后、发请求之前 ⇒ 不调模型就不占额度；放行才记账 - 超限语义与既有失败路径同源：跳过 T1、决定仍是 create、零改写， 只多一个 reason=t1_throttled 进留痕 + ReviewStats.T1Throttled 计数 - 配置键 t1PerWindow / t1WindowSec 放 $DATA_DIR/config/memory-tidy.json （零新 env 键，启动期读一次）；坏配置回落默认 + WARN，不启动失败 - 每窗口只记一条 WARN（超限是预期行为，一天几百条会淹掉真故障） - IngestRuleVersion 仍为 d3.2：判定规则集与解析契约没变，变的只是 额度状态，reason 列已可分辨（升版会有 §17.6 记过的幂等键重复行副作用） 自研而非复用 session.NewRateLimiter 的理由（design/12 §N C.5 自己登记过 这条取舍）：既有件 Allow() 内部写死 time.Now()，没有时钟注入缝， 而本切片必须能注入可控时钟；且复用会把 channel 层概念拖进 memory 包。	2026-10-07 16:25:54 +08:00
AskaEth	987cefdf28	fix(embedding): 端点地址规范化 + 独立短超时（治入库审查整条超时） ... 背景：入库前审查链路一直整条超时（日志每 ~20s 一条 WARN），异步那层 （含刚装好的 T1）从未成功跑过。 - 新增 endpoint.go：把「连接语义上不可靠」的回环别名规范化成 127.0.0.1 （localhost 大小写不敏感 / 0.0.0.0 / 空主机），只替换 Host，不碰 path / query / fragment / userinfo；显式 [::1] 与真实主机名逐字不动 - Embed 加独立短超时 DefaultRequestTimeout = 5s（远小于审查 20s 预算）： 卡住的调用快速失败并走既有「降级到词项余弦」的路径，把预算留给 T1 - .env.example 示例地址 localhost -> 127.0.0.1（未注释行键数 69 -> 69，无增删） - 跨包测试钉住 5s 严格小于审查总预算 诚实边界（子代理实测，推翻了主代理原先的 IPv6 根因推断）： - Go 客户端走 localhost 实测约 57ms、curl 约 0.2s ⇒「localhost -> ::1 等满 20s 预算」这条链不成立；更可能是单槽 llama.cpp 的吞吐/争用 （一批 64 条约 2.1~2.9s，审查 201 条约 8~10s，再叠 T1 8s 顶满预算） - 规范化在任何环境下都无害，5s 快速失败对这个真因对症；但真因 （容量/争用）需要另排切片，已记入工作小结	2026-10-07 16:22:28 +08:00
AskaEth	1b4d0a552f	feat(memory): T1 灰区模型判定 —— D3 入库前审查补上 LLM 那一半 ... 主人 2026-10-07 裁定「可以做 T1」。此前 D3 只有纯规则 T0，凡灰区（相似但 互不包含）一律保守 create，真机上「同一事实换措辞」类重复结构性治不住 （清完 92 条字面级重复后，active 里含「喵喵七号」的仍有 101 条）。 - 插入点：T0 判定内核只多吐一份结构化 Gray（惰性收集，恒零模型调用）； T1 挂在异步审查层 Review，同步入库闸不碰它 ⇒ 写入路径零模型调用是 **数据流结构**而不是承诺 - 只许回 merge / modify / keep + 一句理由；坏 JSON、非法枚举、编号越界 一律回落 create（绝不猜、绝不挑最近的一条） - 禁产新内容：模型只给「动作 + 候选编号 + 一句理由」，正文一律取自库里 既有的两行 ⇒ T1 结构性地不可能把幻觉写进记忆库 - 不越硬门与红线：灰区已滤掉跨角色/作用域/项目/只读来源与时效/数值/冲突/ 低置信；「规则否决一票否决」不可走样，T1 不提供翻案入口 - 有界：每次审查至多一次调用（灰区打包，上限 8 条），子超时 8s 且不超过 审查总预算；失败只改 reason、决定恒 create、零 UPDATE - 开关 t1Judge（放 $DATA_DIR/config/memory-tidy.json，零新 env 键），默认开； 模型出口用闭包晚绑定既有模型栈（零新客户端、零新依赖） - 留痕 reason 结构化（t1_merge / t1_modify / t1_keep / t1_reply_invalid / t1_unavailable），rule_version d3.1 → d3.2；模型的自由文本理由一律丢弃 - preinsert_config.go 为纯搬移（为守 500 行上限，无新逻辑）	2026-10-07 14:10:33 +08:00
AskaEth	90f430216a	feat(memory): D3 从「异步后置」改成「同步入库闸」—— 由整理层决定入库形态 ... 主人 2026-10-07 裁定：「把记忆整理功能接到昔涟和记忆库中间做审查，由整理功能 进行入库」。现状是**异步 + 入库后软合并** ⇒ 行已经落库才审，面板/召回先脏后清， 而写入速率实测 ~25 条/小时（≈600/天）⇒ 清理永远追不上。 落法（三条硬规格，全部落地）： ① **同步闸但有界**：闸在 `store.go:247` 的 `planIngest`（INSERT **之前**）， 本体 `preinsert_gate.go`。墙钟预算 **150ms**（实测最坏 p95 仅 4~7ms ⇒ 20~50 倍 余量）、候选扫描上限 **100**（比异步侧 200 更紧，因为它在写路径上）。 🔴 **零远端 embedding**：闸恒用词项余弦（`deps.Embedder` 根本不参与）—— 远端 embedding 一次 2.3~3.0s 且对同文本返回不同向量（不可复现），不许摆在同步 路径上拍板。 ② **fail-open，绝不丢记忆**：候选源报错 ⇒ `gate:candidates_unavailable`；超预算 ⇒ `gate:budget_exceeded` ⇒ **照常 insert(active) + 投既有队列 + 留痕 + WARN**。 ③ **三态落库（落 merged，而不是"不插入"）**：确定性命中（字面重复 / 归一化等价 / 真包含）⇒ INSERT **直接带 `status='merged'` + `merged_into=<存活行>`**，存活行 `merged_from` 追加、`merge_count`+1 ⇒ **新行从不进 active、从不建向量索引**， 而**行与原文都在表里 ⇒ revert 无损**。若"干脆不插"，那条文本从未存在过行， revert 无从下手，违反 design/23 §8 的红线。 - **不与异步 D3 重复审**：闸做决定的那条 `Async=false`（留痕由闸自己落， 审计动作名 `memory.ingest.gate`）；真新/拿不准的走原有队列（留痕仍归异步层）。 - **开关**：`$DATA_DIR/config/memory-tidy.json` 的 `{"ingestGate": false}` ⇒ 一键回到 「只插不审」（= 改动前的异步行为）。**零新 env 键**（`.env` 未碰）。 - 顺手把 `store.go` 的行映射拆到 `store_rows.go`（守 §10 的 ≤500 行）。 验收（主会话复跑 + 亲自变异）：`go build ./...` + `go vet` 绿；memory 包测试绿； 我用 -overlay 摘掉闸的预算 ⇒ `TestIngestGate_Add墙钟有界` 与 `…failOpen_超预算绝不丢记忆` 变红（"Add 等了 2.0s，越过闸预算 150ms"）。 子代理另做 2 个变异（去掉预算 / 把 fail-open 改成 fail-closed）全红，并实测 **闸开 vs 关的 `Add` 额外墙钟：p50 ≈2.5~3.1ms、p95 ≈4~7ms**（基线批均值 35.8µs）。 ⚠️ 未部署（要一次 build + restart）；⚠️ 已知边界（如实）：闸只用词项余弦 ⇒ 「同义但字面差得远」拦不住（有意为之，由异步层/夜间整理兜）；闸的候选是**最新 100 条**（更老的重复闸看不到）；**并发同内容双写**仍可能两条都落 active（既有竞态， SELECT 与 INSERT 不在同一事务，非本次引入，第二层会清）。	2026-10-07 11:41:44 +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	9126d653e5	fix(memory): 读侧过 status 闸 —— 软删行不再被检索、不再进面板 ... 整理（tidy）与入库前审查（D3）都只做软动作：status 改 merged/archived， 正文一个字不改、行一行不删。因此只要有一条「能看到什么记忆」的读路径 漏了 status 闸，清理就等于白清 —— 生产库上那 10 条 merged 行就是反例。 - store.go：ListByPersona / List 加 status='active' - rules.go：ListScope / ListProject 加 status='active' - Get 刻意不过闸（撤销软合并要先读得到被吸收的行），并在注释里写明 - gateway/admin.go collectMemories 只加注释：口径只有一处，不重复过滤 验证：go build ./... + go vet 绿；memory 包全量测试绿； 新增 status_gate_test.go（4 条读路径逐条断言 + Retriever 端到端 「内容逐字相同的两条，软合并后只召回一条」+ Get 反向护栏）； 用 -overlay 把闸门变异成恒真 ⇒ 5 个读路径用例与检索端到端用例全红。	2026-10-07 09:48:37 +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	ffe2518bf4	feat(memory): 留痕表正式迁移 0025 + 保留期清扫（W5） ... - 迁移 0025_memory_ingest_reviews（幂等，既有部署重跑不炸/不丢行） - GC：保留期 720h + 条数上限 10 万行，挂进审查服务生命周期（Start 起 / Stop 停 / 启动先扫） - 过期即硬删（RevertMerged 只读 memory_items，删留痕不损失回滚能力） - 偏离一处并给理由：表只留 created_at（先例 0017；append-only；加 updated_at 需三份 DDL 真源） - 3 个变异自检（边界 <=/元组比较方向/Retention=0）	2026-10-06 15:59:16 +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	d6ed9cfa2b	feat(memory): 记忆整理「试算（dry-run）」入口 + 面板卡（契约 v0.75） ... 主人要「现在就想看到在 736 条上它会建议合并哪些」，而不是等 23:00 的低峰首跑。 - 后端：Tidier.DryRun + TidyService.DryRun，**复用同一条扫描→召回→判定→构造候选路径**（抽出 tidyRoundPolicy，生产轮与试算轮只差「候选出口」与「召回降级策略」两处；禁止第二套实现） - 🔴 零副作用：不写 memory_tidy_candidates / memory_tidy_runs，绝不改 memory_items 任何列；机械证明 = 跑前跑后 cyrene.db 与 -wal 的 SHA256 一致（测试断言「表行数不变」） - 失败码诚实：500 tidy_unavailable / 409 tidy_disabled / 500 tidy_recall_unavailable（**embedding 不可用不降级成 0 条**）/ 503 tidy_timeout / 500 tidy_dry_run_failed；**空数组唯一含义 = 算过了没建议** - 端点 POST /api/v1/admin/memories/tidy/dry-run（writeAuth）；面板「记忆」页加试算卡（点了才跑、无轮询、三态分开、明写「仅试算，不会改动任何记忆」） - 真机 e2e（741 条活库副本）：76 ms / 15 分区 / 53 候选 / 41 skipped / 1 vetoed(low_confidence)；样例 merge reason=fact_subset score=1.0000、link reason=similar_but_not_contained score=0.9248 - 变异：dry-run 顺手写库 ⇒ 两条测试红（行数 0→2）；自造阈值 ⇒ 红；失败回 200 空数组 ⇒ 红 - 如实登记：Compared=688 被 400/分区护栏截断、候选上限 20/分区被打满 ⇒ 护栏值需在 741 条量级重定（非 bug）	2026-10-05 22:06:54 +08:00
AskaEth	509dc412eb	feat(memory): 记忆 P2（项目索引物化 / decay 回写 / 作用域写规则 / 静默吞点 + loop 级只读红线测试）	2026-10-05 11:47:39 +08:00
AskaEth	91a3209c9b	feat(memory): 记忆整理 v1（design/23）——低峰定期扫描 + 事实包含判定 + 规则否决 + 只产建议队列（不自动应用）	2026-10-05 11:29:36 +08:00
AskaEth	cb564fe981	fix(memory): 空 query 不再触发语义回退 + 回退有界（修真机 39 秒召回） ... 真因（agent-197，文件:行）：只有附件的消息正文为空 ⇒ queryFromMessages 返回空串 ⇒ retrieve.go 的 vectorIndexScores 在问索引之前就 return ⇒ 上层分不清「没问过索引」与 「索引无命中」⇒ 打出误导的 no-candidate-hit ⇒ 转内存回退，把全库 302 条候选正文塞进 一个 embedding 请求（302 × 约 130ms = 39.3 秒，与实测 duration_ns 吻合）。 索引/维度/表/写入其实全是好的（PG vec_items 302 行全 dim=1024，与 SQLite 302 个 id 集合相同）。 修法：空/纯空白 query 整条语义路径跳过（不问索引、不 embed）；回退改为有界 （分批 32 + 1 秒时间预算 + 正文到向量 FIFO 缓存 1024，不再每回合重算）。 文件：retrieve.go / retrieve_semantic.go + 新增 retrieve_fallback.go / retrieve_keyword.go / retrieve_fallback_test.go（retrieve.go 曾达 501 行，按 ≤500 拆分）。 变异：去掉空 query 门 ⇒ 向量化 43 条文本（want 0）；整库单请求 ⇒ 69 条超上限 32；停用缓存 ⇒ 重复嵌入。	2026-10-05 08:04:47 +08:00
AskaEth	fbad02899a	fix(memory,loop,capacity): 打通记忆链三条空壳（P0-3 / P0-4 / P0-17，审计 §4.3） ... - P0-3 持久向量索引**不再空壳**：Store.Add 落库后真做 Embed+Add（失败只记日志、绝不让记忆写入失败）； NewRetriever 拿到 WithVectorIndex 时**自动接上写入路径**（无需改组合根）；索引无命中 → WARN + **回退内存余弦**； 新增每进程一次的**回填**（索引确实为空时把已落库条目向量化，分批 64、上限 512） - P0-4 工作记忆**按会话接线**：回合落定时写入（owner 会话 + 带会话 id 的窗口，LRU 上限 64）， 组装上下文时按会话读取 ⇒ 前导块真的出现；原单窗口 API 语义不变 - P0-17 L4 学习回环**真回写**：新增 capacity.Judge（只跑判定、不施人格覆盖/不发事件/不改状态）； loop 在回合落定"只写 owner 会话 + 跳过子代理分支"，写 ScopeUser（L4 的读域）+ 结构化溯源 - 顺带红线加固：意图记录是主人**原话**的机器可读形态 ⇒ **绝不注入群聊/陌生人块**（design/03 §5） - 复核：三条各自的包 build/vet/test 绿；「真生效」断言含生产构造路径（vector.New + 真实 SQLite 后端 + n-gram embedder）、跑完一轮窗口非空、L4 回写后能唤醒一个自身无强信号的表达； **5 条变异反证**（其中两条专门打「受限会话零写入」与「群聊不泄露主人原话」）均已还原 - 未做（登记）：Index.Search 无 ID 过滤（客户端按候选集过滤，极端情况走回退）；每条记忆一次 Embed	2026-10-04 14:20:22 +08:00
AskaEth	61cf80d5ee	docs(comments): 注释中文化 · internal/runtime/memory（31 文件，纯替换） ... - 只翻注释/文档字符串：820 增 / 820 删 严格 1:1；剥掉整行注释与行尾注释尾巴后， 逐文件与 HEAD 比对「代码部分差异 = 0」；裁决/design 编号计数逐项与 HEAD 一致 - 保留可执行 SQL 样例、SQLite 报错原文、pgvector/HNSW/ANN/BLOB 等技术词原文 - 复核：go build 绿 + memory/projectindex/vector 三包测试绿；gofmt 仅剩 2 个既有未格式化文件（改动前即如此，未顺手修）	2026-10-04 13:32:54 +08:00
AskaEth	0ce498754a	fix(memory,loop): 记忆作用域读写成对 + source_conversation 结构化（裁决 1.9/04.4.2/04.4.3） ... - 04.4.2/1.9 读侧：Retrieve 候选集并集 = 本人 persona 域 ∪ user 共享域 ∪ project 共享域（他角色 persona 域仍排除），群聊/陌生人取受限收窄 - 写侧：群聊/陌生人整段跳过记忆提取（可查不可写），persona 域仅属主可写 - 04.4.3：source_conversation 不再由 LLM 自由生成（prompt 不索要、候选结构不含该键），落库时无条件盖真实 {session_id,message_id}，编解码集中在 memory/source.go - 新增跨角色种子用例（原用例即使关掉并集也会通过）+ 成对用例「同群聊上下文：读得到共享域、写不进 store」 - 同步 store.go/retrieve.go 文档注释，与 design/03 §3/§4 口径一致	2026-10-04 12:07:44 +08:00
AskaEth	0624d9ee36	feat(session,runtime): 多角色并存—按会话选角（迁移0011 + 按回合解析 + agent池 + 提取器修正） ... 按 DevDocs/design/22 批次 1 后端（§2/§3/§4.1-4.5/§4.7/§5 验收 1-6）。 - 迁移 0011：chat_sessions.persona_id + chat_messages.persona_id（均 DEFAULT ''，无回填 → 升级零风险）；同步包内幂等 DDL；**真实库升级验证**（拷贝 data/cyrene.db 到临时目录跑 MigrateUp：既有 1 会话/109 消息 persona 仍为 ''，原库未被触碰） - history：SessionMeta/Message 加 PersonaID + SetSessionPersona；ListSessions/List/scan/Append 带上 - runtime：SessionEnv.PersonaID + loop.personaFor(ctx) 替换固定 l.personaID（memory/request/turn）+ **agent 池**（Options.Agents，按角色取 instructions，未命中回落）+ **提取器不再把 persona 烤死在构造期**（多角色下记忆不再永远记在 cyrene 名下）+ **thinking 旋钮改为按会话角色解析**（否则角色 Y 会用角色 X 的预算/展示） - gateway：会话 DTO/POST/PATCH 支持 personaId；ws/rest/voice 的 OwnerEnv 硬编改为**按会话解析角色**（actor 元数据语义不变）；admin memories 搜索去掉硬编 cyrene - Docs/api-client v0.42；**两处有意的行为收紧**已写明：POST /sessions body 非法 JSON → 400（原先完全忽略 body；空/null/{} 仍 201）；POST /admin/memories/search 省略 personaId 且无默认角色 → 400（原先默认查 cyrene） - 测试：design/22 §5 验收 1-6（记忆隔离/提示词首条 system/情绪按角色/提取 persona 归属/迁移兼容）+ 进程内 e2e（断言 adapter 收到的 model.Request.Messages[0] 即该角色的 systemPrompt） - **已知未做（留批次 2 / 待确认）**：① IM 与渠道级未做 → **§7-3「owner 私聊镜像随主会话角色」尚未生效**；② 请求级覆盖未实现（本批只做会话级）；③ **§7-5 的「上下文发送角色标记」只完成存储+DTO 半边**——消息 persona 已落库且 DTO 已带，但模型上下文不从 chat_messages 重建，「第 N 条是谁说的」尚未进上下文（需确认是否属批次 2）；④「切角色重建摘要」当前是空操作（压缩未接线）；⑤ thinking 旋钮仅在流式路径生效（非流式 agent.RunStep 不带，A 批次既有性质） - 验收：go build/vet/test 全绿 + linux/amd64 与 darwin/arm64 交叉编译（既有 flake 本轮未触发；同批 session_orchestrator.go 一度 501 行 → 抽出 session_tail.go）	2026-10-03 20:12:29 +08:00
AskaEth	31086ed1ab	fix(memory): 定宽时间戳存储 + rowid 确定性排序 + 遗留数据归一化 ... - formatTime 改用固定 30 字节布局(9 位小数秒)，让 TEXT 列的字典序与时间序一致（RFC3339Nano 会去掉尾随零产生变宽字符串，秒内会反序） - memory_items / project / project_chapter 的 ORDER BY 全部补 rowid 兜底，消除同 tick 打平时的顺序不确定 - 开库时幂等归一化变宽的历史值；无法解析的行原样保留，不阻塞开库 - 回归测试：变宽排序反例、同一时间戳插入序、归一化幂等与跳过	2026-10-03 16:08:50 +08:00
Aska	dbcf3df8a3	feat: RAG 知识库真实数据 + 渠道端到端接线（并行∦wire.go）+ 主会话收口 ... 【渠道端到端·接线（agent-72）】 - 新建 internal/services/channelbridge/：桥接服务（Start 对配置渠道 Connect(10s超时/warn)+SetMessageHandler+ReadMessages； 入站 UnifiedMessage→sessions.GetOrCreate(ResolveActor 白名单结构性识别)→loop.Run→SendMessage 回执，chat 文本）。 - cmd/cyrene/channels.go：从 CHANNEL_* env 读 4 渠道凭据（telegram/qq_obv11/weixin_ilink/webhook）。 - wire.go：app 加 channelBridge 字段，wireChannels 构造适配器+bridge.Start()，close() 收尾。 - 无真凭据降级：无 CHANNEL_* → configured()false 跳过不 dial；Connect 失败 Warn 不阻启动； webhook 仅入站(回执 ErrUnsupported 记 debug)。身份识别绝不靠提示词。收发端到端待凭据验证。 【RAG 知识库（agent-71）】 - internal/runtime/knowledge/：真实数据源（doc=资料/记忆=经历 分离 design/03 §3③）。 ListDocuments 走 projectindex.ListProjects(+ListChapters)、Search 走 projectindex.Search(标题/描述+章节 命中行+上下文)+retriever.Retrieve(配 vector 真语义,命中标 semantic:true)。 - gateway/server.go：RagStore 接口+Deps.RAG 可空+3 路由(GET /admin/rag、POST /admin/rag/query、/delete)。 - admin.go：adminListRag/adminSearchRag(空 query 400)/adminDeleteRag(写 501 not_implemented,M10)。 - projectindex/store.go：ListProjects/ListChapters。 - 前端 Rag.tsx：docs 从 GET /admin/rag 拉、检索走 POST /admin/rag/query、删除调真端点(501 显示 Notice)， 上传/分块/嵌入显示 M10 Notice；api.ts/types.ts 加 adminListRag/adminSearchRag/adminDeleteRag。 【主会话收口 wire.go】projStore 提到 app struct+wireMemory 赋值；knowledge.New(...) 注入 gateway.Deps.RAG。 实机验证：admin/rag 200(documents[] 空表非壳)、channels 枚举 4 渠道、health ok。 go build/vet/test 全绿 + 前端 tsc。wire.go 567 行。 遗留(记录)：① 群聊/陌生人 MemWritable 记忆隔离未接 loop(AGENTS.md 红线,待修) ② webhook InboundHandler 需 gateway 挂载 ③ RAG 语义路径 persona-scoped(project 记忆其他 persona 不浮现)。	2026-09-06 20:09:09 +08:00
Aska	24d5924cee	feat(model): Top5#1 结构化流事件 + WS 事件体系（对齐 OpenClaw AssistantMessageEvent） ... - 新增 model/stream.go：StreamKind(text/thinking/tool_call 各 start/delta/end + tool_execution) + StreamEvent{Kind,Delta,Index,ID}。 - ChatStream 签名 onChunk func(delta string)→onEvent func(StreamEvent)；loop OnStream 同改； streamStep 转发结构化事件。 - openai：text_delta + text_start/text_end（正文三段式）；anthropic：文本块 text_*/tool_call_* 按块 Index（content_block_stop 分支）真分段；fallback：有事件即交付。 - ws_hub：wsEvent 壳补 turnId/seq；新增 broadcastStream；streamChat 每帧打 turnId+seq； stream.go 把事件 publish 到 bus ws.stream。 - ws_bridge：streamEventData 映射 text_*→message.start/delta/end、thinking_*→thinking.*、 tool_call_*→tool_call.*、tool_execution_update→tool_execution.update，未知回退 stream_chunk。 - 前端 ws.ts：解析 message.start/delta/end、thinking.start/delta/end(pendingThinking)、 tool_call.start/end→addTool、tool_execution.update；保留旧 stream_chunk/thinking/tool_used 兼容； types.ts 补 turnId/seq。Docs/api-client.md 增 §3.1 v0.4。 已知限制（注释/文档标注）：turnId 在 OnStream→bus→relay 路径暂为空（StreamEvent 无 turnId 字段， bus ws.stream 载荷不带 turn）；OpenAI adapter 未解析 tool_call 段；thinking 段两 adapter 暂不发； tool_execution.update 是保留项（随工具循环钩子后置）。go build/vet/test + 前端 tsc 全绿。	2026-09-06 16:31:28 +08:00
Aska	04bfa2c7a7	feat(gateway): admin 列表端点接真实数据——persona/session/memory 补 List() 并注入 gateway.Deps ... 根因：gateway.Server 定义 SessionStore/PersonaStore/MemoryStore 接口但生产从未满足： - 底层 manager 无 List() 方法； - wireFrontend 的 gateway.Deps{} 未传 Session/Personas/Memories。 → /api/v1/sessions|personas 与 /api/v1/admin/{sessions,personas,memories} 恒返回 []。 改动： - persona/registry：Registry.List() []Character（并发安全、值拷贝）。 - channel/session：SessionManager.List(ctx)（查 channel_sessions 表+按 actor_role 重建）。 - runtime/memory：Store.List(ctx)（全表，复用 scanItems）。 - gateway 三 Store 接口改为返回域类型（Character/MemoryItem），映射统一放 collect* 侧。 - cmd/cyrene/wire.go：Deps 补传 Session/Personas/Memories。 - .gitignore：cyrene→/cyrene（锚定根，不再误伤 cmd/cyrene 目录）。 实机验证：/api/v1/admin/personas 返回 {id:cyrene,name:昔涟,isDefault:true}。	2026-09-06 14:05:34 +08:00
Aska	6ea5affc8a	test(vector): mock 对 dim<=0 不再除零（保持 dim0→ErrInvalidDim 意图）	2026-09-06 11:31:17 +08:00
Aska	111ad598be	fix(vector): New 在 embedder 维度未知(API 首请求前为0)时先 probe 一次学真实维度，避免 PG 向量索引 fallback	2026-09-06 11:30:26 +08:00
Aska	d947ec41a9	feat(memory): M4 记忆完善（三类作用域访问规则+项目索引分层+LLM异步提取+衰减溯源+向量接入，兼容既有57用例）	2026-09-06 06:15:18 +08:00
Aska	fb880572a4	feat(memory/vector): 向量检索引擎（SQLite BLOB 内积默认 + PG pgvector 真语义增强，配置后真生效）	2026-09-06 06:04:44 +08:00
Aska	ef79edd96a	feat(memory/projectindex): 项目索引分层（索引+描述+章节，Search 定位行+上下文，级联删除）	2026-09-06 06:01:20 +08:00
Aska	aa697c385f	feat(memory): 长记忆 store（SQLite+persona 隔离）/工作记忆滑动窗口/检索注入/手工提取钩子	2026-09-06 05:12:42 +08:00