Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
c2c4d5ff8a | ||
|
|
3c8d662ad0 |
No files matched your search
@@ -26,6 +26,9 @@ package-lock.json
|
||||
ui_walkthrough_*/
|
||||
|
||||
# Internal release/open-source coordination must never enter the public tree.
|
||||
HANDSOFF.md
|
||||
新鲜度_todo.md
|
||||
memhub/docs/LOCAL_PRODUCT_APP_MIGRATION_TEST.md
|
||||
OPEN_SOURCE_TODO.md
|
||||
release_todo.md
|
||||
|
||||
|
||||
-87
@@ -1,87 +0,0 @@
|
||||
# HANDSOFF — MemHub / Hy Memory 架构改造
|
||||
|
||||
更新:2026-10-21
|
||||
权威细则:[`memhub/docs/ARCHITECTURE.md`](memhub/docs/ARCHITECTURE.md)(~~旧删线~~ + 新并列)
|
||||
配套:[`memhub/MEMORY.md`](memhub/MEMORY.md);其余 docs 已打「架构变更」条,冲突以 ARCHITECTURE Top Rules 为准。
|
||||
旧用户迁移:[`memhub/docs/contracts/sdk-data-plane-migration-v1.md`](memhub/docs/contracts/sdk-data-plane-migration-v1.md)。
|
||||
|
||||
> 根目录原先无有效 `HANDSOFF` 文件;本文件为清空后重写,只保留本次架构改造交接。
|
||||
|
||||
---
|
||||
|
||||
## IMPORTANT:测试执行规则
|
||||
|
||||
1. 先完整运行目标测试套件一次,收集**全部失败 case**。
|
||||
2. 按根因分组并批量修复,不得用 `-x` 反复重跑已经通过的前置测试。
|
||||
3. 修复后只重跑上次失败的 case。
|
||||
4. 失败 case 全部通过后,才再完整运行一次目标套件作为最终 gate。
|
||||
|
||||
## Top Rules(现行根本)
|
||||
|
||||
1. **所有对 memory 的读写(含存储 backend)都交给 SDK**,经 SDK config / env 配置。
|
||||
2. **MemHub 内对 memory 的原子操作也一律经 SDK**;缺接口 → **先补 SDK client**,禁止 Core 直改 VDB/Graph/SDK 私库或再维护正文权威。
|
||||
3. **MemHub 不存 memory 实体 / 引擎侧关系**(正文、supersede 权威、向量图副本等)。主责是管理面:harness、LLM model、异步写入队列、config、Core/Runtime 状态。
|
||||
- **可以且应当存 `memory_id`**(SDK 给外层的唯一身份)及组织元数据。
|
||||
- Matter 占位功能未发布,删除其表与入口;未来若重做,必须另立合同。
|
||||
|
||||
**推论:**
|
||||
|
||||
| 旧 | 新 |
|
||||
|---|---|
|
||||
| MemHub `evidence*` 原文权威 | 原文 → **SDK raw**;Evidence 权威拆除 |
|
||||
| `governed_*` 列表/版本/supersede 权威 | 拆除方向;UI/纠正/删除 → **授权 + SDK API**;组织层只挂 `memory_id` |
|
||||
| SDK success 后再镜像进 Governance 才算产品写入 | SDK 合同为准;MemHub 至多记 `memory_id` / 任务回执 |
|
||||
| 拦 CRUD / parse ops 双写 supersede | 禁止作为目标架构 |
|
||||
|
||||
---
|
||||
|
||||
## 已改文档(合同先于代码)
|
||||
|
||||
- 重写:`memhub/docs/ARCHITECTURE.md`、`memhub/MEMORY.md`
|
||||
- 条幅 + 关键段新旧对照:`contracts/*`(含 runtime-unification / unified-context-read / source-adapter 等)、`INSTALLATION.md`、`DEVELOPMENT_LOOP.md`、`MEMORY_EVENT_TIME_SCHEDULING_PLAN.md`、`PRODUCT_LOG_TROUBLESHOOTING.md`、`harness-support/README.md`
|
||||
- 各 harness 专页未逐段改写 → 冲突时以 ARCHITECTURE 为准
|
||||
|
||||
**代码尚未按此拆除。** 文档是目标架构,不是已完成迁移。
|
||||
|
||||
---
|
||||
|
||||
## 建议实现顺序
|
||||
|
||||
1. 冻结新功能写入 `governed_*` / MemHub `evidence*` 权威路径。
|
||||
2. 记忆库 UI / recall:授权 + SDK list/get/search/update/delete;组织层只挂 `memory_id`。
|
||||
3. 导入/同步:写入 SDK(含 raw);退役 Evidence 权威。
|
||||
4. 队列降级为「调度 SDK 调用」,完成态以 SDK 可验证结果为准。
|
||||
5. 清空/删除镜像台账;缺的能力开 **SDK PR**,不在 Core 补影子表。
|
||||
|
||||
旧用户的数据迁移不是独立的手工升级步骤:由 App 在可见的启动 loading
|
||||
阶段、Core 开始提供产品读写之前,完成 bundle、可续跑 backfill、reconciliation
|
||||
与最终 cutover。失败或缺少前置配置时 marker 保持未提交,不允许静默进入双写。
|
||||
|
||||
Fresh install 直接创建最新管理面 schema,禁止创建 `evidence*`、`governed_*`
|
||||
及旧 retrieval/Matter/session-shadow 表。Legacy upgrade 在 bundle 与 SDK
|
||||
迁移校验完成后物理 DROP 这些旧表;备份 bundle 才是审计/回滚载体,不在 live DB
|
||||
保留一套“兼容权威”。
|
||||
|
||||
---
|
||||
|
||||
## 管理面仍属 MemHub(勿误拆)
|
||||
|
||||
- harness:`source_grants`、sync desired-state(`config.json`)、适配器扫描(产出进 SDK,不是 Evidence 权威库)
|
||||
- model profiles / 密钥边界 / 模型内容许可
|
||||
- `memory_write_jobs` 单层异步队列、FIFO / event-time 调度与租约(始终属于 MemHub;调度,不是 memory 实体)。旧 `memory_tasks` 二级队列与 task receipt 删除。
|
||||
- pending job 尚未调用 SDK,因此没有 raw/memory ID;worker 对 SDK 只调用一次
|
||||
`add()`,SDK 内部完成 raw + extraction/reconciliation,成功后 MemHub 仅保存
|
||||
返回的 raw ID / memory IDs 与 outcome。禁止“先 import_raw 再排 extraction”。
|
||||
- Core / Runtime 收据与健康
|
||||
- Matter 尚未形成已发布产品合同;删除全部 `matter*` 占位表与运行时入口。未来若重新开发,
|
||||
以新合同重新设计,不为当前占位 schema 保留兼容层。
|
||||
- call_events 类审计元数据(不存记忆正文)
|
||||
- ~~session inbox / change_outbox 围绕 Evidence 外发~~ → 需按新规则重定义或标旧
|
||||
|
||||
---
|
||||
|
||||
## 接手时注意
|
||||
|
||||
- Pin 的公开 `hy-memory` 与「先补 SDK 接口」可能不同步:合源码 ≠ 用户包已带能力;用 `Refs` / pin PR 闭环。
|
||||
- Top Rule 与旧 `ARCHITECTURE`「SQLite 含 Governance 为业务权威」冲突处,**以本 HANDSOFF + 新 ARCHITECTURE 文首为准**。
|
||||
- 本地 `pr_principle.md` / `pr_review.md` 是 PR 流程台账,不替代本架构 HANDSOFF。
|
||||
+17
-49
@@ -2,28 +2,20 @@
|
||||
|
||||
更新:2026-10-21
|
||||
|
||||
**文档约定:** 以 [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) **Top Rules** 为现行权威。
|
||||
~~删除线~~ = 历史产品合同(曾要求走 Evidence / Governance 台账),**不再作为目标**;SDK 用法示例仍可用于开发调试。
|
||||
架构边界以 [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) 为准。
|
||||
|
||||
---
|
||||
|
||||
## Top Rules(与架构一致 · 新)
|
||||
## Architecture Principles
|
||||
|
||||
1. Memory 读写与存储 backend **只经 SDK**(config / env)。
|
||||
2. MemHub 对 memory 的原子操作 **只经 SDK**;缺接口先补 SDK。
|
||||
3. MemHub **不存 memory 实体**;**可以存 `memory_id`** 做组织/回执。原文进 **SDK raw**,不进 MemHub Evidence 权威库。
|
||||
3. MemHub **不存 memory 实体**;**可以存 `memory_id`** 做组织/回执。原文进入 **SDK raw**。
|
||||
|
||||
生产入口仍建议经 `HyMemoryBridge`(共享 Runtime、模型配置、密钥、harness/model 门禁),但 bridge **不得**再把 SDK 结果镜像成第二套 memory 正文权威。
|
||||
|
||||
---
|
||||
|
||||
## ~~旧开篇(已废弃)~~
|
||||
|
||||
~~本文说明 MemHub 当前使用的 Hy Memory SDK… 仓库内仍以 One Memory 命名的 Evidence、权限和 Governance 层属于 MemHub 的历史兼容模块;产品代码不应绕过这些层直接调用 SDK。~~
|
||||
|
||||
~~MemHub 在本地 Runtime 内嵌入 SDK,但不绕过自身的来源授权、模型授权、Evidence、Governance 和撤权边界。~~
|
||||
|
||||
**新:** 来源授权、模型授权、宿主召回授权仍是 MemHub 管理面门禁。~~Evidence / Governance 记忆台账~~ 按 Top Rules 拆除;memory 真相在 SDK。
|
||||
来源授权、模型授权和宿主召回授权仍是 MemHub 管理面门禁;memory
|
||||
数据平面的权威在 SDK。
|
||||
|
||||
## 当前版本状态
|
||||
|
||||
@@ -38,19 +30,12 @@ reader: hybrid
|
||||
|
||||
## MemHub 运行时边界
|
||||
|
||||
### 新
|
||||
|
||||
MemHub 对 SDK 使用公开、可复现的本地策略(经 bridge / `hy_runtime_config` 注入):
|
||||
|
||||
- vector / graph / cache / history / coding 等 **一律 SDK config/env**;
|
||||
- 模型与 embedding 来自版本化 Model Profile;密钥进安全存储;
|
||||
- MemHub 管理库可存 harness/model/队列状态与 **`memory_id` 引用**。
|
||||
|
||||
### ~~旧~~
|
||||
|
||||
~~- MemHub 不绕过 Evidence、Governance…~~
|
||||
~~- 生产路径不能用直接 `client.add()` 代替 Governance 检查。~~
|
||||
|
||||
发布包默认 SDK 行为环境变量仍集中在
|
||||
`apps/core/src/one_memory/hy_runtime_config.py`,并由下表锁定:
|
||||
|
||||
@@ -92,8 +77,8 @@ MemHub 对 SDK 使用公开、可复现的本地策略(经 bridge / `hy_runtim
|
||||
|
||||
下面是独立调试示例。
|
||||
|
||||
**新:** 产品代码经 `HyMemoryBridge` 获取已配置的 client(管理面门禁),memory I/O 仍是 SDK。
|
||||
~~旧:必须额外提供 Evidence 绑定、写后核验进 Governance。~~
|
||||
产品代码经 `HyMemoryBridge` 获取已配置的 client(管理面门禁),memory I/O
|
||||
由 SDK 完成。
|
||||
|
||||
```python
|
||||
from hy_memory import HyMemoryClient, MemoryConfig
|
||||
@@ -126,7 +111,7 @@ client = HyMemoryClient(config=config, mode="ultra")
|
||||
|
||||
## Write:写入对话
|
||||
|
||||
推荐把一段连续对话作为 OpenAI messages 写入(**含原文时由 SDK 接管 raw**,不再写入 MemHub Evidence 权威表):
|
||||
推荐把一段连续对话作为 OpenAI messages 写入;含原文时由 SDK 接管 raw:
|
||||
|
||||
```python
|
||||
from datetime import UTC, datetime
|
||||
@@ -145,7 +130,6 @@ result = client.add(
|
||||
request_id=str(uuid4()),
|
||||
metadata={
|
||||
"source_id": "cursor",
|
||||
# ~~evidence_ids 指向 MemHub Evidence 表~~ → 新:按 SDK raw / 元数据合同填写;勿依赖 MemHub evidence 权威
|
||||
"workspace_ids": ["workspace-abc"],
|
||||
"input_kind": "raw_conversation",
|
||||
},
|
||||
@@ -186,11 +170,11 @@ if result.get("success") is not True:
|
||||
memory_ids = list(result.get("memory_ids") or [])
|
||||
if result.get("memory_id"):
|
||||
memory_ids.append(result["memory_id"])
|
||||
# 新:需要组织/回执时,MemHub 只持久化这些 memory_id
|
||||
# 需要组织或回执时,MemHub 只持久化这些 memory_id。
|
||||
```
|
||||
|
||||
~~不要只相信 `success=True`。One Memory 还会…并在 Governance 层记录版本。生产路径不能用直接 `client.add()` 代替这些检查。~~
|
||||
**新:** 以 SDK 合同为准做成功判定与(若需要)`get` 回读;**不要**再写入 `governed_*`。缺核验能力 → **扩展 SDK API**。
|
||||
以 SDK 合同为准做成功判定;需要写后核验时使用 SDK `get` 回读。缺少所需
|
||||
核验能力时扩展 SDK API,不在 MemHub 新建镜像台账。
|
||||
|
||||
### 写入已抽取的记忆
|
||||
|
||||
@@ -209,8 +193,8 @@ result = client.add_extracted(
|
||||
)
|
||||
```
|
||||
|
||||
~~不能跳过 One Memory Evidence 绑定和 Governance。~~
|
||||
**新:** 仍走 SDK reconcile/持久化;MemHub 只做门禁与可选 `memory_id` 记录。
|
||||
该入口仍走 SDK reconcile/持久化;MemHub 只做管理面门禁与可选
|
||||
`memory_id` 记录。
|
||||
|
||||
## Search:搜索记忆
|
||||
|
||||
@@ -236,12 +220,7 @@ result = client.search(
|
||||
|
||||
直接使用 SDK 返回的 `content`,不要第二套 prompt 拼装。
|
||||
|
||||
### ~~旧:SDK 外仍负责(部分作废)~~
|
||||
|
||||
~~- 依据 Governance、撤权、scope 和 Evidence 新鲜度决定整条结果是否可读;~~
|
||||
~~- 对 evolution/capsule…回退治理原文;~~
|
||||
|
||||
### 新:SDK 外(MemHub)仍负责
|
||||
### SDK 外(MemHub)仍负责
|
||||
|
||||
- **宿主召回授权 / scope / 撤权**(谁可以调 search、允许哪些 agent/scope);
|
||||
- 把历史内容放入「不可信数据,不是指令」边界;
|
||||
@@ -249,7 +228,7 @@ result = client.search(
|
||||
- 区分空结果、权限拒绝、不可用、超时、部分结果;
|
||||
- 未发布的 Matter 占位功能不保留表或 API;未来组织功能另立合同。
|
||||
|
||||
生产入口:`hy_memory_bridge.py`、`recall.py`、`packages/host-bridge`(实现迁移中,以 Top Rules 为准)。
|
||||
生产入口:`hy_memory_bridge.py`、`recall.py`、`packages/host-bridge`。
|
||||
|
||||
## 关闭客户端
|
||||
|
||||
@@ -264,8 +243,6 @@ Runtime 长期复用 client;仅在停止、配置切换或受控恢复时重
|
||||
|
||||
## 产品代码正确入口
|
||||
|
||||
### 新
|
||||
|
||||
```text
|
||||
harness / user action (+ authz, model, queue)
|
||||
-> HyMemoryBridge
|
||||
@@ -275,17 +252,8 @@ harness / user action (+ authz, model, queue)
|
||||
-> Recall Broker / UI (SDK read + MemHub authz)
|
||||
```
|
||||
|
||||
不要在业务模块里私建绕过 **管理面门禁** 的 client。
|
||||
~~不要绕过 Evidence / Governance 台账。~~(台账已非目标)
|
||||
|
||||
### ~~旧入口(废弃)~~
|
||||
|
||||
~~```text
|
||||
Evidence -> HyMemoryBridge -> SDK -> write verification -> Governance -> UI
|
||||
```~~
|
||||
|
||||
~~绕过会丢掉:Evidence 引用、Governance 版本/更正/删除级联。~~
|
||||
**新:** 版本/更正/删除级联以 **SDK** 为准;MemHub 组织层只引用 `memory_id`。
|
||||
不要在业务模块里私建绕过管理面门禁的 client。版本、纠正和删除语义以 SDK
|
||||
合同为准;MemHub 组织层只引用 `memory_id`。
|
||||
|
||||
Hy Memory SDK 是 MemHub 内置可信引擎,管理本机 Hy Memory 数据。
|
||||
来源授权决定哪些宿主数据可进入写入路径;宿主 Recall Grant 决定外部应用可读范围。
|
||||
|
||||
+3
-4
@@ -38,15 +38,14 @@ Linux 制品由 GitHub Actions 在原生架构 runner 上构建并完成生命
|
||||
|
||||
- 一次安装、一个 Runtime、一份数据、多种客户端。
|
||||
- Hy Memory SDK 是 memory/raw/vector/graph/coding 数据面的唯一权威;Python Core
|
||||
管理授权、模型、异步队列、Runtime 状态与 Matters 引用。
|
||||
管理授权、模型、异步队列和 Runtime 状态。
|
||||
- 来源读取、模型处理和宿主读取是相互独立的授权边界。
|
||||
- 正式写链路为 `memory_write_jobs -> SDK add() -> raw/memory ID receipt`;
|
||||
Matter/Wiki 只保存并解析 SDK ID 引用。
|
||||
- 正式写链路为 `memory_write_jobs -> SDK add() -> raw/memory ID receipt`。
|
||||
- 产品不包含屏幕、Accessibility / AXTree、OCR、键鼠、剪贴板或后台录音采集。
|
||||
|
||||
## 仓库结构
|
||||
|
||||
- `apps/core`:Python / FastAPI Kernel,负责授权、模型、队列、SDK bridge、Matters 与 API。
|
||||
- `apps/core`:Python / FastAPI Kernel,负责授权、模型、队列、SDK bridge 与 API。
|
||||
- `apps/cli`:安装、控制和诊断共享 Runtime 的 `one-memory` CLI。
|
||||
- `apps/web`:React / TypeScript 管理界面。
|
||||
- `apps/desktop`:Electron 桌面壳与图形安装入口。
|
||||
|
||||
@@ -7,7 +7,6 @@ segment-key breakage). Call sites still import this module; registration is
|
||||
now a no-op that always admits the row.
|
||||
|
||||
Proof rows may still be written by the ingest path; they are ignored on read.
|
||||
See ``新鲜度_todo.md`` for the remaining teardown steps.
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
"""Executable dependency and memory-authority gates.
|
||||
|
||||
The current target architecture is defined by ``HANDSOFF.md`` and
|
||||
``docs/ARCHITECTURE.md``:
|
||||
The public target architecture is defined by ``docs/ARCHITECTURE.md``:
|
||||
|
||||
* Hy Memory SDK owns memory/raw/vector/graph/coding data;
|
||||
* MemHub owns the management plane and may retain ``memory_id`` references;
|
||||
|
||||
+31
-118
@@ -1,14 +1,13 @@
|
||||
# MemHub / One Memory Architecture
|
||||
# MemHub Architecture
|
||||
|
||||
Updated: 2026-10-21.
|
||||
|
||||
**文档约定:** 以文首 **Top Rules(新)** 为现行权威。
|
||||
用 ~~删除线~~ 标注的段落是历史设计(曾落地或曾写入本文件),**不再作为实现目标**;保留是为了对照迁移,不是双轨并行。
|
||||
Hy Memory = SDK / 引擎。MemHub = 产品与发布名;`one-memory` 仍出现在历史模块、路径与兼容接口名中。
|
||||
Hy Memory 是 SDK / 引擎;MemHub 是产品与发布名。`one-memory` 仍可能出现在
|
||||
兼容路径、模块名和服务标识中。
|
||||
|
||||
---
|
||||
|
||||
## Top Rules(新 · 根本)
|
||||
## Architecture Principles
|
||||
|
||||
1. **所有对 memory 的读写操作都交给 SDK**,包括存储 backend;backend 选择与路径一律通过 **SDK config / env** 完成(如 vector / graph / cache / history / coding / raw)。MemHub 不另起一套 memory 存储引擎。
|
||||
2. **MemHub 内对 memory 的原子操作也一律经 SDK 完成。** SDK 若缺少所需 client 能力,**先补 SDK 接口**,再在产品层调用;禁止在 Core 内直接改 VDB/Graph/SDK 私有库,或再维护一份 memory 正文权威。
|
||||
@@ -16,10 +15,10 @@ Hy Memory = SDK / 引擎。MemHub = 产品与发布名;`one-memory` 仍出现
|
||||
- **可以且应当**持久化 SDK 提供的 **`memory_id`(及组织用元数据)**,作为外键引用。
|
||||
- **禁止**再存一份 memory 正文台账、自判 supersede、把 SDK 当可丢缓存。
|
||||
|
||||
**推论(新):**
|
||||
**直接约束:**
|
||||
|
||||
- ~~原文 Evidence 业务库~~ → **原文进入 SDK raw 层**;不再以 MemHub `evidence` 表为原文权威。
|
||||
- ~~Governance / `governed_*` 作为产品级 memory 权威~~ → **拆除方向**;列表/纠正/删除/召回过滤改为 **授权 + 调 SDK**;需要挂接处只存 `memory_id`。
|
||||
- 原始对话进入 **SDK raw 层**;MemHub 不以 `evidence` 表保存原文权威。
|
||||
- 列表、纠正、删除和召回通过 **授权 + SDK API** 完成;需要挂接处只存 `memory_id`。
|
||||
- Matter 尚未形成已发布产品合同;当前全部 `matter*` 占位表和 API 入口删除。
|
||||
|
||||
---
|
||||
@@ -28,7 +27,7 @@ Hy Memory = SDK / 引擎。MemHub = 产品与发布名;`one-memory` 仍出现
|
||||
|
||||
MemHub is a local-first memory product.
|
||||
|
||||
### 新:职责切分
|
||||
### Responsibilities
|
||||
|
||||
```text
|
||||
AI hosts / harnesses
|
||||
@@ -54,30 +53,6 @@ Memory entities / raw / vectors / graph / coding stores
|
||||
└─ owned exclusively by Hy Memory SDK (config/env under One Memory Home)
|
||||
```
|
||||
|
||||
### ~~旧:产品叙事(已废弃为权威描述)~~
|
||||
|
||||
~~A user authorizes supported AI conversation sources, keeps their original content as local Evidence, processes eligible content through Hy Memory, governs the result, and grants hosts a separate scope for recall.~~
|
||||
|
||||
~~```text
|
||||
AI hosts and local conversation files
|
||||
├─ historical import / incremental sync
|
||||
├─ Host hooks, plugins, Skills and MCP
|
||||
└─ authorized recall
|
||||
│
|
||||
▼
|
||||
Python Core / FastAPI
|
||||
├─ source adapters and grants
|
||||
├─ Evidence and import jobs
|
||||
├─ durable memory_write_jobs
|
||||
├─ single-layer durable write execution records
|
||||
├─ model-content permission checks
|
||||
├─ Hy Memory bridge
|
||||
├─ Governance and retrieval
|
||||
└─ local HTTP API
|
||||
```~~
|
||||
|
||||
**对照:** 管理面(harness、队列、model、config)仍在 Core;~~Evidence + Governance 作 memory/原文权威~~ 按 Top Rules 退出。异步队列仍可调度「调用 SDK 写入」的工作,但 **写入结果的权威在 SDK**,MemHub 至多记录 `memory_id` / 任务回执。
|
||||
|
||||
There is one managed Runtime and one MemHub data home per installation. CLI and
|
||||
Electron are clients and lifecycle interfaces to that Runtime; they do not own
|
||||
separate memory engines. The Web UI is a client of Core and does not access host
|
||||
@@ -87,7 +62,7 @@ files or SDK private stores directly.
|
||||
|
||||
| Path | Responsibility |
|
||||
| --- | --- |
|
||||
| `apps/core` | **新:** FastAPI 管理面:harness、model、队列、config、Runtime 协作、**经 bridge 调用 SDK**。 ~~旧:SQLite 业务库含 Evidence、Governance 记忆台账、HY 集成与 retrieval 权威。~~ |
|
||||
| `apps/core` | FastAPI 管理面:harness、model、队列、config、Runtime 协作,并经 bridge 调用 SDK。 |
|
||||
| `apps/web` | React / TypeScript product UI and API client. |
|
||||
| `apps/desktop` | Electron shell; attaches to or starts the managed Runtime. |
|
||||
| `apps/cli` | Bootstrap, install, upgrade, service lifecycle, diagnostics. |
|
||||
@@ -111,18 +86,17 @@ Source root authorization and Harness synchronization remain distinct:
|
||||
- Core is the only writer of `config.json`(temp + fsync + atomic replace).
|
||||
- Web/Desktop/CLI/Runtime call Core APIs; they do not keep a second durable copy.
|
||||
|
||||
**新:** 同步/导入的目标是把宿主对话 **写入 SDK(含 raw 层)**,而不是写入 MemHub Evidence 权威库。队列可以描述「待调用 SDK 的工作」,完成态以 SDK 可验证结果 + 可选 `memory_id` 回执为准。
|
||||
同步/导入把宿主对话写入 **SDK(含 raw 层)**。队列描述待执行的
|
||||
SDK 调用,完成态以 SDK 可验证结果和可选 `memory_id` 回执为准。
|
||||
|
||||
~~**旧:** Turning sync on prepares catch-up import into Evidence / `memory_write_jobs`; historical turns without a durable write receipt are added to `memory_write_jobs`. Adapters read host files into MemHub Evidence; they do not call HY directly.~~
|
||||
|
||||
~~Turning sync off stops scanning and stops claiming pending jobs; in-flight first HY call may finish; previously published memories remain for recall.~~
|
||||
**新补充:** 暂停同步仍是管理面开关;已在 SDK 中的 memory/raw 生命周期由 SDK 与产品调用 SDK 的删除 API 决定,不由 MemHub 影子表「撤销可见性」单独当权威。
|
||||
暂停同步是管理面开关;已进入 SDK 的 memory/raw 生命周期由 SDK API 管理,
|
||||
不能通过 MemHub 影子表单独改变其可见性。
|
||||
|
||||
Periodic polling / fs watch live in Core. UI does not schedule scans.
|
||||
|
||||
### Memory processing
|
||||
|
||||
#### 新:唯一写入路径
|
||||
#### Write path
|
||||
|
||||
```text
|
||||
authorized harness / user action
|
||||
@@ -138,36 +112,12 @@ authorized harness / user action
|
||||
- **原子 memory 变更**(create / update / delete / supersede 等):只通过 SDK。缺接口则扩展 SDK client。
|
||||
- **异步队列**:只保留 `memory_write_jobs`,其承载 FIFO / event-time、公平调度、租约、暂停、重试与 SDK 回执;一个 job 对应一次 SDK `add()`。旧 `memory_tasks` 与 task receipt 二级台账删除。
|
||||
- SDK `write_outcomes` 只回答某个 request 是否已由 SDK 提交及返回哪些 `memory_id`;它不是队列,也不接管调度。
|
||||
|
||||
#### ~~旧:Evidence → Governance 路径(已废弃为目标架构)~~
|
||||
|
||||
~~```text
|
||||
authorized source
|
||||
-> Evidence
|
||||
-> import job / complete conversation turn
|
||||
-> memory_write_jobs
|
||||
-> persisted event-time window
|
||||
-> durable drain
|
||||
-> sedimentation and source gates
|
||||
-> Hy Memory bridge
|
||||
-> write verification and Governance
|
||||
-> search / recall / UI
|
||||
```~~
|
||||
|
||||
~~Evidence is stored before model work so processing failures do not discard source content.~~
|
||||
**新:** 原文/raw 的持久化与失败保留策略由 **SDK raw(及 SDK 合同)** 承担;MemHub 不再以 `evidence*` 表为原文权威。
|
||||
|
||||
~~`memory_write_jobs` is the sole production intake…~~
|
||||
**新:** 若保留同名队列表,其语义降级为 **SDK 调用调度器**,不再隐含「写入 Governance 台账才算产品成功」。
|
||||
|
||||
~~`memory_tasks` remains as an internal execution record…~~
|
||||
**新:** 该二级执行表与 task receipt 删除;运维状态直接来自 `memory_write_jobs`。
|
||||
- 原文/raw 的持久化与失败保留由 SDK raw 合同承担。
|
||||
- 运维状态直接来自 `memory_write_jobs`,不另设 `memory_tasks` 二级执行表。
|
||||
|
||||
### HY / SDK and MemHub bridge
|
||||
|
||||
#### 新
|
||||
|
||||
Hy Memory is the **only** extraction, memory entity, relationship, and semantic-retrieval engine. Product code enters it through `HyMemoryBridge`(共享 Runtime、模型配置、密钥边界),不在业务模块里私自 new 一套绕过门禁的 client——门禁指的是 **harness/model/队列**,不是再套一层 memory 正文 Governance。
|
||||
Hy Memory is the **only** extraction, memory entity, relationship, and semantic-retrieval engine. Product code enters it through `HyMemoryBridge`(共享 Runtime、模型配置、密钥边界),不在业务模块里私自 new 一套绕过门禁的 client。
|
||||
|
||||
- Storage backends:仅 SDK config/env(Chroma/FAISS/Qdrant、Kuzu/Neo4j、cache/history sqlite|mysql、coding sqlite 等)。
|
||||
- Queue:pending `memory_write_jobs` 只表示尚未调用 SDK 的待处理请求,因此没有 SDK raw/memory ID。worker 单次调用 SDK `add()`;SDK 内部完成 raw 写入与 extraction/reconciliation,成功后 MemHub 仅将返回的 raw ID / memory IDs 记作 job/task outcome。`import_raw()` 只用于历史数据的 exact migration,不拆分正常写路径。
|
||||
@@ -180,12 +130,6 @@ Hy Memory is the **only** extraction, memory entity, relationship, and semantic-
|
||||
|
||||
Pinned SDK 版本见发布锁文件 / `MEMORY.md`(随发布更新)。
|
||||
|
||||
#### ~~旧:Governance 层(已废弃为目标架构)~~
|
||||
|
||||
~~The bridge and Governance layer preserve Evidence references, authorship, scope, write verification, revisions, corrections, and deletion behavior. A successful SDK response alone is not sufficient evidence of a product-level write. Retrieval results are checked against current Governance and access scope before being returned.~~
|
||||
|
||||
~~**旧实现后果(对照用):** 曾将 SDK 结果镜像进 `governed_*`(含 supersede 状态),并靠解析返回值 / observer / 再 `get` 双写。按 Top Rules,该镜像权威 **拆除**;写后核验若仍需要,应落在 **SDK 合同 + 显式 client API**,而不是第二套实体库。~~
|
||||
|
||||
## Permission Boundaries(管理面 · 仍独立)
|
||||
|
||||
These permissions answer different questions and must not be collapsed:
|
||||
@@ -195,8 +139,6 @@ These permissions answer different questions and must not be collapsed:
|
||||
3. **Model-content permission:** may eligible content be sent to the configured model provider (for SDK extraction etc.)?
|
||||
4. **Host recall grant:** may this external host invoke the granted recall tools? This is not a per-memory cross-harness ACL.
|
||||
|
||||
~~Model-content permission… Tasks do not carry a parallel permission receipt…~~(调度细节可保留实现,不改变 Top Rules。)
|
||||
|
||||
Host installation / recall authorization cross an external trust boundary; preview, fingerprint, scope, credential, rollback protections remain.
|
||||
|
||||
The product must not depend on screen capture, Accessibility/AXTree, OCR,
|
||||
@@ -204,49 +146,37 @@ keyboard/mouse, clipboard, or background audio collection.
|
||||
|
||||
## Storage
|
||||
|
||||
### 新
|
||||
|
||||
| 存什么 | 谁拥有 | 怎么配 |
|
||||
| --- | --- | --- |
|
||||
| Memory 实体、raw、向量、图、coding、SDK cache/history | **Hy Memory SDK** | SDK config / env;目录落在 One Memory Home 下由 Runtime 约定 |
|
||||
| harness grants、sync desired-state、model profiles、队列/租约、Core 收据、必要的 `memory_id` 引用 | **MemHub 管理库**(当前多为 `one-memory.sqlite3`) | Core 管理;**不**存 memory 正文 |
|
||||
|
||||
~~SQLite is the sole authoritative MemHub business database… It stores Evidence, grants, import jobs, memory tasks, Governance, model profiles…~~
|
||||
**新:** MemHub SQLite(或后继)是 **管理面** 权威库,不是 memory 实体权威库。
|
||||
|
||||
~~HY-owned vector, graph, cache, and history stores… are not a second authoritative MemHub business database.~~
|
||||
**新表述:** HY/SDK stores **就是** memory 数据平面权威;MemHub 不得再镜像一套业务实体与之并行。
|
||||
MemHub SQLite(或后继)是管理面权威库;HY/SDK stores 是 memory 数据平面
|
||||
权威。两者职责不同,MemHub 不镜像 memory 实体。
|
||||
|
||||
Fresh install 直接 bootstrap 最新管理面 schema,不执行历史 Evidence /
|
||||
Governance migration 链。旧用户启动迁移可以临时读取旧表,但 cutover、raw
|
||||
引用回填和 bundle restore 验证全部成功后,必须在 Runtime 对外服务前 DROP
|
||||
旧 Evidence/Governance/retrieval/session-shadow、全部 Matter 占位表以及迁移专用 alias/ledger。
|
||||
|
||||
~~MySQL-only business storage was an earlier proposal… D56 selected SQLite…~~
|
||||
**仍有效的工程约束:** 不要静默上 MemHub 业务双写 MySQL;SDK 侧 `MEMORY_CACHE_BACKEND=mysql` 等属 **SDK 合同**,与 MemHub 管理库无关。
|
||||
不要为 MemHub 管理面引入隐式 MySQL 双写。SDK 侧
|
||||
`MEMORY_CACHE_BACKEND=mysql` 等属于 SDK 合同,与 MemHub 管理库无关。
|
||||
|
||||
`config.json`:desired user settings,不是 runtime health 的唯一真相;健康态从收据与进程状态重建。
|
||||
|
||||
### ~~旧表族(拆除方向 · 对照)~~
|
||||
|
||||
~~- `evidence*` / import evidence 权威 → 改 SDK raw~~
|
||||
~~- `governed_memories*` / supersessions / versions 作列表与生命周期权威 → 改 SDK API + 可选 `memory_id` 引用~~
|
||||
~~- 以 Governance 为准的 visibility 正文缓存若依赖实体台账 → 随台账拆除或改为纯派生且可重建,且不得成为写权威~~
|
||||
|
||||
**可保留方向(管理面):** `source_grants`、model profile 相关表、队列/任务租约表、call_events 类审计元数据(不存对话/记忆正文)、Runtime 收据。
|
||||
管理面可持久化 `source_grants`、model profile、队列/租约、call_events
|
||||
审计元数据(不存对话或记忆正文)和 Runtime 收据。
|
||||
|
||||
## Matters / call_events / session inbox(口径)
|
||||
|
||||
| 能力 | 新口径 |
|
||||
| 能力 | 当前口径 |
|
||||
| --- | --- |
|
||||
| **Matters** | 未发布占位功能,现已删除表与 Runtime API;未来按新合同重新设计。 |
|
||||
| **call_events** | 本机调用元数据审计(非 memory 实体);可留在管理面;展示记忆时用 id 调 SDK。 |
|
||||
| **session inbox / lease / change_outbox** | ~~旧:围绕 Evidence/变更外发的宿主增量管道~~。Evidence 权威拆除后,若仍需要宿主增量,应重定义为 **管理事件或 SDK 可订阅合同**,不得靠 MemHub 影子 memory 表推送正文。 |
|
||||
| **session inbox / lease / change_outbox** | 已删除的历史管道。未来若需要宿主增量,必须定义管理事件或 SDK 可订阅合同,不得靠 MemHub 影子 memory 表推送正文。 |
|
||||
|
||||
## Runtime and Interfaces
|
||||
|
||||
(以下 Runtime / 安装 / 服务归属 **仍现行**,与 Top Rules 不冲突;未改语义处保持原文。)
|
||||
|
||||
The repository has one Runtime implementation, one default data home, and one
|
||||
OS service identity per installation. macOS App and npm CLI share Runtime
|
||||
artifact contract, `~/.one-memory`, receipts, ports, credentials, Core API,
|
||||
@@ -347,22 +277,11 @@ See [`INSTALLATION.md`](INSTALLATION.md).
|
||||
|
||||
## Engineering Rules
|
||||
|
||||
### 新(优先)
|
||||
|
||||
- Top Rules 1–3 不可被「方便测试 / 赶发布」绕过。
|
||||
- Architecture Principles 不可被「方便测试 / 赶发布」绕过。
|
||||
- Memory I/O 与 backend 只经 SDK;缺能力先补 SDK。
|
||||
- MemHub 可存 `memory_id` 引用与管理面状态;不存 memory 实体副本。
|
||||
- Source grant、model egress、host recall scope 保持独立。
|
||||
- 不要把「管理库查不到行」当成 SDK 侧已删除,除非已显式调 SDK 删除并确认。
|
||||
|
||||
### ~~旧工程句(与 Top Rules 冲突者作废)~~
|
||||
|
||||
~~- Preserve the source record before model processing.~~(改为 SDK raw 合同)
|
||||
~~- Do not create confirmed memory without supporting evidence.~~(证据/raw 关系由 SDK 合同表达)
|
||||
~~- Keep claims traceable to the narrow original Evidence that supports them.~~(改为可追溯到 SDK raw / 引用 id)
|
||||
|
||||
仍有效:
|
||||
|
||||
- Do not treat unavailable source data as deletion(宿主文件消失 ≠ 自动删 SDK memory,除非产品显式定义并调 SDK)。
|
||||
- Do not let graph layout imply semantic relationships.
|
||||
- Run the smallest relevant tests for ordinary development; full/release/soak only when requested.
|
||||
@@ -370,17 +289,11 @@ See [`INSTALLATION.md`](INSTALLATION.md).
|
||||
|
||||
Test entry points: [`../CONTRIBUTING.md`](../CONTRIBUTING.md).
|
||||
|
||||
## Migration note(给实现与评审)
|
||||
|
||||
本文件更新 **先改合同与目标架构**,不表示代码已拆完。实现迁移顺序建议:
|
||||
|
||||
1. 冻结新功能写入 `governed_*` / `evidence*` 权威路径。
|
||||
2. 记忆库 UI / recall 改为 SDK API + 授权;组织层只挂 `memory_id`。
|
||||
3. 导入/同步改为 SDK raw/write;退役 Evidence 权威。
|
||||
4. 删除或清空镜像台账;队列改为纯调度。
|
||||
5. 缺的 SDK API 开 SDK PR,而不是在 Core 里补影子表。
|
||||
## Upgrade Compatibility
|
||||
|
||||
Released installations require the offline, resumable compatibility protocol in
|
||||
[`contracts/sdk-data-plane-migration-v1.md`](contracts/sdk-data-plane-migration-v1.md).
|
||||
Do not cut over an existing home with a SQLite-only backup or by replaying
|
||||
Evidence through extraction.
|
||||
The App runs it during the startup loading phase before Core exposes product
|
||||
reads or writes. A cutover requires a complete bundle, resumable backfill,
|
||||
reconciliation, and verified cleanup; a SQLite-only backup or replaying legacy
|
||||
rows through extraction is not sufficient.
|
||||
@@ -1,8 +1,5 @@
|
||||
# 开发验收闭环
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`ARCHITECTURE.md`](ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
每个步骤只有经过以下状态才算完成:
|
||||
|
||||
`Ready → In progress → Verify → Done`
|
||||
|
||||
@@ -1,7 +1,5 @@
|
||||
# MemHub 安装与发行
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`ARCHITECTURE.md`](ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
MemHub `v1.0.4`(build 13)的发行目标如下:
|
||||
|
||||
| 平台 | 发行物 | 构建与验收 |
|
||||
|
||||
@@ -1,241 +0,0 @@
|
||||
# MemHub App 数据迁移产品验收手册(本地)
|
||||
|
||||
适用范围:从旧版 MemHub App 升级到 SDK 数据面版本,以及 SDK 数据面版本的全新安装。
|
||||
|
||||
默认数据目录:`~/.one-memory`。以下操作只能在测试账号或测试机器执行,禁止拿真实用户唯一一份数据做破坏性测试。
|
||||
|
||||
## 一、验收结论怎么判
|
||||
|
||||
旧用户升级通过,必须同时满足:
|
||||
|
||||
1. 启动时显示 loading,迁移完成前不能进入可操作的主页。
|
||||
2. 旧版中的有效记忆、原始对话、用户画像和配置在新版中仍可读取。
|
||||
3. 修改过的记忆只显示最终内容;旧内容不会作为另一个有效记忆出现。
|
||||
4. 用户已删除的记忆不会恢复。
|
||||
5. 同一份旧数据重复启动、迁移中断后重启,不产生重复记忆。
|
||||
6. 数据权威已切换到 SDK,旧的 Evidence/Governance/Matter 等表已从在线数据库物理删除。
|
||||
7. 迁移前备份 bundle 存在;失败时不得出现“部分新数据 + 部分旧数据”的可用主页。
|
||||
|
||||
全新安装通过,必须同时满足:
|
||||
|
||||
1. 首次进入时记忆列表为空,用户画像为空或显示“尚未形成画像”。
|
||||
2. 数据库从一开始就是 SDK authority。
|
||||
3. 不创建 `evidence*`、`governed_*`、`matter*`、旧 retrieval、旧 session-shadow、`memory_tasks` 等废弃表。
|
||||
4. 全新安装不应生成“旧用户迁移”备份 bundle。
|
||||
5. 新写入一条测试记忆后,UI、CLI 和搜索都能读到,重启 App 后仍存在。
|
||||
|
||||
表的总数不是验收标准。部分管理面表会在对应功能首次使用时按需创建;应检查必需状态和禁止出现的旧表,而不是只核对一个固定数字。
|
||||
|
||||
## 二、场景 A:旧用户升级
|
||||
|
||||
### A1. 准备旧版样本
|
||||
|
||||
1. 在测试账号安装当前线上旧版 App,并完成模型配置。
|
||||
2. 用真实产品入口产生一组容易核对的数据。建议至少包含:
|
||||
- 有效记忆 A:`升级验收-姓名是林澄-20261022`
|
||||
- 有效记忆 B:`升级验收-偏好无糖咖啡-20261022`
|
||||
- 记忆 C:先写“住在上海”,再修改为 `升级验收-住在深圳-20261022`
|
||||
- 记忆 D:写入 `升级验收-稍后删除-20261022`,然后在旧版中删除
|
||||
- 至少一段包含 user/assistant 角色的真实对话,供 raw 数据迁移验证
|
||||
3. 在旧版 UI 截图或导出以下基线:
|
||||
- 有效记忆列表及总数
|
||||
- A、B、C 的完整正文
|
||||
- D 已经不存在
|
||||
- 已连接来源、模型配置和用户画像(如果已有)
|
||||
4. 正常退出 App 后执行:
|
||||
|
||||
```bash
|
||||
memhub stop
|
||||
cp -a "$HOME/.one-memory" "$HOME/.one-memory.before-sdk-migration"
|
||||
```
|
||||
|
||||
注意:关闭 App 窗口不等于后台 Runtime 已停止。必须确认 `memhub stop` 成功后再复制目录。
|
||||
|
||||
### A2. 安装并首次启动新版
|
||||
|
||||
1. 安装待验收的新 App,保留原来的 `~/.one-memory`,不要点清除数据。
|
||||
2. 启动 App。
|
||||
3. 观察启动 loading:
|
||||
- 迁移期间不应提前出现可操作主页。
|
||||
- 成功后自动进入主页。
|
||||
- 如果提示迁移失败或配置不足,记录错误码;此时旧数据必须仍完整,且不能进入一个可写的半迁移状态。
|
||||
4. 不要手工运行 `sdk-migrate`、`sdk-cutover` 或 `sdk-cleanup`。产品验收的目标就是确认 App 启动流程能自动完成迁移。
|
||||
|
||||
### A3. 产品界面验证
|
||||
|
||||
进入主页后逐项检查:
|
||||
|
||||
- 记忆 A、B 均存在且正文完全一致。
|
||||
- C 只保留“住在深圳”的最终内容;“住在上海”不能作为有效记忆出现。
|
||||
- D 不存在,搜索 D 的唯一文本也不能命中。
|
||||
- 原始对话的角色、顺序、来源和时间没有串行或丢失。
|
||||
- 用户画像仍可读取;没有画像的旧用户应明确显示为空,不能报接口不存在。
|
||||
- 来源授权、模型配置仍在。
|
||||
- 用 A、B 的关键词搜索都能命中对应记忆。
|
||||
- 重启 App 后再次检查,数量和内容不变。
|
||||
|
||||
新版 CLI 可作为第二条产品验证通道:
|
||||
|
||||
```bash
|
||||
memhub status --json
|
||||
memhub memories list --limit 500 --json > /tmp/memhub-memories-after.json
|
||||
memhub profile --json > /tmp/memhub-profile-after.json
|
||||
```
|
||||
|
||||
若 CLI 与 UI 结果不一致,验收失败;保留两个输出并导出 App 日志。
|
||||
|
||||
### A4. 工程辅助检查
|
||||
|
||||
以下检查由研发或熟悉终端的测试人员执行。
|
||||
|
||||
1. 数据权威必须为 `sdk`:
|
||||
|
||||
```bash
|
||||
sqlite3 "$HOME/.one-memory/one-memory.sqlite3" \
|
||||
"SELECT authority, migration_id FROM memory_authority_state WHERE singleton=1;"
|
||||
```
|
||||
|
||||
预期:第一列为 `sdk`。旧用户迁移的 `migration_id` 应非空。
|
||||
|
||||
2. 在线数据库中不能残留废弃表:
|
||||
|
||||
```bash
|
||||
sqlite3 "$HOME/.one-memory/one-memory.sqlite3" "
|
||||
SELECT name
|
||||
FROM sqlite_master
|
||||
WHERE type='table' AND (
|
||||
name GLOB 'evidence*'
|
||||
OR name GLOB 'governed_*'
|
||||
OR name GLOB 'matter*'
|
||||
OR name GLOB 'retrieval_*'
|
||||
OR name GLOB 'session_inbox_*'
|
||||
OR name IN (
|
||||
'session_snapshots',
|
||||
'session_subscriptions',
|
||||
'tail_handoff',
|
||||
'change_outbox',
|
||||
'memory_tasks',
|
||||
'memory_task_inputs',
|
||||
'memory_task_outputs',
|
||||
'memory_task_contexts',
|
||||
'memory_task_extractions',
|
||||
'memory_task_sdk_receipts',
|
||||
'memory_deletions',
|
||||
'memory_index_syncs',
|
||||
'extraction_settings'
|
||||
)
|
||||
)
|
||||
ORDER BY name;"
|
||||
```
|
||||
|
||||
预期:无输出。`memory_write_jobs` 是新版仍保留的唯一写入队列,不应误判为旧表。
|
||||
|
||||
3. 迁移前备份 bundle 必须存在:
|
||||
|
||||
```bash
|
||||
ls "$HOME/.one-memory/backups/"sdk-authority-v1-*.sdk-bundle/manifest.json
|
||||
```
|
||||
|
||||
预期:至少一个 `manifest.json`,并且 bundle 内包含管理数据库和 SDK 数据快照。不要删除该 bundle。
|
||||
|
||||
4. 查看本次启动的迁移结果:
|
||||
|
||||
```bash
|
||||
rg '"event":"sdk_migration.startup"' \
|
||||
"$HOME/.one-memory/logs/diagnostic-desktop.jsonl"
|
||||
```
|
||||
|
||||
预期:最新一条结果为 `outcome: "succeeded"`、`state: "cutover"`。如果是 `blocked`,记录 `error_code` 并判定本轮未通过。
|
||||
|
||||
### A5. 中断恢复专项
|
||||
|
||||
使用 `~/.one-memory.before-sdk-migration` 恢复测试环境后,再做一轮:
|
||||
|
||||
1. 启动新版,在迁移 loading 期间强制退出 App。
|
||||
2. 再次启动同一新版 App。
|
||||
3. 迁移应继续完成,而不是从头重复写入。
|
||||
4. 完成后重复 A3、A4。
|
||||
5. 重点确认 A、B、C 各只有一份,且 bundle、记忆、raw 均没有重复。
|
||||
|
||||
此场景只在可随时恢复的数据副本上执行。
|
||||
|
||||
## 三、场景 B:全新安装
|
||||
|
||||
### B1. 准备真正的空环境
|
||||
|
||||
卸载 App 不会删除用户数据,因此“重新安装 App”不等于全新安装。请在测试账号执行:
|
||||
|
||||
```bash
|
||||
memhub stop
|
||||
mv "$HOME/.one-memory" "$HOME/.one-memory.saved-$(date +%Y%m%d-%H%M%S)"
|
||||
```
|
||||
|
||||
确认 `~/.one-memory` 已不存在,再安装并启动新 App。
|
||||
|
||||
### B2. 首次启动产品验证
|
||||
|
||||
首次进入后检查:
|
||||
|
||||
- 正常进入 onboarding 或空主页。
|
||||
- 记忆列表为 0。
|
||||
- 用户画像为空或明确显示尚未形成。
|
||||
- 没有旧来源授权、旧模型密钥、旧任务或旧历史。
|
||||
- 启动过程不应声称“已迁移旧数据”。
|
||||
|
||||
然后配置测试模型并通过新版入口写入一条唯一记忆:
|
||||
|
||||
`全新安装验收-喜欢乌龙茶-20261022`
|
||||
|
||||
确认:
|
||||
|
||||
- 写入任务最终成功。
|
||||
- 记忆列表和搜索都能读到它。
|
||||
- `memhub profile --json` 可调用;画像是否立即形成取决于 SDK 提取结果,但接口不能缺失。
|
||||
- 重启 App 后该记忆仍存在且不重复。
|
||||
|
||||
### B3. 工程辅助检查
|
||||
|
||||
1. 初始 authority:
|
||||
|
||||
```bash
|
||||
sqlite3 "$HOME/.one-memory/one-memory.sqlite3" \
|
||||
"SELECT authority, migration_id FROM memory_authority_state WHERE singleton=1;"
|
||||
```
|
||||
|
||||
预期:`sdk|`,即 authority 为 `sdk`,`migration_id` 为空。
|
||||
|
||||
2. 运行 A4 中的“废弃表检查”SQL。
|
||||
|
||||
预期:无输出。
|
||||
|
||||
3. 检查没有旧用户迁移 bundle:
|
||||
|
||||
```bash
|
||||
ls "$HOME/.one-memory/backups/"sdk-authority-v1-*.sdk-bundle/manifest.json
|
||||
```
|
||||
|
||||
预期:找不到匹配文件。全新安装不需要制作旧数据迁移备份。
|
||||
|
||||
4. CLI 空态:
|
||||
|
||||
```bash
|
||||
memhub memories list --limit 100 --json
|
||||
memhub profile --json
|
||||
```
|
||||
|
||||
写入测试记忆前,memories 的 `total` 应为 `0`;profile 应返回合法空态,而不是 404、422 或 500。
|
||||
|
||||
## 四、失败时提交什么
|
||||
|
||||
发现问题时,请附:
|
||||
|
||||
1. 测试类型:旧用户升级 / 中断恢复 / 全新安装。
|
||||
2. 旧版版本、旧版 build、新版版本、新版 build、macOS 版本和 CPU 架构。
|
||||
3. loading 阶段的截图或录屏,以及是否提前进入主页。
|
||||
4. `memhub status --json` 输出。
|
||||
5. `memhub memories list --limit 500 --json` 输出;如含隐私内容,先脱敏正文,但保留 ID、状态和数量。
|
||||
6. App 内“导出日志”生成的压缩包。
|
||||
7. `memory_authority_state` 查询结果和废弃表检查结果。
|
||||
8. 是否存在 migration bundle;不要上传真实用户的 bundle。
|
||||
|
||||
不要为了继续测试而手工删表、修改 authority 或删除 bundle。保留失败现场,复制整个测试数据目录后再恢复下一轮。
|
||||
@@ -1,8 +1,5 @@
|
||||
# Memory Event-Time Scheduling Implementation Plan
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`ARCHITECTURE.md`](ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
## Goal
|
||||
|
||||
Preserve one user memory timeline across all imported Harnesses without
|
||||
|
||||
@@ -1,8 +1,5 @@
|
||||
# MemHub 产品日志排查手册
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`ARCHITECTURE.md`](ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
本文给产品、测试和一线支持同学使用。目标不是解释底层实现,而是回答三个问题:
|
||||
|
||||
1. 数据有没有成功导入;
|
||||
|
||||
@@ -1,8 +1,5 @@
|
||||
# One Memory 诊断日志合同
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`../ARCHITECTURE.md`](../ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
更新:2026-09-24。关联 D07、D26、RT-D41。
|
||||
|
||||
## 目标
|
||||
|
||||
@@ -1,8 +1,5 @@
|
||||
# HC-06/10/11 Host Context Transport v1
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`../ARCHITECTURE.md`](../ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
Implementation scope: Host Bridge, Broker, MCP, CLI and managed Skill v10 only.
|
||||
Core aggregation/authorization adapters/routes remain owned by the main integration
|
||||
task. This slice consumes its frozen `context_models.py` contract and the identical
|
||||
|
||||
@@ -1,8 +1,5 @@
|
||||
# Memory Event-Time Scheduling v1
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`../ARCHITECTURE.md`](../ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
## Purpose
|
||||
|
||||
MemHub imports several Harnesses concurrently, but the resulting memories
|
||||
|
||||
@@ -1,8 +1,5 @@
|
||||
# MemHub recall install contract, v1
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`../ARCHITECTURE.md`](../ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
This document describes how any MCP-capable host, or any agent that can run a
|
||||
shell command, connects itself to a local MemHub install.
|
||||
|
||||
|
||||
@@ -1,7 +1,4 @@
|
||||
# One Memory Runtime 统一架构与实施合同
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`../ARCHITECTURE.md`](../ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
# MemHub Runtime 统一架构与实施合同
|
||||
|
||||
更新:2026-10-12。关联 D02、D06、D07、D08、D26、D40、RT-D41、D56。
|
||||
|
||||
@@ -18,9 +15,9 @@ One Memory 对外提供两种主要安装入口:
|
||||
- macOS 图形 App;
|
||||
- 设计目标中的跨平台 `one-memory` 兼容 CLI;当前公开入口和平台范围以安装文档为准。
|
||||
|
||||
二者不是两套产品。无论从哪个入口安装,最终都必须使用同一个 One Memory
|
||||
Runtime、同一份用户数据、同一套权限语义和同一条
|
||||
Evidence -> Hy Memory -> Governance -> Matters/Wiki 链路。
|
||||
二者不是两套产品。无论从哪个入口安装,最终都必须使用同一个 MemHub
|
||||
Runtime、同一份用户数据、同一套权限语义,以及由 Hy Memory SDK 负责的
|
||||
memory 数据面。
|
||||
|
||||
产品不变量是“一次安装、一个 Runtime、一份数据、多种客户端”。
|
||||
|
||||
@@ -28,15 +25,15 @@ Evidence -> Hy Memory -> Governance -> Matters/Wiki 链路。
|
||||
|
||||
### Kernel / Core
|
||||
|
||||
Python/FastAPI Core 是唯一记忆数据面和唯一记忆写入者,负责 Evidence、导入任务、
|
||||
Hy Memory、Governance、检索、问答、图投影和事项/Wiki。Core 不负责安装桌面窗口、
|
||||
修改宿主配置或注册操作系统服务。
|
||||
Python/FastAPI Core 是 MemHub 管理面,负责来源授权、模型配置、异步写入队列、
|
||||
SDK bridge、检索/问答 API 与 Runtime 协作。Memory/raw/vector/graph/coding
|
||||
数据面由 Hy Memory SDK 管理。Core 不负责安装桌面窗口、修改宿主配置或注册操作系统服务。
|
||||
|
||||
### Runtime
|
||||
|
||||
Runtime 是可常驻的完整本地服务,由以下部分组成:
|
||||
|
||||
- SQLite,作为 MemHub 唯一权威业务数据库,由 Core 独占写入;
|
||||
- SQLite,作为 MemHub 管理面数据库,由 Core 独占写入;
|
||||
- Core;
|
||||
- Host Gateway,包括 Recall Broker、Hook 通知和宿主授权校验;
|
||||
- Runtime discovery、本地认证、版本与健康状态;
|
||||
@@ -96,12 +93,11 @@ One Memory Home/
|
||||
logs/
|
||||
```
|
||||
|
||||
~~2026-09-26 的 D56 已明确覆盖 D53:正式产品继续以 SQLite 作为 MemHub 唯一业务数据库,
|
||||
不安装或并行维护 MySQL。Evidence、任务、cursor、session、配置、权限、Governance 和审计
|
||||
都以同一 SQLite 数据实例为权威;Adapter 仍可只读宿主自身的 SQLite 文件,HY SDK 内部
|
||||
存储另按 HY 合同处理。~~
|
||||
|
||||
**新(Top Rules):** MemHub SQLite 仍是 **管理面** 权威(任务调度、cursor、session 管理、配置、权限、审计、Matters 组织与 `memory_id` 引用等),**不再**把 Evidence / Governance 当作原文或 memory 实体权威。Memory / raw / 向量 / 图等由 **HY SDK 存储合同** 拥有。Adapter 仍可只读宿主自身文件,但写入目标是 **SDK**。Runtime 仍负责数据目录单写、管理库 schema 升级、WAL、备份恢复、磁盘预算和卸载保留数据。MemHub 管理库不并行上 MySQL 双写(与 SDK 可选 `MEMORY_CACHE_BACKEND=mysql` 无关)。
|
||||
MemHub SQLite 是管理面权威,保存任务调度、cursor、配置、权限、审计和必要的
|
||||
`memory_id` 引用,不保存 memory 实体或原始对话正文。Memory、raw、向量、图和
|
||||
coding stores 由 Hy Memory SDK 管理。Adapter 可只读宿主自身文件,写入目标是 SDK。
|
||||
Runtime 负责数据目录单写、管理库 schema 升级、WAL、备份恢复、磁盘预算和卸载保留
|
||||
数据。MemHub 管理库不并行维护 MySQL 双写;SDK 自身可选 backend 不受此限制。
|
||||
|
||||
`runtime.json` 不得包含 token。`runtime-token` 必须是 owner-only,实例退出时删除;
|
||||
Windows 在正式支持前必须实现并真机验证用户 SID/DACL,不能靠忽略 POSIX mode 过关。
|
||||
|
||||
@@ -1,8 +1,5 @@
|
||||
# SourceAdapter V1
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`../ARCHITECTURE.md`](../ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
状态:9/2 冻结;9/3 仅做向后兼容补强。
|
||||
|
||||
## 输入与输出
|
||||
@@ -17,16 +14,16 @@
|
||||
|
||||
`ScanOptions.cursors` 是同一用户、同一来源的多文件游标集合。每个 cursor
|
||||
包含 opaque `file_key`、文件 identity、已提交 checkpoint、观察到的大小和
|
||||
mtime。Adapter 只能在对应 Evidence 已提交,或该记录可安全跳过后推进该文件
|
||||
mtime。Adapter 只能在对应扫描记录已提交,或该记录可安全跳过后推进该文件
|
||||
cursor。旧文件后续追加也必须能被再次发现,不能只有一个“最后文件”游标。
|
||||
|
||||
用户授权是读取前置条件。环境变量只用于发现候选根,不能代替授权。每个候选
|
||||
文件必须在打开时再次验证 realpath 归属、symlink、普通文件类型和大小预算。
|
||||
|
||||
## Evidence
|
||||
## Imported source record
|
||||
|
||||
~~**旧目标:** Adapter 产出写入 MemHub Evidence 权威库,再进沉淀队列。~~
|
||||
**新目标:** Adapter 仍可描述「扫描到的原文记录」形状,但持久化与 raw 权威归 **SDK**;本节字段名若仍叫 Evidence,视为 **导入中间表示**,不是 MemHub 业务权威表合同。
|
||||
Adapter 输出的 `ScannedEvidence` 是兼容命名的导入中间表示。原文持久化与 raw
|
||||
权威归 Hy Memory SDK;该类型不是 MemHub 业务表合同。
|
||||
|
||||
必填:
|
||||
|
||||
@@ -34,7 +31,7 @@ cursor。旧文件后续追加也必须能被再次发现,不能只有一个
|
||||
- `message_id` 有则使用;没有稳定消息 ID 时必须提供来源内确定性的
|
||||
`source_ordinal`。ordinal 只用于区分同一会话内位置,不用于跨通道关联。
|
||||
- Hook / 插件不知道 `message_id` 但有同一稳定标识时写入 `correlation_id`;
|
||||
后续文件扫描提供相同 `message_id` 后合并为同一 Evidence。
|
||||
后续文件扫描提供相同 `message_id` 后合并为同一导入记录。
|
||||
- Adapter 必须确认 `correlation_id` 与来源 `message_id` 属于同一命名空间;
|
||||
不能把局部序号或自行生成的 UUID 填入该字段。
|
||||
|
||||
@@ -42,14 +39,14 @@ cursor。旧文件后续追加也必须能被再次发现,不能只有一个
|
||||
|
||||
- 原始 role 不能直接推导真正作者。
|
||||
- tool call 参数、tool result 正文、reasoning、文件内容和命令输出默认不进入
|
||||
Evidence;若只为维持对话结构需要,可输出不含内容的最小元数据或 `ScanSkip`。
|
||||
raw 输入;若只为维持对话结构需要,可输出不含内容的最小元数据或 `ScanSkip`。
|
||||
- 缺失来源时间保持 `null`,不能用导入时间冒充。
|
||||
- 同一来源消息经文件、Hook 或插件提供相同 `message_id` / `correlation_id`
|
||||
时合并 origins;没有可靠相关键时不凭相同文本强行合并。
|
||||
- 跨来源相同文本不能合并。
|
||||
- 每个 origin 独立保存 `raw_meta` 与 `source_version`,不能用后来的 Hook
|
||||
元数据覆盖文件定位信息;单个 origin 的 `raw_meta` 最多 64 KiB。
|
||||
- 当前只接受文本 Evidence,不声明附件、图片或音频支持。
|
||||
- 当前只接受文本记录,不声明附件、图片或音频支持。
|
||||
|
||||
## 来源能力
|
||||
|
||||
@@ -64,7 +61,7 @@ cursor。旧文件后续追加也必须能被再次发现,不能只有一个
|
||||
|
||||
## 事件、错误与恢复
|
||||
|
||||
- `ScannedEvidence`:产生一条文本 Evidence。
|
||||
- `ScannedEvidence`:产生一条文本导入记录。
|
||||
- `ScanSkip`:合法排除,如 tool content、reasoning、无文本或预算限制;不计错误。
|
||||
- `ScanFailure`:单条损坏或来源忙;Runner 记录后继续或稍后恢复。
|
||||
- `ScanProgressEvent`:只上报真实 phase 与发现目标增量;总量未知时不得估算百分比。
|
||||
@@ -73,8 +70,8 @@ cursor。旧文件后续追加也必须能被再次发现,不能只有一个
|
||||
- Adapter 整体异常使 job 进入 `failed`;正常 Core 退出使运行任务进入
|
||||
`interrupted`,不是失败。
|
||||
- `paused`、`interrupted` 或 `failed` job 从多文件 cursor set 恢复。
|
||||
- Evidence 必须先原子提交,再推进对应 cursor;若中间崩溃,重跑只能 merge,
|
||||
不能产生新 Evidence 或正文 revision。
|
||||
- 扫描记录必须先原子提交到 SDK 写入路径,再推进对应 cursor;若中间崩溃,
|
||||
重跑必须沿用确定性身份,不能产生重复 raw 记录。
|
||||
|
||||
## 版本策略
|
||||
|
||||
|
||||
@@ -1,11 +1,9 @@
|
||||
# Unified Context Read v1
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 现行权威见 [`../ARCHITECTURE.md`](../ARCHITECTURE.md) **Top Rules**。~~MemHub Evidence / `governed_*` 作原文或 memory 权威~~ 已废弃为目标;memory 读写与 backend 只经 SDK;MemHub 可存 `memory_id` 引用。下文未逐段删线的历史表述,凡与 Top Rules 冲突处以架构文档为准。
|
||||
|
||||
HC-06/08/09/10 and D47 integration slice. Implementation in progress, not host
|
||||
installation or real-data acceptance. No new user approval is inferred from this
|
||||
technical contract; the unified-read direction was explicitly approved.
|
||||
Status: legacy compatibility wire used only before the SDK data-plane cutover.
|
||||
After cutover, Host Bridge uses SDK-native Context v2. The two schemas are
|
||||
validated and returned independently; SDK data is never fabricated into v1
|
||||
revision or Evidence fields.
|
||||
|
||||
## Frozen Integration Surface
|
||||
|
||||
@@ -35,14 +33,13 @@ and trusted authority arguments. Raw adapter receives explicit permitted source
|
||||
IDs (None only for trusted local); memory receives permitted memory scopes (None
|
||||
only local). They return ContextLaneResult and never log private content.
|
||||
|
||||
All permission/deleted/user predicates precede candidate limits.
|
||||
|
||||
~~Use existing SQLite/FTS and governance semantics, not a new memory engine.~~
|
||||
**新:** memory 车道走 **SDK search/get**(可加 MemHub 授权与 `memory_id` 过滤);~~Governance SQLite 正文语义~~ 不作权威。raw 车道目标改为 **SDK raw**(迁移完成前实现可能仍读旧表,以架构 Top Rules 为准)。
|
||||
|
||||
Read connections check deadline/progress; a timed-out thread must not run unbounded.
|
||||
~~Raw returns… evidence revision/author. Memory returns current confirmed content with revision and bounded evidence IDs…~~
|
||||
**新:** raw/memory 正文与身份以 SDK 为准;MemHub 只做授权与组织引用。Exact query / lexical terms 可作为辅助,不替代 SDK 语义检索合同。
|
||||
All permission/deleted/user predicates precede candidate limits. V1 uses the
|
||||
legacy SQLite/FTS and governance semantics that existed before cutover. Read
|
||||
connections are read-only, check deadline/progress, and must not leave a timed-out
|
||||
thread running unbounded. Raw returns at most three independently authorized
|
||||
same-conversation messages per item; excerpts are bounded and carry the actual
|
||||
legacy evidence revision/author. Memory returns current confirmed content with
|
||||
revision and bounded evidence IDs, never evidence body without raw authorization.
|
||||
|
||||
One aggregate limit and character budget applies to both lanes, fairly interleaved
|
||||
when both have results. Count raw message text and memory content once in the
|
||||
@@ -67,12 +64,7 @@ not an encoding length and not a UTF-16 code-unit count, so a client in another
|
||||
language must not compare it against `String.length`: an emoji outside the BMP
|
||||
is one character here and two there.
|
||||
|
||||
## Ownership and Verification
|
||||
|
||||
Main owns models/API/external route guard/TS and integration. Workers own new
|
||||
raw adapter, memory adapter or aggregator/test files only, no existing schema,
|
||||
recall.py or model-processing changes. Other task owns Host integration in its
|
||||
separate worktree, consuming this contract after acknowledgment.
|
||||
## Verification
|
||||
|
||||
Tests require no-model/no-HY, denied-lane zero invocation, source/user/workspace
|
||||
isolation before limits, revision/revoke races, long body/metadata, count/text/
|
||||
|
||||
@@ -1,11 +1,9 @@
|
||||
# Harness 一键插入支持索引
|
||||
|
||||
|
||||
> **架构变更(2026-10-21):** 见 [`../ARCHITECTURE.md`](../ARCHITECTURE.md) Top Rules。宿主适配仍属 MemHub 管理面;~~导入进 MemHub Evidence 权威~~ 改为写入 **SDK(含 raw)**。各 harness 专页未改处冲突时以架构为准。
|
||||
|
||||
更新日期:2026-10-14
|
||||
|
||||
“一键插入应用”控制的是 **MemHub → Harness** 的 Recall 接入;“同步开关”控制的是 **Harness → MemHub** 的会话读取与处理。两者不是同一个功能。
|
||||
同步后的原始对话和记忆由 Hy Memory SDK 数据面持久化。
|
||||
|
||||
打开一键插入通常会执行:
|
||||
|
||||
@@ -55,7 +53,7 @@ Core 会:
|
||||
5. 调度 pending Job,并恢复 paused、interrupted、failed Job;
|
||||
6. 把该来源加入轮询/文件 Watcher;
|
||||
7. 补扫历史尚未处理的 Session,并继续处理未来的新 Session;
|
||||
8. 如果启用了自动记忆处理,恢复对应的 Memory Task。
|
||||
8. 如果启用了自动记忆处理,恢复对应的 `memory_write_jobs`。
|
||||
|
||||
### 关闭同步开关
|
||||
|
||||
|
||||
-70
@@ -1,70 +0,0 @@
|
||||
# 新鲜度(memory evidence freshness)拆除 TODO
|
||||
|
||||
状态:PR1 已开(读路径短路)——分支 `chore/retire-memory-freshness`。#86 不合并。
|
||||
|
||||
## 结论
|
||||
|
||||
- 新鲜度 = 写记忆时记下 `support_refs` 指纹,读时在 MemHub SQLite 里逐条核对 evidence 是否仍匹配;对不上则滤掉该 memory。
|
||||
- 这是过度设计:读路径成本高、失败面大(曾导致记忆库整页 503),收益仅是「证据被改过就藏记忆」。
|
||||
- 业务层为喂 SDK 再做长证据分段(`segment_*`),与 SDK 自身阶段/窗口处理重复;#86 只是继续兼容这套 proof,不应合入。
|
||||
|
||||
## 范围(MemHub Core,非 SDK)
|
||||
|
||||
权威库:`~/.one-memory/one-memory.sqlite3`
|
||||
不涉及 SDK `hy-memory/**` 内部 store。
|
||||
|
||||
### 读路径(优先拆)
|
||||
|
||||
| 位置 | 作用 |
|
||||
|---|---|
|
||||
| `memhub/apps/core/src/one_memory/memory_evidence_freshness.py` | UDF `is_memory_evidence_current`、proof prefetch、预算跳过 |
|
||||
| `source_read_access.py` | 列表/过滤时 per-memory freshness |
|
||||
| `context_memory.py` | search/context 候选行 `_memory_row_is_fresh` |
|
||||
| `memory_library.py` / `home_summary.py` | 记忆库 / 首页可读谓词 |
|
||||
| `memory_visibility.py` | 可见性缓存与 freshness 注册 |
|
||||
| `call_event_references.py` | 引用解析时的 freshness |
|
||||
|
||||
### 写路径 / 数据(后拆,可分 PR)
|
||||
|
||||
| 位置 | 作用 |
|
||||
|---|---|
|
||||
| `memory_tasks.py` → `MemoryTaskOutput.support_refs` / `TaskEvidenceRef` | 抽取输出里的证明 |
|
||||
| `memory_task_outputs` 表 | proof 持久化 |
|
||||
| `memory_processing.py` 分段(`segment_evidence_record` / `_semantic_segment_spans`) | 为 HY 窗口切段;与 freshness 耦合但不全是 freshness——分段是否保留需单独拍板 |
|
||||
|
||||
### 测试(随拆除改/删)
|
||||
|
||||
- `tests/test_memory_evidence_freshness.py`
|
||||
- `tests/test_memory_freshness_integration_review.py`
|
||||
- `tests/test_read_path_freshness_batch.py`
|
||||
- 以及 mock `register_memory_freshness` 的 library / context / visibility / home_summary / call_event 测试
|
||||
|
||||
## 建议落地步骤
|
||||
|
||||
1. **读路径短路(最小 PR)** — 本 PR
|
||||
`register_memory_freshness` 恒返回 `"1"`(UDF 恒 `1`),`freshness_proofs_prefetched` 为空操作。行为:证据改过也不再藏 memory;畸形/segment proof 不再 503。
|
||||
同步改「期望 stale=0」的单测为「始终可读」。
|
||||
|
||||
2. **拆调用点**
|
||||
去掉 `AND is_memory_evidence_current(...)`、`freshness_proofs_prefetched`、`_memory_row_is_fresh` 等死代码,避免假接口长期残留。
|
||||
|
||||
3. **停写 / 弃用 proof(可选第二 PR)**
|
||||
新任务不再依赖 `support_refs` 做读决策;表与历史行可先保留只读,再决定是否 migration 清理。
|
||||
|
||||
4. **分段策略另议**
|
||||
长证据切段是 ingest 窗口问题,不是新鲜度问题。拆除 freshness 后单独决定:继续由 MemHub 切 messages,还是交给 SDK。
|
||||
|
||||
5. **对外沟通**
|
||||
- #86:已留言不合并、将拆除设计。
|
||||
- 相关 issue(如 #74 里 freshness 503)关闭或改指向「拆除」而非「修 segment」。
|
||||
|
||||
## 验收
|
||||
|
||||
- 记忆库 / search / context 在存在「证据已修订 + 旧 proof」时仍返回该 memory,且不再因 malformed/segment ref 503。
|
||||
- 无 `ONE_MEMORY_FRESHNESS_*` 行为依赖;文档/env 若有提及一并删。
|
||||
- Core 相关测试绿。
|
||||
|
||||
## 非目标
|
||||
|
||||
- 不改 SDK 内部抽取/存储。
|
||||
- 不在本轮做「用别的一致性模型替换 freshness」;先删,再按需重设计。
|
||||
Reference in new issue
Block a user