2 Commits

Author	SHA1	Message	Date
JianFeeeee	2330db8a2b	refactor(memory): 移除 media_refs/引用计数，媒体成为一等记忆块 ... 媒体此前是"文本块 + digest 引用 + owner 账本 + 独立 GC"：ContextEvent.Media 记 digest，media_refs 表用 owner_kind/owner_id 保活，ref_count 决定 GC 能否清。 这与文本记忆块的管理方式不一致，也是本次一并纠正的核心偏差。 改为与文本块完全一致的生命周期： 1. 一等记忆块直接由所在层持有 - ContextEvent.Blocks / Doc.Blocks / GraphDB memory_blocks - 块带 modality/digest/MIME/size/vector/fingerprint，文本、图片、视频同构 - Context→Document→Graph 迁移的是块本身（ID 不变），迁移后清空源容器， 同一块不同时存在于两层 2. 删除平行生命周期账本 - media.Store 去掉 media_refs 表、OwnerKind 常量、RefCount 字段、 AddRef/DropRef/DropOwner/Refs、ref_count 列与索引 - 删除 mediaGCLoop、GC(keep,minAge)、容量上限与 media.gc_* / media.max_mb 配置 - 媒体内容在块被永久删除时一并删除（media.Store.Delete + forgetPayloads）， 与"删除文本块即删除内容"同一语义 3. L3 原生结构 - memory_blocks / memory_block_edges（contains/depicts/derived_from） - 边端点必须是真实图节点，不再用 owner 字符串伪装关系 - BlocksForNode 支持 sentence --contains--> block 反查 4. SDK 与检索同步 - 插件附件/标记直接变成块，不再 AddRef - 跨模态检索改用 QueryMediaScored（CAS 内不再有孤儿缓存需要过滤） 测试全部改写为块语义：删除 refcount/media_refs/GC 断言，新增块迁移、 单层不变量、Delete 语义与并发删除回归。 注：cmd/homed/main.go 同时携带工作区中既有的 CLIP→Qwen 模型目录接线改动。	2026-09-11 10:57:22 +08:00
JianFeeeee	c552948d10	test(memory): 媒体存储的压力、冒烟与长稳测试 ... 在 aeb1c97 的 CAS 层之上补齐三类验证。 ## 压力测试（stress_test.go，9 例） 核心不是吞吐数字，而是并发下的不变量。为此写了 checkRefIntegrity： 用 SQL 对比每个 digest 的 ref_count 与 media_refs 实际行数。这条对不上 就意味着 GC 的判断依据是错的——计数偏低会误删有引用的内容，虚高会让 孤儿永远清不掉。所有并发用例收尾都验它。 - 32 goroutine 并发 Put 同一内容 → digest 一致、磁盘只 1 份 - 400 个不同内容并发入库 → 无丢条目、逐条回读无内容串位 - 24 worker × 40 轮引用增删风暴（含故意重复 AddRef 验并发下的幂等） - GC 与读写并发 1.5s → 实测 11508 次 Put / 604 轮 GC，受保护内容零失败 - Describe 与 Search/Pending 并发 → 无 database is locked - 容量上限持续加压 → 上限 256KB 收尾 98KB，有引用项全存活 - 重度 churn 后重开 → 磁盘文件数 == 元数据条数，无双向孤儿 - 4MB 单文件往返（see_video 10 帧 × 2MB 是现实上限附近） - data URL 往返 ×50（SetToolBlocks 给出的实际形态） -race -count=3 干净。 ## 冒烟测试（smoke_test.go，6 场景） 走真实数据路径：真 PNG（自建 IHDR/IDAT/IEND + zlib）、真 data URL、 真 sha256、真 GC、真重启，而不是随机字节。 - 同一张截图连问 5 轮 → 磁盘 1 份、5 个 context 引用 - see_video 6 帧内容各异 → 各存一份、共享一个 owner - 描述落库后按关键词检索命中（方案 C 最关键的一环：blob 可被淘汰， 描述会长期留在记忆里） - L0→L2 归档时引用从 context owner 转到 document owner，期间内容可读 - 别的工具留下的一次性图被 GC 清掉，被记忆引用的一个不少 - 全生命周期跨重启：描述、引用、内容、磁盘一致性全部完好 第一次跑挂在「6 帧只搜到 5 条」，看着像存储丢帧，实际是夹具的 palette[(variant+y*3/h)%5] 只有 5 色，variant=0 与 5 产出逐字节相同的 PNG，被 CAS 正确去重。已把 variant 写进像素保证帧间真不同，并把这段 经过记进注释——误报本身证明了去重在工作，也证明冒烟确实有能力发现 「帧数对不上」这类问题。 冒烟原先是 internal/memory/media/smoke/ 下带 //go:build smoke 的独立 main，得记着加 -tags smoke 才跑得到，那种早晚被忘掉。已搬成普通测试， 随 go test ./... 一起跑，冒烟的意义才真正成立。 ## 长稳测试（soak_test.go，-short 下跳过） 60 秒五路混合负载。实测：put=281885 get=1644084 gc=9142 describe=53875 search=23268 refOps=187926，零失败。收尾 20 个受保护项 内容字节一致、ref_count 全为 1；8MB 上限下实际占用 139KB / 48 条， 说明 28 万次写入产生的孤儿被持续清理，无无界增长。 描述者从 Pending() 取项再 Describe()，GC 随时可能在这两步之间清掉它。 这是正常竞态，故忽略 unknown digest 并注明原因；5 万多次调用没把它 升级成计数错位，印证了 Describe 对已删项返回错误而非静默建条目的选择。 全仓 go build / go vet / go test 通过，SDK 接口冻结 diff 为 0。	2026-09-04 11:29:18 +08:00