LifeOS Cortex 本地记忆检索完整解析：隐私边界、确定性重建与证据门控

LifeOS Cortex 本地记忆检索完整解析隐私边界、确定性重建与证据门控【免费下载链接】LifeOS⛰️ LifeOS — The universal AI Harness designed to move you from Current to Ideal state in both life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS不建向量索引、不起常驻进程本地记忆检索如何做到可验证LifeOS Cortex 给出的答案是一个构建在既有文件型记忆系统之上的本地 Bun CLI它不提供网络服务不引入任何外部存储只用bun一条命令提供可验证的检索与受控写入。1. 定位与非目标没有向量库、没有守护进程Cortex v1 的全部实现入口是 Cortex.ts共 8 个子命令。它的职责边界在三件事之外全部为否不做 MCP 服务器或 HTTP 服务、没有守护进程不被调用就不启动、不提供跨设备同步或远程变更不引入 Chroma、CMEM、外部遥测或向量索引因此也不是第二个记忆运行时。随系统发布的进程内适配器工厂 CortexAdapter.ts 为claude、hermes、codex、subagent四种身份提供工厂方法。createCortexAdapter返回的对象经过Object.freeze冻结status/search/timeline/get/export方法均为只读remember/propose虽然暴露在接口上但每次调用默认同样只读——⚠️ 是否允许写入由每次调用单独决定身份本身不带写权限。实现上写方法只有在writePermission(options)校验出allowWrite为布尔true时才向底层命令追加--allow-write选项对象里出现任何非allowWrite的键权限判定直接返回null并整体拒绝。当前隐私边界的覆盖范围是reviewer 输入、reviewer 调试/错误产物、进入MemorySystem.add()及其受治理持久化路径的类型化条目以及 Cortex search/timeline/get/export/rebuild 使用的规范读。其余 hooks 与通道专属采集写者仍走原有路径直到被显式集成——不存在一个通用适配器守护进程。2. 调用方契约根解析、响应信封与退出码所有命令都以同一形式调用bun LIFEOS/TOOLS/Cortex.ts command [arguments] [options]每个命令都接受--memory-root dir和可选的受识别适配器身份--adapter claude|hermes|codex|subagent。选项表是严格的每个命令有固定的允许集合未知选项、重复选项、缺值、命令不适用某选项一律被拒绝而不是被忽略进入退出码 4 的invalid_input。2.1 规范根解析与符号链接边界规范根按优先级解析测试/运行时注入的memoryRoot→--memory-root命令行选项 → 环境变量CORTEX_MEMORY_ROOT→ 默认值~/.claude/LIFEOS/MEMORY。一个刻意的取舍顶层的规范别名symlink被允许。pinCanonicalRoot对根目录执行一次realpath、确认目标是目录把解析后的真实目录钉住作为信任边界并在status中报告被钉住的路径。默认的LIFEOS/MEMORY符号链接指向私有用户数据仓库~/.config/LIFEOS/USER/MEMORY时能直接工作靠的就是这一步调用者无需手动解析别名。但钉住根之下的任何符号链接都被禁止checkedRealpath每次遍历到文件/目录都先lstat判定是否为符号链接再校验realpath是否逃逸出钉住的根越界即抛IntegrityError。一次通过验证的status运行会把默认别名解析到私有用户数据仓库并报告钉住路径与规范记录数。status同时报告mode:local-read-only和indexes:[]——它描述的是契约与语料形状不测量健康。2.2 五字段响应信封每条命令向 stdout 写恰好一个 JSON 对象五个字段缺一不可、多一不行{schema:lifeos-cortex/v1,ok:true,command:status,data:{},error:null}失败时保持同样的五个顶层字段ok:false、data:nullerror承载{code, message}。发布版 JSON Schema 为LifeOS/install/LIFEOS/TOOLS/schemas/lifeos-cortex-v1.schema.jsonsuccess 与 failure 两种形态均声明additionalProperties:false并用oneOf互斥约束。validateCortexEnvelope校验字段集合恰好为command/data/error/ok/schema、schema 常量值、以及ok与error/data的一致性每次ok(...)/fail(...)构造结果后都先过一遍这个校验器再返回——信封自校验是库内建的不依赖调用方。2.3 退出码与信封对照⚠️ 调用方必须同时使用进程退出码和信封能解析出 JSON 并不意味着成功。退出码含义典型错误码0成功—1未预期的内部失败internal_error3显式 ID 或扩展根未找到not_found4非法命令、选项、payload、过滤器、边界值或规范完整性问题invalid_input、integrity_error5缺少写授权或既有治理拒绝变更write_refused、governance_refused3. 只读检索怎么用search、timeline 与渐进披露3.1 BM25 参数与过滤器语义检索基于本地 BM25词元按[a-z0-9]切分。rankBM25的完整参数化idf 采用log(1 (n-df0.5)/(df0.5))平滑tf 饱和系数 2.5长度归一化b 0.25 0.75·len/avgdl同分按 ID 字典序稳定排序。bun LIFEOS/TOOLS/Cortex.ts search query \ [--type TYPE] [--source SOURCE] [--session SESSION] \ [--from DATE] [--to DATE] [--page N] [--page-size N] \ [--recency WEIGHT] \ [--expand ID --max-nodes N --max-tokens N]--type、--source、--session是精确匹配过滤器--from/--to对记录的created时间戳做闭区间过滤。--recency必须是有限非负数它对updated时间加权但不替代词法相关性。可选图扩展从显式--expandID 出发沿规范relatedID 做广度优先遍历返回有界卡片——它不构建也不查询任何持久化图数据库预算默认 10 个节点、2,000 估算 token。代表性 1,500 条记录的契约检索在测试中限定于 1.5 秒以下。3.2 渐进披露卡片search 只给卡片不给正文检索只返回卡片从不返回正文这是渐进披露的核心。卡片包含且仅包含id、type、created、updated、provenancesource、可空session、相对path、数值score和est_tokens——没有content也没有任何摘录。est_tokens等于净化后正文字符数除以 4 向上取整。列表响应包含精确过滤后的total、从 1 开始的page、page_size和items默认第 1 页、每页 10 条。3.3 timeline 锚点与 get / export 的全或无timeline的锚点可以是活跃记录 ID 或合法日期bun LIFEOS/TOOLS/Cortex.ts timeline --anchor ID_OR_DATE \ [--before N] [--after N] \ [--type TYPE] [--source SOURCE] [--session SESSION] \ [--from DATE] [--to DATE] [--page N] [--page-size N]结果按created排序、同刻按 ID 排序ID 锚点在中心记录仍落在所选过滤器内时包含中心记录本身日期锚点返回请求数量的邻接记录。before/after默认各 5可为 0。get与export只返回显式选中且活跃的 ID 的完整净化记录⚠️ 任一请求 ID 缺失、已过期或尚未生效整条命令以退出码 3 失败all-or-nothing。export尽管名字像写操作实际只是把选中记录序列化为lifeos-cortex-export/v1payload 打印到 stdout不创建任何文件——它是披露动作不是写动词。4. 写入为何难remember 与 propose 的双重授权remember与propose是唯一的变更契约命令bun LIFEOS/TOOLS/Cortex.ts remember typed-item-json \ --adapter claude|hermes|codex|subagent --allow-write bun LIFEOS/TOOLS/Cortex.ts propose typed-item-json \ --adapter claude|hermes|codex|subagent --allow-write授权模型是双重绑定。其一身份与授权分离必须同时给出受识别的显式--adapter和--allow-write只命名适配器本身不授予任何写权限。其二命令与条目判别器绑定remember只接受type:memory、type:idea或type:knowledgepropose只接受type:proposal不匹配在调用MemorySystem.add()之前就被拒绝。每条命令恰好接受一个 JSON payload把一个已授权的条目委托给MemorySystem.add()。既有的变更分层mutation tiers、目标钉住target pinning、提案审批、审计日志、快照、源所有权与收缩守卫shrink guards保持权威地位。⚠️ 治理拒绝时以退出码 5 结束不存在部分成功。5. 隐私与完整性边界fail-closed 的每一个环节5.1privatespan剥离规则与 fail-closed显式私有 span 使用类 HTML 标签public privatenever persist or export this/private publicstripPrivateContentCaptureEnvelope.ts的匹配语义不区分大小写容忍无害的空白与属性嵌套 span 整体移除用深度计数而非单条正则孤儿闭合标签作为控制标记移除保留其两侧公开文本。边界是 fail-closed 的未闭合的开头标签会从该位置起抑制字符串的剩余部分任何归一化后看起来像 private 开头标签但格式不良的构造——NUL/控制字符插入、全角 Unicode、丢失的右尖括号——都按不可信开头处理并 fail closed不做宽松的 HTML 恢复。该边界的应用点覆盖全链路reviewer 推断之前、reviewer 调试/错误序列化之前、类型化条目路由、规范词法排序、图扩展、get、export 与 rebuild 之前。类型化条目的净化是递归的覆盖 content 以及承载持久化语义的元数据标题、名称、rationale、session provenance、entries、related slugs剥离后变空的必填字段会被拒绝。源中立的CaptureEnvelope携带source、channel、timestamps.captured_at加可选source_at、可选valid_from/valid_until、可选session_id和content。真正的摄取助手ingestCaptureEnvelope(input, consumer)先剥离私有内容再把净化后的 envelope 交给给定 consumer。fixture 覆盖 Claude、Hermes、Codex、子代理与一个消息通道——这证明助手与 envelope 能够表示这些来源只有显式调用该助手的调用点才受边界保护不声称所有既有来源或 hook 已被自动迁移。⚠️ 原生 harness 转录可能在 harness 文档所述的 30 天保留期内保留private内容这超出 Cortex 的控制范围。Cortex 不触碰转录字节只在 reviewer 推断或持久化/导出之前剥离受控副本。私有标签是持久化与处理边界不是对 harness 转录、终端滚动回显、上游提供方日志、或标签到达 Cortex 之前已发送内容的清洗承诺。5.2 有效期窗口规则valid_from含边界、valid_until不含边界缺失的边界视为开放非法边界 fail closedDate.parse产生 NaN 即返回 false。search、timeline、get、export 默认排除查询时刻不生效的记录。--from/--to过滤是另一维度约束的是created时间戳不覆盖也不替代有效期判定。5.3 规范完整性与语料级上限规范记录的完整性要求ID 唯一且非空created/updated为合法时间戳缺失 Markdown ID 的记录获得稳定的路径派生 IDpath: 路径 SHA-256 前 16 位provenance 使用相对于规范根的路径因此更换绝对根别名不会改变记录摘要规范读会再次执行隐私净化防止旧的已标记内容绕过当前边界。完整性问题一律以integrity_error失败、退出码 4触发条件结果钉住根之下的目录/文件符号链接、realpath 逃逸integrity_error退出码 4重复的记录 IDintegrity_error退出码 4格式错误的 JSONLintegrity_error退出码 4不可能的时间戳updated早于created、valid_from valid_until、非法日历日期integrity_error退出码 4非常规模块文件symlink、socket 等integrity_error退出码 4语料级上限超出10,000 文件 / 单文件 8 MiB / 总量 128 MiB / 50,000 记录integrity_error退出码 4语料级上限在读取任何内容之前检查。5.4 规范源与 no-index-v1 标记Markdown 与 JSONL 保持规范地位派生索引是可丢弃的不能成为事实源。默认 CLI 检索语料是既有的KNOWLEDGE/树排除下划线和点号前缀的路径当给定规范根下存在根级*_MEMORY.md文件时也会被纳入。canonicalFiles按KNOWLEDGE→MEMORY/KNOWLEDGE→ 根本身三级回退因此带有MEMORY/KNOWLEDGE/布局的 fixture 受支持用于隔离测试。LifeOS/install/LIFEOS/CORTEX_INDEX_POLICY.json是一个肯定性的lifeos-cortex-index-policy/v1标记内容为policy:no-index-v1。标记存在且无索引清单时BM25 直接读规范文件status报告indexes:[]rebuild不创建任何东西健康检查将此明确状态报告为健康的no-index-v1——不会为了证明未采用索引而遍历或哈希整个语料。清单与策略标记双双缺失时索引状态是歧义的健康检查仅告警index-evidence-missing标记格式错误则是 critical。6. 证据门控确定性重建、检索基准与运营健康6.1 rebuild可重建性的只读证明bun LIFEOS/TOOLS/Cortex.ts rebuild --from-canonical显式 flag 必填。rebuild 规范化规范记录分别对规范视图和重建视图计算 SHA-256 摘要在lifeos-cortex-canonical-rebuild/v1payload 中报告equivalent、记录数与indexes:[]。它不创建任何索引摘要相等证明的是Cortex 记录视图可被确定性重建不是源文件的逐字节重写。6.2 检索基准如何避免假对比版本化的带标签查询集位于LIFEOS/MEMORY/BENCHMARKS/cortex-retrieval-v1.jsonl。标签文件存放在私有 MEMORY 树中由操作者在自己的语料上、首次基准运行之前自行编写不随系统发布。每行 JSONL 提供 query、期望 ID、可选的期望时序、可选的已知假阳性 IDCortexBenchmark.ts 还要求每行标签携带lifeos-cortex-benchmark-label-provenance/v1溯源证明期望 ID 来自真实live-cortex-cli执行与人工语料核验。bun LIFEOS/TOOLS/CortexBenchmark.ts \ --labels LIFEOS/MEMORY/BENCHMARKS/cortex-retrieval-v1.jsonl \ --memory-root LIFEOS/MEMORY \ --output LIFEOS/MEMORY/BENCHMARKS/cortex-benchmark-v1-YYYYMMDD.json方法学上最关键的一点基准导入生产代码——activeCortexRecords、rankBM25、toCortexCard与规范摘要函数——而不是携带一份基准专用的排序器。每条带标签查询运行 25 次每个查询/样本只做一次生产排序并把同一份排序结果在两种披露测量间共享bm25-baseline序列化完整 top-5 记录progressive序列化 top-5 卡片、仅抓取被选中的第一条完整记录。排序质量被刻意保持完全相同被比较的是披露与注入成本不是两个检索算法。每个配置报告Recall5、MRR、时序成对排序准确率、假阳性召回、注入 token、p95 延迟、延迟样本数、语料盘上字节数、实测磁盘增长、后代进程数、峰值 RSS、执行路径名另含语料分词次数与排序运行次数防止卡片优先的比较掩盖重复的检索工作。报告 schema 为lifeos-cortex-benchmark/v1stdout 始终收到报告持久化输出通过--output显式开启必须位于解析后的MEMORY/BENCHMARKS/目录之下、使用版本化文件名cortex-benchmark-vN-*.json且不覆盖已存在的报告。报告记录语料/标签摘要、精确命令、时间戳、生产排序器与有效期路径、披露路径、top K 与样本数。它是针对操作者自己语料与标签的、可复现的时点本地测量不是普适性的延迟或质量声明。6.3 向量索引的采用门槛当前vector_config为null没有向量基准候选也没有向量索引。采纳向量或混合索引的前提是一份带标签的报告证明了相对渐进式 BM25 的检索质量提升且索引必须可规范重建、并保持在单独文档化的磁盘与进程边界内。⚠️ 仅仅降低 token 用量不构成采纳向量索引的证据。6.4 运营健康缺失的证据永远不产生绿灯Cortex.ts status报告契约可用性与语料形状运营健康来自另一个工具bun LIFEOS/TOOLS/MemoryHealthCheck.ts --json机器可读报告包含overall、实测证据、生效阈值、findings以及按 ok/warn/critical 派生的健康退出码 0/1/2。默认阈值如下证据默认阈值越界结果Reviewer 成功新鲜度7 天陈旧时 WARN进行中 reviewer 终行宽限10 分钟CRITICAL 超时检索证据新鲜度24 小时缺失/陈旧时 WARN待审提案积压大于 10WARN可观测性字节数大于 256 MiBWARN最老可观测性日志年龄大于 30 天WARN已采用索引新鲜度大于 7 天WARNCortexHealth.ts 的评估器遵循一组硬规则最新 reviewer 证据优先于历史成功——最新一次 reviewer 运行失败、解析失败、超时、格式错误、schema 不完整或无效均为 CRITICAL新运行目录在 10 分钟宽限后仍无终行即判超时格式错误的 JSONL 被暴露而不是静默跳回上一次成功非法或未来时间戳不能证明新鲜度提案证据只统计状态恰为pending的行格式错误的提案 JSONL 告警可观测性证据递归测量MEMORY/OBSERVABILITY/下全部.jsonl与.log文件报告字节数、文件数与最老 mtime检索证据来自最新一行有效的memory-retrievals.jsonl。对未来的派生索引lifeos-cortex-index/v1清单必须给出规范 SHA-256、索引路径与 SHA-256、indexed_at清单非法、路径违规、索引字节缺失、规范不匹配或索引字节不匹配均为 CRITICAL。阈值覆盖只接受有限正数值非法值产生 critical 的cortex-threshold-invalidfinding而不是让比较失效。运营覆盖变量CORTEX_RETRIEVAL_STALE_MS、CORTEX_PROPOSAL_BACKLOG、CORTEX_OBSERVABILITY_MAX_BYTES、CORTEX_OBSERVABILITY_MAX_AGE_MS测试/自动化路径CORTEX_HEALTH_ROOT、CORTEX_HEALTH_NOW、CORTEX_INDEX_MANIFEST、CORTEX_HEALTH_NO_WRITE、CORTEX_HEALTH_REPORT_PATH。已验证的缺失清单是健康的no-index-v1词法基线它不是把未测量的索引状态称为健康的借口每次运行的输出记录的是当前证据不是永久健康保证。7. 非目标清单与延伸阅读当前升级不提供的能力作为定位的负空间清单一次列清MCP 服务器或网络 API跨设备或云端同步CMEM / CMEM Cloud / Chroma / SQLite FTS / 嵌入 / 向量索引外部 Cortex 遥测Cortex 守护进程或常驻 sidecar所有 hook/通道/采集表面的自动采纳对原生 harness 转录的清洗从搜索结果自动注入完整记录。延伸阅读相对仓库根的路径Cortex.ts — 8 个子命令、信封自校验与退出码实现CortexAdapter.ts — 进程内读/写适配器工厂与逐次写授权CaptureEnvelope.ts — private span 剥离与有效期判定CortexBenchmark.ts — 基准方法与lifeos-cortex-benchmark/v1报告CortexHealth.ts — 证据收集与 fail-closed 评估LifeOS/install/LIFEOS/DOCUMENTATION/Memory/MemorySystem.md— 记忆架构、策展分层与写者清单LifeOS/install/LIFEOS/DOCUMENTATION/Observability/ObservabilitySystem.md— 健康证据与本地可观测性管线LifeOS/install/LIFEOS/CORTEX_INDEX_POLICY.json—no-index-v1策略标记LifeOS/install/LIFEOS/TOOLS/schemas/lifeos-cortex-v1.schema.json— 信封 JSON Schema适用前提运行环境要求 Bun 运行时与已部署的~/.claude/LIFEOS/MEMORY或CORTEX_MEMORY_ROOT指定的规范根私有 MEMORY 树中的基准标签、检索日志与索引清单均为操作者本地资产不随开源仓库分发。【免费下载链接】LifeOS⛰️ LifeOS — The universal AI Harness designed to move you from Current to Ideal state in both life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考