Compare commits

...
Author SHA1 Message Date
alvinfeiandCursor c2c4d5ff8a docs: remove internal notes and stale architecture markup
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-22 15:31:59 +08:00
alvinfeiandCursor 3c8d662ad0 chore: keep HANDSOFF local only
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-22 15:26:56 +08:00
21 changed files with 92 additions and 649 deletions

No files matched your search

+3
View File
@@ -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
View File
@@ -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
View File
@@ -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
View File
@@ -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
View File
@@ -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.
-3
View File
@@ -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`
-2
View File
@@ -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.
+13 -17
View File
@@ -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 过关。
+10 -13
View File
@@ -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/
+2 -4
View File
@@ -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
View File
@@ -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」;先删,再按需重设计。