7 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	589e26c887	fix(memory): 增量向量化 + 单分片逐条隔离，召回请求数降一个数量级（M61） ... M15（2026-10-13）登记的两条放大源落在记忆层，本次一并收口： 1. 整理轮/入库审查**只嵌增量**：新加 vector.Index.Vectors（SQLite/PG 实现， 按 id 取已存向量、维度不符当未命中），Store.embedIncremental 先复用索引里的 向量、只嵌缺的那些，并把手算出的向量回填索引 ⇒ 同一分区第二轮起零请求。 判据写明为「向量存在性 + 维度一致」（正文在本仓不可就地改写，故无需哈希）。 维度与当前 embedder 不一致时禁用复用并 WARN（不混两种表示）。 2. 嵌入链对单个慢分片有韧性：embedIsolated 整批失败后逐条隔离，坏的那几条 记缺口、其余照常返回；一条都没拿到才报错降级。请求数上界 1+B（B=8 ⇒ 9）， 服务整体挂死时一次即收手，不用「请求放大」换韧性。 3. 缺口/复用/回填条数进日志（缺口走 WARN），review 的被审条目拿不到向量时 如实返回错误 ⇒ 走既有词项余弦降级（不把「算不出来」说成「没有重复」）。 请求数（单测内假 OpenAI 兼容服务端计数，生产 API embedder + 真 SQLite 索引）： 24 条存量：修复前每轮 3 → 第一轮 3、第二轮 0 12 条分区整理轮：第一轮 2 → 第二轮 0 20 条候选的入库审查：26（201÷8）→ 第一条 3、第二条 0 一条坏正文：保住 7/8 条，代价 9 个请求；整体性故障 9 个请求后收手	2026-10-30 08:30:06 +08:00
AskaEth	42a07cb454	fix(config): 单条入库审查的墙钟上限收敛到唯一真源（M16） ... 生产启动行仍是 timeout=20s —— M15 把 memory 包的 defaultReviewTimeout 抬到 90s 的修复**从未生效**：config 层的 env tag 自己带着 default:"20"， env 层永远产出非零值，于是 memory 侧「≤0 才回落默认」的归一化成了死代码。 修法（二选一中的「① 让 memory 侧成为唯一真源」）：去掉 config 侧 MEMORY_REVIEW_TIMEOUT_SEC 的字面默认值，未配置时读出 0 = 「没配」， 由 normalizeReviewConfig 单点落地 90s。 生效值： .env / env 没写这个键 ⇒ 90s（唯一真源） 写了正数 ⇒ 原样生效（不做任何「保底抬到 90」的加码） 写了 0 / 负数 ⇒ 90s（与项目其它旋钮同一口径：≤0 = 用默认） 新增测试（走真实组装路径，不绕过任何一层）： config.LoadMemoryReviewConfig → ReviewConfig.Timeout → NewPreInsertReviewer → normalizeReviewConfig → 生效值（= 启动行打印的 timeout=） 断言生效值严格大于「实测最坏召回链 57s + T1 子超时 8s」，并断言启动行打印它。 变异自证（修前红）：把 tag 的 default:"20" 加回去 ⇒ 报出 「组装后 timeout = 20s」+「生效值 20s != 唯一真源 1m30s」 原有 TestEmbeddingTimeoutFitsReviewBudget 拦不住这条，因为它比的是**本包常量**， 看不见 env 层；注释里已写明「比常量」与「比组装后生效值」的区别（防后人重蹈）。	2026-10-13 23:09:19 +08:00
AskaEth	bdf3f3edaf	docs(embedding,memory): 复核 p2 的三处措辞改正（纯注释，零行为改动） ... review-m15 round1 判 p2-1items（fix-then-merge），三条都属「把证据能支撑什么写准」： 1. api.go 原写「最坏也只是这一片失败」与实现语义**相反** —— Embed 的实际语义是 「任一片失败 ⇒ 整条调用失败、其余分片已算完的工作量一并丢弃」。改为与该包 budget.go 里已经写对的那一句对齐，并点明调用方据此降级（记忆一条不丢、判定规则 一字不改，变的是这一条审查的召回质量）。 2. 「尖峰与批次无关」是**过度断言**：原证据只支持「至少存在一个与批次无关的外部/ 争用分量」（4 条/片也实测到 7.139s）；越界的**频率**是否随批次上升，1/40 vs 2/40 的样本不足以判定 ⇒ 改标为「归因未定」，并明说批上限取 8 的依据始终是硬证据 （16 条/片实测越界 + 真实代码路径 3 次里 2 次越界），**不依赖**任何成因推断 （原文与同文件「16 条越界故不取更大」的理由自相矛盾）。同时补上独立复核窗口的 对照（review-m15：24 次单请求 0 尖峰）说明尖峰强依赖窗口负载。 3. budget.go 的不变式不再被读成延迟保证：明确定性为「**稳态、空闲机器的建模拟合**， 用途是构造批形状」，并点名真正的兜底（90s 审查预算按整条链算 + 任一片失败即降级 的路径 + 已登记的链路韧性遗留）；结论句由「8 条/片不越界」改为「**空闲实测下**不 越界、负载下仍偶发越界」；perItemBudget 与 callBudgetShare 注释里「另一半／余量」 的同口径措辞一并改正（加一句：这是建模余量，不是单请求一定不越界的保证）。 另：preinsert_config.go 里「设计稿那一行待同步」已过期 —— 塔同日已把 design/23 §15 同步为 Timeout=90s，改为「已按实测同步」。 验证：go build ./... / go vet ./... 干净；go test -count=1 ./... 全绿； go test -race -count=1 ./internal/runtime/embedding/... ./internal/runtime/memory/... 全绿；diff 中无非注释行（纯文档改动）。	2026-10-13 22:12:11 +08:00
AskaEth	f3fb097630	perf(embedding,memory): 批上限 4→8 削掉请求放大，审查预算 20s→90s 覆盖实测链长 ... 实测（2026-10-13，本机空闲，活库 cyrene/user 分区 201 条、均长 34.7 汉字）： - 一条入库审查召回链 = 51 个「4 条」请求 = 23.070 / 21.860 s；旧审查预算 20s 比链长还短 ⇒ 每一条候选满额的审查都超时，且超时后 **一行留痕都不写** （7 天里 92.1% 的审查 recall_mode 为空、2274 条超时降级的根因） - 同一条链改成「8 条」= 26 个请求 = 21.435 / 21.597 s：请求数减半，墙钟几乎不变 —— 链路耗时由「条数 × 每条成本」主导，批次只改请求数 - 「16 条」在**真实代码路径**上 3 次里 2 次让单请求越过 5s 单次超时（1.818 / 5.016 超时 / 5.001 超时）⇒ 批上限不越过 8；隔离测量里 12 条 0.996~1.017 s 仍在界内 改动： - embedding: perItemBudget 500ms→300ms（实测摊销 70~107ms/条的约 3 倍） ⇒ DefaultBatchLimit 由 (5s/2−100ms)/300ms = **8**，同一套推演、两维都成立 （条数 100ms+8×300ms=2.5s；字符 100ms+480×5ms=2.5s，均在超时的一半内） - embedding: 新增 maxSafeBatchLimit=12（实测外沿）+ 编译期断言（越界即 uint 溢出、 编译失败），与 tidy_config.go 那条同手法 - memory: defaultReviewTimeout 20s→**90s**（> 实测最坏链：空闲 21.6s⇒4.2 倍余量、 与整理链并发 56.7s + T1 8s ⇒ 1.4 倍；不再大的理由=单 worker 有界队列 256 的 最坏积压 256×90s≈6.4h、服务真挂死时第一片 5s 就降级用不到这条预算） 测试（不留过时断言）：budget_test.go 加「钉值 8/480 + 两维不等式 + ≤12 外沿 + 16 条必须仍判越界」四层；api_url_test.go 的 reviewBudgetRef 20s→90s； preinsert_recall_test.go 新增跨包断言「预算 > 实测最坏链 + defaultT1Timeout」。 变异自证：perItemBudget 回 500ms ⇒ 钉值断言红；reviewTimeout 回 20s ⇒ 跨包断言红； perItemBudget 150ms（⇒16）⇒ 编译失败（constant -4 overflows uint）。三者均已逐字还原。 遗留（如实登记，未修）：① 整理轮每轮重嵌整个分区（user 一轮仍 250 个请求）， 解法方向是复用已入库的 vec_items 或给整理轮一个 embedding 请求预算；② 链路对单点 慢分片没有韧性 —— 一个分片失败即整条 Embed 失败、丢掉其余分片的工作量，且实测 任何批次形状都会偶发 >5s 尖峰（4 条 7.139s / 8 条 9.711s，与批次无关），方向是 重试/分片级容错，调常量解决不了。	2026-10-13 21:59:31 +08:00
AskaEth	21b906ffb0	feat(memory): D3 第五态 defer（入库审查）+ 提取留存规则闸 + 临时 TTL 配置面 ... 主人原话：「收窄提取器，确实要给他一个主动式的记忆留存规则，不能想到什么都 往记忆里写」「.env 只做兜底用 …这些键优先从面板配置上取」「临时记忆到期删除」。 按 design/23 §18（D3 第五态 defer）、§19（到期处置）、design/03 §9.6 （tempTtlSec 默认 7 天 + 坏值口径）、§10（提取留存规则）落地。 - IngestDecision 闭集加第五态 defer：照常 active 落库 + 写短 expires_at 落 临时层（不删行、不改正文，回滚 = 清空该列）；IngestRuleVersion d3.2 → d3.3。 - 落点：ingestGatePlan 增 ExpiresAt + expiresAt()（走 expiryText/formatTime 的 定宽 30 字节 UTC，与读侧时效闸同一套文本口径），由 finishIngest 在 defer 一态 补写 expires_at（INSERT 与补写之间的短暂窗口如实登记，方向 = 宁可多留）。 非 defer 三态一笔都不多写。 - T0 提取留存规则闸（extract_retention.go）：design/03 §10.5 的 N1~N5 纯规则， 接进 judgeIngest 的候选比对之前，命中即 defer + reason=t0_low_value，不进 T1； 两道护栏（显式「记住」/ 持久信号）一票放行，fail-safe 方向 = 宁可多留。 - T1 闭集扩为 merge/modify/keep/defer（同一个 prompt、同一次调用，绝不新增 第二次模型调用）：只有关系判为真新时才问价值；defer 要求 target=0，否则判 非法回落 create（reason=t1_reply_invalid）。 - 提取器提示词加固（design/03 §10.3 B）：正向清单 + 反例清单 + 「允许返回 []」。 - 临时记忆 TTL：代码默认 tempTtlSec = 604800（7 天）；面板 $DATA_DIR/config/memory-tidy.json 的 tempTtlSec 优先（ApplyReviewTuning 逐键 解析，坏值回落默认 + WARN，绝不写进 cfg）。该键在 .env 里没有出处且不新增 （.env 已冻结）⇒ 实际生效链是「面板 > 代码默认」。启动播种同步该键（*int + omitempty，nil 省略、绝不写 null），保证播种文件与生效值逐字一致。 - preinsert_store.go 的 listReviewCandidatesSQL 原位注释：这条内部召回 SQL 刻意不过时效闸的裁定与理由（design/03 §11.2 第 3 条）。 - 测试：defer 落库带短 expires_at（闸 + T1 两条路径）、写入口径与时效闸同源、 TTL 坏值与回落、规则版本 d3.3、整理候选幂等键不含 IngestRuleVersion、 提取规则正例 11 条 / 反例 11 条。 验收：go build ./... + go vet ./... + go test ./... 全绿；windows/darwin 交叉 编译通过（GOOS=darwin GOARCH=arm64 / GOOS=windows GOARCH=amd64）。	2026-10-13 20:22:48 +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	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